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

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

My patch does completely solve our issue in Asterisk 13, where iLBC-30 is the only mode available, and where chan_sip is being used.  However because this is a patch to chan_sip in particular, if similar issues exist in IAX2 or pjsip, they will not be solved by my patch.

I've tried your iLBC-20 patch by itself, but it doesn't add the "mode" value to chan_sip.  I also tried your patch plus adding "mode" to chan_sip, and that still doesn't work right because the ptime value causes Zoiper to use iLBC-20 even if Zoiper is configured to only offer iLBC-30.  Your patch also does not seem to work right in conjunction with chan_sip even when Zoiper offers iLBC-20 - the SDP negotiation on the wire looks correct in that case (each side offers iLBC-20), but Asterisk still transmits iLBC-30 and complains about receiving iLBC-20 frames (the "Huh?" message).
{noformat}
asterisk: WARNING[3706][C-00000004]: codec_ilbc.c:127 in ilbctolin_framein: Huh?  An ilbc frame that isn't a multiple of 50 bytes long from RTP (38)?
{noformat}

So it seems that your iLBC-20 patch does not really operate correctly with chan_sip at all.

Here, specifically, are the tests which fail:

Common setup for all the tests:
Zoiper v3.9.32144, connecting to Asterisk 13 using chan_sip, and bridging to a G.711 PCMU 20ms back end.

Zoiper with iLBC-30 enabled, Asterisk with the traud/asterisk-ilbc patch applied:
- Zoiper offers iLBC with mode=30 and no ptime
- Asterisk offers iLBC with no mode and ptime=20
- Zoiper begins transmitting iLBC-20 frames
- Asterisk begins transmitting iLBC-30 frames
- Asterisk warns about frame size:
{noformat}
asterisk: WARNING[3706][C-00000004]: codec_ilbc.c:127 in ilbctolin_framein: Huh?  An ilbc frame that isn't a multiple of 50 bytes long from RTP (38)?
{noformat}

Zoiper with iLBC-20 enabled, Asterisk with the traud/asterisk-ilbc patch applied:
- Zoiper offers iLBC with mode=20 and no ptime
- Asterisk offers iLBC with no mode and ptime=20
- Zoiper begins transmitting iLBC-20 frames
- Asterisk begins transmitting iLBC-30 frames
- Asterisk warns about frame size ("Huh?")

Zoiper with iLBC-30 enabled, Asterisk with the traud/asterisk-ilbc patch, and the "mode" line added to chan_sip:
- Zoiper offers iLBC with mode=30 and no ptime
- Asterisk offers iLBC with mode=20 and ptime=20
- Zoiper begins transmitting iLBC-20 frames
- Asterisk begins transmitting iLBC-30 frames
- Asterisk warns about frame size ("Huh?")

Zoiper with iLBC-20 enabled, Asterisk with the traud/asterisk-ilbc patch, and the "mode" line added to chan_sip:
- Zoiper offers iLBC with mode=20 and no ptime
- Asterisk offers iLBC with mode=20 and ptime=20
- Zoiper begins transmitting iLBC-20 frames
- Asterisk begins transmitting iLBC-30 frames
- Asterisk warns about frame size ("Huh?")

Zoiper with iLBC-30 enabled, Asterisk with the traud/asterisk-ilbc patch, and my full chan_sip patch:
- Zoiper offers iLBC with mode=30 and no ptime
- Asterisk offers iLBC with mode=20 and ptime=20
- Zoiper begins transmitting iLBC-20 frames
- Asterisk begins transmitting iLBC-30 frames
- Asterisk warns about frame size ("Huh?")

Zoiper with iLBC-30 enabled, Asterisk with the traud/asterisk-ilbc patch, and my full chan_sip patch:
- Zoiper offers iLBC with mode=20 and no ptime
- Asterisk offers iLBC with mode=20 and ptime=20
- Zoiper begins transmitting iLBC-20 frames
- Asterisk begins transmitting iLBC-30 frames
- Asterisk warns about frame size ("Huh?")

And the tests that succeed:

Zoiper with iLBC-30 enabled, Asterisk with my full chan_sip patch:
- Zoiper offers iLBC with mode=30 and no ptime
- Asterisk offers iLBC with mode=30 and ptime=30
- Zoiper begins transmitting iLBC-30 frames
- Asterisk begins transmitting iLBC-30 frames
- Everything works

Zoiper with iLBC-20 enabled, Asterisk with my full chan_sip patch:
- Zoiper offers iLBC with mode=20 and no ptime
- Asterisk offers iLBC with mode=30 and ptime=30
- Zoiper begins transmitting iLBC-30 frames
- Asterisk begins transmitting iLBC-30 frames
- Everything works


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