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

["Desineni, Harikishan" <[e-mail]>]

It would be good to provide some examples along with these updates. 
(I tried to come up with few examples listed at the end of this e-mail)

Profile and level are not included as parameters to H263-1998 MIME
subtype. It looks like "profile=xx;level=yy" indication is applicable to
H263-2000 MIME subtype only. If this is indeed the case, it would be
better to clarify this as part of the upcoming update to the draft (in
the offer/answer section).

>From Sec 8.1.2 on H263-2000 MIME subtype:
"The optional parameters of the H263-1998 type MAY be used with this
MIME subtype." 
This is giving H263-2000, the freedom to use all optional parameters
defined for H263-1998. Thus, it looks like just one MIME subtype
(H263-2000) is necessary (May be I am terribly incorrect here!) in this
draft. Can somebody enlighten me here on when am I mandated to use only
h263-1998?


Example 1:
SDP offer with Profile 0, Level 10 and profile 1 and level 10

m=video 34560 RTP/AVP 96 97
a=rtpmap:96 h263-2000/90000
a=fmtp:96 profile=0;level=10;
a=rtpmap:97 h263-2000/90000
a=fmtp:97 profile=1;level=10;

SDP answer with profile 0, level 45 
m=video 45678 RTP/AVP 96 
a=rtpmap:96 h263-2000/90000
a=fmtp:96 profile=0;level=45;


Example 2:

SDP offer with Profile 0, Level 10 

m=video 34560 RTP/AVP 96 
a=rtpmap:96 h263-2000/90000
a=fmtp:96 profile=0;level=10;


SDP answer with profile 0, level 45 and profile 1, level 10

m=video 45678 RTP/AVP 96 97
a=rtpmap:96 h263-2000/90000
a=fmtp:96 profile=0;level=45;
a=rtpmap:98 h263-2000/90000
a=fmtp:98 profile=1;level=10;

Mid-call, offerer updates the level from 10 to 45:

m=video 34560 RTP/AVP 96 
a=rtpmap:96 h263-2000/90000
a=fmtp:96 profile=0;level=45;



- - - - - - - - - - - - - - - - -
Harikishan Desineni
Qualcomm Inc.,
mailto:[e-mail]


> -----Original Message-----
> From: Even, Roni [mailto:[e-mail]]
> Sent: Thursday, September 28, 2006 8:31 AM
> To: Magnus Westerlund; IETF AVT WG; Cullen Jennings; [e-mail];
> Carsten Bormann; Stephan Wenger (Nokia); Gary Sullivan
> Subject: RE: [AVT] Offer/Answer section in draft-ietf-avt-rfc2429-bis-
> 09.txt
> 
> 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:[e-mail]]
> > Sent: Thursday, September 28, 2006 12:38 PM
> > To: IETF AVT WG; Cullen Jennings; [e-mail]; Carsten Bormann;
> > Stephan Wenger (Nokia); Gary Sullivan
> > Subject: [AVT] Offer/Answer section in
draft-ietf-avt-rfc2429-bis-09.txt
> >
> > 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 [phone]
> > Torshamsgatan 23           | Fax   [phone]
> > S-164 80 Stockholm, Sweden | mailto: [e-mail]
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt

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