[要約] RFC 4574は、セッション記述プロトコル(SDP)のラベル属性に関する仕様です。このRFCの目的は、SDPセッションのラベル情報を提供し、セッションの特性や要件を明確にすることです。

Network Working Group                                           O. Levin
Request for Comments: 4574                         Microsoft Corporation
Category: Standards Track                                   G. Camarillo
                                                                Ericsson
                                                             August 2006
        

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.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の現在のエディションを参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2006).

Copyright(c)The Internet Society(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.

このドキュメントでは、新しいセッション説明プロトコル(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. 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は、メディアタイプ、輸送プロトコル、メディア形式に関係なく、会議での役割に関してメディアストリームを独自に識別する必要性を特定します。これは、適切なメディアストリームを指す外部ドキュメントを使用して、情報(たとえば、会議におけるメディアストリームの役割)を提供することで実現できます。Conference State [7]のSIPイベントパッケージは、このような外部ドキュメントの具体的な形式を定義および使用します。

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セッションの説明で「M」行で記述されるメディアストリームへのポインターを提供します。

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.

このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈され、準拠の実装の要件レベルを示します。

3. Motivation for the New label Attribute
3. 新しいラベル属性の動機

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.

RFC 2327 [4]で定義されている「i 'SDP属性は、メディアストリームのラベルを付けるために使用できます。それにもかかわらず、「i」属性の値は、オートマトンではなく、人間のユーザーを対象としています。

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).

RFC 3388 [6]で定義されている「Mid」SDP属性は、メディアストリームを識別するためにも使用できます。それにもかかわらず、「MID」の範囲は、複数のSDPセッションを扱うアプリケーションでは使用できないほど制限されています。これは、「MID」属性の値が、単一の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セッションドキュメントの「M」行の順序を使用することです(たとえば、セッションの説明の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)
        
      token-char         = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                           / %x41-5A / %x5E-7E
        

The token-char and token elements are defined in [4] but included here to provide support for the implementor of this SDP feature.

トークンcharおよびトークン要素は[4]で定義されていますが、このSDP機能の実装者をサポートするためにここに含まれています。

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ドキュメントの「M」行に添付でき、必要に応じてアプリケーションがSDPセッション全体でメディアストリームを論理的にグループ化できます。

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
        
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.

攻撃者は、セッションの説明から「ラベル」属性を追加、変更、または削除しようとすることができます。これにより、アプリケーションが非決定不可能な方法で動作する可能性があります。したがって、SDPセッションの説明に完全性保護を適用することを強くお勧めします。SIP [5]で伝えられるセッションの説明では、S/MIMEは、RFC 3261 [5]に記載されているように、このようなエンドツーエンドの完全性保護を提供する自然な選択です。他のアプリケーションは、異なる形式の整合性保護を使用する場合があります。

8. IANA Considerations
8. IANAの考慮事項

The IANA has registered the following new SDP attribute:

IANAは、次の新しいSDP属性を登録しています。

Contact name: Orit Levin oritl@microsoft.com.

連絡先名:orit levin olitl@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.

ロバート・スパークス、アダム・ローチ、およびロハン・マヒーは、この文書に有用なコメントを提供しました。

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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[2] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強:ABNF」、RFC 4234、2005年10月。

[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[3] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル(SDP)を備えたオファー/回答モデル」、RFC 3264、2002年6月。

[4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[4] Handley、M.、Jacobson、V。and C. Perkins、「SDP:セッション説明プロトコル」、RFC 4566、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP:SESSION INTIATION Protocol"、RFC 3261、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] Camarillo、G.、Eriksson、G.、Holler、J。、およびH. Schulzrinne、「セッション説明プロトコル(SDP)のメディアラインのグループ化」、RFC 3388、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] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、「会議州のセッション開始プロトコル(SIP)イベントパッケージ」、RFC 4575、2006年8月。

Authors' Addresses

著者のアドレス

Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA

Orit Levin Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA

   EMail: oritl@microsoft.com
        

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2006).

Copyright(c)The Internet Society(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 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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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 provided by the IETF Administrative Support Activity (IASA).

RFCエディター機能の資金は、IETF管理サポートアクティビティ(IASA)によって提供されます。