Skip to main content

RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)
draft-ietf-fecframe-interleaved-fec-scheme-09

Revision differences

Document history

Date Rev. By Action
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Robert Sparks
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-01-19
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-01-15
09 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-01-15
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-01-15
09 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-01-15
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-01-15
09 (System) IANA Action state changed to In Progress
2010-01-15
09 Amy Vezza IESG state changed to Approved-announcement sent
2010-01-15
09 Amy Vezza IESG has approved the document
2010-01-15
09 Amy Vezza Closed "Approve" ballot
2010-01-15
09 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2010-01-14
09 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Undefined by Robert Sparks
2010-01-14
09 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to Undefined from Discuss by Robert Sparks
2010-01-13
09 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2010-01-12
09 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-09.txt
2010-01-11
09 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2010-01-11
09 Alexey Melnikov
[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 …
[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".
2010-01-11
09 Alexey Melnikov [Ballot discuss]
2010-01-08
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-01-08
08 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-08.txt
2010-01-08
09 (System) Removed from agenda for telechat - 2010-01-07
2010-01-07
09 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-01-07
09 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from No Objection by Cullen Jennings
2010-01-07
09 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2010-01-07
09 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2010-01-07
09 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-01-07
09 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2010-01-06
09 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2010-01-06
09 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2010-01-06
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2010-01-06
09 Russ Housley
[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 …
[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.
2010-01-06
09 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2010-01-05
09 Robert Sparks [Ballot comment]
Would it make sense to explain the relationship of this document and 5109
(which obsoleted 2733 and 3009) in section 1.3?
2010-01-05
09 Robert Sparks
[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 …
[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?
2010-01-05
09 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks
2010-01-05
09 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-01-04
09 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2010-01-04
09 Alexey Melnikov
[Ballot comment]
Comments from ietf-types review (see ):

>>  o  rate:  The RTP timestamp (clock) rate.  The rate SHALL be larger
>>      than …
[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".
2010-01-04
09 Alexey Melnikov
[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 …
[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.
2010-01-04
09 Alexey Melnikov [Ballot comment]
Can you please check if registration fields specified in Section 4.11 of RFC 4288 need to be added to registration templates?
2010-01-04
09 Alexey Melnikov
[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 …
[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.
2010-01-04
09 Alexey Melnikov The media type review request can be seen at
2010-01-03
09 Alexey Melnikov [Ballot comment]
Can you please check if registration fields specified in Section 4.11 of RFC 4288 need to be added to registration templates?
2010-01-03
09 Alexey Melnikov
[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 …
[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.
2010-01-03
09 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2010-01-02
09 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2010-01-01
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-12-21
07 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-07.txt
2009-12-16
09 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2009-12-16
09 Magnus Westerlund Ballot has been issued by Magnus Westerlund
2009-12-16
09 Magnus Westerlund Created "Approve" ballot
2009-12-16
09 Magnus Westerlund Need to check result of media types review.
2009-12-16
09 Magnus Westerlund Placed on agenda for telechat - 2010-01-07 by Magnus Westerlund
2009-12-16
09 Magnus Westerlund State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Magnus Westerlund
2009-12-15
06 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-06.txt
2009-12-14
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-12-11
09 Amanda Baber IANA comments:

Upon approval of this document, IANA will register the following media
types at
http://www.iana.org/assignments/media-types/

audio/1d-interleaved-parityfec
video/1d-interleaved-parityfec
text/1d-interleaved-parityfec
application/1d-interleaved-parityfec
2009-12-09
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Tero Kivinen.
2009-12-03
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tero Kivinen
2009-12-03
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tero Kivinen
2009-11-30
09 Amy Vezza Last call sent
2009-11-30
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-11-30
09 Magnus Westerlund State Changes to Last Call Requested from AD Evaluation by Magnus Westerlund
2009-11-30
09 Magnus Westerlund Last Call was requested by Magnus Westerlund
2009-11-30
09 (System) Ballot writeup text was added
2009-11-30
09 (System) Last call text was added
2009-11-30
09 (System) Ballot approval text was added
2009-11-30
09 Magnus Westerlund State Changes to AD Evaluation from Publication Requested by Magnus Westerlund
2009-11-30
09 Magnus Westerlund [Note]: 'Greg Shepherd <gjshep@gmail.com> is the document shepherd.' added by Magnus Westerlund
2009-10-22
09 Cindy Morgan [Note]: 'Greg Shepherd  is the document shepherd.' added by Cindy Morgan
2009-10-22
09 Cindy Morgan
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) …
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
2009-10-22
09 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-05-05
05 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-05.txt
2009-04-29
04 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-04.txt
2009-04-18
03 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-03.txt
2009-03-08
02 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-02.txt
2008-10-28
01 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-01.txt
2008-08-30
00 (System) New version available: draft-ietf-fecframe-interleaved-fec-scheme-00.txt