Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 12 Feb 2010 17:10:14 -0500

Done as suggested by Stuart.
 
BR, YK

  _____  

From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 12:05 PM
To: 'Stuart Taylor (sttaylor)'; [email-masked]'
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

OK, we will add something like this, once we get the chance to edit the
draft before the RFC is published.
 
BR, YK

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stuart
Taylor (sttaylor)
Sent: Tuesday, December 01, 2009 5:57 PM
To: Roni Even; Mo Zanaty (mzanaty); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

It's clear if you go into with the right understanding of level asymmetry.
Since we have a whole group here at Cisco who were confused, I suggest we
need some more clarity.

The confusion stems from the clause, ". level asymmetry, i.e., using a
different level in the offerer-to-answerer direction than the level in the
answerer-to-offerer direction, is allowed."  The problem is establishing the
context: is this referring to the negotiation or sending media?  I suggest
the following change in section 8.1:

level-asymmetry-allowed:

This parameter MAY be used in a SDP offer/answer to indicate whether level
asymmetry, i.e., sending media encoded at a different level in the
offerer-to-answerer direction than the level in the answerer-to-offerer
direction, is allowed.  The value MAY be equal to 0 or 1.  [.]

Stuart

From: Roni Even [mailto:[email-masked]] 
Sent: Monday, November 30, 2009 6:40 PM
To: Mo Zanaty (mzanaty); Stuart Taylor (sttaylor); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

Hi,

I think that it is clear since it addresses asymmetry and not the downgrade
of the level.

Asymmetry means not the same level in both directions.

Roni

From: Mo Zanaty (mzanaty) [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 12:51 AM
To: Stuart Taylor (sttaylor); Roni Even; [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

This inconsistency in the original RFC 3984 was pointed out several times
before on this list, and was one of the key things to clarify in 3984 bis. I
think the current draft is clear in this regard, except for the description
of level-asymmetry-allowed, which might be clearer if it explicitly
mentioned that level downgrade is always allowed regardless of this
parameter.

Mo Zanaty

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stuart
Taylor (sttaylor)
Sent: Monday, November 30, 2009 4:56 PM
To: Roni Even; [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

Current usage is justified by the following paragraph, later in section
8.2.2 of RFC-3984, which admittedly can be interpreted multiple ways:

.         Parameters declaring a configuration point are not downgradable,

      with the exception of the level part of the "profile-level-id"

      parameter.  This expresses values a receiver expects to be used

      and must be used verbatim on the sender side.

Stuart Taylor

From: Roni Even [mailto:[email-masked]] 
Sent: Monday, November 30, 2009 4:50 PM
To: Stuart Taylor (sttaylor); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]; [email-masked]
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

Hi,

Just to remind all of you that the current text in RFC3984 mandated level
symmetry - downgrading was not allowed - see section 8.2.2 of RFC3984

" The parameters identifying a media format configuration for H.264

      are "profile-level-id", "packetization-mode", and, if required by

      "packetization-mode", "sprop-deint-buf-req".  These three

      parameters MUST be used symmetrically; i.e., the answerer MUST

      either maintain all configuration parameters or remove the media

      format (payload type) completely, if one or more of the parameter

      values are not supported."

This means that every shipping product that does level downgrade is not
compliant, and therefore cannot claim that the current text break backward
computability.

The 3984bis draft is addressing the issue and the current text and products
should align to it.  If the text is not clear enough than it should be fixed
but the backward computability should address the issue that some
implementations did support the standard and supported only symmetry as
discussed in  RFC3984

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stuart
Taylor (sttaylor)
Sent: Monday, November 30, 2009 10:19 PM
To: [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]; [email-masked]
Subject: [AVT] Comment on 3984bis: level-asymmetry-required

I am commenting on H.264 level asymmetry in general and the
level-asymmetry-allowed attribute, introduced in draft 8 of RFC-3984bis, in
particular.  The current draft contains  confusing language and is likely to
break compatibility with many existing devices.

The current language implies that level-asymmetry-allowed applies to both
downgrading and upgrading the level in an answer.  In its absence neither is
therefore allowed.  However, it is only in the description of
level-asymmetry-allowed that this is indicated.  The first paragraphs of
Section 8.2.2 explicitly state that level downgrading is allowed, without
mention of the level-asymmetry-allowed attribute until later.  There are
four examples of level asymmetry given:  level-asymmetry-allowed is absent
in the three downgrade cases and present only the one upgrade case.   Thus
it might be reasonable to infer an intent that level-asymmetry-allowed only
applies to upgrades.

More seriously, I am concerned that this attribute changes the SDP semantics
in a way that is not backwards compatible.  There is a statement near the
end of RFC-3984 Section 8.2.2 which is commonly interpreted as meaning the
level can be downgraded:

.         Parameters declaring a configuration point are not downgradable,

      with the exception of the level part of the "profile-level-id"

      parameter.  This expresses values a receiver expects to be used

      and must be used verbatim on the sender side.

All the H.264 SIP devices that I am familiar with allow the level to be
downgraded in an answer, and some depend on it.  As an example, the
Radvision 3545 MCU will answer any H.264 offer with Level 1.2 (or less, when
operating in "standard rate" mode), and then depend on the remote end to
conform.  All current Cisco endpoints (and Cisco Unified Communications
Manager, acting as B2BUA for SCCP and H.323 devices) use this
interpretation.  If the lack of level-asymmetry-allowed means an endpoint
cannot answer with a lower level, the installed base of these devices will
be non-conformant when 3984bis goes into effect.

Not having been privy to the discussions leading up to this, I do not
understand why level-asymmetry-allowed is required.  Downgrading is an
important mechanism for negotiation between different level endpoints.
Upgrading is harmless in any case: an endpoint is always allowed to encode
at a lower level than negotiated.  If an offering endpoint doesn't like the
answer it can always re-INVITE without the offending PT.

>From my perspective, any of the following are acceptable:

1.       Drop the level-asymmetry-allowed parameter entirely and
unconditionally permit level asymmetry in SDP negotiation.

2.       Change the default to "level-asymmetry-allowed=1", meaning that
legacy endpoints get permissive treatment.

3.       Reverse "level-asymmetry-allowed" to "level-asymmetry-required"
(and leave the default as off).

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]