RE: [AVT] Interop issue with H263-1998

["Even, Roni" <roni.even at polycom.co.il>]

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
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: Sunday, September 09, 2007 5:47 PM
> To: Even, Roni
> Cc: Colin Perkins; Regis Crinon; Franceschini Guido; Gary Sullivan;
> avt at ietf.org; Walid Ali; Paltro Pier Carlo
> Subject: Re: [AVT] Interop issue with H263-1998
> 
> "Even, Roni" <roni.even at polycom.co.il> writes:
> >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.
> 
> 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).
> 
> >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.
> 
> 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.
> 
> >As for you second comment about the "P" parameter I do not understand
> >your concerns.
> 
> There's no syntax specifed for the apparent combination of values:
> 
> >>       "P": Reference Picture Resampling, in which the following
> submodes
> >>       are represented as a number from 1 to 4:
> ...
> >>       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:
> 
> >> >From RFC 4288 referenced by RFC 4566:
> >>
> >>    There is no defined syntax for parameter values.  Therefore
> >>    registrations MUST specify parameter value syntax.
> 
> 
> >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:rjesup at wgate.com]
> >> Sent: Saturday, September 08, 2007 5:03 PM
> >> To: Colin Perkins
> >> Cc: Regis Crinon; Franceschini Guido; Gary Sullivan; avt at ietf.org;
> >Walid
> >> Ali; Paltro Pier Carlo
> >> Subject: Re: [AVT] Interop issue with H263-1998
> >>
> >> >> 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...
> >> >
> >> >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.
> >>
> >> 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.
> >>
> >> --
> >> 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
> 
> 
> --
> 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