CUCM SIP and CUBE call connects then terminates

[richard.priest]

Hi,

I'm trying to reconfigure a CUBE that's was setup as a H.323 gateway between its self and CUCM over to a SIP trunk between the two. Unfortunately whilst the trunk is showing as up in CUCM, outgoing calls are connecting and then terminating and I can't figure out why. (note that as a H.323 gateway calls worked fine, but I'm getting issues with no ringback or hold music when calling CSQ's etc and figured SIP to SIP would be less problematic in that regard...!

Our ISPT provider is Gamma in the UK if that makes any difference.

I've attached a sanitised copy of the CUBE config and a copy of debug ccsip messages

If anyone can off any advise or assistance I'd be really grateful

[Dennis Mink]

Your cucm sends a 183 session in progress. Cube sends it out to itsp and itsp responds with a cancel. Have you sopken to your itsp? Also what is this number on the cucm an ivr?

[richard.priest]

Many thanks for this,

I have spoken with our ISPT, the only thing they came back with is that they only support G711alaw, and that we're presenting them with G711ulaw, but even when I configure the cube to only use alaw I get the same error when attempting to connect a call.

[Maren Mahoney]

The disconnect code of Q.850;cause=88 indicates an attribute "that cannot be accommodated." (Although that's more generic than it sounds.)
Your ITSP-facing dial-peers are showing voice-class codec 1, which does prefer ulaw over alaw, but the SDPs in the debug are showing alaw. Nonetheless, I would change the voice-class codec on the dial-peers to 3 which has alaw preferred. Alternately, manually configure codec g711alaw on the ITSP-facing dial-peers
(And probably the CUCM-facing ones, too, unless you have a reason not to. On a side note, have you configured CUCM itself to prefer alaw over ulaw?)
The other thing I see on the ITSP-facing dial-peer 772002 is the "voice-class sip dtmf-relay force rtp-nte" which is not on any other dial-peer. Did your service provider have you add that to your dial-peer or did you add that? I could see the "requirement" of that (rather than negotiation) being a compatibility issue.
Give those two things a try (force alaw, and remove the force rtp-nte) and try the call and let us know what happens.

Maren

[richard.priest]

Thanks Maren,

I changed all the ISTP and CUCM facing dial peers by removing the codec list and statically setting G711alaw, unfortunately there was no difference.

I've attached another log after making this change.

When you mention configuring CUCM to prefer alaw, do you mean on the trunk config or somehwhere else? On the trunk config I have set the MTP preferred Originating Codec as 711alaw, but can't see any other config on the SIP trunk for codec type?

Cheers

Richard

[Maren Mahoney]

Did you remove the rtp-nte forced from the dial-peer (or confirm that this is recommended by your ITSP)?

There is a CallManager service parameter that allows you to turn off G711ulaw altogether, but that is not recommended unless you are 100% sure you will not need it anywhere. The better way to prefer alaw over ulaw is to configure an Audio Codec Preference List that lists alaw over ulaw and apply that list to all of your regions. Here is a link for that information:

CUCM Administration Guide - Audio Codec Preference List

Once you set this, you should not need (nor do you want) an MTP inserted on your communications via the trunk. Set the SIP profile to "Early Offer Support - Best Effort (no MTP inserted)" , but then have early offer forced on the router (which you do).

Maren

[richard.priest]

I had forgotten to remove the rtp-nte forced, but just tried removing it now with no change in behaviour.

I've created a new audio codec preference list, but rather than change the regions, I've applied it as a service parameter, unfortunately that made zero difference either

FWIW I've attached another failed call log. Why am I now getting a 486 busy here message now?

[Evgeny Izetov · Accepted solution]

In this last debug the CUBE is sending a delayed offer and ITSP may require early offer.

In the previous debugs it is CUCM that sends CANCEL:

1. CUBE is sending an early offer to ITSP

2. ITSP is replying with Trying, then 183 Session Progress with SDP

3. CUBE is acknowledging the 183 with PRACK, then sends 183 to CUCM

4. CUCM sends CANCEL with cause=88

Check that you have "SIP Rel1XX Options" set to "Send PRACK if 1XX contains SDP" on the SIP profile of the SIP trunk in CUCM. Also, disable QSIG Tunneling on the SIP trunk in CUCM - I don't believe it's doing anything in your topology.

On a side note, there's an alphabet soup of commands under voice service voip > sip. Generally, I prefer to start with a really basic SIP config and then add commands only if needed. You'd only need early-offer forced as a starter there.

[richard.priest]

Apologies for the delay in responding, I can't thank everyone enough for their help. 

Our setup is now much clearner and tider, SIP trunk both ends. Looks like there was not much wrojng with the CUBE config other than the hodgepodge of random commands (that's me trying to fix it!) Cleaned all that out and adjusted the CUCM side of the SIP trunk as per your suggestions and it all burst into life!

I really need to learn how to read the SIP messages properly, they make me go quite a bit cross-eyed!

[Maren Mahoney]

In addition to what Evgeny said, the fact that CUCM is sending the SDP in binary is absolutely a problem. I'm not sure what changed on CUCM that it is sending it in binary, but that is causing your ITSP-facing dial-peer to send delayed-offer, which they are rejecting.

[Evgeny Izetov]

The binary is the QSIG tunneling feature:

Content-Type: application/qsig

 The previous debugs had both SIP SDP and QSIG:

Content-Type: multipart/mixed;boundary=uniqueBoundary

So, the latest debug was also a delayed offer from CUCM.