[asterisk-bugs] [JIRA] (ASTERISK-27959) [patch] Asterisk 15.4.1 h264 fmtp negotiation problem

[David Kuehling (JIRA)]

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

David Kuehling updated ASTERISK-27959:
--------------------------------------

    Attachment: profile-level.diff

single-line change that fixed the issue for me

> [patch] Asterisk 15.4.1 h264 fmtp negotiation problem
> -----------------------------------------------------
>
>                 Key: ASTERISK-27959
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27959
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_format_attr_h264
>    Affects Versions: 15.4.1
>         Environment: Debian Stretch amd64
>            Reporter: David Kuehling
>              Labels: patch
>         Attachments: profile-level.diff
>
>
> Hi,
> I'm trying to have a bunch of GXV3240, GXV3275 and GXV3140 telephones perform video-telephony via Asterisk.  The Asterisk 13 that's shipping with Debian did have severe problems correctly handling h264 fmtp negotiation, so I am currently investigating how much the latest upstream Asterisk release improves on that.
> Asterisk 15.4.1 is much better, now passing fmtp headers between all those video phones in the SDP.  However, I think there is one problem with how the {{profile-level-id}} attribute is handled:
> Looking at the logs, I can see that my GXV3240 phone sends a fmtp header for video:
> {noformat}
>     a=fmtp:99 profile-level-id=4D0016; packetization-mode=1
> {noformat}
> When Asterisk now relays the request to the target of the call (a GXV3140), the profile-evel-id field gets dropped:
> {noformat}
>     a=fmtp:99 packetization-mode=1
> {noformat}
> Which is a problem for some of these phones, as it makes them revert to very basic video codec parameters (the GXV3240 seem to go down to transmit QCIF when called without profile-level-id).
> Looking at the source code, it is quite obvious what happens here:
> There is a check in res_format_attr_h264.c that only outputs {{profile-level-id}}, if all its components are non-zero.  Howver, note how the GXV3240 has a zero for PROFILE_IOP (the middle byte):
> {code:java}
>     if (attr->PROFILE_IDC && attr->PROFILE_IOP && attr->LEVEL) {
> {code}
> To my untrained eye it looks like this should read
> {code:java}
>     if (attr->PROFILE_IDC || attr->PROFILE_IOP || attr->LEVEL) {
> {code}
> And patching asterisk accordingly makes it correctly pass the {{profile-level-id}}.
> Other phones (like the GVX3140) do not transmit any zeros in {{profile-level-id}}, so are not affected by the problem.
> However, note that I don't know anything about how fmtp negotiation is defined in the standard, so maybe my naive interpretation misses something here.
> cheers,
> David
> PS: will attach patch below



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