<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>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.<br><br>I will take these tips away for future use because I'm sure it won't be the last time with this certain provider!<br><br><div>> From: cisco-voip-request@puck.nether.net<br>> Subject: cisco-voip Digest, Vol 142, Issue 25<br>> To: cisco-voip@puck.nether.net<br>> Date: Sat, 29 Aug 2015 12:00:03 -0400<br>> <br>> Send cisco-voip mailing list submissions to<br>> cisco-voip@puck.nether.net<br>> <br>> To subscribe or unsubscribe via the World Wide Web, visit<br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> or, via email, send a message with subject or body 'help' to<br>> cisco-voip-request@puck.nether.net<br>> <br>> You can reach the person managing the list at<br>> cisco-voip-owner@puck.nether.net<br>> <br>> When replying, please edit your Subject line so it is more specific<br>> than "Re: Contents of cisco-voip digest..."<br>> <br>> <br>> Today's Topics:<br>> <br>> 1. Service Provider SIP Trunks (Aaron Banks)<br>> 2. Re: Service Provider SIP Trunks (Ryan Huff)<br>> 3. Re: Service Provider SIP Trunks (Daniel Pagan)<br>> 4. Re: Service Provider SIP Trunks (Ryan Huff)<br>> 5. Re: Service Provider SIP Trunks (Daniel Pagan)<br>> <br>> <br>> ----------------------------------------------------------------------<br>> <br>> Message: 1<br>> Date: Fri, 28 Aug 2015 12:34:54 -0700<br>> From: Aaron Banks <amichaelbanks@hotmail.com><br>> To: "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] Service Provider SIP Trunks<br>> Message-ID: <BLU182-W2574BAA20CA25F0C2C91E3BC6E0@phx.gbl><br>> Content-Type: text/plain; charset="iso-8859-1"<br>> <br>> <br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Many thanks<br>> <br>> Aaron<br>> <br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/ed70f204/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 2<br>> Date: Fri, 28 Aug 2015 15:38:36 -0400<br>> From: Ryan Huff <ryanhuff@outlook.com><br>> To: amichaelbanks@hotmail.com, cisco-voip@puck.nether.net<br>> Subject: Re: [cisco-voip] Service Provider SIP Trunks<br>> Message-ID: <COL401-EAS1249A294D219F1C393D1FEEC56E0@phx.gbl><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Sounds like a codec/media issue. Are you supporting early offer?<br>> <br>> Thanks,<br>> <br>> Ryan<br>> <br>> -------- Original Message --------<br>> From: Aaron Banks <amichaelbanks@hotmail.com><br>> Sent: Friday, August 28, 2015 03:35 PM<br>> To: cisco-voip@puck.nether.net<br>> Subject: [cisco-voip] Service Provider SIP Trunks<br>> <br>> ><br>> ><br>> >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.<br>> ><br>> >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.<br>> ><br>> >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.<br>> ><br>> >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.<br>> ><br>> >Many thanks<br>> ><br>> >Aaron<br>> ><br>> > <br>> >_______________________________________________<br>> >cisco-voip mailing list<br>> >cisco-voip@puck.nether.net<br>> >https://puck.nether.net/mailman/listinfo/cisco-voip<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/7950a917/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 3<br>> Date: Fri, 28 Aug 2015 20:57:16 +0000<br>> From: Daniel Pagan <dpagan@fidelus.com><br>> To: Aaron Banks <amichaelbanks@hotmail.com>,<br>> "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Service Provider SIP Trunks<br>> Message-ID:<br>> <1c1f93ba8ffa49c29f992738a1efd848@NYC-EX2K13-MB.fidelus.com><br>> Content-Type: text/plain; charset="windows-1252"<br>> <br>> 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?<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Dan<br>> <br>> From: cisco-voip [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Aaron Banks<br>> Sent: Friday, August 28, 2015 3:35 PM<br>> To: cisco-voip@puck.nether.net<br>> Subject: [cisco-voip] Service Provider SIP Trunks<br>> <br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Many thanks<br>> <br>> Aaron<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/1824cd00/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 4<br>> Date: Fri, 28 Aug 2015 17:13:31 -0400<br>> From: Ryan Huff <ryanhuff@outlook.com><br>> To: amichaelbanks@hotmail.com, cisco-voip@puck.nether.net<br>> Subject: Re: [cisco-voip] Service Provider SIP Trunks<br>> Message-ID: <COL401-EAS17675CC6E82562BC8A3A3B1C56E0@phx.gbl><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> <br>> Thanks,<br>> <br>> Ryan<br>> <br>> -------- Original Message --------<br>> From: Ryan Huff <ryanhuff@outlook.com><br>> Sent: Friday, August 28, 2015 05:12 PM<br>> To: amichaelbanks@hotmail.com<br>> Subject: RE: [cisco-voip] Service Provider SIP Trunks<br>> <br>> >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.<br>> ><br>> >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.<br>> ><br>> >Thanks,<br>> ><br>> >Ryan<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/4ddff46c/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 5<br>> Date: Fri, 28 Aug 2015 21:16:11 +0000<br>> From: Daniel Pagan <dpagan@fidelus.com><br>> To: Ryan Huff <ryanhuff@outlook.com>, "amichaelbanks@hotmail.com"<br>> <amichaelbanks@hotmail.com>, "cisco-voip@puck.nether.net"<br>> <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Service Provider SIP Trunks<br>> Message-ID:<br>> <860ce63f3895431ba28a86cdd6ef9751@NYC-EX2K13-MB.fidelus.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Hey Ryan! Hope you?re well ?<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Hope this helps anyone reading.<br>> <br>> Dan<br>> <br>> From: cisco-voip [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Ryan Huff<br>> Sent: Friday, August 28, 2015 3:39 PM<br>> To: amichaelbanks@hotmail.com; cisco-voip@puck.nether.net<br>> Subject: Re: [cisco-voip] Service Provider SIP Trunks<br>> <br>> <br>> Sounds like a codec/media issue. Are you supporting early offer?<br>> <br>> Thanks,<br>> <br>> Ryan<br>> <br>> <br>> -------- Original Message --------<br>> From: Aaron Banks <amichaelbanks@hotmail.com<mailto:amichaelbanks@hotmail.com>><br>> Sent: Friday, August 28, 2015 03:35 PM<br>> To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] Service Provider SIP Trunks<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Many thanks<br>> <br>> Aaron<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150828/68267084/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Subject: Digest Footer<br>> <br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> <br>> ------------------------------<br>> <br>> End of cisco-voip Digest, Vol 142, Issue 25<br>> *******************************************<br></div> </div></body>
</html>