Internet Engineering Task Force (IETF) C. Jennings
Request for Comments: 7904 Cisco
Category: Standards Track B. Lowekamp
ISSN: 2070-1721 Skype
E. Rescorla
RTFM, Inc.
S. Baset
IBM
H. Schulzrinne
Columbia University
T. Schmidt, Ed.
HAW Hamburg
October 2016
Internet Engineering Task Force (IETF) C. Jennings
Request for Comments: 7904 Cisco
Category: Standards Track B. Lowekamp
ISSN: 2070-1721 Skype
E. Rescorla
RTFM, Inc.
S. Baset
IBM
H. Schulzrinne
Columbia University
T. Schmidt, Ed.
HAW Hamburg
October 2016
A SIP Usage for REsource LOcation And Discovery (RELOAD)
资源定位和发现的SIP使用（重新加载）
Abstract
摘要
This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged.
本文档定义了资源定位和发现（重新加载）的SIP用法。SIP使用在完全分布式系统中提供SIP代理或注册器的功能，并包括覆盖中存储的记录地址（AOR）的查找服务。它还定义了全局可路由用户代理URI（GROUS），允许注册将AOR映射到可通过覆盖访问的特定节点。在对等方的这种初始接触之后，重新加载AppAttach方法用于在节点之间建立直接连接，通过该连接交换SIP消息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7904.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7904.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 7
3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 9
3.4. Overlay Configuration Document Extension . . . . . . . . 10
4. Looking Up an AOR . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 11
4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . 12
5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 12
5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 12
5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 13
6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . 14
8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 15
8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 15
8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 15
8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15
8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16
9.2. XML Namespace Registration . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Third-Party Registration . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 6
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 7
3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 9
3.4. Overlay Configuration Document Extension . . . . . . . . 10
4. Looking Up an AOR . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 11
4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . 12
5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 12
5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 12
5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 13
6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . 14
8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 15
8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 15
8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 15
8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15
8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 16
9.2. XML Namespace Registration . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Third-Party Registration . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines a SIP Usage of RELOAD that allows SIP [RFC3261] user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions without the requirement for a permanent proxy or registration servers, e.g., a fully distributed telephony service. This service transparently supports SIP addressing including telephone numbers. In such a network, the RELOAD overlay itself performs the registration and rendezvous functions ordinarily associated with such servers.
资源定位和发现（重新加载）[RFC6940]指定了一种在Internet上通用的对等（P2P）信令协议。本文档定义了重新加载的SIP用法，该用法允许SIP[RFC3261]用户代理（UAs）建立对等SIP（或SIPS）会话，而无需永久代理或注册服务器，例如完全分布式电话服务。此服务透明地支持SIP寻址，包括电话号码。在这样的网络中，重新加载覆盖本身执行通常与此类服务器相关联的注册和会合功能。
The SIP Usage involves two basic functions:
SIP使用涉及两个基本功能：
Registration: SIP UAs can use the RELOAD data storage functionality to store a mapping from their Address of Record (AOR) to their Node-ID in the overlay and to retrieve the Node-ID of other UAs.
注册：SIP UAs可以使用重新加载数据存储功能在覆盖中存储从其记录地址（AOR）到其节点ID的映射，并检索其他UAs的节点ID。
Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it wishes to call, it can use the RELOAD message routing system to set up a direct connection for exchanging SIP messages.
会合：一旦SIP UA识别出它希望调用的AOR的节点ID，它就可以使用重新加载消息路由系统建立直接连接以交换SIP消息。
Mappings are stored in the SipRegistration Resource Record defined in this document. All operations required to perform a SIP registration or rendezvous are standard RELOAD protocol methods.
映射存储在本文档中定义的SipRegistration资源记录中。执行SIP注册或会合所需的所有操作都是标准的重新加载协议方法。
For example, Bob registers his AOR, "bob@dht.example.com", for his Node-ID "1234". When Alice wants to call Bob, she queries the overlay for "bob@dht.example.com" and receives Node-ID "1234" in return. She then uses the overlay routing to establish a direct connection with Bob and can directly transmit a standard SIP INVITE. In detail, this works along the following steps:
例如，Bob注册了他的AOR，“bob@dht.example.com，用于其节点ID“1234”。当Alice想打电话给Bob时，她询问覆盖图中是否有“bob@dht.example.com并接收节点ID“1234”作为回报。然后，她使用覆盖路由与Bob建立直接连接，并可以直接发送标准SIP INVITE。具体而言，这将按照以下步骤进行：
1. Bob, operating Node-ID "1234", stores a mapping from his AOR to his Node-ID in the overlay by applying a Store request for "bob@dht.example.com -> 1234".
1. 操作节点ID为“1234”的Bob通过应用“1234”的存储请求，在覆盖中存储从其AOR到其节点ID的映射bob@dht.example.com -> 1234".
2. Alice, operating Node-ID "5678", decides to call Bob. She retrieves Node-ID "1234" by performing a Fetch request on "bob@dht.example.com".
2. 操作节点ID为“5678”的Alice决定给Bob打电话。她通过对执行提取请求来检索节点ID“1234”bob@dht.example.com".
3. Alice uses the overlay to route an AppAttach message to Bob's Peer (ID "1234"). Bob responds with his own AppAttach and they set up a direct connection, as shown in Figure 1. Note that mutual Interactive Connectivity Establishment (ICE) checks are invoked automatically from the AppAttach message exchange.
3. Alice使用覆盖将AppAttach消息路由到Bob的对等方（ID“1234”）。Bob使用自己的AppAttach进行响应，他们建立了直接连接，如图1所示。请注意，交互连接建立（ICE）检查是从AppAttach消息交换自动调用的。
Overlay
Alice Peer1 ... PeerN Bob
(5678) (1234)
-------------------------------------------------
AppAttach ->
AppAttach ->
AppAttach ->
AppAttach ->
<- AppAttach
<- AppAttach
<- AppAttach
<- AppAttach
Overlay
Alice Peer1 ... PeerN Bob
(5678) (1234)
-------------------------------------------------
AppAttach ->
AppAttach ->
AppAttach ->
AppAttach ->
<- AppAttach
<- AppAttach
<- AppAttach
<- AppAttach
<------------------ ICE Checks ----------------->
INVITE ----------------------------------------->
<--------------------------------------------- OK
ACK -------------------------------------------->
<------------ ICE Checks for media ------------->
<-------------------- RTP ---------------------->
<------------------ ICE Checks ----------------->
INVITE ----------------------------------------->
<--------------------------------------------- OK
ACK -------------------------------------------->
<------------ ICE Checks for media ------------->
<-------------------- RTP ---------------------->
Figure 1: Connection Setup in P2P SIP Using the RELOAD Overlay
图1：使用重新加载覆盖在P2P SIP中建立连接
It is important to note that the only role of RELOAD in this example is to set up the direct SIP connection between Alice and Bob. As soon as the ICE checks complete and the connection is established, ordinary SIP or SIPS is used. In particular, the establishment of the media channel for a phone call happens via the usual SIP mechanisms, and RELOAD is not involved. Media never traverses the overlay. After the successful exchange of SIP messages, communicating Peers run ICE connectivity checks for media.
需要注意的是，在本例中重新加载的唯一作用是在Alice和Bob之间建立直接SIP连接。ICE检查完成并建立连接后，立即使用普通SIP或SIP。特别是，通过通常的SIP机制建立电话呼叫的媒体通道，并且不涉及重新加载。媒体永远不会穿过覆盖层。成功交换SIP消息后，通信对等方对媒体运行ICE连接检查。
In addition to mappings from AORs to Node-IDs, the SIP Usage also allows mappings from AORs to other AORs. This enables an indirection useful for call forwarding. For instance, if Bob wants his phone calls temporarily forwarded to Charlie, he can store the mapping "bob@dht.example.com -> charlie@dht.example.com". When Alice wants to call Bob, she retrieves this mapping and can then fetch Charlie's AOR to retrieve his Node-ID. These mechanisms are described in Section 3.
除了从AOR映射到节点ID之外，SIP使用还允许从AOR映射到其他AOR。这将启用对呼叫转发有用的间接寻址。例如，如果Bob希望他的电话暂时转发给Charlie，他可以存储映射“bob@dht.example.com -> charlie@dht.example.com". 当Alice想要调用Bob时，她检索这个映射，然后可以获取Charlie的AOR来检索他的节点ID。这些机制在第3节中描述。
Alternatively, Globally Routable User Agent URIs (GRUUs) [RFC5627] can be used for directly accessing Peers. They are handled via a separate mechanism, as described in Section 6.
或者，可以使用全局可路由用户代理URI（GROUS）[RFC5627]直接访问对等方。如第6节所述，它们通过单独的机制进行处理。
Concepts used in this document can be extended to include tel URIs [RFC3966], but this will require further specifications to ensure semantic interoperability of implementations.
本文档中使用的概念可以扩展为包括tel-uri[RFC3966]，但这需要进一步的规范来确保实现的语义互操作性。
The SIP Usage for RELOAD addresses a fully distributed deployment of session-based services among overlay Peers. This RELOAD Usage may be relevant in a variety of environments, including a tightly controlled environment of a single provider that admits parties using AORs with domains from controlled namespace(s) only, or an open, multi-party infrastructure that liberally allows a registration and rendezvous for various or any domain namespace. It is noteworthy in this context that -- in contrast to regular SIP -- domain names play no role in routing to a proxy server. Once connectivity to an overlay is given, the technology allows any name registration, possibly constrained by overlay domain restrictions.
重新加载的SIP使用解决了覆盖对等点之间基于会话的服务的完全分布式部署。这种重新加载的使用可能与多种环境有关，包括单一提供者的严格控制环境，该环境允许仅使用来自受控命名空间的域的AOR的各方，或者开放的多方基础设施，该基础设施允许各种或任何域命名空间的注册和集合。在此上下文中值得注意的是，与常规SIP不同，域名在路由到代理服务器时不起任何作用。一旦连接到覆盖，该技术允许任何名称注册，可能受到覆盖域限制的约束。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
We use the terminology and definitions from "Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)" [RFC7890] and the RELOAD Base Protocol [RFC6940] extensively in this document.
我们在本文档中广泛使用了“对等SIP（P2PSIP）的概念和术语”[RFC7890]和重新加载基本协议[RFC6940]中的术语和定义。
In addition, terms defined by SIP [RFC3261] apply to this memo. The term AOR is the SIP "Address of Record" used to identify a user in SIP. For example, "alice@example.com" could be the AOR for Alice. For the purposes of this specification, an AOR is considered not to include the scheme (e.g., sip:), as the AOR needs to match the rfc822Name in the X.509 v3 certificates [RFC5280]. It is worth noting that SIP and SIPS are distinguished in P2PSIP by the Application-ID.
此外，SIP[RFC3261]定义的术语适用于本备忘录。术语AOR是用于在SIP中标识用户的SIP“记录地址”。例如，”alice@example.com“可能是爱丽丝的AOR。出于本规范的目的，AOR被认为不包括该方案（例如sip:），因为AOR需要匹配X.509 v3证书[RFC5280]中的RFC822名称。值得注意的是，SIP和SIP在P2PSIP中通过应用程序ID进行区分。
In ordinary SIP, a UA registers the user's AOR and its network location with a registrar. In RELOAD, this registrar function is provided by the overlay as a whole. To register its location, a RELOAD peer stores a SipRegistration Resource Record under its own AOR using the SIP-REGISTRATION Kind, which is formally defined in Section 7. Note that the registration lifetime known from the regular SIP REGISTER method is inherited from the lifetime attribute of the basic RELOAD StoredData structure (see Section 7 in [RFC6940]).
在普通SIP中，UA向注册器注册用户的AOR及其网络位置。在重新加载中，该注册器功能由覆盖作为一个整体提供。为了注册其位置，重载对等方使用第7节中正式定义的SIP-REGISTRATION类型在其自己的AOR下存储SipRegistration资源记录。请注意，常规SIP REGISTER方法中已知的注册生存期是从基本RELOAD StoredData结构的生存期属性继承的（请参阅[RFC6940]中的第7节）。
A RELOAD overlay MAY restrict the storage of AORs. Namespaces (i.e., the right-hand side of the AOR) that are supported for registration and lookup can be configured for each RELOAD deployment as described in Section 3.4.
重新加载覆盖可能会限制AOR的存储。支持注册和查找的名称空间（即AOR的右侧）可以按照第3.4节所述为每个重新加载部署进行配置。
As a simple example, consider Alice with an AOR "alice@dht.example.org" at Node-ID "1234". She might store the mapping "alice@dht.example.org -> 1234" telling anyone who wants to call her to contact node "1234".
作为一个简单的例子，用AOR考虑爱丽丝alice@dht.example.org在节点ID“1234”处。她可能会存储映射”alice@dht.example.org->1234“告诉任何想给她打电话的人联系节点“1234”。
RELOAD peers can store two kinds of SIP mappings,
重载对等方可以存储两种SIP映射，
o from an AOR to a destination list (a single Node-ID is just a trivial destination list), or
o 从AOR到目标列表（单个节点ID只是一个微不足道的目标列表），或者
o from one AOR to another.
o 从一个AOR到另一个AOR。
The meaning of the first kind of mapping is "in order to contact me, form a connection with this Peer." The meaning of the second kind of mapping is "in order to contact me, dereference this AOR". The latter allows for forwarding. For instance, if Alice wants her calls to be forwarded to her secretary, Sam, she might insert the following mapping, "alice@dht.example.org -> sam@dht.example.org".
第一种映射的含义是“为了联系我，与该对等方建立连接”。第二种映射的含义是“为了联系我，解除对该AOR的引用”。后者允许转发。例如，如果Alice希望将她的电话转发给她的秘书Sam，她可能会插入以下映射，“alice@dht.example.org -> sam@dht.example.org".
This section defines the SipRegistration Resource Record as follows:
本节对SipRegistration资源记录的定义如下：
enum {
sip_registration_uri(1),
sip_registration_route(2),
(255)
} SipRegistrationType;
enum {
sip_registration_uri(1),
sip_registration_route(2),
(255)
} SipRegistrationType;
select (SipRegistration.type) {
case sip_registration_uri:
opaque uri<0..2^16-1>;
select (SipRegistration.type) {
case sip_registration_uri:
opaque uri<0..2^16-1>;
case sip_registration_route:
opaque contact_prefs<0..2^16-1>;
Destination destination_list<3..2^16-1>;
case sip_registration_route:
opaque contact_prefs<0..2^16-1>;
Destination destination_list<3..2^16-1>;
/* This type can be extended */
/* This type can be extended */
} SipRegistrationData;
}SIP注册数据；
struct {
SipRegistrationType type;
uint16 length;
SipRegistrationData data;
} SipRegistration;
struct {
SipRegistrationType type;
uint16 length;
SipRegistrationData data;
} SipRegistration;
The contents of the SipRegistration Resource Record are:
SipRegistration资源记录的内容包括：
type
类型
the type of the registration
注册的类型
length
长
the length of the rest of the PDU
PDU其余部分的长度
data
数据
the registration data
注册数据
o If the registration is of type "sip_registration_uri", then the contents are an opaque string containing the AOR.
o 如果注册类型为“sip\u registration\u uri”，则内容是包含AOR的不透明字符串。
o If the registration is of type "sip_registration_route", then the contents are an opaque string containing the registrant's contact preferences and a destination list for the Peer.
o 如果注册类型为“sip_registration_route”，则内容为不透明字符串，其中包含注册人的联系人首选项和对等方的目的地列表。
The callee expresses its capabilities within the contact preferences as specified in [RFC3840]. It encodes a media feature set comprised of its capabilities as a contact predicate, i.e., a string of feature parameters that appear as part of the Contact header field. Feature parameters are derived from the media feature set syntax of [RFC2533] (see also [RFC2738]) as described in [RFC3840].
被调用方在[RFC3840]中指定的联系人首选项中表示其能力。它将由其功能组成的媒体功能集编码为联系人谓词，即显示为联系人标题字段一部分的一串功能参数。特征参数源自[RFC2533]（另请参见[RFC2738]）的媒体特征集语法，如[RFC3840]所述。
This encoding covers all SIP User Agent capabilities, as defined in [RFC3840] and registered in the SIP feature tag registration tree. In particular, a callee can indicate that it prefers contact via a particular SIP scheme -- SIP or SIPS -- by using one of the following contact_prefs attributes:
该编码涵盖了[RFC3840]中定义并在SIP功能标签注册树中注册的所有SIP用户代理功能。具体地说，被叫方可以通过使用以下contact_prefs属性之一来指示它更喜欢通过特定的SIP方案（SIP或SIPS）进行联系：
(sip.schemes=SIP) (sip.schemes=SIPS)
（sip.schemes=sip）（sip.schemes=SIPS）
RELOAD explicitly supports multiple registrations for a single AOR. The registrations are stored in a dictionary with Node-IDs as the dictionary keys. Consider, for instance, the case where Alice has two Peers:
重新加载显式支持单个AOR的多个注册。注册存储在一个字典中，其中节点ID作为字典键。例如，考虑爱丽丝有两个对等点的情况：
o her desk phone (1234)
o 她的办公桌电话（1234）
o her cell phone (5678)
o 她的手机（5678）
Alice might store the following in the overlay at resource "alice@dht.example.com":
Alice可能会在资源的覆盖中存储以下内容“alice@dht.example.com":
o a SipRegistration of type "sip_registration_route" with dictionary key "1234" and value "1234", both referring to Node-IDs
o 类型为“sip_registration_route”的SipRegistration，字典键为“1234”，值为“1234”，两者均指节点ID
o a SipRegistration of type "sip_registration_route" with dictionary key "5678" and value "5678"
o 具有字典键“5678”和值“5678”的类型为“sip_registration_route”的SipRegistration
Note that this structure explicitly allows one Node-ID to forward to another Node-ID. For instance, Alice could set calls to her desk phone to ring at her cell phone by storing a SipRegistration of type "sip_registration_route" with a dictionary key "1234" and a value "5678".
请注意，此结构明确允许一个节点ID转发到另一个节点ID。例如，Alice可以通过使用字典密钥“1234”和值“5678”存储类型为“sip_registration_route”的SipRegistration，将对其桌面电话的呼叫设置为在其手机上响铃。
In order to prevent hijacking or other misuse, registrations are subject to access control rules. Two kinds of restrictions apply:
为了防止劫持或其他滥用，注册必须遵守访问控制规则。适用两种限制：
o A Store is permitted only for AORs with domain names that fall into the namespaces supported by the RELOAD Overlay Instance.
o 只有域名属于重载覆盖实例支持的名称空间的AOR才允许使用存储。
o Storing requests are performed according to the USER-NODE-MATCH access control policy of RELOAD.
o 存储请求根据RELOAD的用户-节点-匹配访问控制策略执行。
Before issuing a Store request to the overlay, any Peer SHOULD verify that the AOR of the request is a valid Resource Name with respect to its domain name and the namespaces defined in the overlay configuration document (see Section 3.4).
在向覆盖层发出存储请求之前，任何对等方都应验证请求的AOR相对于其域名和覆盖层配置文档中定义的名称空间是有效的资源名称（参见第3.4节）。
Before a Store is permitted, the Storing Peer MUST check that:
在允许存储之前，存储对等方必须检查：
o The AOR of the request is a valid Resource Name with respect to the namespaces defined in the overlay configuration document.
o 请求的AOR是相对于覆盖配置文档中定义的名称空间的有效资源名称。
o The certificate contains a username that is a SIP AOR that hashes to the Resource-ID it is being stored at.
o 该证书包含一个用户名，该用户名是一个SIP AOR，它散列到它所存储的资源ID。
o The certificate contains a Node-ID that is the same as the dictionary key it is being stored at.
o 该证书包含一个节点ID，该ID与存储该证书的字典密钥相同。
If any of these checks fail, the request MUST be rejected with an Error_Forbidden error.
如果这些检查中的任何一个失败，请求必须被拒绝，并出现错误。
Note that these rules permit Alice to forward calls to Bob without his permission. However, they do not permit Alice to forward Bob's calls to her. See Section 8.2.2 for additional details.
注意，这些规则允许Alice在未经Bob允许的情况下将呼叫转发给Bob。然而，他们不允许爱丽丝把鲍勃的电话转给她。更多详情见第8.2.2节。
The use of a SIP-enabled overlay MAY be restricted to users with AORs from specific domains. When deploying an overlay service, providers can implement such restrictions by defining a set of namespaces for admissible domain names. This section extends the overlay configuration document by defining new elements for patterns that describe a corresponding domain name syntax.
启用SIP的覆盖的使用可能仅限于具有特定域的AOR的用户。在部署覆盖服务时，提供者可以通过为允许的域名定义一组名称空间来实现此类限制。本节通过为描述相应域名语法的模式定义新元素来扩展覆盖配置文档。
A RELOAD overlay can be configured to accept store requests for any AOR, or to apply domain name restrictions. To apply restrictions, the overlay configuration document needs to contain a <domain-restrictions> element. The <domain-restrictions> element serves as a container for zero to multiple <pattern> sub-elements. A <pattern> element MAY be present if the "enable" attribute of its parent element is set to true. Each <pattern> element defines a pattern for constructing admissible resource names. It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]). Encoding of the domain name adheres to the restricted ASCII character set without character escaping as defined in Section 19.1 of [RFC3261].
可以将重新加载覆盖配置为接受任何AOR的存储请求，或应用域名限制。要应用限制，覆盖配置文档需要包含<domain restrictions>元素。<domain restrictions>元素用作零到多个子元素的容器。如果父元素的“enable”属性设置为true，则可能存在<pattern>元素。每个<pattern>元素定义一个用于构造可接受资源名称的模式。它是xsd:string类型，根据“POSIX扩展正则表达式”（参见[IEEE POSIX]中的规范）解释为正则表达式。域名编码遵循[RFC3261]第19.1节中定义的受限ASCII字符集，无字符转义。
Inclusion of a <domain-restrictions> element in an overlay configuration document is OPTIONAL. If the element is not included, the default behavior is to accept any AOR. If the element is included and the "enable" attribute is not set or set to false, the overlay MUST only accept AORs that match the domain name of the overlay. If the element is included and the "enable" attribute is set to true, the overlay MUST only accept AORs that match patterns specified in the <domain-restrictions> element.
在覆盖配置文档中包含<domain restrictions>元素是可选的。如果未包含该元素，则默认行为是接受任何AOR。如果包含元素且“enable”属性未设置或设置为false，则覆盖必须仅接受与覆盖域名匹配的AOR。如果包含元素且“enable”属性设置为true，则覆盖必须仅接受与<domain restrictions>元素中指定的模式匹配的AOR。
Example of Domain Patterns: dht\.example\.com .*\.my\.example
域模式示例：dht\.Example\.com.*\.my\.Example
In this example, any AOR will be accepted that is either of the form <user>@dht.example.com, or ends with the domain "my.example".
在本例中，任何形式为<user>@dht.example.com或以域“my.example”结尾的AOR都将被接受。
The RELAX NG grammar for the AOR Domain Restriction reads:
AOR域限制的RELAX NG语法如下：
# AOR DOMAIN RESTRICTION URN SUB-NAMESPACE
#AOR域限制URN子命名空间
namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip"
namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip"
# AOR DOMAIN RESTRICTION ELEMENT
#AOR域限制元素
Kind-parameter &= element sip:domain-restriction {
Kind-parameter &= element sip:domain-restriction {
attribute enable { xsd:boolean }
attribute enable { xsd:boolean }
# PATTERN ELEMENT
#模式元素
element sip:pattern { xsd:string }*
}?
element sip:pattern { xsd:string }*
}?
A RELOAD user, member of an overlay, who wishes to call another user with a given AOR SHALL proceed in the following way:
重新加载用户（覆盖层成员）希望使用给定AOR呼叫另一用户时，应按以下方式进行：
AOR is a GRUU? If the AOR is a GRUU for this overlay, the callee can be contacted directly as described in Section 6.
AOR是一个GRUU？如果AOR是该覆盖的GRUU，则可以按照第6节所述直接联系被叫方。
AOR domain is hosted in overlay? If the domain part of the AOR matches a domain pattern configured in the overlay, the user can continue to resolve the AOR in this overlay. The user MAY choose to query the DNS service records to search for additional support of this domain name.
AOR域是否托管在覆盖中？如果AOR的域部分与覆盖中配置的域模式匹配，则用户可以继续在此覆盖中解析AOR。用户可以选择查询DNS服务记录以搜索对此域名的其他支持。
AOR domain not supported by overlay? If the domain part of the AOR is not supported in the current overlay, the user might query the DNS (or other discovery services at hand) to search for an alternative overlay that services the AOR under request. Alternatively, standard SIP procedures for contacting the callee might be used.
覆盖不支持AOR域？如果当前覆盖不支持AOR的域部分，则用户可能会查询DNS（或手头的其他发现服务），以搜索为请求中的AOR提供服务的替代覆盖。或者，可以使用用于联系被叫方的标准SIP程序。
AOR inaccessible? If all of the above contact attempts fail, the call fails.
AOR无法访问？如果上述所有联系尝试均失败，则呼叫失败。
The procedures described above likewise apply when nodes are simultaneously connected to several overlays.
当节点同时连接到多个覆盖层时，上述步骤同样适用。
A RELOAD user that has discovered a route to an AOR in the current overlay SHALL execute the following steps:
在当前覆盖中发现AOR路由的重新加载用户应执行以下步骤：
1. Perform a Fetch for Kind SIP-REGISTRATION at the Resource-ID corresponding to the AOR. This Fetch SHOULD NOT indicate any dictionary keys, so that it will fetch all the stored values.
1. 在与AOR对应的资源ID处执行种类SIP-REGISTRATION的获取。此获取不应指示任何字典键，因此它将获取所有存储的值。
2. If any of the results of the Fetch are non-GRUU AORs, then repeat step 1 for that AOR.
2. 如果提取的任何结果是非GROU AOR，则对该AOR重复步骤1。
3. Once only GRUUs and destination lists remain, the Peer removes duplicate destination lists and GRUUs from the list and initiates SIP or SIPS connections to the appropriate Peers as described in the following sections. If there are also external AORs, the Peer follows the appropriate procedure for contacting them as well.
3. 一旦仅保留GRUS和目的地列表，对等方将从列表中删除重复的目的地列表和GRUS，并启动到适当对等方的SIP或SIPS连接，如以下部分所述。如果还存在外部AOR，对等方也会遵循适当的程序与它们联系。
Once the Peer has translated the AOR into a set of destination lists, it then uses the overlay to route AppAttach messages to each of those Peers. The "application" field MUST be either 5060 to indicate SIP or 5061 to indicate SIPS. If certificate-based authentication is in use, the responding Peer MUST present a certificate with a Node-ID matching the terminal entry in the destination list. Otherwise, the connection MUST NOT be used and MUST be closed. Note that it is possible that the Peers already have a RELOAD connection mutually established. This MUST NOT be used for SIP messages unless it is a SIP connection. A previously established SIP connection MAY be used for a new call.
一旦对等方将AOR转换为一组目的地列表，它就会使用覆盖将AppAttach消息路由到每个对等方。“应用”字段必须是5060以表示SIP或5061以表示SIP。如果使用基于证书的身份验证，则响应的对等方必须提供一个节点ID与目标列表中的终端条目匹配的证书。否则，不得使用连接，必须关闭连接。请注意，对等方可能已经相互建立了重新加载连接。除非是SIP连接，否则不得将其用于SIP消息。先前建立的SIP连接可用于新呼叫。
Once the AppAttach succeeds, the Peer sends plain or (D)TLS-encrypted SIP messages over the connection as in normal SIP. A caller MAY choose to contact the callee using SIP or SIPS, but SHOULD follow a preference indicated by the callee in its contact_prefs attribute (see Section 3.2). A callee MAY choose to listen on both SIP and SIPS ports and accept calls from either SIP scheme, or select a single one. However, a callee that decides to accept SIPS calls only, SHOULD indicate its choice by setting the corresponding attribute in its contact_prefs. It is noteworthy that, according to [RFC6940], all overlay links are built on (D)TLS-secured transport.
一旦AppAttach成功，对等方将通过连接发送普通或（D）TLS加密的SIP消息，与正常SIP中的一样。呼叫者可以选择使用SIP或SIPS与被呼叫者联系，但应遵循被呼叫者在其contact_prefs属性中指示的首选项（参见第3.2节）。被叫方可以选择在SIP和SIPS端口上侦听，并接受来自任一SIP方案的呼叫，或者选择单个SIP方案。但是，决定只接受SIPS呼叫的被叫方应通过在其contact_prefs中设置相应属性来指示其选择。值得注意的是，根据[RFC6940]，所有覆盖链路都建立在（D）TLS安全传输上。
SIP messages carry the SIP URIs of actual overlay endpoints (e.g., "sip:alice@dht.example.com") in the Via and Contact headers, while the communication continues via the RELOAD connection. However, a UA can redirect its communication path by setting an alternate Contact header field like in ordinary SIP.
SIP消息携带实际覆盖端点的SIP URI（例如，“SIP:alice@dht.example.com），而通过重新加载连接继续通信。然而，UA可以通过设置与普通SIP类似的备用联系人报头字段来重定向其通信路径。
In many cases, RELOAD connections established from ICE [RFC5245] negotiations will traverse stateful NATs and firewalls. It is the responsibility of the Peers to send messages with a frequency sufficient to maintain the necessary state in these NATs and firewalls and thus keep the connection alive. Keepalives are a mandatory component of ICE (see Section 10 of [RFC5245]) and no further operations are required. Applications that want to assure maintenance of sessions individually need to follow regular SIP means. Accordingly, a SIP Peer MAY apply keep-alive techniques in agreement with its transport binding as defined in Section 3.5 of [RFC5626].
在许多情况下，通过ICE[RFC5245]协商建立的重新加载连接将穿越有状态NAT和防火墙。对等方负责以足够的频率发送消息，以保持这些NAT和防火墙中的必要状态，从而保持连接的活动性。Keepalives是ICE的强制性组件（见[RFC5245]第10节），无需进一步操作。希望确保会话单独维护的应用程序需要遵循常规SIP方法。相应地，SIP对等方可在符合[RFC5626]第3.5节中定义的传输绑定的情况下应用保持活动技术。
Globally Routable User Agent URIs (GRUUs) [RFC5627] have been designed to allow direct routing to a specific UA instance without the need for dereferencing by a domain-specific SIP proxy function. The concept is transferred to RELOAD overlays as follows. GRUUs in RELOAD are constructed by embedding a base64-encoded destination list in the "gr" URI parameter of the GRUU. The base64 encoding is done with the alphabet specified in Table 1 of [RFC4648] with the exception that "~" is used in place of "=".
全局可路由用户代理URI（GROUS）[RFC5627]的设计允许直接路由到特定UA实例，而无需通过特定于域的SIP代理功能解除引用。该概念转移到重新加载覆盖层，如下所示。重载中的GRUs是通过在GRUU的“gr”URI参数中嵌入base64编码的目标列表来构造的。base64编码使用[RFC4648]表1中指定的字母表完成，但使用“~”代替“=”除外。
Example of a RELOAD GRUU:
alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~
Example of a RELOAD GRUU:
alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~
GRUUs do not require storing data in the Overlay Instance. Rather, when a Peer needs to route a message to a GRUU in the same P2P overlay, it simply uses the destination list and connects to that Peer. Because a GRUU contains a destination list, it can have the same contents as a destination list stored elsewhere in the resource dictionary.
GRUUs不需要在覆盖实例中存储数据。相反，当对等方需要将消息路由到同一P2P覆盖中的GRUU时，它只需使用目的地列表并连接到该对等方。因为GRUU包含目标列表，所以它可以具有与存储在资源字典中其他位置的目标列表相同的内容。
Anonymous GRUUs [RFC5767] are constructed analogously, but require either that the enrollment server issues a different Node-ID for each anonymous GRUU required, or that a destination list be used that includes a Peer that compresses the destination list to stop the Node-ID from being revealed.
匿名Gru[RFC5767]的构造与此类似，但要求注册服务器为每个所需的匿名Gru颁发不同的节点ID，或者使用目标列表，其中包括压缩目标列表以阻止节点ID被显示的对等方。
This section defines the SIP-REGISTRATION Kind.
本节定义了SIP注册类型。
Name: SIP-REGISTRATION
名称：SIP-REGISTRATION
Kind IDs: The Resource Name for the SIP-REGISTRATION Kind-ID is the AOR of the user as specified in Section 2. The data stored is a SipRegistration, which can contain either another URI or a destination list to the Peer that is acting for the user.
种类ID：SIP-REGISTRATION种类ID的资源名称是第2节中指定的用户的AOR。存储的数据是SipRegistration，它可以包含另一个URI或为用户代理的对等方的目标列表。
Data Model: The data model for the SIP-REGISTRATION Kind-ID is a dictionary. The dictionary key is the Node-ID of the Storing Peer. This allows each Peer (presumably corresponding to a single device) to store a single route mapping.
数据模型：SIP-REGISTRATION种类ID的数据模型是一个字典。字典键是存储对等节点的节点ID。这允许每个对等方（可能对应于单个设备）存储单个路由映射。
Access Control: USER-NODE-MATCH. Note that this matches the SIP AOR against the rfc822Name in the X.509 v3 certificate. The rfc822Name does not include the scheme so that the "sip:" prefix needs to be removed from the SIP AOR before matching. Escaped characters ('%' encoding) in the SIP AOR also need to be decoded prior to matching (see [RFC3986]).
访问控制：USER-NODE-MATCH。注意，这与X.509 v3证书中的RFC822名称匹配SIP AOR。RFC822名称不包括该方案，因此在匹配之前需要从sip AOR中删除“sip:”前缀。SIP AOR中的转义字符（“%”编码）也需要在匹配之前进行解码（请参阅[RFC3986]）。
Data stored under the SIP-REGISTRATION Kind is of type SipRegistration, containing one of two data types:
SIP-REGISTRATION类型下存储的数据为SipRegistration类型，包含以下两种数据类型之一：
sip_registration_uri
sip\u注册\u uri
A URI that the user can be reached at.
用户可以访问的URI。
sip_registration_route
sip_注册_路线
A destination list that can be used to reach the user's Peer.
可用于到达用户对等方的目的地列表。
This Usage for RELOAD does not define new protocol elements or operations. Hence, no new threats arrive from message exchanges in RELOAD.
重新加载的这种用法不定义新的协议元素或操作。因此，在重新加载中，没有来自消息交换的新威胁。
This document introduces an AOR domain restriction function that must be compared against the registration attempt by the Storing Peer. A misconfigured or malicious Peer could cause frequent rejects of illegitimate storing requests. However, domain name control relies on a lightweight pattern matching and can be processed prior to
本文档介绍了一个AOR域限制函数，该函数必须与存储对等方的注册尝试进行比较。配置错误或恶意的对等方可能导致频繁拒绝非法存储请求。然而，域名控制依赖于轻量级模式匹配，可以在
validating certificates. Hence, no extra burden is introduced for RELOAD peers beyond loads already present in the base protocol.
正在验证证书。因此，在基本协议中已经存在的负载之外，不会为重新加载对等点引入额外的负担。
Because SIP includes a forking capability (the ability to retarget to multiple recipients), fork bombs (i.e., attacks using SIP forking to amplify the effect on the intended victims) are a potential DoS concern. However, in the SIP Usage of RELOAD, fork bombs are a much lower concern than in a conventional SIP Proxy infrastructure, because the calling party is involved in each retargeting event. It can therefore directly measure the number of forks and throttle at some reasonable number.
由于SIP包括分叉功能（重定目标到多个接收者的能力），分叉炸弹（即使用SIP分叉放大对目标受害者的影响的攻击）是一个潜在的DoS问题。然而，与传统的SIP代理基础设施相比，在重新加载的SIP使用中，叉炸弹的关注度要低得多，因为调用方参与了每个重定目标事件。因此，它可以直接测量一些合理数量的叉子和油门的数量。
To launch a DoS attack, the owner of a popular AOR could retarget all calls to the victim. This attack is common to SIP and is difficult to ameliorate without requiring the target of a SIP registration to authorize all stores. The overhead of that requirement would be excessive and, in addition, there are good use cases for retargeting to a Peer without its explicit cooperation.
要发起DoS攻击，流行AOR的所有者可以将所有呼叫重新定位到受害者。这种攻击在SIP中很常见，如果不要求SIP注册的目标授权所有存储，则很难改进。该需求的开销将是过大的，此外，在没有明确合作的情况下，有很好的重新定位到对等方的用例。
A RELOAD overlay and enrollment service that liberally accepts registrations for AORs of domain names unrelated to the overlay instance and without further authorization could store presence state for AORs without the consent of the owner of the AOR. An attacker could hijack names, register a bogus presence, and attract calls dedicated to a victim that resides within or outside the Overlay Instance.
重新加载覆盖和注册服务自由地接受与覆盖实例无关的域名的AOR注册，而无需进一步授权，可以在未经AOR所有者同意的情况下存储AOR的存在状态。攻击者可以劫持姓名，注册虚假存在，并吸引专门针对覆盖实例内外的受害者的呼叫。
A hijacking of AORs can be mitigated by restricting the name spaces admissible in the Overlay Instance, or by additional verification actions of the enrollment service. To prevent an (exclusive) routing to a bogus registration, a caller can in addition query the DNS (or other discovery services at hand), search for an alternative presence of the callee in another overlay or a SIP infrastructure using [RFC3263] for name resolution.
通过限制覆盖实例中允许的名称空间，或通过注册服务的附加验证操作，可以减轻AOR劫持。为了防止（独占）路由到虚假注册，呼叫者还可以查询DNS（或手头的其他发现服务），使用[RFC3263]进行名称解析，在另一覆盖或SIP基础设施中搜索被呼叫者的替代存在。
All RELOAD SIP registration data is visible to all nodes in the overlay. Location privacy can be gained from using anonymous GRUUs. Methods of providing anonymity or deploying pseudonyms exist, but are beyond the scope of this document.
覆盖中的所有节点都可以看到所有重新加载SIP注册数据。使用匿名GRUUs可以获得位置隐私。提供匿名或使用假名的方法已经存在，但超出了本文档的范围。
IANA has registered the following code point in the "RELOAD Data Kind-ID" Registry (cf., [RFC6940]) to represent the SIP-REGISTRATION Kind, as described in Section 7.
IANA已在“重新加载数据种类ID”注册表（参见[RFC6940]）中注册了以下代码点，以表示SIP-REGISTRATION种类，如第7节所述。
+---------------------+------------+-----------+
| Kind | Kind-ID | Reference |
+---------------------+------------+-----------+
| SIP-REGISTRATION | 0x1 | RFC 7904 |
+---------------------+------------+-----------+
+---------------------+------------+-----------+
| Kind | Kind-ID | Reference |
+---------------------+------------+-----------+
| SIP-REGISTRATION | 0x1 | RFC 7904 |
+---------------------+------------+-----------+
This document registers the following URI for the config XML namespace in the IETF XML registry defined in [RFC3688]:
本文档在[RFC3688]中定义的IETF XML注册表中为配置XML命名空间注册以下URI：
URI: urn:ietf:params:xml:ns:p2p:config-base:sip
URI: urn:ietf:params:xml:ns:p2p:config-base:sip
Registrant Contact: The IESG
注册联系人：IESG
XML: N/A; the requested URI is an XML namespace
XML: N/A; the requested URI is an XML namespace
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, January 2014, <http://www.rfc-editor.org/info/rfc6940>.
[RFC6940]Jennings，C.，Lowekamp，B.，Ed.，Rescorla，E.，Baset，S.，和H.Schulzrinne，“资源定位和发现（重新加载）基础协议”，RFC 6940，DOI 10.17487/RFC6940，2014年1月<http://www.rfc-editor.org/info/rfc6940>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, DOI 10.17487/RFC2533, March 1999, <http://www.rfc-editor.org/info/rfc2533>.
[RFC2533]Klyne，G.“描述媒体功能集的语法”，RFC 2533，DOI 10.17487/RFC2533，1999年3月<http://www.rfc-editor.org/info/rfc2533>.
[RFC2738] Klyne, G., "Corrections to "A Syntax for Describing Media Feature Sets"", RFC 2738, DOI 10.17487/RFC2738, December 1999, <http://www.rfc-editor.org/info/rfc2738>.
[RFC2738]Klyne，G.“对“描述媒体功能集的语法”的更正”，RFC 2738，DOI 10.17487/RFC2738，1999年12月<http://www.rfc-editor.org/info/rfc2738>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<http://www.rfc-editor.org/info/rfc3688>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，DOI 10.17487/RFC3840，2004年8月<http://www.rfc-editor.org/info/rfc3840>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<http://www.rfc-editor.org/info/rfc5245>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <http://www.rfc-editor.org/info/rfc5626>.
[RFC5626]Jennings，C.，Ed.，Mahy，R.，Ed.，和F.Audet，Ed.，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，DOI 10.17487/RFC5626，2009年10月<http://www.rfc-editor.org/info/rfc5626>.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <http://www.rfc-editor.org/info/rfc5627>.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，DOI 10.17487/RFC5627，2009年10月<http://www.rfc-editor.org/info/rfc5627>.
[IEEE-Posix] IEEE, "International Standard - Information technology Portable Operating System Interface (POSIX) Base Specifications, Issue 7", ISO/IEC/IEEE 9945:2009, DOI 10.1109/IEEESTD.2009.5393893, September 2009.
[IEEE Posix]IEEE，“国际标准-信息技术便携式操作系统接口（Posix）基本规范，第7期”，ISO/IEC/IEEE 9945:2009，DOI 10.1109/IEEESTD.2009.5393893，2009年9月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <http://www.rfc-editor.org/info/rfc3263>.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，DOI 10.17487/RFC3263，2002年6月<http://www.rfc-editor.org/info/rfc3263>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，DOI 10.17487/RFC3966，2004年12月<http://www.rfc-editor.org/info/rfc3966>.
[RFC7890] Bryan, D., Matthews, P., Shim, E., Willis, D., and S. Dawkins, "Concepts and Terminology for Peer-to-Peer SIP (P2PSIP)", RFC 7890, DOI 10.17487/RFC7890, June 2016, <http://www.rfc-editor.org/info/rfc7890>.
[RFC7890]Bryan，D.，Matthews，P.，Shim，E.，Willis，D.，和S.Dawkins，“对等SIP（P2PSIP）的概念和术语”，RFC 7890，DOI 10.17487/RFC78902016年6月<http://www.rfc-editor.org/info/rfc7890>.
[RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, DOI 10.17487/RFC5767, April 2010, <http://www.rfc-editor.org/info/rfc5767>.
[RFC5767]Munakata，M.，Schubert，S.，和T.Ohba，“SIP的用户代理驱动隐私机制”，RFC 5767，DOI 10.17487/RFC5767，2010年4月<http://www.rfc-editor.org/info/rfc5767>.
[SHARE] Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A Usage for Shared Resources in RELOAD (ShaRe)", Work in Progress, draft-ietf-p2psip-share-08, March 2016.
[共享]可耐福，A.，施密特，T.，黑格，G.和M.韦利希，“重新加载（共享）中共享资源的使用”，正在进行的工作，草稿-ietf-p2psip-SHARE-082016年3月。
Non-peer-to-peer SIP defines third-party registration (e.g., an assistant acting for a manager or a changing set of users registering under a role-based AOR) in Section 10.2 of [RFC3261]. This is a REGISTER that uses the URI of the third party in its From header and cannot be translated directly into a P2PSIP registration because only the owner of the certificate can store a SIP-REGISTRATION in a RELOAD overlay.
非点对点SIP在[RFC3261]第10.2节中定义了第三方注册（例如，代表经理的助手或根据基于角色的AOR注册的一组变化的用户）。这是一个在其From标头中使用第三方URI的寄存器，无法直接转换为P2PSIP注册，因为只有证书的所有者才能在重新加载覆盖中存储SIP注册。
Third-party registration can be implemented by using the extended access control mechanism USER-CHAIN-ACL defined in [SHARE]. Creating a new Kind "SIP-3P-REGISTRATION" that is ruled by USER-CHAIN-ACL allows the owner of the certificate to delegate the right for registration to individual third parties. This way, the SIP third-party registration functionality can be regained without weakening the security controls of RELOAD.
第三方注册可以通过使用[SHARE]中定义的扩展访问控制机制USER-CHAIN-ACL来实现。创建一种由USER-CHAIN-ACL管理的新类型“SIP-3P-REGISTRATION”，允许证书所有者将注册权委托给各个第三方。这样，SIP第三方注册功能可以重新获得，而不会削弱重新加载的安全控制。
Acknowledgments
致谢
This document was generated in parts from initial drafts and discussions in the early specification phase of the P2PSIP base protocol. We gratefully acknowledge the significant contributions made by (in alphabetical order) David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan Rosenberg, and Marcia Zangrilli.
本文件由P2PSIP基本协议早期规范阶段的初稿和讨论部分生成。我们衷心感谢大卫·A·布莱恩、詹姆斯·德弗里克、马辛·马图塞夫斯基、乔纳森·罗森博格和马西亚·赞格里利（按字母顺序）所作的重大贡献。
Additional thanks go to all those who helped with ideas, discussions, and reviews, in particular (in alphabetical order) Roland Bless, Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, Meral Shirazipour, and Matthias Waehlisch.
此外，还要感谢所有在想法、讨论和评论方面提供帮助的人，特别是（按字母顺序排列）罗兰·布莱斯、迈克尔·陈、艾丽莎·库珀、马克·佩蒂特·胡格宁、布赖恩·罗森、梅拉尔·谢拉齐普尔和马蒂亚斯·韦利希。
Authors' Addresses
作者地址
Cullen Jennings Cisco 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 United States of America Phone: +1 408 421-9990 Email: fluffy@cisco.com
Cullen Jennings Cisco 170西塔斯曼大道MS:SJC-21/2加利福尼亚州圣何塞95134美利坚合众国电话：+1 408 421-9990电子邮件：fluffy@cisco.com
Bruce B. Lowekamp Skype Palo Alto, CA United States of America Email: bbl@lowekamp.net
Bruce B.Lowekamp Skype Palo Alto，加利福尼亚州美利坚合众国电子邮件：bbl@lowekamp.net
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 United States of America Phone: +1 650 678 2350 Email: ekr@rtfm.com
Eric Rescorla RTFM，Inc.美国加利福尼亚州帕洛阿尔托埃奇伍德大道2064号94303电话：+1 650 678 2350电子邮件：ekr@rtfm.com
Salman A. Baset IBM T. J. Watson Research Center 1101 Kitchawan Road Yorktown Heights, NY 10598 United States of America Email: sabaset@us.ibm.com
Salman A.Baset IBM T.J.Watson研究中心1101 Kitchawan Road Yorktown Heights，NY 10598美利坚合众国电子邮件：sabaset@us.ibm.com
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States of America Email: hgs@cs.columbia.edu
Henning Schulzrinne哥伦比亚大学纽约阿姆斯特丹大道1214号，邮编：10027美利坚合众国电子邮件：hgs@cs.columbia.edu
Thomas C. Schmidt (editor) HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany Email: t.schmidt@haw-hamburg.de
Thomas C.Schmidt（编辑）HAW Hamburg Berliner Tor 7 Hamburg 20099德国电子邮件：t。schmidt@haw-汉堡