[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=231535#comment-231535 ] 

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

{quote}if client advertises 20ms and Asterisk advertises nothing, some clients might expect Asterisk to transmit 30ms and others might expect 20ms{quote}You repeated yourself without going through my rationale. Consequently, I do not know whether you have not seen or not understand (parts of) the rationale: When one party has no {{mode}} in SDP, both parties have to fall back to iLBC 30. Consequently yet, I cannot give a better explanation because I do not know which part created the misunderstanding.{quote}Zoiper{quote}I tested that client but did not double-check that scenario via Wireshark correctly. As you stated, when Asterisk does not answer with a mode, Zoiper falls back to iLBC 20. Tested with Zoiper Premium 1.13.2 for iPhone. This breaks compatibility with legacy iLBC-30-only implementations which do not send/know about the mode parameter. Therefore, I am going to report this to the Zoiper team.{quote}your patch alone may not solve our issue in all cases{quote}I updated the patch and Asterisk sends the mode in any case now, because I see no harm in doing so. With that, Zoiper passed all my tests. Thanks for reporting. When you find an outstanding case/scenario, please update this issue report.

[~asteriskteam], my change is just for Asterisk 14 and newer. This report here affects Asterisk 13 as well:
A) shall I adopt my change for Asterisk 13, or
B) shall Aaron submit his patch for inclusion, or
C) is this report resolved as ‘Not A Bug’?

> 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: Unassigned
>            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)