[VoiceOps] TCP Signaling for SIP Signaling

[Pete Eisengrein]

If you have multiple SBC's (e.g. DNS SRV) then yeah, it would drop and need
to re-register for both UDP and TCP. I was talking about primary/standby
failover, which is more likely than a complete data center failure
(**knocks on wood**). Are you referring to Polycoms for TCPpreferred? I
think that's the default Polycom setting.

On Mon, Jul 17, 2017 at 10:59 AM, Colton Conor <colton.conor at gmail.com>
wrote:

> Pete,
>
> That makes sense. Lets assume a user that was registered to the west coast
> SBC using UDP. If the west coast was to fail and they were on an active
> call, its not like the call would continue and bounce over to the East
> coast right? The call would drop, and the customer would have to call back
> right?
>
> Assuming you have your phones register every 5 minutes or so how would
> that differ then UDP vs TCP? Are you saying UDP would instantly re-register
> to the east cost node, but TCP would wait 5 minutes to it re registers?
>
> I have noticed in the Broadsoft device config files provided by Broadsoft,
> that Broadsoft themselves recommends TCPpreferred: TCP is the preferred
> transport, UDP is used if TCP fails. However, I have yet to see any
> Broadsoft based providers make TCPpreferred as the standard for the Polycom
> phones. Everyone seems to leave it on the default of DNSnaptr or UDP only,
> and uses UDP signaling. The question is why aren't they following the
> Broadsoft lab tested and recommended approach?
>
>
>
>
>
> On Mon, Jul 17, 2017 at 8:32 AM, Pete Eisengrein <peeip989 at gmail.com>
> 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>
>> 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> 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> 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
>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20170717/9a5dbdc0/attachment.html>