draft-ietf-fecframe-interleaved-fec-scheme-03.txt   draft-ietf-fecframe-interleaved-fec-scheme-04.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track April 18, 2009 Intended status: Standards Track April 29, 2009
Expires: October 20, 2009 Expires: October 31, 2009
RTP Payload Format for 1-D Interleaved Parity FEC RTP Payload Format for 1-D Interleaved Parity FEC
draft-ietf-fecframe-interleaved-fec-scheme-03 draft-ietf-fecframe-interleaved-fec-scheme-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 20, 2009. This Internet-Draft will expire on October 31, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 43 skipping to change at page 3, line 43
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 22 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 22
6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 24 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 24
6.3.1. Associating the Source and Repair Packets . . . . . . 24 6.3.1. Associating the Source and Repair Packets . . . . . . 24
6.3.2. Recovering the RTP Header and Payload . . . . . . . . 25 6.3.2. Recovering the RTP Header and Payload . . . . . . . . 25
7. Session Description Protocol (SDP) Signaling . . . . . . . . . 26 7. Session Description Protocol (SDP) Signaling . . . . . . . . . 26
8. Congestion Control Considerations . . . . . . . . . . . . . . 27 8. Congestion Control Considerations . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. draft-ietf-fecframe-interleaved-fec-scheme-03 . . . . . . 28 12.1. draft-ietf-fecframe-interleaved-fec-scheme-04 . . . . . . 29
12.2. draft-ietf-fecframe-interleaved-fec-scheme-02 . . . . . . 29 12.2. draft-ietf-fecframe-interleaved-fec-scheme-03 . . . . . . 29
12.3. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 29 12.3. draft-ietf-fecframe-interleaved-fec-scheme-02 . . . . . . 29
12.4. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 29 12.4. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.5. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . . 29 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . . 30 13.2. Informative References . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document extends the Forward Error Correction (FEC) header This document extends the Forward Error Correction (FEC) header
defined in [RFC2733] and uses this new FEC header for the FEC that is defined in [RFC2733] and uses this new FEC header for the FEC that is
generated by the 1-D interleaved parity code from a source media generated by the 1-D interleaved parity code from a source media
encapsulated in RTP [RFC3550]. The resulting new RTP payload format encapsulated in RTP [RFC3550]. The resulting new RTP payload format
is registered by this document. is registered by this document.
skipping to change at page 15, line 29 skipping to change at page 15, line 29
This section provides the media subtype registration for the 1-D This section provides the media subtype registration for the 1-D
interleaved parity FEC. The parameters that are required to interleaved parity FEC. The parameters that are required to
configure the FEC encoding and decoding operations are also defined configure the FEC encoding and decoding operations are also defined
in this section. in this section.
5.1. Media Type Registration 5.1. Media Type Registration
This registration is done using the template defined in [RFC4288] and This registration is done using the template defined in [RFC4288] and
following the guidance provided in [RFC3555]. following the guidance provided in [RFC3555].
Note to the RFC Editor: In the following sections, please replace
"XXXX" with the number of this document prior to publication as an
RFC.
5.1.1. Registration of audio/1d-interleaved-parityfec 5.1.1. Registration of audio/1d-interleaved-parityfec
Type name: audio Type name: audio
Subtype name: 1d-interleaved-parityfec Subtype name: 1d-interleaved-parityfec
Required parameters: Required parameters:
o rate: The RTP timestamp (clock) rate. The rate SHALL be larger o rate: The RTP timestamp (clock) rate. The rate SHALL be larger
than 1000 Hz to provide sufficient resolution to RTCP operations. than 1000 Hz to provide sufficient resolution to RTCP operations.
skipping to change at page 16, line 16 skipping to change at page 16, line 21
is no issue of delay variation, the FEC decoder SHOULD NOT wait is no issue of delay variation, the FEC decoder SHOULD NOT wait
longer than the repair window since additional waiting would not longer than the repair window since additional waiting would not
help the recovery process. The size of the repair window is help the recovery process. The size of the repair window is
specified in microseconds. specified in microseconds.
Optional parameters: None. Optional parameters: None.
Encoding considerations: This media type is framed (See Section 4.8 Encoding considerations: This media type is framed (See Section 4.8
in the template document [RFC4288]) and contains binary data. in the template document [RFC4288]) and contains binary data.
Security considerations: See Section 9 of this document. Security considerations: See Section 9 of [RFCXXXX].
Interoperability considerations: None. Interoperability considerations: None.
Published specification: This document. Published specification: [RFCXXXX].
Applications that use this media type: Multimedia applications that Applications that use this media type: Multimedia applications that
want to improve resiliency against packet loss by sending redundant want to improve resiliency against packet loss by sending redundant
data in addition to the source media. data in addition to the source media.
Additional information: None. Additional information: None.
Person & email address to contact for further information: Ali Begen Person & email address to contact for further information: Ali Begen
<abegen@cisco.com> and IETF Audio/Video Transport Working Group. <abegen@cisco.com> and IETF Audio/Video Transport Working Group.
Intended usage: COMMON. Intended usage: COMMON.
Restriction on usage: None. Restriction on usage: This media type depends on RTP framing, and
hence, is only defined for transport via RTP [RFC3550].
Author: Ali Begen <abegen@cisco.com>. Author: Ali Begen <abegen@cisco.com>.
Change controller: IETF Audio/Video Transport Working Group Change controller: IETF Audio/Video Transport Working Group
delegated from the IESG. delegated from the IESG.
5.1.2. Registration of video/1d-interleaved-parityfec 5.1.2. Registration of video/1d-interleaved-parityfec
Type name: video Type name: video
skipping to change at page 17, line 27 skipping to change at page 17, line 32
is no issue of delay variation, the FEC decoder SHOULD NOT wait is no issue of delay variation, the FEC decoder SHOULD NOT wait
longer than the repair window since additional waiting would not longer than the repair window since additional waiting would not
help the recovery process. The size of the repair window is help the recovery process. The size of the repair window is
specified in microseconds. specified in microseconds.
Optional parameters: None. Optional parameters: None.
Encoding considerations: This media type is framed (See Section 4.8 Encoding considerations: This media type is framed (See Section 4.8
in the template document [RFC4288]) and contains binary data. in the template document [RFC4288]) and contains binary data.
Security considerations: See Section 9 of this document. Security considerations: See Section 9 of [RFCXXXX].
Interoperability considerations: None. Interoperability considerations: None.
Published specification: This document. Published specification: [RFCXXXX].
Applications that use this media type: Multimedia applications that Applications that use this media type: Multimedia applications that
want to improve resiliency against packet loss by sending redundant want to improve resiliency against packet loss by sending redundant
data in addition to the source media. data in addition to the source media.
Additional information: None. Additional information: None.
Person & email address to contact for further information: Ali Begen Person & email address to contact for further information: Ali Begen
<abegen@cisco.com> and IETF Audio/Video Transport Working Group. <abegen@cisco.com> and IETF Audio/Video Transport Working Group.
Intended usage: COMMON. Intended usage: COMMON.
Restriction on usage: None. Restriction on usage: This media type depends on RTP framing, and
hence, is only defined for transport via RTP [RFC3550].
Author: Ali Begen <abegen@cisco.com>. Author: Ali Begen <abegen@cisco.com>.
Change controller: IETF Audio/Video Transport Working Group Change controller: IETF Audio/Video Transport Working Group
delegated from the IESG. delegated from the IESG.
5.1.3. Registration of text/1d-interleaved-parityfec 5.1.3. Registration of text/1d-interleaved-parityfec
Type name: text Type name: text
skipping to change at page 18, line 40 skipping to change at page 18, line 43
is no issue of delay variation, the FEC decoder SHOULD NOT wait is no issue of delay variation, the FEC decoder SHOULD NOT wait
longer than the repair window since additional waiting would not longer than the repair window since additional waiting would not
help the recovery process. The size of the repair window is help the recovery process. The size of the repair window is
specified in microseconds. specified in microseconds.
Optional parameters: None. Optional parameters: None.
Encoding considerations: This media type is framed (See Section 4.8 Encoding considerations: This media type is framed (See Section 4.8
in the template document [RFC4288]) and contains binary data. in the template document [RFC4288]) and contains binary data.
Security considerations: See Section 9 of this document. Security considerations: See Section 9 of [RFCXXXX].
Interoperability considerations: None. Interoperability considerations: None.
Published specification: This document. Published specification: [RFCXXXX].
Applications that use this media type: Multimedia applications that Applications that use this media type: Multimedia applications that
want to improve resiliency against packet loss by sending redundant want to improve resiliency against packet loss by sending redundant
data in addition to the source media. data in addition to the source media.
Additional information: None. Additional information: None.
Person & email address to contact for further information: Ali Begen Person & email address to contact for further information: Ali Begen
<abegen@cisco.com> and IETF Audio/Video Transport Working Group. <abegen@cisco.com> and IETF Audio/Video Transport Working Group.
Intended usage: COMMON. Intended usage: COMMON.
Restriction on usage: None. Restriction on usage: This media type depends on RTP framing, and
hence, is only defined for transport via RTP [RFC3550].
Author: Ali Begen <abegen@cisco.com>. Author: Ali Begen <abegen@cisco.com>.
Change controller: IETF Audio/Video Transport Working Group Change controller: IETF Audio/Video Transport Working Group
delegated from the IESG. delegated from the IESG.
5.1.4. Registration of application/1d-interleaved-parityfec 5.1.4. Registration of application/1d-interleaved-parityfec
Type name: application Type name: application
skipping to change at page 19, line 50 skipping to change at page 20, line 6
is no issue of delay variation, the FEC decoder SHOULD NOT wait is no issue of delay variation, the FEC decoder SHOULD NOT wait
longer than the repair window since additional waiting would not longer than the repair window since additional waiting would not
help the recovery process. The size of the repair window is help the recovery process. The size of the repair window is
specified in microseconds. specified in microseconds.
Optional parameters: None. Optional parameters: None.
Encoding considerations: This media type is framed (See Section 4.8 Encoding considerations: This media type is framed (See Section 4.8
in the template document [RFC4288]) and contains binary data. in the template document [RFC4288]) and contains binary data.
Security considerations: See Section 9 of this document. Security considerations: See Section 9 of [RFCXXXX].
Interoperability considerations: None. Interoperability considerations: None.
Published specification: This document. Published specification: [RFCXXXX].
Applications that use this media type: Multimedia applications that Applications that use this media type: Multimedia applications that
want to improve resiliency against packet loss by sending redundant want to improve resiliency against packet loss by sending redundant
data in addition to the source media. data in addition to the source media.
Additional information: None. Additional information: None.
Person & email address to contact for further information: Ali Begen Person & email address to contact for further information: Ali Begen
<abegen@cisco.com> and IETF Audio/Video Transport Working Group. <abegen@cisco.com> and IETF Audio/Video Transport Working Group.
Intended usage: COMMON. Intended usage: COMMON.
Restriction on usage: None. Restriction on usage: This media type depends on RTP framing, and
hence, is only defined for transport via RTP [RFC3550].
Author: Ali Begen <abegen@cisco.com>. Author: Ali Begen <abegen@cisco.com>.
Change controller: IETF Audio/Video Transport Working Group Change controller: IETF Audio/Video Transport Working Group
delegated from the IESG. delegated from the IESG.
5.2. Mapping to SDP Parameters 5.2. Mapping to SDP Parameters
Applications that are using RTP transport commonly use Session Applications that are using RTP transport commonly use Session
Description Protocol (SDP) [RFC4566] to describe their RTP sessions. Description Protocol (SDP) [RFC4566] to describe their RTP sessions.
skipping to change at page 21, line 39 skipping to change at page 21, line 44
o Although combinations with the same L and D values but with o Although combinations with the same L and D values but with
different repair-window sizes produce the same FEC data, such different repair-window sizes produce the same FEC data, such
combinations are still considered different offers. The size of combinations are still considered different offers. The size of
the repair-window is related to how fast the sender will send the the repair-window is related to how fast the sender will send the
repair packets. This directly impacts the buffering requirement repair packets. This directly impacts the buffering requirement
on the receiver side and the receiver must consider this when on the receiver side and the receiver must consider this when
choosing an offer. choosing an offer.
o There are no optional format parameters defined for this payload. o There are no optional format parameters defined for this payload.
Any unknown option in the offer MUST be ignored and deleted from Any unknown option in the offer MUST be ignored and deleted from
the answer. the answer. If FEC is not desired by the receiver, it can be
deleted from the answer.
5.2.2. Declarative Considerations 5.2.2. Declarative Considerations
In declarative usage, like SDP in the Real-time Streaming Protocol In declarative usage, like SDP in the Real-time Streaming Protocol
(RTSP) [RFC2326] or the Session Announcement Protocol (SAP) (RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
[RFC2974], the following considerations apply: [RFC2974], the following considerations apply:
o The payload format configuration parameters are all declarative o The payload format configuration parameters are all declarative
and a participant MUST use the configuration that is provided for and a participant MUST use the configuration that is provided for
the session. the session.
skipping to change at page 28, line 45 skipping to change at page 29, line 7
11. Acknowledgments 11. Acknowledgments
A major part of this document is borrowed from [RFC2733] and A major part of this document is borrowed from [RFC2733] and
[SMPTE2022-1]. Thus, the author would like to thank the authors and [SMPTE2022-1]. Thus, the author would like to thank the authors and
editors of these earlier specifications. The author also thanks editors of these earlier specifications. The author also thanks
Colin Perkins for his constructive suggestions for this document. Colin Perkins for his constructive suggestions for this document.
12. Change Log 12. Change Log
12.1. draft-ietf-fecframe-interleaved-fec-scheme-03 12.1. draft-ietf-fecframe-interleaved-fec-scheme-04
The following are the major changes compared to version 03:
o Further comments from AVT WG have been addressed.
12.2. draft-ietf-fecframe-interleaved-fec-scheme-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o Comments from WGLC have been addressed. o Comments from WGLC have been addressed.
12.2. draft-ietf-fecframe-interleaved-fec-scheme-02 12.3. draft-ietf-fecframe-interleaved-fec-scheme-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o Some details were added regarding the use of CNAME field. o Some details were added regarding the use of CNAME field.
o Offer-Answer and Declarative Considerations sections have been o Offer-Answer and Declarative Considerations sections have been
completed. completed.
o Security Considerations section has been completed. o Security Considerations section has been completed.
12.3. draft-ietf-fecframe-interleaved-fec-scheme-01 12.4. draft-ietf-fecframe-interleaved-fec-scheme-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o The timestamp field definition has changed. o The timestamp field definition has changed.
12.4. draft-ietf-fecframe-interleaved-fec-scheme-00 12.5. draft-ietf-fecframe-interleaved-fec-scheme-00
This is the initial version, which is based on an earlier individual This is the initial version, which is based on an earlier individual
submission. The following are the major changes compared to that submission. The following are the major changes compared to that
document: document:
o Per the discussion in the WG, references to the FEC Framework have o Per the discussion in the WG, references to the FEC Framework have
been removed and the document has been turned into a pure RTP been removed and the document has been turned into a pure RTP
payload format specification. payload format specification.
o A new section is added for congestion control considerations. o A new section is added for congestion control considerations.
 End of changes. 22 change blocks. 
28 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/