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

[David Kuehling (JIRA)]

David Kuehling created ASTERISK-27959:
-----------------------------------------

             Summary: [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


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)