Asterisk 1.8.5.0 Codec Negotiation Problem

Hello,

I have a serious codec problem.

This is my setup :

Asterisk 1.8.5.0 (on Ubuntu)
2 users behind different NATs: USER_A and USER_B

USER_A (PAP2T) supports the following codecs : G729, G711
USER_B (X-Lite) supports the following codec : G711

sip.conf config for both users
nat=yes
qualify=yes
canreinvite=no
disallow=all
allow=g729
allow=ulaw
allow=alaw

When USER_B calls USER_A, everything works fine, the codec selected being G711.

When USER_A calls USER_B, Asterisk forces the call with G729 codec => USER_B’s x-lite rings, but call cannot be answered because x-lite doesn’t recognize G729. Asterisk seems to ignore the destination user’s codec and doesn’t negotiate codec.

Calls between users supporting the same codecs are obviously working well.

I cannot set canreinvite=yes nor directrtpsetup=yes since they don’t work with NAT.

I cannot set only G711 codec for USER_B in sip.conf because it may login from another device supporting G729.

There is a patch for codec negotiation problems for the 1.4 version : b2bua.org/wiki/AsteriskCodecNegotiationPatch
But I cannot find a patch for the 1.8 version.

It seems the problem is still present since several years now, and Asterisk’s developers still didn’t solve the issue.

Any thoughts? Anyone with similar setup?

You will need the G.729 codec code and licences. Asterisk doesn’t know the downstream codec limitation when it accepts the call from user A, so it offers both. The codec actually used from User A to Asterisk is chosen by User A’s phone.

As described the patch won’t help, as you cannot have an order of codecs when there is only one allowed codecs. However, even if it did work, the Asterisk intellectual property rules mean that they could not accept a patch unless directly donated by its copyright owner.

Whilst, in theory, if you do not answer before the Dial, the limitations for B could be passed upstream, I don’t think that Asterisk actually has the mechnisms to do this. Instead, it assumes that there will be codec conversion path available.

Thank you for your reply.

I also tried the Set(SIP_CODEC=ulaw) and Set(SIP_CODEC_OUTBOUND=ulaw) just to test the function but it doesn’t seem to work at all.

Is there any workaround? Can I dynamically set the codec in the dialplan?
Any thoughts? Any similar experience?

Set those with inheritance, use __, e.g. Set(__SIP_CODEC_OUTBOUND=ulaw)

Thank you Malcom, but that didn’t work either. The call is still setup using G729.

Well you’re using a softphone that doesn’t support the G.729 codec, yet you’re configuring the peer for it. You said that you’re setting:

allow=g729

…for both peers. You shouldn’t do that. Only set the codecs actually available for the peer. Asterisk is negotiating G.729 because you’re saying it can be supported, yet the end point does not support it. The re-negotiation of codecs is slightly weak in Asterisk, so the codecs can’t be re-negotiated after the call is established. By that point it’s too late.