Network Working Group A. Li
Request for Comments: 4756 Hyervision
Category: Standards Track November 2006
Forward Error Correction Grouping Semantics
in Session Description Protocol
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
This document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) to group together "m" lines in the same session.
この文書では、セッション記述プロトコルで保護されたペイロードストリーム（SDP）とストリーム前方誤り訂正（FEC）のグループ化を可能にするセマンティクスを定義します。この文書で定義された意味は、同じセッションで「M」の行をグループに「セッション記述プロトコルにおけるメディア行のグループ化」（RFC 3388）で使用されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Forward Error Correction (FEC) ..................................2
4. FEC Grouping ....................................................3
4.1. FEC Group ..................................................3
4.2. Offer / Answer Consideration ...............................3
4.3. Example of FEC Grouping ....................................3
5. Security Considerations .........................................4
6. IANA Considerations .............................................4
7. Acknowledgments .................................................5
8. References ......................................................5
8.1. Normative References .......................................5
8.2. Informative References .....................................5
The media lines in an SDP [3] session may be associated with each other in various ways. SDP itself does not provide methods to convey the relationships between the media lines. Such relationships are indicated by the extension to SDP as defined in "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) [2]. RFC 3388 defines two types of semantics: Lip Synchronization and Flow Identification.
SDP [3]セッション内のメディア行は、様々な方法で互いに関連付けられてもよいです。 SDP自体は、メディアラインの間の関係を伝えるための方法を提供していません。 「セッション記述プロトコルにおけるメディア行のグループ化」で定義され、このような関係は、SDPに拡張することによって（RFC 3388）に示されている[2]。リップ同期とフローの識別：RFC 3388には、意味論の二つのタイプを定義します。
Forward Error Correction (FEC) is a common technique to achieve robust communication in error-prone environments. In this document, we define the semantics that allows for grouping of FEC streams with the protected payload streams in SDP by further extending RFC 3388.
前方誤り訂正（FEC）は、エラーが発生しやすい環境での強固な通信を実現するための一般的な技術です。この文書では、我々はさらに、RFC 3388を拡張することにより、SDP内の保護ペイロードストリームと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 RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、「、すべきである "べきではない "ないもの" "ものと""、 "推奨"、 "MAY"、および "" オプションがにありますRFC 2119に記載されるように解釈される[1]。
Forward Error Correction (FEC) is a common technique to achieve robust communication in error-prone environments. In FEC, communication uses a bandwidth that is more than payload to send redundantly coded payload information. The receivers can readily recover the original payload even when some communication is lost in the transmission. Compared to other error correction techniques (such as retransmission), FEC can achieve much lower transmission delay, and it does not have the problem of implosion from retransmission requests in various multicast scenarios.
前方誤り訂正（FEC）は、エラーが発生しやすい環境での強固な通信を実現するための一般的な技術です。 FECでは、通信は、冗長符号化されたペイロード情報を送信するためのペイロードよりも大きい帯域幅を使用します。受信機は、容易に、いくつかの通信が送信中に失われても、元のペイロードを回復することができます。 （例えば、再送のような）他の誤り訂正技術と比較して、FECは、はるかに低い送信遅延を達成することができ、それは様々なマルチキャストシナリオでの再送要求から爆縮の問題を有していません。
In general, the FEC data can be sent in two different ways: (1) multiplexed together with the original payload stream or (2) as a separate stream. It is thus necessary to define mechanisms to indicate the association relationship between the FEC data and the payload data they protect.
（1）元のペイロード・ストリーム又は（2）のような別のストリームと共に多重化：一般的には、FECデータは、2つの異なる方法で送信することができます。 FECデータと、それらが保護するペイロード・データとの対応関係を示すためのメカニズムを定義する必要があります。
When FEC data are multiplexed with the original payload stream, the association relationship may, for example, be indicated as specified in "An RTP Payload for Redundant Audio Data" (RFC 2198) [4]. The generic RTP payload format for FEC [5] uses that method.
FECデータは、元のペイロードストリームに多重化されている場合、対応関係は、例えば、「冗長オーディオデータのRTPペイロード」で指定されるように示されてもよい（RFC 2198）[4]。 FECのための一般的なRTPペイロードフォーマットは、[5]その方法を使用します。
When FEC data are sent as a separate stream from the payload data, the association relationship can be indicated in various ways. This document on the FEC media line grouping specifies a mechanism for indicating such relationships.
FECデータはペイロードデータとは別のストリームとして送信されるとき、対応関係は、様々な方法で示すことができます。 FECメディア行のグループ化でこの文書では、そのような関係を示すためのメカニズムを指定します。
Each "a=group" line is used to indicate an association relationship between the FEC streams and the payload streams. The streams included in one "a=group" line are called a "FEC Group".
各「A =グループ」線はFECストリームとペイロードストリーム間の対応関係を示すために使用されます。 1「A =グループ」ラインに含まれるストリームは、「FECグループ」と呼ばれています。
Each FEC group MAY have one or more than one FEC stream, and one or more than one payload stream. For example, it is possible to have one payload stream protected by more than one FEC stream , or multiple payload streams sharing one FEC stream.
各FECグループは、1つまたは複数のFECストリーム、および1つまたは複数のペイロード・ストリームを持っているかもしれません。例えば、一個の以上のFECストリームで保護ペイロードストリーム、または1つのFECストリームを共有する複数のペイロード・ストリームを有することが可能です。
Grouping streams in a FEC group only indicates the association relationship between streams. The detailed FEC protection scheme/parameters are conveyed through the mechanism of the particular FEC algorithm used. For example, the FEC grouping is used for generic RTP payload for FEC [5] to indicate the association relationship between the FEC stream and the payload stream. The detailed protection level and length information for the Unequal Loss Protection (ULP) algorithm is communicated in band within the FEC stream.
FECグループにストリームをグループ化するだけストリーム間の対応関係を示しています。詳細なFEC保護方式/パラメータは、使用される特定のFECアルゴリズムの機構を介して搬送されます。例えば、FECグルーピングは、[5] FECストリームとペイロードストリーム間の対応関係を示すために、FECのための一般的なRTPペイロードのために使用されます。不等ロスプロテクション（ULP）アルゴリズムの詳細な保護レベルと長さ情報は、FECストリーム内の帯域で通信されます。
The backward compatibility in offer / answer is generally handled as specified in RFC 3388 [2].
RFC 3388で指定されるようにオファー/アンサーに下位互換性は、一般的に処理される[2]。
Depending on the implementation, a node that does not understand FEC grouping (either does not understand line grouping at all, or just does not understand the FEC semantics) SHOULD respond to an offer containing FEC grouping either (1) with an answer that ignores the grouping attribute or (2) with a refusal to the request (e.g., 488 Not acceptable here or 606 Not acceptable in SIP).
実装に応じて、FECグループ化を理解していないノードは、（すべてでグループ化ラインを理解していないか、単にFECの意味を理解していないのいずれか）（1）無視答えのいずれかのグループ化FECを含むプランに応じます要求に拒否を持つ属性または（2）をグループ化する（ここでは例えば、488許容できないか、SIPにおける606受け入れられません）。
In the first case, the original sender of the offer MUST establish the connection without FEC. In the second case, if the sender of the offer still wishes to establish the session, it SHOULD re-try the request with an offer without FEC.
最初のケースでは、オファーの元の送信者は、FECなしで接続を確立する必要があります。オファーの送信者がまだセッションを確立することを希望する場合は、2番目のケースでは、それはFECなしで提供して、要求を再試してみてください。
The following example shows a session description of a multicast conference. The first media stream (mid:1) contains the audio stream. The second media stream (mid:2) contains the Generic FEC [5] protection for the audio stream. These two streams form an FEC group. The relationship between the two streams is indicated by the "a=group:FEC 1 2" line. The FEC stream is sent to the same multicast group and has the same Time to Live (TTL) as the audio, but on a port number two higher. Likewise, the video stream (mid:3) and its Generic FEC protection stream (mid:4) form another FEC group. The relationship between the two streams is indicated by the "a=group:FEC 3 4" line. The FEC stream is sent to a different multicast address, but has the same port number (30004) as the payload video stream.
次の例では、マルチキャスト会議のセッション記述を示しています。最初のメディアストリーム（ミッドは：1）オーディオストリームが含まれています。第2のメディアストリーム（ミッド：2）オーディオストリームのための一般的なFEC [5]の保護が含まれています。これら二つの流れは、FECグループを形成します。ライン2つのストリーム間の関係は、「FEC 1 2 A =基」で示されています。 FECストリームは、同一のマルチキャストグループに送信され、オーディオとして生きるために同じ時間（TTL）を有するが、ポート番号2に高くされています。同様に、ビデオストリーム（ミッド：3）とそのジェネリックFEC保護ストリーム（ミッドは：4）別のFECグループを形成します。ライン2つのストリーム間の関係は、「FEC 3 4 A =基」で示されています。 FECストリームは、異なるマルチキャストアドレスに送信されたが、ペイロード・ビデオ・ストリームと同一のポート番号（30004）を有しています。
v=0
o=adam 289083124 289083124 IN IP4 host.example.com
s=ULP FEC Seminar
t=0 0
c=IN IP4 224.2.17.12/127
a=group:FEC 1 2
a=group:FEC 3 4
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 100
a=rtpmap:100 ulpfec/8000
a=mid:2
m=video 30004 RTP/AVP 31
a=mid:3
m=video 30004 RTP/AVP 101
c=IN IP4 224.2.17.13/127
a=rtpmap:101 ulpfec/8000
a=mid:4
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 mishandling of other media payload streams. It is recommended that the receiver SHOULD do integrity check on SDP and follow the security considerations of SDP [3] to only trust SDP from trusted sources.
FECグループが存在しないFECの関係を示すように変更することができる受信機のための弱い脅威があります。このような攻撃は、保護するためにFECの故障、および/または他のメディアペイロードストリームの誤操作を生じ得ます。 [3]信頼できるソースからのみSDPを信頼するように受信機はSDPの整合性チェックを行い、SDPのセキュリティ上の考慮事項に従うべきであることをお勧めします。
This document defines the semantics to be used with grouping of media lines in SDP as defined in RFC 3388. The semantics defined in this document are to be registered by the IANA when they are published in standards track RFCs.
この文書は、本文書に定義された意味がRFC 3388.で定義されたSDP内のメディア・ラインのグループ化で使用するセマンティクスを定義し、それらを標準で公開されているとき、IANAによって登録されるRFCを追跡します。
The following semantics have been registered by IANA in Semantics for the "group" SDP Attribute under SDP Parameters.
次のセマンティクスは、SDPパラメータの下の「グループ」SDP属性のためのセマンティクスにIANAによって登録されています。
Semantics Token Reference
------------------------ ----- ----------
Forward Error Correction FEC RFC 4756
The author would like to thank Magnus Westerlund, Colin Perkins, Joerg Ott, and Cullen Jennings for their feedback on this document.
作者はこのドキュメントの彼らのフィードバックのためにマグヌスウェスター、コリンパーキンス、イェルク・オット、およびカレンジェニングスに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[2]キャマリロ、G.、エリクソン、G.、大声、J.、およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）におけるメディア行のグループ化"、RFC 3388、2002年12月。
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[3]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[4] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
[4]パーキンス、C.、Kouvelas、I.、ホドソン、O.、ハードマン、V.、ハンドレー、M.、Bolot、J.、ベガ・ガルシア、A.、およびS.フォッシー-Parisis、「RTPペイロード冗長オーディオ・データ」、RFC 2198、1997年9月のため。
[5] Li, A., "An RFC Payload Format for Generic FEC", Work in Progress.
[5]李、A.、 "ジェネリックFECのためのRFCペイロードフォーマット" が進行中で働いています。
Author's Address
著者のアドレス
Adam H. Li HyerVision 10194 Wateridge Circle #152 San Diego, CA 92121 U.S.A.
アダムH.リーHyerVision 10194 Wateridgeサークル＃152サンディエゴ、CA 92121 U.S.A.
Tel: +1 858 622 9038 EMail: adamli@hyervision.com
電話：+1 858 622 9038 Eメール：adamli@hyervision.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。