Re: [AVT] Interop issue with H263-1998

[Randell Jesup <rjesup at wgate.com>]

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)


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt