[要約] RFC 4508は、SIP REFERメソッドでの機能タグの伝達に関する仕様です。このRFCの目的は、SIPセッションの参照に関連する機能を明確に定義し、相互運用性を向上させることです。
Network Working Group O. Levin
Request for Comments: 4508 Microsoft Corporation
Category: Standards Track A. Johnston
Avaya
May 2006
Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method
セッション開始プロトコル（SIP）参照メソッドで機能タグを伝える
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
概要
The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach.
RFC 3840で定義されているSIP「発信者設定」拡張機能は、SIPリクエストがその要求を処理するためのオリジネーターの機能と好みに関連する情報を伝えることを可能にするメカニズムを提供します。RFC 3515で定義されているSIP参照方法は、ある当事者が別の当事者にSIP要求を開始するように誘導できるメカニズムを提供します。このドキュメントは、RFC 3840のメカニズムを使用するための紹介方法を拡張します。そうすることにより、紹介の創始者は、誘導要求が到達すると予想されるターゲットの特性について受信者に通知することができます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Definitions .....................................................3
4. Examples ........................................................3
4.1. isfocus Feature Tag Usage ..................................3
4.2. Voice and Video Feature Tags Usage .........................3
4.3. Example with URI parameters and multiple feature tags ......3
5. Security Considerations .........................................4
6. Acknowledgements ................................................4
7. Normative References ............................................4
This document extends the SIP [2] REFER method defined in RFC 3515 [3] to be used with feature parameters defined in RFC 3840 [4].
このドキュメントは、RFC 3515 [3]で定義されたSIP [2]参照方法を拡張し、RFC 3840 [4]で定義された特徴パラメーターで使用されます。
Feature tags are used by a UA to convey to another UA information about capabilities and features. This information can be shared by a UA using a number of mechanisms, including REGISTER requests and responses and OPTIONS responses. This information can also be shared in the context of a dialog by inclusion with a remote target URI (Contact URI).
機能タグは、UAによって使用され、機能と機能に関する別のUA情報に伝えられます。この情報は、レジスタリクエストや応答、オプションの応答など、多くのメカニズムを使用してUAで共有できます。この情報は、リモートのターゲットURI（連絡先URI）に含めることにより、ダイアログのコンテキストで共有することもできます。
Feature tag information can be very useful to another UA. It is especially useful prior to the establishment of a session. For example, if a UA knows (through an OPTIONS query, for example) that the remote UA supports both video and audio, the calling UA might call, offering video in the SDP. Another example is when a UA knows that a remote UA is acting as a focus and hosting a conference. In this case, the UA might first subscribe to the conference URI and find out details about the conference prior to sending an INVITE to join.
機能タグ情報は、別のUAにとって非常に便利です。セッションを設立する前に特に便利です。たとえば、UAがリモートUAがビデオとオーディオの両方をサポートしていることを（たとえば、オプションクエリを介して）知っている場合、Calling UAはSDPでビデオを提供する可能性があります。もう1つの例は、UAがリモートUAが焦点として機能し、会議を開催していることを知っていることです。この場合、UAは最初に会議URIを購読し、参加する招待を送信する前に会議の詳細を見つけます。
This extension to the REFER method provides a mechanism by which the REFER-Issuer can provide this useful information about the REFER-Target capabilities and functionality to the REFER-Recipient by including feature tags in the Refer-To header field in a REFER request.
この参照メソッドへの拡張機能は、参照標的機能と機能に関するこの有用な情報を参照リクエストに参照ヘッダーフィールドに紹介フィールドに含めることにより、参照標的機能と機能に関するこの有用な情報を提供できるメカニズムを提供します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "RFC 2119 [1]に記載されているように解釈されるべきです。
To simplify discussions of the REFER method and its extensions, three new terms are used throughout the document:
参照方法とその拡張の議論を簡素化するために、ドキュメント全体で3つの新しい用語が使用されます。
o REFER-Issuer: the UA issuing the REFER request o REFER-Recipient: the UA receiving the REFER request o REFER-Target: the UA designated in the Refer-To URI
o REFER-ISSUER：紹介リクエストを発行するUA o Recrecipient：recome requertを受信するua re refer-target：uri to uriで指定されているua
The Refer-To BNF from RFC 3515:
RFC 3515からの紹介BNF：
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
*(SEMI generic-param)
is extended to:
拡張されています：
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
*(SEMI refer-param)
refer-param = generic-param / feature-param
where feature-param is defined in Section 9 of RFC 3840 [4].
ここで、機能パラムはRFC 3840のセクション9で定義されています[4]。
Note that if any URI parameters are present, the entire URI must be enclosed in "<" and ">". If the "<" and ">" are not present, all parameters after the URI are header parameters, not URI parameters.
URIパラメーターが存在する場合、URI全体を「<」と「>」に囲む必要があることに注意してください。「<」と「>」が存在しない場合、URI後のすべてのパラメーターはURIパラメーターではなく、ヘッダーパラメーターです。
The example below shows how the "isfocus" feature tag can be used by REFER-Issuer to tell the REFER-Recipient that the REFER-Target is a conference focus and, consequently, that sending an INVITE will bring the REFER-Recipient into the conference:
以下の例は、「isFocus」機能タグをRefer-Issuerによってどのように使用できるかを示しています。参照標識が会議の焦点であること、そしてその結果、招待を送信することでrefer-Recipientを会議に持ち込むことを伝えることができます。：
Refer-To: sip:conf44@example.com;isfocus
The example below shows how a REFER-Issuer can tell the REFER-Recipient that the REFER-Target supports audio and video and, consequently, that a video and audio session can be established by sending an INVITE to the REFER-Target:
以下の例は、Refer-IssuerがRefer-Recipientに、参照ターゲットがオーディオとビデオをサポートしていることをどのように伝えることができるか、その結果、参照標的に招待を送信することでビデオとオーディオセッションを確立できることを示しています。
Refer-To: "Alice's Videophone" <sip:alice@videophone.example.com>
;audio;video
The example below shows how the REFER-Issuer can tell the REFER-Recipient that the REFER-Target is a voicemail server. Note that the transport URI parameter is enclosed within the "<" and ">" so that it is not interpreted as a header parameter.
以下の例は、Refer-IssuerがRefer-Recipientに参照ターゲットがボイスメールサーバーであることをどのように伝えることができるかを示しています。トランスポートURIパラメーターは、ヘッダーパラメーターとして解釈されないように「<」と「>」に囲まれていることに注意してください。
Refer-To: <sip:alice-vm@example.com;transport=tcp>
;actor="msg-taker";automata;audio
Feature tags can provide sensitive information about a user or a UA. As such, RFC 3840 cautions against providing sensitive information to another party. Once this information is given out, any use may be made of it, including relaying to a third party as in this specification.
機能タグは、ユーザーまたはUAに関する機密情報を提供できます。そのため、RFC 3840は、他の当事者に機密情報を提供することに注意しています。この情報が提供されると、この仕様のように第三者に中継するなど、使用する場合があります。
A REFER-Issuer MUST NOT create or guess feature tags. Instead, a feature tag included in a REFER SHOULD be discovered in an authenticated and secure method (such as an OPTIONS response or from a remote target URI in a dialog) directly from the REFER-Target.
参照イッサーは、機能タグを作成または推測してはなりません。代わりに、参照に含まれる機能タグは、参照標的から直接認証された安全な方法（オプション応答やダイアログ内のリモートターゲットURIから）で発見する必要があります。
It is RECOMMENDED that the REFER-Issuer includes in the Refer-To header field all feature tags that were listed in the most recent Contact header field of the REFER-Target.
Refer-Issuerには、参照ヘッダーフィールドに、リファレンスターゲットの最新のコンタクトヘッダーフィールドにリストされたすべての機能タグを含めることをお勧めします。
A feature tag provided by a REFER-Issuer cannot be authenticated or certified directly from the REFER request. As such, the REFER-Recipient MUST treat the information as a hint. If the REFER-Recipient application logic or user's action depends on the presence of the expressed feature, the feature tag can be verified. For example, in order to do so, the REFER-Recipient can directly send an OPTIONS query to the REFER-Target over a secure (e.g., mutually authenticated and integrity-protected) connection. This protects the REFER-Recipient against the sending of incorrect or malicious feature tags.
refer-Issuerが提供する機能タグは、参照要求から直接認証または認証することはできません。そのため、参照受信者は情報をヒントとして扱う必要があります。参照要件アプリケーションロジックまたはユーザーのアクションが、表現された機能の存在に依存する場合、機能タグを検証できます。たとえば、そのためには、参照受信者は、安全な（たとえば、相互に認証された、整合性保護）接続を介して、リファレンスターゲットにオプションクエリを直接送信できます。これにより、誤ったまたは悪意のある機能タグの送信から紹介が保護されます。
The authors would like to thank Jonathan Rosenberg for providing helpful guidance to this work.
著者は、この作業に役立つガイダンスを提供してくれたJonathan Rosenbergに感謝したいと思います。
[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] 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.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[3] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[4] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年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
Phone: 425-722-2225 EMail: oritl@microsoft.com
電話：425-722-2225メール：oritl@microsoft.com
Alan Johnston Avaya St. Louis, MO 63124
アラン・ジョンストン・アヴァヤ・セントルイス、ミズーリ州63124
EMail: ajohnston@ipstation.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）によって提供されます。