CUBE with DSP’s registered to CUCM and G729 to G711 Call Legs

[kmeyersva]

I have a CUBE with the basic configuration of a SIP ITSP on one side and CUCM on the other. CUCM was recently updated and we hit a known bug with UCCX regarding Call Hold with one leg of the call going to a CUBE.  The work around to get UCCX functional was to select “MTP Required” on the trunk heading to the CUBE (which required us to select the preferred codec to G729).

We also have a LYNC server that only talks G711. Prior to the upgrade we could get calls in from the outside which would be transcoded successfully. Since we changed the trunk to “MTP Required” inbound calling to LYNC fails.  What I tried to do was to create a new dial-peer selecting G711 as the codec and pointing this directly to the LYNC server thus bypassing the CUCM trunk.  The CUBE will not even send an INVITE to LYNC but instead falls back on the generic dial-peer pointing to CUCM when I have the codec specified on the dial-peer as G711.  I’ve ran some debugs and verified that the correct dial-peer is being selected for the LYNC number but receive a “Cause Value=47” causing the CUBE to not send an INVITE with G711 to LYNC. I’m not sure this will work but thought it might be a workaround.  I also tried a “voice class codec” with G711 as the 1^st preference (G729 as second) but the INVITE hits LYNC with SDP of G729 only (never even sending the possibility of G711)

I have media resources configured on the CUBE but all are registered to CUCM. Does the CUBE not send an INVITE to LYNC due to no transcoding resources registered to the CUBE itself?  If so, can you split off some transcoders to register to the CUBE and the remaining to CUCM? One additional question is I could not find a good debug to see how the transcoding is being selected in IOS.  If anyone could supply the debug to get more information I’d appreciate it.

I’ll attach the debug if that helps. Calling number is 43424938XX and Called number is 43442233YY.

Thanks,

Ken

[Ayodeji Okanlawon]

Can you post your CUBE config...The call shows that the inbound dial-peer matched Dial-peer=7700 and the outbound dial-peer is 252..

From what you have described, it looks as if CUBE is stuck on selecting your preferred  codec in the inbound invite...

So when CUBE receives INVITE from ITSP the codec advertised in this order: G729, G711ulaw, G711alaw

v=0

o=BroadWorks 104852222 1 IN IP4 172.31.153.228

s=-

c=IN IP4 172.31.153.228

t=0 0

m=audio 17560 RTP/AVP 18 0 8 101 (g729, g711u, g711a)

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

a=fmtp:18 annexb=no

Ideally what should happen is that the CUBE should select one of this codec in the outgoing dial-peer to use for the outbound INVITE..In your case if its g711, then the invite should go out with G711..But thats not whats happening...So you have one leg of the call at g729 and the other leg at g711 and CUBE wants to invoke a xcoder for the outbound INVITE. This is not normal. That points to a defect in IOS code. I have similar scenario and invite is succesfully sent using G711 in my case too..

For the xcoder, in scenarios like htis, you will need an onboard xcoder, not the one registered with CUCM. But you shoudlnt need a xcoder for calls like this...Lets have a look at your config first

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[kmeyersva]

Aokanlawon,

    Thanks for taking a look.

    When the ITSP sends us SDP with the 3 codec's advertised should he not send 3 "a=" lines or is this normal for them to advertise the codecs they'll accept but only 1 "a=" line is given?

Ken

[Ayodeji Okanlawon · Accepted solution]

Ken,

Your config is wrong..This is why CUBE is behaving this way..

The inbound dial-peer 7700 has this voice class codec 10 on it..however its only g729 codec in its codec list..

voice class codec 10

codec preference 1 g729r8

The implication of this is that CUBE can only use g729 for outbound INVITE..to resolve this please configure your voice class codec 10 as follows:

codec preference 1 g729r8

codec preference 2 g711ulaw

codec preference 3 g711alaw

Then on your dial-peer 252..just use g711. remove the voice class codec and it should work

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[kmeyersva]

As has come to be expected you are 100% right in your answer.

Just for my education, the codec's specified on the inbound dial-peer will be the deciding factor on what codecs get sent on the outbound dial-peer INVITE? 

Much appreciate your support!

Ken

[Ayodeji Okanlawon]

Ken,

I think its better to say that a combination of the codecs offered to the CUBE and the inbound dial-peer will determine what codec is used..

You can read my document on dial-peer codec selection on CUBE

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

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"