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:
I would be interested to learn how others have tackled this issue.
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 :(
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.
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.