- VoiceOps - lists.voiceops.org

TCP Signaling for SIP Signaling
by colton.conor＠gmail.com July 18, 2017

July 18, 2017

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?

11 29

TCP Signaling for SIP Signaling
by colton.conor＠gmail.com July 18, 2017

July 18, 2017

I do believe this to be the case. Its step two in the BroadSoft Partner Configuration Guide Polycom UC Software VVX and Trio Phones Dated May 2017 Document Version 3.8 Step 2 Enter the Preferred Transport Type. Example: voIpProt.server.1.transport=?TCPp referred? Set the Transport Protocol Type to ?TCP?. This is the suggested protocol to use, and prior to version 3.0.0, is required if using Busy Lamp Field (BLF). On Mon, Jul 17, 2017 at 10:30 PM, Colton Conor <colton.conor at gmail.com> wrote: > I do believe this to be the case. Its step two in the attached BroadSoft > Partner Configuration Guide Polycom UC Software VVX and Trio Phones Dated > May 2017 Document Version 3.8 > > > Step 2 Enter the Preferred Transport Type. Example: > voIpProt.server.1.transport=?TCPp referred? Set the Transport Protocol > Type to ?TCP?. This is the suggested protocol to use, and prior to version > 3.0.0, is required if using Busy Lamp Field (BLF). > > On Mon, Jul 17, 2017 at 1:46 PM, Michael Bain <mike at redpoint.systems> > wrote: > >> 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. >> >> >> 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) >> >> I don't believe Polycom and BroadSoft are asserting that TCP is the best >> method overall. >> >> Mike >> >> Sent from my iPhone >> >> On Jul 17, 2017, at 9:42 AM, Colton Conor <colton.conor at gmail.com> wrote: >> >> Pete, >> >> Still not quite understanding how multiple SBC's vs primary/standby >> fail-over is differnet? Wouldn't primary/standby fail-over require 2 >> SBCs? >> >> Yes, I am referring to Polycom's TCPpreferred setting. I just looked at >> Polycom Admin guide, the the default is DNSnaptr not TCPpreferred. >> However, in Broadsoft's recommended device config file it says use TCPpreferred. >> Also in Polycom's guide, they recommend Note: Use BLF with TCPpreferred >> transport Use this feature with TCPpreferred transport. I assume this is >> due to UDP framentation with large BLF packets. >> >> 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. >> >> >> >> >> On Mon, Jul 17, 2017 at 10:06 AM, Pete Eisengrein <peeip989 at gmail.com> >> wrote: >> >>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> VoiceOps mailing list >> VoiceOps at voiceops.org >> https://puck.nether.net/mailman/listinfo/voiceops >> >> >

1 0

E911 service in Mexico
by DLai＠transbeam.com July 12, 2017

July 12, 2017

Anyone have any experience with E911 service in Mexico? If so, can you send me a list of providers? Preferably US based providers. Thanks in advance! [cid:image001.jpg at 01D2770D.2FC9F310] Daniel Lai Lead, Network Engineering Transbeam p: 212.631.8100 x228 m: 917.731.3257 a: 8 W 38th Street | 7th Fl | New York, NY 10018 e: dlai at transbeam.com<mailto:dlai at transbeam.com> [cid:image002.png at 01D2770D.2FC9F310]<https://www.facebook.com/Transbeam/> [cid:image003.png at 01D2770D.2FC9F310] <https://twitter.com/transbeam> [cid:image004.png at 01D2770D.2FC9F310] <https://www.linkedin.com/company/transbeam/> [cid:image005.png at 01D2770D.2FC9F310] <https://www.instagram.com/transbeamusa/> [cid:image009.jpg at 01D27710.1B9AFD50]

2 1

Wholesale Voice Platform
by jschmidt＠giganection.com July 11, 2017

July 11, 2017

We are searching for a wholesale voice platform provider (broadsoft, metaswitch, etc) and I am reaching out to this list for suggestions. We need to be able to utilize our Origination and Termination providers and E911 provider. We would like to have API access for provisioning from our B/OSS system, but this is not required. We handle both residential voice and business UC services.

8 13

Misconfigured e.164 addresses in From: field
by David.Zilk＠cdk.com July 11, 2017

July 11, 2017

How common is it that SIP received from a carrier would have a misconfigured e.164 address in the From: field? We are seeing calls from various US numbers appearing with a leading '+', but no '1' country code. Therefore they appear to be originating from a foreign caller. An example would be: From: sip:+208488xxxx at aaa.bb.cc.dd:5060;user=phone Which would appear to be from Egypt (country code: 20) but is really from Boise, Idaho (NPA: 208) We are seeing this from at least one of our carriers. Do we need to just live with this, or should it be something that we try to get fixed? It doesn't impact routing of calls, but it messes up our statistics. --- David Zilk Senior VoIP Engineer Network Solutions CDK Global, LLC Evolving the Automotive Retail Experience 2525 SW 1st Ave Suite 450 Portland, Oregon 97201-4760 o: 503-402-3132 m: 503-753-6591 cdkglobal.com<http://cdkglobal.com/> Follow us on: Twitter<https://twitter.com/CDKGlobal> Facebook<https://www.facebook.com/CDKGlobal> LinkedIn<https://www.linkedin.com/company/1464?trk=vsrp_companies_res_name&trkInfo=V…> YouTube<https://www.youtube.com/user/adpdealer> ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.

6 12

Offnet LIDB providers
by david＠ringfree.com July 8, 2017

July 8, 2017

Can anyone provide a recommendation for LIDB providers that can support offnet numnbers? So far I haven't been able to find anyone. Our main origination provider is Level3, and their ELS package is pricey. We're using other providers for CNAM and 911, but so far haven't found anyone that can support getting listings into LIDB. Thanks David -- David Wessell *Co-Owner*, Ringfree Communications, Inc. [image: Ringfree Communications Logo] <http://www.ringfree.com/> Phone: (828) 575-0030 x101 <82825750030> Email: david at ringfree.com Website: www.ringfree.com 824 Locust St. Suite 200 Hendersonville, NC 28792 [image: Twitter] <https://www.twitter.com/RingfreeCom> [image: Facebook] <http://www.facebook.com/Ringfree> [image: LinkedIn] <http://www.linkedin.com/company/ringfree-communications-llc> How was your experience? Tell us by taking our Customer Service Survey <https://www.supersimplesurvey.com/Survey/16842/signature/>. *Confidentiality Note: * This e-mail and any attachments are confidential and may be protected by legal privilege. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation.

3 2

Origination Provider
by anakaoka＠trinet-hi.com July 3, 2017

July 3, 2017

Who do you use for Origination? I'm looking for options on origination since we're having issues with our current provider. thanks, Aryn

3 6

Porting in cell numbers without canceling service
by caalvarez＠gmail.com July 3, 2017

July 3, 2017

We have a new customer who needs to port some Verizon wireless numbers to us, but not cancel the cell contract. They want to keep it and just have a new number on the cell phones. Any tips on accomplishing this? I haven't asked them to call Verizon yet, figured I'd see if someone here has experience doing it.

2 1

CNAM lookup options for Broadowks (SIP or SOAP)
by paul＠timmins.net June 30, 2017

June 30, 2017

An HTML attachment was scrubbed... URL: <https://puck.nether.net/pipermail/voiceops/attachments/20170630/f9637b36/at…>

1 0

CNAM lookup options for Broadowks (SIP or SOAP)
by matthew＠corp.crocker.com June 30, 2017

June 30, 2017

Hello, I?m looking into getting CNAM lookups working in Broadworks instead of having my Taqua perform SS7 dips. Broadworks supports lookups via SIP or SOAP. I?m testing ezcnam.com via SIP. Broadworks sends the SUBSCRIBE and I get a NOTIFY response. Broadworks then fails on decoding the Calling-Name from ezcnam Does anyone on this list use a CNAM service with Broadworks (R20sp1)? If so, can you send me some contacts for ones that work? Thanks -Matt -- Matthew Crocker Crocker Communications, Inc. President

1 0