[AVT] First bug in the RTP payload format for H.264 (RFC 3984)

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,

We authors have received a question that identifies an contradiction in 
section 8.2.2:

One paragraph states:

   o  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.

Two other states:

   o  Parameters used for declaring receiver capabilities are in general
      downgradable; i.e., they express the upper limit for a sender's
      possible behavior.  Thus a sender MAY select to set its encoder
      using only lower/lesser or equal values of these parameters.
      "sprop-parameter-sets" MUST NOT be used in a sender's declaration
      of its capabilities, as the limits of the values that are carried
      inside the parameter sets are implicit with the profile and level
      used.

   o  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.


As can be seen there is an inconsistency in the description in respect 
to the level part of "profile-level-id" value included in any offer. The 
two different interpretations that can be done are:

1. The answerer may change the level part of the profile-level-id value 
in the answer.

2. Exactly the same profile-level-id string MUST be used in the answer. 
However the media sender may use a lower level.

These two alternative interpretations could lead to a interoperability 
issue, this needs to be clarified.

So the functional difference is that for alternative 1, the answerer can 
accept a media type even if it only support a lower level than the 
offerer, as long as the profile and restrictions match. However I don't 
think that this work due to the fact that the offer assumes that a 
certain level is supported. That assumption is used to when determining 
the parameter-sets that the offerer intends to use when sending to the 
answerer. So if the answerer is allowed to change level, new parameter 
sets are needed to be sent to the answerer. Thus requiring a second 
updated offer/answer exchange. So this can be used but require further 
clarifications in text and indicating these requirements.

Alternative 2 also has the advantage that it will not cause any failures 
even if either part has made the interpretation and gone for alternative 1.

So alternative 1 provides better functionality but at the cost of added 
complexity and reduced interoperability. Using alternative 2 would be 
safe from interoperability stand point.

So what do people say about this? I have no clear preference.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt