Summary:ASTERISK-12651: Asterisk doesn't respect the codec order
Reporter:Iñaki Baz Castillo (ibc)Labels:
Date Opened:2008-08-27 10:24:43Date Closed:2011-06-07 14:02:51
Versions:Frequency of
is the original version of this clone:ASTERISK-18887 Asterisk doesn't respect the codec order - alaw always first in realtime.
Description:I receive calls from a E1 in Europe (so audio is encoded in PCMA). Then Asterisk does a Dial to a SIP proxy defined as:

type = peer
host = xxxxxxxx
allow = g729   ; <--- FIRST
allow = alaw
allow = ulaw
context = from-proxy

But the INVITE generated by Asterisk has the following SDP:
o=root 5394 5394 IN IP4
c=IN IP4
t=0 0
m=audio 14868 RTP/AVP 8 18 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

As you can see, the preferred codec is PCMA instead of G729.
I've also tryed adding in the dialplan:
 exten => _XXXXX.,n,Set(__SIP_CODEC=g729)
but it does nothing.

Well, I can understand that in order to avoid transcoding Asterisk chooses PCMA (since it's the same codification as the audio coming from the E1), but it should be possible to respect the codec order set in the peer configuration.

Of course this is very important for a SIP provider.

So I wonder why there is not a way to get it, and also why this is the default behaviour (non respecting the codec order set in sip.conf).
Comments:By: Iñaki Baz Castillo (ibc) 2008-08-27 10:36:48

It's true that I forgot adding "disallow=all" into the peer, but doing it the only difference is that Asterisk doesn't offer GSM, but the order remains:

m=audio 15196 RTP/AVP 8 18 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000

PCMA is the preferred offered codec still.

By: Leif Madsen (lmadsen) 2008-08-27 10:44:40

At this time all codec negotiation issues are being closed as we are aware there are issues in the codec negotiation algorithm. Please see Qwell's final comment in bug 4825 for a slightly more thorough explaination.