draft-ietf-fecframe-sdp-elements-03.txt   draft-ietf-fecframe-sdp-elements-04.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track June 4, 2009 Intended status: Standards Track August 19, 2009
Expires: December 6, 2009 Expires: February 20, 2010
SDP Elements for FEC Framework SDP Elements for FEC Framework
draft-ietf-fecframe-sdp-elements-03 draft-ietf-fecframe-sdp-elements-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 December 6, 2009. This Internet-Draft will expire on February 20, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 4 3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 4
3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 4 3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 4
3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 5 3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 5
3.3. FEC Framework Configuration Information . . . . . . . . . 6 3.3. FEC Framework Configuration Information . . . . . . . . . 6
4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 7 4. SDP Descriptors for FEC Framework . . . . . . . . . . . . . . 7
4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 8 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 8
4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 8 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 8
4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 10 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 9
4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 12 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 12
5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 13 5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 13
5.1. Declarative Considerations . . . . . . . . . . . . . . . . 13 5.1. Declarative Considerations . . . . . . . . . . . . . . . . 13
5.2. Offer/Answer Model Considerations . . . . . . . . . . . . 13 5.2. Offer/Answer Model Considerations . . . . . . . . . . . . 13
5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.1. One Source Flow, One Repair Flow and One FEC Scheme . 14 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme . 14
5.3.2. Two Source Flows, One Repair Flow and One FEC 5.3.2. Two Source Flows, One Repair Flow and One FEC
Scheme . . . . . . . . . . . . . . . . . . . . . . . . 15 Scheme . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.3. Two Source Flows, Two Repair Flows and Two FEC 5.3.3. Two Source Flows, Two Repair Flows and Two FEC
Schemes . . . . . . . . . . . . . . . . . . . . . . . 16 Schemes . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 17 7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 17
7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 18 7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. draft-ietf-fecframe-sdp-elements-03 . . . . . . . . . . . 19 9.1. draft-ietf-fecframe-sdp-elements-04 . . . . . . . . . . . 19
9.2. draft-ietf-fecframe-sdp-elements-02 . . . . . . . . . . . 19 9.2. draft-ietf-fecframe-sdp-elements-03 . . . . . . . . . . . 19
9.3. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 19 9.3. draft-ietf-fecframe-sdp-elements-02 . . . . . . . . . . . 19
9.4. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 19 9.4. draft-ietf-fecframe-sdp-elements-01 . . . . . . . . . . . 19
9.5. draft-ietf-fecframe-sdp-elements-00 . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Forward Error Correction (FEC) Framework, described in The Forward Error Correction (FEC) Framework, described in
[I-D.ietf-fecframe-framework], outlines a general framework for using [I-D.ietf-fecframe-framework], outlines a general framework for using
FEC-based error recovery in packet flows carrying media content. FEC-based error recovery in packet flows carrying media content.
skipping to change at page 7, line 14 skipping to change at page 7, line 14
4. The length of the Explicit Source FEC Payload ID (in bytes). 4. The length of the Explicit Source FEC Payload ID (in bytes).
This value MAY be zero indicating that no Explicit Source FEC This value MAY be zero indicating that no Explicit Source FEC
Payload ID is used by the FEC scheme. If it is nonzero, however, Payload ID is used by the FEC scheme. If it is nonzero, however,
it means that the Explicit Source FEC Payload ID is used. In this it means that the Explicit Source FEC Payload ID is used. In this
case, only one FEC scheme MUST be used for this source flow, case, only one FEC scheme MUST be used for this source flow,
unless the generic tag (defined in [I-D.ietf-fecframe-framework]) unless the generic tag (defined in [I-D.ietf-fecframe-framework])
is used by all of the FEC schemes protecting this source flow. is used by all of the FEC schemes protecting this source flow.
5. An opaque container for the FEC-Scheme-Specific Information (FSSI) 5. A container for the FEC-Scheme-Specific Information (FSSI) that is
that is required by only the receiver or by both the receiver and required by only the receiver or by both the receiver and sender.
sender.
6. Another opaque container for the FSSI that is only required by the 6. Another container for the FSSI that is only required by the
sender. This is referred to as the Sender-Side FEC-Scheme- sender. This is referred to as the Sender-Side FEC-Scheme-
Specific Information (SS-FSSI). Specific Information (SS-FSSI).
FSSI includes the information that is specific to the FEC scheme used FSSI includes the information that is specific to the FEC scheme used
by the CDP. FSSI is used to communicate the information that cannot by the CDP. FSSI is used to communicate the information that cannot
be adequately represented otherwise and is essential for proper FEC be adequately represented otherwise and is essential for proper FEC
encoding and decoding operations. The motivation behind separating encoding and decoding operations. The motivation behind separating
the FSSI required only by the sender from the rest of the FSSI is to the FSSI required only by the sender from the rest of the FSSI is to
provide the receiver or the 3rd party entities a means of controlling provide the receiver or the third party entities a means of
the FEC operations at the sender. Any FSSI other than the one solely controlling the FEC operations at the sender. Any FSSI other than
required by the sender MUST be communicated via the FSSI container. the one solely required by the sender MUST be communicated via the
FSSI container.
The variable-length opaque SS-FSSI and FSSI containers transmit the
information in the form of an octet string. The FEC schemes define
the structure of this octet string, which MAY contain multiple
distinct elements. If the FEC scheme does not require any specific
information, the FSSI MAY be null. For the fully-specified FEC
schemes, a full description of the encoded information in both
containers MUST be provided. See [I-D.ietf-fecframe-framework] for
details.
Editor's note: Should we mandate base64 encoding for these fields in The variable-length SS-FSSI and FSSI containers transmit the
SDP? information in textual representation and MAY contain multiple
distinct elements. For the fully-specified FEC schemes, a full
description of these elements for both containers MUST be provided.
If the FEC scheme does not require any specific information, the FSSI
MAY be null.
Editor's note: When RTP transport is used for the source and/or Note that when RTP transport is used for the source and/or repair
repair flows, the information included in the FSSI/SS-FSSI containers flows, the information in the FSSI/SS-FSSI containers will be carried
will be carried via the format-specific parameters ("a=fmtp" line). via the format-specific parameters (i.e., "a=fmtp" line).
4. SDP Descriptors for FEC Framework 4. SDP Descriptors for FEC Framework
This section defines the SDP elements that MUST be used to describe This section defines the SDP elements that MUST be used to describe
the FEC Framework Configuration Information in multimedia sessions by the FEC Framework Configuration Information in multimedia sessions by
the CDPs that choose SDP [RFC4566] as their session description the CDPs that choose SDP [RFC4566] as their session description
protocol. Example SDP configurations can be found in Section 5. protocol. Example SDP configurations can be found in Section 5.
4.1. Transport Protocol Identifiers 4.1. Transport Protocol Identifiers
skipping to change at page 11, line 36 skipping to change at page 11, line 36
The OPTIONAL parameter 'preference-lvl' is used to indicate the The OPTIONAL parameter 'preference-lvl' is used to indicate the
preferred order of using the repair flows. The exact usage of the preferred order of using the repair flows. The exact usage of the
parameter 'preference-lvl' and the pertaining rules MAY be defined by parameter 'preference-lvl' and the pertaining rules MAY be defined by
the FEC scheme or the CDP. If no value is specified for the the FEC scheme or the CDP. If no value is specified for the
parameter 'preference-lvl', it means that the receiver(s) MAY receive parameter 'preference-lvl', it means that the receiver(s) MAY receive
and use the repair flows in any order. However, if a preference and use the repair flows in any order. However, if a preference
level is assigned to the repair flow(s), the receivers are encouraged level is assigned to the repair flow(s), the receivers are encouraged
to follow the specified order in receiving and using the repair to follow the specified order in receiving and using the repair
flow(s). flow(s).
The OPTIONAL parameters 'ss-fssi' and 'fssi' are opaque containers to The OPTIONAL parameters 'ss-fssi' and 'fssi' are containers to convey
convey the FEC-Scheme-Specific Information (FSSI) that includes the the FEC-Scheme-Specific Information (FSSI) that includes the
information that is specific to the FEC scheme used by the CDP and is information that is specific to the FEC scheme used by the CDP and is
necessary for proper FEC encoding and decoding operations. The FSSI necessary for proper FEC encoding and decoding operations. The FSSI
required only by the sender (called Sender-Side FSSI) MUST be required only by the sender (called Sender-Side FSSI) MUST be
communicated in the container specified by the parameter 'ss-fssi'. communicated in the container specified by the parameter 'ss-fssi'.
Any other FSSI MUST be communicated in the container specified by the Any other FSSI MUST be communicated in the container specified by the
parameter 'fssi'. In both containers, FSSI is transmitted in the parameter 'fssi'. In both containers, FSSI is transmitted in the
form of an octet string. The FEC schemes define the structure of form of textual representation and MAY contain multiple distinct
this octet string, which MAY contain multiple distinct elements. If elements. If the FEC scheme does not require any specific
the FEC scheme does not require any specific information, the 'ss- information, the 'ss-fssi' and 'fssi' parameters MAY be null and
fssi' and 'fssi' parameters MAY be null and ignored. ignored.
4.6. Repair Window 4.6. Repair Window
An FEC encoder processes a block of source packets and generates a An FEC encoder processes a block of source packets and generates a
number of repair packets, which are then transmitted within a certain number of repair packets, which are then transmitted within a certain
duration. At the receiver side, the FEC decoder tries to decode all duration. At the receiver side, the FEC decoder tries to decode all
the packets received within the repair window to recover the missing the packets received within the repair window to recover the missing
packets, if there are any. Repair window stands for the time that packets, if there are any. Repair window stands for the time that
spans the source packets and the corresponding repair packets. spans the source packets and the corresponding repair packets.
Assuming that there is no issue of delay variation, the FEC decoder Assuming that there is no issue of delay variation, the FEC decoder
SHOULD NOT wait longer than the repair window since additional SHOULD NOT wait longer than the repair window since additional
waiting would not help the recovery process. waiting would not help the recovery process.
This document specifies a new attribute to describe the size of the This document specifies a new attribute to describe the size of the
repair window in milliseconds and microseconds. repair window in milliseconds and microseconds.
The syntax for the attribute in ABNF is as follows: The syntax for the attribute in ABNF is as follows:
repair-window-line = "a=repair-window:" window-size repair-window-line = "a=repair-window:" window-size
[SP unit] CRLF [unit] CRLF
window-size = 1*DIGIT window-size = 1*DIGIT
unit = ms / us unit = ms / us
<unit> is the unit of time the repair window size is specified with. <unit> is the unit of time the repair window size is specified with.
Currently, two units are defined: "ms", which stands for Currently, two units are defined: 'ms', which stands for
milliseconds and "us", which stands for microseconds. The default milliseconds and 'us', which stands for microseconds. The default
unit is "ms". Alternative units MAY be defined in the future by unit is 'ms'. Alternative units MAY be defined in the future by
registering them with IANA. registering them with IANA.
The 'a=repair-window' attribute is a media-level attribute since each The 'a=repair-window' attribute is a media-level attribute since each
repair flow MAY have a different repair window size. repair flow MAY have a different repair window size.
Specifying the repair window size in an absolute time value may not
correspond to an integer number of packets or exactly match with the
clock rate used in RTP (in case of RTP transport) causing mismatchs
among subsequent repair windows. However, in practice, this mismatch
does not break anything in the FEC decoding process.
4.7. Bandwidth Specification 4.7. Bandwidth Specification
The bandwidth specification as defined in [RFC4566] denotes the The bandwidth specification as defined in [RFC4566] denotes the
proposed bandwidth to be used by the session or media. The proposed bandwidth to be used by the session or media. The
specification of bandwidth is OPTIONAL. specification of bandwidth is OPTIONAL.
In the context of the FEC Framework, the bandwidth specification can In the context of the FEC Framework, the bandwidth specification can
be used to express the bandwidth of the repair flows or the bandwidth be used to express the bandwidth of the repair flows or the bandwidth
of the session. If included in the SDP, it SHALL adhere to the of the session. If included in the SDP, it SHALL adhere to the
following rules: following rules:
skipping to change at page 14, line 7 skipping to change at page 14, line 15
Receivers supporting the SDP Capability Negotiation Framework Receivers supporting the SDP Capability Negotiation Framework
[I-D.ietf-mmusic-sdp-capability-negotiation] MAY also use this [I-D.ietf-mmusic-sdp-capability-negotiation] MAY also use this
framework to negotiate all or a subset of the FEC Framework framework to negotiate all or a subset of the FEC Framework
parameters. parameters.
The backward compatibility in offer/answer model is handled as The backward compatibility in offer/answer model is handled as
specified in [I-D.ietf-mmusic-rfc4756bis]. specified in [I-D.ietf-mmusic-rfc4756bis].
5.3. Examples 5.3. Examples
Editor's note: As of now, no FEC Encoding ID has been registered
with IANA. In the examples below, an FEC Encoding ID of zero will be
used for illustrative purposes. Artificial content for the SS-FSSI
and FSSI will also be provided.
[I-D.ietf-mmusic-rfc3388bis] defines the media stream identification [I-D.ietf-mmusic-rfc3388bis] defines the media stream identification
attribute ('mid') as a token in ABNF. In contrast, the identifiers attribute ('mid') as a token in ABNF. In contrast, the identifiers
for the source flows MUST be integers and SHOULD be allocated for the source flows MUST be integers and SHOULD be allocated
starting from zero and increasing by one for each flow. To avoid any starting from zero and increasing by one for each flow. To avoid any
ambiguity, using the same values for identifying the media streams ambiguity, using the same values for identifying the media streams
and source flows is NOT RECOMMENDED, even when 'mid' values are and source flows is NOT RECOMMENDED, even when 'mid' values are
integers. integers.
In the examples below, an FEC Encoding ID of zero will be used for
illustrative purposes. Artificial content for the SS-FSSI and FSSI
will also be provided.
5.3.1. One Source Flow, One Repair Flow and One FEC Scheme 5.3.1. One Source Flow, One Repair Flow and One FEC Scheme
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
0: Source Flow |---------| 1: Repair Flow 0: Source Flow |---------| 1: Repair Flow
| |
Figure 2: Scenario #1 Figure 2: Scenario #1
In this example, we have one source video flow (mid:S1) and one FEC In this example, we have one source video flow (mid:S1) and one FEC
repair flow (mid:R1). We form one FEC group with the "a=group:FEC-XR repair flow (mid:R1). We form one FEC group with the "a=group:FEC-XR
skipping to change at page 15, line 17 skipping to change at page 15, line 17
s=FEC Framework Examples s=FEC Framework Examples
t=0 0 t=0 0
a=group:FEC-XR S1 R1 a=group:FEC-XR 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 udp/fec m=application 30000 udp/fec
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150 a=repair-window:150
a=mid:R1 a=mid:R1
5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme 5.3.2. Two Source Flows, One Repair Flow and One FEC Scheme
SOURCE FLOWS SOURCE FLOWS
0: Source Flow | | INSTANCE #1 0: Source Flow | | INSTANCE #1
|---------| 2: Repair Flow |---------| 2: Repair Flow
1: Source Flow | 1: Source Flow |
skipping to change at page 16, line 22 skipping to change at page 16, line 22
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=video 30000 RTP/AVP 101 m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000 a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1 a=fec-source-flow: id=1
a=mid:S2 a=mid:S2
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 233.252.0.3/127 c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150500 us a=repair-window:150500 us
a=mid:R1 a=mid:R1
5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 5.3.3. Two Source Flows, Two Repair Flows and Two FEC Schemes
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
0: Source Flow |---------| 2: Repair Flow 0: Source Flow |---------| 2: Repair Flow
1: Source Flow |---------| INSTANCE #2 1: Source Flow |---------| INSTANCE #2
| 3: Repair Flow | 3: Repair Flow
skipping to change at page 17, line 23 skipping to change at page 17, line 23
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=video 30000 RTP/AVP 101 m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000 a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1 a=fec-source-flow: id=1
a=mid:S2 a=mid:S2
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 233.252.0.3/127 c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; fssi=4W5S6X a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:200 ms a=repair-window:200 ms
a=mid:R1 a=mid:R1
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 233.252.0.4/127 c=IN IP4 233.252.0.4/127
a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; fssi=456WSX a=fec-repair-flow: encoding-id=0; ss-fssi=n:14,k:10
a=repair-window:400 ms a=repair-window:400 ms
a=mid:R2 a=mid:R2
6. Security Considerations 6. Security Considerations
There is a weak threat if the SDP is modified in a way that it shows There is a weak threat if the SDP is modified in a way that it shows
incorrect association and/or grouping of the source and repair flows. incorrect association and/or grouping of the source and repair flows.
Such attacks may result in failure of FEC protection and/or Such attacks may result in failure of FEC protection and/or
mishandling of other media streams. It is RECOMMENDED that the mishandling of other media streams. It is RECOMMENDED that the
receiver SHOULD do integrity check on SDP and follow the security receiver SHOULD do integrity check on SDP and follow the security
skipping to change at page 18, line 7 skipping to change at page 18, line 7
7. IANA Considerations 7. IANA Considerations
7.1. Transport Protocols 7.1. Transport Protocols
The 'proto' sub-field of the media description line ("m=") describes The 'proto' sub-field of the media description line ("m=") describes
the transport protocol used. This document registers the following the transport protocol used. This document registers the following
values: values:
UDP/FEC UDP/FEC
Editor's note: Additional transport protocols to be registered are
TBD.
7.2. Attribute Names 7.2. Attribute Names
As recommended by [RFC4566], the following attribute names should be As recommended by [RFC4566], the following attribute names should be
registered with IANA. registered with IANA.
The contact information for the registrations is: The contact information for the registrations is:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
skipping to change at page 19, line 12 skipping to change at page 19, line 7
Reference: This document Reference: This document
Values: See this document Values: See this document
8. Acknowledgments 8. Acknowledgments
The author would like to thank the FEC Framework Design Team for The author would like to thank the FEC Framework Design Team for
their inputs, suggestions and contributions. their inputs, suggestions and contributions.
9. Change Log 9. Change Log
9.1. draft-ietf-fecframe-sdp-elements-03 9.1. draft-ietf-fecframe-sdp-elements-04
The following are the major changes compared to version 03:
o Incorporated final outstanding issues for the WGLC.
9.2. draft-ietf-fecframe-sdp-elements-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o Now referencing to 3388bis and 4756bis instead of RFC 3388 and RFC o Now referencing to 3388bis and 4756bis instead of RFC 3388 and RFC
4756, respectively. Also cleaned up the editor's notes regarding 4756, respectively. Also cleaned up the editor's notes regarding
the grouping issues. the grouping issues.
o Parameter "priority" has been replaced with "preference-lvl" for o Parameter "priority" has been replaced with "preference-lvl" for
the repair flows. the repair flows.
9.2. draft-ietf-fecframe-sdp-elements-02 9.3. draft-ietf-fecframe-sdp-elements-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o Clarified the definitions for the FSSI fields. o Clarified the definitions for the FSSI fields.
o Hostnames in the SDP examples are fixed. o Hostnames in the SDP examples are fixed.
9.3. draft-ietf-fecframe-sdp-elements-01 9.4. draft-ietf-fecframe-sdp-elements-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o Additive repair flows can now be from different instances. The o Additive repair flows can now be from different instances. The
sender may also assign different levels of priorities to each sender may also assign different levels of priorities to each
repair flow regardless of whether the repair flows are additive or repair flow regardless of whether the repair flows are additive or
not. not.
o SDP examples are fixed. o SDP examples are fixed.
o Comments posted in the mailing list are incorporated. o Comments posted in the mailing list are incorporated.
9.4. draft-ietf-fecframe-sdp-elements-00 9.5. draft-ietf-fecframe-sdp-elements-00
This is the initial version, which is based on an earlier individual This is the initial version, which is based on an earlier individual
submission. The following are the major changes compared to that submission. The following are the major changes compared to that
document: document:
o The opaque container in the FEC Framework Configuration o The opaque container in the FEC Framework Configuration
Information (FEC-Scheme-Specific Information) is now divided into Information (FEC-Scheme-Specific Information) is now divided into
two parts: information needed only by the sender and information two parts: information needed only by the sender and information
needed by the receiver. The repair flow descriptors are also needed by the receiver. The repair flow descriptors are also
updated accordingly. updated accordingly.
skipping to change at page 20, line 27 skipping to change at page 20, line 27
framework draft. framework draft.
o Some other editorial changes. o Some other editorial changes.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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-03 (work in progress), draft-ietf-fecframe-framework-05 (work in progress),
October 2008. July 2009.
[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.
[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.
[RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol
(SDP) Source Filters", RFC 4570, July 2006. (SDP) Source Filters", RFC 4570, July 2006.
[I-D.ietf-mmusic-rfc3388bis] [I-D.ietf-mmusic-rfc3388bis]
Camarillo, G., "The SDP (Session Description Protocol) Camarillo, G., "The SDP (Session Description Protocol)
Grouping Framework", draft-ietf-mmusic-rfc3388bis-02 (work Grouping Framework", draft-ietf-mmusic-rfc3388bis-03 (work
in progress), January 2009. in progress), July 2009.
[I-D.ietf-mmusic-rfc4756bis] [I-D.ietf-mmusic-rfc4756bis]
Begen, A., "Forward Error Correction Grouping Semantics in Begen, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", Session Description Protocol",
draft-ietf-mmusic-rfc4756bis-02 (work in progress), draft-ietf-mmusic-rfc4756bis-02 (work in progress),
April 2009. April 2009.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)", Modifier for the Session Description Protocol (SDP)",
RFC 3890, September 2004. RFC 3890, September 2004.
 End of changes. 29 change blocks. 
61 lines changed or deleted 65 lines changed or added

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