RFC4574 日本語訳
4574 The Session Description Protocol (SDP) Label Attribute. O. Levin,G. Camarillo. August 2006. (Format: TXT=13484 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group O. Levin
Request for Comments: 4574 Microsoft Corporation
Category: Standards Track G. Camarillo
Ericsson
August 2006
コメントを求めるワーキンググループO.レヴィンの要求をネットワークでつないでください: 4574年のマイクロソフト社カテゴリ: 標準化過程G.キャマリロエリクソン2006年8月
The Session Description Protocol (SDP) Label Attribute
セッション記述プロトコル(SDP)ラベル属性
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 Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context.
このドキュメントは新しいSession記述プロトコル(SDP)メディアレベル属性を定義します: 「ラベルします」。 「ラベル」属性はSDPを使用する任意のネットワーク応用の文脈のメディアストリームまで指針を運びます。 SDPドキュメントの送付者は「ラベル」属性を特定のメディアストリームかストリームに付けることができます。次に、アプリケーションは、文脈のそれぞれの特定のメディアストリームについて言及するのに提供された指針を使用できます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Motivation for the New label Attribute ..........................2
4. The Label Attribute .............................................3
5. The Label Attribute in the Offer/Answer Model ...................4
6. Example .........................................................4
7. Security Considerations .........................................4
8. IANA Considerations .............................................5
9. Acknowledgements ................................................5
10. References .....................................................6
10.1. Normative References ......................................6
10.2. Informative References ....................................6
1. 序論…2 2. 用語…2 3. NewラベルAttributeに関する動機…2 4. ラベル属性…3 5. 申し出/答えモデルのラベル属性…4 6. 例…4 7. セキュリティ問題…4 8. IANA問題…5 9. 承認…5 10. 参照…6 10.1. 標準の参照…6 10.2. 有益な参照…6
Levin & Camarillo Standards Track [Page 1] RFC 4574 SDP Label Attribute August 2006
レヴィンとRFC4574SDPが属性2006年8月にレッテルを貼るキャマリロ標準化過程[1ページ]
1. Introduction
1. 序論
SDP is being used by a variety of distributed-over-the-network applications. These applications deal with multiple sessions being described by SDP [4] and serving multiple users or services in the context of a single application instance. Applications of this kind need a means to identify a particular media stream across multiple SDP descriptions exchanged with different users.
SDPが使用されている、様々である、分配、過剰、ネットワーク応用 これらのアプリケーションはただ一つのアプリケーションインスタンスの文脈でSDP[4]によって説明されて、複数のユーザかサービスに役立つことである複数のセッションに対処します。 この種類のアプリケーションは異なったユーザと共に交換された複数のSDP記述の向こう側に特定のメディアストリームを特定する手段を必要とします。
The XCON framework is an example of a centralized conference architecture that uses SDP according to the offer/answer mechanism defined in [3] to establish media streams with each of the conference participants. Additionally, XCON identifies the need to uniquely identify a media stream in terms of its role in a conference regardless of its media type, transport protocol, and media format. This can be accomplished by using an external document that points to the appropriate media stream and provides information (e.g., the media stream's role in the conference) about it. The SIP Event Package for Conference State [7] defines and uses a concrete format for such external documents.
XCONフレームワークは会議の参加者各人と共にメディアストリームを証明するために[3]で定義された申し出/答えメカニズムによると、SDPを使用する集結された会議アーキテクチャに関する例です。 さらに、XCONはメディアタイプ、トランスポート・プロトコル、およびメディア形式にかかわらず会議における役割に関して唯一メディアストリームを特定する必要性を特定します。 それに関して適切なメディアストリームを示して、(例えば、会議におけるメディアストリームの役割)を情報に提供する外部のドキュメントを使用することによって、これを達成できます。 コンファレンス州[7]のためのSIP Eventパッケージは、そのような外部のドキュメントに具体的な書式を定義して、使用します。
This specification defines the SDP [4] "label" media-level attribute, which provides a pointer to a media stream that is described by an 'm' line in an SDP session description.
(属性はそれが説明されるメディアストリームに指針を提供します)。中に'系列があります。'この仕様がSDP[4]「ラベル」メディアレベル属性を定義する、SDPセッション記述。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
3. Motivation for the New label Attribute
3. NewラベルAttributeに関する動機
Even though SDP and its extensions already provide a few ways to refer to a media stream, none of them is appropriate to be used in the context of external documents that may be created before the session description itself and need to be handled by automata.
SDPとその拡大は既にメディアストリームについて言及するいくつかの方法を提供しますが、それらのいずれもセッション記述自体の前に作成されるかもしれない外部のドキュメントの文脈で使用されて、オートマトンによって扱われるのが必要であるのは適切ではありません。
The 'i' SDP attribute, defined in RFC 2327 [4], can be used to label media streams. Nevertheless, values of the 'i' attribute are intended for human users and not for automata.
メディアをストリームに分類するのにRFC2327[4]で定義された'i'SDP属性は使用できます。それにもかかわらず、'i'属性の値はオートマトンのために意図するのではなく、人間のユーザのために意図します。
Levin & Camarillo Standards Track [Page 2] RFC 4574 SDP Label Attribute August 2006
レヴィンとRFC4574SDPが属性2006年8月にレッテルを貼るキャマリロ標準化過程[2ページ]
The 'mid' SDP attribute, defined in RFC 3388 [6], can be used to identify media streams as well. Nevertheless, the scope of 'mid' is too limited to be used by applications dealing with multiple SDP sessions. This is because values of the 'mid' attribute are meaningful in the context of a single SDP session, not in the context of a broader application (e.g., a multiparty application).
また、メディアストリームを特定するのにRFC3388[6]で定義された'中間'のSDP属性は使用できます。 それにもかかわらず、'中間'の範囲は複数のSDPセッションに対処するアプリケーションで使用されるのがあまり限られています。 これは'中間'の属性の値が、より広いアプリケーション(例えば、「マルチ-パーティー」アプリケーション)の文脈で重要であるのではなく、ただ一つのSDPセッションの文脈で重要であるからです。
Another way of referring to a media stream is by using the order of the 'm' line in the SDP session document (e.g., the 5th media stream in the session description). This is the mechanism used in the offer/answer model [3].
中に'系列があります。'メディアストリームについて言及する別の方法がオーダーを使用することによってある、SDPセッションドキュメント(例えば、セッション記述における5番目のメディアストリーム)。 これは申し出/答えモデル[3]で使用されるメカニズムです。
The problem with this mechanism is that it can only be used to refer to media streams in session descriptions that exist already. There are scenarios where a static document needs to refer, using a pointer, to a media stream that will be negotiated by SDP means and created in the future. When the media stream is eventually created, the application needs to label the media stream so that the pointer in the static document points to the proper media stream in the session description.
このメカニズムに関する問題は既に存在するセッション記述におけるメディアストリームについて言及するのにそれを使用できるだけであるということです。 シナリオが静的なドキュメントが参照する必要があるところにあります、指針を使用して、SDP手段で交渉されて、将来作成されるメディアストリームに。 メディアストリームが結局作成されるとき、アプリケーションが、メディアストリームをラベルする必要があるので、静的なドキュメントの指針はセッション記述における適切なメディアストリームを示します。
4. The Label Attribute
4. ラベル属性
This specification defines a new media-level value attribute: 'label'. Its formatting in SDP is described by the following ABNF [2]:
この仕様はニューメディアレベル値の属性を定義します: 'ラベルします'。 SDPの形式は以下のABNF[2]によって説明されます:
label-attribute = "a=label:" pointer
ラベル属性=「=は以下をラベルします」。 指針
pointer = token
指針=トークン
token = 1*(token-char)
トークン=1*(トークン炭)
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
%x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7トークン炭=E
The token-char and token elements are defined in [4] but included here to provide support for the implementor of this SDP feature.
トークン炭とトークン要素は、このSDPの特徴の作成者のサポートを提供するために[4]で定義されますが、ここに含まれています。
The 'label' attribute contains a token that is defined by an application and is used in its context. The new attribute can be attached to 'm' lines in multiple SDP documents allowing the application to logically group the media streams across SDP sessions when necessary.
'ラベル'属性はアプリケーションで定義されて、文脈で使用されるトークンを含んでいます。 '新しい属性は'付けるのが、必要であるときにアプリケーションがSDPセッションの向こう側にメディアストリームを論理的に分類できる複数のSDPドキュメントの系列であるということであるかもしれません。
Levin & Camarillo Standards Track [Page 3] RFC 4574 SDP Label Attribute August 2006
レヴィンとRFC4574SDPが属性2006年8月にレッテルを貼るキャマリロ標準化過程[3ページ]
5. The Label Attribute in the Offer/Answer Model
5. 申し出/答えモデルのラベル属性
This specification does not define a means to discover whether or not the peer endpoint understands the 'label' attribute because 'label' values are informative only at the offer/answer model level.
この仕様は'ラベル'値が単に申し出/答えモデルレベルで有益であるので同輩終点が'ラベル'属性を理解しているかどうか発見する手段を定義しません。
At the offer/answer level, it means that the fact that an offer does not contain label attributes does not imply that the answer should not have them. It also means that the fact that an offer contains label attributes does not imply that the answer should have them too.
申し出/答えレベルでは、それは、申し出がラベル属性を含んでいないという事実が、答えにはそれらがあるべきでないのを含意しないことを意味します。 また、それは、申し出がラベル属性を含んでいるという事実が、答えにはそれらもあるべきであるのを含意しないことを意味します。
In addition to the basic offer/answer rule above, applications that use 'label' as a pointer to media streams MUST specify its usage constraints. For example, such applications MAY mandate support for 'label'. In this case, the application will define means for negotiation of the 'label' attribute support as a part of its specification.
基本的な申し出/答え規則に加えて、上では、メディアへの指針が流れるとき'ラベル'を使用するアプリケーションが用法規制を指定しなければなりません。 例えば、そのようなアプリケーションは'ラベル'のサポートを強制するかもしれません。 この場合、アプリケーションは'ラベル'属性サポートの交渉のための手段を仕様の一部と定義するでしょう。
6. Example
6. 例
The following is an example of an SDP session description that uses the 'label' attribute:
↓これは'ラベル'属性を使用するSDPセッション記述に関する例です:
v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
i=A Seminar on the session description protocol
c=IN IP4 192.0.2.2
t=0 0
m=audio 6886 RTP/AVP 0
a=label:1
m=audio 22334 RTP/AVP 0
a=label:2
セッション記述プロトコルc=IN IP4 192.0.2.2t==オーディオの6886RTP/AVP0 0 0m a=ラベルの上のボブの280744730 28977631IN v=0o=IP4 host.example.com s=i=A Seminar: オーディオの22334RTP/AVP0 1m=a=ラベル: 2
7. Security Considerations
7. セキュリティ問題
An attacker may attempt to add, modify, or remove 'label' attributes from a session description. This could result in an application behaving in a non-desirable way. So, it is strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions. For session descriptions carried in SIP [5], S/MIME is the natural choice to provide such end-to-end integrity protection, as described in RFC 3261 [5]. Other applications MAY use a different form of integrity protection.
攻撃者は、セッション記述から'ラベル'属性を加えるか、変更するか、または取り除くのを試みるかもしれません。 これは非望ましい方法で振る舞うアプリケーションをもたらすかもしれません。 強く、保全保護をあるRECOMMENDEDは、申し込みました。したがって、それがそうである、SDPセッション記述。 SIP[5]で運ばれたセッション記述のために、S/MIMEは終わりから終わりへの保全そのような保護を提供する自然な選択です、RFC3261[5]で説明されるように。 他のアプリケーションは異なった形式の保全保護を使用するかもしれません。
Levin & Camarillo Standards Track [Page 4] RFC 4574 SDP Label Attribute August 2006
レヴィンとRFC4574SDPが属性2006年8月にレッテルを貼るキャマリロ標準化過程[4ページ]
8. IANA Considerations
8. IANA問題
The IANA has registered the following new SDP attribute:
IANAは以下の新しいSDP属性を示しました:
Contact name: Orit Levin oritl@microsoft.com.
名前に連絡してください: Oritレヴィン oritl@microsoft.com 。
Attribute name: "label".
名前を結果と考えてください: 「ラベルします」。
Type of attribute: Media level.
属性のタイプ: メディアレベル。
Subject to charset: Not.
charsetへの対象: .
Purpose of attribute: The 'label' attribute associates a media stream with a label. This label allows the media stream to be referenced by external documents.
属性の目的: 'ラベル'属性はメディアストリームをラベルに関連づけます。 このラベルは、メディアストリームが外部のドキュメントによって参照をつけられるのを許容します。
Allowed attribute values: A token.
許容属性値: トークン。
9. Acknowledgements
9. 承認
Robert Sparks, Adam Roach, and Rohan Mahy provided useful comments on this document.
ロバート・スパークス、アダム・ローチ、およびRohanマーイはこのドキュメントの役に立つコメントを提供しました。
Levin & Camarillo Standards Track [Page 5] RFC 4574 SDP Label Attribute August 2006
レヴィンとRFC4574SDPが属性2006年8月にレッテルを貼るキャマリロ標準化過程[5ページ]
10. References
10. 参照
10.1. Normative References
10.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] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[2] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[4] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
10.2. Informative References
10.2. 有益な参照
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[6] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[6]キャマリロ、G.、エリクソン、G.、叫び声、J.、およびH.Schulzrinne、「メディアの組分けはセッション記述プロトコル(SDP)で立ち並んでいます」、RFC3388、2002年12月。
[7] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[7] ローゼンバーグ、J.、Schulzrinne、H.、およびO.レヴィン、「コンファレンス状態へのセッション開始プロトコル(一口)イベントパッケージ」、RFC4575(2006年8月)。
Levin & Camarillo Standards Track [Page 6] RFC 4574 SDP Label Attribute August 2006
レヴィンとRFC4574SDPが属性2006年8月にレッテルを貼るキャマリロ標準化過程[6ページ]
Authors' Addresses
作者のアドレス
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Oritレヴィンマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: oritl@microsoft.com
メール: oritl@microsoft.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Levin & Camarillo Standards Track [Page 7] RFC 4574 SDP Label Attribute August 2006
レヴィンとRFC4574SDPが属性2006年8月にレッテルを貼るキャマリロ標準化過程[7ページ]
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Levin & Camarillo Standards Track [Page 8]
レヴィンとキャマリロ標準化過程[8ページ]
一覧
スポンサーリンク
