<div><div dir="auto"><div id="m_3976838716337398058AppleMailSignature"><blockquote type="cite"><div><font color="#000000"><span style="background-color:rgba(255,255,255,0)">So sounds like both Polycom and Broadsoft agree TCPpreferred aka use TCP when possible is the best method, especially when using BLF. So the question is why do most NOT due this. I assume there has to be some reason not to. </span></font></div></blockquote><div><br></div></div></div></div><div><div dir="auto"><div id="m_3976838716337398058AppleMailSignature">I don't believe this is the case. TCP was recommended iff you were using BLF and had large packets. (Some of the SoundPoint line had an issue with UDP fragmentation, I don't believe the VVX line has this issue)</div><div id="m_3976838716337398058AppleMailSignature"><br></div><div id="m_3976838716337398058AppleMailSignature">I don't believe Polycom and BroadSoft are asserting that TCP is the best method overall.</div><div id="m_3976838716337398058AppleMailSignature"><br></div><div id="m_3976838716337398058AppleMailSignature">Mike<br><br>Sent from my iPhone</div></div></div><div><div dir="auto"><div><br>On Jul 17, 2017, at 9:42 AM, Colton Conor <<a href="mailto:colton.conor@gmail.com" target="_blank">colton.conor@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div><div>Pete,</div><div><br></div><div>Still not quite understanding how multiple SBC's vs <span style="font-size:12.8px"> primary/standby fail-over is differnet? Wouldn't </span><span style="font-size:12.8px"> primary/standby fail-over require 2 SBCs? </span></div><div><br></div>Yes, I am referring to Polycom's <span style="font-size:12.8px"> TCPpreferred setting. I just looked at Polycom Admin guide, the the default is </span>DNSnaptr not <span style="font-size:12.8px">TCPpreferred. However, in Broadsoft's recommended device config file it says use </span><span style="font-size:12.8px">TCPpreferred. Also in Polycom's guide, they recommend </span>Note: Use BLF with TCPpreferred transport
Use this feature with TCPpreferred transport. I assume this is due to UDP framentation with large BLF packets. <div><br></div><div>So sounds like both Polycom and Broadsoft agree TCPpreferred aka use TCP when possible is the best method, especially when using BLF. So the question is why do most NOT due this. I assume there has to be some reason not to. </div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 10:06 AM, Pete Eisengrein <span><<a href="mailto:peeip989@gmail.com" target="_blank">peeip989@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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. </div><div class="m_3976838716337398058HOEnZb"><div class="m_3976838716337398058h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 10:59 AM, Colton Conor <span><<a href="mailto:colton.conor@gmail.com" target="_blank">colton.conor@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Pete,<div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="m_3976838716337398058m_751488298775833150HOEnZb"><div class="m_3976838716337398058m_751488298775833150h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 8:32 AM, Pete Eisengrein <span><<a href="mailto:peeip989@gmail.com" target="_blank">peeip989@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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).<div><br></div><div>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. </div><div><br></div><div>-Pete</div></div><div class="m_3976838716337398058m_751488298775833150m_533813743380032299HOEnZb"><div class="m_3976838716337398058m_751488298775833150m_533813743380032299h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 9:01 AM, Colton Conor <span><<a href="mailto:colton.conor@gmail.com" target="_blank">colton.conor@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Thanks for the replies. I am mainly talking about using TCP for SIP signaling for <span style="font-size:12.8px">access/customer side of the network only. I think trunk connections to carriers will stay UDP only for a long time. </span><div><br></div><div>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 "<span style="font-size:12.8px">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." </span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div>Using UDP for RTP makes perfect sense. Sorry for asking the stupid question about RTP. </div></div></div><div class="m_3976838716337398058m_751488298775833150m_533813743380032299m_-2823537556677005469HOEnZb"><div class="m_3976838716337398058m_751488298775833150m_533813743380032299m_-2823537556677005469h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 16, 2017 at 9:59 PM, Peter E <span><<a href="mailto:peeip989@gmail.com" target="_blank">peeip989@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<div><div class="m_3976838716337398058m_751488298775833150m_533813743380032299m_-2823537556677005469m_-1292223908235040841h5"><br>
<br>
<br>
On Jul 16, 2017, at 22:28, Colton Conor <<a href="mailto:colton.conor@gmail.com" target="_blank">colton.conor@gmail.com</a>> wrote:<br>
<br>
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?<br>
<br>
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.<br>
<br>
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?<br>
<br>
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?<br>
<br>
<br>
</div></div>_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>VoiceOps mailing list</span><br><span><a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a></span><br><span><a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a></span><br></div></blockquote></div></div>