Thank you to everyone who responded to me. It was a service provider issue and they didn't admit it until the 3rd day when the issue was escalated to someone who was willing to do something about it.
I will take these tips away for future use because I'm sure it won't be the last time with this certain provider! > From: cisco-voip-requ...@puck.nether.net > Subject: cisco-voip Digest, Vol 142, Issue 25 > To: cisco-voip@puck.nether.net > Date: Sat, 29 Aug 2015 12:00:03 -0400 > > Send cisco-voip mailing list submissions to > cisco-voip@puck.nether.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://puck.nether.net/mailman/listinfo/cisco-voip > or, via email, send a message with subject or body 'help' to > cisco-voip-requ...@puck.nether.net > > You can reach the person managing the list at > cisco-voip-ow...@puck.nether.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cisco-voip digest..." > > > Today's Topics: > > 1. Service Provider SIP Trunks (Aaron Banks) > 2. Re: Service Provider SIP Trunks (Ryan Huff) > 3. Re: Service Provider SIP Trunks (Daniel Pagan) > 4. Re: Service Provider SIP Trunks (Ryan Huff) > 5. Re: Service Provider SIP Trunks (Daniel Pagan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 28 Aug 2015 12:34:54 -0700 > From: Aaron Banks <amichaelba...@hotmail.com> > To: "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net> > Subject: [cisco-voip] Service Provider SIP Trunks > Message-ID: <blu182-w2574baa20ca25f0c2c91e3bc...@phx.gbl> > Content-Type: text/plain; charset="iso-8859-1" > > > > I have a strange problem with SIP trunks. Let me preface this with the > service provider moved the SIP trunks to a different device and that's what > certain calls stopped working. Before this move, everything was tested and > working for 6 weeks. Read on, someone might have had the same experience. > > Post SIP trunk move, callers inside of the organization cannot call 911 or a > mobile phone (ANY mobile phone). When they dial the number, let's use 911 > for example, the call rings once, the calling line ID is delivered to 911 and > then the call goes to busy. So 911 knows that organization called. The same > thing happens with mobile phones. All other call types (local, LD, > international) work. If I call forward a phone from inside of the > organization to a mobile phone and call that forwarded phone (from outside or > inside), the call is redirected to the mobile, call is answered and then the > call drops. If I forward that same phone inside of the organization to an > outside land line ((either local or LD), the call is successful. > > For 911 or the mobile calls that fail, the SIP trace reveals a 500 (internal > server error), a BYE message with reason Q.850; cause=16. The SIP call > messages show the state of the call is DEAD. > > My question is why would the number make any difference at all? Has anyone > ever seen this type of issue before? The provider says it is CUCM 10.5/Voice > GW 2901 that is rejecting the call. I disagree. > > Many thanks > > Aaron > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/ed70f204/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Fri, 28 Aug 2015 15:38:36 -0400 > From: Ryan Huff <ryanh...@outlook.com> > To: amichaelba...@hotmail.com, cisco-voip@puck.nether.net > Subject: Re: [cisco-voip] Service Provider SIP Trunks > Message-ID: <col401-eas1249a294d219f1c393d1feec5...@phx.gbl> > Content-Type: text/plain; charset="utf-8" > > Sounds like a codec/media issue. Are you supporting early offer? > > Thanks, > > Ryan > > -------- Original Message -------- > From: Aaron Banks <amichaelba...@hotmail.com> > Sent: Friday, August 28, 2015 03:35 PM > To: cisco-voip@puck.nether.net > Subject: [cisco-voip] Service Provider SIP Trunks > > > > > > >I have a strange problem with SIP trunks. Let me preface this with the > >service provider moved the SIP trunks to a different device and that's what > >certain calls stopped working. Before this move, everything was tested and > >working for 6 weeks. Read on, someone might have had the same experience. > > > >Post SIP trunk move, callers inside of the organization cannot call 911 or a > >mobile phone (ANY mobile phone). When they dial the number, let's use 911 > >for example, the call rings once, the calling line ID is delivered to 911 > >and then the call goes to busy. So 911 knows that organization called. The > >same thing happens with mobile phones. All other call types (local, LD, > >international) work. If I call forward a phone from inside of the > >organization to a mobile phone and call that forwarded phone (from outside > >or inside), the call is redirected to the mobile, call is answered and then > >the call drops. If I forward that same phone inside of the organization to > >an outside land line ((either local or LD), the call is successful. > > > >For 911 or the mobile calls that fail, the SIP trace reveals a 500 (internal > >server error), a BYE message with reason Q.850; cause=16. The SIP call > >messages show the state of the call is DEAD. > > > >My question is why would the number make any difference at all? Has anyone > >ever seen this type of issue before? The provider says it is CUCM > >10.5/Voice GW 2901 that is rejecting the call. I disagree. > > > >Many thanks > > > >Aaron > > > > > >_______________________________________________ > >cisco-voip mailing list > >cisco-voip@puck.nether.net > >https://puck.nether.net/mailman/listinfo/cisco-voip > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/7950a917/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Fri, 28 Aug 2015 20:57:16 +0000 > From: Daniel Pagan <dpa...@fidelus.com> > To: Aaron Banks <amichaelba...@hotmail.com>, > "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net> > Subject: Re: [cisco-voip] Service Provider SIP Trunks > Message-ID: > <1c1f93ba8ffa49c29f992738a1efd...@nyc-ex2k13-mb.fidelus.com> > Content-Type: text/plain; charset="windows-1252" > > My first step would be to find out the direction of the 500 final response. I > would run a ccsip messages debug on CUBE and recreate the issue for > determining where the 500 final response is being generated. The User-Agent > header should tell you what device is generating it. My second step would be > to determine where in the call flow this 500 is being generated. The 500 is a > final response, so it's likely going to be after the INVITE and 100 TRYING - > but you shouldn't see a 200 OK since that would give you two final responses. > Do you see a 180 or 183? If so then I would try to find out if there's an SDP > offer or answer in the 1XX provisional.. perhaps the remote SBC doesn't like > your offer or answer. Is there a Require: 100rel in the 100, 180 or 183? If > so then is your equipment sending a PRACK? > > Just a few thoughts that come to mind. Like you, I would also be skeptical of > the provider's findings until reviewing the SIP transactions and making sure > for myself. > > Use the request URI (i.e. INVITE > sip:<dialed_num>@<dest-ip<sip:%3cdialed_num%3e@%3cdest-ip>-or-fqdn>) for > finding your call and the Call-ID header to track your two call-legs in CUBE. > > Feel free to send me SIP debugs off your CUBE outside the email list and > after recreating the issue - I can take a few minutes to review them offline. > > Dan > > From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of > Aaron Banks > Sent: Friday, August 28, 2015 3:35 PM > To: cisco-voip@puck.nether.net > Subject: [cisco-voip] Service Provider SIP Trunks > > > I have a strange problem with SIP trunks. Let me preface this with the > service provider moved the SIP trunks to a different device and that's what > certain calls stopped working. Before this move, everything was tested and > working for 6 weeks. Read on, someone might have had the same experience. > > Post SIP trunk move, callers inside of the organization cannot call 911 or a > mobile phone (ANY mobile phone). When they dial the number, let's use 911 > for example, the call rings once, the calling line ID is delivered to 911 and > then the call goes to busy. So 911 knows that organization called. The same > thing happens with mobile phones. All other call types (local, LD, > international) work. If I call forward a phone from inside of the > organization to a mobile phone and call that forwarded phone (from outside or > inside), the call is redirected to the mobile, call is answered and then the > call drops. If I forward that same phone inside of the organization to an > outside land line ((either local or LD), the call is successful. > > For 911 or the mobile calls that fail, the SIP trace reveals a 500 (internal > server error), a BYE message with reason Q.850; cause=16. The SIP call > messages show the state of the call is DEAD. > > My question is why would the number make any difference at all? Has anyone > ever seen this type of issue before? The provider says it is CUCM 10.5/Voice > GW 2901 that is rejecting the call. I disagree. > > Many thanks > > Aaron > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/1824cd00/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Fri, 28 Aug 2015 17:13:31 -0400 > From: Ryan Huff <ryanh...@outlook.com> > To: amichaelba...@hotmail.com, cisco-voip@puck.nether.net > Subject: Re: [cisco-voip] Service Provider SIP Trunks > Message-ID: <col401-eas17675cc6e82562bc8a3a3b1c5...@phx.gbl> > Content-Type: text/plain; charset="utf-8" > > > Thanks, > > Ryan > > -------- Original Message -------- > From: Ryan Huff <ryanh...@outlook.com> > Sent: Friday, August 28, 2015 05:12 PM > To: amichaelba...@hotmail.com > Subject: RE: [cisco-voip] Service Provider SIP Trunks > > >As long as you didn't change anything on the cpe side, it may be more likely > >your itsp changed more than just the pe. > > > >You should be able to reproduce a failed call and provide your itsp with the > >session id and they should be able trace it; sometimes that encourages them > >to find whatever they broke. > > > >Thanks, > > > >Ryan > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/4ddff46c/attachment-0001.html> > > ------------------------------ > > Message: 5 > Date: Fri, 28 Aug 2015 21:16:11 +0000 > From: Daniel Pagan <dpa...@fidelus.com> > To: Ryan Huff <ryanh...@outlook.com>, "amichaelba...@hotmail.com" > <amichaelba...@hotmail.com>, "cisco-voip@puck.nether.net" > <cisco-voip@puck.nether.net> > Subject: Re: [cisco-voip] Service Provider SIP Trunks > Message-ID: > <860ce63f3895431ba28a86cdd6ef9...@nyc-ex2k13-mb.fidelus.com> > Content-Type: text/plain; charset="utf-8" > > Hey Ryan! Hope you?re well ? > > Just wanted to add here that not supporting early offer should result in one > of two things ? either local ring back would be generated on the calling > device and/or there will be no audio in scenarios where audio cut-through is > required before the 200 final response (sometimes experienced with toll-free > numbers). But in terms of call failure and complete disconnect, I?m unaware > of any true requirement built into SIP for early offer or early media. > > By ?no requirement? I?m referring to the lack of built-in specific SIP > headers that call for early offer or early media. The offer/answer model for > SDP states that an SDP answer must be included in a 200 if the offer is in an > INVITE, or must be in the ACK for the 200 if the offer is in the 200 final > response. These types of requirements ensure that media turn-up has a way to > be established regardless if early media is successful or early offer is > supported. More on this in RFC 3261 section 13.2.1. > > Hope this helps anyone reading. > > Dan > > From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of > Ryan Huff > Sent: Friday, August 28, 2015 3:39 PM > To: amichaelba...@hotmail.com; cisco-voip@puck.nether.net > Subject: Re: [cisco-voip] Service Provider SIP Trunks > > > Sounds like a codec/media issue. Are you supporting early offer? > > Thanks, > > Ryan > > > -------- Original Message -------- > From: Aaron Banks > <amichaelba...@hotmail.com<mailto:amichaelba...@hotmail.com>> > Sent: Friday, August 28, 2015 03:35 PM > To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> > Subject: [cisco-voip] Service Provider SIP Trunks > > I have a strange problem with SIP trunks. Let me preface this with the > service provider moved the SIP trunks to a different device and that's what > certain calls stopped working. Before this move, everything was tested and > working for 6 weeks. Read on, someone might have had the same experience. > > Post SIP trunk move, callers inside of the organization cannot call 911 or a > mobile phone (ANY mobile phone). When they dial the number, let's use 911 > for example, the call rings once, the calling line ID is delivered to 911 and > then the call goes to busy. So 911 knows that organization called. The same > thing happens with mobile phones. All other call types (local, LD, > international) work. If I call forward a phone from inside of the > organization to a mobile phone and call that forwarded phone (from outside or > inside), the call is redirected to the mobile, call is answered and then the > call drops. If I forward that same phone inside of the organization to an > outside land line ((either local or LD), the call is successful. > > For 911 or the mobile calls that fail, the SIP trace reveals a 500 (internal > server error), a BYE message with reason Q.850; cause=16. The SIP call > messages show the state of the call is DEAD. > > My question is why would the number make any difference at all? Has anyone > ever seen this type of issue before? The provider says it is CUCM 10.5/Voice > GW 2901 that is rejecting the call. I disagree. > > Many thanks > > Aaron > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/68267084/attachment-0001.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > > > ------------------------------ > > End of cisco-voip Digest, Vol 142, Issue 25 > *******************************************
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
