Subject: RE: [AVT] Interop issue with H263-1998

From: Gary Sullivan <[email-masked]>
Date: Fri, 7 Sep 2007 11:15:57 -0700

I don't think I have seen a direct reply to this message.  Here is my attempt to answer Guido's question:

RFC 2429 did not have any SDP specification in it (in fact the string "SDP" is not found in RFC 2429).

It is true that RFC 2429 defined an RTP payload packetization scheme that was capable of carrying H.263 data either with or without the various optional H.263 features.  However, in practice, RFC 2429 depended on some externally-defined method (not specified in the RFC) of figuring out which such features would be used in the bitstream.  One such externally-defined method was/is H.245, which supports some pretty elaborate capability declaration expressions for such feature capability negotiation.  But the SDP definition found in RFC 4629 is for scenarios that do not use such an H.245 capability exchange protocol.  I don't actually know where the SDP definition for H.263 was specified before RFC 4629 existed.  However, I am sure that it was not OK to send a fancy combination of obscure H.263 optional features in a bitstream using SDP before RFC 4629.  My understanding is that the majority of H.263 usage is still the "baseline" (no optional modes) configuration, and that is really all that anyone can assume is found in an implementation unless they have some way of knowing otherwise.

As far as I know, someone can hypothetically still use H.263 with H.245 (without using SDP), and such use would be considered in conformance with RFC 4629, regardless of which optional modes were being used.  I believe that the wording "current implementations will not send any optional parameters in their SDP..." in RFC 4629 only applies to when SDP is being used.

Best Regards,

Gary Sullivan

+> -----Original Message-----
+> From: Franceschini Guido
+> [mailto:[email-masked]]
+> Sent: Tuesday, August 21, 2007 8:49 AM
+> To: [email-masked]
+> Cc: Paltro Pier Carlo
+> Subject: [AVT] Interop issue with H263-1998
+>
+> Dear all,
+>
+> I have an issue with the definition of the H263-1998 media type.
+> In the RFC 2429, no optional parameters are defined,
+> implying that any valid H263+ stream could be streamed.
+> In the RFC 4629, that obsoletes 2429, various optional
+> parameters are specified, which allow specifying the
+> (decoder) support to the various annexes.
+>
+> What confuses me is the following statement in RFC 4629,
+> concerning H263-1998
+>
+>    Interoperability considerations:
+>
+>       These are receiver options; current implementations
+> will not send
+>       any optional parameters in their SDP.  They will ignore the
+>       optional parameters and will *** encode the H.263
+> stream without any ***
+>       of the annexes.  Most decoders support at least QCIF
+> and CIF fixed
+>       resolutions, and they are expected to be available
+> almost in every
+>       H.263-based video application.
+>
+> Indeed my understanding would be quite different, and I
+> would have written instead:
+>
+>       These are receiver options; current implementations
+> will not send
+>       any optional parameters in their SDP.  They will ignore the
+>       optional parameters and will *** encode the H.263+
+> stream with possibly all ***
+>       of the annexes.  Most decoders support at least QCIF
+> and CIF fixed
+>       resolutions, and they are expected to be available
+> almost in every
+>       H.263-based video application.
+>
+>
+> Any clarification would be welcomed
+>
+> Best regards
+> Guido Franceschini
+> --------------------------------------------------------------------
+>
+> CONFIDENTIALITY NOTICE
+>
+> This message and its attachments are addressed solely to the
+> persons above and may contain confidential information. If
+> you have received the message in error, be informed that any
+> use of the content hereof is prohibited. Please return it
+> immediately to the sender and delete the message. Should you
+> have any questions, please contact us by replying to
+> [email-masked].
+>
+>         Thank you
+>
+>                                         www.telecomitalia.it
+>
+> --------------------------------------------------------------------
+>
+>
+> _______________________________________________
+> 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: Randell Jesup <[email-masked]>
Date: Fri, 07 Sep 2007 23:20:04 -0400

>"SDP" is not found in RFC 2429). 

Right.  I spent a while looking for the H263/H263+ SDP spec; it didn't
exist (until recently).

