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.co...@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 <peeip...@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.co...@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 <peeip...@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.co...@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@voiceops.org >>>> https://puck.nether.net/mailman/listinfo/voiceops >>>> >>> >>> >> >
_______________________________________________ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
