Subject: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Sep 2006 11:38:18 +0200

Hi,

I with help of my colleagues we have found a shortcoming in the Media 
type and offer/answer description of the updated H.263 payload format. I 
am really sorry to not have spotted these before. However I think we 
need to address them.

The first issue is that the text for profile is unclear in how one 
handle profiles.

    Profile: The offer of a SDP profile parameter signal that the sender
    can decode a stream that uses the specified profile.  Each profile
    uses different H.263 annexes so there is no implied relationship
    between them.  In the offer/answer exchange this parameter SHOULD be
    the same in the offer and answer.  A decoder that support a profile
    SHALL also support H.263 baseline profile (profile 0).

First of all, I think the profile should be non changeable for a given 
payload type. Instead one has to offer each profile one desires to use 
in different payload types. To avoid the issue that the other end-point 
can't propose another profile one should always offer profile 0.

Secondly we need text that says that downgrading the LEVEL parameter in 
an answer is allowed to be done. At least in unicast cases, but not in 
multicast, where the value is take it or leave it.

Thus I would propose the following new text:

    PROFILE: The offer of a SDP profile parameter signal that the offerer
    can decode a stream that uses the specified profile.  Each profile
    uses different H.263 annexes so there is no implied relationship
    between them.  Thus an answerer SHALL NOT change the profile
    parameter and MUST instead reject the payload type containing a
    unsupported profile. A decoder that support a profile SHALL also
    support H.263 baseline profile (profile 0). A offerer is RECOMMENDED
    to offer all the different profiles it is interested to use as
    individual payload types. In addition an offerer is RECOMMENDED to
    always offer profile 0, as this will enable communication, and in
    addition allow an answerer to add those profiles it does support in
    an answer.

    LEVEL: The LEVEL parameter in an offer indicates the maximum
    computational complexity supported by the offerer in performing
    decoding for the given PROFILE. An answerer MAY change the value
    (both up and down) of the LEVEL parameter in its answer to indicate
    the highest value it supports.

The next issue is that there is no special rules specified for 
multicast. I think they are needed as individual participants of an 
multicast session can't change the parameters on an individual basis.

NEW (end of section 8.2.1)

    The following limitations apply for usage of these media types when
    performing offer/answer for sessions using multicast transport. A
    answerer SHALL NOT change any of the parameters in an answer, instead
    if the indicated values are not supported the payload type MUST be
    rejected.

Yet another issues is that there is no default level is specified in the 
definition in section 8.1.2 (H263-2000). This something that should be 
done. However there is a conflict in specifying this parameter with the 
legacy support discussed in section 9.1 that indicates that QCIF and 30 
FPS should be supported when no parameters is given. If one tries to 
express that in profile and levels that is profile 0 and level 20. 
However level 20 also supports CIF in 15 FPS. Thus the proposed default 
behavior is sub-profiling the existing profile and level system which 
seems very unfortunate. I would propose that level defaults to 10.

Finally the INTERLACE parameter is missing offer/answer text. My 
interpretation of this parameter is that if included by an offerer or an 
answerer that entity is able to receive interlaced content.

    INTERLACE: The parameter MAY be included in either offer or answer to
    indicate that the offerer or answerer respectively supports reception
    of interlaced content.  The inclusion in either offer or answer is
    independent of each other.

The above text is assuming that it is the senders choice to provide a 
interlaced bit-stream or not. There is no possibility as currently 
defined to force a sender to provide interlaced content.

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: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Sep 2006 18:30:35 +0300

Magnus,
As the editor of 2429-bis I appreciate you comments and suggest that I will update the draft accordingly. Since it is waiting for IANA then I assume we can still hold it.
Colin can you please help me with how to enable me to update the draft.

The major point for my point of view that requires updating is to clearly define the default behavior if no parameter is specifies.
My suggestion is that for H.263-1998 the default is H.263 baseline (this will also be in line with the historic H263), QCIF 30 fps. 

For H.263-2000 it will be profile 0 level 10 line your suggestion.

I think that the rest of the comments and clarification will prevent future interoperability issue even though to me they were clear so I will make them.

Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, September 28, 2006 12:38 PM
> To: IETF AVT WG; Cullen Jennings; [email-masked]; Carsten Bormann;
> Stephan Wenger (Nokia); Gary Sullivan
> Subject: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-09.txt
> 
> Hi,
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 28 Sep 2006 20:15:35 +0200

On 28 Sep 2006, at 17:30, Even, Roni wrote:
> As the editor of 2429-bis I appreciate you comments and suggest  
> that I will update the draft accordingly. Since it is waiting for  
> IANA then I assume we can still hold it.

You can fix it in AUTH48, although it'll need AD approval if there  
are technical changes to the draft.

Colin