[要約] RFC 6364は、転送エラー訂正（FEC）フレームワークのためのセッション記述プロトコル（SDP）要素に関するものです。このRFCの目的は、FECフレームワークをサポートするためのSDP要素を定義することです。
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 6364 Cisco
Category: Standards Track October 2011
ISSN: 2070-1721
Session Description Protocol Elements for the Forward Error Correction (FEC) Framework
セッション説明フォワードエラー補正（FEC）フレームワークのプロトコル要素
Abstract
概要
This document specifies the use of the Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework.
このドキュメントは、セッション説明プロトコル（SDP）の使用を指定して、送信者と受信機の間のフォワードエラー補正（FEC）フレームワークの構成情報を信号するために必要なパラメーターを説明します。このドキュメントは、FECフレームワークの複数のインスタンスを同時に使用するアプリケーションの複数のソースと修理フローをグループ化するためのセマンティクスを示す例も提供します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6364.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6364で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Forward Error Correction (FEC) and FEC Framework ................3
3.1. Forward Error Correction (FEC) .............................3
3.2. FEC Framework ..............................................4
3.3. FEC Framework Configuration Information ....................4
4. SDP Elements ....................................................5
4.1. Transport Protocol Identifiers .............................6
4.2. Media Stream Grouping ......................................6
4.3. Source IP Addresses ........................................6
4.4. Source Flows ...............................................6
4.5. Repair Flows ...............................................7
4.6. Repair Window ..............................................8
4.7. Bandwidth Specification ....................................9
5. Scenarios and Examples .........................................10
5.1. Declarative Considerations ................................10
5.2. Offer/Answer Model Considerations .........................10
6. SDP Examples ...................................................11
6.1. One Source Flow, One Repair Flow, and One FEC Scheme ......11
6.2. Two Source Flows, One Repair Flow, and One FEC Scheme .....12
6.3. Two Source Flows, Two Repair Flows, and Two FEC Schemes ...13
6.4. One Source Flow, Two Repair Flows, and Two FEC Schemes ....14
7. Security Considerations ........................................15
8. IANA Considerations ............................................15
8.1. Registration of Transport Protocols .......................15
8.2. Registration of SDP Attributes ............................16
9. Acknowledgments ................................................16
10. References ....................................................17
10.1. Normative References .....................................17
10.2. Informative References ...................................17
The Forward Error Correction (FEC) Framework, described in [RFC6363], outlines a general framework for using FEC-based error recovery in packet flows carrying media content. While a continuous signaling between the sender(s) and receiver(s) is not required for a Content Delivery Protocol (CDP) that uses the FEC Framework, a set of parameters pertaining to the FEC Framework has to be initially communicated between the sender(s) and receiver(s). A signaling protocol (such as the one described in [FECFRAME-CFG-SIGNAL]) is required to enable such communication, and the parameters need to be appropriately encoded so that they can be carried by the signaling protocol.
[RFC6363]に記載されているフォワードエラー補正（FEC）フレームワークは、メディアコンテンツを運ぶパケットフローでFECベースのエラー回復を使用するための一般的なフレームワークを概説しています。FECフレームワークを使用するコンテンツ配信プロトコル（CDP）には、送信者と受信機の間の連続シグナル伝達は必要ありませんが、FECフレームワークに関連するパラメーターのセットを最初に送信者間で通知する必要があります（s）およびレシーバー。このような通信を有効にするには、[Fecframe-CFG-Signal]で説明されているシグナリングプロトコル（[Fecframe-CFG-Signal]で説明されているなど）が必要であり、シグナリングプロトコルによって実行できるようにパラメーターを適切にエンコードする必要があります。
One format to encode the parameters is the Session Description Protocol (SDP) [RFC4566]. SDP provides a simple text-based format for announcements and invitations to describe multimedia sessions. These SDP announcements and invitations include sufficient information for the sender(s) and receiver(s) to participate in the multimedia sessions. SDP also provides a framework for capability negotiation, which can be used to negotiate all, or a subset, of the parameters pertaining to the individual sessions.
パラメーターをエンコードする1つの形式は、セッション説明プロトコル（SDP）[RFC4566]です。SDPは、マルチメディアセッションを説明するためのアナウンスと招待状のシンプルなテキストベースの形式を提供します。これらのSDPの発表と招待状には、送信者と受信機がマルチメディアセッションに参加するのに十分な情報が含まれています。SDPは、個々のセッションに関連するパラメーターのすべてまたはサブセットを交渉するために使用できる機能交渉のフレームワークも提供します。
The purpose of this document is to introduce the SDP elements that are used by the CDPs using the FEC Framework that choose SDP [RFC4566] for their multimedia sessions.
このドキュメントの目的は、マルチメディアセッションにSDP [RFC4566]を選択するFECフレームワークを使用してCDPで使用されるSDP要素を導入することです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、[RFC2119]に記載されているように解釈されます。
This section gives a brief overview of FEC and the FEC Framework.
このセクションでは、FECとFECフレームワークの概要を説明します。
Any application that needs reliable transmission over an unreliable packet network has to cope with packet losses. FEC is an effective approach that provides reliable transmission, particularly in multicast and broadcast applications where the feedback from the receiver(s) is either not available or quite limited.
信頼性の低いパケットネットワークを介して信頼できる送信を必要とするアプリケーションは、パケット損失に対処する必要があります。FECは、特に受信者からのフィードバックが利用できないか、まったく限られていないマルチキャストおよびブロードキャストアプリケーションで、信頼できる送信を提供する効果的なアプローチです。
In a nutshell, FEC groups source packets into blocks and applies protection to generate a desired number of repair packets. These repair packets can be sent on demand or independently of any receiver feedback. The choice depends on the FEC scheme or the Content Delivery Protocol used by the application, the packet loss characteristics of the underlying network, the transport scheme (e.g., unicast, multicast, and broadcast), and the application itself. At the receiver side, lost packets can be recovered by erasure decoding provided that a sufficient number of source and repair packets have been received.
一言で言えば、FECグループはパケットをブロックにソースにし、保護を適用して、望ましい数の修理パケットを生成します。これらの修理パケットは、オンデマンドまたはレシーバーフィードバックとは独立して送信できます。選択は、アプリケーションで使用されるFECスキームまたはコンテンツ配信プロトコル、基礎となるネットワークのパケット損失特性、輸送スキーム（ユニキャスト、マルチキャスト、ブロードキャストなど）、およびアプリケーション自体に依存します。レシーバー側では、十分な数のソースと修理パケットが受信されていれば、消去デコードによって失われたパケットを回収できます。
The FEC Framework [RFC6363] outlines a general framework for using FEC codes in multimedia applications that stream audio, video, or other types of multimedia content. It defines the common components and aspects of Content Delivery Protocols (CDPs). The FEC Framework also defines the requirements for the FEC schemes that need to be used within a CDP. However, the details of the FEC schemes are not specified within the FEC Framework. For example, the FEC Framework defines what configuration information has to be known at the sender and receiver(s) at a minimum, but the FEC Framework neither specifies how the FEC repair packets are generated and used to recover missing source packets, nor dictates how the configuration information is communicated between the sender and receiver(s). These are rather specified by the individual FEC schemes or CDPs.
FECフレームワーク[RFC6363]は、オーディオ、ビデオ、またはその他のタイプのマルチメディアコンテンツをストリーミングするマルチメディアアプリケーションでFECコードを使用するための一般的なフレームワークの概要を示しています。コンテンツ配信プロトコル（CDP）の一般的なコンポーネントと側面を定義します。FECフレームワークは、CDP内で使用する必要があるFECスキームの要件も定義しています。ただし、FECスキームの詳細はFECフレームワーク内で指定されていません。たとえば、FECフレームワークは、送信者と受信機で最小限に既知の構成情報を定義しますが、FECフレームワークは、FEC修復パケットの生成方法を指定し、欠落したソースパケットを回復するために使用されず、どのように決定するかも指定しません。構成情報は、送信者と受信機の間で通信されます。これらは、個々のFECスキームまたはCDPによってかなり指定されています。
The FEC Framework [RFC6363] defines a minimum set of information that has to be communicated between the sender and receiver(s) for proper operation of a FEC scheme. This information is called the "FEC Framework Configuration Information". This information includes unique identifiers for the source and repair flows that carry the source and repair packets, respectively. It also specifies how the sender applies protection to the source flow(s) and how the repair flow(s) can be used to recover lost data.
FECフレームワーク[RFC6363]は、FECスキームの適切な操作のために送信者と受信機の間で通信する必要がある最小の情報セットを定義します。この情報は、「FECフレームワーク構成情報」と呼ばれます。この情報には、ソースと修理パケットをそれぞれ運ぶソースおよび修理フローの一意の識別子が含まれています。また、送信者がソースフローに保護を適用する方法と、修復フローを使用して失われたデータを回復する方法も指定します。
Multiple instances of the FEC Framework can simultaneously exist at the sender and the receiver(s) for different source flows, for the same source flow, or for various combinations of the source flows. Each instance of the FEC Framework provides the following FEC Framework Configuration Information:
FECフレームワークの複数のインスタンスは、異なるソースフロー、同じソースフロー、またはソースフローのさまざまな組み合わせに対して、送信者と受信機に同時に存在します。FECフレームワークの各インスタンスは、次のFECフレームワーク構成情報を提供します。
1. Identification of the repair flows.
1. 修理フローの識別。
2. For each source flow protected by the repair flow(s):
2. 修復フローによって保護されている各ソースフローについて：
A. Definition of the source flow.
A.ソースフローの定義。
B. An integer identifier for this flow definition (i.e., tuple). This identifier MUST be unique among all source flows that are protected by the same FEC repair flow. Integer identifiers can be allocated starting from zero and increasing by one for each flow. However, any random (but still unique) allocation is also possible. A source flow identifier need not be carried in source packets, since source packets are directly associated with a flow by virtue of their packet headers.
B.このフロー定義の整数識別子（つまり、タプル）。この識別子は、同じFEC修復フローによって保護されているすべてのソースフローの中で一意でなければなりません。整数識別子は、ゼロから開始し、各フローに対して1つ増加することを割り当てることができます。ただし、ランダムな（ただしユニークな）割り当ても可能です。ソースパケットはパケットヘッダーのおかげでフローに直接関連付けられるため、ソースフロー識別子をソースパケットに携帯する必要はありません。
3. The FEC Encoding ID, identifying the FEC scheme.
3. FECエンコードID、FECスキームを識別します。
4. The length of the Explicit Source FEC Payload ID (in octets).
4. 明示的なソースFECペイロードID（オクテット）の長さ。
5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, each consisting of a name and a value where the valid element names and value ranges are defined by the FEC scheme.
5. ゼロ以上のFEC-Scheme固有の情報（FSSI）要素。それぞれが、有効な要素名と値の範囲がFECスキームによって定義される名前と値で構成される要素です。
FSSI includes the information that is specific to the FEC scheme used by the CDP. FSSI is used to communicate the information that cannot be adequately represented otherwise and is essential for proper FEC encoding and decoding operations. The motivation behind separating the FSSI required only by the sender (which is carried in a Sender-Side FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of the FSSI is to provide the receiver or the third-party entities a means of controlling the FEC operations at the sender. Any FSSI other than the one solely required by the sender MUST be communicated via the FSSI container.
FSSIには、CDPが使用するFECスキームに固有の情報が含まれています。FSSIは、それ以外の場合は適切に表現できない情報を通信するために使用され、適切なFECエンコードおよびデコード操作に不可欠です。FSSIの残りの部分からの送信者のみが必要とするFSSIを分離する動機（送信者側FEC-Scheme固有の情報（SS-FSSI）コンテナで運ばれる）は、受信者またはサードパーティのエンティティを提供することです。送信者でのFEC操作を制御する手段。送信者のみが必要とするfssi以外のfssiは、FSSIコンテナを介して通信する必要があります。
The variable-length SS-FSSI and FSSI containers transmit the information in textual representation and contain zero or more distinct elements, whose descriptions are provided by the fully specified FEC schemes.
可変長さのSS-FSSIおよびFSSIコンテナは、情報をテキスト表現で送信し、ゼロ以上の異なる要素を含み、その説明は完全に指定されたFECスキームによって提供されます。
This section defines the SDP elements that MUST be used to describe the FEC Framework Configuration Information in multimedia sessions by the CDPs that choose SDP [RFC4566] for their multimedia sessions. Example SDP descriptions can be found in Section 6.
このセクションでは、マルチメディアセッションにSDP [RFC4566]を選択したCDPによるマルチメディアセッションのFECフレームワーク構成情報を記述するために使用する必要があるSDP要素を定義します。SDPの例の説明は、セクション6に記載されています。
This specification defines a new transport protocol identifier for the FEC schemes that take a UDP-formatted input stream and append an Explicit Source FEC Payload ID, as described in Section 5.3 of [RFC6363], to generate a source flow. This new protocol identifier is called 'FEC/UDP'. To use input streams that are formatted according to another <proto> (as listed in the table for the 'proto' field in the "Session Description Protocol (SDP) Parameters" registry), the corresponding 'FEC/<proto>' transport protocol identifier MUST be registered with IANA by following the instructions specified in [RFC4566].
この仕様では、UDP形式の入力ストリームを取得し、[RFC6363]のセクション5.3で説明されているように、Sourceフローを生成するために、明示的なソースFECペイロードIDを追加するFECスキームの新しい輸送プロトコル識別子を定義します。この新しいプロトコル識別子は「FEC/UDP」と呼ばれます。別の<proto>に従ってフォーマットされている入力ストリームを使用するには（「セッション説明プロトコル（SDP）パラメーター」レジストリの「プロト」フィールドのテーブルにリストされています）、対応する「FEC/<Proto>」トランスポートプロトコル[RFC4566]で指定された指示に従って、識別子をIANAに登録する必要があります。
Note that if a FEC scheme does not use the Explicit Source FEC Payload ID as described in Section 4.1 of [RFC6363], then the original transport protocol identifier MUST be used to support backward compatibility with the receivers that do not support FEC at all.
FECスキームが[RFC6363]のセクション4.1で説明されているように明示的なソースPayload IDを使用しない場合、元の輸送プロトコル識別子を使用して、FECをまったくサポートしない受信機との後方互換性をサポートする必要があることに注意してください。
This specification also defines another transport protocol identifier, 'UDP/FEC', to indicate the FEC repair packet format defined in Section 5.4 of [RFC6363]. For detailed registration information, refer to Section 8.1.
この仕様では、別の輸送プロトコル識別子「UDP/FEC」も定義し、[RFC6363]のセクション5.4で定義されているFEC修復パケット形式を示します。詳細な登録情報については、セクション8.1を参照してください。
In the FEC Framework, the 'group' attribute and the FEC grouping semantics defined in [RFC5888] and [RFC5956], respectively, are used to associate source and repair flows.
FECフレームワークでは、[RFC5888]および[RFC5956]でそれぞれ定義されている「グループ」属性とFECグループ化セマンティクスを、それぞれソースと修復の流れと修復に使用します。
The 'source-filter' attribute of SDP ("a=source-filter") as defined in [RFC4570] is used to express the source addresses or fully qualified domain names in the FEC Framework.
[RFC4570]で定義されているSDP（ "a = source-filter"）の「ソースフィルター」属性は、FECフレームワークでソースアドレスまたは完全に適格なドメイン名を表現するために使用されます。
The FEC Framework allows that multiple source flows MAY be grouped and protected together by single or multiple FEC Framework instances. For this reason, as described in Section 3.3, individual source flows MUST be identified with unique identifiers. For this purpose, we introduce the attribute 'fec-source-flow'.
FECフレームワークにより、複数のソースフローが単一または複数のFECフレームワークインスタンスによってグループ化および保護される可能性があります。このため、セクション3.3で説明したように、個々のソースフローは一意の識別子で識別する必要があります。この目的のために、属性「FEC-Source-Flow」を紹介します。
The syntax for the new attribute in ABNF [RFC5234] is as follows:
ABNF [RFC5234]の新しい属性の構文は次のとおりです。
fec-source-flow-line = "a=fec-source-flow:" SP source-id
[";" SP tag-length] CRLF
source-id = "id=" src-id
src-id = 1*DIGIT ; Represented as 32-bit non-negative
; integers, and leading zeros are ignored
tag-length = "tag-len=" tlen
tlen = %x31-39 *DIGIT
The REQUIRED parameter 'id' is used to identify the source flow. Parameter 'id' MUST be an integer.
必要なパラメーター「ID」は、ソースフローを識別するために使用されます。パラメーター「ID」は整数でなければなりません。
The 'tag-len' parameter is used to specify the length of the Explicit Source FEC Payload ID field (in octets). In the case that an Explicit Source FEC Payload ID is used, the 'tag-len' parameter MUST exist and indicate its length. Otherwise, the 'tag-len' parameter MUST NOT exist.
「Tag-Len」パラメーターは、明示的なソースFECペイロードIDフィールド（オクテット）の長さを指定するために使用されます。明示的なソースFECペイロードIDが使用されている場合、「Tag-Len」パラメーターが存在し、その長さを示す必要があります。それ以外の場合、「タグレン」パラメーターが存在してはなりません。
A repair flow MUST contain only repair packets formatted as described in [RFC6363] for a single FEC Framework instance; i.e., packets belonging to source flows or other repair flows from a different FEC Framework instance cannot be sent within this flow. We introduce the attribute 'fec-repair-flow' to describe the repair flows.
修理フローには、単一のFECフレームワークインスタンスの[RFC6363]に記載されているようにフォーマットされた修理パケットのみを含める必要があります。つまり、ソースフローに属するパケットまたは異なるFECフレームワークインスタンスからのその他の修復フローをこのフロー内で送信することはできません。修復フローを説明するために、属性「FEC-Repair-Flow」を紹介します。
The syntax for the new attribute in ABNF is as follows (CHAR and CTL are defined in [RFC5234]):
ABNFの新しい属性の構文は次のとおりです（CHARおよびCTLは[RFC5234]で定義されています）：
fec-repair-flow-line = "a=fec-repair-flow:" SP fec-encoding-id
[";" SP flow-preference]
[";" SP sender-side-scheme-specific]
[";" SP scheme-specific] CRLF
fec-encoding-id = "encoding-id=" enc-id
enc-id = 1*DIGIT ; FEC Encoding ID
flow-preference = "preference-lvl=" preference-level-of-the-flow
preference-level-of-the-flow = 1*DIGIT
sender-side-scheme-specific = "ss-fssi=" sender-info
sender-info = element *( "," element )
element = name ":" value
name = token
token = 1*<any CHAR except CTLs or separators>
value = *<any CHAR except CTLs or separators>
separator = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / DQUOTE
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HTAB
scheme-specific = "fssi=" scheme-info
scheme-info = element *( "," element )
The REQUIRED parameter 'encoding-id' is used to identify the FEC scheme used to generate this repair flow. These identifiers (in the range of [0 - 255]) are registered by the FEC schemes that use the FEC Framework and are maintained by IANA.
必要なパラメーター「Encoding-ID」は、この修復フローを生成するために使用されるFECスキームを識別するために使用されます。これらの識別子（[0-255]の範囲）は、FECフレームワークを使用し、IANAによって維持されるFECスキームによって登録されます。
The OPTIONAL parameter 'preference-lvl' is used to indicate the preferred order for using the repair flows. The exact usage of the parameter 'preference-lvl' and the pertaining rules MAY be defined by the FEC scheme or the CDP. If the parameter 'preference-lvl' does not exist, it means that the receiver(s) MAY receive and use the repair flows in any order. However, if a preference level is assigned to the repair flow(s), the receivers are encouraged to follow the specified order in receiving and using the repair flow(s).
オプションのパラメーター「Preference-LVL」は、修理フローを使用するための優先順序を示すために使用されます。パラメーター「Preference-LVL」と関連するルールの正確な使用法は、FECスキームまたはCDPによって定義される場合があります。パラメーター「Preference-LVL」が存在しない場合、受信者が任意の順序で修理フローを受信して使用できることを意味します。ただし、修理フローに優先レベルが割り当てられている場合、受信機は、修理フローの受信および使用において指定された順序に従うことをお勧めします。
The OPTIONAL parameters 'ss-fssi' and 'fssi' are containers to convey the FEC-Scheme-Specific Information (FSSI) that includes the information that is specific to the FEC scheme used by the CDP and is necessary for proper FEC encoding and decoding operations. The FSSI required only by the sender (the Sender-Side FSSI) MUST be communicated in the container specified by the parameter 'ss-fssi'. Any other FSSI MUST be communicated in the container specified by the parameter 'fssi'. In both containers, FSSI is transmitted in the form of textual representation and MAY contain multiple distinct elements. If the FEC scheme does not require any specific information, the 'ss-fssi' and 'fssi' parameters MUST NOT exist.
オプションのパラメーターのSS-FSSI 'および「FSSI」は、CDPで使用され、適切なFECエンコードとデコードに必要なFECスキームに固有の情報を含むFECスキーム固有の情報（FSSI）を伝えるためのコンテナです。オペレーション。送信者（送信者側FSSI）がのみ必要とするFSSIは、パラメーターの「SS-FSSI」で指定されたコンテナで通信する必要があります。他のFSSIは、パラメーター「FSSI」で指定されたコンテナで通信する必要があります。両方の容器で、FSSIはテキスト表現の形で送信され、複数の異なる要素が含まれる場合があります。FECスキームが特定の情報を必要としない場合、「SS-FSSI」および「FSSI」パラメーターが存在してはなりません。
The repair window is the time that spans a FEC block, which consists of the source block and the corresponding repair packets.
修理ウィンドウは、ソースブロックと対応する修理パケットで構成されるFECブロックにまたがる時間です。
At the sender side, the FEC encoder processes a block of source packets and generates a number of repair packets. Then, both the source and repair packets are transmitted within a certain duration
送信者側では、FECエンコーダーはソースパケットのブロックを処理し、多くの修理パケットを生成します。次に、ソースパケットと修理パケットの両方が特定の期間内に送信されます
not larger than the value of the repair window. The value of the repair window impacts the maximum number of source packets that can be included in a FEC block.
修理ウィンドウの値よりも大きくありません。修理ウィンドウの値は、FECブロックに含めることができるソースパケットの最大数に影響を与えます。
At the receiver side, the FEC decoder should wait at least for the duration of the repair window after getting the first packet in a FEC block, to allow all the repair packets to arrive. (The waiting time can be adjusted if there are missing packets at the beginning of the FEC block.) The FEC decoder can start decoding the already received packets sooner; however, it SHOULD NOT register a FEC decoding failure until it waits at least for the duration of the repair window.
受信側では、FECブロックに最初のパケットを取得した後、少なくともすべての修理パケットが到着できるように、少なくとも修理ウィンドウの期間を待機する必要があります。（FECブロックの先頭にパケットが欠落している場合、待機時間を調整できます。）FECデコーダーは、すでに受信したパケットをより早くデコードし始めることができます。ただし、少なくとも修理ウィンドウの期間が待機するまで、FECデコード障害を登録しないでください。
This document specifies a new attribute to describe the size of the repair window in milliseconds and microseconds.
このドキュメントは、ミリ秒およびマイクロ秒単位で修理ウィンドウのサイズを記述するための新しい属性を指定します。
The syntax for the attribute in ABNF is as follows:
ABNFの属性の構文は次のとおりです。
repair-window-line = "a=repair-window:" window-size unit CRLF
window-size = %x31-39 *DIGIT ; Represented as
; 32-bit non-negative integers
unit = "ms" / "us"
<unit> is the unit of time specified for the repair window size. Two units are defined here: 'ms', which stands for milliseconds; and 'us', which stands for microseconds.
<ユニット>は、修理ウィンドウサイズに指定された時間単位です。ここでは、2つのユニットが定義されています。「MS」は、ミリ秒を表します。マイクロ秒を表す「私たち」。
The 'a=repair-window' attribute is a media-level attribute, since each repair flow MAY have a different repair window size.
「a = Repair-Window」属性は、各修復フローの修理ウィンドウサイズが異なる場合があるため、メディアレベルの属性です。
Specifying the repair window size in an absolute time value does not necessarily correspond to an integer number of packets or exactly match with the clock rate used in RTP (in the case of RTP transport), causing mismatches among subsequent repair windows. However, in practice, this mismatch does not break anything in the FEC decoding process.
絶対時間値で修理ウィンドウのサイズを指定すると、必ずしも整数数のパケットに対応しているわけではなく、RTPで使用されるクロックレート（RTPトランスポートの場合）と正確に一致するわけではなく、その後の修理ウィンドウ間で不一致を引き起こします。ただし、実際には、この不一致はFECデコードプロセスで何も壊れません。
The bandwidth specification as defined in [RFC4566] denotes the proposed bandwidth to be used by the session or media. The specification of bandwidth is OPTIONAL.
[RFC4566]で定義されている帯域幅の仕様は、セッションまたはメディアで使用される提案された帯域幅を示します。帯域幅の仕様はオプションです。
In the context of the FEC Framework, the bandwidth specification can be used to express the bandwidth of the repair flows or the bandwidth of the session. If included in the SDP, it SHALL adhere to the following rules.
FECフレームワークのコンテキストでは、帯域幅の仕様を使用して、修理フローの帯域幅またはセッションの帯域幅を表現できます。SDPに含まれる場合、次のルールを遵守します。
The session-level bandwidth for a FEC Framework instance or the media-level bandwidth for the individual repair flows MAY be specified. In this case, it is RECOMMENDED that the Transport Independent Application Specific (TIAS) bandwidth modifier [RFC3890] and the 'a=maxprate' attribute be used, unless the Application-Specific (AS) bandwidth modifier [RFC4566] is used. The use of the AS bandwidth modifier is NOT RECOMMENDED, since TIAS allows the calculation of the bitrate according to the IP version and transport protocol whereas AS does not. Thus, in TIAS-based bitrate calculations, the packet size SHALL include all headers and payload, excluding the IP and UDP headers. In AS-based bitrate calculations, the packet size SHALL include all headers and payload, plus the IP and UDP headers.
FECフレームワークインスタンスのセッションレベルの帯域幅または個々の修復フローのメディアレベルの帯域幅を指定することができます。この場合、アプリケーション固有の（AS）帯域幅修飾子[RFC4566]を使用しない限り、トランスポート独立したアプリケーション固有の帯域幅修飾子[RFC3890]および「A = MaxPrate」属性を使用することをお勧めします。TIASはIPバージョンと輸送プロトコルに従ってビットレートの計算を許可するため、帯域幅修飾子の使用は推奨されません。したがって、TIASベースのビットレート計算では、パケットサイズには、IPおよびUDPヘッダーを除くすべてのヘッダーとペイロードを含めるものとします。ASベースのBitRate計算では、パケットサイズにはすべてのヘッダーとペイロード、およびIPおよびUDPヘッダーが含まれます。
For the ABNF syntax information of the TIAS and AS, refer to [RFC3890] and [RFC4566], respectively.
TIASのABNF構文情報については、それぞれ[RFC3890]と[RFC4566]を参照してください。
This section discusses the considerations for Session Announcement and Offer/Answer Models.
このセクションでは、セッションの発表と提供/回答モデルの考慮事項について説明します。
In multicast-based applications, the FEC Framework Configuration Information pertaining to all FEC protection options available at the sender MAY be advertised to the receivers as a part of a session announcement. This way, the sender can let the receivers know all available options for FEC protection. Based on their needs, the receivers can choose protection provided by one or more FEC Framework instances and subscribe to the respective multicast session(s) to receive the repair flow(s). Unless explicitly required by the CDP, the receivers SHOULD NOT send an answer back to the sender specifying their choices, since this can easily overwhelm the sender, particularly in large-scale multicast applications.
マルチキャストベースのアプリケーションでは、セッション発表の一環として、送信者で利用可能なすべてのFEC保護オプションに関するFECフレームワーク構成情報がレシーバーに宣伝される場合があります。これにより、送信者は、FEC保護のために利用可能なすべてのオプションを受信者に知らせることができます。ニーズに基づいて、受信機は1つ以上のFECフレームワークインスタンスによって提供される保護を選択し、それぞれのマルチキャストセッションを購読して修理フローを受け取ることができます。CDPが明示的に必要としない限り、受信機は選択肢を指定する送信者に回答を送り返すべきではありません。これは、特に大規模なマルチキャストアプリケーションで、送信者を簡単に圧倒する可能性があるためです。
In unicast-based applications, a sender and receiver MAY adopt the Offer/Answer Model [RFC3264] to set the FEC Framework Configuration Information. In this case, the sender offers the options available to this particular receiver, and the receiver answers back to the sender with its choice(s).
ユニキャストベースのアプリケーションでは、送信者とレシーバーがオファー/回答モデル[RFC3264]を採用してFECフレームワークの構成情報を設定することができます。この場合、送信者はこの特定のレシーバーが利用できるオプションを提供し、受信者はその選択をして送信者に返信します。
Receivers supporting the SDP Capability Negotiation Framework [RFC5939] MAY also use this framework to negotiate all, or a subset, of the FEC Framework parameters.
SDP機能交渉フレームワーク[RFC5939]をサポートするレシーバーは、このフレームワークを使用して、FECフレームワークパラメーターのすべてまたはサブセットをネゴシエートすることもできます。
The backward compatibility in the Offer/Answer Model is handled as specified in [RFC5956].
オファー/回答モデルの後方互換性は、[RFC5956]で指定されているように処理されます。
This section provides SDP examples that can be used by the FEC Framework.
このセクションでは、FECフレームワークで使用できるSDPの例を示します。
[RFC5888] defines the media stream identification attribute ('mid') as a token in ABNF. In contrast, the identifiers for the source flows are integers and can be allocated starting from zero and increasing by one for each flow. To avoid any ambiguity, using the same values for identifying the media streams and source flows is NOT RECOMMENDED, even when 'mid' values are integers.
[RFC5888]は、ABNFのトークンとしてメディアストリーム識別属性（ 'MID'）を定義します。対照的に、ソースフローの識別子は整数であり、ゼロから開始し、各フローに対して1つ増加することを割り当てることができます。あいまいさを避けるために、「中間」の値が整数であっても、メディアストリームとソースフローを識別するために同じ値を使用することは推奨されません。
In the examples below, random FEC Encoding IDs will be used for illustrative purposes. Artificial content for the SS-FSSI and FSSI will also be provided.
以下の例では、ランダムFECエンコードIDが説明のために使用されます。SS-FSSIおよびFSSIの人工含有量も提供されます。
SOURCE FLOWS | INSTANCE #1
S1: Source Flow |--------| R1: Repair Flow
|
Figure 1: Scenario #1
図1：シナリオ＃1
In this example, we have one source video flow (mid:S1) and one FEC repair flow (mid:R1). We form one FEC group with the "a=group:FEC-FR S1 R1" line. The source and repair flows are sent to the same port on different multicast groups. The repair window is set to 150 ms.
この例では、1つのソースビデオフロー（MID：S1）と1つのFEC修復フロー（MID：R1）があります。「A =グループ：FEC-FR S1 R1」ラインで1つのFECグループを形成します。ソースと修理フローは、異なるマルチキャストグループの同じポートに送信されます。修理ウィンドウは150ミリ秒に設定されています。
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples
t=0 0
a=group:FEC-FR S1 R1
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.2/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150ms
a=mid:R1
SOURCE FLOWS
S2: Source Flow | | INSTANCE #1
|---------| R2: Repair Flow
S3: Source Flow |
Figure 2: Scenario #2
図2：シナリオ＃2
In this example, we have two source video flows (mid:S2 and mid:S3) and one FEC repair flow (mid:R2) protecting both source flows. We form one FEC group with the "a=group:FEC-FR S2 S3 R2" line. The source and repair flows are sent to the same port on different multicast groups. The repair window is set to 150500 us.
この例では、2つのソースビデオフロー（MID：S2とMID：S3）と、両方のソースフローを保護するFEC修復フロー（MID：R2）が1つあります。「A =グループ：FEC-FR S2 S3 R2」ラインで1つのFECグループを形成します。ソースと修理フローは、異なるマルチキャストグループの同じポートに送信されます。修理ウィンドウは150500米国に設定されています。
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples
t=0 0
a=group:FEC-FR S2 S3 R2
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S2
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1
a=mid:S3
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150500us
a=mid:R2
SOURCE FLOWS | INSTANCE #1
S4: Source Flow |--------| R3: Repair Flow
S5: Source Flow |--------| INSTANCE #2
| R4: Repair Flow
Figure 3: Scenario #3
図3：シナリオ＃3
In this example, we have two source video flows (mid:S4 and mid:S5) and two FEC repair flows (mid:R3 and mid:R4). The source flows mid:S4 and mid:S5 are protected by the repair flows mid:R3 and mid:R4, respectively. We form two FEC groups with the "a=group:FEC-FR S4 R3" and "a=group:FEC-FR S5 R4" lines. The source and repair flows are sent to the same port on different multicast groups. The repair window is set to 200 ms and 400 ms for the first and second FEC group, respectively.
この例では、2つのソースビデオフロー（MID：S4およびMID：S5）と2つのFEC修復フロー（MID：R3とMID：R4）があります。ソースフローミッド：S4およびMID：S5は、それぞれ修復フローによって保護されています：R3とMID：R4。「A =グループ：FEC-FR S4 R3」と「A =グループ：FEC-FR S5 R4」ラインで2つのFECグループを形成します。ソースと修理フローは、異なるマルチキャストグループの同じポートに送信されます。修理ウィンドウは、それぞれ1番目と2番目のFECグループで200ミリ秒と400ミリ秒に設定されています。
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples
t=0 0
a=group:FEC-FR S4 R3
a=group:FEC-FR S5 R4
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S4
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1
a=mid:S5
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:200ms
a=mid:R3
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.4/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:14,k:10
a=repair-window:400ms
a=mid:R4
SOURCE FLOWS | INSTANCE #1
S6: Source Flow |--------| R5: Repair Flow
|
|--------| INSTANCE #2
| R6: Repair Flow
Figure 4: Scenario #4
図4：シナリオ＃4
In this example, we have one source video flow (mid:S6) and two FEC repair flows (mid:R5 and mid:R6) with different preference levels. The source flow mid:S6 is protected by both of the repair flows. We form two FEC groups with the "a=group:FEC-FR S6 R5" and "a=group:FEC-FR S6 R6" lines. The source and repair flows are sent to the same port on different multicast groups. The repair window is set to 200 ms for both FEC groups.
この例では、異なる優先レベルの1つのソースビデオフロー（MID：S6）と2つのFEC修復フロー（MID：R5およびMID：R6）があります。ソースフローミッド：S6は、両方の修復フローによって保護されています。「A =グループ：FEC-FR S6 R5」と「A =グループ：FEC-FR S6 R6」ラインで2つのFECグループを形成します。ソースと修理フローは、異なるマルチキャストグループの同じポートに送信されます。修理ウィンドウは、両方のFECグループで200ミリ秒に設定されています。
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples
t=0 0
a=group:FEC-FR S6 R5
a=group:FEC-FR S6 R6
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S6
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; preference-lvl=0; ss-fssi=n:7,k:5
a=repair-window:200ms
a=mid:R5
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.4/127
a=fec-repair-flow: encoding-id=1; preference-lvl=1; ss-fssi=t:3
a=repair-window:200ms
a=mid:R6
There is a weak threat if the SDP is modified in a way that it shows an incorrect association and/or grouping of the source and repair flows. Such attacks can result in failure of FEC protection and/or mishandling of other media streams. It is RECOMMENDED that the receiver perform an integrity check on SDP to only trust SDP from trusted sources. The receiver MUST also follow the security considerations of SDP [RFC4566]. For other general security considerations related to SDP, refer to [RFC4566]. For the security considerations related to the use of source address filters in SDP, refer to [RFC4570].
SDPが誤った関連性および/またはソースおよび修復フローのグループ化を示すように変更されている場合、弱い脅威があります。このような攻撃は、FEC保護の失敗や他のメディアストリームの誤った操作をもたらす可能性があります。受信者は、信頼できるソースからSDPのみを信頼するために、SDPの整合性チェックを実行することをお勧めします。受信者は、SDP [RFC4566]のセキュリティ上の考慮事項にも従う必要があります。SDPに関連する他の一般的なセキュリティ上の考慮事項については、[RFC4566]を参照してください。SDPでのソースアドレスフィルターの使用に関連するセキュリティ上の考慮事項については、[RFC4570]を参照してください。
The security considerations for the FEC Framework also apply. Refer to [RFC6363] for details.
FECフレームワークのセキュリティ上の考慮事項も適用されます。詳細については、[RFC6363]を参照してください。
This specification updates the "Session Description Protocol (SDP) Parameters" registry as defined in Section 8.2.2 of [RFC4566]. Specifically, it adds the following values to the table for the 'proto' field.
この仕様は、[RFC4566]のセクション8.2.2で定義されている「セッション説明プロトコル（SDP）パラメーター」レジストリを更新します。具体的には、「プロト」フィールドのテーブルに次の値を追加します。
Type SDP Name Reference
------ ---------- -----------
proto FEC/UDP [RFC6364]
proto UDP/FEC [RFC6364]
This document registers new attribute names in SDP.
このドキュメントは、SDPで新しい属性名を登録します。
SDP Attribute ("att-field"): Attribute name: fec-source-flow Long form: Pointer to FEC Source Flow Type of name: att-field Type of attribute: Media level Subject to charset: No Purpose: Provide parameters for a FEC source flow Reference: [RFC6364] Values: See [RFC6364]
SDP属性（ "att-field"）：属性名：fec-source-flow long form：fecソースフローへのポインタタイプの名前：att-field属性属性のタイプ：charset：なし目的：FECソースフローリファレンス：[RFC6364]値：[RFC6364]を参照
SDP Attribute ("att-field"): Attribute name: fec-repair-flow Long form: Pointer to FEC Repair Flow Type of name: att-field Type of attribute: Media level Subject to charset: No Purpose: Provide parameters for a FEC repair flow Reference: [RFC6364] Values: See [RFC6364]
SDP属性（ "att-field"）：属性名：fec-repair-flow long form：fec修復フローのポインタタイプの名前：att-field属性のタイプ：charset：charset：no gone for for a for a forFEC修復フローリファレンス：[RFC6364]値：[RFC6364]を参照
SDP Attribute ("att-field"): Attribute name: repair-window Long form: Pointer to FEC Repair Window Type of name: att-field Type of attribute: Media level Subject to charset: No Purpose: Indicate the size of the repair window Reference: [RFC6364] Values: See [RFC6364]
SDP属性（ "att-field"）：属性名：修理ウィンドウロングフォーム：fec修理ウィンドウへのポインター名前のタイプタイプ：att-field属性タイプ：charset：charset：no gons：no gins of the Repairのサイズを示すウィンドウリファレンス：[RFC6364]値：[RFC6364]を参照
The author would like to thank the FEC Framework Design Team for their inputs, suggestions, and contributions.
著者は、FECフレームワーク設計チームの入力、提案、貢献について感謝したいと思います。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「フォワードエラー補正（FEC）フレームワーク」、RFC 6363、2011年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", RFC 4570, July 2006.
[RFC4570] Quinn、B。およびR. Finlayson、「セッション説明プロトコル（SDP）ソースフィルター」、RFC 4570、2006年7月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「セッション説明プロトコル（SDP）グループ化フレームワーク」、RFC 5888、2010年6月。
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, September 2010.
[RFC5956] Begen、A。、「セッション説明プロトコルのセマンティクスのグループ化の分解補正補正」、RFC 5956、2010年9月。
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[RFC3890] Westerlund、M。、「セッション説明プロトコル（SDP）の輸送独立帯域幅修飾子」、RFC 3890、2004年9月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[FECFRAME-CFG-SIGNAL] Asati, R., "Methods to convey FEC Framework Configuration Information", Work in Progress, September 2011.
[fecframe-cfg-signal] asati、R。、「FECフレームワーク構成情報を伝える方法」、2011年9月、作業中。
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010.
[RFC5939] Andreasen、F。、「セッション説明プロトコル（SDP）機能交渉」、RFC 5939、2010年9月。
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