[asterisk-bugs] [JIRA] (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

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-24543:
---------------------------------------

    Attachment: chan_sip_codec_clash.patch

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.

> Asterisk 13 responds to SIP Invite with all possible codecs configured for peer as opposed to intersection of configured codecs and offered codecs
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24543
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24543
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CodecHandling, Channels/chan_sip/General
>    Affects Versions: 13.0.0
>            Reporter: Taylor Hawkes
>         Attachments: Asterisk-13-SDP.pcap, chan_sip_codec_clash.patch, sip.conf
>
>
> 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). 



--
This message was sent by Atlassian JIRA
(v6.2#6252)