Network Working Group O. Levin
Request for Comments: 4508 Microsoft Corporation
Category: Standards Track A. Johnston
Avaya
May 2006
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）REFER方法传送功能标签
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).
版权所有（C）互联网协会（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.
rfc3840中定义的SIP“呼叫者偏好”扩展提供了一种机制，该机制允许SIP请求传递与发起人处理该请求的能力和偏好相关的信息。RFC 3515中定义的SIP REFER方法提供了允许一方诱导另一方发起SIP请求的机制。本文档扩展了REFER方法以使用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
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]REFER方法，以用于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同时支持视频和音频，则主叫UA可能会呼叫，在SDP中提供视频。另一个例子是当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.
REFER方法的扩展提供了一种机制，通过该机制，REFER发卡机构可以通过在REFER请求的REFER-REFER标头字段中包含功能标签，向REFER接收方提供有关REFER-Target功能和功能的有用信息。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中的说明进行解释。
To simplify discussions of the REFER method and its extensions, three new terms are used throughout the document:
为了简化对REFER方法及其扩展的讨论，本文档中使用了三个新术语：
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 转介发卡机构：发出转介请求的UA转介收件人：接收转介请求的UA转介目标：转介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)
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
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[4]第9节定义了特征参数。
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-To: sip:conf44@example.com;isfocus
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-To: "Alice's Videophone" <sip:alice@videophone.example.com>
;audio;video
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发卡机构如何告知REFER收件人REFER目标是语音邮件服务器。请注意，传输URI参数包含在“<”和“>”中，因此它不会被解释为标头参数。
Refer-To: <sip:alice-vm@example.com;transport=tcp>
;actor="msg-taker";automata;audio
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发卡机构在REFER-REFER标头字段中包含REFER目标最近联系人标头字段中列出的所有功能标签。
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颁发者提供的功能标签不能直接通过REFER请求进行身份验证或认证。因此，推荐接收者必须将信息视为提示。如果refererecipient应用程序逻辑或用户操作取决于所表达功能的存在，则可以验证功能标签。例如，为了做到这一点，REFER接收方可以通过安全（例如，相互认证和完整性保护）连接直接向REFER目标发送选项查询。这可以防止REFER收件人发送不正确或恶意的功能标签。
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：会话启动协议”，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
奥利特·莱文微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
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
EMail: ajohnston@ipstation.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（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.
本文件受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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。