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:16	Date Closed:	2006-11-09 16:08:11.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling
Versions:		Frequency of Occurrence
Related Issues:
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. ****** ADDITIONAL INFORMATION ****** 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. ID8014-bug_codec_ulaw-a001-2006-09-23.txt 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: [general] disallow=all allow=g726 allow=speex allow=ulaw allow=alaw allow=ilbc allow=gsm [peer] disallow=all allow=g726 allow=ulaw 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. thanks 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 jpyle, 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.