Re: [AVT] RFC 3984 offer/answer Question

[Randell Jesup <rjesup at wgate.com>]

"Even, Roni" <roni.even at polycom.co.il> writes:
>"If the offerer wants to support only level 1.0" - this is not the case
>here. The offerer can support level 3. The answerer can support only
>level 1 which is implied by the offer. The parameter value is supported.
>This is why the answerer maintains the configuration parameters. 

My apologies if I wrote too quickly - I was on the way to pick up my
mother-in-law at the hospital (after 10 weeks).  I should have said
"if the offerer wants to also support level 1.0".  It should have
been clear from the context, but I mis-stated it.


The offerer supports Level 3.0, and in the original question, only includes
a single payload and FMTP at 3.0.  According to 8.2.2 (below), you MUST use
profile-level-id symmetrically (along with packetization-mode and maybe
sprop-deint-buf-req).  The answer MUST not change any of them, or it must
remove the payload if it cannot support them.  So, when offered level 3, an
answerer who supports level 1 MUST remove the level 3 payload.

Accordingly (and per the much longer full section 8 of the RFC and RFC
3264, I think if you want to support levels 1-N you must offer levels 1-N
as separate payloads (N payloads).  If you want to support
packetization-modes 0 and 1 as well, you'll need 2*N payloads.

I wish I'd been looking at this before it was approved, though given
general offer-answer semantics it's not too surprising they chose this way.

>> I think that's invalid for offer/answer, per 8.2.2.  If the offerer
>> wants to support only level 1.0 (in this case, 42a00a), it *has* to
>> offer it as a separate payload type in the offer.  The answer cannot add
>> it as the same payload type, and you're not supposed to add media
>> formats (payloads) in an answer.
>> 
>> 
>> 8.2.2.  Usage with the SDP Offer/Answer Model
>> 
>>    When H.264 is offered over RTP using SDP in an Offer/Answer model [7]
>>    for negotiation for unicast usage, the following limitations and
>>    rules apply:
>> 
>>    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.
>> 
>>          Informative note: The requirement for symmetric use applies
>>          only for the above three parameters and not for the other
>>          stream properties and capability parameters.
-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)


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