Re: [AVT] RFC 3984 offer/answer Question

[Randell Jesup <rjesup at wgate.com>]

"Even, Roni" <roni.even at polycom.co.il> writes:
>Randell,
>I can see your point but I would like to see other opinions maybe from
>the authors of the text.

Absolutely.

>My view is that most current implementation of offer / answer for
>unicast has the same approach. (this is based on interoperability tests
>between vendors of video conferencing systems)

I suspect that all the implementations you've tested (conferencing systems)
have tested against each other, and they've ended up (perhaps without even 
realizing it) at a non-compliant implementation.  Or perhaps one or more
realized the RFC meant the SDP processing would be a royal pain, and so
decided to purposely implement something similar but not RFC compliant.

>The problem here is that the profile-level-id parameter includes three
>different parameters.
>I still think that on the level part of the parameter the comparison
>should be based on the highest common. I do not believe that the
>intention here was to fix a specific mode.

Perhaps it wasn't, but that is the result of the text (or more to the
point, fix a 1<->1 relationship of payload value to level).  You can
support a lot of levels, but the RFC says you have to be able to
distinguish them by payload value.  It ends up wordy in the SDP (VERY
wordy), but it would work.  (It would make support for 3984 above a low
level pretty much impossible on UDP SIP, for example, but it's not the only
thing that can do this - see Magnus's 10K SDP example.)

>Since the level parameter is an upper bound and lower levels are
>included (except for level 1b) it does not make sense to offer a
>separate media type for each level (there are 15 levels defined), for
>example if the offerer support level 3 it will need to specify 3,2.2,
>2.1, 2, 1.3, 1.2, 1.1 and 1 using 8 media type. 

Lower levels are included, but from the registration for profile-level-id
in 8.1:

                        If the profile-level-id parameter is used to
                        indicate properties of a NAL unit stream, it
                        indicates the profile and level that a decoder
                        has to support in order to comply with [1] when
                        it decodes the stream.  

(that is declaritive SDP) and for negotiation:

                        If the profile-level-id parameter is used for
                        capability exchange or session setup procedure,
                        it indicates the profile that the codec
                        supports and the highest level
                        supported for the signaled profile.  The
                        profile-iop byte indicates whether the codec
                        has additional limitations whereby only the
                        common subset of the algorithmic features and
                        limitations of the profiles signaled with the
                        profile-iop byte and of the profile indicated
                        by profile_idc is supported by the codec.  For
                        example, if a codec supports only the common
                        subset of the coding tools of the Baseline
                        profile and the Main profile at level 2.1 and
                        below, the profile-level-id becomes 42E015, in
                        which 42 stands for the Baseline profile, E0
                        indicates that only the common subset for all
                        profiles is supported, and 15 indicates level
                        2.1.

                            Informative note: Capability exchange and
                            session setup procedures should provide
                            means to list the capabilities for each
                            supported codec profile separately.  For
                            example, the one-of-N codec selection
                            procedure of the SDP Offer/Answer model can
                            be used (section 10.2 of [7]).

10.2 of RFC 3264 is the "offer inactive with many payloads, get inactive
response, reINVITE active with a single payload, get active response".

That (and the "list the capabilities for each supported codec profile
separately") makes me think that this requirement to have N (or 2*N or
in theory even more) payloads is intentional, not just poor wording.

>I do not think that this was the intention in offer/answer. Offer/answer
>should not be used to fix a specific level.

See above; I'm not sure you're right here.  I agree that (unless there's
something I'm missing about why they did this) I'd really like to be
able to have an asymmetric response, but there's no standard (see my
options a-e in my response to Yuval).

>To make it more complicated, by using the other optional parameters like
>max-mbps, max-fs the meaning of the level according to table A.1 in
>H.264 is changed and the current maximum values supported are based on
>the sum of the values from table A.1 and the optional parameters. 

Right, though the offer-answer section says that those do not have to
match in the offer and answer.

>BTW: I do not think that having the same level in the offer and answer
>will make the communication symmetric, the encoder on each side can send
>any frame size at any macro blocks per second rate that falls within the
>specified level (this means frame size and frame rate would not be the
>same on each direction). 

You're correct it doesn't select actual frame size (in x, y) or frame rate.
(within the limits of the level).  However, the assumption of the writers
*may* have been that agreeing on a level was important due to some
algorithmic differences or resource-reservation issues - for example, an
offerer who does a lot of streams might not want to have to reserve enough
processing power, buffers, etc to decode level 3 if the answerer only
supports level 1 - but if you let the answerer respond at level 1 to a
level 3 offer, the offerer doesn't know if they'll receive level 1 or 3.
(That's totally a guess and likely wrong, but it's an example of why they
might have made the decision.)

>If you want to have a specific picture size or frame rate (e.g. CIF at
>30 fps) then you will need a different signaling for requesting specific
>mode. I mentioned in Chicago that we are working in H.323 on such
>extensions (requesting a specific mode (picture size and frame rate))
>and we will have a similar draft for SDP based systems.

Which will be useful when it's available.  Our device in reality only
supports fixed resolutions.  It can support others, but it has to scale
them to fit on the display, so it's better to avoid that, and scaling isn't
free (horsepower-wise, or artifact-wise).

We may need a 3984-bis, or an explanation why all the conferencing people
are doing it wrong or have mis-read the RFC (it's dense reading - witness
this discussion.  And some people read it and say "that's silly, they must
have meant to do it this way..." since they don't know why the rfc reads
the way it does - me included.)

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