[cisco-voip] Service Provider SIP Trunks

[Daniel Pagan]

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-bounces at puck.nether.net] On Behalf Of Aaron Banks
Sent: Friday, August 28, 2015 3:35 PM
To: cisco-voip at 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.html>