RE: [AVT] RFC 3984 offer/answer Question

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

Randell,

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

Roni

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
A consensus means that everyone agrees to say collectively what no one
believes individually
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: Wednesday, August 15, 2007 2:41 PM
> To: Even, Roni
> Cc: Yuval Nissan; ctrobianni at ecotronics.com; avt at ietf.org
> Subject: Re: [AVT] RFC 3984 offer/answer Question
> 
> "Even, Roni" <roni.even at polycom.co.il> writes:
> >>      m=video 49170 RTP/AVP 98
> >>      a=rtpmap:97 H264/90000
> >>      a=fmtp:97 profile-level-id=42A00A; packetization-mode=0;
> >
> >You just have a problem with the payload type 98
> 
> >>      m=video 49170 RTP/AVP 98
> >>      a=rtpmap:98 H264/90000
> >>      a=fmtp:98 profile-level-id=42A00A; packetization-mode=0;
> 
> Roni -
> 
> 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.
> 
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >
> >> From: Yuval Nissan [mailto:Yuval.Nissan at audiocodes.com]
> >
> >> Sent: Wednesday, August 15, 2007 9:19 AM
> >
> >> To: Randell Jesup; ctrobianni at ecotronics.com
> >
> >> Cc: Even, Roni; avt at ietf.org
> >
> >> Subject: RE: [AVT] RFC 3984 offer/answer Question
> >
> >>
> >
> >> I now understand that the following scenario is legal:
> >
> >>
> >
> >> Offerer support up to level 3.
> >
> >> Offerer -> Answerer SDP message:
> >
> >>
> >
> >>       m=video 49170 RTP/AVP 98
> >
> >>       a=rtpmap:98 H264/90000
> >
> >>       a=fmtp:98 profile-level-id=42A01E; packetization-mode=0;
> >
> >>
> >
> >> Answerer support level 1 only.
> >
> >> Answerer -> Offerer SDP message:
> >
> >>
> >
> >>      m=video 49170 RTP/AVP 98
> >
> >>      a=rtpmap:97 H264/90000
> >
> >>      a=fmtp:97 profile-level-id=42A00A; packetization-mode=0;
> >
> >>
> >
> >> The offerer understands that the session should be in level 1.
> >
> >>
> >
> >> Thanks for your feedback,
> >
> >> Yuval
> >
> >>
> >
> >>
> >
> >> -----Original Message-----
> >
> >> From: Randell Jesup [mailto:rjesup at wgate.com]
> >
> >> Sent: Tuesday, August 14, 2007 19:25
> >
> >> To: ctrobianni at ecotronics.com
> >
> >> Cc: Yuval Nissan; roni.even at polycom.co.il; avt at ietf.org
> >
> >> Subject: Re: [AVT] RFC 3984 offer/answer Question
> >
> >>
> >
> >> "Cesar Trobianni" <ctrobianni at ecotronics.com> writes:
> >
> >> >>The level is the highest level supported so level 3 means that
you
> >
> >> also
> >
> >> >>support level 1. This is specified in RFC 3984.
> >
> >> >>
> >
> >> >>B can offer level 3.
> >
> >> >
> >
> >> >But still a separate profile-level-id ftmp line per level should
be
> >
> >> >acceptable (as worst-case scenario), right?
> >
> >>
> >
> >> You can only have one fmtp line per payload value.
> >
> >>
> >
> >> You can define multiple payloads with different fmtp's for a media
> >
> >> stream,
> >
> >> however.  Responses (payloads and their fmtp's) are matched up
against
> >
> >> the
> >
> >> offer using a combination of profile-level-id, packetization-mode,
and
> >
> >> (if
> >
> >> used) the sprop interleave (if I remember correctly - that last one
> >only
> >
> >> applies to packetization-mode 2).
> >
> >>
> >
> >> Assuming anyone implements all of that totally correctly... :-/
> >
> >>
> >
> >> --
> >
> >> 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
> 
> 
> --
> 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