[cisco-voip] Service Provider SIP Trunks

Daniel Pagan dpagan at fidelus.com
Fri Aug 28 17:16:11 EDT 2015


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-bounces at puck.nether.net] On Behalf Of Ryan Huff
Sent: Friday, August 28, 2015 3:39 PM
To: amichaelbanks at hotmail.com; cisco-voip at 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 <amichaelbanks at hotmail.com<mailto:amichaelbanks at hotmail.com>>
Sent: Friday, August 28, 2015 03:35 PM
To: cisco-voip at puck.nether.net<mailto: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/68267084/attachment.html>


More information about the cisco-voip mailing list