[要約] RFC 5956は、セッション記述プロトコル（SDP）における転送エラー訂正（FEC）グループ化の意味論に関する規格です。このRFCの目的は、SDPを使用してFECグループ化を効果的に表現し、通信の信頼性と効率性を向上させることです。
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）で使用されます。これらのセマンティクスは、同じグループに1つまたは複数のソースおよび/または修復フローが関連付けられている場合、ソースと修理フローのグループ化関係の説明を可能にし、追加の修復フローをサポートします。SSRCレベル（同期ソース）グループ化セマンティクスは、SSRCマルチプレックスを使用したリアルタイムトランスポートプロトコル（RTP）ストリームのこのドキュメントでも定義されています。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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スキームの1つはパリティコードです。パリティコードでは、排他的または（XOR）操作がパケットのグループ（つまり、ソースブロック）のグループに適用され、単一の修理パケットが生成されます。レシーバー側では、ソースブロック内で1つのパケットのみが失われ、修理パケットが受信された場合、このスキームは完全な回復を提供します。おそらく異なる損失回復機能を備えた修理パケットを生成する他のさまざまな方法があります。
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]により、Source Flowを複数のFECスキームで保護できます。したがって、FECフレームワークの複数のインスタンスが送信者と受信機に存在する場合があります。さらに、単一のFECフレームワークインスタンス内で、複数のソースフローをグループ化および1つ以上の修理フローによって保護できます。
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
Figure 1: Example scenario with two FEC Framework instances where R1 protects S1 and R2 protects the group of S1 and S2
図1：R1がS1とR2を保護する2つのFECフレームワークインスタンスを使用して、S1とS2のグループを保護する2つのFECフレームワークインスタンスを使用した例のシナリオの例
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はベースレイヤーのみを保護します。帯域幅またはその他の制限が原因でのみベースレイヤーの場合。
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 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フレームワークインスタンスを使用すると、受信機に柔軟性が得られます。例のシナリオを図2にスケッチします。さまざまなインスタンスが、さまざまなFECスキームによって生成される修理フローを提供する場合があり、受信機はサポートおよびデコードできる適切な修理フローを受信することを選択します。あるいは、異なるインスタンス（同じFECスキームを使用するかどうかにかかわらず）が、それぞれ緩いレイテンシの要件を持つレシーバーに対応する大小のソースブロックサイズを使用する場合があります。さらに、さまざまなインスタンスが異なる冗長レベルでFEC保護を提供する場合があります。これは、異なる受信機が異なるパケット損失率を経験し、各レシーバーがニーズに合わせた修理フローを選択できるマルチキャストシナリオで特に役立ちます。
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：2つのFECフレームワークインスタンスを備えたシナリオの例。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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. 1つ以上の修復フローは、ソースフローのグループを保護します。
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「グループ」属性は、ソースと修復フローを関連付けるために使用されます。また、このドキュメントは、「グループ」属性が1つ以上のソースフローと複数の修理フローをグループ化するために使用する方法を指定します。
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]は[RFC5888]が[RFC3388]を廃止して、「MID」属性によって識別された「M」ラインが同じセマンティクスを使用して複数の「A =グループ」ラインに表示されるようにすることに注意してください。この変更と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.5で説明したシナリオの後方適合性の理由について、セクション4.4で指定された「FEC」セマンティクスをサポートするために実装を推奨します。
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内で添加剤になる可能性があります。あるいは、3つの修復フローすべて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
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：2つのFECフレームワークインスタンスを使用した2つのFECフレームワークインスタンスの例のシナリオの例。最初のインスタンスで2つの修復が流れ、2番目のインスタンスの単一の修復フローが同じソースフローS4を保護します。
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 =グループ」行は、ソースフローと修理フローの間の関連性の関係を示すために使用されます。1つの「A =グループ」行に含まれるフローは、FECグループと呼ばれます。FECグループに複数の修復フローが含まれている場合、これらの修復フローは添加剤と見なされる必要があります。添加剤ではない修復フローは、別々のFECグループで示される必要があります。ただし、FECグループで2つの（またはそれ以上の）修復フローが添加剤である場合、これらの修復フローも他の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 =グループ：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
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 =グループ：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
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
[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が多重化され、同じRTPセッションで運ばれるRTPストリームをグループ化するために、「SSRC-Group」と呼ばれるSDPメディアレベルの属性を定義します。グループ化は、同期ソース（SSRC）識別子に基づいています。SSRCマルチプレックス付きRTPストリームは同じ「M」行で定義されているため、「グループ」属性を使用できません。
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.
このセクションでは、FECが「SSRC-Group」属性[RFC5576]を使用して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グループ」属性の「FEC-FR」のセマンティクスは、SSRC識別子がFECグループ化関連を指定するために使用されることを除いて、「グループ」属性に対して定義されたものと同じです。A= SSRCグループ：FEC：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].
同じRTPセッションで運ばれるRTPストリームのSSRC識別子は、[RFC3550]ごとに一意でなければなりません。ただし、SSRC識別子は、異なるRTPセッションの間で一意であることを保証されていません。したがって、「SSRCグループ」属性は、メディアレベル[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.
2つのソースフロー（1つのビデオと1つのオーディオなど）がある次のシナリオと、ソースフローの1つのみを保護する単一の修理フロー（ビデオ）を考えてみましょう。これらのすべてのフローは、同じRTPセッションでSSRCが多重化された個別のRTPストリームであると仮定します。
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：単一の修理フローがソースフローの1つのみを保護する1つの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
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.
実際の使用では、ランダムな32ビット数値であるSSRC値は、この例に示されているものよりもはるかに大きい場合があることに注意してください。また、各ストリームに対して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-group」ラインに含まれる修復フローは、添加剤でなければなりません。添加剤ではない修復フローは、個別の「a = ssrc-group」線で示される必要があります。
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」セマンティクスの使用を非難します。この仕様を実装する2つのエンドポイント間で交渉されたセッションでは、「FEC」セマンティクスではなく「FEC-FR」セマンティクスを使用する必要があります。セクション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 =グループ」線を使用して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 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.
「FEC」セマンティクスでは、ソースまたは修理フローは、単一の「A =グループ：FEC」行でのみ表示できます。したがって、互いに何らかの形で関連するすべてのソースと修復フローは、同じ「a =グループ：FEC」行にリストする必要があります。たとえば、図1にスケッチされているシナリオでは、どの修復フローがどの特定のソースフローを保護するかに関係なく、「A =グループ：FEC S1 S2 R1 R2」を記述する必要があります。同様に、図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.
1つのソースフローと1つの修理フローがある場所などの特定の単純なシナリオでは、これらの制限は懸念事項ではない場合があります。「FEC」セマンティクスが「FEC」セマンティクスが提供できる限り、「FEC-FR」セマンティクスが回答者によって理解されていない場合、「FEC-FR」セマンティクスが「FEC」セマンティクスが提供される限り、「FEC」セマンティクスを提供できます。あいまいさを作成しないでください。詳細については、セクション4.5を参照してください。
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:
ノードが「FEC-FR」グループ化セマンティクスとのセッションを提供されますが、[RFC5888]に従ってライングループ化や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なしで新しいオファーを送信する必要があります。2番目のケースでは、送信者がまだセッションを確立したい場合、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:
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-Group」SDP属性のセマンティクス」レジストリで、次のセマンティクスをIANAで登録します。
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]に貢献した人々に感謝したいと思います。また、セクション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 3550、2003年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：セッション説明プロトコル」、RFC 4566、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 5576、2009年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。、「Forward Error Correction（FEC）Framework」、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] Li、A。、「セッション説明プロトコルのフォワードエラー補正セマンティクス」、RFC 4756、2006年11月。
Author's Address
著者の連絡先
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco 181 Bay Street Toronto、M5J 2T3カナダ
EMail: abegen@cisco.com