Codec G729 Bearer capability not implemented

[chandy2012]

Hello everyone,

I am having the problem interconnecting Cisco Universal Gateway AS5400 Version 12.4(11)T4 with ACME Net-Net 4250 and the disconnect code cause was 65 which mean Bearer capability not implemented. This problem happened only when using codec G729 and it was working with codec G711. I took almost a half month for troubleshooting this but could not find the fault. Can anyone have any idea what could be the problem?

Please find the trace in attachment file for both G729 and G711.

Thanks,

Chandy

[Humza Khan]

Hi, 

By default mostly service providers use g711 codec, some uses other codec like g729. I faced this issue & resolve this issue by using command bearer-cap Speech in ports.

What is your PSTN connectivity (FXO/PRI)? 

Regards,

Humza Khan

[chandy2012]

Hi Humza,

First of all thanks for your response. It seems that what you have mentioned is not fell in my scenario since we are using SIP inter-connectivity with my partner. You can see my call scenario in the attachment file.

Base on the trace file, it looks like my partner site has already replied with G729 in SDP message but I don't know why somehow my Cisco sent the CANCEL message back to them.

Best regards,

Chandy

[Dennis Mink]

just to make sure, 119.82.250.5 is your end correct!?

quickly looking at your SDP contents, both parties seem to be negotiating G729. only difference is that the 119.x.x.x end adds NSE capabilities to the SDP as well.

where does the G711 RTP stream come from that is included in the pcap?

also, the end of the call indicates it is a normal call clearing.

[chandy2012]

Hi Dennis,

Just to be clear, I had the problem only when negotiating G729 and no issue with G711. I have attached the trace for both G729 and G711 so that you can compare the different. Do you think NSE capabilities could be the problem?

[Sreekanth Narayanan]

You should also have the debugs set for the 2 scenarios to see what's different about the SIP call processing on the router in the 2 cases.

debug ccsip message

debug ccsip info

debug ccsip error

should be good. Make sure you also do the following:

Router(config)#no logging console
Router(config)#no logging monitor
Router(config)#service timestamps debug datetime msec
Router(config)#logging buffered <buffer size> debugging
Router(config)#service sequence
Router(config)#no logging rate-limit

[Ayodeji Okanlawon · Accepted solution]

Chandy,

The issue you are having is the flavor of g729 you have configured.  You have disabled g729annexb on your gateway and your provider wants to do that flavor of G729.

In the invite sent you have under the fmtp parameter nnexb=no, however we do not see the same on the 183 session progress from your ITSP. This suggests they want to do annexb..

The  resolution is to enabled  annexb in your voice class config

[chandy2012]

Hi Ayodeji,

Thanks very much for giving me the right direction of the problem. Now I got it working after enabling codec g729br8 on dial-peer. 

Best regards,

Chandy

[asafayan1]

Once gain, Deji saves the day!

Thank you Deji as we are experiencing the same thing!

Merry Christmas!

Amir

[Ayodeji Okanlawon]

Merry Christmas! Amir.

[asafayan1]

Hi Deji,

At my new job in beautiful Boulder Colorado - we have the following configuration:

CUCM <<>> CUBE <<>> CenturyLink

The cube is hard coded on both it's CUCM and CenturyLink dial peers to voice class codec 1 which itself has only g711ulaw.

When we call a particular number on the PSTN - we experience the failure you identified.  Let me ask you a simple question after having spent the last 4-5 years focused on UCS / DataCenter and now getting back into IPT:

Is it CenturyLink's SBCs responsibility to negotiate different codecs on our behalf?  In essence - our CUBE is locked down to only passing g711 traffic between our CUCM and CenturyLink.  Would that be an accurate statement? 

Best,

Amir

[Ayodeji Okanlawon]

It depends. If you are using early offer, then century has only one option which is to accept or reject the G711 codec you offer. If you are using delayed offer, then century will send you a bunch of codecs and it will be your CUBE that will negotiate g711 based on the offers received from Century

[marvinmejia]

Thanks, yes this solved a similar issue on routing a call thru SIP+E1+SIP.

[AlejoSan]

Gracias, efectivamente cambié el orden de los codecs dentro del voice-class codec, dejé g711u de primeras y la llamada se estableció.

Saludos