Transcoding in CUBE

[tony loktu]

Hi

As our TSP is removing the support for G.711ulaw it will impose probles for our UCCX.

We also have 2x CUBE with DSPs so i should be able to transcode there.

I found this thread but i cant seam to make it work as we only have dial-peers (not ephones) on CUBE.

https://supportforums.cisco.com/t5/ip-telephony/ccx-recording-g711alaw/td-p/2568155

Or do i actually have to configure telephony service on CUBE to make it work?

There is no way of making a dial-peer for the DNs thats directed to the UCCX (the DNs are scattered around).

/T

[Chris Deren]

You can either configure LTI transcoding on the CUBE:

https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/115018-configure-cube-lti.html

Or register the DSP farm with CUCM via SCCP and allow SCCP invoking the transcoder when needed for CCX calls.

[tony loktu]

Hi Chris

I must have overcomplicated things, because LTI was quick to configure (i did it in an staging environment).

The traffic flow with LTI is easy to figure out. Would SCCP registered xcode differ much? Would the load on the resources on CUBE differ?

It is only for the UCCX we need transcoding.

/T

[Chris Deren]

With SCCP registered to CUCM you would build the profile, associate with CUCM instance and on CUCM build the transcoder and assign to proper MRG.  

Please rate all useful posts.

Chris

[R0g22]

LTI Xcoder won't be invoked by CUCM. This is local to CUBE only. If there is a requirement for CUCM to invoke a Xcoder for calls to your UCCX, then you would need the resource to be SCCP registered.
To answer your other question, LTI is less performance intensive since there is no need for TCP connections, SCCP usage etc.

[Ayodeji Okanlawon]

Hi, Tony

 LTI is easier to configure. However if you only want to transcode calls to only UCCX environment , then you will be better off using SCCP based transcoders. You will need to setup MRG/MRGL in CUCM and assign this to your UCCX CTI-devices.

[tony loktu]

Hi Ayodeji

As it registers in CUCM i assume i have it correctly configured:

!
voice-card 0
dspfarm
dsp services dspfarm
!

!
sccp local GigabitEthernet0/0
sccp ccm xx.xx.xx.xx identifier 1 version 7.0
sccp ccm xx.xx.xx.xx identifier 2 version 7.0
sccp ccm xx.xx.xx.xx identifier 3 version 7.0
sccp
!

sccp ccm group 1
associate ccm 1 priority 1
associate ccm 2 priority 2
associate ccm 3 priority 3
associate profile 1 register XCODE_ulaw
keepalive retries 1
keepalive timeout 10
switchover method immediate
switchback method immediate
!

ccm-manager config server xx.xx.xx.x
ccm-manager sccp local GigabitEthernet0/0
ccm-manager sccp
!
dspfarm profile 1 transcode
codec g711alaw
codec g711ulaw
codec g722-64
maximum sessions 12
associate application SCCP
!

Our TSP sends G711a only on this SIP trunk (its an staging environment so i kan play around a lot).

But i dont see any transcoding being done:

CUBE#show dspfarm dsp active
SLOT DSP VERSION STATUS CHNL USE TYPE RSC_ID BRIDGE_ID PKTS_TXED PKTS_RXED

Total number of DSPFARM DSP channel(s) 0

CUBE#show call active voice compact
<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp> VRF
Total call-legs: 2
3772610 ANS T4 g711alaw VOIP P+4792xxxxxx 148.xxx.xxx.xxx:10344 NA
3772611 ORG T4 g711alaw VOIP P073xxxxxxx 10.xxx.xxxx.xxx:24744 NA

[Ayodeji Okanlawon]

Hi,
If the call was successful, then it is most likely that cucm software MTP was invoked. You will have to ensure that you assign all your cucm media resources are assigned to a mrg, then exclude the mrg from the mrgl assigned to your CTI devices. 

You can verify where the cube terminated the media to from the IP using the either 

Sheet VoIP rtp connection 

Show call active voice comp

[Graham Old]

CCX has supported the G711 a-law codec since 9.0(2).

You are supposed to convert all your wav files from u-law to a-law but in practice you can't hear the difference.

The only thing to be careful of is the script record step does not support a-law,  your recording just ends up with a 28 byte header and no data, see Bug id: CSCul41517

We had one customer that used the record step in one script and I did setup up CUBE transcoding to handle calls to that single number using a dial-peer to pick out the single external number.

Graham

[tony loktu]

Hi Graham

Thats good news, in partial at least.

We're using UCCX 11.5.1 so we shouldnt be affected by that bug, should we? I dont see any fixed releases though :(

We're using (i'm guessing here) 50+ applications so making dial-peers for all those would be a pain to setup and maintain.

I've tried using a seperate MRGL that has access to the transcoder (nothing else has that access to that MRGL,  and that MRGL has a only that transcoder enabled) and assigned it to the Triggers.

There are no unallocated MTPs on CUCM.

/T

[Graham Old]

Because CCX accepts both codecs the call connects a-law, when it comes to the record step CCX does not try to change codec and it fails to record.

Allocating a MTP will not work as the call will still connect a-law

The only way I could force it to work was to make the call u-law in the dial-peer then the CUBE allocated a transcoder and that call connected u-law from the start.

Prior to version 9.0(2) you would see that UCM inserted a MTP to convert from a-law to u-law. Then when the call connected to the agent the MTP would drop out and the call would connect a-law to the agent.

Adding a-law support just made a mess of things, it worked better when it only supported u-law.

If you are not using the record step you should be fine with a-law, are you using the record step in your scripts?

The record step still fails in the latest 11.6 release

Graham

[tony loktu]

Hi Graham

How do i give only one dial-peer access to transcoding?

/Tony

[Graham Old · Accepted solution]

Setup Transcoding

 dspfarm profile 1 transcode 

 codec g711ulaw

 codec g711alaw

 codec g729ar8

 codec g729abr8

 codec g729r8

 maximum sessions 8

 associate application CUBE

!

Only g711 ulaw

voice class codec 2

 codec preference 1 g711ulaw

!

dial-peer voice 200 voip

 destination-pattern <Your CCX external number>

 session protocol sipv2

 session target ipv4:<Your UCM Address>

 session transport udp

 voice-class codec 2 

 dtmf-relay rtp-nte

!

The inbound leg will offer g711 a-law and possibly g729, the outbound leg to UCM can only be g711 ulaw and the CUBE will allocate a transcoder to do the a-law to u-law conversion.

The transcoder will be in use for the duration of the call so after it connects to the agent the call will remain g711 u-law and will continue to use transcoding/dsp resource.

As I said earlier it worked better before Cisco fixed it.

Graham

[tony loktu]

Hi Graham

Pritty much the same as:

!
dspfarm profile 1 transcode
codec g711alaw
codec g711ulaw
codec g722-64
maximum sessions 12
associate application CUBE
!
voice class e164-pattern-map 100
#DNs for those applications
!
voice class codec 2
codec preference 1 g711ulaw
!
dial-peer voice 5555555 voip
voice class codec 2
voice class e164-pattern-map 100
#rest of dial-peer have been omittet

But this doesnt give exclusive right for that particular dial-peer to that transcoding resource, does it? I belive it gives anything access to that resource.

/T

[Graham Old]

That is correct it is not exclusive.

If all your other dial-peers have only g711 a-law then the CUBE will not use the transcoding on other calls.

Graham