CUBE Transcoding Design Question

[James Hawkins]

Hello,

I work in the United Kingdom where SIP providers typically use G.711alaw as the codec of choice for calls. Sometimes where the calling party selects G.729 the SIP provider passes this straight through so this needs to be dealt with too.

I am implementing a Cisco Unified Contact Center Express system for a customer and certain features (mainly recording) mandate that this system use G.711ulaw.

This means that inbound calls via the SIP provider must be converted to ulaw by the CUBE. I have set up LTI based transcoding and this works ok but the DSP resource requirement for transcoding all inbound calls is very expensive in terms of PVDM resource required. The current CUBE is an ISR 4431 with PVDM4-256. If I configure the LTI transcoding so that it can deal with G729 and G711alaw as inbound codecs to be transcoded to G711ulaw the maximum number of calls supported is 192 which is below the 250 channels supported by the trunk.

I am looking for suggestions to resolve this. Possible solutions I have though of include:

1. Only transcode calls to contact centre pilot numbers (I could do this by placing those numbers in an E.164 pattern map and setting up a dial-peer that with that as the destination with the codec set as ulaw). The idea behind this is that only calls to contact centre numbers would be transcoded with other calls passed through the CUBE with the codec used for the inbound call leg. I dislike this for the reason that every time a UCCX pilot number is created it would have to be added to the CUBE config. I am not sure if there are any other issues to consider with this approach?
2. Use an MTP rather than transcoder to convert between alaw and ulaw. I would be looking at using a software MTP configured on the CUBE but am unsure whether this can convert between alaw and ulaw or whether a DSP based MTP is required for that.

I would be interested to learn how others have tackled this issue. 

[Mike_Brezicky]

This may not exactly answer your question, but I have dealt with enough random carriers and codec delivery outside of the US, that ever new deployment, I recommend, and almost require the router to have an additional PVDM installed to meet the total call paths. My default config for all Europe sites have hardware transcoders for 7.11, 7.29, and 7.22. Then with all devices in the site having access to the transcoder in the Media resource group, I rely on the destination to determine what it requires and the router to transcode it properly.

The point for me in all this is I try to avoid MTP as much as possible.

[James Hawkins]

Thanks for your input Mike. Useful to know what works for you. The ISR G3's seem limited in terms of PVDM functionality compared to their predecessors though.

I have found the statement below in the SRND

When Cisco IOS MTP resources are invoked by Unified CM for a call flow, a software session rather than a hardware DSP session is consumed unless the media legs of the call flow require transrating. Thus, for flows invoking an MTP, a DSP session is used only when transrating (conversion between media legs with the same codec but different packetization times) is required.

It seems that I can cross software based MTP conversion between alaw and ulaw off my list of potential solutions :(

[Jonathan Schulenberg]

An IOS Enhanced software MTP is capable of G.711 ulaw to alaw conversion so long as the sample size (ie packetization interval) doesn’t need to change; 20ms is the default.

I agree with Mike here and really suggest avoiding a CUCM-registered media resource for CUBE. That will significantly complicate the call signaling/media path and MTPs often create problems of their own.

As for the capacity, this is why Cisco created the Service Module form factor DSPs:
https://www.cisco.com/c/en/us/products/collateral/routers/4000-series-integrated-services-routers-isr/data_sheet_c78-728307.html
If you work with your Cisco AM they may be able to return the PVDM4-256 or provide some discounting to make the correct DSP capacity more palatable.

[James Hawkins]

Jonathan,

Thank you for the clarification around alaw to ulaw conversion. This could be configured to take place on the same ISR that runs the CUBE function so the media path should be simple (I would not allow that MTP resource to be used by other devices).

Are you aware of any guidelines on how many software based MTP sessions may be configured on an ISR router?

I am also wondering whether I can get away without supporting G.729 as an inbound codec? - I have not seen any inbound calls that use it but the provider (British Telecom) recommends that it be enabled as they just pass through calls with whatever codec preference the caller sets.

Re. the Service Module it is not supported in the ISR 4431 router they have so they are limited to one PVDM4-256.

If I was able to get away without G.729 I could get the required number of LTI based transcoding sessions using the PVDM4-256.

Do you ever run in to this issue with UCCX deployments? - I attended a Cisco UCCX Summit in Amsterdam a couple of months ago and the lack of proper support for alaw within UCCX was the top issue raised with the CCX BU.

[Jonathan Schulenberg]

Huh, I hadn’t noticed the SM modules aren’t supported on the 4431. Nice catch.

The media path is just as complex, it’s just looping around inside the router - hitting the CPU - inside of the on the wire. I have not seen Cisco publish MTP capacity but heard that you should look at the CUBE concurrent call support as a guideline. Considering the router will be processing the call twice I would suggest halving the capacity of both features. For a 4431 that would be 1500 as a starting point. The only way to be sure though would be to hammer test it and validate it holds up under load.

As for CUCM MRGL, be careful about the assumption that only the SIP Trunk being able to access it. I honestly don’t know the logic of how MediaResourceManager chooses the calling vs. called party MGRL for the call. I’m not certain that is a viable approach.

As for G.729, I am in the US. The incumbent here is AT&T and they make the same recommendation because they will not interwork/transcode between codecs if the far-end offers an incompatible codec. All it takes is one customer/business partner/etc. that uses SIP and only offers G.729 to cause a call failure if you don’t support it.