draft-ietf-fecframe-rtp-raptor-02.txt   draft-ietf-fecframe-rtp-raptor-03.txt 
FEC Framework Working Group M. Watson FEC Framework Working Group M. Watson
Internet-Draft Qualcomm Inc. Internet-Draft Qualcomm Inc.
Intended status: Standards Track October 23, 2009 Intended status: Standards Track March 5, 2010
Expires: April 26, 2010 Expires: September 6, 2010
RTP Payload Format for Raptor FEC RTP Payload Format for Raptor FEC
draft-ietf-fecframe-rtp-raptor-02 draft-ietf-fecframe-rtp-raptor-03
Abstract
This document specifies an RTP Payload Format for Forward Error
Correction repair data produced by the Raptor FEC Schemes. Raptor
FEC Schemes are specified for use with the IETF FEC Framework which
supports transport of repair data over both UDP and RTP. This
document specifies the Payload Format which is required for the use
of RTP to carry Raptor repair flows.
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 41
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 26, 2010. This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies an RTP Payload Format for Forward Error described in the BSD License.
Correction repair data produced by the Raptor FEC Schemes. Raptor
FEC Schemes are specified for use with the IETF FEC Framework which
supports transport of repair data over both UDP and RTP. This
document specifies the Payload Format which is required for the use
of RTP to carry Raptor repair flows.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4
3. Media Format Background . . . . . . . . . . . . . . . . . . . 5 3. Media Format Background . . . . . . . . . . . . . . . . . . . 5
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 6
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
5. Congestion Control Considerations . . . . . . . . . . . . . . 7 5. Congestion Control Considerations . . . . . . . . . . . . . . 7
6. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Registration of the application/raptorfec media type . . . 8 6.1. Registration of the application/raptorfec media type . . . 8
6.1.1. Media Type Definition . . . . . . . . . . . . . . . . 8 6.1.1. Media Type Definition . . . . . . . . . . . . . . . . 8
6.2. Registration of the video/raptorfec media type . . . . . . 9 6.2. Registration of the video/raptorfec media type . . . . . . 9
6.2.1. Media Type Definition . . . . . . . . . . . . . . . . 9 6.2.1. Media Type Definition . . . . . . . . . . . . . . . . 9
6.3. Registration of the audio/raptorfec media type . . . . . . 10 6.3. Registration of the audio/raptorfec media type . . . . . . 11
6.3.1. Media Type Definition . . . . . . . . . . . . . . . . 10 6.3.1. Media Type Definition . . . . . . . . . . . . . . . . 11
6.4. Registration of the text/raptorfec media type . . . . . . 12 6.4. Registration of the text/raptorfec media type . . . . . . 12
6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 12 6.4.1. Media Type Definition . . . . . . . . . . . . . . . . 13
7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 15 8. Offer/Answer considerations . . . . . . . . . . . . . . . . . 16
9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 16 9. Declarative SDP Considerations . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The FEC Framework [I-D.ietf-fecframe-framework] defines a general The FEC Framework [I-D.ietf-fecframe-framework] defines a general
framework for the use of Forward Error Correction in association with framework for the use of Forward Error Correction in association with
arbitrary packet flows, including flows over UDP and RTP. Forward arbitrary packet flows, including flows over UDP and RTP [RFC3550].
Error Corrections operates by generating redundant data packets Forward Error Corrections operates by generating redundant data
("repair data") which can be sent independently from the original packets ("repair data") which can be sent independently from the
flow. At a receiver the original flow can be reconstructed provided original flow. At a receiver the original flow can be reconstructed
a sufficient set of redundant data packets and possibly original data provided a sufficient set of redundant data packets and possibly
packets are received. original data 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 an FEC Scheme which may then be used framework is defined by means of an 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 such
as UDP, or they may be encapsulated within RTP. In the latter case, as UDP, or they may be encapsulated within RTP. In the latter case,
an RTP Payload Format must be defined for each FEC Scheme. an RTP Payload Format must be defined for each FEC Scheme.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
Schemes defined in [I-D.ietf-fecframe-raptor]. Schemes defined in [I-D.ietf-fecframe-raptor].
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 code is an efficient XOR-based block-based fountain code, The Raptor and RaptorQ codes are efficient block-based fountain
meaning that from any group of source packets (or 'source block') an codes, meaning that from any group of source packets (or 'source
arbitrary number of repair packets may be generated. The Raptor code block') an arbitrary number of repair packets may be generated. The
has the property that the original group of source packets can be Raptor and RaptorQ codes have the property that the original group of
recovered with very high probability from any set of packets (source source symbols can be recovered with very high probability from any
and repair) only slightly greater in number than the original number set of symbols (source and repair) only slightly greater in number
of source packets. than the original number of source symbols. The RaptorQ code
additionally has the property that the probability that the original
group of source symbols can be recovered from a set of symbols
(source and repair) equal in number to the original number of source
symbols is in many cases also very high.
[I-D.ietf-fecframe-raptor] defines three FEC Schemes for the use of [I-D.ietf-fecframe-raptor] defines six FEC Schemes for the use of the
the Raptor code with arbitary packet flows: the first scheme is fully Raptor and RaptorQ codes with arbitary packet flows: the first two
applicable to arbitary packet flows. The second scheme is a slightly schemes are fully applicable to arbitary packet flows (using Raptor
optimised version of the first scheme which is applicable in and RaptorQ respectively). The third and fourth schemes are slightly
applications with relatively small block sizes. The third scheme is optimised versions of the first two schemes which are applicable in
a variant of the second scheme which is applicable to a single source applications with relatively small block sizes. The fifth and sixth
flow which already has some kind of identifiable sequence number. schemes are variants of the third and fourth schemes which are
The presence of a sequence number in the source flow allows for applicable to a single source flow which already has some kind of
backwards compatible operation (the source flows do not need to be identifiable sequence number. The presence of a sequence number in
modified in order to apply FEC). In this case, in the language of the source flow allows for backwards compatible operation (the source
the FEC Framework, there is no explicit FEC Source Payload Id. 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
explicit FEC Source Payload Id and it is therefore not included in
the packets.
4. Payload Format 4. Payload Format
The RTP Payload contains a FEC Repair Payload as defined in
[I-D.ietf-fecframe-raptor].
4.1. RTP Header Usage 4.1. RTP Header Usage
The rules SHALL be followed for the RTP header used with FEC repair The following rules SHALL be followed for the RTP header used with
packets: FEC repair packets:
o Marker bit: The marker bit shall be set 1 for the last protection o Marker bit: The marker bit SHALL be set 1 for the last protection
RTP packet sent for each source block, and otherwise set to 0 RTP packet sent for each source block, and otherwise set to 0
o Timestamp: The timestamp SHALL be set to a time corresponding to o Timestamp: The timestamp SHALL be set to a time corresponding to
the packet's transmission time. The timestamp value has no use in the packet's transmission time. The timestamp value has no use in
the actual FEC protection process. It may be used for packet the actual FEC protection process. It may be used for packet
arrival timing and jitter calculations. arrival timing and jitter calculations. The timestamp rate SHALL
be specified using the "rate" media type parameter defined below.
Other header fields SHALL be set according to the rules of [RFC3550].
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
The RTP Payload contains a FEC Repair Payload as defined in Procedures and data formats for the use of Raptor Forward Error
Correction in an FECFRAME context are fully defined in
[I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-framework] and
are not duplicated here. The procedures of those documents SHALL be
followed in order to generate repair data streams to be carried by
the payload formats defined in this document.
The RTP Payload SHALL contain an FEC Repair Payload as defined in
[I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor]. [I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-raptor].
5. Congestion Control Considerations 5. Congestion Control Considerations
See [I-D.ietf-fecframe-framework]. See [I-D.ietf-fecframe-framework].
6. Media Types 6. Media Types
6.1. Registration of the application/raptorfec media type 6.1. Registration of the application/raptorfec media type
skipping to change at page 8, line 21 skipping to change at page 8, line 21
the template of [RFC4288]. 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:
rate: The RTP timestamp (clock) rate. The rate SHALL be larger
than 1000 Hz to provide sufficient resolution to RTCP operations.
However, it is RECOMMENDED to select the rate that matches the
rate of the protected source RTP stream.
raptor-scheme-id: The value of this parameter is the FEC Scheme Id 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]. [I-D.ietf-fecframe-raptor].
max-sbl: The value of this parameter is the FEC Object Kmax: The value of this parameter is the FEC Framework
Transmission Information element "Maximum Source Block Length" as Configuration Information element "Maximum Source Block Length" as
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal defined in [I-D.ietf-fecframe-raptor] encoded as a decimal
integer. integer.
symbol-size: The value of this parameter is the FEC Object T: The value of this parameter is the FEC Framework Configuration
Transmission Information element "Encoding Symbol Size" as Information element "Encoding Symbol Size" as defined in
definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal [I-D.ietf-fecframe-raptor] encoded as a decimal integer.
integer.
Optional parameters: none repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window
is specified in microseconds.
Optional parameters:
P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in
[I-D.ietf-fecframe-raptor]. If this parameter is missing that the
value "A" shall be assumed.
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 security consideration in
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
Applications that use this media type: Applications that use this media type:
Additional information: Additional information:
skipping to change at page 9, line 36 skipping to change at page 9, line 49
template of [RFC4288]. 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:
rate: The RTP timestamp (clock) rate. The rate SHALL be larger
than 1000 Hz to provide sufficient resolution to RTCP operations.
However, it is RECOMMENDED to select the rate that matches the
rate of the protected source RTP stream.
raptor-scheme-id: The value of this parameter is the FEC Scheme Id 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] [I-D.ietf-fecframe-raptor].
max-sbl: The value of this parameter is the FEC Object Kmax: The value of this parameter is the FEC Framework
Transmission Information element "Maximum Source Block Length" as Configuration Information element "Maximum Source Block Length" as
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal defined in [I-D.ietf-fecframe-raptor] encoded as a decimal
integer. integer.
symbol-size: The value of this parameter is the FEC Object T: The value of this parameter is the FEC Framework Configuration
Transmission Information element "Encoding Symbol Size" as Information element "Encoding Symbol Size" as defined in
definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal [I-D.ietf-fecframe-raptor] encoded as a decimal integer.
integer.
repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window
is specified in microseconds.
Optional parameters:
P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in
[I-D.ietf-fecframe-raptor]. If this parameter is missing that the
value "A" shall be assumed.
Optional parameters: none
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 security consideration in
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
skipping to change at page 11, line 5 skipping to change at page 11, line 29
template of [RFC4288]. 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:
rate: The RTP timestamp (clock) rate. The rate SHALL be larger
than 1000 Hz to provide sufficient resolution to RTCP operations.
However, it is RECOMMENDED to select the rate that matches the
rate of the protected source RTP stream.
raptor-scheme-id: The value of this parameter is the FEC Scheme Id 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] [I-D.ietf-fecframe-raptor].
max-sbl: The value of this parameter is the FEC Object Kmax: The value of this parameter is the FEC Framework
Transmission Information element "Maximum Source Block Length" as Configuration Information element "Maximum Source Block Length" as
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal defined in [I-D.ietf-fecframe-raptor] encoded as a decimal
integer. integer.
symbol-size: The value of this parameter is the FEC Object T: The value of this parameter is the FEC Framework Configuration
Transmission Information element "Encoding Symbol Size" as Information element "Encoding Symbol Size" as defined in
definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal [I-D.ietf-fecframe-raptor] encoded as a decimal integer.
integer.
Optional parameters: none repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window
is specified in microseconds.
Optional parameters:
P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in
[I-D.ietf-fecframe-raptor]. If this parameter is missing that the
value "A" shall be assumed.
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 security consideration in
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
skipping to change at page 12, line 20 skipping to change at page 13, line 13
template of [RFC4288]. 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:
rate: The RTP timestamp (clock) rate. The rate SHALL be larger
than 1000 Hz to provide sufficient resolution to RTCP operations.
However, it is RECOMMENDED to select the rate that matches the
rate of the protected source RTP stream.
raptor-scheme-id: The value of this parameter is the FEC Scheme Id 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] [I-D.ietf-fecframe-raptor].
max-sbl: The value of this parameter is the FEC Object Kmax: The value of this parameter is the FEC Framework
Transmission Information element "Maximum Source Block Length" as Configuration Information element "Maximum Source Block Length" as
defined in [I-D.ietf-fecframe-raptor] encoded as a decimal defined in [I-D.ietf-fecframe-raptor] encoded as a decimal
integer. integer.
symbol-size: The value of this parameter is the FEC Object T: The value of this parameter is the FEC Framework Configuration
Transmission Information element "Encoding Symbol Size" as Information element "Encoding Symbol Size" as defined in
definedf in [I-D.ietf-fecframe-raptor] encoded as a decimal [I-D.ietf-fecframe-raptor] encoded as a decimal integer.
integer.
Optional parameters: none repair-window: The maximum time that spans the source packets and
the corresponding repair packets. The size of the repair window
is specified in microseconds.
Optional parameters:
P: The value of this parameter is the FEC Framework Configuration
Information element "Payload ID Format" as defined in
[I-D.ietf-fecframe-raptor]. If this parameter is missing that the
value "A" shall be assumed.
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 security consideration in
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Interoperability considerations: Interoperability considerations:
Published specification: [I-D.ietf-fecframe-raptor] Published specification: [I-D.ietf-fecframe-raptor]
skipping to change at page 14, line 7 skipping to change at page 15, line 7
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: Mark Watson, Qualcomm Inc. Author: Mark Watson, Qualcomm Inc.
Change controller: IETF Audio/Video Transport working group delegated Change controller: IETF Audio/Video Transport working group delegated
from the IESG. from the IESG.
7. Mapping to SDP 7. Mapping to SDP
Applications that are using RTP transport commonly use Session
Description Protocol (SDP) [RFC4566] to describe their RTP sessions.
The information that is used to specify the media types in an RTP
session has specific mappings to the fields in an SDP description.
Note that if an application does not use SDP to describe the RTP
sessions, an appropriate mapping must be defined and used to specify
the media types and their parameters for the control/description
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-
format-specific paraeters 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 SHALL be used to specify the FEC Media Type Parameters defined above SHALL be used to specify the FEC
Object Transmission Information in preference to the SDP attributes Framework Configuration Information in preference to the SDP
specified in [I-D.ietf-fecframe-sdp-elements] attributes specified in [I-D.ietf-fecframe-sdp-elements]
8. Offer/Answer considerations 8. Offer/Answer considerations
None. When offering Raptor FEC over RTP using SDP in an Offer/Answer model
[RFC3264], the following considerations apply:
o Each combination of the Kmax and T parameters produces different
FEC data and is not compatible with any other combination. A
sender application may desire to offer multiple offers with
different sets of Kmax and T values as long as the parameter
values are valid. The receiver SHOULD normally choose the offer
with the largest value of the product of Kmax and T that it
supports.
o The size of the repair-window is related to the maximum delay
between the transmission of a source packet and the associated
repair packet. This directly impacts the buffering requirement on
the receiver side and the receiver must consider this when
choosing an offer.
o When the P parameter is omitted, FEC Payload ID Format A MUST be
assumed. In an answer which selects an offer in which the P
parameter was omitted, the P parameter MUST either be omitted, or
included with value "A".
9. Declarative SDP Considerations 9. Declarative SDP Considerations
None. In declarative usage, like SDP in the Real-time Streaming Protocol
(RTSP) [RFC2326] or the Session Announcement Protocol (SAP)
[RFC2947], 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.
10. IANA Considerations 10. IANA Considerations
This memo requests that IANA registers application/raptorfec as This memo requests that IANA registers application/raptorfec as
specified in Section 6.1.1, video/raptorfec as specified in specified in Section 6.1.1, video/raptorfec as specified in
Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and Section 6.2.1, audio/raptorfec as specified in Section 6.3.1 and
text/raptorfec as specified in Section 6.4.1. The media type is also text/raptorfec as specified in Section 6.4.1. The media type is also
requested to be added to the IANA registry for "RTP Payload Format requested to be added to the IANA registry for "RTP Payload Format
MIME types" (http://www.iana.org/assignments/rtp-parameters). MIME types" (http://www.iana.org/assignments/rtp-parameters).
11. Security Considerations 11. Security Considerations
See [I-D.ietf-fecframe-framework] Security Considerations related to the use of the FEC Framework are
addressed in [I-D.ietf-fecframe-framework]. These consideration
apply in full to users of the RTP Payload Formats defined in this
document, since these are defined in terms of the FEC Framework.
No further security considerations related specifically to the Raptor
FEC Schemes defined in [I-D.ietf-fecframe-raptor] have been
identified.
Users of RTP should consider the Security Considerations of
[RFC3550].
12. References 12. 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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[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.
[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.
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework", Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-05 (work in progress), draft-ietf-fecframe-framework-06 (work in progress),
July 2009. March 2010.
[I-D.ietf-fecframe-sdp-elements] [I-D.ietf-fecframe-sdp-elements]
Begen, A., "SDP Elements for FEC Framework", Begen, A., "SDP Elements for FEC Framework",
draft-ietf-fecframe-sdp-elements-04 (work in progress), draft-ietf-fecframe-sdp-elements-04 (work in progress),
August 2009. August 2009.
[I-D.ietf-fecframe-raptor] [I-D.ietf-fecframe-raptor]
Watson, M., "Raptor FEC Schemes for FECFRAME", Watson, M., "Raptor FEC Schemes for FECFRAME",
draft-ietf-fecframe-raptor-01 (work in progress), draft-ietf-fecframe-raptor-01 (work in progress),
July 2009. July 2009.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2947] Altman, J., "Telnet Encryption: DES3 64 bit Cipher
Feedback", RFC 2947, September 2000.
Author's Address Author's Address
Mark Watson Mark Watson
Qualcomm Inc. Qualcomm Inc.
3165 Kifer Rd. 3165 Kifer Rd.
Santa Clara, CA 95051 Santa Clara, CA 95051
U.S.A. U.S.A.
Email: watson@qualcomm.com Email: watson@qualcomm.com
 End of changes. 43 change blocks. 
99 lines changed or deleted 233 lines changed or added

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