| Summary: | ASTERISK-24543: Asterisk 13 responds to SIP Invite with all possible codecs configured for peer as opposed to intersection of configured codecs and offered codecs | ||||
| Reporter: | Taylor Hawkes (antiochIst) | Labels: | |||
| Date Opened: | 2014-11-20 17:59:50.000-0600 | Date Closed: | 2016-03-31 17:05:33 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_sip/CodecHandling Channels/chan_sip/General | ||
| Versions: | 13.0.0 13.6.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) Asterisk-13-SDP.pcap ( 1) chan_sip_codec_clash_revision_2.patch ( 2) chan_sip_codec_clash.patch ( 3) sip.conf | |||
| Description: | Asterisk 13.0 responds to INVITE with SDP of all possible codecs it has available.
Asterisk 12.7 responds only with the codecs sent in INVITE request and whatever it has available (i believe this is correct behavior). | ||||
| Comments: | By: Taylor Hawkes (antiochIst) 2014-11-20 18:00:46.351-0600 Here is relevant SIP. By: Taylor Hawkes (antiochIst) 2014-11-20 18:04:12.977-0600 sip.conf looks like this. [general] bindaddr = 0.0.0.0 realm=mydomain.com context = mycontext host=dynamic type=friend allow=all textsupport=yes accept_outofcall_message = yes outofcall_message_context = sms_in rtcachefriends=yes dtmfmode=rfc2833 By: Matt Jordan (mjordan) 2014-11-20 19:19:43.582-0600 Please attach your entire {{sip.conf}}. Note that while this is a bug, using {{allow=all}} is generally a bad idea. You should be defining the allowed codecs for your peers, i.e., {{allow=!all,g722,ulaw}}; etc. By: Taylor Hawkes (antiochIst) 2014-11-20 19:54:41.478-0600 here is sip.conf By: Alexander Traud (traud) 2015-10-26 11:32:17.050-0500 This bug is a bit more severe. When the remote client is using the same ID for a dynamic RTP payload type as Asterisk, however, when the types are different actually, in SIP/SDP {{m=audio}} contains the same ID twice, for different codecs. For example (bare minimum): 1) Asterisk is configured to allow just iLBC (97) and Speex (110). 2) VoIP client calls Asterisk and request iLBC but at payload ID 110. 3) Asterisk responds with m=audio 31494 RTP/SAVP 110 110 a=rtpmap:110 iLBC/8000 a=rtpmap:110 speex/8000 Furthermore, {{ast_format_cap_iscompatible}} does not work correctly. Even if a format is not compatible, it gets appended at the end. This can lead to terrible results when the first returned codec is not chosen by the caller (because Asterisk is sending an incompatible fmtp, for example). Finally, this issue is not limited to {{allow=all}} in {{sip.conf}}. Actually, in my case, it happens always: All allowed codecs are appended for an incoming call, even if the caller is not requesting = supporting them. In Asterisk 13 channels/chan_sip.c:add_sdp, the order of add_*codec_to_sdp is 1) sip_pvt->prefcaps 2) sip_pvt->jointcaps 3) sip_pvt->caps The latter is the culprit for incoming calls. In Asterisk 11, the order was 1) sip_pvt->prefcaps 2) sip_pvt->prefs, if in sip_pvt->jointcaps 3) sip_pvt->jointcaps I do not think, we have to change the behavior back to that of Asterisk 11. Actually in general, I like the new behavior better. However, the old code did differentiate between incoming and outgoing calls implicitly. In the code of Asterisk 13, we have to do this explicitly now. For this, please, see the attached patch. By: Alexander Traud (traud) 2016-03-24 14:20:42.453-0500 Long story short: I created a regression because I used the wrong variable. There is one variable and one flag to detect an outgoing call. The variable is used for the session and the flag for the dialog. I should have used the one for the session, because the state of the variable remains. When a Session Timer kicks in the state of the flag is flipped (after the codecs are added to the SDP). Therefore, on the second elapsed Session Timer, Asterisk is sending all allowed codecs instead of the requested one. Or stated differently: The issue was just moved. Some VoIP/SIP clients (for example Nokia Symbian/S60) interpret this change of the codec list as a changed session and increase the SDP counter. Because of that, Asterisk is creating a new dialog and ignoring the NAT behaviour for the RTP audio. Asterisk is sending the RTP to a local IP address rather than the remote resource. Therefore, after the second Session Timer fired, Nokia Symbian/S60 phones did not receive any RTP packets anymore. A no-audio scenario. The attached patch fixes this. If anyone is interested, I am able to provide SIP/SDP traces. However, the change/fix is so minor, let us try without any SIP/SDP traces. By: Alexander Traud (traud) 2016-03-24 14:21:15.119-0500 | ||||