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

[Aaron Meriwether (JIRA)]

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

Aaron Meriwether commented on ASTERISK-26221:
---------------------------------------------

Thanks for staying on top of this issue, @traud.  We have indeed been using the patch I provided to solve our immediate issues, and thus not been motivated to babysit the upstream fix.  I got the impression that you and I had a little bit of a disagreement about the most correct fix to the SDP negotiation, and I didn't have the time to work through the arguments in detail.

On the point about {{mode=30}}, I agree; after careful review of the RFC, it seems that this was never intended by the authors, but it does not seem to break anything, and it does seem to be expected by some implementations, so it makes sense to transmit it for interoperability reasons.

"why it was present in Asterisk<13": Yes, I am not aware of any specific documentation as to "why" either, so it may have simply been coincidence that the RFC was misinterpreted in the same way by the original Asterisk implementor as the implementors of other software.

On the subject of {{ptime=30}}, after further testing, it seems that it may actually be Asterisk that is encountering transcoding issues when the {{framing}} value is not a multiple of the codec packet size.  I have observed the issue when trying to connect from Zoiper, but from the packet capture, it appears to be the Asterisk side which is failing to transmit RDP packets when using iLBC-30 with {{framing = ast_format_cap_get_format_framing(p->caps, format)}}.  Zoiper does as you suggested and omits the {{ptime}} value from their side of the SDP, and that seems to be what confuses Asterisk, causing {{ast_format_cap_get_format_framing}} to return "20" even though that value will not work as a valid frame size with iLBC-30.  In my patch, I use {{ast_format_get_default_ms}} instead to inject the value of "30" into the Asterisk side of the SDP negotiation.  I assume this fixes things by causing later capabilities logic on the Asterisk side to see "30" as the negotiated frame size, rather than "20" as it seems to assume by default. This default frame size of "20" may be central to @sstream's iLBC-30 transcoding problems too.  Unfortunately, I do not understand the capabilities structure well enough to correct the {{ast_format_cap_get_format_framing}} function to handle iLBC packetization calculations correctly...

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