>It is true that RFC 2429 defined an RTP payload packetization scheme that
>was capable of carrying H.263 data either with or without the various
>optional H.263 features.  However, in practice, RFC 2429 depended on some
>externally-defined method (not specified in the RFC) of figuring out which
>such features would be used in the bitstream.  One such externally-defined
>method was/is H.245, which supports some pretty elaborate capability
>declaration expressions for such feature capability negotiation.  But the
>SDP definition found in RFC 4629 is for scenarios that do not use such an
>H.245 capability exchange protocol.  I don't actually know where the SDP
>definition for H.263 was specified before RFC 4629 existed.  However, I am
>sure that it was not OK to send a fancy combination of obscure H.263
>optional features in a bitstream using SDP before RFC 4629.  My
>understanding is that the majority of H.263 usage is still the "baseline"
>(no optional modes) configuration, and that is really all that anyone can
>assume is found in an implementation unless they have some way of knowing
>otherwise.

As best I can tell, there were various ad-hoc SDP setups for H.263 before
RFC 4629.  Many of them supported optional parameters (in particular
resolution and MPI), in contradiction of RFC 4629 section 9.1 (which says
that old implementations will ignore these parameters).  For added fun, RFC
4629 doesn't specify the grammar for the fmtp parameters; it assumes
silently (based on other RFCs one assumes) that they'll be delimited by
semicolons.  Many/most existing H.263/263+ applications delimit fmtp
parameters with spaces instead.  RFC 4566 doesn't even mention semicolons
or the details of the ftmp string -- 4566 considers the fmtp string to be
none of its business.  The problem is that different implementers may make
different assumptions about the grammar for the fmtp line.  Perhaps I've
missed something...

>As far as I know, someone can hypothetically still use H.263 with H.245
>(without using SDP), and such use would be considered in conformance with
>RFC 4629, regardless of which optional modes were being used.  I believe
>that the wording "current implementations will not send any optional
>parameters in their SDP..." in RFC 4629 only applies to when SDP is being
>used. 

Note that since the assertion of 4629/9.1 doesn't hold (even for deprecated
RFC 2190; media type video/H263), there can be side-effects when
interoperating, which should have been discussed in the spec and how to
deal with it.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"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)

---

From: Colin Perkins <[email-masked]>
Date: Sat, 8 Sep 2007 08:48:59 +0100

On 8 Sep 2007, at 04:20, Randell Jesup wrote:
...
> different assumptions about the grammar for the fmtp line.  Perhaps  

RFC 4629 section 8.2 states:

    o The optional parameters, if any, MUST be included in the "a=fmtp"
      line of SDP.  These parameters are expressed as a media type
      string, in the form of a semicolon-separated list of
      parameter=value pairs.

The legal syntax of a media type string is specified in the MIME  
RFCs, which are included by reference via a citation to RFC 3555.

-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Sat, 08 Sep 2007 10:03:19 -0400

>> As best I can tell, there were various ad-hoc SDP setups for H.263
>> before RFC 4629.  Many of them supported optional parameters (in
>> particular resolution and MPI), in contradiction of RFC 4629 section 9.1
>> (which says that old implementations will ignore these parameters).  For
>> added fun, RFC 4629 doesn't specify the grammar for the fmtp parameters;
>> it assumes silently (based on other RFCs one assumes) that they'll be
>> delimited by semicolons.  Many/most existing H.263/263+ applications
>> delimit fmtp parameters with spaces instead.  RFC 4566 doesn't even
>> mention semicolons or the details of the ftmp string -- 4566 considers
>> the fmtp string to be none of its business.  The problem is that
>> different implementers may make different assumptions about the grammar
>> for the fmtp line.  Perhaps I've missed something...
>

Aha.  Missed that this time (I knew I'd read that semicolons were required
somewhere, but I only searched 4566 this time).

My real point was that existing implementations used parameters (with the
same names as the ones in 4629), so the statement in 4629 that older
implementations will ignore 4629 parameters is false, and the older
implementations of h263, h263-1998 and h263-2000 often (usually?) use
spaces instead of semicolons as delimiters will cause odd interoperability
problems if someone insists on semicolons when parsing (and I suspect that
some existing implementations insist on spaces, though I have no proof of
that yet).

>The legal syntax of a media type string is specified in the MIME  RFCs,
>which are included by reference via a citation to RFC 3555.

>From RFC 4288 referenced by RFC 4566:

   There is no defined syntax for parameter values.  Therefore
   registrations MUST specify parameter value syntax.  Additionally,
   some transports impose restrictions on parameter value syntax, so
   care should be taken to limit the use of potentially problematic
   syntaxes; e.g., pure binary valued parameters, while permitted in
   some protocols, probably should be avoided.

   New parameters SHOULD NOT be defined as a way to introduce new
   functionality in types registered in the standards tree, although new
   parameters MAY be added to convey additional information that does
   not otherwise change existing functionality.  An example of this
   would be a "revision" parameter to indicate a revision level of an
   external specification such as JPEG.  Similar behavior is encouraged
   for media types registered in the vendor or personal trees but is not
   required.

The paragraph from RFC 4629 section 8.2 may cover the first paragraph
above, though I'd have expected something more descriptive of the syntax.
Witness this from 4629 - where is this syntax specified except in the
example?

      "P": Reference Picture Resampling, in which the following submodes
      are represented as a number from 1 to 4:

      1: dynamicPictureResizingByFour
      2: dynamicPictureResizingBySixteenthPel
      3: dynamicWarpingHalfPel
      4: dynamicWarpingSixteenthPel

      Example: P=1,3

The second paragraph from RFC 4288 would seem to be violated by RFC 4629.

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 9 Sep 2007 10:55:06 +0300

Randell,
I am confused.
RFC 3555 registered the payload type for H263-1998 and H263-2000. 
The only optional parameters specified were profile and level for
H263-2000 payload type.
So the statement in RFC 4629 about no older parameters is correct.
If you claim that there are other optional parameters for H263-1998
please point me to such a document.
There was an early revision of draft-ietf-avt-rfc2429-bis that became
RFC 4629 that by mistake listed space separated list of parameters
instead of semicolon-separated as specified in RFC3555.

As for you second comment about the "P" parameter I do not understand
your concerns. 
RFC 4288 is a BCP for media type registration. I assume that in AVT we
follow it but also follow RFC 3555

Roni Even

> -----Original Message-----
> From: Randell Jesup [mailto:[email-masked]]
> Sent: Saturday, September 08, 2007 5:03 PM
> To: Colin Perkins
> Cc: Regis Crinon; Franceschini Guido; Gary Sullivan; [email-masked];
Walid
> Ali; Paltro Pier Carlo
> Subject: Re: [AVT] Interop issue with H263-1998
> 
> >> particular resolution and MPI), in contradiction of RFC 4629
section
> 9.1
RFCs,
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team
> [email-masked]
> "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."

---

From: Randell Jesup <[email-masked]>
Date: Sun, 09 Sep 2007 10:46:50 -0400

>please point me to such a document.

No document.  My point was that many implementations use parameters
with H263, H263-1998, and H263-2000 in ways incompatible with RFC 4629.
4629 stated that older implementations will ignore these parameters.
Many (most?) won't.  I agree older *standards* don't include them, and
older implementations would ignore them *if* they strictly implemented
the older standard with no additions.  And yes, they use these parameters
with video/H263, not just H263-1998 and 2000 (though in theory that
wouldn't impact RFC 4629's statement, since it only updates 1998 and 2000).

>instead of semicolon-separated as specified in RFC3555.

Perhaps that's what they all implemented.  But I suspect (no proof) the
mistake may have been an codifying of existing usage, which got removed
from the draft - and that causes potential interoperability problems.

...
>>       Example: P=1,3

Without the example I would never have known that it's a comma-separated
list (I assume).  Are spaces allowed?  Who knows.  Per rfc 4288: 

>>    registrations MUST specify parameter value syntax.

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 10 Sep 2007 10:46:46 +0300

Randell,
At least in the video conferencing market who is the major user of those
parameters I am not aware of such problems except for the usage of the
optional parameters with the H263 payload type but this is not causing
interop problems for those who ignore the parameters as you pointed.

