draft-ietf-fecframe-interleaved-fec-scheme-01.txt   draft-ietf-fecframe-interleaved-fec-scheme-02.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track October 27, 2008 Intended status: Standards Track March 7, 2009
Expires: April 30, 2009 Expires: September 8, 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-01 draft-ietf-fecframe-interleaved-fec-scheme-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 30, 2009. This Internet-Draft will expire on September 8, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document defines a new RTP payload format for the Forward Error This document defines a new RTP payload format for the Forward Error
Correction (FEC) that is generated by the 1-D interleaved parity code Correction (FEC) that is generated by the 1-D interleaved parity code
from a source media encapsulated in RTP. The 1-D interleaved parity from a source media encapsulated in RTP. The 1-D interleaved parity
code is a systematic code, where a number of repair symbols are 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 generated from a set of source symbols and sent in a repair flow
separate from the source flow that carries the source symbols. The separate from the source flow that carries the source symbols. The
1-D interleaved parity code offers a good protection against bursty 1-D interleaved parity code offers a good protection against bursty
skipping to change at page 2, line 27 skipping to change at page 3, line 25
3. Definitions, Notations and Abbreviations . . . . . . . . . . . 10 3. Definitions, Notations and Abbreviations . . . . . . . . . . . 10
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Source Packets . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Repair Packets . . . . . . . . . . . . . . . . . . . . . . 11
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14
5.1. Media Type Registration . . . . . . . . . . . . . . . . . 14 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 14
5.1.1. Registration of audio/1d-interleaved-parityfec . . . . 14 5.1.1. Registration of audio/1d-interleaved-parityfec . . . . 14
5.1.2. Registration of video/1d-interleaved-parityfec . . . . 15 5.1.2. Registration of video/1d-interleaved-parityfec . . . . 16
5.1.3. Registration of text/1d-interleaved-parityfec . . . . 17 5.1.3. Registration of text/1d-interleaved-parityfec . . . . 17
5.1.4. Registration of 5.1.4. Registration of
application/1d-interleaved-parityfec . . . . . . . . . 18 application/1d-interleaved-parityfec . . . . . . . . . 18
5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 19 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 19
5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 20 5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 20
5.2.2. Declarative Considerations . . . . . . . . . . . . . . 20 5.2.2. Declarative Considerations . . . . . . . . . . . . . . 21
6. Protection and Recovery Procedures . . . . . . . . . . . . . . 20 6. Protection and Recovery Procedures . . . . . . . . . . . . . . 21
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 20 6.2. Repair Packet Construction . . . . . . . . . . . . . . . . 21
6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 22 6.3. Source Packet Reconstruction . . . . . . . . . . . . . . . 23
6.3.1. Associating the Source and Repair Packets . . . . . . 23 6.3.1. Associating the Source and Repair Packets . . . . . . 24
6.3.2. Recovering the RTP Header and Payload . . . . . . . . 23 6.3.2. Recovering the RTP Header and Payload . . . . . . . . 24
7. Session Description Protocol (SDP) Signaling . . . . . . . . . 25 7. Session Description Protocol (SDP) Signaling . . . . . . . . . 26
8. Congestion Control Considerations . . . . . . . . . . . . . . 25 8. Congestion Control Considerations . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 26 12.1. draft-ietf-fecframe-interleaved-fec-scheme-02 . . . . . . 28
12.2. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 26 12.2. draft-ietf-fecframe-interleaved-fec-scheme-01 . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12.3. draft-ietf-fecframe-interleaved-fec-scheme-00 . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
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.
The type of the source media protected by the 1-D interleaved parity The type of the source media protected by the 1-D interleaved parity
skipping to change at page 11, line 27 skipping to change at page 11, line 27
and FEC-capable receivers to receive and interpret the same source and FEC-capable receivers to receive and interpret the same source
packets sent in the same multicast session. packets sent in the same multicast session.
4.2. Repair Packets 4.2. Repair Packets
The repair packets MUST contain information that identifies the The repair packets MUST contain information that identifies the
source block they pertain to and the relationship between the source block they pertain to and the relationship between the
contained repair symbols and the original source block. For this contained repair symbols and the original source block. For this
purpose, we use the RTP header of the repair packets as well as purpose, we use the RTP header of the repair packets as well as
another header within the RTP payload, which we refer to as the FEC another header within the RTP payload, which we refer to as the FEC
header, as shown in Figure 7. header, as shown in Figure 6.
+------------------------------+ +------------------------------+
| IP Header | | IP Header |
+------------------------------+ +------------------------------+
| Transport Header | | Transport Header |
+------------------------------+ +------------------------------+
| RTP Header | __ | RTP Header | __
+------------------------------+ | +------------------------------+ |
| FEC Header | \ | FEC Header | \
+------------------------------+ > RTP Payload +------------------------------+ > RTP Payload
| Repair Symbols | / | Repair Symbols | /
+------------------------------+ __| +------------------------------+ __|
Figure 7: Format of repair packets Figure 6: Format of repair packets
The RTP header is formatted according to [RFC3550] with some further The RTP header is formatted according to [RFC3550] with some further
clarifications listed below: clarifications listed below:
o Version: The version field is set to 2. o Version: The version field is set to 2.
o Padding (P) Bit: This bit is obtained by applying protection to o Padding (P) Bit: This bit is obtained by applying protection to
the corresponding P bits from the RTP headers of the source the corresponding P bits from the RTP headers of the source
packets protected by this repair packet. However, padding octets packets protected by this repair packet. However, padding octets
are never present in a repair packet, independent of the value of are never present in a repair packet, independent of the value of
skipping to change at page 12, line 47 skipping to change at page 12, line 47
o Timestamp (TS): The timestamp SHALL be set to a time o Timestamp (TS): The timestamp SHALL be set to a time
corresponding to the repair packet's transmission time. Note that corresponding to the repair packet's transmission time. Note that
the timestamp value has no use in the actual FEC protection the timestamp value has no use in the actual FEC protection
process and is usually useful for jitter calculations. process and is usually useful for jitter calculations.
o Synchronization Source (SSRC): The SSRC value SHALL be randomly o Synchronization Source (SSRC): The SSRC value SHALL be randomly
assigned as suggested by [RFC3550]. This allows the sender to assigned as suggested by [RFC3550]. This allows the sender to
multiplex the source and repair flows on the same port, or multiplex the source and repair flows on the same port, or
multiplex multiple repair flows on a single port. The repair multiplex multiple repair flows on a single port. The repair
flows SHOULD use the RTCP CNAME field to associate themselves with flows SHOULD use the RTCP CNAME field to associate themselves with
the source flow. Note that due to the randomness of the SSRC the source flow.
assignments, there is a possibility of SSRC collision. In such
cases, the collisions MUST be resolved as described in [RFC3550]. In some networks, the RTP Source, which produces the source
packets and the FEC Source, which generates the repair packets
from the source packets may not be the same host. In such
scenarios, using the same CNAME for the source and repair flows
means that the RTP Source and the FEC Source MUST share the same
CNAME (for this specific source-repair flow association). A
common CNAME may be produced based on an algorithm that is known
both to the RTP and FEC Source. This usage is compliant with
[RFC3550].
Note that due to the randomness of the SSRC assignments, there is
a possibility of SSRC collision. In such cases, the collisions
MUST be resolved as described in [RFC3550].
Note that the P bit, X bit, CC field and M bit of the source packets Note that the P bit, X bit, CC field and M bit of the source packets
are protected by the corresponding bits/fields in the RTP header of are protected by the corresponding bits/fields in the RTP header of
the repair packet. On the other hand, the payload of a repair packet the repair packet. On the other hand, the payload of a repair packet
protects the concatenation of (if present) the CSRC list, RTP protects the concatenation of (if present) the CSRC list, RTP
extension, payload and padding of the source RTP packets associated extension, payload and padding of the source RTP packets associated
with this repair packet. with this repair packet.
The FEC header is 16 octets. The format of the FEC header is shown The FEC header is 16 octets. The format of the FEC header is shown
in Figure 8. in Figure 7.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SN base low | Length recovery | | SN base low | Length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| PT recovery | Mask | |E| PT recovery | Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery | | TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|D|Type |Index| Offset | NA | SN base ext | |N|D|Type |Index| Offset | NA | SN base ext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of the FEC header Figure 7: Format of the FEC header
The FEC header consists of the following fields: The FEC header consists of the following fields:
o The SN base low field is used to indicate the lowest sequence o The SN base low field is used to indicate the lowest sequence
number, taking wrap around into account, of those source packets number, taking wrap around into account, of those source packets
protected by this repair packet. protected by this repair packet.
o The Length recovery field is used to determine the length of any o The Length recovery field is used to determine the length of any
recovered packets. recovered packets.
skipping to change at page 20, line 15 skipping to change at page 20, line 28
rate. rate.
o The remaining required payload-format-specific parameters go into o The remaining required payload-format-specific parameters go into
the "a=fmtp" line by copying them directly from the media type the "a=fmtp" line by copying them directly from the media type
string as a semicolon-separated list of parameter=value pairs. string as a semicolon-separated list of parameter=value pairs.
SDP examples are provided in Section 7. SDP examples are provided in Section 7.
5.2.1. Offer-Answer Model Considerations 5.2.1. Offer-Answer Model Considerations
TBC. When offering 1-D interleaved parity FEC over RTP using SDP in an
Offer/Answer model [RFC3264], the following considerations apply:
o Each combination of the L and D parameters produces a different
FEC data and is not compatible with any other combination. A
sender application may desire to offer multiple offers with
different sets of L and D values as long as the parameter values
are valid. The receiver SHOULD normally choose the offer that has
a sufficient amount of interleaving. If multiple such offers
exist, the receiver may choose the offer that has the lowest
overhead or the one that requires the smallest amount of
buffering. The selection depends on the application requirements.
o The value for the repair-window parameter depends on the L and D
values and cannot be chosen arbitrarily. More specifically, L and
D values determine the lower limit for the repair-window size.
The upper limit of the repair-window size does not depend on the L
and D values.
o Although combinations with the same L and D values but with
different repair-window sizes produce the same FEC data, such
combinations are still considered different offers. The size of
the repair-window is related to how fast the sender will send the
repair packets. This directly impacts the buffering requirement
on the receiver side and the receiver must consider this when
choosing an offer.
o There are no optional format parameters defined for this payload.
Any unknown option in the offer MUST be ignored and deleted from
the answer.
5.2.2. Declarative Considerations 5.2.2. Declarative Considerations
TBC. In declarative usage, like SDP in the Real-time Streaming Protocol
(RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
[RFC2974], the following considerations apply:
o The payload format configuration parameters are all declarative
and a participant MUST use the configuration that is provided for
the session.
o More than one configuration may be provided (if desired) by
declaring multiple RTP payload types. In that case, the receivers
should choose the repair flow that is best for them.
6. Protection and Recovery Procedures 6. Protection and Recovery Procedures
This section provides a complete specification of the 1-D interleaved This section provides a complete specification of the 1-D interleaved
parity code. parity code.
6.1. Overview 6.1. Overview
The following sections specify the steps involved in generating the The following sections specify the steps involved in generating the
repair packets and reconstructing the missing source packets from the repair packets and reconstructing the missing source packets from the
skipping to change at page 25, line 41 skipping to change at page 26, line 47
a=mid:R1 a=mid:R1
8. Congestion Control Considerations 8. Congestion Control Considerations
FEC is an effective approach to provide applications resiliency FEC is an effective approach to provide applications resiliency
against packet losses. However, in networks where the congestion is against packet losses. However, in networks where the congestion is
a major contributor to the packet loss, the potential impacts of a major contributor to the packet loss, the potential impacts of
using FEC SHOULD be considered carefully before injecting the repair using FEC SHOULD be considered carefully before injecting the repair
flows into the network. In particular, in bandwidth-limited flows into the network. In particular, in bandwidth-limited
networks, FEC repair flows may consume most or all of the available networks, FEC repair flows may consume most or all of the available
bandwidth and consequently may congest the network. In such cases, bandwidth and may consequently congest the network. In such cases,
the applications MUST NOT arbitrarily increase the amount of FEC the applications MUST NOT arbitrarily increase the amount of FEC
protection since doing so may lead to a congestion collapse. If protection since doing so may lead to a congestion collapse. If
desired, stronger FEC protection MAY be applied only after the source desired, stronger FEC protection MAY be applied only after the source
rate has been reduced. rate has been reduced.
In a network-friendly implementation, an application SHOULD NOT send/ In a network-friendly implementation, an application SHOULD NOT send/
receive FEC repair flows if it knows that sending/receiving those FEC receive FEC repair flows if it knows that sending/receiving those FEC
repair flows would not help at all in recovering the missing packets. repair flows would not help at all in recovering the missing packets.
Such a practice helps reduce the amount of wasted bandwidth. It is Such a practice helps reduce the amount of wasted bandwidth. It is
RECOMMENDED that the amount of FEC protection is adjusted dynamically RECOMMENDED that the amount of FEC protection is adjusted dynamically
skipping to change at page 26, line 17 skipping to change at page 27, line 24
In multicast scenarios, it may be difficult to optimize the FEC In multicast scenarios, it may be difficult to optimize the FEC
protection per receiver. If there is a large variation among the protection per receiver. If there is a large variation among the
levels of FEC protection needed by different receivers, it is levels of FEC protection needed by different receivers, it is
RECOMMENDED that the sender offers multiple repair flows with RECOMMENDED that the sender offers multiple repair flows with
different levels of FEC protection and the receivers join the different levels of FEC protection and the receivers join the
corresponding multicast sessions to receive the repair flow(s) that corresponding multicast sessions to receive the repair flow(s) that
is best for them. is best for them.
9. Security Considerations 9. Security Considerations
TBC. RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [RFC3550] and in any applicable RTP profile. The main
security considerations for the RTP packet carrying the RTP payload
format defined within this memo are confidentiality, integrity and
source authenticity. Confidentiality is achieved by encrypting the
RTP payload. Integrity of the RTP packets is achieved through a
suitable cryptographic integrity protection mechanism. Such a
cryptographic system may also allow the authentication of the source
of the payload. A suitable security mechanism for this RTP payload
format should provide confidentiality, integrity protection, and at
least source authentication capable of determining if an RTP packet
is from a member of the RTP session.
Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the
application, transport and signaling protocol employed. Therefore, a
single mechanism is not sufficient, although if suitable, using the
Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended.
Other mechanisms that may be used are IPsec [RFC4301] and Transport
Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may
exist.
10. IANA Considerations 10. IANA Considerations
New media subtypes are subject to IANA registration. For the New media subtypes are subject to IANA registration. For the
registration of the payload format and its parameters introduced in registration of the payload format and its parameters introduced in
this document, refer to Section 5. this document, refer to Section 5.
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-01 12.1. draft-ietf-fecframe-interleaved-fec-scheme-02
The following are the major changes compared to version 01:
o Some details were added regarding the use of CNAME field.
o Offer-Answer and Declarative Considerations sections have been
completed.
o Security Considerations section has been completed.
12.2. 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.2. draft-ietf-fecframe-interleaved-fec-scheme-00 12.3. 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.
skipping to change at page 27, line 36 skipping to change at page 29, line 26
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006. Session Description Protocol", RFC 4756, November 2006.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003. Payload Formats", RFC 3555, July 2003.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
13.2. Informative References 13.2. Informative References
[I-D.ietf-fecframe-dvb-al-fec] [I-D.ietf-fecframe-dvb-al-fec]
Begen, A. and T. Stockhammer, "DVB Application-Layer Begen, A. and T. Stockhammer, "DVB Application-Layer
Hybrid FEC Protection", draft-ietf-fecframe-dvb-al-fec-00 Hybrid FEC Protection", draft-ietf-fecframe-dvb-al-fec-01
(work in progress), August 2008. (work in progress), January 2009.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733, for Generic Forward Error Correction", RFC 2733,
December 1999. December 1999.
[RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of [RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of
parityfec MIME types", RFC 3009, November 2000. parityfec MIME types", RFC 3009, November 2000.
[ETSI-TS-102-034] [ETSI-TS-102-034]
DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1), DVB Document A086 Rev. 4 (ETSI TS 102 034 V1.3.1),
"Transport of MPEG 2 Transport Stream (TS) Based DVB "Transport of MPEG 2 Transport Stream (TS) Based DVB
Services over IP Based Networks", March 2007. Services over IP Based Networks", March 2007.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[SMPTE2022-1] [SMPTE2022-1]
SMPTE 2022-1-2007, "Forward Error Correction for Real-Time SMPTE 2022-1-2007, "Forward Error Correction for Real-Time
Video/Audio Transport over IP Networks", 2007. Video/Audio Transport over IP Networks", 2007.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Author's Address Author's Address
Ali Begen Ali Begen
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: abegen@cisco.com Email: abegen@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 23 change blocks. 
45 lines changed or deleted 153 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/