Diverted calls to cell via SIP Trunk not completing

[Jorge F]

Hey gentlemen,

Having some issue here with a SIP trunk on our Cube router.

We had a wan link downtime due to a carrier physical failure and when it came back up certain SIP operations against a Verizon SIP trunk went mad.

The last one not being sorted out is when we have an extension forwarded to a cell phone: If I call a phone with such a forward, the SIP call to the target cell will fail on the Cube.

If I call to the cell phone directly from any phone, the call will complete.

However if a switch to H323 between CUCM (7.1.5) and Cube the "diverted" call will complete succesfully, which lets me smell there's something wrong with the protocol on our LAN side.

Find attached a SIP debug from the Cube. At certain point there's a codec mismatch, but no DSPs are being used at all for transcoding and there's plenty of unused resources, so this shouldnt be the issue.

The Cubes and hard phones region relationship is forced to G729, and the Verizon wan side call is also set to 729.

Looking forward to hearing from you some suggestions.

Thank you.

[Jorge F]

I'll answer myself:

Disabling "Redirecting Diversion Header Delivery - Outbound" at the SIP Trunk config @ CUCM did the trick.

H323 does not work the same way that's why it worked out.

No explanation for the codec thing saw on the debug output, we'll dive into that later on.

Thank you.

[Ayodeji Okanlawon · Accepted solution]

Jorge,

Just to help you understand what is going on with the codec on the divert. Codec selection on the divert is a little different from normal calls.

Look at the call flow:

PSTN1----------->CUBE-------->PhoneA--------cfwd---------->CUBE----->PSTN2

                           <------------G729---------->

                          <-----------------------------G711---------------------------->

In this scenario, Region between phone and cube=g729

regionbetween cube=g711

Now because in a CFWD rtp stream did not actually get setup with the phone because the phone didnt answer the codec settings between the ip phone and the cube does not come into effect.

The RTP strream is setup between the CUBE. So call comes in on the CUBE and call goes out via the CUBE, hence you will see whatever region relationship is used between the CUBE. If its the same CUBE you will see G711.

I wrote a document to explain in detail how codec is  negotiated on call flows like this..take a look here..It is quite detailed and it will help you understand much better the codec selection matrix.

https://supportforums.cisco.com/docs/DOC-26098

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Jorge F]

That pretty much explains the codec behaviour when it comes to a call divert.

I was unaware of this slight change in the way codecs are negotiated.

Will refer to your document to dig into this some more.

Great input, thank you.