summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6364.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6364.txt')
-rw-r--r--doc/rfc/rfc6364.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc6364.txt b/doc/rfc/rfc6364.txt
new file mode 100644
index 0000000..b663683
--- /dev/null
+++ b/doc/rfc/rfc6364.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Begen
+Request for Comments: 6364 Cisco
+Category: Standards Track October 2011
+ISSN: 2070-1721
+
+
+ Session Description Protocol Elements for the
+ Forward Error Correction (FEC) Framework
+
+Abstract
+
+ This document specifies the use of the Session Description Protocol
+ (SDP) to describe the parameters required to signal the Forward Error
+ Correction (FEC) Framework Configuration Information between the
+ sender(s) and receiver(s). This document also provides examples that
+ show the semantics for grouping multiple source and repair flows
+ together for the applications that simultaneously use multiple
+ instances of the FEC Framework.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6364.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Begen Standards Track [Page 1]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Requirements Notation ...........................................3
+ 3. Forward Error Correction (FEC) and FEC Framework ................3
+ 3.1. Forward Error Correction (FEC) .............................3
+ 3.2. FEC Framework ..............................................4
+ 3.3. FEC Framework Configuration Information ....................4
+ 4. SDP Elements ....................................................5
+ 4.1. Transport Protocol Identifiers .............................6
+ 4.2. Media Stream Grouping ......................................6
+ 4.3. Source IP Addresses ........................................6
+ 4.4. Source Flows ...............................................6
+ 4.5. Repair Flows ...............................................7
+ 4.6. Repair Window ..............................................8
+ 4.7. Bandwidth Specification ....................................9
+ 5. Scenarios and Examples .........................................10
+ 5.1. Declarative Considerations ................................10
+ 5.2. Offer/Answer Model Considerations .........................10
+ 6. SDP Examples ...................................................11
+ 6.1. One Source Flow, One Repair Flow, and One FEC Scheme ......11
+ 6.2. Two Source Flows, One Repair Flow, and One FEC Scheme .....12
+ 6.3. Two Source Flows, Two Repair Flows, and Two FEC Schemes ...13
+ 6.4. One Source Flow, Two Repair Flows, and Two FEC Schemes ....14
+ 7. Security Considerations ........................................15
+ 8. IANA Considerations ............................................15
+ 8.1. Registration of Transport Protocols .......................15
+ 8.2. Registration of SDP Attributes ............................16
+ 9. Acknowledgments ................................................16
+ 10. References ....................................................17
+ 10.1. Normative References .....................................17
+ 10.2. Informative References ...................................17
+
+
+
+
+
+
+
+Begen Standards Track [Page 2]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+1. Introduction
+
+ The Forward Error Correction (FEC) Framework, described in [RFC6363],
+ outlines a general framework for using FEC-based error recovery in
+ packet flows carrying media content. While a continuous signaling
+ between the sender(s) and receiver(s) is not required for a Content
+ Delivery Protocol (CDP) that uses the FEC Framework, a set of
+ parameters pertaining to the FEC Framework has to be initially
+ communicated between the sender(s) and receiver(s). A signaling
+ protocol (such as the one described in [FECFRAME-CFG-SIGNAL]) is
+ required to enable such communication, and the parameters need to be
+ appropriately encoded so that they can be carried by the signaling
+ protocol.
+
+ One format to encode the parameters is the Session Description
+ Protocol (SDP) [RFC4566]. SDP provides a simple text-based format
+ for announcements and invitations to describe multimedia sessions.
+ These SDP announcements and invitations include sufficient
+ information for the sender(s) and receiver(s) to participate in the
+ multimedia sessions. SDP also provides a framework for capability
+ negotiation, which can be used to negotiate all, or a subset, of the
+ parameters pertaining to the individual sessions.
+
+ The purpose of this document is to introduce the SDP elements that
+ are used by the CDPs using the FEC Framework that choose SDP
+ [RFC4566] for their multimedia sessions.
+
+2. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+3. Forward Error Correction (FEC) and FEC Framework
+
+ This section gives a brief overview of FEC and the FEC Framework.
+
+3.1. Forward Error Correction (FEC)
+
+ Any application that needs reliable transmission over an unreliable
+ packet network has to cope with packet losses. FEC is an effective
+ approach that provides reliable transmission, particularly in
+ multicast and broadcast applications where the feedback from the
+ receiver(s) is either not available or quite limited.
+
+
+
+
+
+
+Begen Standards Track [Page 3]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ In a nutshell, FEC groups source packets into blocks and applies
+ protection to generate a desired number of repair packets. These
+ repair packets can be sent on demand or independently of any receiver
+ feedback. The choice depends on the FEC scheme or the Content
+ Delivery Protocol used by the application, the packet loss
+ characteristics of the underlying network, the transport scheme
+ (e.g., unicast, multicast, and broadcast), and the application
+ itself. At the receiver side, lost packets can be recovered by
+ erasure decoding provided that a sufficient number of source and
+ repair packets have been received.
+
+3.2. FEC Framework
+
+ The FEC Framework [RFC6363] outlines a general framework for using
+ FEC codes in multimedia applications that stream audio, video, or
+ other types of multimedia content. It defines the common components
+ and aspects of Content Delivery Protocols (CDPs). The FEC Framework
+ also defines the requirements for the FEC schemes that need to be
+ used within a CDP. However, the details of the FEC schemes are not
+ specified within the FEC Framework. For example, the FEC Framework
+ defines what configuration information has to be known at the sender
+ and receiver(s) at a minimum, but the FEC Framework neither specifies
+ how the FEC repair packets are generated and used to recover missing
+ source packets, nor dictates how the configuration information is
+ communicated between the sender and receiver(s). These are rather
+ specified by the individual FEC schemes or CDPs.
+
+3.3. FEC Framework Configuration Information
+
+ The FEC Framework [RFC6363] defines a minimum set of information that
+ has to be communicated between the sender and receiver(s) for proper
+ operation of a FEC scheme. This information is called the "FEC
+ Framework Configuration Information". This information includes
+ unique identifiers for the source and repair flows that carry the
+ source and repair packets, respectively. It also specifies how the
+ sender applies protection to the source flow(s) and how the repair
+ flow(s) can be used to recover lost data.
+
+ Multiple instances of the FEC Framework can simultaneously exist at
+ the sender and the receiver(s) for different source flows, for the
+ same source flow, or for various combinations of the source flows.
+ Each instance of the FEC Framework provides the following FEC
+ Framework Configuration Information:
+
+
+
+
+
+
+
+
+Begen Standards Track [Page 4]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ 1. Identification of the repair flows.
+
+ 2. For each source flow protected by the repair flow(s):
+
+ A. Definition of the source flow.
+
+ B. An integer identifier for this flow definition (i.e., tuple).
+ This identifier MUST be unique among all source flows that
+ are protected by the same FEC repair flow. Integer
+ identifiers can be allocated starting from zero and
+ increasing by one for each flow. However, any random (but
+ still unique) allocation is also possible. A source flow
+ identifier need not be carried in source packets, since
+ source packets are directly associated with a flow by virtue
+ of their packet headers.
+
+ 3. The FEC Encoding ID, identifying the FEC scheme.
+
+ 4. The length of the Explicit Source FEC Payload ID (in octets).
+
+ 5. Zero or more FEC-Scheme-Specific Information (FSSI) elements,
+ each consisting of a name and a value where the valid element
+ names and value ranges are defined by the FEC scheme.
+
+ FSSI includes the information that is specific to the FEC scheme used
+ by the CDP. FSSI is used to communicate the information that cannot
+ be adequately represented otherwise and is essential for proper FEC
+ encoding and decoding operations. The motivation behind separating
+ the FSSI required only by the sender (which is carried in a Sender-
+ Side FEC-Scheme-Specific Information (SS-FSSI) container) from the
+ rest of the FSSI is to provide the receiver or the third-party
+ entities a means of controlling the FEC operations at the sender.
+ Any FSSI other than the one solely required by the sender MUST be
+ communicated via the FSSI container.
+
+ The variable-length SS-FSSI and FSSI containers transmit the
+ information in textual representation and contain zero or more
+ distinct elements, whose descriptions are provided by the fully
+ specified FEC schemes.
+
+4. SDP Elements
+
+ This section defines the SDP elements that MUST be used to describe
+ the FEC Framework Configuration Information in multimedia sessions by
+ the CDPs that choose SDP [RFC4566] for their multimedia sessions.
+ Example SDP descriptions can be found in Section 6.
+
+
+
+
+
+Begen Standards Track [Page 5]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+4.1. Transport Protocol Identifiers
+
+ This specification defines a new transport protocol identifier for
+ the FEC schemes that take a UDP-formatted input stream and append an
+ Explicit Source FEC Payload ID, as described in Section 5.3 of
+ [RFC6363], to generate a source flow. This new protocol identifier
+ is called 'FEC/UDP'. To use input streams that are formatted
+ according to another <proto> (as listed in the table for the 'proto'
+ field in the "Session Description Protocol (SDP) Parameters"
+ registry), the corresponding 'FEC/<proto>' transport protocol
+ identifier MUST be registered with IANA by following the instructions
+ specified in [RFC4566].
+
+ Note that if a FEC scheme does not use the Explicit Source FEC
+ Payload ID as described in Section 4.1 of [RFC6363], then the
+ original transport protocol identifier MUST be used to support
+ backward compatibility with the receivers that do not support FEC
+ at all.
+
+ This specification also defines another transport protocol
+ identifier, 'UDP/FEC', to indicate the FEC repair packet format
+ defined in Section 5.4 of [RFC6363]. For detailed registration
+ information, refer to Section 8.1.
+
+4.2. Media Stream Grouping
+
+ In the FEC Framework, the 'group' attribute and the FEC grouping
+ semantics defined in [RFC5888] and [RFC5956], respectively, are used
+ to associate source and repair flows.
+
+4.3. Source IP Addresses
+
+ The 'source-filter' attribute of SDP ("a=source-filter") as defined
+ in [RFC4570] is used to express the source addresses or fully
+ qualified domain names in the FEC Framework.
+
+4.4. Source Flows
+
+ The FEC Framework allows that multiple source flows MAY be grouped
+ and protected together by single or multiple FEC Framework instances.
+ For this reason, as described in Section 3.3, individual source flows
+ MUST be identified with unique identifiers. For this purpose, we
+ introduce the attribute 'fec-source-flow'.
+
+
+
+
+
+
+
+
+Begen Standards Track [Page 6]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ The syntax for the new attribute in ABNF [RFC5234] is as follows:
+
+ fec-source-flow-line = "a=fec-source-flow:" SP source-id
+ [";" SP tag-length] CRLF
+
+ source-id = "id=" src-id
+ src-id = 1*DIGIT ; Represented as 32-bit non-negative
+ ; integers, and leading zeros are ignored
+
+ tag-length = "tag-len=" tlen
+ tlen = %x31-39 *DIGIT
+
+ The REQUIRED parameter 'id' is used to identify the source flow.
+ Parameter 'id' MUST be an integer.
+
+ The 'tag-len' parameter is used to specify the length of the Explicit
+ Source FEC Payload ID field (in octets). In the case that an
+ Explicit Source FEC Payload ID is used, the 'tag-len' parameter MUST
+ exist and indicate its length. Otherwise, the 'tag-len' parameter
+ MUST NOT exist.
+
+4.5. Repair Flows
+
+ A repair flow MUST contain only repair packets formatted as described
+ in [RFC6363] for a single FEC Framework instance; i.e., packets
+ belonging to source flows or other repair flows from a different FEC
+ Framework instance cannot be sent within this flow. We introduce the
+ attribute 'fec-repair-flow' to describe the repair flows.
+
+ 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
+ [";" SP flow-preference]
+ [";" SP sender-side-scheme-specific]
+ [";" SP scheme-specific] CRLF
+
+ fec-encoding-id = "encoding-id=" enc-id
+ enc-id = 1*DIGIT ; FEC Encoding ID
+
+ flow-preference = "preference-lvl=" preference-level-of-the-flow
+ preference-level-of-the-flow = 1*DIGIT
+
+
+
+
+
+
+
+
+
+Begen Standards Track [Page 7]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ sender-side-scheme-specific = "ss-fssi=" sender-info
+ sender-info = element *( "," element )
+ element = name ":" value
+ name = token
+ token = 1*<any CHAR except CTLs or separators>
+ value = *<any CHAR except CTLs or separators>
+ separator = "(" / ")" / "<" / ">" / "@"
+ / "," / ";" / ":" / "\" / DQUOTE
+ / "/" / "[" / "]" / "?" / "="
+ / "{" / "}" / SP / HTAB
+
+ scheme-specific = "fssi=" scheme-info
+ scheme-info = element *( "," element )
+
+ The REQUIRED parameter 'encoding-id' is used to identify the FEC
+ scheme used to generate this repair flow. These identifiers (in the
+ 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
+ preferred order for using the repair flows. The exact usage of the
+ parameter 'preference-lvl' and the pertaining rules MAY be defined by
+ the FEC scheme or the CDP. If the parameter 'preference-lvl' does
+ not exist, it means that the receiver(s) MAY receive and use the
+ repair flows in any order. However, if a preference level is
+ assigned to the repair flow(s), the receivers are encouraged to
+ follow the specified order in receiving and using the repair flow(s).
+
+ The OPTIONAL parameters 'ss-fssi' and 'fssi' are containers to convey
+ the FEC-Scheme-Specific Information (FSSI) that includes the
+ information that is specific to the FEC scheme used by the CDP and is
+ necessary for proper FEC encoding and decoding operations. The FSSI
+ required only by the sender (the Sender-Side FSSI) MUST be
+ communicated in the container specified by the parameter 'ss-fssi'.
+ Any other FSSI MUST be communicated in the container specified by the
+ parameter 'fssi'. In both containers, FSSI is transmitted in the
+ form of textual representation and MAY contain multiple distinct
+ elements. If the FEC scheme does not require any specific
+ information, the 'ss-fssi' and 'fssi' parameters MUST NOT exist.
+
+4.6. Repair Window
+
+ The repair window is the time that spans a FEC block, which consists
+ of the source block and the corresponding repair packets.
+
+ At the sender side, the FEC encoder processes a block of source
+ packets and generates a number of repair packets. Then, both the
+ source and repair packets are transmitted within a certain duration
+
+
+
+Begen Standards Track [Page 8]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ not larger than the value of the repair window. The value of the
+ repair window impacts the maximum number of source packets that can
+ be included in a FEC block.
+
+ At the receiver side, the FEC decoder should wait at least for the
+ duration of the repair window after getting the first packet in a FEC
+ block, to allow all the repair packets to arrive. (The waiting time
+ can be adjusted if there are missing packets at the beginning of the
+ FEC block.) The FEC decoder can start decoding the already received
+ packets sooner; however, it SHOULD NOT register a FEC decoding
+ failure until it waits at least for the duration of the repair
+ window.
+
+ This document specifies a new attribute to describe the size of the
+ repair window in milliseconds and microseconds.
+
+ The syntax for the attribute in ABNF is as follows:
+
+ repair-window-line = "a=repair-window:" window-size unit CRLF
+
+ window-size = %x31-39 *DIGIT ; Represented as
+ ; 32-bit non-negative integers
+
+ unit = "ms" / "us"
+
+ <unit> is the unit of time specified for the repair window size. Two
+ units are defined here: 'ms', which stands for milliseconds; and
+ 'us', which stands for microseconds.
+
+ The 'a=repair-window' attribute is a media-level attribute, since
+ each repair flow MAY have a different repair window size.
+
+ Specifying the repair window size in an absolute time value does not
+ necessarily correspond to an integer number of packets or exactly
+ match with the clock rate used in RTP (in the case of RTP transport),
+ causing mismatches among subsequent repair windows. However, in
+ practice, this mismatch does not break anything in the FEC decoding
+ process.
+
+4.7. Bandwidth Specification
+
+ The bandwidth specification as defined in [RFC4566] denotes the
+ proposed bandwidth to be used by the session or media. The
+ specification of bandwidth is OPTIONAL.
+
+
+
+
+
+
+
+Begen Standards Track [Page 9]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ In the context of the FEC Framework, the bandwidth specification can
+ 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
+ following rules.
+
+ The session-level bandwidth for a FEC Framework instance or the
+ media-level bandwidth for the individual repair flows MAY be
+ specified. In this case, it is RECOMMENDED that the Transport
+ Independent Application Specific (TIAS) bandwidth modifier [RFC3890]
+ and the 'a=maxprate' attribute be used, unless the Application-
+ Specific (AS) bandwidth modifier [RFC4566] is used. The use of the
+ AS bandwidth modifier is NOT RECOMMENDED, since TIAS allows the
+ calculation of the bitrate according to the IP version and transport
+ protocol whereas AS does not. Thus, in TIAS-based bitrate
+ calculations, the packet size SHALL include all headers and payload,
+ excluding the IP and UDP headers. In AS-based bitrate calculations,
+ the packet size SHALL include all headers and payload, plus the IP
+ and UDP headers.
+
+ For the ABNF syntax information of the TIAS and AS, refer to
+ [RFC3890] and [RFC4566], respectively.
+
+5. Scenarios and Examples
+
+ This section discusses the considerations for Session Announcement
+ and Offer/Answer Models.
+
+5.1. Declarative Considerations
+
+ In multicast-based applications, the FEC Framework Configuration
+ Information pertaining to all FEC protection options available at the
+ sender MAY be advertised to the receivers as a part of a session
+ announcement. This way, the sender can let the receivers know all
+ available options for FEC protection. Based on their needs, the
+ receivers can choose protection provided by one or more FEC Framework
+ instances and subscribe to the respective multicast session(s) to
+ receive the repair flow(s). Unless explicitly required by the CDP,
+ the receivers SHOULD NOT send an answer back to the sender specifying
+ their choices, since this can easily overwhelm the sender,
+ particularly in large-scale multicast applications.
+
+5.2. Offer/Answer Model Considerations
+
+ In unicast-based applications, a sender and receiver MAY adopt the
+ Offer/Answer Model [RFC3264] to set the FEC Framework Configuration
+ Information. In this case, the sender offers the options available
+ to this particular receiver, and the receiver answers back to the
+ sender with its choice(s).
+
+
+
+Begen Standards Track [Page 10]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ Receivers supporting the SDP Capability Negotiation Framework
+ [RFC5939] MAY also use this framework to negotiate all, or a subset,
+ of the FEC Framework parameters.
+
+ The backward compatibility in the Offer/Answer Model is handled as
+ specified in [RFC5956].
+
+6. SDP Examples
+
+ This section provides SDP examples that can be used by the FEC
+ Framework.
+
+ [RFC5888] defines the media stream identification attribute ('mid')
+ as a token in ABNF. In contrast, the identifiers for the source
+ flows are integers and can be allocated starting from zero and
+ increasing by one for each flow. To avoid any ambiguity, using the
+ same values for identifying the media streams and source flows is NOT
+ RECOMMENDED, even when 'mid' values are integers.
+
+ In the examples below, random FEC Encoding IDs will be used for
+ illustrative purposes. Artificial content for the SS-FSSI and FSSI
+ will also be provided.
+
+6.1. One Source Flow, One Repair Flow, and One FEC Scheme
+
+ SOURCE FLOWS | INSTANCE #1
+ S1: Source Flow |--------| R1: Repair Flow
+ |
+
+ Figure 1: Scenario #1
+
+ 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-FR S1 R1" line. The source and repair flows are sent to
+ the same port on different multicast groups. The repair window is
+ set to 150 ms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen Standards Track [Page 11]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ v=0
+ o=ali 1122334455 1122334466 IN IP4 fec.example.com
+ s=FEC Framework Examples
+ t=0 0
+ a=group:FEC-FR S1 R1
+ m=video 30000 RTP/AVP 100
+ c=IN IP4 233.252.0.1/127
+ a=rtpmap:100 MP2T/90000
+ a=fec-source-flow: id=0
+ a=mid:S1
+ m=application 30000 UDP/FEC
+ c=IN IP4 233.252.0.2/127
+ a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
+ a=repair-window:150ms
+ a=mid:R1
+
+6.2. Two Source Flows, One Repair Flow, and One FEC Scheme
+
+ SOURCE FLOWS
+ S2: Source Flow | | INSTANCE #1
+ |---------| R2: Repair Flow
+ S3: Source Flow |
+
+ Figure 2: Scenario #2
+
+ In this example, we have two source video flows (mid:S2 and mid:S3)
+ and one FEC repair flow (mid:R2) protecting both source flows. We
+ form one FEC group with the "a=group:FEC-FR S2 S3 R2" line. The
+ source and repair flows are sent to the same port on different
+ multicast groups. The repair window is set to 150500 us.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen Standards Track [Page 12]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ v=0
+ o=ali 1122334455 1122334466 IN IP4 fec.example.com
+ s=FEC Framework Examples
+ t=0 0
+ a=group:FEC-FR S2 S3 R2
+ m=video 30000 RTP/AVP 100
+ c=IN IP4 233.252.0.1/127
+ a=rtpmap:100 MP2T/90000
+ a=fec-source-flow: id=0
+ a=mid:S2
+ m=video 30000 RTP/AVP 101
+ c=IN IP4 233.252.0.2/127
+ a=rtpmap:101 MP2T/90000
+ a=fec-source-flow: id=1
+ a=mid:S3
+ m=application 30000 UDP/FEC
+ c=IN IP4 233.252.0.3/127
+ a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
+ a=repair-window:150500us
+ a=mid:R2
+
+6.3. Two Source Flows, Two Repair Flows, and Two FEC Schemes
+
+ SOURCE FLOWS | INSTANCE #1
+ S4: Source Flow |--------| R3: Repair Flow
+
+ S5: Source Flow |--------| INSTANCE #2
+ | R4: Repair Flow
+
+ Figure 3: Scenario #3
+
+ In this example, we have two source video flows (mid:S4 and mid:S5)
+ and two FEC repair flows (mid:R3 and mid:R4). The source flows
+ mid:S4 and mid:S5 are protected by the repair flows mid:R3 and
+ mid:R4, respectively. We form two FEC groups with the
+ "a=group:FEC-FR S4 R3" and "a=group:FEC-FR S5 R4" lines. The source
+ and repair flows are sent to the same port on different multicast
+ groups. The repair window is set to 200 ms and 400 ms for the first
+ and second FEC group, respectively.
+
+
+
+
+
+
+
+
+
+
+
+
+Begen Standards Track [Page 13]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ v=0
+ o=ali 1122334455 1122334466 IN IP4 fec.example.com
+ s=FEC Framework Examples
+ t=0 0
+ a=group:FEC-FR S4 R3
+ a=group:FEC-FR S5 R4
+ m=video 30000 RTP/AVP 100
+ c=IN IP4 233.252.0.1/127
+ a=rtpmap:100 MP2T/90000
+ a=fec-source-flow: id=0
+ a=mid:S4
+ m=video 30000 RTP/AVP 101
+ c=IN IP4 233.252.0.2/127
+ a=rtpmap:101 MP2T/90000
+ a=fec-source-flow: id=1
+ a=mid:S5
+ m=application 30000 UDP/FEC
+ c=IN IP4 233.252.0.3/127
+ a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
+ a=repair-window:200ms
+ a=mid:R3
+ m=application 30000 UDP/FEC
+ c=IN IP4 233.252.0.4/127
+ a=fec-repair-flow: encoding-id=0; ss-fssi=n:14,k:10
+ a=repair-window:400ms
+ a=mid:R4
+
+6.4. One Source Flow, Two Repair Flows, and Two FEC Schemes
+
+ SOURCE FLOWS | INSTANCE #1
+ S6: Source Flow |--------| R5: Repair Flow
+ |
+ |--------| INSTANCE #2
+ | R6: Repair Flow
+
+ Figure 4: Scenario #4
+
+ In this example, we have one source video flow (mid:S6) and two FEC
+ repair flows (mid:R5 and mid:R6) with different preference levels.
+ The source flow mid:S6 is protected by both of the repair flows. We
+ form two FEC groups with the "a=group:FEC-FR S6 R5" and
+ "a=group:FEC-FR S6 R6" lines. The source and repair flows are sent
+ to the same port on different multicast groups. The repair window is
+ set to 200 ms for both FEC groups.
+
+
+
+
+
+
+
+Begen Standards Track [Page 14]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ v=0
+ o=ali 1122334455 1122334466 IN IP4 fec.example.com
+ s=FEC Framework Examples
+ t=0 0
+ a=group:FEC-FR S6 R5
+ a=group:FEC-FR S6 R6
+ m=video 30000 RTP/AVP 100
+ c=IN IP4 233.252.0.1/127
+ a=rtpmap:100 MP2T/90000
+ a=fec-source-flow: id=0
+ a=mid:S6
+ m=application 30000 UDP/FEC
+ 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=repair-window:200ms
+ a=mid:R5
+ m=application 30000 UDP/FEC
+ c=IN IP4 233.252.0.4/127
+ a=fec-repair-flow: encoding-id=1; preference-lvl=1; ss-fssi=t:3
+ a=repair-window:200ms
+ a=mid:R6
+
+7. Security Considerations
+
+ There is a weak threat if the SDP is modified in a way that it shows
+ an incorrect association and/or grouping of the source and repair
+ flows. Such attacks can result in failure of FEC protection and/or
+ mishandling of other media streams. It is RECOMMENDED that the
+ receiver perform an integrity check on SDP to only trust SDP from
+ trusted sources. The receiver MUST also follow the security
+ considerations of SDP [RFC4566]. For other general security
+ considerations related to SDP, refer to [RFC4566]. For the security
+ considerations related to the use of source address filters in SDP,
+ refer to [RFC4570].
+
+ The security considerations for the FEC Framework also apply. Refer
+ to [RFC6363] for details.
+
+8. IANA Considerations
+
+8.1. Registration of Transport Protocols
+
+ This specification updates the "Session Description Protocol (SDP)
+ Parameters" registry as defined in Section 8.2.2 of [RFC4566].
+ Specifically, it adds the following values to the table for the
+ 'proto' field.
+
+
+
+
+
+Begen Standards Track [Page 15]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+ Type SDP Name Reference
+ ------ ---------- -----------
+ proto FEC/UDP [RFC6364]
+ proto UDP/FEC [RFC6364]
+
+8.2. Registration of SDP Attributes
+
+ This document registers new attribute names in SDP.
+
+ SDP Attribute ("att-field"):
+ Attribute name: fec-source-flow
+ Long form: Pointer to FEC Source Flow
+ Type of name: att-field
+ Type of attribute: Media level
+ Subject to charset: No
+ Purpose: Provide parameters for a FEC source flow
+ Reference: [RFC6364]
+ Values: See [RFC6364]
+
+ SDP Attribute ("att-field"):
+ Attribute name: fec-repair-flow
+ Long form: Pointer to FEC Repair Flow
+ Type of name: att-field
+ Type of attribute: Media level
+ Subject to charset: No
+ Purpose: Provide parameters for a FEC repair flow
+ Reference: [RFC6364]
+ Values: See [RFC6364]
+
+ SDP Attribute ("att-field"):
+ Attribute name: repair-window
+ Long form: Pointer to FEC Repair Window
+ Type of name: att-field
+ Type of attribute: Media level
+ Subject to charset: No
+ Purpose: Indicate the size of the repair window
+ Reference: [RFC6364]
+ Values: See [RFC6364]
+
+9. Acknowledgments
+
+ The author would like to thank the FEC Framework Design Team for
+ their inputs, suggestions, and contributions.
+
+
+
+
+
+
+
+
+Begen Standards Track [Page 16]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+10. References
+
+10.1. Normative References
+
+ [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
+ Correction (FEC) Framework", RFC 6363, October 2011.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol
+ (SDP) Source Filters", RFC 4570, July 2006.
+
+ [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
+ Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
+
+ [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
+ the Session Description Protocol", RFC 5956,
+ September 2010.
+
+ [RFC3890] Westerlund, M., "A Transport Independent Bandwidth
+ Modifier for the Session Description Protocol (SDP)",
+ RFC 3890, September 2004.
+
+ [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234,
+ January 2008.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+ with Session Description Protocol (SDP)", RFC 3264,
+ June 2002.
+
+10.2. Informative References
+
+ [FECFRAME-CFG-SIGNAL]
+ Asati, R., "Methods to convey FEC Framework Configuration
+ Information", Work in Progress, September 2011.
+
+ [RFC5939] Andreasen, F., "Session Description Protocol (SDP)
+ Capability Negotiation", RFC 5939, September 2010.
+
+
+
+
+
+
+
+
+Begen Standards Track [Page 17]
+
+RFC 6364 SDP Elements for FEC Framework October 2011
+
+
+Author's Address
+
+ Ali Begen
+ Cisco
+ 181 Bay Street
+ Toronto, ON M5J 2T3
+ Canada
+
+ EMail: abegen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen Standards Track [Page 18]
+