Summary:ASTERISK-07802: ulaw always the first codec in SDP, regardless of position in the peer's allowed codec list
Reporter:blanket (blanket)Labels:
Date Opened:2006-09-22 10:52:16Date Closed:2006-11-09 16:08:11.000-0600
Versions:Frequency of
Environment:Attachments:( 0) ID8014-bug_codec_ulaw-a001-2006-09-23.txt
Description:Asterisk with Realtime for SIP peers.
If I have the codec ulaw in the list of allowed codecs (position of ulaw does not matter) ulaw is always the first codec in the SIP invite -  media description when placing outbound calls.
So if the peer is supporting ulaw this codec is always used.
This does only happened with codec ulaw.


Same problem with Asterisk version 1.2.10.
I did not test without Realtime.
Comments:By: Serge Vecher (serge-v) 2006-09-22 11:03:45

Can you please provide a sip debug showing this as per the following instructions?

1) Prepare test environment (reduce the amount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterik.
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Save complete console log to file and _attach_ said file to the bug.

By: blanket (blanket) 2006-09-23 05:53:55

I have attached the requested log.

By: Jeff Pyle (jpyle) 2006-09-26 13:36:48

This does not seem to be limited to realtime.  In my sip.conf on SVN-branch-1.2-r43634:



The call goes out to the peer with the following in the SDP:

a=rtpmap:0 PCMU/8000
a=rtpmap:111 G726-32/8000

And therefore, the call gets established with ulaw:

*CLI> sip show channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)  Form  Hold     Last Message  
64.xx.yy.zz      09500615    281c27ac5f4  00103/00000  ulaw  No       Tx: ACK        

Various combinations of codecs in [general] and [peer] always seem to put ulaw first in the SDP.  I know this used to work, but I'm not sure at what point it went awry.  The same thing seems to happen on all recent versions of 1.2.

- Jeff

By: Anthony LaMantia (alamantia) 2006-10-16 16:28:47

jpyle, can you post a SIP dump as well?  I am currently developing a patch for this issue, and any more debugging information would be helpfull..

and blanket if you can describe the layout of your network a bit it would also help a ton.


By: Anthony LaMantia (alamantia) 2006-10-17 11:27:34

also, the output for the coec line in the Global Singalling Settings: section of your output fromt the "sip show settings" cli command.

By: blanket (blanket) 2006-10-20 06:39:32

Hi alamantia,
sorry for answering so late. I have been some days off.

Global Signalling Settings:
 Codecs:                 gsm,alaw

my network:
Asterisk has an LAN IP and is behind an NAT-router/Firewall (Linux)
Iam using NAT=yes, localnet and externip.
The NAT-Router is forwarding UDP/5060 and the rtp-ports to my Asterisk.

By: Jeff Pyle (jpyle) 2006-10-20 08:31:25

alamantia, I do not have a test environment to get a clean debug, as described by serge-v.  If you can help me understand exactly what pieces of information might be the most useful, I can do my best to isolate them and get a trace up, along with a network description.

By: Serge Vecher (serge-v) 2006-10-25 11:49:46

By: Anthony LaMantia (alamantia) 2006-10-30 12:36:41.000-0600


if you could provide a pure sip debug log from asterisk. it would be quite a bit of help, i am trying to reproduce this issue myself with the latest 1.2 svn right now.

just run asterisk

"asterisk -c"
and type "sip debug" from the cli and paste the output.

the advice from serge-v will be a tad simpler for you but both methods will work for  this issue.

By: Anthony LaMantia (alamantia) 2006-10-30 12:45:41.000-0600

i can't seem to reproduce this issue on svn branch 1.2-r46258 ..
is anyone still effected by this issue?

By: Anthony LaMantia (alamantia) 2006-11-06 17:08:21.000-0600

By: Anthony LaMantia (alamantia) 2006-11-09 16:07:59.000-0600

please reopen this if the issue is still effecting you.