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

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

{quote} {{mode=30}} seem to be expected by some implementations, so it makes sense to transmit it for interoperability reasons.{quote}

Fully agreed. Another question, hopefully the last: What about my iLBC 20 patch which is available via ASTERISK-26218 (actually via [my GitHub|https://github.com/traud/asterisk-ilbc]). Would that solve your issue as well? Then, I would look into alternative A to solve this here. Otherwise, I go for alternative B because alternative C conflicts with alternative A (I would have to add a reverse patch to my GitHub) and I do not think I get it passed the review process because the issue would not be solved for chan_pjsip, just chan_sip.{quote} Asterisk encounters transcoding issues when the framing value is not a multiple of the codec packet size.{quote}I would like to split this issue into a new report. Could you do me a favor and create concise steps to reproduce your issue? Which SIP client (Zoiper), SIP server (Asterisk chan_sip), which versions, which operating system, and which translation paths you get/use. The latter can be double-checked from the CLI. I look-up the exact command, if you need.

I have done a lot of stuff in that area and all my framing issues were solved with Asterisk 13.6 (ASTERISK-25353). Obviously, you found another issue. To track that down, steps to reproduce, the actual results you see, the expected results – Apple explained such an bug-reporting approach [formerly…|http://web.archive.org/web/20160324163652/https://developer.apple.com/bug-reporting/using-bug-reporter/problem-detail/]

That would help to reproduce your issue. Then, I can look into that as well. Perhaps, I find the reason and even a solution. Or went _all_ your issues away already with the patch you proposed here in that report? Anyway, please, create a full blown bug report.

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