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

Fri Jul 22 14:56:56 CDT 2016

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

Aaron Meriwether edited comment on ASTERISK-26221 at 7/22/16 2:54 PM:
----------------------------------------------------------------------

[~traud], RFC-3952 is very unclear on some points, which is why I referred to certain scenarios as "undefined".  Specifically, although the RFC in one place seems to imply that "20" is the only valid mode (or "0" which is "reserved") for transmission in an SDP packet, it later goes on to describe negotiation logic involving `an offer of "mode=20" receiving an answer of "mode=30"`, which seems to contradict the earlier assertion.  If that later part is taken to mean that absence of a "mode=" parameter is used to represent the implied "mode=30" constraint (as I believe you are interpreting it), then yes, your removal of the "mode=" parameter from Asterisk-13 could be considered to be according to the RFC.  However, it seems that others may have interpreted the RFC to mean that the literal "mode=30" string is a valid (and even required) value during negotiation, which is why it was present in Asterisk<13 (and why Zoiper uses a literal "mode=30" value too, so this interpretation is not without precedent).

The other (perhaps primary?) issue is the "ptime" value, which is also derived from the "framing" variable in Asterisk.  With "framing" now calculated via "ast_format_cap_get_format_framing", unpatched Asterisk-13.9 may generate an SDP with no "mode=" and a "ptime" of "20" (copied from the other G711 leg of the call I assume), which is completely nonsensical.  Below, find an actual SDP negotiation from Zoiper calling in to unpatched Asterisk 13.9.1, (which bridges onward to a G711 channel):

Zipper --> Asterisk
{noformat}
v=0
o=Z 0 0 IN IP4 xxx.x.xxx.xxx
s=Z
c=IN IP4 xxx.x.xxx.xxx
t=0 0
m=audio 8000 RTP/AVP 98
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=30
a=sendrecv
{noformat}

Asterisk-->Zoiper
{noformat}
v=0
o=xxxxxxx 226373662 226373662 IN IP4 xx.xxx.xx.xx
s=Asterisk PBX
c=IN IP4 xx.xxx.xxx.xx
t=0 0
m=audio 21772 RTP/AVP 98
a=rtpmap:98 iLBC/8000
a=silenceSupp:off - - - -
a=ptime:20
a=maxptime:300
a=sendrecv
{noformat}

My patch addresses both the (perhaps non-RFC-intended but certainly widely used) lacking "mode=30" as well as the (definitely incorrect) "ptime" value.  Although it seems "mode=30" may not actually be required in some interpretations of the RFC, it caused no issues before Asterisk-13, so reverting behavior to the complete known-working pre-Asterisk-13 format seems like a good idea, especially in such a way as to make room as my patch does for the future iLBC-20 support that [~traud] is pushing for Asterisk-14.

[~jcolp], here is the history of the code in question:
* Originally, chan_sip.c always transmitted ("mode=%d", fmt.cur_ms), and things worked fine.
* When [~mjordan] merged the Media Format Rewrite, this changed to ("mode=%d", framing), where framing comes from ast_format_cap_get_format_framing, causing Asterisk to advertise iLBC with "mode=20" in some cases (e.g. transcoding to G711).  Some other transcoding-between-mismatched-frame-sizes issues also appeared with this rewrite, which [~traud] has since resolved.
* When [~traud] removed the "mode=" parameter as of "Change-Id: I92d724600a183eec3114da0ac607b994b1a793da", it may have fixed the issue in some cases (because Asterisk no longer advertises "mode=20"), but it not for our Zoiper use-case.

Now that I have examined the history more closely, I suspect that the iLBC "ptime" issue may have been present since the Media Format Rewrite, which is why [~traud]'s removal of the "mode=" parameter was insufficient to get SDP negotiation working again for us.

was (Author: ameriwether):
[~traud], RFC-3952 is very unclear on some points, which is why I referred certain scenarios as "undefined".  Specifically, although the RFC in one place seems to imply that "20" is the only valid mode (or "0" which is "reserved") for transmission in an SDP packet, it later goes on to describe negotiation logic involving `an offer of "mode=20" receiving an answer of "mode=30"`, which seems to contradict the earlier assertion.  If that later part is taken to mean that absence of a "mode=" parameter is used to represent the implied "mode=30" constraint (as I believe you are interpreting it), then yes, your removal of the "mode=" parameter from Asterisk-13 could be considered to be according to the RFC.  However, it seems that others may have interpreted the RFC to mean that the literal "mode=30" string is a valid (and even required) value during negotiation, which is why it was present in Asterisk<13 (and why Zoiper uses a literal "mode=30" value too, so this interpretation is not without precedent).

The other (perhaps primary?) issue is the "ptime" value, which is also derived from the "framing" variable in Asterisk.  With "framing" now calculated via "ast_format_cap_get_format_framing", unpatched Asterisk-13.9 may generate an SDP with no "mode=" and a "ptime" of "20" (copied from the other G711 leg of the call I assume), which is completely nonsensical.  Below, find an actual SDP negotiation from Zoiper calling in to unpatched Asterisk 13.9.1, (which bridges onward to a G711 channel):

Zipper --> Asterisk
{noformat}
v=0
o=Z 0 0 IN IP4 xxx.x.xxx.xxx
s=Z
c=IN IP4 xxx.x.xxx.xxx
t=0 0
m=audio 8000 RTP/AVP 98
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=30
a=sendrecv
{noformat}

Asterisk-->Zoiper
{noformat}
v=0
o=xxxxxxx 226373662 226373662 IN IP4 xx.xxx.xx.xx
s=Asterisk PBX
c=IN IP4 xx.xxx.xxx.xx
t=0 0
m=audio 21772 RTP/AVP 98
a=rtpmap:98 iLBC/8000
a=silenceSupp:off - - - -
a=ptime:20
a=maxptime:300
a=sendrecv
{noformat}

My patch addresses both the (perhaps non-RFC-intended but certainly widely used) lacking "mode=30" as well as the (definitely incorrect) "ptime" value.  Although it seems "mode=30" may not actually be required in some interpretations of the RFC, it caused no issues before Asterisk-13, so reverting behavior to the complete known-working pre-Asterisk-13 format seems like a good idea, especially in such a way as to make room as my patch does for the future iLBC-20 support that [~traud] is pushing for Asterisk-14.

[~jcolp], here is the history of the code in question:
* Originally, chan_sip.c always transmitted ("mode=%d", fmt.cur_ms), and things worked fine.
* When [~mjordan] merged the Media Format Rewrite, this changed to ("mode=%d", framing), where framing comes from ast_format_cap_get_format_framing, causing Asterisk to advertise iLBC with "mode=20" in some cases (e.g. transcoding to G711).  Some other transcoding-between-mismatched-frame-sizes issues also appeared with this rewrite, which [~traud] has since resolved.
* When [~traud] removed the "mode=" parameter as of "Change-Id: I92d724600a183eec3114da0ac607b994b1a793da", it may have fixed the issue in some cases (because Asterisk no longer advertises "mode=20"), but it not for our Zoiper use-case.

Now that I have examined the history more closely, I suspect that the iLBC "ptime" issue may have been present since the Media Format Rewrite, which is why [~traud]'s removal of the "mode=" parameter was insufficient to get SDP negotiation working again for us.

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