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

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Mon, 30 Nov 2009 14:18:35 -0600

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]

---

From: Randell Jesup <[email-masked]>
Date: Mon, 30 Nov 2009 16:10:21 -0500

>likely to break compatibility with many existing devices.

(Jumping back in after a long time with my head down doing work I'm
paid for...)

I believe there's a considerable mis-understanding here of the intent of
level-asymmetry-allowed.  Level asymmetry is not the same issue as level
downgrade; it's allowing the two directions in an exchange to use
different levels, and in particular for the answerer to specify a higher
level (if they can decode it) or a lower level then the offer because
they can't use/handle it (but still send video at the (higher) offer
level).  See the discussions as to the uses for these behaviors
(irrelevant in this discussion).

Barring agreement on level-asymmetry (such as in 3984, or if it's not
allowed in 3984bis), you can downgrade levels, but if so then both sides
must downgrade, per the normal interpretation of 3984 (after the spec
was standardized).  This is why we added a parameter - retain
compatibility with 3984 devices.

This was the language I was pushing during the editing, but the final
language was rewritten by Ye Kui after my last input, based on his
earlier language.  I'll have to check to make sure the behaviour
intended (per above) is still specified in the spec.

>devices will be non-conformant when 3984bis goes into effect.

I'll have to review the current language, but if people are
misunderstanding this, then we may need to add a clarifying comment
and/or example.  

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
[email-masked]

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Mon, 30 Nov 2009 15:46:04 -0600

Thanks... that makes sense.  If in the draft you could clarify the
distinction between asymmetry in the answer versus asymmetry in the
encodings then we should be happy.

Stuart Taylor, Cisco Systems
[email-masked]

> -----Original Message-----
> From: Randell Jesup [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 4:10 PM
> To: Stuart Taylor (sttaylor)
> Cc: [email-masked]; Cullen Jennings (fluffy);
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Chelliah
> Sivachelvan (chelliah)
> Subject: Re: Comment on 3984bis: level-asymmetry-required
>

---

From: Roni Even <[email-masked]>
Date: Mon, 30 Nov 2009 23:50:04 +0200

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,

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.

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]

---

From: "Stuart Taylor (sttaylor)" <[email-masked]>
Date: Mon, 30 Nov 2009 15:55:34 -0600

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

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

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)

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 30 Nov 2009 17:51:15 -0500

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

Stuart Taylor

Hi,

Roni Even

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]

---

From: Roni Even <[email-masked]>
Date: Tue, 01 Dec 2009 00:58:41 +0200

Hi,

I am wondering what this means, even if it will mean that the answer may use
lower level which may contradict the previous text. 

Is it level downgrade where both sides need to use the same level as
specified in the answer (which will be lower than the one in the offer) or
is it asymmetry where the answerer wants to receive the lower level but will
still send at the higher level (asymmetry). I think that our assumption was
like Randell said that asymmetry is not part of RFC3984

BTW: The issue with asymmetry is true for most products (not only the ones
you mentioned and was the reason why we did not have a problem with
proposing a solution that will change the semantics of the text in the first
bullet of 8.2.2 in RFC3984 which we felt was mandating symmetry).

Still I agree with Randell that the text about level-asymmetry-allowed must
be clear and would expect that if it is not you should propose text since we
have been going through this drafting for long time and the feeling in the
working group last call was that it is clear

thanks

Roni Even

Sent: Monday, November 30, 2009 11:56 PM

Stuart Taylor

Hi,

Roni Even

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]

---

From: Roni Even <[email-masked]>
Date: Tue, 01 Dec 2009 01:39:44 +0200

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

  _____  

Stuart Taylor

Hi,

Roni Even

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 30 Nov 2009 21:09:53 -0500

I think the confusion might be due to the following text in section 8.1.
It is ambiguous whether "level asymmetry" refers to the actual RTP media
level or the SDP offer/answer level. I assume the RTP media level was
intended. But if some readers interpret this as the SDP offer/answer
level, they will incorrectly conclude that this parameter is required in
order to use a different level in the SDP answer even for level
downgrade.

       level-asymmetry-allowed:
          This parameter MAY be used in SDP Offer/Answer to indicate
          whether 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 value MAY be equal to
          either 0 or 1.  When the parameter is not present, the value
          MUST be inferred to be equal to 0.  The value 1 in both the
          offer and the answer indicates that level asymmetry is
          allowed.  The value of 0 in either the offer or the answer
          indicates the level asymmetry is not allowed.
 
          If "level-asymmetry-allowed" is equal to 0 (or not present)
          in either the offer or the answer, level asymmetry is not
          allowed.  In this case, the level to use in the direction
          from the offerer to the answerer MUST be the same as the
          level to use in the opposite direction.

Mo Zanaty

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.

Roni

Mo Zanaty

Stuart Taylor

Hi,

Roni Even

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]