| Summary: | ASTERISK-18887: Asterisk doesn't respect the codec order - alaw always first in realtime. | ||||||
| Reporter: | Maciej Krajewski (jamicque) | Labels: | |||||
| Date Opened: | 2011-11-18 07:37:40.000-0600 | Date Closed: | 2012-01-09 08:30:03.000-0600 | ||||
| Priority: | Major | Regression? | No | ||||
| Status: | Closed/Complete | Components: | Channels/chan_sip/CodecHandling | ||||
| Versions: | Frequency of Occurrence | ||||||
| Related Issues: |
| ||||||
| Environment: | Attachments: | ( 0) asterisk_1.6.2.21.patch ( 1) codec.patch | |||||
| Description: | This is the old bug from 2008 - as a reply to that bug it was told that it won't be changed it that moment. Has anything changed? Problem still exists in 1.8.7.1 {code} 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: --------------- [proxy] type = peer host = xxxxxxxx allow = g729 ; <--- FIRST allow = alaw allow = ulaw context = from-proxy ---------------- But the INVITE generated by Asterisk has the following SDP: ------------- v=0 o=root 5394 5394 IN IP4 88.99.3.2 s=session c=IN IP4 88.99.3.2 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 - - - - a=ptime:20 a=sendrecv ------------- 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). {code} the originating call does not have to come from E1 it can be originated by SIP UA. What i have noticed that in no mater what configuration in sip.conf for peer/friend/user alaw is always the first codec in SDP (despite the order of configuration), rest of the codes are in order as configured in sip.conf. Deleting alaw from configuration causes codec to placed in proper order so the issue seems to be concerning alaw being always first in SDP no matter what. If any more information is required please let me know. | ||||||
| Comments: | By: Maciej Krajewski (jamicque) 2011-11-18 09:21:54.734-0600 after some test I've noticed that this bug only happens if You have peers/friends/users configured in real-time. When configuring them in sip.conf SDP act ok and order is kept. By: Walter Doekes (wdoekes) 2011-11-21 04:11:41.094-0600 What does the Codec Order say in 'sip show peer PEERNAME load'? By: Maciej Krajewski (jamicque) 2011-11-21 04:25:24.408-0600 Codecs : 0x108 (alaw|g729) Codec Order : (g729:20,alaw:20) By: Maciej Krajewski (jamicque) 2011-11-28 04:49:21.363-0600 psql -c "SELECT allow,disallow from sip_ps where type='peer'" allow | disallow -----------+---------- g729;alaw | all (1 row) Codecs : 0x108 (alaw|g729) Codec Order : (g729:20,alaw:20) By: Maciej Krajewski (jamicque) 2011-12-05 18:31:21.594-0600 and here is the INVITE Packet send by asterisk .... c=IN IP4 10.0.4.63 t=0 0 m=audio 17446 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv By: Maciej Krajewski (jamicque) 2011-12-06 15:36:25.717-0600 I've done a little research, and found out that this istuation only happens if the first leg of the call is negotiated with alaw By: Maciej Krajewski (jamicque) 2011-12-12 17:35:14.426-0600 this patch seams to fix the problem patch for asterisk 1.6.21 By: Maciej Krajewski (jamicque) 2011-12-13 16:47:23.631-0600 it seems that it is a desired funcionality to use codec negotiated in first leg in outbound call if possible. I've attached patch against 1.6.2.21 to use codecs stated only in config file with desired priority. By: Matt Jordan (mjordan) 2012-01-04 14:49:26.870-0600 I haven't been able to reproduce this behavior in the current 1.8 branch, using two SIP Polycom SoundPoint IPs, configured using SIP realtime with codecs g729;alaw. When Phone A contacts Asterisk, the initial invite contains the following media information in the SDP: a=sendrecv m=audio 2234 RTP/AVP 0 8 18 127 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:127 telephone-event/8000 When Asterisk replies back with the 200 OK, the SDP contains the proper codec ordering as determined by the SIP realtime configuration: m=audio 9540 RTP/AVP 18 8 127 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:8 PCMA/8000 a=rtpmap:127 telephone-event/8000 a=fmtp:127 0-16 a=ptime:20 a=sendrecv Finally, when Asterisk sends the INVITE to Phone B, we send the correct SDP: m=audio 20828 RTP/AVP 18 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv As it is, I don't believe this is currently a problem in 1.8. You may want to try and test to see if this is still an issue in 1.8.9.0-rc1. By: Maciej Krajewski (jamicque) 2012-01-04 18:37:57.936-0600 I've checked it in newest 1.8 branch and it still occurs. It happens only if the first leg of the call is negotiated with ALAW, as I've written in comment from 6/12 By: David Vossel (dvossel) 2012-01-05 11:50:16.848-0600 I would not consider this a bug. What is being encountered here is expected behavior. In chan_sip, the audio format used when requesting a channel will take precedence over all other media formats in the SDP as long as the format is supported by the peer. This is done to avoid translation. If we know the channel requesting the new outgoing sip channel supports uLaw, then we know that the best possible scenario for Asterisk would be for that new channel to support uLaw as well. In order to achieve this, ulaw is placed at the at the beginning of the SDP offer in the INVITE. This has been the behavior of Asterisk for quite some time, and people have built logic that depends on this. Changing this behavior to default to anything else will cause problems. That is not to say I don't understand why someone would want the format preference order completely honored in the SDP of outbound calls regardless of the requester channel's media format. This should be considered a new feature, and options will have to be created to support this feature. ---- Comment from chan_sip explaining this behavior --- /* Now, start adding audio codecs. These are added in this order: - First what was requested by the calling channel - Then preferences in order from sip.conf device config for this peer/user - Then other codecs in capabilities, including video */ By: David Vossel (dvossel) 2012-01-05 11:56:15.498-0600 Also, just to avoid confusion. This issue has nothing to do with realtime peers. The behavior is going to be the same for all peers. By: Maciej Krajewski (jamicque) 2012-01-07 16:09:23.519-0600 I confirm what David has written. This is the exact behaviour of Asterisk when the first leg of the call is negotiated in g711a/u. I leave it to moderators to either close the ticket or leave it for consideration of new feature. By: Matt Jordan (mjordan) 2012-01-09 08:30:03.045-0600 This probably isn't behavior that we will change in the near future. If someone from the open source community would like to see the behavior changed, they would need to write a patch for it, and submit it as an improvement. In that case, we can open a new issue and link it to this one. As this issue was being approached as a bug, I'm going to close this out. | ||||||