RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)
RFC 6015

[Ballot comment]
After Magnus explained limitation of SDP regarding use of MIME types (the same top level MIME type has to be used for all media streams), I remove my DISCUSS about registration of text/1d-interleaved-parityfec.
I wish SDP didn't have this limitation, but not much I can do about that anyway.


Comments from ietf-types review (see ):

>>  o  rate:  The RTP timestamp (clock) rate.  The rate SHALL be larger
>>      than 1000 Hz to provide sufficient resolution to RTCP operations.
>>      However, it is RECOMMENDED to select the rate that matches the
>>      rate of the protected source RTP stream.
>
> I am not sure from this what the syntax is, the text makes it sound
> like rate="1001 Hz" might be it. Perhaps something like "The RTP time-
> stamp (clock) rate in Hz. The rate SHALL be larger than 1000 ..." to
> make it clearer. Alternatively "an integer ..." like some of the other
> parameters say.

Magnus replied: Yes, I would agree, because the value is just the integer "rate=1001".

[Ballot discuss]
Spencer Dawkins provided a Gen-ATR Review on 2010-01-05.  The
  authors agreed to make several changes based on these comments,
  but the updated document has not been posted yet.

[Ballot discuss]
There is a conflict between what RFC3550 requires and
what this draft is specifying for the use of the P, X,
and CC fields in the RTP header.

In particular, a 3550-compliant implementation that needs
to discard a packet constructed according to this document
is going to look for padding to discard if the P bit is
set, at least one extension if the X bit is set, and a CSRC
list if CC is not zero. The semantics of these fields are
not subordinate to the contents of PT.

I understand (from a short conversation with Ali), there is
some history from RFC2733, and an installed base of
implementations to take into account in the resolution of
this conflict. Can we find a way to scope this document so
that we're not creating a non-backward-compatible update of
3550?

[Ballot comment]
Comments from ietf-types review (see ):

>>  o  rate:  The RTP timestamp (clock) rate.  The rate SHALL be larger
>>      than 1000 Hz to provide sufficient resolution to RTCP operations.
>>      However, it is RECOMMENDED to select the rate that matches the
>>      rate of the protected source RTP stream.
>
> I am not sure from this what the syntax is, the text makes it sound
> like rate="1001 Hz" might be it. Perhaps something like "The RTP time-
> stamp (clock) rate in Hz. The rate SHALL be larger than 1000 ..." to
> make it clearer. Alternatively "an integer ..." like some of the other
> parameters say.

Magnus replied: Yes, I would agree, because the value is just the integer "rate=1001".

[Ballot discuss]
1). Is the registration of text/1d-interleaved-parityfec truly necessary? I would like to see some examples of how this is going to be used and some justification of why the resulting media type can still be considered textual.

[Ballot discuss]
1). Is the registration of text/1d-interleaved-parityfec truly necessary? I would like to see some examples of how this is going to be used and some justification of why the resulting media type can still be considered textual.

[Ballot discuss]
1). This part of the DISCUSS is a process DISCUSS.
I couldn't find the following information in the document write-up:

Were the new MIME types submitted to the ietf-types mailing list for review (see )?
If yes, please send me the corresponding mailing list archive URL.
If not, please submit the MIME type registrations to the ietf-types@ mailing list and CC me.

2). Is the registration of text/1d-interleaved-parityfec truly necessary? I would like to see some examples of how this is going to be used and some justification of why the resulting media type can still be considered textual.

1.a) The Document Shepherd is Greg Shepherd

1.b) The document has had adequate review both from within and from
outside the FECFrame working group.

1.c) There are no concerns regarding the need for additional expanded review.

1.d) There are no specific concerns with this document

1.e) There is solid WG consensus for this document.

1.f) There is no discontent.

1.g) The idnits are minor and I don't feel warrant a rev of the
document and the associated process. I believe we should handle the
edits as publication notes. The relevant nit output being:

** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856)

The normative reference to RFC 3555 should be updated to RFC 4855,
RFC 4856 as suggested.

There is a reference to draft-ietf-fecframe-dvb-al-fec-01 though the
latest rev of that draft is 03. This will be updated before
publication with the correct RFC number.

The other nit issues regarding informational references to RFC 2733
and RFC 3009 can be ignored as these obsolete references are
intentional.


1.h) All references are split between normative and informative. There
is one informative reference to a draft in the FECFrame WG that is
also in the process of progressing to last-call:
draft-ietf-fecframe-dvb-al-fec

1.i) The IANA consideration section exists and is consistent with the
body of the document. The required IANA registries are clearly defined
in the document.

1.j) The xml code validates correctly

1.k)

Technical Summary
This document defines a new RTP payload format for the Forward Error
Correction that is generated by the 1-D interleaved parity code from a
source media encapsulated in RTP. The 1-D interleaved parity code is a
systematic code, where a number of repair symbols are generated from a
set of source symbols and sent in a repair flow separate from the
source flow that carries the source symbols. The new payload format
defined in this document is used (with some exceptions) as part of the
DVB Application-layer FEC specification.

Working Group Summary
There were no seriously contentious issues during the WG process. The
only controversy stemmed from some individuals who did the work in
SMPTE and didn't want the IETF redefining their work. But the problem
is that RFC 2733 did not protect some fields in the header and SMPTE
was based on RFC 2733. SMTPE spec also made mistakes with SSRC, CSRC
and timestamps which are corrected in this document. Additionally, RTP
validity checks fail in RPF 2733/SMTPE specs.

Document Quality
Current implementations follow SMTPE and not yet this specification.

Personal
Document Shepherd - Greg Shepherd
Responsible Area Director - TBD