[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] RFC 3984 offer/answer Question
Randell,
I went back to the mailing list and found the attached email.
It is in line with my thought that the level can be downgraded
Roni
> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: Thursday, August 16, 2007 4:22 PM
> To: Yuval Nissan
> Cc: Even, Roni; ctrobianni at ecotronics.com; avt at ietf.org;
stewe at stewe.org;
> Ilan Avner
> Subject: Re: [AVT] RFC 3984 offer/answer Question
>
> "Yuval Nissan" <Yuval.Nissan at audiocodes.com> writes:
> >Regarding the communication symmetric - if we understand it the way
> >which you propose (which I think is the practical one):
> >
> >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:98 H264/90000
> > a=fmtp:98 profile-level-id=42A00A; packetization-mode=0;
> >
> >There can be 2 possibilities:
> >
> >1. The offerer must transmit in level 1.0. Still the answerer can
> >transmit up to level 3.0 if he wants.
> >
> >2. Both of them must use level 1.
> >
> >Which one is correct?
>
> Correct? Neither, I'm afraid.
>
> Given the RFC, if someone sends a response that doesn't comply with
the
> RFC (i.e. a level 1.0 response to level 3.0 offer), there's no way to
know
> how the offerer will deal with that response.
>
> They could:
> a) go asymmetric, and send 1.0 and receive any 1.0 -> 3.0 stream
> b) require symmetric, and send and receive 1.0 only
> c) Not understand the response and consider it in error, and either
> reINVITE (perhaps to 1.0, or to another codec, or even 3.0 again)
or
> send a BYE.
> d) Not understand the response and send 3.0 anyways (since the payload
> value was accepted, and the RFC doesn't allow for changing the
level of
> a payload).
> e) Process the response as a new, added payload (since it doesn't
match
> on the triple of level, packetization, deint-buf) even though
> numerically it's the same. Given offer-answer semantics, this
would
> mean the answer did not provide a payload that was offered, and
while
> each side should continue to accept what they sent, the offerer
> should not send. This is probably the most canonically-correct way
to
> handle the response per the RFCs (3984 and 3264).
>
> You don't know which of these they will do, especially if the
> implementation was developed in a closed system without direct
> interoperation tests (against systems that may not comply with the RFC
and
> so force them to do something other than option e, or whatever
possible
> mis-reading of the RFC they had).
>
> Now, Roni may be correct that some of the conferencing people have
assumed
> that you don't have to match profile-level-id (which is incorrect per
the
> RFC, but if they all test against each other may work in practice).
If
> there is a big hole in the RFC that has caused everyone to make some
> non-compliant assumption (like option 'a' above), then it should be
> made into a new RFC (3984bis). They may find that the authors had a
> reason
> for not allowing it, or perhaps there's a better solution to their
> problem.
>
> So neither is 'correct'. One of those (or one of a-e) may be
compatible
> with many or even most H.264+SIP+SDP devices -- but I doubt that
either
> choice will avoid compatibility problems with all such devices.
> Unfortunately.
>
> --
> 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)
--- Begin Message ---
Hi,
We authors was made aware of an issue in the Offer/Answer usage for the
H.264 RTP payload format by Tang Yongliang.
The issue is that section 8.2.2 says:
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.
And later
" o Parameters declaring a configuration point are not downgradable,
with the exception of the level part of the "profile-level-id"
parameter."
That is contradicting for the "profile-level-id" parameter. The
intention of the authors was that the profile part (profile_idc and
profile_iop) would be fixed but the level (level_idc) can be downgraded.
That way you as an receiver state the profiles and highest level for
that profile you are willing to accept. The answerer can then respond
with the same profile but with a possibly lower level.
So for clarification: An answerer MUST only maintain the profile_idc and
profile_iop bytes of the profile-level-id value and MAY downgrade the
level part.
Please note: This may require the offering party to make a new offer to
provide its "sprop" parameters correctly due to the reduction in level.
However without this clarification the only way of getting a successful
offer/answer for H.264 when not fully aware of the counter-parts
capabilities would be to write one payload type for each profile-level
combination that one could downgrade to.
Any comments on this clarification?
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
--- End Message ---
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt