draft-ietf-fecframe-sdp-elements-08.txt   draft-ietf-fecframe-sdp-elements-09.txt 
FEC Framework A. Begen FEC Framework A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track August 12, 2010 Intended status: Standards Track September 26, 2010
Expires: February 13, 2011 Expires: March 30, 2011
Session Description Protocol (SDP) Elements for FEC Framework Session Description Protocol Elements for FEC Framework
draft-ietf-fecframe-sdp-elements-08 draft-ietf-fecframe-sdp-elements-09
Abstract Abstract
This document specifies the use of Session Description Protocol (SDP) This document specifies the use of Session Description Protocol (SDP)
to describe the parameters required to signal the Forward Error to describe the parameters required to signal the Forward Error
Correction (FEC) Framework Configuration Information between the Correction (FEC) Framework Configuration Information between the
sender(s) and receiver(s). This document also provides examples that sender(s) and receiver(s). This document also provides examples that
show the semantics for grouping multiple source and repair flows show the semantics for grouping multiple source and repair flows
together for the applications that simultaneously use multiple together for the applications that simultaneously use multiple
instances of the FEC Framework. instances of the FEC Framework.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 13, 2011. This Internet-Draft will expire on March 30, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 5 3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 5
3.3. FEC Framework Configuration Information . . . . . . . . . 5 3.3. FEC Framework Configuration Information . . . . . . . . . 5
4. SDP Elements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. SDP Elements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6
4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 7
4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 7 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 7
4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Repair Window . . . . . . . . . . . . . . . . . . . . . . 10
4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 11 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 11
5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 12 5. Scenarios and Examples . . . . . . . . . . . . . . . . . . . . 11
5.1. Declarative Considerations . . . . . . . . . . . . . . . . 12 5.1. Declarative Considerations . . . . . . . . . . . . . . . . 11
5.2. Offer/Answer Model Considerations . . . . . . . . . . . . 12 5.2. Offer/Answer Model Considerations . . . . . . . . . . . . 12
6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. One Source Flow, One Repair Flow and One FEC Scheme . . . 13 6.1. One Source Flow, One Repair Flow and One FEC Scheme . . . 12
6.2. Two Source Flows, One Repair Flow and One FEC Scheme . . . 13 6.2. Two Source Flows, One Repair Flow and One FEC Scheme . . . 13
6.3. Two Source Flows, Two Repair Flows and Two FEC Schemes . . 14 6.3. Two Source Flows, Two Repair Flows and Two FEC Schemes . . 14
6.4. One Source Flow, Two Repair Flows and Two FEC Schemes . . 15 6.4. One Source Flow, Two Repair Flows and Two FEC Schemes . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. Registration of Transport Protocols . . . . . . . . . . . 16 8.1. Registration of Transport Protocols . . . . . . . . . . . 16
8.2. Registration of SDP Attributes . . . . . . . . . . . . . . 17 8.2. Registration of SDP Attributes . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
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.
While a continuous signaling between the sender(s) and receiver(s) is While a continuous signaling between the sender(s) and receiver(s) is
not required for a Content Delivery Protocol (CDP) that uses the FEC not required for a Content Delivery Protocol (CDP) that uses the FEC
skipping to change at page 6, line 19 skipping to change at page 6, line 19
b. An integer identifier for this flow definition (i.e., tuple). b. An integer identifier for this flow definition (i.e., tuple).
This identifier MUST be unique amongst all source flows that are This identifier MUST be unique amongst all source flows that are
protected by the same FEC repair flow. The identifiers SHOULD be protected by the same FEC repair flow. The identifiers SHOULD be
allocated starting from zero and increasing by one for each flow. allocated starting from zero and increasing by one for each flow.
A source flow identifier need not be carried in source packets A source flow identifier need not be carried in source packets
since source packets are directly associated with a flow by virtue since source packets are directly associated with a flow by virtue
of their packet headers. of their packet headers.
3. The FEC Encoding ID, identifying the FEC scheme. 3. The FEC Encoding ID, identifying the FEC scheme.
4. The length of the Explicit Source FEC Payload ID (in bytes). 4. The length of the Explicit Source FEC Payload ID (in octets).
5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, each 5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, each
consisting of a name and a value where the valid element names and consisting of a name and a value where the valid element names and
value ranges are defined by the FEC scheme. value ranges are defined by the FEC scheme.
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 (which is carried in Sender-Side the FSSI required only by the sender (which is carried in Sender-Side
skipping to change at page 8, line 5 skipping to change at page 8, line 5
4.4. Source Flows 4.4. Source Flows
The FEC Framework allows that multiple source flows MAY be grouped The FEC Framework allows that multiple source flows MAY be grouped
and protected together by a single or multiple FEC Framework and protected together by a single or multiple FEC Framework
instances. For this reason, as described in Section 3.3, individual instances. For this reason, as described in Section 3.3, individual
source flows MUST be identified with unique identifiers. For this source flows MUST be identified with unique identifiers. For this
purpose, we introduce the attribute 'fec-source-flow'. purpose, we introduce the attribute 'fec-source-flow'.
The syntax for the new attribute in ABNF [RFC5234] is as follows: The syntax for the new attribute in ABNF [RFC5234] is as follows:
fec-source-flow-line = "a=fec-source-flow:" source-id fec-source-flow-line = "a=fec-source-flow:" SP source-id
[";" SP tag-length] CRLF [";" SP tag-length] CRLF
source-id = "id=" src-id source-id = "id=" src-id
src-id = 1*DIGIT src-id = 1*DIGIT
tag-length = "tag-len=" tlen tag-length = "tag-len=" tlen
tlen = *DIGIT tlen = %x31-39 *DIGIT
The REQUIRED parameter 'id' is used to identify the source flow. The REQUIRED parameter 'id' is used to identify the source flow.
Parameter 'id' MUST be an integer. Parameter 'id' MUST be an integer.
The OPTIONAL 'tag-len' parameter is used to specify the length of the The 'tag-len' parameter is used to specify the length of the Explicit
Explicit Source FEC Payload ID field (in bytes). If no value is Source FEC Payload ID field (in octets). In the case that an
specified for the 'tag-len' parameter, it indicates a value of zero. Explicit Source FEC Payload ID is used, the 'tag-len' parameter MUST
However, in the case that an Explicit Source FEC Payload ID is used, exist and indicate its length. Otherwise, the 'tag-len' parameter
the 'tag-len' parameter MUST exist and indicate its length. MUST NOT exist.
4.5. Repair Flows 4.5. Repair Flows
A repair flow MUST contain only repair packets formatted as described A repair flow MUST contain only repair packets formatted as described
in [I-D.ietf-fecframe-framework] for a single FEC Framework instance, in [I-D.ietf-fecframe-framework] for a single FEC Framework instance,
i.e., packets belonging to source flows or other repair flows from a i.e., packets belonging to source flows or other repair flows from a
different FEC Framework instance cannot be sent within this flow. We different FEC Framework instance cannot be sent within this flow. We
introduce the attribute 'fec-repair-flow' to describe the repair introduce the attribute 'fec-repair-flow' to describe the repair
flows. flows.
The syntax for the new attribute in ABNF is as follows: The syntax for the new attribute in ABNF is as follows (CHAR and CTL
are defined in [RFC5234]):
fec-repair-flow-line = "a=fec-repair-flow:" SP fec-encoding-id fec-repair-flow-line = "a=fec-repair-flow:" SP fec-encoding-id
[";" SP flow-preference] [";" SP flow-preference]
[";" SP sender-side-scheme-specific] [";" SP sender-side-scheme-specific]
[";" SP scheme-specific] CRLF [";" SP scheme-specific] CRLF
fec-encoding-id = "encoding-id=" enc-id fec-encoding-id = "encoding-id=" enc-id
enc-id = 1*DIGIT ; FEC Encoding ID enc-id = 1*DIGIT ; FEC Encoding ID
flow-preference = "preference-lvl=" preference-level-of-the-flow flow-preference = "preference-lvl=" preference-level-of-the-flow
preference-level-of-the-flow = *DIGIT preference-level-of-the-flow = 1*DIGIT
sender-side-scheme-specific = "ss-fssi=" sender-info sender-side-scheme-specific = "ss-fssi=" sender-info
sender-info = [ element *( ',' element ) ] sender-info = element *( "," element )
element = name ':' value element = name ":" value
name = token name = token
token = 1*<any CHAR except CTLs or separators> token = 1*<any CHAR except CTLs or separators>
value = *<any CHAR except CTLs or separators> value = *<any CHAR except CTLs or separators>
separator = "(" | ")" | "<" | ">" | "@" separator = "(" / ")" / "<" / ">" / "@"
| "," | ";" | ":" | "\" | <"> / "," / ";" / ":" / "\" / <">
| "/" | "[" | "]" | "?" | "=" / "/" / "[" / "]" / "?" / "="
| "{" | "}" | SP | HT / "{" / "}" / SP / HTAB
scheme-specific = "fssi=" scheme-info scheme-specific = "fssi=" scheme-info
scheme-info = [ element *( ',' element ) ] scheme-info = element *( "," element )
element = name ':' value element = name ":" value
name = token
token = 1*<any CHAR except CTLs or separators>
value = *<any CHAR except CTLs or separators>
separator = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
The REQUIRED parameter 'encoding-id' is used to identify the FEC The REQUIRED parameter 'encoding-id' is used to identify the FEC
scheme used to generate this repair flow. These identifiers MUST be scheme used to generate this repair flow. These identifiers (in the
registered with IANA by the FEC schemes that use the FEC Framework. range of [0 - 255]) are registered by the FEC schemes that use the
FEC Framework and are maintained by IANA.
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 the parameter 'preference-lvl' does
parameter 'preference-lvl', it means that the receiver(s) MAY receive not exist, it means that the receiver(s) MAY receive and use the
and use the repair flows in any order. However, if a preference repair flows in any order. However, if a preference level is
level is assigned to the repair flow(s), the receivers are encouraged assigned to the repair flow(s), the receivers are encouraged to
to follow the specified order in receiving and using the repair follow the specified order in receiving and using the repair flow(s).
flow(s).
The OPTIONAL parameters 'ss-fssi' and 'fssi' are containers to convey The OPTIONAL parameters 'ss-fssi' and 'fssi' are containers to 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 textual representation and MAY contain multiple distinct form of textual representation and MAY contain multiple distinct
elements. If the FEC scheme does not require any specific elements. If the FEC scheme does not require any specific
information, the 'ss-fssi' and 'fssi' parameters MAY be null and information, the 'ss-fssi' and 'fssi' parameters MUST NOT exist.
ignored.
4.6. Repair Window 4.6. Repair Window
Repair window is the time that spans an FEC block, which consists of Repair window is the time that spans an FEC block, which consists of
the source block and the corresponding repair packets. the source block and the corresponding repair packets.
At the sender side, the FEC encoder processes a block of source At the sender side, the FEC encoder processes a block of source
packets and generates a number of repair packets. Then both the packets and generates a number of repair packets. Then both the
source and repair packets are transmitted within a certain duration source and repair packets are transmitted within a certain duration
not larger than the value of the repair window. The value of the not larger than the value of the repair window. The value of the
repair window impacts the maximum number of source packets that can repair window impacts the maximum number of source packets that can
be included in an FEC block. be included in an FEC block.
At the receiver side, the FEC decoder should wait at least for the At the receiver side, the FEC decoder should wait at least for the
duration of the repair window after getting the first packet in an duration of the repair window after getting the first packet in an
FEC block to allow all the repair packets to arrive (The waiting time FEC block to allow all the repair packets to arrive (The waiting time
can be adjusted if there are mising packets at the beginning of the can be adjusted if there are missing packets at the beginning of the
FEC block). The FEC decoder can start decoding the already received FEC block). The FEC decoder can start decoding the already received
packets sooner, however, it SHOULD NOT register an FEC decoding packets sooner, however, it SHOULD NOT register an FEC decoding
failure until it waits at least for the repair-window duration. failure until it waits at least for the repair-window duration.
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 unit CRLF
[unit] CRLF
window-size = 1*DIGIT window-size = %x31-39 *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.
Two units are defined here: 'ms', which stands for milliseconds and Two units are defined here: 'ms', which stands for milliseconds and
'us', which stands for microseconds. The default unit is 'ms'. 'us', which stands for microseconds.
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 does not Specifying the repair window size in an absolute time value does not
necessarily correspond to an integer number of packets or exactly necessarily correspond to an integer number of packets or exactly
match with the clock rate used in RTP (in case of RTP transport) match with the clock rate used in RTP (in case of RTP transport)
causing mismatches among subsequent repair windows. However, in causing mismatches among subsequent repair windows. However, in
practice, this mismatch does not break anything in the FEC decoding practice, this mismatch does not break anything in the FEC decoding
process. process.
skipping to change at page 13, line 32 skipping to change at page 13, line 15
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples s=FEC Framework Examples
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 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=n:7,k:5 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150 a=repair-window:150ms
a=mid:R1 a=mid:R1
6.2. Two Source Flows, One Repair Flow and One FEC Scheme 6.2. Two Source Flows, One Repair Flow and One FEC Scheme
SOURCE FLOWS SOURCE FLOWS
S2: Source Flow | | INSTANCE #1 S2: Source Flow | | INSTANCE #1
|---------| R2: Repair Flow |---------| R2: Repair Flow
S3: Source Flow | S3: Source Flow |
Figure 2: Scenario #2 Figure 2: Scenario #2
skipping to change at page 14, line 22 skipping to change at page 14, line 20
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:S2 a=mid:S2
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:S3 a=mid:S3
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=n:7,k:5 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150500us a=repair-window:150500us
a=mid:R2 a=mid:R2
6.3. Two Source Flows, Two Repair Flows and Two FEC Schemes 6.3. Two Source Flows, Two Repair Flows and Two FEC Schemes
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
S4: Source Flow |--------| R3: Repair Flow S4: Source Flow |--------| R3: Repair Flow
skipping to change at page 15, line 21 skipping to change at page 15, line 21
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:S4 a=mid:S4
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:S5 a=mid:S5
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=n:7,k:5 a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:200ms a=repair-window:200ms
a=mid:R3 a=mid:R3
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=n:14,k:10 a=fec-repair-flow: encoding-id=0; ss-fssi=n:14,k:10
a=repair-window:400ms a=repair-window:400ms
a=mid:R4 a=mid:R4
6.4. One Source Flow, Two Repair Flows and Two FEC Schemes 6.4. One Source Flow, Two Repair Flows and Two FEC Schemes
SOURCE FLOWS | INSTANCE #1 SOURCE FLOWS | INSTANCE #1
S6: Source Flow |--------| R5: Repair Flow S6: Source Flow |--------| R5: Repair Flow
| |
skipping to change at page 16, line 16 skipping to change at page 16, line 16
o=ali 1122334455 1122334466 IN IP4 fec.example.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples s=FEC Framework Examples
t=0 0 t=0 0
a=group:FEC-FR S6 R5 a=group:FEC-FR S6 R5
a=group:FEC-FR S6 R6 a=group:FEC-FR S6 R6
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:S6 a=mid:S6
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; preference-lvl=0; ss-fssi=n:7,k:5 a=fec-repair-flow: encoding-id=0; preference-lvl=0; ss-fssi=n:7,k:5
a=repair-window:200ms a=repair-window:200ms
a=mid:R5 a=mid:R5
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=1; preference-lvl=1; ss-fssi=t:3 a=fec-repair-flow: encoding-id=1; preference-lvl=1; ss-fssi=t:3
a=repair-window:200ms a=repair-window:200ms
a=mid:R6 a=mid:R6
7. Security Considerations 7. 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 can 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 does integrity check on SDP to only trust SDP from trusted
considerations of SDP [RFC4566] to only trust SDP from trusted sources. The receiver MUST also follow the security considerations
sources. For other general security considerations related to SDP, of SDP [RFC4566]. For other general security considerations related
refer to [RFC4566]. For the security considerations related to the to SDP, refer to [RFC4566]. For the security considerations related
use of source address filters in SDP, refer to [RFC4570]. to the use of source address filters in SDP, refer to [RFC4570].
The security considerations for the FEC Framework also apply. Refer The security considerations for the FEC Framework also apply. Refer
to [I-D.ietf-fecframe-framework] for details. to [I-D.ietf-fecframe-framework] for details.
8. IANA Considerations 8. IANA Considerations
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC. the number of this document prior to publication as an RFC.
8.1. Registration of Transport Protocols 8.1. Registration of Transport Protocols
skipping to change at page 17, line 12 skipping to change at page 17, line 12
This specification updates the Session Description Protocol (SDP) This specification updates the Session Description Protocol (SDP)
Parameters registry as defined in Section 8.2.2 of [RFC4566]. Parameters registry as defined in Section 8.2.2 of [RFC4566].
Specifically, it adds the following values to the table for the Specifically, it adds the following values to the table for the
'proto' field. 'proto' field.
Type SDP Name Reference Type SDP Name Reference
------ ---------- ----------- ------ ---------- -----------
proto UDP/FEC [RFCXXXX] proto UDP/FEC [RFCXXXX]
This specification also defines a class of new transport protocol
identifiers. For all existing identifiers <proto> (listed in the
table for the 'proto' field in the Session Description Protocol (SDP)
Parameters registry), this specification defines the identifier 'FEC/
<proto>'.
8.2. Registration of SDP Attributes 8.2. Registration of SDP Attributes
This document registers new attribute names in SDP. This document registers new attribute names in SDP.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: fec-source-flow Attribute name: fec-source-flow
Long form: Pointer to FEC Source Flow Long form: Pointer to FEC Source Flow
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
skipping to change at page 18, line 11 skipping to change at page 18, line 26
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.
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-09 (work in progress), draft-ietf-fecframe-framework-10 (work in progress),
July 2010. September 2010.
[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.
 End of changes. 35 change blocks. 
66 lines changed or deleted 64 lines changed or added

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