[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Interop issue with H263-1998
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
> >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.
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
> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: sabato 8 settembre 2007 5.20
> To: Gary Sullivan
> Cc: Franceschini Guido; avt at ietf.org; Paltro Pier Carlo; Regis Crinon;
> Walid Ali
> Subject: Re: [AVT] Interop issue with H263-1998
>
>
> Gary Sullivan <garysull at windows.microsoft.com> writes:
> >RFC 2429 did not have any SDP specification in it (in fact the string
> >"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
> 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)
>
>
--------------------------------------------------------------------
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 webmaster at telecomitalia.it.
Thank you
www.telecomitalia.it
--------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt