<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>OK so to expand on my previous smug-ness <br>
</p>
<p>Upsides: <br>
</p>
<ul>
<li>No more signaling nat issues. Literally zero. If you want to
be super-sneaky run your edge over TLS port 443 and most things
wont touch you. <br>
</li>
<li>No retransmission's or registration avalanches. They simply
cannot happen since you need a tcp session first. <br>
</li>
<li>No packet fragmentation issues. Send massive bloated SDP's and
never worry about pruning headers again. If you are doing sip
SIMPLE send mime bodies in messages if you want. Its all good. <br>
</li>
<li>Faster convergence (if you reset the TCP connections to your
devices it will usually trigger an instantaneous proxy advance)<br>
</li>
<li>Real-HA on carrier grade SBC's works just fine and TCP state
is maintained across pairs (Acme, Perimeta etc)</li>
<li>Never chase lost signaling<br>
</li>
</ul>
<p><br>
</p>
<p>Downsides: <br>
</p>
<ul>
<li>Conventional HA doesnt work so well. Your reg/subscription etc
will all be in the context of a single TCP session (with or
without TLS). This means for that second when you restart your
proxy the session is lost and MUST be re-establised by the
client. </li>
<li>SIP Outbound support, which would basically be the answer here
basically doesn't exist in a usable fashion for reliable
dual-reg. Device support is partial and broken. Its not good.
There are potential solutions but it involves real commitment to
this right now and the gulf of experience between having and not
isnt huge. </li>
<li>Moderately more load since TCP state must be retained, but on
modern hardware this is so trivial its almost not worth
mentioning. </li>
<li>Need to re-learn KPI's for network. The entire signaling
profile changes. Its just a different animal. <br>
</li>
<li>Most of your sniffer-based diagnostic tools become useless
(for tls) since packets wont be readable. This is dodged with an
edge that will feed encrypted traffic to a collector. <br>
</li>
</ul>
<p><br>
</p>
<p>Suggestions: <br>
</p>
<p>STRONGLY recommend terminating TCP/TLS at the edge and still
running core in straight UDP with jumbo frames. You dont want a
cascde of tcp session reestablishments <br>
</p>
<p>I have a growing SP network today doing this with great success
and also advise my consulting clients to take this path. <br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 8/8/2018 12:36 PM, Alex Balashov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20180808193640.GA5232@tlaquepaque.localdomain">
<pre wrap="">On Wed, Aug 08, 2018 at 12:21:09PM -0700, Carlos Alvarez wrote:
</pre>
<blockquote type="cite">
<pre wrap="">So...who else on the list uses TCP and has any comments about it?
</pre>
</blockquote>
<pre wrap="">
We are not an ITSP and are Polycom-only with a trivial number of
endpoints, but we do use it and it works just fine.
However, we have numerous customers, some of whom use TCP predominantly
for thousands of endpoints. It works just fine.
In terms of downsides:
In addition to a historical lack of (RFC 3261-mandated) support, there
are of course theoretical trade-offs involved in using TCP. There's
more overhead, and connection state to be maintained on the server side,
which of course consumes resources — resources considered trivial
nowadays, but once upon a time, when RFC 3261 was ratified (2002),
perhaps not. As with all things TCP, it can also present a DoS vector if
you don't limit the number of connections somewhere.
The congestion control/end-to-end delay aspects of TCP are certainly not
as important now as they were at a time when the public IP backbone and
was in an entirely different place in its evolution. Also, nowadays the
congestion/windowing algorithms used in TCP can be tweaked to something
more efficient.
I think the most damning thing about using TCP is perceived to be the
relative difficulty of failing over TCP session state to a different
host. UDP does not require connection state, so as long as you have some
means of handling requests in a relatively stateless fashion, things can
just carry on as they did before in the event of an IP takeover without
anyone having to "reconnect". This is one area where the big enterprise
boxes certainly trump the open-source ecosystem, where transparent TCP
failover *for SIP* doesn't really exist, although in my opinion the
whole issue is getting a bit moot with the way cloud infrastructure and
virtualisation networking is evolving.
-- Alex
</pre>
</blockquote>
<br>
</body>
</html>