Network Working Group J. Peterson
Request for Comments: 3764 NeuStar
Category: Standards Track April 2004
Network Working Group J. Peterson
Request for Comments: 3764 NeuStar
Category: Standards Track April 2004
enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record
记录的会话启动协议（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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM.
本文档根据RFC 3761中的指南，为会话启动协议（SIP）注册了一个电子号码（ENUM）服务。具体来说，本文档重点介绍在ENUM中提供记录的SIP地址。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ENUM Service Registration . . . . . . . . . . . . . . . . . . . 2
3. Addresses-of-record in SIP. . . . . . . . . . . . . . . . . . . 3
4. The 'E2U+SIP' enumservice . . . . . . . . . . . . . . . . . . . 5
5. Example of E2U+SIP enumservice. . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References. . . . . . . . . . . . . . . . . . . 6
8.2. Informative References. . . . . . . . . . . . . . . . . . 7
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 7
10. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 8
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ENUM Service Registration . . . . . . . . . . . . . . . . . . . 2
3. Addresses-of-record in SIP. . . . . . . . . . . . . . . . . . . 3
4. The 'E2U+SIP' enumservice . . . . . . . . . . . . . . . . . . . 5
5. Example of E2U+SIP enumservice. . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References. . . . . . . . . . . . . . . . . . . 6
8.2. Informative References. . . . . . . . . . . . . . . . . . 7
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 7
10. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 8
ENUM (E.164 Number Mapping, RFC 2916 [6]) is a system that uses DNS (Domain Name Service, STD 13, RFC 1034 [3]) to translate telephone numbers, like '+12025332600', into URIs (Uniform Resource Identifiers, RFC 2396 [4]), like 'sip:egar@example.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to route transactions. This document applies to the revised version of ENUM described in RFC 3761.
ENUM（E.164数字映射，RFC 2916[6]）是一个使用DNS（域名服务，STD 13，RFC 1034[3]）将电话号码（如“+12025332600”）转换为URI（统一资源标识符，RFC 2396[4]），如“sip:egar@example.com'. ENUM的存在主要是为了促进依赖电话号码的系统与使用uri路由事务的系统之间的互连。本文件适用于RFC 3761中所述的ENUM修订版。
SIP (Session Initiation Protocol, RFC 3261 [2]) is a text-based application protocol that allows endpoints on the Internet to discover one another in order to exchange context information about a session they would like to share. Common forms of communication that are set up by SIP include Internet telephony, instant messaging, video, Internet gaming and other forms of real-time communications. SIP is a multi-service protocol capable of initiating sessions involving different forms of real-time communications simultaneously. SIP is a protocol that finds the best way for parties to communicate.
SIP（Session Initiation Protocol，RFC 3261[2]）是一种基于文本的应用程序协议，它允许Internet上的端点相互发现，以便交换有关他们想要共享的会话的上下文信息。SIP建立的常见通信形式包括互联网电话、即时消息、视频、互联网游戏和其他实时通信形式。SIP是一种多业务协议，能够同时启动涉及不同形式实时通信的会话。SIP是一种为各方找到最佳通信方式的协议。
As defined in [1], the following is a template covering information needed for the registration of the enumservice specified in this document.
如[1]中所定义，以下模板涵盖了注册本文档中指定的enumservice所需的信息。
Enumservice Name: "E2U+SIP"
Enumservice名称：“E2U+SIP”
Type(s): "SIP"
类型：“SIP”
Subtype(s): N/A
Subtype(s): N/A
URI Scheme(s): "sip:", "sips:"
URI Scheme(s): "sip:", "sips:"
Functional Specification: see Section 4
功能规范：见第4节
Security considerations: see Section 6
安全注意事项：见第6节
Intended usage: COMMON
预期用途：普通
Author: Jon Peterson (jon.peterson@neustar.biz)
作者：Jon Peterson（Jon。peterson@neustar.biz)
Any other information that the author deems interesting: See Section 3
作者认为有趣的任何其他信息：见第3节
This document specifies an enumservice field that is appropriate for SIP addresses-of-record URIs. Various other types of URIs can be present in SIP requests. A URI that is associated with a particular SIP user agent (for example, a SIP phone) is commonly known as a SIP contact address.
本文档指定了适用于记录URI的SIP地址的enumservice字段。SIP请求中可以存在各种其他类型的URI。与特定SIP用户代理（例如，SIP电话）关联的URI通常称为SIP联系人地址。
The difference between a contact address and an address-of-record is like the difference between a device and its user. While there is no formal distinction in the syntax of these two forms of addresses, contact addresses are associated with a particular device, and may have a very device-specific form (like sip:10.0.0.1, or sip:edgar@ua21.example.com). An address-of-record, however, represents an identity of the user, generally a long-term identity, and it does not have a dependency on any device; users can move between devices or even be associated with multiple devices at one time while retaining the same address-of-record. A simple URI, generally of the form 'sip:egdar@example.com', is used for an address-of-record.
联系地址和记录地址之间的差异就像设备和用户之间的差异一样。虽然这两种形式的地址的语法没有正式的区别，但联系人地址与特定的设备相关联，并且可能具有特定于设备的形式（如sip:10.0.0.1或sip:edgar@ua21.example.com). 然而，记录地址表示用户的身份，通常是长期身份，并且它不依赖于任何设备；用户可以在设备之间移动，甚至一次与多个设备关联，同时保留相同的记录地址。一个简单的URI，通常采用“sip:egdar@example.com，用于记录的地址。
When a SIP request is created by a user agent, it populates the address-of-record of its target in its To header field and (generally) Request-URI. The address-of-record of the user that is sending the request populates the From header field of the message; the contact address of the device from which the request is sent is listed in the Contact header field.
当用户代理创建SIP请求时，它会在其To头字段和（通常）请求URI中填充其目标的记录地址。发送请求的用户的记录地址填充消息的From头字段；联系人标头字段中列出了发送请求的设备的联系人地址。
By sending a registration to a registrar on behalf of its user, a SIP device (i.e., a user agent) can temporarily associate its own contact address with the user's address-of-record. In so doing, the device becomes eligible to receive requests that are sent to the address-of-record. Upon receiving the registration request, the registrar modifies the provisioning data in a SIP location service to create a mapping between the address-of-record for the user and the device where the user can currently be reached. When future requests arrive at the administrative domain of this location service for the user in question, proxy servers ask the location service where to find the user, and will in turn discover the registered contact address(es). A SIP-based follow-me telephony service, for example, would rely on this real-time availability data in order to find the best place to reach the end user without having to cycle through numerous devices from which the user is not currently registered. Note that addresses-of-record can be registered with other addresses-of-record; for example, while at home, a user might elect to register the address-of-record they use as their personal identity under their
通过代表其用户向注册器发送注册，SIP设备（即，用户代理）可以临时将其自己的联系地址与用户的记录地址相关联。这样，设备就有资格接收发送到记录地址的请求。在接收到注册请求时，注册器修改SIP位置服务中的供应数据，以创建用户的记录地址与当前可到达用户的设备之间的映射。当将来的请求到达相关用户的此位置服务的管理域时，代理服务器会询问位置服务在何处查找用户，并反过来查找已注册的联系人地址。例如，基于SIP的follow-me电话服务将依赖于此实时可用性数据，以便找到与最终用户联系的最佳位置，而不必在用户当前未注册的众多设备之间循环。请注意，记录地址可以与其他记录地址一起注册；例如，当用户在家时，可能会选择将其用作个人身份的记录地址注册到其
work address-of-record in order to direct requests for their work identity to whatever devices they might have associated with their home address-of-record.
记录的工作地址，以便将对其工作身份的请求定向到他们可能与记录的家庭地址相关联的任何设备。
When a SIP entity (be it a user agent or proxy server) needs to make a forwarding decision for a Request-URI containing an address-of-record, it uses the mechanisms described in the SIP specification (RFC 3263) to locate the proper resource in the network. Ordinarily, this entails resolving the domain portion of the URI (example.com in the example above) in order to route the call to a proxy server that is responsible for that domain.
当SIP实体（无论是用户代理还是代理服务器）需要对包含记录地址的请求URI做出转发决策时，它使用SIP规范（RFC 3263）中描述的机制来定位网络中的适当资源。通常，这需要解析URI的域部分（上面示例中的example.com），以便将调用路由到负责该域的代理服务器。
SIP user agents have specific communications capabilities (such as the ability to initiate voice communications with particular codecs, or support for particular SIP protocol extensions). Because an address-of-record does not represent any particular device or set of devices, an address-of-record does not have capabilities as such. When a SIP user agent sends a request to an address-of-record, it begins a phase of capability negotiation that will eventually discover the best way for the originator to communicate with the target. The originating user agent first expresses capabilities of its own in the request it sends (and preferences for the type of session it would like to initiate). The expression of these capabilities may entail the usage of SDP [8] to list acceptable types of media supported and favored by the client, the inclusion of Required/Supported headers to negotiate compatibility of extensions, and possibly the usage of optional SIP extensions, for example using callee capabilities [7] to communicate request handling dispositions. Proxy servers or endpoints subsequently return responses that allow a rich bidirectional capability negotiation process.
SIP用户代理具有特定的通信功能（例如，能够使用特定编解码器启动语音通信，或支持特定的SIP协议扩展）。由于记录地址不代表任何特定的设备或设备集，因此记录地址本身不具有这种功能。当SIP用户代理向记录地址发送请求时，它将开始一个能力协商阶段，该阶段将最终发现发起人与目标通信的最佳方式。发起用户代理首先在其发送的请求中表达其自身的功能（以及它想要发起的会话类型的首选项）。这些功能的表达可能需要使用SDP[8]来列出客户端支持和喜爱的可接受类型的媒体，包括协商扩展兼容性所需/支持的头，以及可能使用可选的SIP扩展，例如使用被叫方功能[7]传达请求处理的部署。代理服务器或端点随后返回允许丰富的双向功能协商过程的响应。
The process by which SIP endpoints negotiate capabilities can overlap with the primary service provided by NAPTR records: permitting the originating client to select a particular URI for communications based on an ordered list of enumservices. However, ENUM's capability management mechanism is decidedly one-way - the administrator of the telephone number expresses capabilities (in the form of protocol names) and preferences that the client must evaluate without negotiation. Moreover, listing available protocols is not comparable to agreement on session media (down to the codec/interval level) and protocol extension support - it would be difficult to express, in the level of detail necessary to arrange a desired session, the capabilities of a SIP device within a NAPTR service field. Provisioning contact addresses in ENUM rather than addresses-of-record would compromise the SIP capability negotiation and discovery process. Much of the benefit of using a URI comes from the fact that
SIP端点协商功能的过程可以与NAPTR记录提供的主服务重叠：允许发起客户端根据服务的有序列表选择通信的特定URI。然而，ENUM的能力管理机制显然是单向的——电话号码的管理员表示能力（以协议名称的形式）和首选项，客户端必须在不进行协商的情况下进行评估。此外，列出可用的协议与会话媒体协议（下至编解码器/间隔级别）和协议扩展支持不可比-很难在安排所需会话所需的详细级别上表示NAPTR服务字段中SIP设备的能力。在ENUM中设置联系人地址而不是记录地址会影响SIP功能协商和发现过程。使用URI的大部分好处来自以下事实
it represents a logical service associated with a user, rather than a device - indeed, if ENUM wished to target particular devices, 'E2IPv4' would be a more appropriate resolution service to define than 'E2U'.
它表示与用户关联的逻辑服务，而不是与设备关联的逻辑服务——事实上，如果ENUM希望以特定设备为目标，那么“E2IPv4”将是比“E2U”更适合定义的解析服务。
SIP addresses-of-record may use the SIP URI scheme or the SIPS URI scheme. The SIPS URI scheme, when used in an address-of-record, indicates that the user it represents can only be reached over a secure connection (using TLS).
记录的SIP地址可以使用SIP URI方案或SIPS URI方案。当在记录地址中使用SIPS URI方案时，表示只能通过安全连接（使用TLS）联系到它所代表的用户。
Traditionally, the services field of a NAPTR record (as defined in [5]) contains a string that is composed of two subfields: a 'protocol' subfield and a 'resolution service' subfield. ENUM in particular defines an 'E2U' (E.164 to URI) resolution service. This document defines an 'E2U+SIP' enumservice for SIP.
传统上，NAPTR记录的服务字段（如[5]中所定义）包含由两个子字段组成的字符串：“协议”子字段和“解析服务”子字段。ENUM特别定义了一个“E2U”（E.164到URI）解析服务。本文档为SIP定义了“E2U+SIP”枚举服务。
The scheme of the URI that will appear in the regexp field of a NAPTR record using the 'E2U+SIP' enumservice may either be 'SIP' or 'SIPS'. This enumservice is best suited to SIP addresses-of-record.
使用“E2U+SIP”枚举服务将出现在NAPTR记录的regexp字段中的URI方案可以是“SIP”或“SIPS”。此枚举服务最适合记录的SIP地址。
When a SIP address-of-record appears in the regexp field of a NAPTR record, there is no need to further qualify the enumservice field with any capability data, since addresses-of-record do not have capabilities.
当记录的SIP地址出现在NAPTR记录的regexp字段中时，无需使用任何功能数据进一步限定enumservice字段，因为记录的地址没有功能。
There is also generally no need to have more than one NAPTR record under a single telephone number that points to a SIP address-of-record.
在指向SIP记录地址的单个电话号码下，通常也不需要有多个NAPTR记录。
Note that the user portion of a SIP URI may contain a telephone number (e.g., 'sip:+1442079460148@example.com'). Clients should be careful to avoid infinite loops when recursively performing ENUM queries on URIs that result from an ENUM lookup.
注意，SIP URI的用户部分可以包含电话号码（例如，“SIP:+1442079460148@example.com'). 当对枚举查找产生的URI递归执行枚举查询时，客户端应小心避免无限循环。
The following is an example of the use of the enumservice registered by this document in a NAPTR resource record.
下面是在NAPTR资源记录中使用此文档注册的enumservice的示例。
$ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:edgar@example.com!" .
$ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa。在NAPTR 10 100“u”E2U+sip“！^.*$！sip中：edgar@example.com!" .
A SIP address-of-record is a canonical address by which a user is known - placing this address in ENUM is comparable to placing an email address or a similar URI in the DNS.
SIP记录地址是一个已知用户的规范地址-将此地址放在ENUM中与将电子邮件地址或类似URI放在DNS中相当。
DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public - which is a cause for some privacy considerations.
DNS不会对其与查询者共享的记录做出策略决定。必须假设所有DNS记录在任何时候都可供所有查询者使用。因此，必须将枚举记录集中提供的信息视为对公众开放，这是出于某些隐私考虑的原因。
Unlike a traditional telephone number, the resource identified by a SIP URI may require that callers provide cryptographic credentials for authentication and authorization before a user is alerted. In this respect, ENUM in concert with SIP can actually provide far greater protection from unwanted callers than the existing PSTN, despite the public availability of ENUM records. An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC [9] to these, is provided in [1].
与传统电话号码不同，SIPURI标识的资源可能要求呼叫者在向用户发出警报之前提供用于身份验证和授权的加密凭据。在这方面，尽管ENUM记录可以公开使用，但与SIP配合使用的ENUM实际上可以提供比现有PSTN更大的保护，以防止不需要的呼叫者。[1]中提供了对ENUM依赖DNS的特定威胁的分析，以及DNSSEC[9]对这些威胁的适用性。
This document registers the 'E2U+SIP' enumservice under the enumservice registry described in the IANA considerations in RFC 3761. Details of the registration are given in Section 2.
本文档在RFC 3761中IANA注意事项中描述的enumservice注册表下注册“E2U+SIP”enumservice。注册详情见第2节。
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年5月。
[3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[3] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[5] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[6] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[6] Faltstrom，P.，“E.164号码和域名系统”，RFC 29162000年9月。
[7] Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", Work in Progress.
[7] Rosenberg，J.，Schulzrinne，H.和P.Kyzviat，“指出会话启动协议（SIP）中的用户代理功能”，正在进行中。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[9] R. Arends, et al., "Protocol Modifications for the DNS Security Extensions", Work in Progress.
[9] R.Arends等人，“DNS安全扩展的协议修改”，正在进行中。
Thanks to Richard Shockey for comments on the initial draft of this document, and to Allison Mankin for valuable review comments.
感谢Richard Shockey对本文件初稿提出的意见，以及Allison Mankin提出的宝贵审查意见。
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。