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

["Even, Roni" <roni.even at polycom.co.il>]

Magnus,

I asked in Polycom the feedback is:

Alternative 1 seems like the best choice.  The Offer/Answer is really
just a caps exchange and we are telling the remote side in the answer
what we can accept.

>From RFC 3264:
8.3.4 Changing Attributes

   Any other attributes in a media description MAY be updated in an
offer or answer.  Generally, an agent MUST send media (if the
directionality of the stream allows) using the new parameters once the
SDP with the change is received.




Alternative 2 does not sound good as it says the answer must have the
exact same profile-level-id.  If we do not support receiving that
profile-level-id then it would appear we would either have to remove
H.264 from the media line, or reject that media line and answer with a
new one.

Roni Even


-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
Magnus Westerlund
Sent: Tuesday, May 17, 2005 5:45 PM
To: IETF AVT WG
Subject: [AVT] First bug in the RTP payload format for H.264 (RFC 3984)

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

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