[asterisk-bugs] [JIRA] (ASTERISK-29268) Format Attribute Modules: Parameter Names are Case-Insensitive

[Alexander Traud (JIRA)]

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

Alexander Traud updated ASTERISK-29268:
---------------------------------------

    Description: 
[RFC 4855|https://tools.ietf.org/html/rfc4855#page-7]:
bq. parameter names are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp attribute.

Format attribute modules parse ‘a=fmtp’ of a media format like H.263+. Those format parameters are offered by the originating call (leg) caller. Then, Asterisk generates a line ‘a=fmtp’. That is presented to the outgoing call leg (callee). Currently, all modules are expecting the parameter names in lower case. Except the module for H.263+, which expects upper-case. If the caller presents its parameter differently, Asterisk ignores, and then not propagates it to the callee. This affects media quality because, without some parameters, defaults are assumed, a common low quality.

Even by looking through the Asterisk issue tracker, just for H.263+, several implementations use lower-, some mixed-cases, and not the expected upper-cases. H.263+ has a common low quality. Therefore, the video quality degrades

The attached patch fixes this for H.263+. That patch up-cases the whole format parameter, and the existing parsing succeeds. However, actually, only the parameter names, not their values, are case-insensitive. In the case of H.263+, this differentiation does not matter because all values are just digits.

  was:
[RFC 4855|https://tools.ietf.org/html/rfc4855#page-7]:
bq. parameter names are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp attribute.

Format attribute modules parse ‘a=fmtp’ of a media format like H.263+. Those format parameters are offered by the originating call (leg) caller. Then, Asterisk generates a line ‘a=fmtp’. That is presented to the outgoing call leg (callee). Currently, all modules are expecting the parameter names in lower case. Except the module for H.263+, which expects upper-case. If the caller presents its parameter differently, Asterisk ignores, and then not propagates it to the callee. This affects media quality because, without some parameters, defaults are assumed, a common low quality.

Even by looking through the Asterisk issue tracker, just for H.263+, several implementations use lower-, some mixed-cases, and not the expected upper-cases. H.263+ has a common low quality. Therefore, the video quality degrades

The attached patch fixes this for H.263+. That patch up-cases the whole format parameter, and the existing parsing succeeds. However, actually, only the parameter names, not their values, are case-insensitive. In the case of H.263+, this differentiation does not matter because all values are just digits.

*Note to a Bug Marshal*
The components list is not complete because attributes for Siren, VP8, and G.729 exist. The latter is not affected because it does not parse. Nevertheless, I do not know which component to choose to cover Siren and VP8 as well.


> Format Attribute Modules: Parameter Names are Case-Insensitive
> --------------------------------------------------------------
>
>                 Key: ASTERISK-29268
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29268
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_format_attr_celt, Resources/res_format_attr_h263, Resources/res_format_attr_h264, Resources/res_format_attr_opus, Resources/res_format_attr_silk, Resources/res_format_attr_siren14, Resources/res_format_attr_siren7, Resources/res_format_attr_vp8
>    Affects Versions: 13.38.1, 16.16.0, 18.2.0
>            Reporter: Alexander Traud
>            Severity: Major
>              Labels: patch
>         Attachments: h263_upper.patch
>
>
> [RFC 4855|https://tools.ietf.org/html/rfc4855#page-7]:
> bq. parameter names are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp attribute.
> Format attribute modules parse ‘a=fmtp’ of a media format like H.263+. Those format parameters are offered by the originating call (leg) caller. Then, Asterisk generates a line ‘a=fmtp’. That is presented to the outgoing call leg (callee). Currently, all modules are expecting the parameter names in lower case. Except the module for H.263+, which expects upper-case. If the caller presents its parameter differently, Asterisk ignores, and then not propagates it to the callee. This affects media quality because, without some parameters, defaults are assumed, a common low quality.
> Even by looking through the Asterisk issue tracker, just for H.263+, several implementations use lower-, some mixed-cases, and not the expected upper-cases. H.263+ has a common low quality. Therefore, the video quality degrades
> The attached patch fixes this for H.263+. That patch up-cases the whole format parameter, and the existing parsing succeeds. However, actually, only the parameter names, not their values, are case-insensitive. In the case of H.263+, this differentiation does not matter because all values are just digits.



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