As for you comment on "P" I agree that it is not specified and that
there is only an example, we may fix it when we go to draft standard
based on common usage in shipping products.

Anyhow we will need to review which parameters are actually used in SDP
based system.

Roni

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
A consensus means that everyone agrees to say collectively what no one
believes individually
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
> Sent: Sunday, September 09, 2007 5:47 PM
> To: Even, Roni
> Cc: Colin Perkins; Regis Crinon; Franceschini Guido; Gary Sullivan;
> [email-masked]; Walid Ali; Paltro Pier Carlo
> >> >> (which says that old implementations will ignore these
parameters).
> >> For
> >> >> it assumes silently (based on other RFCs one assumes) that
they'll
> >be
> >> My real point was that existing implementations used parameters
(with
> >> problems if someone insists on semicolons when parsing (and I
suspect
> >that
> >> some existing implementations insist on spaces, though I have no
proof
> >of
Additionally,
> >>    functionality in types registered in the standards tree,
although
> >new
> >>    for media types registered in the vendor or personal trees but
is
> >not
OS
the
from

---

From: "Franceschini Guido" <[email-masked]>
Date: Mon, 10 Sep 2007 10:52:25 +0200

Thanks to all for the replies.

My understanding is that:
- RFC 2429 specified an RTP payload format for H263+ but did not define how to use it in SDP
- in the Hxxx world, H.245 defined mechanisms to negotiate the H263+ encoding features to be used on top of the payload format specified in RFC 2429
- RFC 3551 assigned the mime type H263-1998 to the payload format specified in RFC 2429, but no optional parameters. From now on it is possible to negotiate H263-1998 using SDP

At this point, in my opinion, any H263+ encoding on top of the H263-1998 payload format is allowed from the RTP/SDP perspective.
>From the codec perspective however there are constraints on the combination of the various encoding tools, as Gary states:
> However, I am
> >optional features in a bitstream using SDP before RFC 4629.

Nevertheless, it is possible to send some form of H263+, i.e. more than pure Baseline H263, on top of the H263-1998 payload format.

Hence, my initial concern with RFC 4629 $8.1.1 still holds.

Best regards
Guido

> Sent: sabato 8 settembre 2007 5.20
> To: Gary Sullivan
> Cc: Franceschini Guido; [email-masked]; Paltro Pier Carlo; Regis Crinon;
> Walid Ali
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 10 Sep 2007 12:09:20 +0300

Guido,
I have to agree that systems that tried to use the payload type H263-1998 before RFC 4629 may send any annexes available in H.263+, not all of them since that may be not feasible. So it was really un-specified before RFC 4629. 

The big motivation for RFC 4629 was because the video conferencing manufacturers, who were the major users of H.263+ were trying to support SIP (Moving from H.263) and ran into SDP problems.

When writing the draft, the assumption was that there were no real implementations using H.263-1998 but mostly H263 or H263-200 with profile and level optional options.

Roni 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
A consensus means that everyone agrees to say collectively what no one believes individually
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

> From: Franceschini Guido [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2007 6:49 PM
> To: [email-masked]
> Cc: Paltro Pier Carlo
> Subject: [AVT] Interop issue with H263-1998
> 
> Dear all,
> 
> I have an issue with the definition of the H263-1998 media type.
> In the RFC 2429, no optional parameters are defined, implying that any
> valid H263+ stream could be streamed.
> In the RFC 4629, that obsoletes 2429, various optional parameters are
> specified, which allow specifying the (decoder) support to the various
> annexes.
> 
> What confuses me is the following statement in RFC 4629, concerning H263-
> 1998
> 
>    Interoperability considerations:
> 
>       These are receiver options; current implementations will not send
>       any optional parameters in their SDP.  They will ignore the
>       optional parameters and will *** encode the H.263 stream without any
> ***
>       of the annexes.  Most decoders support at least QCIF and CIF fixed
>       resolutions, and they are expected to be available almost in every
>       H.263-based video application.
> 
> Indeed my understanding would be quite different, and I would have written
> instead:
> 
>       These are receiver options; current implementations will not send
>       any optional parameters in their SDP.  They will ignore the
>       optional parameters and will *** encode the H.263+ stream with
> possibly all ***
>       of the annexes.  Most decoders support at least QCIF and CIF fixed
>       resolutions, and they are expected to be available almost in every
>       H.263-based video application.
> 
> 
> Any clarification would be welcomed
> 
> Best regards
> Guido Franceschini
> This message and its attachments are addressed solely to the persons above
> and may contain confidential information. If you have received the message
> in error, be informed that any use of the content hereof is prohibited.
> Please return it immediately to the sender and delete the message. Should
> you have any questions, please contact us by replying to
> [email-masked].
> 
>         Thank you
> 
>                                         www.telecomitalia.it
>

---

From: "Franceschini Guido" <[email-masked]>
Date: Mon, 10 Sep 2007 12:41:29 +0200

Thanks for the background.

Actually I was analyzing an interop issue where one terminal generates H263+ using H263-1998 with no FMTP line, while the other assumes no H263+ annexes are being used and so raises an error on reception of H263+ syntax.
I was trying to understand which of the two terminals is compliant to the RFCs rules, and ... hitted into the problem :(

My conclusion is that it is legitimate to generate H263+ syntax when H263-1998 has been negotiated and no FMTP line has been provided, and that paragraph 8.1.1 of RFC 4629 is inaccurate.

Best regards
Guido

> From: Even, Roni [mailto:[email-masked]]
> Sent: lunedì 10 settembre 2007 11.09
> To: Franceschini Guido; [email-masked]
> Cc: Paltro Pier Carlo
> Subject: RE: [AVT] Interop issue with H263-1998
> 
> 
> Guido,
> I have to agree that systems that tried to use the payload 
> type H263-1998 before RFC 4629 may send any annexes available 
> in H.263+, not all of them since that may be not feasible. So 
> it was really un-specified before RFC 4629. 
> 
> The big motivation for RFC 4629 was because the video 
> conferencing manufacturers, who were the major users of 
> H.263+ were trying to support SIP (Moving from H.263) and ran 
> into SDP problems.
> 
> When writing the draft, the assumption was that there were no 
> real implementations using H.263-1998 but mostly H263 or 
> H263-200 with profile and level optional options.
> 
> Roni 
> 
> > From: Franceschini Guido 
> [mailto:[email-masked]]

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 10 Sep 2007 13:49:05 +0300

Guido,
I think that the conclusion is that there is no interoperability if you use H263-1998 payload without the optional parameters. Still I would expect such terminals to send baseline H.263 since otherwise they cannot know if the receiver support any of the optional H.263 annexes
Roni 

> Sent: Monday, September 10, 2007 1:41 PM
> To: Even, Roni; [email-masked]
> Cc: Paltro Pier Carlo
> Actually I was analyzing an interop issue where one terminal generates
> H263+ using H263-1998 with no FMTP line, while the other assumes no H263+
> annexes are being used and so raises an error on reception of H263+
> syntax.
> I was trying to understand which of the two terminals is compliant to the
> RFCs rules, and ... hitted into the problem :(
> 
> My conclusion is that it is legitimate to generate H263+ syntax when H263-
> 1998 has been negotiated and no FMTP line has been provided, and that
> paragraph 8.1.1 of RFC 4629 is inaccurate.
> 
> Best regards
> Guido
> 
>

---

From: "Franceschini Guido" <[email-masked]>
Date: Mon, 10 Sep 2007 14:38:46 +0200

Actually, you are right.

Indeed, since we have now both the (obsoleted) RFC 2429 and RFC 4629 that specify differently how to deal with an empty FMTP, ... yes, we have no interoperability for this case.

Best regards
Guido

> Sent: lunedì 10 settembre 2007 12.49
> I think that the conclusion is that there is no 
> interoperability if you use H263-1998 payload without the 
> optional parameters. Still I would expect such terminals to 
> send baseline H.263 since otherwise they cannot know if the 
> receiver support any of the optional H.263 annexes
> Roni 
> 
> 

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it