cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

7669
Views
20
Helpful
9
Replies
James Hawkins
Collaborator

Cisco CUBE Transcoding

Hi,

I have deployed CUBE on a 2921 running IOS 15.3(1)T to link a CUCM 8.6 cluster to an ITSP (Gamma Telecom in the UK).

The ITSP sends/receives calls using G711alaw. This is fine for standard voice calls to IP phones (7940 and 7960) as they support this codec.

The customer also has UCCX 8.5 and this is where the issues are happening. My understanding (correct me if I am wrong!) is that UCCX only supports G711ulaw.

When I try calling a UCCX trigger number via the SIP trunk I get a number unallocated in the CDR record. This implies to me that it is a codec issue and that I need to do some transcoding.  It looks like the new CUBE 9.0 Local Transcoding Interface (LTI) feature should solve the problem.

This is detailed in the link below but a full config is not included.

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/products_tech_note09186a0080bdfd58.shtml

I have tried configuring it but had limited success in the outage period I had available. The calls did not invoke the transcoding functionality and G711alaw was used for both legs whereas I wanted G711alaw for the external leg and G711ulaw for the internal leg. I think the issue may be to do with dial peer matching and will test this later today.

In the meantime I would like to check a few things.

What CUBE version is included with IOS 15.3(1)T on the ISR 2921? - I cannot find an up to date table that maps CUBE versions to IOS.

Has anyone else successfully configured the Local Transcoding Interface on an ISR G2 platform? - if yes can you share your config.

If LTI is not going to work has anyone had any success using the older SCCP/CME based transcoding?

Thanks in advance!

1 ACCEPTED SOLUTION

Accepted Solutions

James,

First of all unallocated number is definitely not capabilites related. Unless you are looking at the wrong CDR record. Capabilites issues such as codec mismatch always come with cause code of either 47 or 65..which is either resourve unavailable or bearer cap not supported etc..

Second, if you are running IOS 15.2.3T you can definitely use the LTI interface. Below are the steps to configure this

1. Enable dspfarm services

voice-card 0
dspfarm
dsp services dspfarm

2. dsfarm pfrofile configuration

dspfarm profile 1 transcode
codec g711ulaw
codec g711alaw
codec g729abr8
codec g729ar8
codec ilbc
maximum sessions 100
associate application CUBE

3.Bring the Service-Engine
interface up

interface Service-Engine0/1/0
no shut

Thirdly you can use local transocding available on CUBE with sccp to do this also.

Use the steps below..

1. Enable dspfarm services under voice-card

voice-card 0
dspfarm
dsp services dspfarm

2. Configure telephony service

telephony-service
sdspfarm units 1
sdspfarm transcode sessions 128
sdspfarm tag 1 CUBE-XCODE
max-ephones 10
max-dn 10
ip source-address port 2000

3.sccp configuration

sccp local GigabitEthernet0/0
sccp ccm
identifier 1 version 4.0
sccp
sccp ccm group 1
associate ccm 1 priority 1

4.dspfarm profile configuration


dspfarm profile 1 transcode
codec g711ulaw
codec g711alaw
codec g729r8
maximum sessions 10
associate application SCCP
associate profile 1 register CUBE-XCODE

Please rate all useful posts

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

Please rate all useful posts

View solution in original post

9 REPLIES 9
Karthik Sivaram
Enthusiast

If your getting  unallocated number in the cdr records the problem could also be related to call routing . Could you include

the follwoing from the cube...

-show run

-show ver

-debug ccsip messages

-debug voip ccapi inout

collect the debugs in a logging buffer and also mention your calling and called number used.

Regards,

Karthik

Hi Karthik,

Thank you for the response. I am pretty certain that the issue is not to do with call routing as I can dial DNs assigned to phones in the same partition as the UCCX trigger. The only variable seems to be the codecs supported by the device I am dialling. I will check the call routing again though - I should have permission to do some testing in about four hours and can collect debugs etc. then.

In the meantime I was hoping to get feedback about the CUBE based transcoding feature - has anyone used this yet?

Thanks

James

James,

First of all unallocated number is definitely not capabilites related. Unless you are looking at the wrong CDR record. Capabilites issues such as codec mismatch always come with cause code of either 47 or 65..which is either resourve unavailable or bearer cap not supported etc..

Second, if you are running IOS 15.2.3T you can definitely use the LTI interface. Below are the steps to configure this

