|Summary:||ASTERISK-07802: ulaw always the first codec in SDP, regardless of position in the peer's allowed codec list|
|Date Opened:||2006-09-22 10:52:16||Date Closed:||2006-11-09 16:08:11.000-0600|
|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
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:
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.
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
sorry for answering so late. I have been some days off.
Global Signalling Settings:
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
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.