[asterisk-bugs] [JIRA] (ASTERISK-26221) chan_sip: iLBC does not include correct mode

[Alexander Traud (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231524#comment-231524 ] 

Alexander Traud commented on ASTERISK-26221:
--------------------------------------------

{quote}If one side offers mode=20 and the other makes no framing offer, behavior is undefined.{quote}Mhm. I still understand it the way I did it. Rationale: iLBC 20 was introduced later than iLBC 30. If the answerer (in our case: Asterisk) does not support parameters at all, it cannot answer with a parameter {{mode}} because it does not know about this _new_ feature. Requiring a mode would break backwards compatibility. Furthermore, the chapter ‘Mapping to SDP parameters’ does not state 30 as a possible value for mode, just 20 and 0. No mode as parameter in SDP means iLBC 30. Although {{"mode=30"}} is written in the RFC, this is meant semantically not syntactically. Otherwise the previous statement – just 20 and 0 – does not make sense. Consequently, you have found a bug in one of your VoIP/SIP clients. Please, report this to their authors!

Anyway, you raised an interoperability issue and I am curious which clients face this issue in particular. Especially, because the current reviewed change is just about the master branch (Asterisk 14 and newer) not about Asterisk 13, yet. I tested with a lot of iLBC clients – with iLBC 20 and without – and found no interoperability issue. Therefore, please, mention in detail which clients are faced by this issue. I would love to see iLBC 20 support in Asterisk 13 as well.

If iLBC 20 does not come for Asterisk 13, the Asterisk team has to go for your proposal because I see no harm in including {{mode=30}} always. I removed that parameter because of the RFC and because it was in conflict with my iLBC 20 patch (which sets this value in a format-attribute module rather than chan_sip).

> chan_sip: iLBC does not include correct mode
> --------------------------------------------
>
>                 Key: ASTERISK-26221
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26221
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CodecHandling
>    Affects Versions: 13.9.1
>            Reporter: Aaron Meriwether
>            Assignee: Aaron Meriwether
>            Severity: Minor
>         Attachments: asterisk-13-ilbc-sdp.patch
>
>
> As of Asterisk-13, the format/channel handling was overhauled.  Bug ASTERISK-25309 was introduced as a result and eventually closed, but the fix for that bug was not complete.
> The old (pre-Asterisk-13) behavior was that whenever iLBC would be listed in an SDP message, it would be qualified with "mode=30" because Asterisk supports only the 30ms framing of iLBC.  As of Asterisk-13, the new format/channel handling overhaul caused Asterisk to offer "mode=20" in some cases, resulting in some connections negotiating an unsupported framing.  ASTERISK-25309 addressed this by removing the mode value entirely, which resolved the issue for some SIP clients, but because the mode is omitted entirely from the Asterisk side, if the client offers mode=20 and Asterisk does not override that offer with a mode=30 offer, some clients take that as an invitation to begin transmitting iLBC-20 data.
> ASTERISK-25309 cites RFC 3952 section 5 as justification for removing the "mode=" offer, however if that specification is read carefully, it can be seen that it only defines the "always use iLBC-30" behavior when at least one side offers mode=30.  If one side offers mode=20 and the other makes no framing offer, behavior is undefined.
> The attached patch causes iLBC negotiation to return to its pre-Asterisk-13 behavior of always offering mode=30 regardless of the other side's offer.  It does this by reinstating the "mode=" output, and taking the "framing" value from "ast_format_get_default_ms" rather than "ast_format_cap_get_format_framing".  This also causes "ptime" to be output correctly, and does not preclude using a patched iLBC-20 format module (as hard-coding the value in chan_sip.c would have).



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