CUCM media resource allocation question

[Chris Deren]

Say a SIP trunk from CUBE invokes an MTP due to a DTMF mismatch as it connects to IPIVR (RFC2833 vs. OOB), the MRGL has both G711 and G729 MTPs in the same MRG as most calls arrive via G729 and offer both G711/G729. However some calls from specific carrier cloud IVR offer only G711. I am noticing that CUCM is not intelligent enough to select matching G711 MTP and instead goes down its resrouce select list and allocates G729 MTP and then requires to invoke an Xcoder. Is there a way to "force" CUCM to select matching codec MTPs more intelligently?

[Jaime Valencia]

I don't believe you can do that, I think when it comes to MRG/MRGL, CUCM is only intelligent enough to distinguish between the need/availability of a video CFB Vs. an audio CFB.

CUCM only knows that it has an MTP available, but not the config/capabilities from it, and it still tries to do the best effort round robin, and once it chooses a resource because it said it had enough resources available, it sticks to it, even if it's not the right one.

[Jonathan Schulenberg]

---

CUCM only knows that it has an MTP available, but not the config/capabilities from it

Are you sure about that Jaime? I though that media resources report their capabilities when they register.

Other ideas, just in case they’re useful:

- Add “codec pass-through” to the MTP.

- Have CUBE perform the DTMF interworking instead and avoid the MTP in the first place. “dtmf-relay rtp-nte sip-kpml” is one of my favorite CUBE commands. RFC2833 to KPML doesn’t even require an LTI.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561

[Jaime Valencia]

Let me doublecheck on that and I'll come back

[Chris Deren]

Thanks guys, it appears CUCM gets codec-passthrough capabilities from the router and will use those resources as of CUCM 10.5 based on what I read, and it's clearly visible in SDL traces, but it does not appear to get codec capabilities and thus does not intelligently select desired MTP.

I have used LTI on many occasions, but it's not an option here as there are many moving parts here including multiple clusters some of which are running unsupported versions and unsupported UCCE with IPIVR.  I am using “dtmf-relay rtp-nte sip-kpml” for majority calls, though ran into some other DTMF issues requiring me to separate dial-peers to use reverse order, etc.  Lots of fun with unsupported IPIVR and SIP trunking going over ICT between clusters :-)

Jaime, if you are able to dig up something about possibility of CUCM allocating MTPs based on codec let me know. 

[Ayodeji Okanlawon]

Chris,

CUCM does not have the capability to intelligently select an MTP based on codec configured. A throw back to the days when transcoders cant perform the role of MTP. One of the fundamental design consideration in this case is to ensure that you have your MTP in a seperate MRG from your transcoder and that the MRG for MTP is the first in the MRGL, because CUCM doesnt have the intelligent to know if it needs a transcoder or MTP, same as with codec capabilites. CUCM does know the capabilites of media resources as they advertise their capabilites when registering with it, but CUCM doesnt have the kind of intelligence to know which MTP to allocate based on the negotiated capabilites of the call. ( One reason why you have to ensure that the region setting between your device invoking MTP and your MTP is the codec configured on that MTP)

The only way to force the selection of an MTP is to use codec pass-through as Jonathan suggested, because CUCM prefers an MTP configured with pass through capabilites. Codec pass-thru MTP's are preferred in this case so that video, SRTP, or T38 can potentially be negotiated later in the cal if needed. However this provides a different inssue here. The implication of this is that all your calls will choose the MTP with pass-through on them and if this a G729 MTP, then it doesnt solve your issue.

[Georgios Fotiadis]

Hello Chris,

a possible workaround/solution to this could be:

you could create a second SIP Trunk between CUCM and CUBE (let's say to another loopback IP address). The first SIP trunk would have "MTP Preferred Originating Codec" G711 while the second G729 and a MRGL with the corresponding MTP (G711 or G729 accordingly).

Now, on the CUBE side you would have 2 dial-peers, each one matching the desired SIP trunk using "voice-class sip bind" on for each codec negotiation.

If your ITSP is using early-offer then CUBE would pick the desired dial-peer, leading to the desired SIP trunk and MTP.

I have re-produced it in lab and it seems to be working.

[Chris Deren]

Georgios,

that at was my plan for backup solution as well, though the issue was resolved by adjusting codecs on regions involved in the call flow, so there was no need for it. Customer has firewalls everywhere will long process for adjusting rules hence adding new IPs would take some time to adjust the rules.

[Ayodeji Okanlawon]

Georgio, first of all people like you make this forum great. So (+5) for taking time to simulate this.

A few questions though. I dont get how this would work..

How will CUBE select the correct SIP trunk based on the codec offered, if the call is made to the same DNIS.??

I am not aware of any feature in CUBE that selects dial-peer based on offers in the SDP. Perhaps I am missinbg something here

[Georgios Fotiadis]

Thank you Ayodej. Credits should also be to Chris for posting such interesting cases.

CUBE will not make any selection. There would be two dial-peers configured with different preferences; one for each SIP Trunk (i.e. for each codec G711 and G729) with same-destination. The call will hit the first dial-peer (eg the G729 one), but if it is G711 call it will fail and then hit the second (the G711 one). That worked only when ITSP was sending early offer.

[Ayodeji Okanlawon]

Ah got you, but cube will not reroute based on cause code of 47. I think if the wrong dial-peer is selected, the call will fail out rightly.

[Georgios Fotiadis]

Indeed, that was the case when I was receiving delayed offer from the "ITSP". It wasn't failing back and the call was failing instantly.

(In that case I thought using SIP profiles, translating the destination number and then matching another dial-peer, but didn't move forward with that; it would be interesting though (match one criteria with SIP profiles - that would be SDP of G711/G729- and then changing another part of the INVITE - the "To header" in order to select different dial-peer. Anyway...)

When I enabled early offer, it was trying the second (in preference) dial-peer. This is a config sample:

dial-peer voice 30 voip
 preference 3
 destination-pattern ^2...$
 session protocol sipv2
 session target ipv4:192.168.1.71
 voice-class sip bind control source-interface Loopback0
 voice-class sip bind media source-interface Loopback0
 dtmf-relay rtp-nte sip-notify
 codec g711ulaw
 no vad
!
dial-peer voice 32 voip
 preference 1
 destination-pattern ^2...$
 session protocol sipv2
 session target ipv4:192.168.1.71
 voice-class sip bind control source-interface Loopback1
 voice-class sip bind media source-interface Loopback1
 dtmf-relay rtp-nte sip-notify
 no vad
!
interface Loopback0
 ip address 10.10.32.1 255.255.255.255
!
interface Loopback1
 ip address 10.10.32.10 255.255.255.255
!

In the "g711_call.txt"("fallback" from G729 which is the preferred) there is:

Outgoing Dial-peer=32

...

Call Entry(Disconnect Cause=47, Voice Class Cause Code=0, Retry Count=0)

...

and then

Outgoing Dial-peer=30

[Ayodeji Okanlawon]

Excellent stuff. That is indeed very interesting, that CUBE will reorute a failed call based on early offer. I wonder what the logic is..Kind of like to get to the bottom of things :)