Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 6364 Cisco
Category: Standards Track October 2011
ISSN: 2070-1721
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
前向纠错（FEC）框架的会话描述协议元素
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.
本文档规定使用会话描述协议（SDP）来描述发送端和接收方之间发送前向纠错（FEC）框架配置信息所需的参数。本文档还提供了一些示例，展示了同时使用多个FEC框架实例的应用程序将多个源和修复流分组在一起的语义。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
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
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
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.
[RFC6363]中描述的前向纠错（FEC）框架概述了在承载媒体内容的数据包流中使用基于FEC的错误恢复的一般框架。虽然使用FEC框架的内容交付协议（CDP）不需要发送方和接收方之间的连续信令，但是与FEC框架相关的一组参数必须在发送方和接收方之间进行初始通信。需要信令协议（例如[FECFRAME-CFG-SIGNAL]中描述的协议）来启用这种通信，并且需要对参数进行适当编码，以便信令协议能够携带这些参数。
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.
对参数进行编码的一种格式是会话描述协议（SDP）[RFC4566]。SDP为公告和邀请提供了一种简单的基于文本的格式，用于描述多媒体会话。这些SDP公告和邀请包含足够的信息，供发送方和接收方参与多媒体会话。SDP还提供了一个能力协商框架，可用于协商与单个会话相关的所有或子集参数。
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.
本文档旨在介绍CDP使用FEC框架使用的SDP元素，该框架选择SDP[RFC4566]进行多媒体会话。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This section gives a brief overview of FEC and the FEC Framework.
本节简要概述了FEC和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.
任何需要在不可靠的数据包网络上进行可靠传输的应用程序都必须处理数据包丢失。FEC是一种提供可靠传输的有效方法，特别是在多播和广播应用中，其中来自接收器的反馈不可用或非常有限。
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.
简而言之，FEC将源数据包分组成块，并应用保护来生成所需数量的修复数据包。这些修复包可以按需发送，也可以独立于任何接收器反馈发送。选择取决于应用程序使用的FEC方案或内容交付协议、底层网络的丢包特性、传输方案（例如，单播、多播和广播）以及应用程序本身。在接收机侧，只要接收到足够数量的源和修复分组，就可以通过擦除解码来恢复丢失的分组。
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.
FEC框架[RFC6363]概述了在流式传输音频、视频或其他类型多媒体内容的多媒体应用程序中使用FEC代码的一般框架。它定义了内容交付协议（CDP）的通用组件和方面。FEC框架还定义了需要在CDP中使用的FEC方案的要求。然而，FEC框架中并未规定FEC方案的细节。例如，FEC框架定义了发送方和接收方至少必须知道的配置信息，但是FEC框架既不指定如何生成FEC修复包并将其用于恢复丢失的源包，也不规定发送方和接收方之间如何通信配置信息（s） 。这些都是由个别的外汇券计划或外汇券指定的。
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.
FEC框架[RFC6363]定义了发送方和接收方之间必须通信的最小信息集，以确保FEC方案的正确操作。该信息称为“FEC框架配置信息”。此信息包括分别携带源和修复数据包的源和修复流的唯一标识符。它还指定发送方如何对源流应用保护，以及如何使用修复流恢复丢失的数据。
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:
对于不同的源流、相同的源流或源流的各种组合，FEC框架的多个实例可以同时存在于发送方和接收方。FEC框架的每个实例都提供以下FEC框架配置信息：
1. Identification of the repair flows.
1. 识别维修流程。
2. For each source flow protected by the repair flow(s):
2. 对于受修复流保护的每个源流：
A. Definition of the source flow.
A.源流的定义。
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.
B.此流定义的整数标识符（即元组）。该标识符在受同一FEC修复流保护的所有源流中必须是唯一的。整数标识符可以从零开始分配，并为每个流增加一个。然而，任何随机（但仍然是唯一的）分配也是可能的。源流标识符不需要在源分组中携带，因为源分组凭借其分组报头直接与流相关联。
3. The FEC Encoding ID, identifying the FEC scheme.
3. FEC编码ID，标识FEC方案。
4. The length of the Explicit Source FEC Payload ID (in octets).
4. 显式源FEC有效负载ID的长度（以八位字节为单位）。
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.
5. 零个或多个FEC方案特定信息（FSSI）元素，每个元素由名称和值组成，其中有效元素名称和值范围由FEC方案定义。
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.
FSSI包括特定于CDP使用的FEC方案的信息。FSSI用于传递无法以其他方式充分表示的信息，对于正确的FEC编码和解码操作至关重要。将仅由发送方（在发送方FEC方案特定信息（SS-FSSI）容器中携带）所需的FSSI与FSSI的其余部分分离的动机是为接收方或第三方实体提供控制发送方FEC操作的手段。除发送方单独要求的FSSI以外的任何FSSI必须通过FSSI容器进行通信。
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.
可变长度SS-FSSI和FSSI容器以文本表示形式传输信息，并包含零个或多个不同元素，其描述由完全指定的FEC方案提供。
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.
本节定义了SDP元素，这些SDP元素必须用于描述多媒体会话中选择SDP[RFC4566]的CDP的FEC框架配置信息。SDP说明示例见第6节。
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].
如[RFC6363]第5.3节所述，本规范为采用UDP格式输入流并附加显式源FEC有效负载ID的FEC方案定义了新的传输协议标识符，以生成源流。这个新的协议标识符称为“FEC/UDP”。要使用根据另一个<proto>格式化的输入流（如“会话描述协议（SDP）参数”注册表中“proto”字段表中所列），必须按照[RFC4566]中指定的说明向IANA注册相应的“FEC/<proto>”传输协议标识符。
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.
请注意，如果FEC方案不使用[RFC6363]第4.1节中所述的显式源FEC有效负载ID，则必须使用原始传输协议标识符来支持与根本不支持FEC的接收机的向后兼容性。
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.
本规范还定义了另一个传输协议标识符“UDP/FEC”，以指示[RFC6363]第5.4节中定义的FEC修复数据包格式。有关详细注册信息，请参阅第8.1节。
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.
在FEC框架中，[RFC5888]和[RFC5956]中分别定义的“组”属性和FEC分组语义用于关联源流和修复流。
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.
[RFC4570]中定义的SDP的“源过滤器”属性（“a=源过滤器”）用于表示FEC框架中的源地址或完全限定域名。
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'.
FEC框架允许通过单个或多个FEC框架实例将多个源流分组并保护在一起。因此，如第3.3节所述，必须使用唯一标识符标识单个源流。为此，我们引入属性“fec源流”。
The syntax for the new attribute in ABNF [RFC5234] is as follows:
ABNF[RFC5234]中新属性的语法如下：
fec-source-flow-line = "a=fec-source-flow:" SP source-id
[";" SP tag-length] CRLF
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
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
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.
所需参数“id”用于标识源流。参数“id”必须是整数。
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.
“tag len”参数用于指定显式源FEC有效负载ID字段的长度（以八位字节为单位）。在使用显式源FEC有效负载ID的情况下，“tag len”参数必须存在并指示其长度。否则，“tag len”参数不能存在。
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.
对于单个FEC框架实例，修复流必须仅包含[RFC6363]中所述格式的修复包；i、 例如，来自不同FEC框架实例的属于源流或其他修复流的数据包不能在此流中发送。我们引入属性“fec修复流”来描述修复流。
The syntax for the new attribute in ABNF is as follows (CHAR and CTL are defined in [RFC5234]):
ABNF中新属性的语法如下（CHAR和CTL在[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-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
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
flow-preference = "preference-lvl=" preference-level-of-the-flow
preference-level-of-the-flow = 1*DIGIT
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
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 )
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.
所需参数“encoding id”用于标识用于生成此修复流的FEC方案。这些标识符（范围为[0-255]）由使用FEC框架的FEC方案注册，并由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).
可选参数“preference lvl”用于指示使用修复流的首选顺序。参数“preference lvl”和相关规则的确切用法可由FEC方案或CDP定义。如果参数“preference lvl”不存在，则表示接收方可以按任何顺序接收和使用修复流。但是，如果为维修流程指定了首选级别，则鼓励接收者按照指定顺序接收和使用维修流程。
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.
可选参数“ss fssi”和“fssi”是用于传送FEC方案特定信息（fssi）的容器，该信息包括特定于CDP使用的FEC方案的信息，并且对于正确的FEC编码和解码操作是必需的。仅发送方所需的FSSI（发送方方FSSI）必须在参数“ss FSSI”指定的容器中进行通信。任何其他FSSI必须在参数“FSSI”指定的容器中进行通信。在这两个容器中，FSSI以文本表示的形式传输，并且可能包含多个不同的元素。如果FEC方案不需要任何特定信息，“ss fssi”和“fssi”参数不得存在。
The repair window is the time that spans a FEC block, which consists of the source block and the corresponding repair packets.
修复窗口是跨越FEC块的时间，FEC块由源块和相应的修复数据包组成。
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
在发送方，FEC编码器处理源分组块并生成多个修复分组。然后，在一定的持续时间内传输源和修复包
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.
不大于“修复”窗口的值。修复窗口的值影响FEC块中可包括的最大源数据包数。
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.
在接收机侧，FEC解码器应当在获得FEC块中的第一个分组之后至少等待修复窗口的持续时间，以允许所有修复分组到达。（如果在FEC块的开头有丢失的分组，则可以调整等待时间。）FEC解码器可以更快地开始解码已经接收到的分组；但是，在至少等待修复窗口的持续时间之前，不应注册FEC解码故障。
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:
ABNF中属性的语法如下所示：
repair-window-line = "a=repair-window:" window-size unit CRLF
repair-window-line = "a=repair-window:" window-size unit CRLF
window-size = %x31-39 *DIGIT ; Represented as
; 32-bit non-negative integers
window-size = %x31-39 *DIGIT ; Represented as
; 32-bit non-negative integers
unit = "ms" / "us"
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.
<unit>是为修复窗口大小指定的时间单位。这里定义了两个单位：“ms”，表示毫秒；还有“我们”，代表微秒。
The 'a=repair-window' attribute is a media-level attribute, since each repair flow MAY have a different repair window size.
“a=修复窗口”属性是媒体级属性，因为每个修复流可能具有不同的修复窗口大小。
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.
在绝对时间值中指定修复窗口大小不一定对应于整数个数据包或与RTP中使用的时钟速率完全匹配（在RTP传输的情况下），从而导致后续修复窗口之间不匹配。然而，在实践中，这种失配不会破坏FEC解码过程中的任何内容。
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.
[RFC4566]中定义的带宽规范表示会话或媒体使用的建议带宽。带宽规格是可选的。
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.
在FEC框架的上下文中，带宽规范可用于表示修复流的带宽或会话的带宽。如果包含在SDP中，则应遵守以下规则。
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.
可以指定FEC框架实例的会话级带宽或单个修复流的媒体级带宽。在这种情况下，建议使用与传输无关的应用程序特定（TIAS）带宽修饰符[RFC3890]和“a=maxprate”属性，除非使用应用程序特定（AS）带宽修饰符[RFC4566]。不建议使用AS带宽修饰符，因为TIA允许根据IP版本和传输协议计算比特率，而AS不允许。因此，在基于TIA的比特率计算中，数据包大小应包括所有报头和有效载荷，不包括IP和UDP报头。在基于AS的比特率计算中，数据包大小应包括所有报头和有效载荷，以及IP和UDP报头。
For the ABNF syntax information of the TIAS and AS, refer to [RFC3890] and [RFC4566], respectively.
有关TIA和AS的ABNF语法信息，请分别参考[RFC3890]和[RFC4566]。
This section discusses the considerations for Session Announcement and Offer/Answer Models.
本节讨论会话公告和提供/应答模型的注意事项。
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.
在基于多播的应用中，与发送方可用的所有FEC保护选项相关的FEC框架配置信息可以作为会话公告的一部分通告给接收方。这样，发送方可以让接收方知道FEC保护的所有可用选项。根据其需求，接收器可以选择由一个或多个FEC框架实例提供的保护，并订阅相应的多播会话以接收修复流。除非CDP明确要求，否则接收者不应向发送者发送指定其选择的回复，因为这很容易压倒发送者，尤其是在大规模多播应用中。
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).
在基于单播的应用中，发送方和接收方可以采用提供/应答模型[rfc326]来设置FEC框架配置信息。在这种情况下，发送方提供此特定接收方可用的选项，接收方用其选择回复发送方。
Receivers supporting the SDP Capability Negotiation Framework [RFC5939] MAY also use this framework to negotiate all, or a subset, of the FEC Framework parameters.
支持SDP能力协商框架[RFC5939]的接收机还可以使用该框架协商FEC框架参数的全部或子集。
The backward compatibility in the Offer/Answer Model is handled as specified in [RFC5956].
提供/应答模型中的向后兼容性按照[RFC5956]中的规定处理。
This section provides SDP examples that can be used by the FEC Framework.
本节提供了FEC框架可以使用的SDP示例。
[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.
[RFC5888]将媒体流标识属性（“mid”）定义为ABNF中的令牌。相反，源流的标识符是整数，可以从零开始分配，并为每个流增加1。为避免任何歧义，建议不要使用相同的值来标识媒体流和源流，即使“中间”值是整数。
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.
在下面的示例中，随机FEC编码id将用于说明目的。还将提供SS-FSSI和FSSI的人工内容。
SOURCE FLOWS | INSTANCE #1
S1: Source Flow |--------| R1: Repair Flow
|
SOURCE FLOWS | INSTANCE #1
S1: Source Flow |--------| R1: Repair Flow
|
Figure 1: Scenario #1
图1：情景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.
在本例中，我们有一个源视频流（mid:S1）和一个FEC修复流（mid:R1）。我们用“a=组：FEC-FR S1 R1”行组成一个FEC组。源流和修复流被发送到不同多播组上的同一端口。维修窗口设置为150毫秒。
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
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
SOURCE FLOWS
S2: Source Flow | | INSTANCE #1
|---------| R2: Repair Flow
S3: Source Flow |
SOURCE FLOWS
S2: Source Flow | | INSTANCE #1
|---------| R2: Repair Flow
S3: Source Flow |
Figure 2: Scenario #2
图2：场景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.
在本例中，我们有两个源视频流（mid:S2和mid:S3）和一个FEC修复流（mid:R2）来保护这两个源流。我们用“a=组：FEC-FR S2 S3 R2”行组成一个FEC组。源流和修复流被发送到不同多播组上的同一端口。维修窗口设置为150500 us。
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
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
SOURCE FLOWS | INSTANCE #1
S4: Source Flow |--------| R3: Repair Flow
SOURCE FLOWS | INSTANCE #1
S4: Source Flow |--------| R3: Repair Flow
S5: Source Flow |--------| INSTANCE #2
| R4: Repair Flow
S5: Source Flow |--------| INSTANCE #2
| R4: Repair Flow
Figure 3: Scenario #3
图3：场景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.
在本例中，我们有两个源视频流（mid:S4和mid:S5）和两个FEC修复流（mid:R3和mid:R4）。源流mid:S4和mid:S5分别受到维修流mid:R3和mid:R4的保护。我们用“a=组：FEC-FR S4 R3”和“a=组：FEC-FR S5 R4”线组成两个FEC组。源流和修复流被发送到不同多播组上的同一端口。第一个和第二个FEC组的修复窗口分别设置为200ms和400ms。
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
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
SOURCE FLOWS | INSTANCE #1
S6: Source Flow |--------| R5: Repair Flow
|
|--------| INSTANCE #2
| R6: Repair Flow
SOURCE FLOWS | INSTANCE #1
S6: Source Flow |--------| R5: Repair Flow
|
|--------| INSTANCE #2
| R6: Repair Flow
Figure 4: Scenario #4
图4：场景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.
在本例中，我们有一个源视频流（mid:S6）和两个具有不同偏好级别的FEC修复流（mid:R5和mid:R6）。源流mid:S6受两个维修流的保护。我们用“a=组：FEC-FR S6 R5”和“a=组：FEC-FR S6 R6”线组成两个FEC组。源流和修复流被发送到不同多播组上的同一端口。两个FEC组的修复窗口均设置为200 ms。
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
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
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].
如果SDP的修改方式显示源和修复流的不正确关联和/或分组，则存在微弱威胁。此类攻击可能导致FEC保护失败和/或其他媒体流处理不当。建议接收方对SDP执行完整性检查，以仅信任来自受信任源的SDP。接收方还必须遵守SDP[RFC4566]的安全注意事项。有关SDP的其他一般安全注意事项，请参阅[RFC4566]。有关在SDP中使用源地址筛选器的安全注意事项，请参阅[RFC4570]。
The security considerations for the FEC Framework also apply. Refer to [RFC6363] for details.
FEC框架的安全考虑也适用。有关详细信息，请参阅[RFC6363]。
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.
本规范更新了[RFC4566]第8.2.2节中定义的“会话描述协议（SDP）参数”注册表。具体来说，它将以下值添加到“proto”字段的表中。
Type SDP Name Reference
------ ---------- -----------
proto FEC/UDP [RFC6364]
proto UDP/FEC [RFC6364]
Type SDP Name Reference
------ ---------- -----------
proto FEC/UDP [RFC6364]
proto UDP/FEC [RFC6364]
This document registers new attribute names in SDP.
此文档在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属性（“att字段”）：属性名称：fec源流长格式：指向fec源流的指针名称类型：att字段类型属性：媒体级别受字符集约束：无用途：为fec源流引用提供参数：[RFC6364]值：请参阅[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属性（“att字段”）：属性名称：fec修复流长格式：指向fec修复流的指针名称类型：att字段类型属性：媒体级别受字符集约束：无用途：为fec修复流引用提供参数：[RFC6364]值：请参阅[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]
SDP属性（“att字段”）：属性名称：修复窗口长格式：指向FEC修复窗口的指针名称类型：att字段类型属性：媒体级别根据字符集：无用途：指示修复窗口的大小参考：[RFC6364]值：请参阅[RFC6364]
The author would like to thank the FEC Framework Design Team for their inputs, suggestions, and contributions.
作者要感谢FEC框架设计团队的投入、建议和贡献。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363]Watson，M.，Begen，A.，和V.Roca，“前向纠错（FEC）框架”，RFC6363，2011年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", RFC 4570, July 2006.
[RFC4570]Quinn，B.和R.Finlayson，“会话描述协议（SDP）源过滤器”，RFC 45702006年7月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，2010年6月。
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, September 2010.
[RFC5956]Begen，A.“会话描述协议中的前向纠错分组语义”，RFC 59562010年9月。
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[RFC3890]Westerlund，M.“会话描述协议（SDP）的传输无关带宽修改器”，RFC 38902004年9月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[FECFRAME-CFG-SIGNAL] Asati, R., "Methods to convey FEC Framework Configuration Information", Work in Progress, September 2011.
[FECFRAME-CFG-SIGNAL]Asati，R.，“FEC框架配置信息的传递方法”，正在进行的工作，2011年9月。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939]Andreasen，F.，“会话描述协议（SDP）能力协商”，RFC 59392010年9月。
Author's Address
作者地址
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco位于加拿大多伦多湾街181号M5J 2T3
EMail: abegen@cisco.com
EMail: abegen@cisco.com