[asterisk-bugs] [JIRA] (ASTERISK-29285) res_format_attr_h264: level_idc can be downgraded

[Joshua C. Colp (JIRA)]

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

Joshua C. Colp updated ASTERISK-29285:
--------------------------------------

    Summary: res_format_attr_h264: level_idc can be downgraded  (was: H.264: level_idc can be downgraded)

> res_format_attr_h264: level_idc can be downgraded
> -------------------------------------------------
>
>                 Key: ASTERISK-29285
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29285
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_format_attr_h264
>    Affects Versions: 13.38.1, 16.16.0, 18.2.0
>            Reporter: Alexander Traud
>            Severity: Major
>              Labels: patch
>         Attachments: h264_min_joint.patch
>
>
> Since the year 2003, the media format H.264 exists. It includes [levels|https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels], which describe the complexity of the resulting video. A certain level means that all lower levels are supported. Consequently, when the SDP Offer/Answer model was finalized in the year 2004 with [RFC 3984|https://tools.ietf.org/html/rfc3984#section-8.2.2] and clarified with [RFC 6184|https://tools.ietf.org/html/rfc6184#section-8.2.2]
> * the offerer, in SIP the caller, presents its highest level
> * the answerer, in SIP the callee, [downgrades|https://mailarchive.ietf.org/arch/msg/avt/o-q0iDkaZXZRg1IQUeD67pd4kAo/] to its highest level.
> Without that, the caller might send too complex data.
> *Steps to Reproduce*
> are based on the Call example from [RFC 3665 section 3.1|https://tools.ietf.org/html/rfc3665#section-3.1] with three additional constraints: Alice, (1) with her Cisco IP Phone 8845 or 8865 with Multiplatform Firmware (Cisco MPP, former Sipura), calls Bob with his (2) Poly VVX 501 or VVX 601 with an EagleEye Mini attached (Polycom UC). Asterisk is configured (3) with {code}directmedia=false
> videosupport=yes
> disallow=all
> allow=ulaw,h264{code}in the configuration file {{sip.conf}}.
> *Expected Result*
> The call is established with audio and video on both sides.
> *Actual Results*
> The call is established. The Cisco MPP plays audio and video. The Poly UC plays just audio, no video.
> *Note*
> When the call is established the other way around, Bob calls Alice, both parties enjoy audio+video.
> *Cause*
> In SDP, the Cisco MPP offers{code}
> b=AS:4064
> [...]
> m=video [...] RTP/AVP 110
> b=TIAS:4000000
> a=rtpmap:110 H264/90000
> a=fmtp:110 profile-level-id=428016;packetization-mode=0;max-fs=3600;max-mbps=108000
> a=imageattr:* recv [x=800,y=480,q=0.60] [x=1280,y=720,q=0.50]{code}
> and the Poly UC answers{code}
> b=AS:2048
> [...]
> m=video [...] RTP/AVP 109
> a=rtpmap:109 H264/90000
> a=fmtp:109 profile-level-id=42800d{code}
> level_idc got downgraded from Level 2.2 (0x16) to Level 1.3 (0x0d). However, Asterisk does not forward that answer to the original caller but just mirrors its level_idc. In other words, Asterisk sends the Cisco MPP in the final OK still 0x16 instead of 0x0d.
> *Fix*
> For a long time, Asterisk had the architectural design-flaw that there was no way to negotiate SDP attribute changes from the callee to the caller. However, with the re-architecture of the format handling and two additional fixes, it got possible to communicate such a thing since Asterisk 13.7 (see ASTERISK-29183 for more details). The attached patch leverages that.
> Because I am not sure whether I manage to include that patch in the current Asterisk, some notes to those who consider incorporating it in their Asterisk anyway: The patch follows the approach of my audio format [module for AMR|https://github.com/traud?tab=repositories&q=asterisk-]. That module is known to be used in large scale environments.



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