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

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 2 Oct 2006 18:15:38 -0700

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

> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Thursday, September 28, 2006 8:31 AM
> To: Magnus Westerlund; IETF AVT WG; Cullen Jennings; [email-masked];
> 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:[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,
> >
> > 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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 03 Oct 2006 10:34:21 +0200

> draft. Can somebody enlighten me here on when am I mandated to use only

With system that only implements H263-1998. Please remember that this is 
an update of RFC 2429.

> m=video 45678 RTP/AVP 96 97

An bug on the above line   98

Cheers

Magnus Westerlund

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 3 Oct 2006 10:57:28 +0200

Hi,
The 1998 and 2000 are two version of the H.263 ITU. The profiles and
levels which are specified in H.263 annex X were added only in the 2000
version.

One important point I took from the email thread is that there is a need
to clearly specify the default mode if no optional parameters are
specified. Here is the difference between the 1998 and 2000 version. For
the h263-1998 the default will be H.263 base line QCIF while for the
H263-2000 it will be profile 0 level 10 (if all agree). In the text I
will explain that H263-1998 does not support profile and levels that
were defines later.
Note also that the interlace parameter is also in H263-2000, again it is
part of an annex W that was defined only in the 2000 version.

My expectation is that People read the normative references and will
understand the different H.263 revisions.
Also section 2 of the draft explains the difference between H.263-1998
(H.263+) and H.263-2000 (H.263++)

As for the example I will add
Roni

> From: Desineni, Harikishan [mailto:[email-masked]]
> Sent: Tuesday, October 03, 2006 3:16 AM
> To: Even, Roni; Magnus Westerlund
> Cc: IETF AVT WG; Cullen Jennings; [email-masked]; Carsten Bormann;

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 3 Oct 2006 19:55:45 -0700

Making profile 0, level 10 {QCIF 15FPS for h263-1998} as the default
will be very friendly towards legacy implementations. This would be the
best choice for both h263-1998 and h263-2000.

I don't think it is safe to assume that all decoders out there support
30FPS QCIF,CIF.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: Tuesday, October 03, 2006 1:57 AM
To: Desineni, Harikishan; Magnus Westerlund
Cc: IETF AVT WG; Cullen Jennings; [email-masked]; Carsten Bormann;
Stephan Wenger (Nokia); Gary Sullivan
Subject: RE: [AVT] Offer/Answer section in
draft-ietf-avt-rfc2429-bis-09.txt

For the h263-1998 the default will be H.263 base line QCIF while for the
H263-2000 it will be profile 0 level 10 (if all agree). In the text I
will explain that H263-1998 does not support profile and levels that
were defines later.

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 4 Oct 2006 12:18:51 +0200

Hi,
The problem is that profile 0 level 10 is not defined for H263-1998. The
ITU document H.263 from 1998 does not have profile 0 level 10. That is
why older implementation will support H.263 baseline at QCIF

Roni

> Sent: Wednesday, October 04, 2006 4:56 AM

---

From: Gary Sullivan <[email-masked]>
Date: Wed, 4 Oct 2006 10:56:32 -0700

Actually, I would personally say that H.263-1998 DOES support profile 0
level 10.  It just did not have that name officially defined for that
type of bitstream until 2001.  In fact that type of operation was even
supported in the original (1995) edition.

Profile 0 level 10 is synonymous with Baseline operation at QCIF
resolution with a frame rate no greater than 15 / 1.001 frames per
second.  There is no difference between the bitstream formats of
H.263-2005, H.263-2001, H.263-2000, H.263-1998, or H.263-1995 when
operated in that fashion.

Best Regards,

Gary Sullivan

+> -----Original Message-----
+> From: Even, Roni [mailto:[email-masked]] 
+> Sent: Wednesday, October 04, 2006 3:19 AM
+> To: Desineni, Harikishan; Magnus Westerlund
+> Cc: IETF AVT WG; Cullen Jennings; [email-masked]; Carsten 
+> Bormann; Stephan Wenger (Nokia); Gary Sullivan
+> Subject: RE: [AVT] Offer/Answer section in 
+> draft-ietf-avt-rfc2429-bis-09.txt
+> 
+> Hi,
+> The problem is that profile 0 level 10 is not defined for 
+> H263-1998. The
+> ITU document H.263 from 1998 does not have profile 0 level 
+> 10. That is
+> why older implementation will support H.263 baseline at QCIF
+> 
+> Roni
+> 
+> > -----Original Message-----
+> > From: Desineni, Harikishan [mailto:[email-masked]]
+> > Sent: Wednesday, October 04, 2006 4:56 AM
+> > To: Even, Roni; Magnus Westerlund
+> > Cc: IETF AVT WG; Cullen Jennings; [email-masked]; 
+> Carsten Bormann;
+> > Stephan Wenger (Nokia); Gary Sullivan
+> > Subject: RE: [AVT] Offer/Answer section in 
+> draft-ietf-avt-rfc2429-bis-
+> > 09.txt
+> > 
+> > Making profile 0, level 10 {QCIF 15FPS for h263-1998} as 
+> the default
+> > will be very friendly towards legacy implementations. This would be
+> the
+> > best choice for both h263-1998 and h263-2000.
+> > 
+> > I don't think it is safe to assume that all decoders out 
+> there support
+> > 30FPS QCIF,CIF.
+> > 
+> > -----Original Message-----
+> > From: Even, Roni [mailto:[email-masked]]
+> > Sent: Tuesday, October 03, 2006 1:57 AM
+> > To: Desineni, Harikishan; Magnus Westerlund
+> > Cc: IETF AVT WG; Cullen Jennings; [email-masked]; 
+> Carsten Bormann;
+> > Stephan Wenger (Nokia); Gary Sullivan
+> > Subject: RE: [AVT] Offer/Answer section in
+> > draft-ietf-avt-rfc2429-bis-09.txt
+> > 
+> > For the h263-1998 the default will be H.263 base line QCIF 
+> while for
+> the
+> > H263-2000 it will be profile 0 level 10 (if all agree). In 
+> the text I
+> > will explain that H263-1998 does not support profile and 
+> levels that
+> > were defines later.
+> 
+>

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 5 Oct 2006 08:48:27 +0200

Gary,
You are correct and I was not arguing the mode. I was just pointing pout
that if H263-1998 references the 1998 version then it can not suggest
using profile and level which were defined in the 2000 version.
The txt I suggested was that if the EP signals H263-1998 with no
parameters it will mean base line at QCIF while if it signals H263-2000
with no parameters it will mean profile 0 level 0.
I assume that we will still have the frame rate as an issue since for
H263 and H263-1998, my view is that it was 30 fps while level 10 is
15fps but I do not see this as a major problem.
Roni

> From: Gary Sullivan [mailto:[email-masked]]
> Sent: Wednesday, October 04, 2006 7:57 PM
> To: Even, Roni; Desineni, Harikishan; Magnus Westerlund
> Stephan Wenger (Nokia)

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 5 Oct 2006 09:31:33 +0200

Hi,
After further study of the framework I saw that in H.323 it states that
systems supporting H.263 must support QCIF with no resolution specified.
At the IETF there was no way to specify resolutions and frame rates.
This was one of the reasons for updating the H.263 and H.261 RFCs (2429,
2032 and 2190 which will become historical)
Roni

> Sent: Thursday, October 05, 2006 8:48 AM
> To: Gary Sullivan; Desineni, Harikishan; Magnus Westerlund
> Cc: Cullen Jennings; Carsten Bormann; Stephan Wenger (Nokia); IETF AVT
WG
> > Subject: RE: [AVT] Offer/Answer section in
draft-ietf-avt-rfc2429-bis-
> > 09.txt
> >
> >
> > Actually, I would personally say that H.263-1998 DOES support
profile
> 0
> > +> > will be very friendly towards legacy implementations. This
would