[asterisk-bugs] [JIRA] (ASTERISK-29267) H.263+ Format Attribute Module: not RFC 4629

[George Joseph (JIRA)]

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

George Joseph updated ASTERISK-29267:
-------------------------------------

    Status: Open  (was: Triage)

> H.263+ Format Attribute Module: not RFC 4629
> --------------------------------------------
>
>                 Key: ASTERISK-29267
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29267
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_format_attr_h263
>    Affects Versions: 13.38.1, 16.16.0, 18.2.0
>            Reporter: Alexander Traud
>            Severity: Minor
>              Labels: patch
>         Attachments: h263_upper.patch
>
>
> Asterisk 11 introduced a format attribute module for H.263+. The idea is to pass the format parameters (line “fmtp” in SDP) from the originating call leg (caller) to the called leg (callee). The module is based on [RFC 4629|https://tools.ietf.org/html/rfc4629#section-8.1.1]. It parses all mentioned parameters and then generates one line “fmtp” again.
> However, there are bugs and limitations:
> # CPCF is simply missing
>    OK, nobody (?) is using that; forget about it.
> # CIFs are printed with MPI=0 when not specified
>    That is a violation because MPI can be 1 to 32 only.
> # K and N are printed with =0 when not specified
>    That is a violation because 0 is not a defined value.
> # BPP is printed with =0 when not specified
>    although 0 seems to have a meaning.
> # MaxBR is simply missing
>    OK, not specified RFC 4629, but some implementations use it.
> 2-5 can be solved by applying the same unset/nonzero approach as in the format attribute module for H.264. See the attached patch.
> However, however, RFC 4629 states: “Parameters offered first are the most preferred picture mode to be received.” This can be worked-around for the normal CIFs if one assumes that larger is better. In that case, the order of the CIFs in {{generate_sdp_fmtp(.)}} is simply reversed. See the attached patch.
> However, however, however, RFC 4629 includes that CPCF and allows CUSTOM. Those can be better or worse than other picture modes. This cannot be incorporated that easily.
> *Long story short*
> Saving the whole fmtp as one line, coping that over, rather than parsing and generating all parameters; wouldn’t that make much more sense?



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