[asterisk-bugs] [JIRA] (ASTERISK-25309) [patch] iLBC 20 advertised

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-25309:
------------------------------------

    Status: Open  (was: Triage)

> [patch] iLBC 20 advertised
> --------------------------
>
>                 Key: ASTERISK-25309
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25309
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CodecHandling
>    Affects Versions: SVN, 13.5.0
>            Reporter: Alexander Traud
>         Attachments: asterisk_iLBC_30.patch
>
>
> Since version 13, chan_sip advertises iLBC 20. However, only iLBC 30 is implemented in the transcoding module of Asterisk. When the callee accepts iLBC 20, this negotiates ilBC 20 (see [RFC 3952|https://tools.ietf.org/html/rfc3952#section-5] section 5) and creates a call without audio.
> The cause of this bug is a newly introduced property ({{framing}}) included in the capabilities of a channel ({{ast_format_cap}}). I do understand why this property is related to the variant of iLBC, yet. Isn’t cap->framing the ptime? The attached patch fixes this issue, only in case when {{format_cap_framed_init}} is called with framing = 0 = caller does not care. There might be other code paths which set framing to value 20.
> However, because iLBC 30 is the default variant, and reading the RFC literally - {{a=fmtp:xx mode=30}} is not defined in the RFC - the second part of this patch removes sending of a=fmtp for iLBC in SIP/SDP at all. That way, chan_sip offers iLBC 30 for sure.
> This bug was not reproducible in Asterisk 11 or earlier.



--
This message was sent by Atlassian JIRA
(v6.2#6252)