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

Alexander Traud (JIRA) noreply at issues.asterisk.org
Thu Jan 28 10:07:59 CST 2021


Alexander Traud created ASTERISK-29268:
------------------------------------------

             Summary: 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
    Affects Versions: 18.2.0, 16.16.0, 13.38.1
            Reporter: Alexander Traud


[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.



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



More information about the asterisk-bugs mailing list