RFC4756 日本語訳
4756 Forward Error Correction Grouping Semantics in SessionDescription Protocol. A. Li. November 2006. (Format: TXT=12743 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Li Request for Comments: 4756 Hyervision Category: Standards Track November 2006
コメントを求めるワーキンググループA.李の要求をネットワークでつないでください: 4756年のHyervisionカテゴリ: 標準化過程2006年11月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントは保護されたペイロードの流れでSession記述プロトコル(SDP)で分類すると考慮するForward Error Correction(FEC)の流れの意味論を定義します。 本書では定義された意味論は同じセッションのときに一緒に分類する「セッション記述プロトコルにおける、メディア線の組分け」(RFC3388)「m」線と共に使用されることです。
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
1. 序論…2 2. 用語…2 3. エラー修正(FEC)を進めてください…2 4. FEC組分け…3 4.1. FECは分類します…3 4.2. 考慮に提供するか、または答えてください…3 4.3. FEC組分けに関する例…3 5. セキュリティ問題…4 6. IANA問題…4 7. 承認…5 8. 参照…5 8.1. 標準の参照…5 8.2. 有益な参照…5
Li Standards Track [Page 1] RFC 4756 FEC Grouping Semantics in SDP November 2006
2006年11月にSDPの意味論を分類する李標準化過程[1ページ]RFC4756FEC
1. Introduction
1. 序論
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自身はメディア線の間の関係を伝える方法を提供しません。 そのような関係は「セッション記述プロトコルにおける、メディア線の組分け」(RFC3388)[2]で定義されるようにSDPへの拡大で示されます。 RFC3388は2つのタイプの意味論を定義します: 唇同期と流れ識別。
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.
前方に、Error Correction(FEC)は誤り傾向がある環境における強健なコミュニケーションを達成する一般的なテクニックです。 本書では、保護されたペイロードの流れがSDPにある状態で、私たちは、さらにRFC3388を広げることによって、分類すると考慮するFECの流れの意味論を定義します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、「「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?」
3. Forward Error Correction (FEC)
3. 前進型誤信号訂正(FEC)
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.
前方に、Error Correction(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.
一般に、2つの異なった方法でFECデータを送ることができます: (1) 元のペイロードの流れか(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有効搭載量」(RFC2198)[4]で指定されるように協会関係を示すかもしれません。 FEC[5]のための一般的なRTPペイロード形式はその方法を使用します。
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の上のこのドキュメントはそのような関係を示すのにメカニズムを指定します。
Li Standards Track [Page 2] RFC 4756 FEC Grouping Semantics in SDP November 2006
2006年11月にSDPの意味論を分類する李標準化過程[2ページ]RFC4756FEC
4. FEC Grouping
4. FEC組分け
4.1. FEC Group
4.1. 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".
それぞれの「=グループ」線は、FECの流れとペイロードの流れとの協会関係を示すのに使用されます。「=グループ」が裏打ちする1つに含まれていた流れは「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か1つ以上のFECの流れと、1か1つ以上のペイロードの流れがあるかもしれません。 例えば、1つ以上のFECの流れ、または1つのFECの流れを共有する複数のペイロードの流れで1つのペイロードの流れを保護させるのは可能です。
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]のための一般的なRTPペイロードがFECの流れとペイロードの流れとの協会関係を示すのにFEC組分けは使用されます。 Unequal Loss Protection(ULP)アルゴリズムのための詳細な保護レベルと長さの情報はFECの流れの中でバンドで伝えられます。
4.2. Offer / Answer Consideration
4.2. 申し出/答えの考慮
The backward compatibility in offer / answer is generally handled as specified in RFC 3388 [2].
一般に、申し出/答えにおける後方の互換性はRFC3388[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).
よって、実現、SHOULDを分類する(線が全く分類されるのを理解していないか、またはただFEC意味論を理解していません)FECが答えで(1)を分類するFECを含む申し出に応じるのを理解していないノードの上では、それは拒否で要求(例えば、ここで許容できる488NotかSIPで許容できる606Not)に組分け属性か(2)を無視します。
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番目のケースまだそうしていたいなら、セッションを確立してください、それ。SHOULDは申し出でFECなしで要求を再試行します。
4.3. Example of FEC Grouping
4.3. 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
以下の例はマルチキャスト会議のセッション記述を示しています。 最初のメディアが流れる、(中間、: 1は)オーディオストリームを含んでいます。 2番目のメディアが流れる、(中間、: 2は)オーディオストリームのためのGeneric FEC[5]保護を含んでいます。 これらの2つの流れがFECグループを結成します。 2つの流れの間の関係は「=グループ: 2インチが裏打ちするFEC1」時までに示されます。 FEC小川を同じマルチキャストに送ります。
Li Standards Track [Page 3] RFC 4756 FEC Grouping Semantics in SDP November 2006
2006年11月にSDPの意味論を分類する李標準化過程[3ページ]RFC4756FEC
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.
No.twoをaにより高く移植するのを除いて、オーディオとしてLive(TTL)に同じTimeを分類して、持っています。 同様にビデオストリーム、(中間、: 3と)そのGeneric FEC保護が流れる、(中間、:4は)別のFECグループを結成します。 2つの流れの間の関係は「=グループ: 4インチが裏打ちするFEC3」時までに示されます。 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
=グループ: FECあたりv=0 o=adam289083124 289083124IN IP4 host.example.com s=ULP FEC Seminar t=0 0c=IN IP4 224.2.17.12/127、1 2、= 分類してください: FEC=オーディオの30000RTP/AVP0 3 4m aは中間の: 1m=オーディオの30002RTP/AVP100a=rtpmap: 100ulpfec/8000とa=中間であることで等しいです: 2mがビデオと等しい、30004RTP/AVP31aが: 3mの中間の=ビデオ30004RTP/AVPと等しい、101、c、=IN IP4 224.2.17.13/127a=rtpmap: 101 ulpfec/8000a=中間:、4
5. Security Considerations
5. セキュリティ問題
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のこと、そして/または、他のメディアペイロードの流れを誤って扱うことをもたらすかもしれません。受信機SHOULDが信頼できるソースからSDPを信じるだけであるためにSDPの保全チェックをして、SDP[3]のセキュリティ問題に従うのは、お勧めです。
6. IANA Considerations
6. IANA問題
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.
このドキュメントは、SDPのメディア線の組分けと共にRFC3388で定義されるように使用されるために意味論を定義します。 本書では定義された意味論はそれらが標準化過程RFCsで発行されるとき、IANAによって登録されることです。
The following semantics have been registered by IANA in Semantics for the "group" SDP Attribute under SDP Parameters.
以下の意味論はSDP Parametersの下の「グループ」SDP AttributeのためにSemanticsにIANAによって登録されました。
Semantics Token Reference ------------------------ ----- ---------- Forward Error Correction FEC RFC 4756
意味論象徴参照------------------------ ----- ---------- 前進型誤信号訂正FEC RFC4756
Li Standards Track [Page 4] RFC 4756 FEC Grouping Semantics in SDP November 2006
2006年11月にSDPの意味論を分類する李標準化過程[4ページ]RFC4756FEC
7. Acknowledgments
7. 承認
The author would like to thank Magnus Westerlund, Colin Perkins, Joerg Ott, and Cullen Jennings for their feedback on this document.
作者はこのドキュメントのそれらのフィードバックについてマグヌスWesterlund、コリン・パーキンス、ヨルク・オット、およびCullenジョニングスに感謝したがっています。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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)で立ち並んでいます」、RFC3388、2002年12月。
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[3] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
8.2. Informative References
8.2. 有益な参照
[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有効搭載量」、RFC2198(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.李HyerVision10194Wateridge円#152カリフォルニア92121サンディエゴ(米国)
Tel: +1 858 622 9038 EMail: adamli@hyervision.com
Tel: +1 9038年の858 622メール: adamli@hyervision.com
Li Standards Track [Page 5] RFC 4756 FEC Grouping Semantics in SDP November 2006
2006年11月にSDPの意味論を分類する李標準化過程[5ページ]RFC4756FEC
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Li Standards Track [Page 6]
李標準化過程[6ページ]
一覧
スポンサーリンク