1. Enable dspfarm services

voice-card 0
dspfarm
dsp services dspfarm

2. dsfarm pfrofile configuration

dspfarm profile 1 transcode
codec g711ulaw
codec g711alaw
codec g729abr8
codec g729ar8
codec ilbc
maximum sessions 100
associate application CUBE

3.Bring the Service-Engine
interface up

interface Service-Engine0/1/0
no shut

Thirdly you can use local transocding available on CUBE with sccp to do this also.

Use the steps below..

1. Enable dspfarm services under voice-card

voice-card 0
dspfarm
dsp services dspfarm

2. Configure telephony service

telephony-service
sdspfarm units 1
sdspfarm transcode sessions 128
sdspfarm tag 1 CUBE-XCODE
max-ephones 10
max-dn 10
ip source-address port 2000

3.sccp configuration

sccp local GigabitEthernet0/0
sccp ccm
identifier 1 version 4.0
sccp
sccp ccm group 1
associate ccm 1 priority 1

4.dspfarm profile configuration


dspfarm profile 1 transcode
codec g711ulaw
codec g711alaw
codec g729r8
maximum sessions 10
associate application SCCP
associate profile 1 register CUBE-XCODE

Please rate all useful posts

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

Please rate all useful posts

View solution in original post

Hi,

Thank you for the response. I appreciate it

In the document for configuring LTI that I found there is no mention of bringing the service engine up. The router does not have a Service-Engine0/1/0 but it does have an interface Embedded-Service-Engine0/0 so I guess I can try enabling that.

I will check through the CDRs in more detail too - I was just looking at the call list using the Translator-X tool.

Hopefully I should be able to update this in a couple of hours.

Why dont you just look at the sip traces in Translator x and see what the disconnect code is..You  may well have a call routing issue..You can send the trace here and we can have a look

Please rate all useful posts

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

Please rate all useful posts

Hi,

I have managed to get it working

There were two issues.

The first was the transcoding issue which I solved using the Local Transcoding Interface feature. I did not have to enter

the interface Service-Engine0/1/0 no shut command.

The second issue was call routing related. Basically the trunk could reach the DN assigned to the UCCX trigger but could not reach the DNs assigned to the CTI ports used by UCCX. I solved this by setting the Calling Search Space for Redirect on the UCCX trigger to Route Point Address Search Space.

Many thanks to both guys who responded and Jonathan Schulenberg whose response to a previous thread pointed me in the right direction to resolve the UCCX issue.

James,

Glad to hear its resolved. It may be good to mark the thread as answered to help others...

Please rate all useful posts

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

Please rate all useful posts

Hi 

 

I have situation with outbound call. I have raised a TAC case for this 

My call routing design is based on G729 end to end as its centralized SIP trunk and remote sites reach to HQ CUBE to send out and receive PSTN calls. Hence all of my region settings are G729

Almost all calls work with g729 except for few long distance calls where AT&T accepts only G711

TAC says CUBE is sending out SIP invite with g729r8 based on the codec sent by the CUCM SIP invite to CUBE. Though My CUBE has voice class codec with 

1st preference as G729

2nd preference as g711alaw

3rd preference as g711ulaw

i cant map those individual numbers with separate dial peer hard coded with g711 codec at dial peer level as those numbers may grow in future

TAC suggested to do LTI and that will take care of transcoding, before even i want to configure that. I would like to understand the voice class codec and the CUCM Invite that send g729 codec in invite. Would LTI be invoked incase CUCM sends only G729 codec as per my design? or should I redesign region relation between CUCM and CUBE?

Pasting the TAC response here

 

!!!! This is because the CUBE is doing codec filtering. When CUBE receives the G729 codec from cucm it will filter the outgoing codecs to provider as per incoming offer. This means that since cucm sends g729 , CUBE will not be able to send all offered codecs including g711 as it sees the limited bitrate coming from the CUCM. So even if voice class codec has all codecs it will still send g729. So we need CUBE application’s intelligence that if a transcoder is registered locally to it, it will be able to handle a G729-G711 call. this way CUBE will be able to send G711 in outgoing direction.

Hope this makes sense. !!!!

 

So in my case CUBE is offering only G729 and AT&T immediately sends Bearer Not capable and disconnects the call.. after configuring Transcoder will outbound call codec offer will change?

Create
Recognize Your Peers
Content for Community-Ad