Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 5956 Cisco
Obsoletes: 4756 September 2010
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 5956 Cisco
Obsoletes: 4756 September 2010
Category: Standards Track
ISSN: 2070-1721
Forward Error Correction Grouping Semantics in the Session Description Protocol
会话描述协议中的前向纠错分组语义
Abstract
摘要
This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888). These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing.
本文档定义了会话描述协议（SDP）中关联源和基于FEC（前向纠错）修复流的分组语义。本文档中定义的语义将与SDP分组框架（RFC 5888）一起使用。当一个或多个源和/或修复流关联在同一个组中时，这些语义允许描述源和修复流之间的分组关系，并且它们支持附加修复流。本文档还为使用SSRC多路复用的实时传输协议（RTP）流定义了SSRC级（同步源）分组语义。
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/rfc5956.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5956.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation ...........................................5
3. Requirements and Changes from RFC 4756 ..........................5
3.1. FEC Grouping Requirements ..................................5
3.2. Source and Repair Flow Associations ........................6
3.3. Support for Additivity .....................................6
4. FEC Grouping ....................................................7
4.1. "FEC-FR" Grouping Semantics ................................7
4.2. SDP Example ................................................7
4.3. FEC Grouping for SSRC-Multiplexed RTP Streams ..............9
4.4. "FEC" Grouping Semantics ..................................10
4.5. SDP Offer/Answer Model and RFC 4756
Backward-Compatibility Considerations .....................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................12
7. Acknowledgments ................................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
1. Introduction ....................................................3
2. Requirements Notation ...........................................5
3. Requirements and Changes from RFC 4756 ..........................5
3.1. FEC Grouping Requirements ..................................5
3.2. Source and Repair Flow Associations ........................6
3.3. Support for Additivity .....................................6
4. FEC Grouping ....................................................7
4.1. "FEC-FR" Grouping Semantics ................................7
4.2. SDP Example ................................................7
4.3. FEC Grouping for SSRC-Multiplexed RTP Streams ..............9
4.4. "FEC" Grouping Semantics ..................................10
4.5. SDP Offer/Answer Model and RFC 4756
Backward-Compatibility Considerations .....................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................12
7. Acknowledgments ................................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
Any application that needs a reliable transmission over an unreliable packet network has to cope with packet losses. Forward Error Correction (FEC) is an effective approach that improves the reliability of the transmission, particularly in multicast and broadcast applications where the feedback from the receiver(s) is potentially 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 may be sent on demand or independently of any receiver feedback. The choice depends on the FEC scheme, the packet loss characteristics of the underlying network, the transport scheme (e.g., unicast, multicast, and broadcast), and the application. 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方案、底层网络的丢包特性、传输方案（例如，单播、多播和广播）和应用程序。在接收机侧，只要接收到足够数量的源和修复分组，就可以通过擦除解码来恢复丢失的分组。
For example, one of the most basic FEC schemes is the parity codes, where an exclusive OR (XOR) operation is applied to a group of packets (i.e., source block) to generate a single repair packet. At the receiver side, this scheme provides a full recovery if only one packet is lost within the source block and the repair packet is received. There are various other ways of generating repair packets, possibly with different loss-recovery capabilities.
例如，最基本的FEC方案之一是奇偶校验码，其中对分组组（即，源块）应用异或（XOR）操作以生成单个修复分组。在接收器端，如果在源块内仅丢失一个分组并且接收到修复分组，则该方案提供完全恢复。生成修复数据包的其他方法多种多样，可能具有不同的丢失恢复功能。
The FEC Framework [FEC-FRAMEWK] outlines a general framework for using FEC codes in multimedia applications that stream audio, video, or other types of multimedia content. The FEC Framework specification states that source and repair packets must be carried in different streams, which are referred to as the source and repair flows, respectively. At the receiver side, the receivers should know which flows are the source flows and which ones are the repair flows. The receivers should also know the exact association of the source and repair flows so that they can use the correct data to repair the original content in case there is a packet loss. SDP [RFC4566] uses [RFC5888] and this RFC for this purpose.
FEC框架[FEC-FRAMEWK]概述了在流式传输音频、视频或其他类型多媒体内容的多媒体应用程序中使用FEC代码的一般框架。FEC框架规范规定源数据包和修复数据包必须在不同的流中传输，这些流分别称为源数据流和修复数据流。在接收方，接收方应该知道哪些流是源流，哪些流是修复流。接收者还应该知道源流和修复流的确切关联，以便在数据包丢失的情况下使用正确的数据修复原始内容。SDP[RFC4566]为此目的使用[RFC5888]和此RFC。
In order to provide applications more flexibility, the FEC Framework [FEC-FRAMEWK] allows a source flow to be protected by multiple FEC schemes, each of which requires an instance of the FEC Framework. Thus, multiple instances of the FEC Framework may exist at the sender and the receiver(s). Furthermore, within a single FEC Framework instance, multiple source flows may be grouped and protected by one or more repair flows.
为了给应用程序提供更大的灵活性，FEC框架[FEC-FRAMEWK]允许源流受到多个FEC方案的保护，每个方案都需要一个FEC框架实例。因此，FEC框架的多个实例可以存在于发送方和接收方。此外，在单个FEC框架实例中，多个源流可以由一个或多个修复流分组和保护。
The FEC Framework requires the source and repair packets to be carried in different streams. When the Real-time Transport Protocol (RTP) [RFC3550] is used to carry the source and repair streams, the FEC Framework recommends that each stream be carried in its own RTP session. This provides flexibility in using FEC in a backward-compatible manner. However, in some scenarios, it may be desirable for a single RTP session to carry multiple RTP streams via Synchronization Source (SSRC) multiplexing in order to reduce the port usage. For such scenarios, appropriate grouping semantics are also required.
FEC框架要求在不同的流中携带源和修复数据包。当使用实时传输协议（RTP）[RFC3550]来承载源流和修复流时，FEC框架建议在其自己的RTP会话中承载每个流。这为以向后兼容的方式使用FEC提供了灵活性。然而，在一些场景中，可能希望单个RTP会话通过同步源（SSRC）复用来承载多个RTP流，以减少端口使用。对于此类场景，还需要适当的分组语义。
A basic example scenario is shown in Figure 1. Here, the source flow S1 is protected by the repair flow R1. Also, the source flows S1 and S2 are grouped and protected together by the repair flow R2.
图1显示了一个基本的示例场景。这里，源流S1由修复流R1保护。此外，源流S1和S2由修复流R2分组和保护在一起。
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
| S1: Source Flow |--------| R1: Repair Flow
+---|
| | S2: Source Flow
|
+______________________________| FEC FRAMEWORK INSTANCE #2
| R2: Repair Flow
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
| S1: Source Flow |--------| R1: Repair Flow
+---|
| | S2: Source Flow
|
+______________________________| FEC FRAMEWORK INSTANCE #2
| R2: Repair Flow
Figure 1: Example scenario with two FEC Framework instances where R1 protects S1 and R2 protects the group of S1 and S2
图1：两个FEC框架实例的示例场景，其中R1保护S1，R2保护S1和S2组
Grouping source flows before applying FEC protection may allow us to achieve a better coding performance. As a typical scenario, suppose that source flows S1 and S2 in Figure 1 correspond to the base and enhancement layers in a layered video content, respectively. The repair flow R2 protects the combination of the base and enhancement layers for the receivers that receive both layers, whereas the repair flow R1 protects the base layer only, for the receivers that want the base layer only or that receive both layers but prefer FEC protection for the base layer only due to a bandwidth or any other limitation.
在应用FEC保护之前对源流进行分组可以使我们获得更好的编码性能。作为典型场景，假设图1中的源流S1和S2分别对应于分层视频内容中的基本层和增强层。修复流R2为接收两个层的接收机保护基本层和增强层的组合，而修复流R1仅为仅需要基本层或接收两个层但仅由于带宽或任何其他限制而偏好对基本层进行FEC保护的接收机保护基本层。
The grouping semantics defined in this document offer the flexibility to determine how source streams are grouped together prior to applying FEC protection. However, not all FEC schemes may support the full range of the possible scenarios (e.g., when the source streams carry different top-level media types such as audio and video).
本文档中定义的分组语义提供了在应用FEC保护之前确定如何将源流分组在一起的灵活性。然而，并非所有FEC方案都可以支持所有可能的场景（例如，当源流携带不同的顶级媒体类型，例如音频和视频时）。
Using multiple FEC Framework instances for a single source flow provides flexibility to the receivers. An example scenario is sketched in Figure 2. Different instances may offer repair flows that are generated by different FEC schemes, and receivers choose to receive the appropriate repair flow(s) that they can support and
对单个源流使用多个FEC框架实例为接收器提供了灵活性。图2中绘制了一个示例场景。不同的实例可以提供由不同的FEC方案生成的修复流，并且接收方选择接收它们可以支持和支持的适当的修复流
decode. Alternatively, different instances (whether or not they use the same FEC scheme) may use larger and smaller source block sizes, which accommodate the receivers that have looser and tighter latency requirements, respectively. In addition, different instances may also provide FEC protection at different redundancy levels. This is particularly useful in multicast scenarios where different receivers may experience different packet loss rates and each receiver can choose the repair flow that is tailored to its needs.
解码或者，不同的实例（无论它们是否使用相同的FEC方案）可以使用更大和更小的源块大小，这分别适应具有更宽松和更严格延迟要求的接收机。此外，不同实例还可以在不同冗余级别提供FEC保护。这在多播场景中特别有用，在多播场景中，不同的接收器可能会经历不同的分组丢失率，并且每个接收器可以选择适合其需要的修复流。
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S3: Source Flow |---------| R3: Repair Flow
|
|---------| FEC FRAMEWORK INSTANCE #2
| R4: Repair Flow
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S3: Source Flow |---------| R3: Repair Flow
|
|---------| FEC FRAMEWORK INSTANCE #2
| R4: Repair Flow
Figure 2: Example scenario with two FEC Framework instances, each with a single repair flow protecting the same source flow S3
图2：具有两个FEC框架实例的示例场景，每个实例都有一个修复流来保护相同的源流S3
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
As illustrated in the introduction and based on the FEC Framework [FEC-FRAMEWK], the SDP grouping semantics for FEC must support the ability to indicate that:
如引言所示，基于FEC框架[FEC-FRAMEWK]，FEC的SDP分组语义必须支持以下能力：
1. A given source flow is protected by multiple different FEC schemes.
1. 给定的源流由多个不同的FEC方案保护。
2. Multiple repair flows are associated with a given FEC scheme.
2. 多个修复流与给定的FEC方案相关联。
3. Multiple source flows are grouped prior to applying FEC protection.
3. 在应用FEC保护之前，对多个源流进行分组。
4. One or more repair flows protect a group of source flows.
4. 一个或多个修复流保护一组源流。
The FEC grouping semantics defined in this document and the SDP "group" attribute defined in [RFC5888] are used to associate source and repair flows. This document also specifies how the "group" attribute is used to group multiple repair flows with one or more source flows.
本文档中定义的FEC分组语义和[RFC5888]中定义的SDP“group”属性用于关联源流和修复流。本文档还指定了如何使用“组”属性将多个修复流与一个或多个源流分组。
Note that [RFC5888] obsoleted [RFC3388] to allow an "m" line identified by its "mid" attribute to appear in more than one "a=group" line using the same semantics. With this change and the definitions contained in this document of the FEC grouping semantics, a sender can indicate the specific associations between the source and repair flows, and a receiver can determine which repair flow(s) protect which source flow(s).
请注意，[RFC5888]淘汰了[RFC3388]，以允许由其“mid”属性标识的“m”行使用相同的语义出现在多个“a=group”行中。通过此更改和本文件中包含的FEC分组语义定义，发送方可以指示源流和修复流之间的特定关联，接收方可以确定哪个修复流保护哪个源流。
This document defines the FEC grouping semantics and obsoletes [RFC4756]. Implementations compliant with this document MUST use the semantics introduced in Sections 4.1 and 4.3. In addition to complying with the requirements defined in Sections 4.1 and 4.3, implementations are RECOMMENDED to support the "FEC" semantics specified in Section 4.4 for backward-compatibility reasons in scenarios described in Section 4.5.
本文件定义了FEC分组语义和淘汰项[RFC4756]。符合本文档的实现必须使用第4.1节和第4.3节中介绍的语义。除了遵守第4.1节和第4.3节中定义的要求外，建议实施支持第4.4节中规定的“FEC”语义，以在第4.5节中描述的场景中实现向后兼容性。
The FEC Framework [FEC-FRAMEWK] describes support for additive repair flows. Additivity among the repair flows means that multiple repair flows may be decoded jointly to improve the recovery chances of the missing packets in a single or the same set of source flows. Additive repair flows can be generated by the same FEC scheme or different FEC schemes.
FEC框架[FEC-FRAMEWK]描述了对附加修复流的支持。修复流之间的可加性意味着可以联合解码多个修复流，以提高单个或同一组源流中丢失分组的恢复机会。附加修复流可以由相同的FEC方案或不同的FEC方案生成。
For example, in Figure 3, the repair flows R5 and R6 may be additive within the FEC Framework instance #1. Alternatively, all three repair flows R5, R6, and R7 could be additive, too.
例如，在图3中，修复流R5和R6可以在FEC框架实例#1中相加。或者，所有三个修复流R5、R6和R7也可以是相加的。
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S4: Source Flow |---------| R5: Repair Flow
| | R6: Repair Flow
|
|---------| FEC FRAMEWORK INSTANCE #2
| R7: Repair Flow
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S4: Source Flow |---------| R5: Repair Flow
| | R6: Repair Flow
|
|---------| FEC FRAMEWORK INSTANCE #2
| R7: Repair Flow
Figure 3: Example scenario with two FEC Framework instances where two repair flows in the first instance and a single repair flow in the second instance protect the same source flow S4
图3：两个FEC框架实例的示例场景，其中第一个实例中的两个修复流和第二个实例中的一个修复流保护相同的源流
This document defines the mechanisms to support additive repair flows that were not included in [RFC4756].
本文件定义了支持[RFC4756]中未包含的附加维修流程的机制。
Each "a=group" line is used to indicate an association relationship between the source and repair flows. The flows included in one "a=group" line are called an FEC group. If there is more than one repair flow included in an FEC group, these repair flows MUST be considered to be additive. Repair flows that are not additive MUST be indicated in separate FEC groups. However, if two (or more) repair flows are additive in an FEC group, it does not necessarily mean that these repair flows will also be additive in any other FEC group. Generally, in order to express multiple relations between the source and repair flows, each source and repair flow MAY appear in more than one FEC group.
每个“a=组”行用于指示源流和修复流之间的关联关系。包含在一个“a=组”行中的流称为FEC组。如果FEC组中包含多个维修流，则必须将这些维修流视为附加维修流。非添加剂的维修流程必须在单独的FEC组中指示。但是，如果两个（或更多）修复流在一个FEC组中是相加的，则不一定意味着这些修复流在任何其他FEC组中也是相加的。通常，为了表示源和修复流之间的多个关系，每个源和修复流可以出现在多个FEC组中。
Using the framework in [RFC5888], this document defines "FEC-FR" as the grouping semantics to indicate support for the FEC Framework features.
使用[RFC5888]中的框架，本文档将“FEC-FR”定义为分组语义，以表示对FEC框架功能的支持。
The "a=group:FEC-FR" semantics MUST be used to associate the source and repair flows except when the source and repair flows are specified in the same media description, i.e., in the same "m" line (see Section 4.3). Note that additivity is not necessarily a transitive relationship. Thus, each set of additive repair flows MUST be stated explicitly in SDP, as illustrated in the example below.
“a=group:FEC-FR”语义必须用于关联源流和修复流，除非源流和修复流在同一介质描述中指定，即在同一“m”行中指定（见第4.3节）。注意，可加性不一定是传递关系。因此，必须在SDP中明确说明每组附加维修流，如下面的示例所示。
For the scenario sketched in Figure 1, we need to write the following SDP:
对于图1所示的场景，我们需要编写以下SDP：
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Grouping Semantics
t=0 0
a=group:FEC-FR S1 R1
a=group:FEC-FR S1 S2 R2
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=mid:S1
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000
a=mid:S2
m=application 30000 RTP/AVP 110
c=IN IP4 233.252.0.3/127
a=rtpmap:110 1d-interleaved-parityfec/90000
a=fmtp:110 L=5; D=10; repair-window=200000
a=mid:R1
m=application 30000 RTP/AVP 111
c=IN IP4 233.252.0.4/127
a=rtpmap:111 1d-interleaved-parityfec/90000
a=fmtp:111 L=10; D=10; repair-window=400000
a=mid:R2
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Grouping Semantics
t=0 0
a=group:FEC-FR S1 R1
a=group:FEC-FR S1 S2 R2
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=mid:S1
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000
a=mid:S2
m=application 30000 RTP/AVP 110
c=IN IP4 233.252.0.3/127
a=rtpmap:110 1d-interleaved-parityfec/90000
a=fmtp:110 L=5; D=10; repair-window=200000
a=mid:R1
m=application 30000 RTP/AVP 111
c=IN IP4 233.252.0.4/127
a=rtpmap:111 1d-interleaved-parityfec/90000
a=fmtp:111 L=10; D=10; repair-window=400000
a=mid:R2
In this example, the source and repair flows are carried in their own RTP sessions, and the grouping is achieved through the "a=group:FEC-FR" lines.
在本例中，源流和修复流在各自的RTP会话中进行，分组是通过“a=group:FEC-FR”行实现的。
For the additivity example, let us consider the scenario sketched in Figure 3. Suppose that repair flows R5 and R6 are additive but repair flow R7 is not additive with any of the other repair flows. In this case, we must write
对于可加性示例，让我们考虑图3中勾画的场景。假设维修流R5和R6是相加的，但维修流R7与任何其他维修流都不是相加的。在这种情况下，我们必须写作
a=group:FEC-FR S4 R5 R6
a=group:FEC-FR S4 R7
a=group:FEC-FR S4 R5 R6
a=group:FEC-FR S4 R7
If none of the repair flows is additive, we must write
如果没有一个修复流是加法的，我们必须编写
a=group:FEC-FR S4 R5
a=group:FEC-FR S4 R6
a=group:FEC-FR S4 R7
a=group:FEC-FR S4 R5
a=group:FEC-FR S4 R6
a=group:FEC-FR S4 R7
[RFC5576] defines an SDP media-level attribute, called "ssrc-group", for grouping the RTP streams that are SSRC multiplexed and carried in the same RTP session. The grouping is based on the Synchronization Source (SSRC) identifiers. Since SSRC-multiplexed RTP streams are defined in the same "m" line, the "group" attribute cannot be used.
[RFC5576]定义了一个称为“ssrc组”的SDP媒体级属性，用于对ssrc多路复用并在同一RTP会话中传输的RTP流进行分组。分组基于同步源（SSRC）标识符。由于SSRC多路复用RTP流定义在同一“m”行中，因此不能使用“group”属性。
This section specifies how FEC is applied to source and repair flows for SSRC-multiplexed streams using the "ssrc-group" attribute [RFC5576]. This section also specifies how the additivity of the repair flows is expressed for the SSRC-multiplexed streams.
本节指定如何使用“SSRC组”属性[RFC5576]将FEC应用于SSRC多路复用流的源流和修复流。本节还规定了如何表示SSRC多路复用流的修复流的可加性。
The semantics of "FEC-FR" for the "ssrc-group" attribute are the same as those defined for the "group" attribute, except that the SSRC identifiers are used to designate the FEC grouping associations: a=ssrc-group:FEC-FR *(SP ssrc-id) [RFC5576].
“ssrc group”属性的“FEC-FR”语义与为“group”属性定义的语义相同，只是ssrc标识符用于指定FEC分组关联：a=ssrc group:FEC-FR*（SP ssrc id）[RFC5576]。
The SSRC identifiers for the RTP streams that are carried in the same RTP session MUST be unique per [RFC3550]. However, the SSRC identifiers are not guaranteed to be unique among different RTP sessions. Thus, the "ssrc-group" attribute MUST only be used at the media level [RFC5576].
根据[RFC3550]，在同一RTP会话中承载的RTP流的SSRC标识符必须是唯一的。但是，SSRC标识符不能保证在不同RTP会话中是唯一的。因此，“ssrc group”属性只能在媒体级别使用[RFC5576]。
Let us consider the following scenario where there are two source flows (e.g., one video and one audio) and a single repair flow that protects only one of the source flows (e.g., video). Suppose that all these flows are separate RTP streams that are SSRC multiplexed in the same RTP session.
让我们考虑下面的场景，其中有两个源流（例如，一个视频和一个音频）和仅保护一个源流（例如，视频）的单个修复流。假设所有这些流都是在同一RTP会话中被SSRC多路复用的独立RTP流。
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S5: Source Flow |--------| R8: Repair Flow
S6: Source Flow
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S5: Source Flow |--------| R8: Repair Flow
S6: Source Flow
Figure 4: Example scenario with one FEC Framework instance where a single repair flow protects only one of the source flows
图4：一个FEC框架实例的示例场景，其中单个修复流仅保护一个源流
The following SDP describes the scenario sketched in Figure 4.
下面的SDP描述了图4所示的场景。
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Grouping Semantics for SSRC Multiplexing
t=0 0
m=video 30000 RTP/AVP 100 101 110
c=IN IP4 233.252.0.1/127
a=rtpmap:100 JPEG/90000
a=rtpmap:101 L16/32000/2
a=rtpmap:110 1d-interleaved-parityfec/90000
a=fmtp:110 L=5; D=10; repair-window=200000
a=ssrc:1000 cname:fec@example.com
a=ssrc:1010 cname:fec@example.com
a=ssrc:2110 cname:fec@example.com
a=ssrc-group:FEC-FR 1000 2110
a=mid:Group1
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Grouping Semantics for SSRC Multiplexing
t=0 0
m=video 30000 RTP/AVP 100 101 110
c=IN IP4 233.252.0.1/127
a=rtpmap:100 JPEG/90000
a=rtpmap:101 L16/32000/2
a=rtpmap:110 1d-interleaved-parityfec/90000
a=fmtp:110 L=5; D=10; repair-window=200000
a=ssrc:1000 cname:fec@example.com
a=ssrc:1010 cname:fec@example.com
a=ssrc:2110 cname:fec@example.com
a=ssrc-group:FEC-FR 1000 2110
a=mid:Group1
Note that in actual use, SSRC values, which are random 32-bit numbers, may be much larger than the ones shown in this example. Also, note that before receiving an RTP packet for each stream, the receiver cannot know which SSRC identifier is associated with which payload type.
请注意，在实际使用中，SSRC值（随机32位数字）可能比本示例中显示的值大得多。另外，请注意，在接收每个流的RTP数据包之前，接收器无法知道哪个SSRC标识符与哪个有效负载类型关联。
The additivity of the repair flows is handled in the same way as described in Section 4.2. In other words, the repair flows that are included in an "a=ssrc-group" line MUST be additive. Repair flows that are not additive MUST be indicated in separate "a=ssrc-group" lines.
修理流程的可加性处理方式与第4.2节所述相同。换句话说，包含在“a=ssrc组”行中的维修流程必须是相加的。非附加的维修流程必须在单独的“a=ssrc组”行中注明。
This document deprecates the usage of the "FEC" semantics. Sessions negotiated between two endpoints implementing this specification MUST use the "FEC-FR" semantics and not the "FEC" semantics. Section 4.5 details how an implementation supporting this specification detects peers that do not support this specification (based on their SDP answer to the initial offer). When this occurs, the offering implementation SHOULD initiate a new offer using the "FEC" semantics as defined in this section.
本文档不推荐使用“FEC”语义。实现此规范的两个端点之间协商的会话必须使用“FEC-FR”语义，而不是“FEC”语义。第4.5节详细说明了支持本规范的实现如何检测不支持本规范的对等方（基于其对初始报价的SDP回答）。出现这种情况时，产品实现应使用本节中定义的“FEC”语义启动新产品。
The "FEC" grouping semantics had been originally introduced in [RFC4756]. The "FEC" semantics used the "a=group" line from [RFC3388] to form an FEC group to indicate the association relationship between the source and repair flows.
“FEC”分组语义最初是在[RFC4756]中引入的。“FEC”语义使用[RFC3388]中的“a=group”行来形成FEC组，以指示源流和修复流之间的关联关系。
In the "FEC" semantics, a source or repair flow can only appear in a single "a=group:FEC" line. Thus, all the source and repair flows that are somehow related to each other have to be listed in the same "a=group:FEC" line. For example, for the scenario sketched in
在“FEC”语义中，源或修复流只能出现在单个“a=group:FEC”行中。因此，必须在同一行“a=组：FEC”中列出所有以某种方式相互关联的源流和修复流。例如，对于中绘制的场景
Figure 1, we have to write "a=group:FEC S1 S2 R1 R2" regardless of which repair flows protect which particular source flows. Similarly, for the scenario sketched in Figure 3, we have to write "a=group:FEC S4 R5 R6 R7" regardless of which repair flows are additive. However, the interpretation of these lines would be ambiguous.
图1中，我们必须编写“a=group:fecs1s2 r1r2”，不管哪个修复流保护哪个特定的源流。类似地，对于图3中所示的场景，我们必须编写“a=组：FEC S4 R5 R6 R7”，而不管哪种修复流是加法的。然而，对这些行的解释将是模棱两可的。
In certain simple scenarios, such as where there is one source flow and one repair flow, these limitations may not be a concern. In Offer/Answer model scenarios, when the "FEC-FR" semantics are not understood by the answerer, the "FEC" semantics can be offered, as long as the "FEC" semantics provide an exact association among the source and repair flows and do not create any ambiguity. See Section 4.5 for details.
在某些简单的场景中，例如存在一个源流和一个修复流的情况下，这些限制可能不会引起关注。在提供/应答模型场景中，当应答者不理解“FEC-FR”语义时，可以提供“FEC”语义，只要“FEC”语义提供源流和修复流之间的精确关联且不产生任何歧义。详见第4.5节。
4.5. SDP Offer/Answer Model and RFC 4756 Backward-Compatibility Considerations
4.5. SDP提供/应答模型和RFC 4756向后兼容性注意事项
When offering FEC grouping using SDP in an Offer/Answer model [RFC3264], the following considerations apply.
在提供/应答模型[RFC3264]中使用SDP提供FEC分组时，应考虑以下因素。
A node that is receiving an offer from a sender may or may not understand line grouping. It is also possible that the node understands line grouping but it does not understand the "FEC-FR" semantics. From the viewpoint of the sender of the offer, these cases are indistinguishable.
从发送方接收报价的节点可能理解也可能不理解行分组。节点也可能理解线路分组，但不理解“FEC-FR”语义。从要约发送人的角度来看，这些情况无法区分。
Implementations are RECOMMENDED to support the "FEC" semantics specified in Section 4.4 for backward-compatibility reasons. If the sender of the offer supports the "FEC" semantics, it SHOULD fall back to using the "FEC" semantics when the "FEC-FR" semantics are not understood by the node.
出于向后兼容性的原因，建议实现支持第4.4节中指定的“FEC”语义。如果要约的发送方支持“FEC”语义，那么当节点不理解“FEC-FR”语义时，它应该返回使用“FEC”语义。
When a node is offered a session with the "FEC-FR" grouping semantics, but it does not support line grouping or the FEC grouping semantics, as per [RFC5888], the node responds to the offer with one of the following:
当根据[RFC5888]向节点提供了具有“FEC-FR”分组语义的会话，但它不支持行分组或FEC分组语义时，节点会使用以下之一响应该提议：
o An answer that ignores the grouping attribute.
o 忽略分组属性的答案。
In this case, if the original sender of the offer
在这种情况下，如果要约的原始发件人
* supports the "FEC" semantics described in Section 4.4, it MUST first check whether or not using the "FEC" semantics will create any ambiguity. If using the "FEC" semantics still provides an exact association among the source and repair flows, the sender SHOULD send a new offer using the "FEC" semantics. However, if an exact association cannot be described, it MUST send a new offer without FEC.
* 支持第4.4节中描述的“FEC”语义，必须首先检查使用“FEC”语义是否会产生任何歧义。如果使用“FEC”语义仍能在源流和修复流之间提供精确的关联，则发送方应使用“FEC”语义发送新要约。但是，如果无法描述确切的关联，则必须发送不带FEC的新报价。
* does not support the "FEC" semantics described in Section 4.4, it MUST send a new offer without FEC.
* 不支持第4.4节中描述的“FEC”语义，它必须在没有FEC的情况下发送新报价。
o A refusal to the request (e.g., 488 Not Acceptable Here or 606 Not Acceptable in SIP).
o 拒绝请求（例如，此处不接受488或SIP中不接受606）。
In this case, if the original sender of the offer
在这种情况下，如果要约的原始发件人
* supports the "FEC" semantics and still wishes to establish the session, it MUST first check whether or not using the "FEC" semantics will create any ambiguity. If using the "FEC" semantics still provides an exact association among the source and repair flows, the sender SHOULD send a new offer using the "FEC" semantics. However, if an exact association cannot be described, it SHOULD send a new offer without FEC.
* 支持“FEC”语义并且仍希望建立会话，它必须首先检查使用“FEC”语义是否会产生任何歧义。如果使用“FEC”语义仍能在源流和修复流之间提供精确的关联，则发送方应使用“FEC”语义发送新要约。但是，如果无法描述确切的关联，则应发送不带FEC的新报价。
* does not support the "FEC" semantics described in Section 4.4, it SHOULD send a new offer without FEC.
* 不支持第4.4节中描述的“FEC”语义，它应在不使用FEC的情况下发送新报价。
In both cases described above, when the sender of the offer sends a new offer with the "FEC" semantics, and the node understands it, the session will be established, and the rules pertaining to the "FEC" semantics will apply.
在上述两种情况下，当要约的发送者发送具有“FEC”语义的新要约并且节点理解它时，会话将被建立，并且与“FEC”语义相关的规则将被应用。
As specified in [RFC5888], if the node does not understand the "FEC" semantics, it responds to the offer with either (1) an answer that ignores the grouping attribute or (2) a refusal to the request. In the first case, the sender must send a new offer without FEC. In the second case, if the sender still wishes to establish the session, it should retry the request with an offer without FEC.
如[RFC5888]中所述，如果节点不理解“FEC”语义，则它会以（1）忽略分组属性的回答或（2）拒绝请求的方式响应要约。在第一种情况下，发送方必须发送不带FEC的新报价。在第二种情况下，如果发送方仍希望建立会话，则应使用不带FEC的要约重试请求。
There is a weak threat for the receiver that the FEC grouping can be modified to indicate FEC relationships that do not exist. Such attacks may result in failure of FEC to protect, and/or to mishandle, other media payload streams. The receiver SHOULD do an integrity check on SDP and follow the security considerations of SDP [RFC4566] to trust only SDP from trusted sources.
对于接收方来说，FEC分组可能会被修改以指示不存在的FEC关系的威胁很小。此类攻击可能导致FEC无法保护和/或错误处理其他媒体有效负载流。接收方应对SDP进行完整性检查，并遵循SDP[RFC4566]的安全注意事项，仅信任来自受信任源的SDP。
This document registers the following semantics with IANA in the "Semantics for the "group" SDP Attribute" registry under SDP Parameters:
本文档在SDP参数下的“组”SDP属性的语义”注册表中向IANA注册以下语义：
Semantics Token Reference
------------------------------------- ------ ---------
Forward Error Correction (Deprecated) FEC [RFC5956]
Forward Error Correction FR FEC-FR [RFC5956]
Semantics Token Reference
------------------------------------- ------ ---------
Forward Error Correction (Deprecated) FEC [RFC5956]
Forward Error Correction FR FEC-FR [RFC5956]
This document also registers the following semantics with IANA in the "Semantics for the "ssrc-group" SDP Attribute" registry under SDP Parameters:
本文档还在SDP参数下的“ssrc组”SDP属性的语义”注册表中向IANA注册以下语义：
Token Semantics Reference
------- ----------------------------- ---------
FEC-FR Forward Error Correction FR [RFC5956]
Token Semantics Reference
------- ----------------------------- ---------
FEC-FR Forward Error Correction FR [RFC5956]
Some parts of this document are based on [RFC4756]. Thus, the author would like to thank those who contributed to [RFC4756]. Also, thanks to Jonathan Lennox, who has contributed to Section 4.3; and Jean-Francois Mule, who has reviewed this document in great detail and suggested text edits.
本文件的某些部分基于[RFC4756]。因此，作者要感谢那些为[RFC4756]做出贡献的人。此外，感谢Jonathan Lennox，他为第4.3节做出了贡献；还有Jean-Francois Mule，他非常详细地审查了这份文件，并建议进行文本编辑。
[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月。
[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月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[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月。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[RFC5576]Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 55762009年6月。
[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月。
[FEC-FRAMEWK] Watson, M., "Forward Error Correction (FEC) Framework", Work in Progress, September 2010.
[FEC-FRAMEWK]Watson，M.，“前向纠错（FEC）框架”，正在进行的工作，2010年9月。
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3388]Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006.
[RFC4756]李安，“会话描述协议中的前向纠错分组语义”，RFC4756，2006年11月。
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