[asterisk-bugs] [JIRA] (ASTERISK-29285) H.264: level_idc can be downgraded

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253743#comment-253743 ] 

Asterisk Team commented on ASTERISK-29285:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].

> H.264: 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
>
> 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)