[要約] RFC 5688は、SIPメディア機能タグを定義し、MIMEアプリケーションサブタイプを識別するためのものです。目的は、SIPセッション中のメディアの特性を明確にすることです。
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5688 Skype
Category: Standards Track January 2010
ISSN: 2070-1721
A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes
MIMEアプリケーションサブタイプのセッション開始プロトコル（SIP）メディア機能タグ
Abstract
概要
The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities. Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability. This specification allows a UA to indicate which application subtypes the agent supports.
セッション開始プロトコル（SIP）の発信者設定仕様により、発信者は、特定の機能を持つユーザーエージェント（UA）に通話をルーティングするという設定を表現できます。同様に、UAが登録でその機能を示すことを可能にする仕様が存在します。それらの機能の中には、エージェントがサポートするメディアストリームのタイプがあり、トップレベルのMIMEタイプとして説明されています。 「アプリケーション」MIMEタイプは、幅広いストリームタイプを記述するために使用され、機能としては不十分な粒度を提供します。この仕様により、UAはエージェントがサポートするアプリケーションのサブタイプを示すことができます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc5688.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5688で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. sip.app-subtype Media Feature Tag . . . . . . . . . . . . . . . 3
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
The caller preferences specification [RFC3841] for the Session Initiation Protocol (SIP) [RFC3261] allows a user to express preferences for the routing of SIP requests. These preferences are expressed as a set of desired capabilities and characteristics of a receiving agent. When a user agent registers to the SIP network, it includes, as part of its registration, its own capabilities and characteristics [RFC3840]. These capabilities are stored as part of the registration, and then made available to the proxy in the network. When a request arrives at the proxy with caller preferences, the preferences in the request are compared with the supported characteristics and capabilities stored in the registrations, and the result is used to select the target user agents for the request.
セッション開始プロトコル（SIP）[RFC3261]の発信者設定仕様[RFC3841]により、ユーザーはSIPリクエストのルーティングの設定を表現できます。これらの設定は、受信側エージェントの望ましい機能と特性のセットとして表現されます。ユーザーエージェントがSIPネットワークに登録するとき、その登録の一部として、独自の機能と特性が含まれます[RFC3840]。これらの機能は登録の一部として保存され、ネットワークのプロキシで利用できるようになります。リクエストが呼び出し元の設定でプロキシに到着すると、リクエストの設定が、登録に保存されているサポートされている特性および機能と比較され、その結果を使用して、リクエストのターゲットユーザーエージェントが選択されます。
RFC 3840 makes use of media feature tags [RFC2506]. Each tag has a name and a type. The tags defined in RFC 3840 describe some of the basic characteristics of user agents, including whether or not they are automata (the sip.automata tag), their class (the sip.class tag), whether they support media in one or both directions (the sip.duplex), and whether they are a conference focus (sip.isfocus). These tags also include SIP capabilities, including the schemes supported by the agent (sip.schemes), the methods (sip.methods), and the event packages (sip.events) [RFC3265].
RFC 3840は、メディア機能タグ[RFC2506]を利用しています。各タグには名前とタイプがあります。 RFC 3840で定義されているタグは、それらがオートマタ（sip.automataタグ）であるかどうか、クラス（sip.classタグ）、一方向または双方向でメディアをサポートするかどうかなど、ユーザーエージェントのいくつかの基本的な特性を説明します（sip.duplex）、およびそれらが会議のフォーカスであるかどうか（sip.isfocus）。これらのタグには、エージェント（sip.schemes）、メソッド（sip.methods）、およびイベントパッケージ（sip.events）[RFC3265]でサポートされるスキームを含むSIP機能も含まれています。
RFC 3840 also defines media feature tags for multimedia stream types. There is a media feature tag defined for each top-level media type -- sip.audio for audio streams, sip.video for video streams, and so on. The primary use case for this is to correctly deliver multimedia sessions to the user agent that supports that media type. Consider a caller on a videophone that wants to have a video call with another user. That user has two devices -- a mobile phone that only supports audio and a videophone. We'd like to deliver the videophone call to the videophone as a first priority, and only 'ring' the mobile device for an audio-only call if the user is not present on the videophone.
RFC 3840では、マルチメディアストリームタイプのメディア機能タグも定義されています。トップレベルのメディアタイプごとに定義されたメディア機能タグがあります。オーディオストリームの場合はsip.audio、ビデオストリームの場合はsip.videoなどです。これの主な使用例は、そのメディアタイプをサポートするユーザーエージェントにマルチメディアセッションを正しく配信することです。別のユーザーとのビデオ通話を希望するテレビ電話の発信者を考えます。そのユーザーには、オーディオとテレビ電話のみをサポートする携帯電話という2つのデバイスがあります。私たちは、テレビ電話をテレビ電話に優先的に配信し、ユーザーがテレビ電話にいない場合にのみ、音声のみの通話のためにモバイルデバイスを「呼び出し」ます。
RFC 3840 defines media feature tags for each and every top-level media type, including 'application'. This media type covers an extremely broad range of subtypes -- multiplayer games of all sorts, shared whiteboards and application sharing, and so on. With audio and video, where there is often a common codec supported by agents (i.e., a common subtype). Consequently, if a caller wants an audio session, routing the request to any user agent that supports audio is likely to result in successful communications. However, with application streams, just routing a request to an agent that supports *some* application stream isn't useful; application streams for different applications are wildly different. Consequently, the application media feature tag does not provide sufficient granularity for call preferences. The specific application subtype needs to be indicated as well.
RFC 3840は、「アプリケーション」を含むすべてのトップレベルメディアタイプごとにメディア機能タグを定義しています。このメディアタイプは、あらゆる種類のマルチプレイヤーゲーム、共有ホワイトボード、アプリケーション共有など、非常に幅広いサブタイプをカバーしています。オーディオとビデオでは、エージェントによってサポートされる共通のコーデック（つまり、共通のサブタイプ）がよくあります。したがって、発信者がオーディオセッションを必要とする場合、オーディオをサポートするユーザーエージェントに要求をルーティングすると、通信が成功する可能性があります。ただし、アプリケーションストリームでは、*一部の*アプリケーションストリームをサポートするエージェントにリクエストをルーティングするだけでは役に立ちません。異なるアプリケーションのアプリケーションストリームは大きく異なります。その結果、アプリケーションメディア機能タグは、コールプリファレンスに十分な粒度を提供しません。特定のアプリケーションサブタイプも指定する必要があります。
To remedy this, this specification defines a new media feature tag that indicates which application subtypes are supported by the agent for streaming. The name of this media feature tag is 'sip.app-subtype'.
これを修正するために、この仕様では、ストリーミング用にエージェントがサポートするアプリケーションサブタイプを示す新しいメディア機能タグを定義しています。このメディア機能タグの名前は「sip.app-subtype」です。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The 'sip.app-subtype' media feature tag is of type token with a case-insensitive equality relationship. Its value can be any registered or private MIME application subtype compliant to the subtype-name grammar defined in [RFC4288]. When included in the Contact header field of a REGISTER request, an agent SHOULD include all application subtypes that it can support as streaming formats. An application subtype is supported if the user agent would be capable of processing a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that contained that subtype as a format in the m-line of the SDP.
「sip.app-subtype」メディア機能タグは、大文字と小文字を区別しない等価関係を持つタイプトークンです。その値は、[RFC4288]で定義されているサブタイプ名の文法に準拠した、登録済みまたはプライベートのMIMEアプリケーションサブタイプです。 REGISTERリクエストのContactヘッダーフィールドに含まれる場合、エージェントは、ストリーミング形式としてサポートできるすべてのアプリケーションサブタイプを含める必要があります（SHOULD）。ユーザーエージェントがセッション記述プロトコル（SDP）[RFC4566]オファー[RFC3264]を処理できる場合、アプリケーションサブタイプがサポートされます。このサブタイプは、SDPのm行のフォーマットとして含まれています。
When included in the Accept-Contact or Reject-Contact header field, it indicates a desire on the part of a User Agent Client (UAC) to be connected to a User Agent Server (UAS) that can support or cannot support, respectively, streaming using that application subtype.
Accept-ContactまたはReject-Contactヘッダーフィールドに含まれている場合、ユーザーエージェントクライアント（UAC）が、ストリーミングをそれぞれサポートできる、またはサポートできないユーザーエージェントサーバー（UAS）に接続したいという要望を示します。そのアプリケーションサブタイプを使用します。
It is important to note that this media feature tag is only indicating the streaming media types that a user agent is capable of supporting. It says nothing about the functionality provided by the user agent itself or the MIME types that the agent can send or receive in SIP messages or emails. For example, let us assume that a SIP user agent is capable of supporting a chess game. The game is played by each user sending chess moves as binary objects over UDP between a pair of user agents. Those objects have a MIME type of "application/example". When a UA includes the sip.app-subtype media feature tag in a Contact header field with a value of "example", it means that the UA can handle a SIP INVITE that contained an SDP with an application media line and format of "example". It does not mean that the SIP user agent is a chess application, or that the user agent can accept SIP requests that include bodies of type "application/example". To indicate that a user agent can accept SIP requests that include bodies of type "application/example", the agent would utilize the "type" media feature tag as defined in [RFC3840].
このメディア機能タグは、ユーザーエージェントがサポートできるストリーミングメディアタイプのみを示していることに注意してください。ユーザーエージェント自体が提供する機能や、エージェントがSIPメッセージや電子メールで送受信できるMIMEタイプについては何も述べられていません。たとえば、SIPユーザーエージェントがチェスゲームをサポートできると仮定します。ゲームは、チェスの動きを送信する各ユーザーが、一対のユーザーエージェント間で、UDPを介してバイナリオブジェクトとして移動します。これらのオブジェクトのMIMEタイプは「アプリケーション/例」です。 UAがsip.app-subtypeメディア機能タグを「example」の値を持つContactヘッダーフィールドに含む場合、それは、UAが「example」のアプリケーションメディアラインとフォーマットを持つSDPを含むSIP INVITEを処理できることを意味します」これは、SIPユーザーエージェントがチェスアプリケーションであること、またはユーザーエージェントが「アプリケーション/例」タイプの本文を含むSIPリクエストを受け入れることができることを意味するものではありません。ユーザーエージェントがタイプ「application / example」のボディを含むSIPリクエストを受け入れることができることを示すために、エージェントは[RFC3840]で定義されている「タイプ」メディア機能タグを利用します。
A consequence of this is that, as new streaming media type formats are defined (such as game stream formats, whiteboard session formats, and so on), they SHOULD be defined using the SDP application stream and utilize a MIME application subtype.
この結果、新しいストリーミングメディアタイプのフォーマット（ゲームストリームフォーマット、ホワイトボードセッションフォーマットなど）が定義されると、SDPアプリケーションストリームを使用して定義し、MIMEアプリケーションサブタイプを利用する必要があります。
The following is an example SIP REGISTER message fragment indicating usage of this media feature tag. The REGISTER indicates that the UA can participate in application media sessions utilizing exchange of objects of type "application/example".
以下は、このメディア機能タグの使用を示すSIP REGISTERメッセージフラグメントの例です。 REGISTERは、UAが「アプリケーション/例」タイプのオブジェクトの交換を利用してアプリケーションメディアセッションに参加できることを示します。
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
;+sip.app-subtype="example"
Such a registration indicates that an INVITE of the following form:
このような登録は、次の形式のINVITEであることを示しています。
INVITE sip:Y@example.com SIP/2.0
To: sip:Y@example.com
Content-Type: application/sdp
Content-Length: ...
v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 c=IN IP4 192.0.1.2 t=0 0 m=audio 49170 RTP/AVP 0 m=application 8493 udp example
v = 0 o = jdoe 2890844526 2890842807 IN IP4 10.47.16.5 c = IN IP4 192.0.1.2 t = 0 0 m = audio 49170 RTP / AVP 0 m = application 8493 udpの例
would be accepted by the UA. The SDP in the INVITE indicates an audio session and an application session that runs over UDP and exchanges "application/example" object formats.
UAによって受け入れられます。 INVITEのSDPは、UDPを介して実行され、「アプリケーション/例」のオブジェクト形式を交換するオーディオセッションとアプリケーションセッションを示します。
When present in a REGISTER request, this media feature tag gives information on the set of supported application media streams. It is possible that this information is sensitive, providing insight into the capabilities of a product. These considerations are already discussed in RFC 3840, and those considerations apply here as well. Applications that utilize this media feature tag SHOULD provide a means for ensuring its integrity. Similarly, the media feature tag should only be trusted as valid when it comes from the user or user agent described by the feature tag. As a result, mechanisms for conveying the feature tag SHOULD provide a mechanism for guaranteeing authenticity.
REGISTERリクエストに存在する場合、このメディア機能タグは、サポートされているアプリケーションメディアストリームのセットに関する情報を提供します。この情報は機密情報であり、製品の機能に関する洞察を提供する可能性があります。これらの考慮事項はRFC 3840で既に説明されており、それらの考慮事項はここでも適用されます。このメディア機能タグを利用するアプリケーションは、その完全性を保証する手段を提供する必要があります（SHOULD）。同様に、メディア機能タグは、機能タグによって記述されたユーザーまたはユーザーエージェントからのものである場合にのみ、有効であると信頼されるべきです。その結果、機能タグを伝達するためのメカニズムは、信頼性を保証するためのメカニズムを提供する必要があります（SHOULD）。
This specification adds a new media feature tag to the SIP Media Feature Tag Registration Tree defined in RFC 3840 [RFC3840].
この仕様は、RFC 3840 [RFC3840]で定義されているSIPメディア機能タグ登録ツリーに新しいメディア機能タグを追加します。
Media feature tag name: sip.app-subtype
メディア機能タグ名：sip.app-subtype
ASN.1 Identifier: 1.3.6.1.8.4.24
ASN.1識別子：1.3.6.1.8.4.24
Summary of the media feature indicated by this tag: This feature tag indicates the MIME application subtypes supported by the agent for purposes of streaming media.
このタグで示されるメディア機能の概要：この機能タグは、メディアをストリーミングする目的でエージェントによってサポートされるMIMEアプリケーションサブタイプを示します。
Values appropriate for use with this feature tag: Token (equality relationship).
この機能タグでの使用に適した値：トークン（等価関係）。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
機能タグは、主に次のアプリケーション、プロトコル、サービス、またはネゴシエーションメカニズムでの使用を目的としています。この機能タグは、電話やPDAなどのデバイスの機能を説明するための通信アプリケーションで最も役立ちます。
Examples of typical use: Routing a call to a phone that can support a multiplayer game.
典型的な使用例：マルチプレイヤーゲームをサポートできる電話に通話をルーティングする。
Related standards or documents: RFC 5688
関連する規格または文書：RFC 5688
Security Considerations: Security considerations for this media feature tag are discussed in Section 5 of RFC 5688.
セキュリティに関する考慮事項：このメディア機能タグのセキュリティに関する考慮事項は、RFC 5688のセクション5で説明されています。
[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月。
[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月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）でのユーザーエージェント機能の表示」、RFC 3840、2004年8月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 4288、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A。、「Session Initiation Protocol（SIP）-Specific Event Notification」、RFC 3265、2002年6月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「Session Initiation Protocol（SIP）の発信者設定」、RFC 3841、2004年8月。
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC2506] Holtman、K.、Mutz、A。、およびT. Hardie、「Media Feature Tag Registration Procedure」、BCP 31、RFC 2506、1999年3月。
Author's Address
著者のアドレス
Jonathan Rosenberg Skype Monmouth, NJ USA
Jonathan Rosenberg Skypeモンマス、ニュージャージー州アメリカ合衆国
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net