draft-ietf-fecframe-rtp-raptor-07.txt   rfc6682.txt 
FEC Framework Working Group M. Watson Internet Engineering Task Force (IETF) M. Watson
Internet-Draft Netflix Request for Comments: 6682 Netflix
Intended status: Standards Track T. Stockhammer Category: Standards Track T. Stockhammer
Expires: August 27, 2012 Nomor Research ISSN: 2070-1721 Nomor Research
M. Luby M. Luby
Qualcomm Incorporated Qualcomm Incorporated
February 24, 2012 August 2012
RTP Payload Format for Raptor FEC RTP Payload Format for Raptor Forward Error Correction (FEC)
draft-ietf-fecframe-rtp-raptor-07
Abstract Abstract
This document specifies an RTP Payload Format for Forward Error This document specifies an RTP payload format for the Forward Error
Correction repair data produced by the Raptor FEC Schemes. Raptor Correction (FEC) repair data produced by the Raptor FEC Schemes.
FEC Schemes are specified for use with the IETF FEC Framework which Raptor FEC Schemes are specified for use with the IETF FEC Framework
supports transport of repair data over both UDP and RTP. This that supports the transport of repair data over both UDP and RTP.
document specifies the Payload Format which is required for the use This document specifies the payload format that is required for the
of RTP to carry Raptor repair flows. use of RTP to carry Raptor repair flows.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by
material or to cite them other than as "work in progress." the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 5741.
This Internet-Draft will expire on August 27, 2012. Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6682.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 2. Conventions, Definitions, and Acronyms ..........................3
3. Media Format Background . . . . . . . . . . . . . . . . . . . 5 3. Media Format Background .........................................3
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Payload Format for FEC Repair Packets ...........................4
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 4.1. RTP Header Usage ...........................................4
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Payload Header .............................................5
4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Payload Data ...............................................5
5. Congestion Control Considerations . . . . . . . . . . . . . . 7 5. Congestion Control Considerations ...............................5
6. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Media Types .....................................................5
6.1. Registration of the application/raptorfec media type . . . 8 6.1. Registration of the 'application/raptorfec' Media Type .....5
6.1.1. Media Type Definition . . . . . . . . . . . . . . . . 8 6.1.1. Media Type Definition ...............................5
6.2. Registration of the video/raptorfec media type . . . . . . 9 6.2. Registration of the 'video/raptorfec' Media Type ...........7
6.2.1. Media Type Definition . . . . . . . . . . . . . . . . 9 6.2.1. Media Type Definition ...............................7
6.3. Registration of the audio/raptorfec media type . . . . . . 11 6.3. Registration of the 'audio/raptorfec' Media Type ...........8
6.3.1. Media Type Definition . . . . . . . . . . . . . . . . 11 6.3.1. Media Type Definition ...............................8
6.4. Registration of the text/raptorfec media type . . . . . . 13 6.4. Registration of the 'text/raptorfec' Media Type ...........10
6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 13 6.4.1. Media Type Definition ..............................10
7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Mapping to the Session Description Protocol (SDP) ..............12
8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 16 8. Offer/Answer Considerations ....................................12
9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 17 9. Declarative SDP Considerations .................................13
10. Repair Flow Generation and Recovery Procedures . . . . . . . . 18 10. Repair Flow Generation and Recovery Procedures ................13
10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Overview .................................................13
10.2. Repair Packet Construction . . . . . . . . . . . . . . . . 18 10.2. Repair Packet Construction ...............................14
10.3. Usage of RTCP . . . . . . . . . . . . . . . . . . . . . . 18 10.3. Usage of RTCP ............................................14
10.4. Source Packet Reconstruction . . . . . . . . . . . . . . . 19 10.4. Source Packet Reconstruction .............................14
11. Session Description Protocol (SDP) Example . . . . . . . . . . 20 11. Session Description Protocol (SDP) Example ....................14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 12. IANA Considerations ...........................................15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Security Considerations .......................................15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References ....................................................16
14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 14.1. Normative References .....................................16
14.2. Informative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References ...................................17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The FEC Framework [RFC6363] defines a general framework for the use The FEC Framework [RFC6363] defines a general framework for the use
of Forward Error Correction in association with arbitrary packet of Forward Error Correction in association with arbitrary packet
flows, including flows over UDP and RTP [RFC3550]. Forward Error flows, including flows over UDP and RTP [RFC3550]. Forward Error
Correction operates by generating redundant data packets ("repair Correction operates by generating redundant data packets ("repair
data") which can be sent independently from the original flow. At a data") that can be sent independently from the original flow. At a
receiver the original flow can be reconstructed provided a sufficient receiver, the original flow can be reconstructed provided a
set of redundant data packets and possibly original data packets are sufficient set of redundant data packets and possibly original data
received. packets are received.
The FEC Framework provides for independence between application The FEC Framework provides for independence between application
protocols and FEC codes. The use of a particular FEC code within the protocols and FEC codes. The use of a particular FEC code within the
framework is defined by means of a FEC Scheme which may then be used framework is defined by means of a FEC Scheme, which may then be used
with any application protocol compliant to the framework. with any application protocol compliant to the framework.
Repair data flows may be sent directly over a transport protocol such Repair data flows may be sent directly over a transport protocol,
as UDP, or they may be encapsulated within specialized transports for such as UDP, or they may be encapsulated within specialized
multimedia, such as RTP. transports for multimedia, such as RTP.
This document defines the RTP Payload Format for the Raptor FEC This document defines the RTP payload format for the Raptor FEC
Schemes defined in [I-D.ietf-fecframe-raptor]. Schemes defined in [RFC6681].
2. Conventions, Definitions and Acronyms 2. Conventions, Definitions, and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Media Format Background 3. Media Format Background
The Raptor and RaptorQ codes are efficient block-based fountain The Raptor and RaptorQ codes are efficient block-based fountain
codes, meaning that from any group of source packets (or 'source codes, meaning that from any group of source packets (or 'source
block') one can generate an arbitrary number of repair packets. The block'), one can generate an arbitrary number of repair packets. The
Raptor and RaptorQ codes have the property that the original group of Raptor and RaptorQ codes have the property that the original group of
source symbols can be recovered with very high probability from any source symbols can be recovered with a very high probability from any
set of symbols (source and repair) only slightly greater in number set of symbols (source and repair) only slightly greater in number
than the original number of source symbols. The RaptorQ code than the original number of source symbols. The RaptorQ code
additionally has the property that the probability that the original additionally has the property that the probability that the original
group of source symbols can be recovered from a set of symbols group of source symbols can be recovered from a set of symbols
(source and repair) equal in number to the original number of source (source and repair) equal in number to the original number of source
symbols is in many cases also very high. symbols is in many cases also very high.
[I-D.ietf-fecframe-raptor] defines six FEC Schemes for the use of the [RFC6681] defines six FEC Schemes for the use of the Raptor and
Raptor and RaptorQ codes with arbitrary packet flows: the first two RaptorQ codes with arbitrary packet flows. The first two schemes are
schemes are fully applicable to arbitrary packet flows (using Raptor fully applicable to arbitrary packet flows (using Raptor and RaptorQ
and RaptorQ respectively). The third and fourth schemes are slightly respectively). The third and fourth schemes are slightly optimized
optimised versions of the first two schemes which are applicable in versions of the first two schemes, which are applicable in
applications with relatively small block sizes. The fifth and sixth applications with relatively small block sizes. The fifth and sixth
schemes are variants of the third and fourth schemes which are schemes are variants of the third and fourth schemes, which are
applicable to a single source flow which already has some kind of applicable to a single source flow that already has some kind of
identifiable sequence number. The presence of a sequence number in identifiable sequence number. The presence of a sequence number in
the source flow allows for backwards-compatible operation (the source the source flow allows for backwards-compatible operation (the source
flows do not need to be modified in order to apply FEC). In this flows do not need to be modified in order to apply FEC). In this
case, in the language of the FEC Framework, there is no need for an case, in the language of the FEC Framework, there is no need for an
explicit FEC Source Payload Id and it is therefore not included in explicit FEC Source Payload ID; therefore, it is not included in the
the packets. packets.
This document specifies the payload format for RTP repair flows and This document specifies the payload format for RTP repair flows and
can be used with any of the FEC Schemes defined in can be used with any of the FEC Schemes defined in [RFC6681].
[I-D.ietf-fecframe-raptor].
4. Payload Format 4. Payload Format for FEC Repair Packets
4.1. RTP Header Usage 4.1. RTP Header Usage
Header fields SHALL be set according to the rules of [RFC3550]. In Header fields SHALL be set according to the rules of [RFC3550]. In
addition, the following rules and definitions apply for the RTP addition, the following rules and definitions apply for the RTP
header used with FEC repair packets: headers used with FEC repair packets:
o Marker bit: The marker bit SHALL be set to 1 for the last o Marker bit: The marker bit SHALL be set to 1 for the last
protection RTP packet sent for each source block, and otherwise protection RTP packet sent for each source block, and otherwise
set to 0. set to 0.
o Payload Type (PT): The payload type codes SHALL be assigned o Payload Type (PT): The payload type codes SHALL be assigned
dynamically through non-RTP means. If SDP is used for signaling, dynamically through non-RTP means. If the Session Description
the the rules in Section 7 apply. Protocol (SDP) is used for signaling, the rules in Section 7
apply.
o Timestamp: This field contains the time at which the packet is o Timestamp: This field contains the time at which the packet is
transmitted. The time SHOULD be as close as possible to the transmitted. The time SHOULD be as close as possible to the
packet's actual time of transmission. The timestamp value has no packet's actual time of transmission. The timestamp value has no
use in the actual FEC protection process. However, use in the actual FEC protection process. However,
implementations SHOULD supply a value that can be used for packet implementations SHOULD supply a value that can be used for packet-
arrival timing or jitter calculations. The timestamp rate is arrival timing or jitter calculations. The timestamp rate is
specified using the "rate" media type parameter defined in specified using the "rate" media type parameter defined in Section
Section 6. The operator SHALL select a 'rate' larger than 1000 Hz 6. The operator SHALL select a "rate" larger than 1000 Hz to
to provide sufficient resolution to RTCP operations and the provide sufficient resolution to the Real-Time Transport Control
operator SHOULD select the rate that matches the rate of the Protocol (RTCP) operations, and the operator SHOULD select the
protected source RTP stream. rate that matches the rate of the protected source RTP stream.
o SSRC: The SSRC values MUST be set according to [RFC3550]. The o Synchronization Source (SSRC): The SSRC values MUST be set
SSRC value of the RTP repair flow MUST be different from the SSRC according to [RFC3550]. The SSRC value of the RTP repair flow
value of the protected source flow. MUST be different from the SSRC value of the protected source
flow.
4.2. Payload Header 4.2. Payload Header
There is no Payload Header in this Payload Format. There is no payload header in this payload format.
4.3. Payload Data 4.3. Payload Data
Procedures and data formats for the use of Raptor Forward Error Procedures and data formats for the use of Raptor Forward Error
Correction in a FECFRAME context are fully defined in [RFC6363] and Correction in a FECFRAME context are fully defined in [RFC6363] and
[I-D.ietf-fecframe-raptor] and are not duplicated here. The [RFC6681] and are not duplicated here. The procedures of those
procedures of those documents apply in order to generate repair data documents apply in order to generate repair data streams to be
streams to be carried by the payload formats defined in this carried by the payload formats defined in this document.
document.
The RTP Payload SHALL contain a FEC Repair Payload as defined in The RTP Payload SHALL contain a Repair FEC Payload ID as defined in
[RFC6363] and [I-D.ietf-fecframe-raptor]. [RFC6363] and [RFC6681].
5. Congestion Control Considerations 5. Congestion Control Considerations
See [RFC6363]. See [RFC6363].
6. Media Types 6. Media Types
6.1. Registration of the application/raptorfec media type 6.1. Registration of the 'application/raptorfec' Media Type
This RTP payload format is identified using the application/raptorfec This RTP payload format is identified using the
media type which is registered in accordance with [RFC4855] and using 'application/raptorfec' media type that is registered in accordance
the template of [RFC4288]. with [RFC4855] and uses the template of [RFC4288].
6.1.1. Media Type Definition 6.1.1. Media Type Definition
Type name: application Type name: application
Subtype name: raptorfec Subtype name: raptorfec
Required parameters: Required parameters:
o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock)
rate is specified in Hz and the format is unsigned integer. rate is specified in Hz and the format is unsigned integer.
o raptor-scheme-id: The value of this parameter is the FEC Scheme Id o raptor-scheme-id: The value of this parameter is the FEC Scheme ID
for the specific Raptor FEC Scheme that will be used as defined in for the specific Raptor FEC Scheme that will be used as defined in
[I-D.ietf-fecframe-raptor]. [RFC6681].
o Kmax: The value of this parameter is the FEC Framework o Kmax: The value of this parameter is the FEC Framework
Configuration Information element "Maximum Source Block Length" as Configuration Information element, Maximum Source Block Length
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal (MSBL), as defined in [RFC6681], encoded as a unsigned integer.
integer. For specific requirements for this value refer to For specific requirements for this value, refer to [RFC6681].
[I-D.ietf-fecframe-raptor].
o T: The value of this parameter is the FEC Framework Configuration o T: The value of this parameter is the FEC Framework Configuration
Information element "Encoding Symbol Size" as defined in Information element, encoding symbol size, as defined in
[I-D.ietf-fecframe-raptor] encoded as a decimal integer. For [RFC6681], encoded as a unsigned integer. For specific
specific requirements for this value refer to requirements for this value, refer to [RFC6681].
[I-D.ietf-fecframe-raptor].
o repair-window: The maximum time that spans the source packets and o repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window the corresponding repair packets. The size of the repair window
is specified in microseconds and the format is unsigned integer. is specified in microseconds and the format is unsigned integer.
Optional parameters: Optional parameters:
o P: The value of this parameter is the FEC Framework Configuration o P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in Information element, Payload ID Format, as defined in [RFC6681].
[I-D.ietf-fecframe-raptor]. The default value of this parameter The default value of this parameter (when it does not appear
(when it does not appear explicitly) is 'A'. explicitly) is 'A'.
Encoding considerations: This media type is framed and binary, see Encoding considerations: This media type is framed and binary; see
section 4.8 in [RFC4288] Section 4.8 in [RFC4288]
Security considerations: Please see security consideration in
[RFC6363] Security considerations: Please see the security considerations in
[RFC6363].
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [RFC6681]
Applications that use this media type: Real-time multimedia Applications that use this media type: Real-time multimedia
applications like video streaming, audio streaming, and video applications like video streaming, audio streaming, and video
conferencing. conferencing.
Additional information: Additional information:
Magic number(s): <none defined> Magic number(s): <none defined>
File extension(s): <none defined> File extension(s): <none defined>
Macintosh file type code(s): <none defined> Macintosh file type code(s): <none defined>
Person & email address to contact for further information: Thomas Person & email address to contact for further information:
Stockhammer, stockhammer@nomor.de Thomas Stockhammer, stockhammer@nomor.de
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [[RFC3550]]. Transport hence is only defined for transfer via RTP [RFC3550]. Transport
within other framing protocols is not defined at this time. within other framing protocols is not defined at this time.
Author: Thomas Stockhammer, Nomor Research Author: Thomas Stockhammer, Nomor Research
Change controller: IETF PAYLOAD working group delegated from the
IESG.
Change controller: IETF Audio/Video Transport working group delegated 6.2. Registration of the 'video/raptorfec' Media Type
from the IESG.
6.2. Registration of the video/raptorfec media type
This RTP payload format is identified using the video/raptorfec media This RTP payload format is identified using the 'video/raptorfec'
type which is registered in accordance with [RFC4855] and using the media type that is registered in accordance with [RFC4855] and uses
template of [RFC4288]. the template of [RFC4288].
6.2.1. Media Type Definition 6.2.1. Media Type Definition
Type name: video Type name: video
Subtype name: raptorfec Subtype name: raptorfec
Required parameters: Required parameters:
o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock)
rate is specified in Hz and the format is unsigned integer. rate is specified in Hz and the format is unsigned integer.
o raptor-scheme-id: The value of this parameter is the FEC Scheme Id o raptor-scheme-id: The value of this parameter is the FEC Scheme ID
for the specific Raptor FEC Scheme that will be used as defined in for the specific Raptor FEC Scheme that will be used as defined in
[I-D.ietf-fecframe-raptor]. [RFC6681].
o Kmax: The value of this parameter is the FEC Framework o Kmax: The value of this parameter is the FEC Framework
Configuration Information element "Maximum Source Block Length" as Configuration Information element, MSBL, as defined in [RFC6681],
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal encoded as a unsigned integer. For specific requirements for this
integer. For specific requirements for this value refer to value, refer to [RFC6681].
[I-D.ietf-fecframe-raptor].
o T: The value of this parameter is the FEC Framework Configuration o T: The value of this parameter is the FEC Framework Configuration
Information element "Encoding Symbol Size" as defined in Information element, encoding symbol size, as defined in
[I-D.ietf-fecframe-raptor] encoded as a decimal integer. For [RFC6681], encoded as a unsigned integer. For specific
specific requirements for this value refer to requirements for this value, refer to [RFC6681].
[I-D.ietf-fecframe-raptor].
o repair-window: The maximum time that spans the source packets and o repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window the corresponding repair packets. The size of the repair window
is specified in microseconds and the format is unsigned integer. is specified in microseconds, and the format is unsigned integer.
Optional parameters: Optional parameters:
o P: The value of this parameter is the FEC Framework Configuration o P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in Information element, Payload ID Format, as defined in [RFC6681].
[I-D.ietf-fecframe-raptor]. The default value of this parameter The default value of this parameter (when it does not appear
(when it does not appear explicitly) is 'A'. explicitly) is 'A'.
Encoding considerations: This media type is framed and binary, see Encoding considerations: This media type is framed and binary; see
section 4.8 in [RFC4288] Section 4.8 in [RFC4288].
Security considerations: Please see security consideration in Security considerations: Please see the security considerations in
[RFC6363] [RFC6363].
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [RFC6681]
Applications that use this media type: Real-time multimedia Applications that use this media type: Real-time multimedia
applications like video streaming, audio streaming, and video applications like video streaming, audio streaming, and video
conferencing. conferencing.
Additional information: Additional information:
Magic number(s): <none defined> Magic number(s): <none defined>
File extension(s): <none defined> File extension(s): <none defined>
Macintosh file type code(s): <none defined> Macintosh file type code(s): <none defined>
Person & email address to contact for further information: Thomas Person & email address to contact for further information:
Stockhammer, stockhammer@nomor.de Thomas Stockhammer, stockhammer@nomor.de
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [[RFC3550]]. Transport hence is only defined for transfer via RTP [RFC3550]. Transport
within other framing protocols is not defined at this time. within other framing protocols is not defined at this time.
Author: Thomas Stockhammer, Nomor Research. Author: Thomas Stockhammer, Nomor Research.
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF PAYLOAD working group delegated from the
from the IESG. IESG.
6.3. Registration of the audio/raptorfec media type 6.3. Registration of the 'audio/raptorfec' Media Type
This RTP payload format is identified using the audio/raptorfec media This RTP payload format is identified using the 'audio/raptorfec'
type which is registered in accordance with [RFC4855] and using the media type that is registered in accordance with [RFC4855] and uses
template of [RFC4288]. the template of [RFC4288].
6.3.1. Media Type Definition 6.3.1. Media Type Definition
Type name: audio Type name: audio
Subtype name: raptorfec Subtype name: raptorfec
Required parameters: Required parameters:
o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock)
rate is specified in Hz and the format is unsigned integer. rate is specified in Hz and the format is unsigned integer.
o raptor-scheme-id: The value of this parameter is the FEC Scheme Id o raptor-scheme-id: The value of this parameter is the FEC Scheme ID
for the specific Raptor FEC Scheme that will be used as defined in for the specific Raptor FEC Scheme that will be used as defined in
[I-D.ietf-fecframe-raptor]. [RFC6681].
o Kmax: The value of this parameter is the FEC Framework o Kmax: The value of this parameter is the FEC Framework
Configuration Information element "Maximum Source Block Length" as Configuration Information element, MSBL, as defined in [RFC6681],
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal encoded as a unsigned integer. For specific requirements for this
integer. For specific requirements for this value refer to value, refer to [RFC6681].
[I-D.ietf-fecframe-raptor].
o T: The value of this parameter is the FEC Framework Configuration o T: The value of this parameter is the FEC Framework Configuration
Information element "Encoding Symbol Size" as defined in Information element, encoding symbol size, as defined in
[I-D.ietf-fecframe-raptor] encoded as a decimal integer. For [RFC6681], encoded as a unsigned integer. For specific
specific requirements for this value refer to requirements for this value, refer to [RFC6681].
[I-D.ietf-fecframe-raptor].
o repair-window: The maximum time that spans the source packets and o repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window the corresponding repair packets. The size of the repair window
is specified in microseconds and the format is unsigned integer. is specified in microseconds and the format is unsigned integer.
Optional parameters: Optional parameters:
o P: The value of this parameter is the FEC Framework Configuration o P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in Information element, Payload ID Format, as defined in [RFC6681].
[I-D.ietf-fecframe-raptor]. The default value of this parameter The default value of this parameter (when it does not appear
(when it does not appear explicitly) is 'A'. explicitly) is 'A'.
Encoding considerations: This media type is framed and binary, see Encoding considerations: This media type is framed and binary; see
section 4.8 in [RFC4288] Section 4.8 in [RFC4288].
Security considerations: Please see security consideration in Security considerations: Please see the security considerations in
[RFC6363] [RFC6363].
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [RFC6681]
Applications that use this media type: Real-time multimedia Applications that use this media type: Real-time multimedia
applications like video streaming, audio streaming, and video applications like video streaming, audio streaming, and video
conferencing. conferencing.
Additional information: Additional information:
Magic number(s): <none defined> Magic number(s): <none defined>
File extension(s): <none defined> File extension(s): <none defined>
Macintosh file type code(s): <none defined> Macintosh file type code(s): <none defined>
Person & email address to contact for further information: Thomas Person & email address to contact for further information:
Stockhammer, stockhammer@nomor.de Thomas Stockhammer, stockhammer@nomor.de
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [[RFC3550]]. Transport hence is only defined for transfer via RTP [RFC3550]. Transport
within other framing protocols is not defined at this time. within other framing protocols is not defined at this time.
Author: Thomas Stockhammer, Nomor Research. Author: Thomas Stockhammer, Nomor Research.
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF PAYLOAD working group delegated from the
from the IESG. IESG.
6.4. Registration of the text/raptorfec media type 6.4. Registration of the 'text/raptorfec' Media Type
This RTP payload format is identified using the text/raptorfec media This RTP payload format is identified using the 'text/raptorfec'
type which is registered in accordance with [RFC4855] and using the media type that is registered in accordance with [RFC4855] and uses
template of [RFC4288]. the template of [RFC4288].
6.4.1. Media Type Definition 6.4.1. Media Type Definition
Type name: text Type name: text
Subtype name: raptorfec Subtype name: raptorfec
Required parameters: Required parameters:
o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock) o rate: The RTP timestamp (clock) rate. The RTP timestamp (clock)
rate is specified in Hz and the format is unsigned integer. rate is specified in Hz and the format is unsigned integer.
o raptor-scheme-id: The value of this parameter is the FEC Scheme Id o raptor-scheme-id: The value of this parameter is the FEC Scheme ID
for the specific Raptor FEC Scheme that will be used as defined in for the specific Raptor FEC Scheme that will be used as defined in
[I-D.ietf-fecframe-raptor]. [RFC6681].
o Kmax: The value of this parameter is the FEC Framework o Kmax: The value of this parameter is the FEC Framework
Configuration Information element "Maximum Source Block Length" as Configuration Information element, MSBL, as defined in [RFC6681],
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal encoded as a unsigned integer. For specific requirements for this
integer. For specific requirements for this value refer to value, refer to [RFC6681].
[I-D.ietf-fecframe-raptor].
o T: The value of this parameter is the FEC Framework Configuration o T: The value of this parameter is the FEC Framework Configuration
Information element "Encoding Symbol Size" as defined in Information element, encoding symbol size, as defined in
[I-D.ietf-fecframe-raptor] encoded as a decimal integer. For [RFC6681], encoded as a unsigned integer. For specific
specific requirements for this value refer to requirements for this value, refer to [RFC6681].
[I-D.ietf-fecframe-raptor].
o repair-window: The maximum time that spans the source packets and o repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window the corresponding repair packets. The size of the repair window
is specified in microseconds and the format is unsigned integer. is specified in microseconds and the format is unsigned integer.
Optional parameters: Optional parameters:
o P: The value of this parameter is the FEC Framework Configuration o P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in Information element, Payload ID Format, as defined in [RFC6681].
[I-D.ietf-fecframe-raptor]. The default value of this parameter The default value of this parameter (when it does not appear
(when it does not appear explicitly) is 'A'. explicitly) is 'A'.
Encoding considerations: This media type is framed and binary, see Encoding considerations: This media type is framed and binary; see
section 4.8 in [RFC4288] Section 4.8 in [RFC4288].
Security considerations: Please see security consideration in
[RFC6363] Security considerations: Please see the security considerations in
[RFC6363].
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [RFC6681]
Applications that use this media type: Real-time multimedia Applications that use this media type: Real-time multimedia
applications like video streaming, audio streaming, and video applications like video streaming, audio streaming, and video
conferencing. conferencing.
Additional information: Additional information:
Magic number(s): <none defined> Magic number(s): <none defined>
File extension(s): <none defined> File extension(s): <none defined>
Macintosh file type code(s): <none defined> Macintosh file type code(s): <none defined>
Person & email address to contact for further information: Thomas Person & email address to contact for further information:
Stockhammer, stockhammer@nomor.de Thomas Stockhammer, stockhammer@nomor.de
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP [[RFC3550]]. Transport hence is only defined for transfer via RTP [RFC3550]. Transport
within other framing protocols is not defined at this time. within other framing protocols is not defined at this time.
Author: Thomas Stockhammer, Nomor Research. Author: Thomas Stockhammer, Nomor Research.
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF PAYLOAD working group delegated from the
from the IESG. IESG.
7. Mapping to SDP 7. Mapping to the Session Description Protocol (SDP)
Applications that are using RTP transport commonly use Session Applications that are using RTP transport commonly use the Session
Description Protocol (SDP) [RFC4566] to describe their RTP sessions. Description Protocol (SDP) [RFC4566] to describe their RTP sessions.
The information that is used to specify the media types in an RTP The information that is used to specify the media types in an RTP
session has specific mappings to the fields in an SDP description. session has specific mappings to the fields in an SDP description.
Note that if an application does not use SDP to describe the RTP Note that if an application does not use SDP to describe the RTP
sessions, an appropriate mapping must be defined and used to specify sessions, an appropriate mapping must be defined and used to specify
the media types and their parameters for the control/description the media types and their parameters for the control/description
protocol employed by the application. protocol employed by the application.
The mapping of the above defined payload format media type and its The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of [RFC4855] parameters SHALL be done according to Section 3 of [RFC4855],
following the suggestion therein regarding the mapping of payload- following the suggestion therein regarding the mapping of payload-
format-specific parameters into the "'"a=fmtp"' field. format-specific parameters into the "a=fmtp" field.
When the RTP Payload Formats defined in this document are used, the When the RTP payload formats defined in this document are used, the
Media Type Parameters defined above MUST use the media types in this media type parameters defined above MUST use the media types in this
document and MUST NOT use those specified in [RFC6364]. document and MUST NOT use those specified in [RFC6364].
8. Offer/Answer considerations 8. Offer/Answer Considerations
When offering Raptor FEC over RTP using SDP in an Offer/Answer model When offering Raptor FEC over RTP using SDP in an Offer/Answer model
[RFC3264], the following considerations apply: [RFC3264], the following considerations apply:
o Each combination of the Kmax and T parameters produces different o Each combination of the Kmax and T parameters produces different
FEC data and is not compatible with any other combination. A FEC data and is not compatible with any other combination. A
sender application MAY desire to offer multiple offers with sender application MAY desire to provide multiple offers with
different sets of Kmax and T values as long as the parameter different sets of Kmax and T values, which is possible as long as
values are valid. The receiver SHOULD normally choose the offer the parameter values are valid. The receiver SHOULD normally
with the largest value of the product of Kmax and T that it choose the offer with the largest value of the product of Kmax and
supports. T that it supports.
o The size of the repair-window is related to the maximum delay o The size of the repair window is related to the maximum delay
between the transmission of a source packet and the associated between the transmission of a source packet and the associated
repair packet. This directly impacts the buffering requirement on repair packet. This directly impacts the buffering requirement on
the receiver side and the receiver must consider this when the receiver side and the receiver must consider this when
choosing an offer. choosing an offer.
o When the P parameter is not present, the receiver MUST use FEC o When the P parameter is not present, the receiver MUST use FEC
Payload ID Format A. In an answer which selects an offer in which Payload ID Format A. In an answer that selects an offer in which
the P parameter was omitted, the P parameter MUST either be the P parameter was omitted, the P parameter MUST either be
omitted, or included with value "A". omitted, or included with value "A".
9. Declarative SDP Considerations 9. Declarative SDP 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.
o More than one configuration MAY be provided (if desired) by o More than one configuration MAY be provided (if desired) by
declaring multiple RTP payload types. In that case, the receivers declaring multiple RTP payload types. In this case, the receivers
should choose the repair session that is best for them. should choose the repair session that is best for them.
10. Repair Flow Generation and Recovery Procedures 10. Repair Flow Generation and Recovery Procedures
10.1. Overview 10.1. Overview
This document only specifies the repair flow construction when the This document only specifies repair flow construction when the repair
repair packets are delivered with RTP. Source packet construction is packets are delivered with RTP. Source packet construction is
covered in [I-D.ietf-fecframe-raptor]. This section provides an covered in [RFC6681]. This section provides an overview on how to
overview on how to generate a repair flow including the repair generate a repair flow, including the repair packets and how to
packets and on how to reconstruct missing source packets from a set reconstruct missing source packets from a set of available source and
of available source and repair packets. Detailed algorithms for the repair packets. Detailed algorithms for the generation of Raptor and
generation of Raptor and RaptorQ symbols are provided in [RFC5053] RaptorQ symbols are provided in [RFC5053] and [RFC6330],
and [RFC6330], respectively. respectively.
As per the FEC Framework document [RFC6363] the FEC Framework As per the FEC Framework document [RFC6363], the FEC Framework
Configuration Information includes among others the identification of Configuration Information includes, among others, the identification
the repair flow(s) and the source flow(s). Methods to convey FEC of the repair flow(s) and the source flow(s). Methods to convey FEC
Framework Configuration Information are provided in Framework Configuration Information are provided in [FEC-SIG].
[I-D.ietf-fecframe-config-signaling]. Specifically, the reader is Specifically, the reader is referred to the SDP elements document
referred to the SDP elements document [RFC6364], which describes the [RFC6364], which describes the usage of the 'SDP' encoding format as
usage of 'SDP' encoding format as an example encoding format for FEC an example encoding format for FEC Framework Configuration
Framework Configuration Information. Information.
For the generation of a repair flow For the generation of a repair flow:
o repair packets SHALL be constructed according to Section 10.2, and o repair packets SHALL be constructed according to Section 10.2, and
o RTCP SHALL be used according to Section 10.3. o RTCP SHALL be used according to Section 10.3.
For the reconstruction of a source packets of a source RTP session at For the reconstruction of a source packet of a source RTP session at
the receiver based on the availability of a source RTP session and an the receiver, based on the availability of a source RTP session and a
repair RTP session the procedures in Section 10.4 may be used. repair RTP session, the procedures in Section 10.4 may be used.
10.2. Repair Packet Construction 10.2. Repair Packet Construction
The construction of the repair packet is fully specified in The construction of the repair packet is fully specified in Section
Section 4. A repair packet is constructed by the concatenation of 4. A repair packet is constructed by the concatenation of
o an RTP header as specified in Section 4.1, and o an RTP header as specified in Section 4.1, and
o payload data as defined in Section 4.3. o payload data as defined in Section 4.3.
Repair Packet Construction may make use of the Sender Operation for Repair Packet Construction may make use of the Sender Operation for
RTP repair flows as specified in see [RFC6363], section 4.2. RTP repair flows as specified in see [RFC6363], Section 4.2.
10.3. Usage of RTCP 10.3. Usage of RTCP
RTCP SHALL be used according to [RFC3550]. If the repair RTP session RTCP SHALL be used according to [RFC3550]. If the repair RTP session
is sent in a separate RTP session the two sessions MUST be associated is sent in a separate RTP session, the two sessions MUST be
using RTCP CNAME. associated using RTCP CNAME (Canonical Name).
10.4. Source Packet Reconstruction 10.4. Source Packet Reconstruction
Source Packet Reconstruction may make use of the Receiver Operation Source Packet Reconstruction may make use of the receiver operation
for the case of RTP repair flows as specified in [RFC6363], section for the case of RTP repair flows as specified in [RFC6363], Section
4.3. Depending on the FEC scheme in use of the ones defined in 4.3. Depending on the FEC Scheme using the ones defined in
[I-D.ietf-fecframe-raptor], the appropriate source blocks are formed. [RFC6681], the appropriate source blocks are formed. If enough data
If enough data for decoding of any or all of the missing source for decoding any or all of the missing source payloads in the source
payloads in the source block has been received, the respective FEC block has been received, the respective FEC decoding procedures are
decoding procedures are applied. applied.
In case the FEC scheme uses Raptor codes as defined in [RFC5053], In case the FEC Scheme uses Raptor codes as defined in [RFC5053],
then the Example FEC decoder as specifed in [RFC5053], section 5.5, then the Example FEC Decoder, as specified in [RFC5053], Section 5.5,
may be used. may be used.
In case the FEC scheme uses RaptorQ codes as defined in [RFC6330], In case the FEC Scheme uses RaptorQ codes as defined in [RFC6330],
then the Example FEC decoder as specified in [RFC6330], section 5.4, then the Example FEC Decoder, as specified in [RFC6330], Section 5.4,
may be used. may be used.
11. Session Description Protocol (SDP) Example 11. Session Description Protocol (SDP) Example
This section provides an SDP [RFC4566] example. Assume we have one This section provides an SDP [RFC4566] example. Assume we have one
source video stream (mid:S1) and one FEC repair stream (mid:R1). The source video stream (mid:S1) and one FEC repair stream (mid:R1). The
'group' attribute and the FEC grouping semantics defined in [RFC5888] 'group' attribute and the FEC grouping semantics defined in [RFC5888]
and [RFC5956], respectively, are used to associate source and repair and [RFC5956], respectively, are used to associate source and repair
flows. We form one FEC group with the "a=group:FEC S1 R1" line. The flows. We form one FEC group with the "a=group:FEC S1 R1" line. The
source and repair streams are sent to the same port on different source and repair streams are sent to the same port on different
multicast groups. The repair window is set to 200 ms. multicast groups. The repair window is set to 200 ms.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=Raptor RTP FEC Example s=Raptor RTP FEC Example
t=0 0 t=0 0
a=group:FEC-FR S1 R1 a=group:FEC-FR S1 R1
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0 a=fec-source-flow: id=0
a=mid:S1 a=mid:S1
m=application 30000 RTP/AVP 110 m=application 30000 RTP/AVP 110
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=rtpmap:110 raptorfec/90000 a=rtpmap:110 raptorfec/90000
a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128; P=A; repair-window=200000 a=fmtp:110 raptor-scheme-id=1; Kmax=8192; T=128;
a=mid:R1 P=A; repair-window=200000
a=mid:R1
12. IANA Considerations 12. IANA Considerations
This memo requests that IANA registers application/raptorfec as IANA has registered 'application/raptorfec' as specified in Section
specified in Section 6.1.1, video/raptorfec as specified in 6.1.1, 'video/raptorfec' as specified in Section 6.2.1,
Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and 'audio/raptorfec' as specified in Section 6.3.1, and 'text/raptorfec'
text/raptorfec as specified in Section 6.4.1. The media type is also as specified in Section 6.4.1. The media type has also been added to
requested to be added to the IANA registry for "RTP Payload Format the IANA registry for "RTP Payload Format media types"
MIME types" (http://www.iana.org/assignments/rtp-parameters). (http://www.iana.org/assignments/rtp-parameters).
13. Security Considerations 13. Security Considerations
Security Considerations related to the use of the FEC Framework are Security Considerations related to the use of the FEC Framework are
addressed in [RFC6363]. These consideration apply in full to users addressed in [RFC6363]. These considerations apply in full to users
of the RTP Payload Formats defined in this document, since these are of the RTP payload formats defined in this document, since these are
defined in terms of the FEC Framework. defined in terms of the FEC Framework.
No further security considerations related specifically to the Raptor No further security considerations related specifically to the Raptor
FEC Schemes defined in [I-D.ietf-fecframe-raptor] have been FEC Schemes defined in [RFC6681] have been identified.
identified.
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550] and in any applicable RTP profile. The main specification [RFC3550] and in any applicable RTP profile. The main
security considerations for the RTP packet carrying the RTP payload security considerations for the RTP packet carrying the RTP payload
format defined within this memo are confidentiality, integrity and format defined within this memo are confidentiality, integrity, and
source authenticity. Confidentiality is achieved by encrypting the source authenticity. Confidentiality is achieved by encrypting the
RTP payload. Integrity of the RTP packets is achieved through a RTP payload. Integrity of the RTP packets is achieved through a
suitable cryptographic integrity protection mechanism. Such a suitable cryptographic integrity protection mechanism. Such a
cryptographic system can also allow the authentication of the source cryptographic system can also allow the authentication of the source
of the payload. A suitable security mechanism for this RTP payload of the payload. A suitable security mechanism for this RTP payload
format should provide confidentiality, integrity protection, and at format should provide confidentiality, integrity protection, and at
least source authentication capable of determining if an RTP packet least source authentication capable of determining if an RTP packet
is from a member of the RTP session. Note that the appropriate is from a member of the RTP session. Note that the appropriate
mechanism to provide security to RTP and payloads following this memo mechanism to provide security to RTP and payloads following this memo
MAY vary. It is dependent on the application, transport and MAY vary. It is dependent on the application, transport, and
signaling protocol employed. Therefore, a single mechanism is not signaling protocol employed. Therefore, a single mechanism is not
sufficient, although if suitable, using the Secure Real-time sufficient; although, if suitable, using the Secure Real-Time
Transport Protocol (SRTP) [RFC3711] is RECOMMENDED. Other mechanisms Transport Protocol (SRTP) [RFC3711] is RECOMMENDED. Other mechanisms
that may be used are IPsec [RFC4301] and Transport Layer Security that may be used are IPsec [RFC4301] and Transport Layer Security
(TLS) [RFC5246] (RTP over TCP); other alternatives exist. (TLS) [RFC5246] (RTP over TCP); other alternatives exist.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 23, line 29 skipping to change at page 16, line 37
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, October 2011. Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6364] Begen, A., "Session Description Protocol Elements for the [RFC6364] Begen, A., "Session Description Protocol Elements for the
Forward Error Correction (FEC) Framework", RFC 6364, Forward Error Correction (FEC) Framework", RFC 6364,
October 2011. October 2011.
[I-D.ietf-fecframe-raptor] [RFC6681] Watson, M., Stockhammer, T., and M. Luby, "Raptor Forward
Watson, M., Stockhammer, T., and M. Luby, "Raptor FEC Error Correction (FEC) Schemes for FECFRAME", RFC 6681,
Schemes for FECFRAME", draft-ietf-fecframe-raptor-06 (work August 2012.
in progress), November 2011.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
skipping to change at page 24, line 22 skipping to change at page 17, line 31
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
the Session Description Protocol", RFC 5956, the Session Description Protocol", RFC 5956, September
September 2010. 2010.
[I-D.ietf-fecframe-config-signaling] [FEC-SIG] Asati, R., "Methods to convey FEC Framework Configuration
Asati, R., "Methods to convey FEC Framework Configuration Information", Work in Progress, February 2012.
Information", draft-ietf-fecframe-config-signaling-06
(work in progress), September 2011.
Authors' Addresses Authors' Addresses
Mark Watson Mark Watson
Netflix Netflix
100 Winchester Circle 100 Winchester Circle
Los Gatos, CA 95032 Los Gatos, CA 95032
U.S.A. United States
Email: watsonm@netflix.com EMail: watsonm@netflix.com
Thomas Stockhammer Thomas Stockhammer
Nomor Research Nomor Research
Brecherspitzstrasse 8 Brecherspitzstrasse 8
Munich 81541 Munich 81541
Germany. Germany
Email: stockhammer@nomor.de EMail: stockhammer@nomor.de
Michael Luby Michael Luby
Qualcomm Incorporated Qualcomm Research Berkeley
3165 Kifer Road 2030 Addison Street
Santa Clara, CA 95051 Berkeley, CA 94704
U.S.A. United States
Email: luby@qualcomm.com EMail: luby@qualcomm.com
 End of changes. 121 change blocks. 
316 lines changed or deleted 301 lines changed or added

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