[VoiceOps] TCP Signaling for SIP Signaling

Mon Jul 17 15:30:41 EDT 2017

UDP remains the "weapon of choice" for sip trunking applications and for 
many subscriber applications.  However, feature-rich subscriber 
implementations frequently require SIP messages to be substantially 
larger than the (approximately) 1500 byte MTU (maximum transmission 
unit) supported in the public internet.   UDP has a mechanism for 
dealing with messages greater than MTU size, but it doesn't work 
reliably for SIP over UDP in the public internet.

When you need to go > 1500 bytes, you need to go to TCP.

Although SIP registration state and SIP call state can be replicated 
over a pair of SBC's (Acme or Sonus), TCP state cannot be maintained.  
There is way to much going on at the driver level for that to be 
practical.  When switchover occurs, the TCP "transmission control" 
parameters are stale.   So, there will be a TCP RST, and the endpoints 
need to start over with the whole SYN / SYN,ACK "three-way handshake" 
drill.

Although the subscriber device will in all likelihood need to restart 
the TCP session, the worst-case disruption will be only as long as the 
re-registration interval.  And even then, only outbound calls (toward 
the subscriber device) will be affected.  But even in that unlucky 
instance, voice mail should save the day.

The Acme "TCP session leak" was fixed several years ago  At least 
three.   Any software having that leak has been End of Support for long 
time.

If anybody would like further discussion, feel free to contact me directly.

    John S. Robinson
    jsr (at) communichanic dot com
    Communichanic Consultants, Inc.

On 7/17/2017 08:32, Pete Eisengrein wrote:
> Perfect example. With an Acme SBC as a redundant pair, if (when) the 
> primary fails and switches to the standby, all UDP immediately goes to 
> the standby and is generally unnoticed by the end users. However, if 
> the SIP is over TCP in that scenario, the switch still happens but the 
> TCP session must re-establish itself to the secondary SBC and 
> therefore is an outage for those users until they re-register. I 
> suppose it is possible to share TCP session info, but I am not aware 
> of any SBC's that do this any differently (though would love to hear 
> from the group if one exists).
>
> Somewhat related, but not really: It's since been patched but Acme 
> (Oracle) had a bug at one point where it was not releasing TCP 
> sessions after they were gone and you'd end up using all available 
> resources (TCP ports); if that happened you'd begin blocking new 
> sessions and the only workaround was a forced switchover which, of 
> course, then meant a forced outage for those users.
>
> -Pete
>
> On Mon, Jul 17, 2017 at 9:01 AM, Colton Conor <colton.conor at gmail.com 
> <mailto:colton.conor at gmail.com>> wrote:
>
>     Thanks for the replies. I am mainly talking about using TCP for
>     SIP signaling for access/customer side of the network only. I
>     think trunk connections to carriers will stay UDP only for a long
>     time.
>
>     Overwhelming it seems like using TCP for signaling doesn't seem to
>     be a bad thing, and preferred by many. Peter, I have a question
>     about what you mean by "But the biggest reason I prefer UDP is for
>     failover/redundancy. In the event of a system failure/failover,
>     UDP will be in-disrupted but TCP will."
>
>     Lets assume we are using Broadsoft with an Acme Packet SBCs, and
>     have redundancy having one on the West coast and one on the east
>     cost.
>
>     Using TCP for signaling, how would this be different than using
>     UDP in a fail over secenario? Assume the client is closer to the
>     West cost node, and the West coast node rebooted or shut down due
>     to power failure.
>
>
>     Using UDP for RTP makes perfect sense. Sorry for asking the stupid
>     question about RTP.
>
>     On Sun, Jul 16, 2017 at 9:59 PM, Peter E <peeip989 at gmail.com
>     <mailto:peeip989 at gmail.com>> wrote:
>
>         The SIP protocol already has some built in reliability
>         techniques built in (timers, retransmission) for which TCP is
>         usually used. Yes, TCP is a bit more resource intensive due to
>         the TCP overhead. But the biggest reason I prefer UDP is for
>         failover/redundancy. In the event of a system
>         failure/failover, UDP will be in-disrupted but TCP will. Your
>         TLS argument is valid, however.
>
>         RTP will always be UDP. Think about it... TCP will retransmit
>         when packers are lost, but in real time communication there is
>         no need to retransmit. While packet loss is problematic, a
>         retransmission of lost packets would be unexpected and cause
>         further quality issues.
>
>
>
>         On Jul 16, 2017, at 22:28, Colton Conor
>         <colton.conor at gmail.com <mailto:colton.conor at gmail.com>> wrote:
>
>         I know UDP seems to be the gold standard for SIP, and is in
>         use by most service providers that are offering hosted voice
>         today. My question is why not use TCP instead of UDP for SIP
>         signaling?
>
>         Overall with small business clients we run into firewalls with
>         SIP ALGs, short UDP session time out limits, and all sorts of
>         connectivity issues with UDP. Some small business routers and
>         modems have built in SIP ALGs that can't be disabled at all.
>         The second we switch to TCP for signaling most of the issues
>         go away for our hosted voice customers. Overall TCP just
>         always seems to work, and UPD depends on the situation of the
>         network. TCP is better for battery consumption on mobile sip
>         applications as well.
>
>         With more providers switching to encryption using TLS which
>         uses TCP, is there any need for us UDP for signaling anymore?
>         Assuming most IP phones from Polycom, Yealink, and Cisco
>         support TCP why not use it? Is it more resouce intensive on
>         the SBCs?
>
>         What about on the media side? Does the RTP use UDP or TCP? If
>         it uses UDP can TCP be used? What about for encryption like
>         SRTP? Is SRTP TCP or UDP?
>
>
>         _______________________________________________
>         VoiceOps mailing list
>         VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org>
>         https://puck.nether.net/mailman/listinfo/voiceops
>         <https://puck.nether.net/mailman/listinfo/voiceops>
>
>
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20170717/38073de3/attachment.html>