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レベル（同期ソース）のグループ化の意味は、リアルタイムトランスポートプロトコル（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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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スキームの一つは、排他的OR（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セッションは、複数のRTPポートの使用を低減するために、同期ソース（SSRC）多重化を介してストリームを搬送するためしかし、いくつかのシナリオでは、それが望ましいかもしれません。このようなシナリオの場合は、適切なグループ化の意味も必要です。
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.
基本的な例のシナリオは、ソース流S1を修復流R1によって保護され、ここで、図1に示されています。また、ソースは、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は、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を流れると仮定する。リペアフローR1のみ下地層を望む受信機のみ下地層を保護するか、または、両方の層を受けるが、FEC保護を好むのに対し、リペアフローR2は、両方の層を受け取る受信機のベース及びエンハンスメント層の組み合わせを保護しますのみによる帯域幅または他の制限にベース層用。
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フレームワークのインスタンスを使用して受信者に柔軟性を提供します。例示的なシナリオは、異なるFECスキームによって生成されたリペアフローを提供することができる図2異なるインスタンスにスケッチされ、受信機は、サポートおよびデコードできること適切な修復の流れ（S）を受信することを選択します。代替的に、異なるインスタンスが（同じ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：同一のソース流S3を保護単一修復流を有する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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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スキームによって保護されています。
3. Multiple source flows are grouped prior to applying FEC protection.
前記複数のソース・フローは、FEC保護を適用する前にグループ化されます。
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.
この文書と[RFC5888]で定義されたSDP「グループ」属性で定義されたFECグループ化セマンティクスは、ソースおよびリペアフローを関連付けるために使用されます。また、このドキュメントでは、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]時代遅れ[RFC3388]はその「中間」属性によって識別される「M」の行は同じセマンティクスを使用して複数の「A =基」行に表示できるようにすることに留意されたいです。この変更及びFECグループ化セマンティクスの本書に記載されている定義と、送信者は、ソースおよびリペアフロー間の特定の関連付けを示すことができ、受信機は、修復の流れ（S）を決定することができるソース流（複数可）を保護。
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フレームワークインスタンス有するシナリオ例及び第二例における単一修復フローは、同じソース・フローを保護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 =グループ」線源とリペアフローの間の対応関係を示すために使用されます。一つの「A =基」行に含まれるフローはFECグループと呼ばれます。 FECグループに含まれる複数のリペアフローがある場合、これらの修復フローは、添加剤であると見なされなければなりません。添加されない修復フローは別FECグループに示されなければなりません。 2つ（またはそれ以上）の修復フローが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フレームワーク機能のサポートを示すためにグループ化セマンティクスとして「FEC-FR」を定義します。
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グループ」と呼ばれる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グループ」属性[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].
A = SSRCグループ：SSRC識別子はFECグループの関連付けを指定するために使用されることを除いて、「SSRCグループ」属性の「FEC-FR」の意味は、「グループ」属性に定義されたものと同じである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.
私たちは二つのソースの流れがある次のシナリオを検討してみましょう（例えば、一つのビデオとオーディオの1）とソース・フロー（例えば、ビデオ）の一つだけを保護し、単一の修理の流れ。これらのすべてのフローがSSRCが同じRTPセッションで多重化される別個の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つの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グループ」行に含まれる修理・フローは、添加していなければなりません。添加されない修復フローは別の「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」セマンティクスの使用を非難します。この仕様を実装する2つのエンドポイント間で交渉セッションは、「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」セマンティクスは、ソースおよびリペアフローとの対応関係を示すためにFECグループを形成するために、[RFC3388]から「A =グループ」線を用います。
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」の意味で、ソースや修理の流れは、単一の「FEC A =グループ」に表示されます。ライン：したがって、何とか互いに関連しているすべてのソースおよびリペアフローは同じ「FEC A =グループ」に記載されなければなりません。例えば、シナリオの中でスケッチ
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は、本発明者らは、書き込み「FEC S1 S2 R1 R2 =基」しなければなりません。かかわらず修復フローが添加されているの：同様に、図3に描かシナリオでは、書き込み「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 Backward-Compatibility Considerations
4.5. SDPオファー/アンサーモデルと下位互換性に関する注意事項
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」はセマンティクスをグループ化するとのセッションを提供しているが、それはセマンティクスをグループ化行のグループ化またはFECをサポートしていない場合は、[RFC5888]に従って、ノードは、次のいずれかを提供するために応答します。
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」の意味を理解していない場合、その要求にグループ化属性または（2）拒否を無視（1）答えのいずれかとの申し出に応答します。最初のケースでは、送信側が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を信頼するSDP [RFC4566]のセキュリティの考慮事項に従ってください。
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]
This document also registers the following semantics with IANA in the "Semantics for the "ssrc-group" SDP Attribute" registry under SDP Parameters:
また、このドキュメントでは、SSRC-グループSDPパラメータの下の「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節に貢献してきたジョナサン・レノックス、おかげ。非常に詳細にこの文書を検討し、テキスト編集を示唆している、ジャン・フランソワ・ミュール、。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]レノックス、J.、オット、J.、およびT. Schierl、RFC 5576、2009年6月 "ソース固有のメディアセッション記述プロトコル（SDP）の属性"。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]キャマリロ、G.およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）グループ化フレームワーク"、RFC 5888、2010年6月。
[FEC-FRAMEWK] Watson, M., "Forward Error Correction (FEC) Framework", Work in Progress, September 2010.
[FEC-FRAMEWK]ワトソン、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]キャマリロ、G.、エリクソン、G.、大声、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]李、A.、 "セッション記述プロトコルでセマンティクスをグループ化する前方誤り訂正"、RFC 4756、2006年11月。
Author's Address
著者のアドレス
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
M5J 2T3カナダONアリBegenのCisco 181ベイストリートトロント、
EMail: abegen@cisco.com
メールアドレス：abegen@cisco.com