Network Working Group J. Rosenberg
Request for Comments: 5360 Cisco Systems
Category: Standards Track G. Camarillo, Ed.
Ericsson
D. Willis
Unaffiliated
October 2008
Network Working Group J. Rosenberg
Request for Comments: 5360 Cisco Systems
Category: Standards Track G. Camarillo, Ed.
Ericsson
D. Willis
Unaffiliated
October 2008
A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)
会话启动协议（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）。本备忘录的分发不受限制。
Abstract
摘要
SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP.
SIP支持多种服务的通信，包括实时音频、视频、文本、即时消息和状态。在其当前形式中，它允许会话邀请、即时消息和其他请求从一方传递到另一方，而无需接收方的明确同意。如果没有这种同意，SIP可能被用于恶意目的，包括放大和DoS（拒绝服务）攻击。本文档确定了SIP中基于同意的通信框架。
Table of Contents
目录
1. Introduction ....................................................3
2. Definitions and Terminology .....................................3
3. Relays and Translations .........................................4
4. Architecture ....................................................6
4.1. Permissions at a Relay .....................................6
4.2. Consenting Manipulations on a Relay's Translation Logic ....7
4.3. Store-and-Forward Servers ..................................8
4.4. Recipients Grant Permissions ...............................9
4.5. Entities Implementing This Framework .......................9
5. Framework Operations ............................................9
5.1. Amplification Avoidance ...................................11
5.1.1. Relay's Behavior ...................................12
5.2. Subscription to the Permission Status .....................12
5.2.1. Relay's Behavior ...................................13
5.3. Request for Permission ....................................13
5.3.1. Relay's Behavior ...................................13
5.4. Permission Document Structure .............................15
5.5. Permission Requested Notification .........................16
5.6. Permission Grant ..........................................17
5.6.1. Relay's Behavior ...................................17
5.6.1.1. SIP Identity ..............................17
5.6.1.2. P-Asserted-Identity .......................17
5.6.1.3. Return Routability ........................18
5.6.1.4. SIP Digest ................................19
5.7. Permission Granted Notification ...........................19
5.8. Permission Revocation .....................................19
5.9. Request-Contained URI Lists ...............................20
5.9.1. Relay's Behavior ...................................21
5.9.2. Definition of the 470 Response Code ................21
5.9.3. Definition of the Permission-Missing Header Field ..22
5.10. Registrations ............................................22
5.11. Relays Generating Traffic towards Recipients .............25
5.11.1. Relay's Behavior ..................................25
5.11.2. Definition of the Trigger-Consent Header Field ....25
6. IANA Considerations ............................................26
6.1. Registration of the 470 Response Code .....................26
6.2. Registration of the Trigger-Consent Header Field ..........26
6.3. Registration of the Permission-Missing Header Field .......26
6.4. Registration of the target-uri Header Field Parameter .....26
7. Security Considerations ........................................27
8. Acknowledgments ................................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................29
1. Introduction ....................................................3
2. Definitions and Terminology .....................................3
3. Relays and Translations .........................................4
4. Architecture ....................................................6
4.1. Permissions at a Relay .....................................6
4.2. Consenting Manipulations on a Relay's Translation Logic ....7
4.3. Store-and-Forward Servers ..................................8
4.4. Recipients Grant Permissions ...............................9
4.5. Entities Implementing This Framework .......................9
5. Framework Operations ............................................9
5.1. Amplification Avoidance ...................................11
5.1.1. Relay's Behavior ...................................12
5.2. Subscription to the Permission Status .....................12
5.2.1. Relay's Behavior ...................................13
5.3. Request for Permission ....................................13
5.3.1. Relay's Behavior ...................................13
5.4. Permission Document Structure .............................15
5.5. Permission Requested Notification .........................16
5.6. Permission Grant ..........................................17
5.6.1. Relay's Behavior ...................................17
5.6.1.1. SIP Identity ..............................17
5.6.1.2. P-Asserted-Identity .......................17
5.6.1.3. Return Routability ........................18
5.6.1.4. SIP Digest ................................19
5.7. Permission Granted Notification ...........................19
5.8. Permission Revocation .....................................19
5.9. Request-Contained URI Lists ...............................20
5.9.1. Relay's Behavior ...................................21
5.9.2. Definition of the 470 Response Code ................21
5.9.3. Definition of the Permission-Missing Header Field ..22
5.10. Registrations ............................................22
5.11. Relays Generating Traffic towards Recipients .............25
5.11.1. Relay's Behavior ..................................25
5.11.2. Definition of the Trigger-Consent Header Field ....25
6. IANA Considerations ............................................26
6.1. Registration of the 470 Response Code .....................26
6.2. Registration of the Trigger-Consent Header Field ..........26
6.3. Registration of the Permission-Missing Header Field .......26
6.4. Registration of the target-uri Header Field Parameter .....26
7. Security Considerations ........................................27
8. Acknowledgments ................................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................29
The Session Initiation Protocol (SIP) [RFC3261] supports communications for several services, including real-time audio, video, text, instant messaging, and presence. This communication is established by the transmission of various SIP requests (such as INVITE and MESSAGE [RFC3428]) from an initiator to the recipient with whom communication is desired. Although a recipient of such a SIP request can reject the request, and therefore decline the session, a network of SIP proxy servers will deliver a SIP request to its recipients without their explicit consent.
会话启动协议（SIP）[RFC3261]支持多种服务的通信，包括实时音频、视频、文本、即时消息和状态。这种通信是通过从发起者向需要通信的接收者传输各种SIP请求（如INVITE和MESSAGE[RFC3428]）来建立的。尽管此类SIP请求的接收者可以拒绝该请求，并因此拒绝会话，但SIP代理服务器网络将在未经接收者明确同意的情况下向其发送SIP请求。
Receipt of these requests without explicit consent can cause a number of problems. These include amplification and DoS (Denial of Service) attacks. These problems are described in more detail in a companion requirements document [RFC4453].
未经明确同意而收到这些请求可能会造成许多问题。这些攻击包括放大攻击和DoS（拒绝服务）攻击。这些问题在配套需求文件[RFC4453]中有更详细的描述。
This specification defines a basic framework for adding consent-based communication to SIP.
本规范定义了向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]中所述进行解释。
Recipient URI: The Request-URI of an outgoing request sent by an entity (e.g., a user agent or a proxy). The sending of such request can have been the result of a translation operation.
接收方URI：实体（例如，用户代理或代理）发送的传出请求的请求URI。发送此类请求可能是翻译操作的结果。
Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, that receives a request, translates its Request-URI into one or more next-hop URIs (i.e., recipient URIs), and delivers the request to those URIs.
中继：接收请求、将其请求URI转换为一个或多个下一跳URI（即接收方URI）并将请求传递给这些URI的任何SIP服务器，无论是代理服务器、B2BUA（背对背用户代理）还是某种混合服务器。
Target URI: The Request-URI of an incoming request that arrives to a relay that will perform a translation operation.
目标URI：到达将执行转换操作的中继的传入请求的请求URI。
Translation logic: The logic that defines a translation operation at a relay. This logic includes the translation's target and recipient URIs.
翻译逻辑：定义继电器翻译操作的逻辑。此逻辑包括翻译的目标URI和收件人URI。
Translation operation: Operation by which a relay translates the Request-URI of an incoming request (i.e., the target URI) into one or more URIs (i.e., recipient URIs) that are used as the Request-URIs of one or more outgoing requests.
转换操作：中继将传入请求的请求URI（即目标URI）转换为一个或多个URI（即接收方URI）的操作，这些URI用作一个或多个传出请求的请求URI。
Relays play a key role in this framework. A relay is defined as any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, that receives a request, translates its Request-URI into one or more next-hop URIs, and delivers the request to those URIs. The Request-URI of the incoming request is referred to as 'target URI' and the destination URIs of the outgoing requests are referred to as 'recipient URIs', as shown in Figure 1.
继电器在该框架中起着关键作用。中继被定义为接收请求、将其请求URI转换为一个或多个下一跳URI并将请求传递给这些URI的任何SIP服务器，可以是代理服务器、B2BUA（背对背用户代理）或某种混合服务器。传入请求的请求URI称为“目标URI”，传出请求的目标URI称为“收件人URI”，如图1所示。
+---------------+ recipient URI
| |---------------->
| |
target URI | Translation | [...]
-------------->| Operation |
| | recipient URI
| |---------------->
+---------------+
+---------------+ recipient URI
| |---------------->
| |
target URI | Translation | [...]
-------------->| Operation |
| | recipient URI
| |---------------->
+---------------+
Figure 1: Translation Operation
图1：翻译操作
Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates the Request-URI (target URI) into one or more additional URIs (recipient URIs). Through this translation operation, the relay can create outgoing requests to one or more additional recipient URIs, thus creating the consent problem.
因此，接力的一个重要方面是翻译。当中继接收到请求时，它将请求URI（目标URI）转换为一个或多个附加URI（接收方URI）。通过此转换操作，中继可以创建到一个或多个其他收件人URI的传出请求，从而产生同意问题。
The consent problem is created by two types of translations: translations based on local data and translations that involve amplifications.
同意问题由两种类型的翻译造成：基于本地数据的翻译和涉及放大的翻译。
Translation operations based on local policy or local data (such as registrations) are the vehicle by which a request is delivered directly to an endpoint, when it would not otherwise be possible to. In other words, if a spammer has the address of a user, 'sip:user@example.com', it cannot deliver a MESSAGE request to the UA (user agent) of that user without having access to the registration data that maps 'sip:user@example.com' to the user agent on which that user is present. Thus, it is the usage of this registration data, and more generally, the translation logic, that is expected to be authorized in order to prevent undesired communications. Of course, if the spammer knows the address of the user agent, it will be able to deliver requests directly to it.
基于本地策略或本地数据（如注册）的转换操作是将请求直接传递到端点的工具，否则无法进行转换。换句话说，如果垃圾邮件发送者拥有用户的地址，“sip:user@example.com，它无法向该用户的UA（用户代理）发送消息请求，而无需访问映射“sip:user@example.com'发送给该用户所在的用户代理。因此，为了防止不期望的通信，期望授权的是该注册数据的使用，以及更一般的翻译逻辑。当然，如果垃圾邮件发送者知道用户代理的地址，它将能够直接向其发送请求。
Translation operations that result in more than one recipient URI are a source of amplification. Servers that do not perform translations, such as outbound proxy servers, do not cause amplification. On the other hand, servers that perform translations (e.g., inbound proxies
导致多个收件人URI的转换操作是放大的来源。不执行翻译的服务器（如出站代理服务器）不会导致放大。另一方面，执行翻译的服务器（例如，入站代理
authoritatively responsible for a SIP domain) may cause amplification if the user can be reached at multiple endpoints (thereby resulting in multiple recipient URIs).
如果可以在多个端点到达用户（从而导致多个接收者URI），则授权负责SIP域（IP）可能会导致放大。
Figure 2 shows a relay that performs translations. The user agent client in the figure sends a SIP request to a URI representing a resource in the domain 'example.com' (sip:resource@example.com). This request can pass through a local outbound proxy (not shown), but eventually arrives at a server authoritative for the domain 'example.com'. This server, which acts as a relay, performs a translation operation, translating the target URI into one or more recipient URIs, which can (but need not) belong to the domain 'example.com'. This relay can be, for instance, a proxy server or a URI-list service [RFC5363].
图2显示了执行转换的继电器。图中的用户代理客户端向表示域“example.com”（SIP:resource@example.com). 此请求可以通过本地出站代理（未显示），但最终会到达域“example.com”的权威服务器。此服务器充当中继，执行转换操作，将目标URI转换为一个或多个收件人URI，这些URI可以（但不需要）属于域“example.com”。例如，该中继可以是代理服务器或URI列表服务[RFC5363]。
+-------+
| |
>| UA |
/ | |
/ +-------+
/
/
+-----------------------+ /
| | /
+-----+ | Relay | / +-------+
| | | |/ | |
| UA |------>| |-------->| Proxy |
| | |+---------------------+|\ | |
+-----+ || Translation || \ +-------+
|| Logic || \
|+---------------------+| \ [...]
+-----------------------+ \
\
\ +-------+
\ | |
>| B2BUA |
| |
+-------+
+-------+
| |
>| UA |
/ | |
/ +-------+
/
/
+-----------------------+ /
| | /
+-----+ | Relay | / +-------+
| | | |/ | |
| UA |------>| |-------->| Proxy |
| | |+---------------------+|\ | |
+-----+ || Translation || \ +-------+
|| Logic || \
|+---------------------+| \ [...]
+-----------------------+ \
\
\ +-------+
\ | |
>| B2BUA |
| |
+-------+
Figure 2: Relay Performing a Translation
图2：执行转换的继电器
This framework allows potential recipients of a translation to agree to be actual recipients by giving the relay performing the translation permission to send them traffic.
此框架允许翻译的潜在收件人同意成为实际收件人，方法是向执行翻译的中继授予向其发送流量的权限。
Figure 3 shows the architectural elements of this framework. The manipulation of a relay's translation logic typically causes the relay to send a permission request, which in turn causes the recipient to grant or deny the relay permissions for the translation. Section 4.1 describes the role of permissions at a relay. Section 4.2 discusses the actions taken by a relay when its translation logic is manipulated by a client. Section 4.3 discusses store-and-forward servers and their functionality. Section 4.4 describes how potential recipients can grant a relay permissions to add them to the relay's translation logic. Section 4.5 discusses which entities need to implement this framework.
图3显示了该框架的体系结构元素。对中继的翻译逻辑的操作通常会导致中继发送权限请求，这反过来又会导致收件人授予或拒绝对翻译的中继权限。第4.1节描述了权限在中继中的作用。第4.2节讨论了当客户机操纵继电器的翻译逻辑时，继电器所采取的行动。第4.3节讨论存储转发服务器及其功能。第4.4节描述了潜在收件人如何授予中继权限，以将其添加到中继的翻译逻辑中。第4.5节讨论了哪些实体需要实施该框架。
+-----------------------+ Permission +-------------+
| | Request | |
+--------+ | Relay |----------->| Store & Fwd |
| | | | | Server |
| Client | | | | |
| | |+-------+ +-----------+| +-------------+
+--------+ ||Transl.| |Permissions|| |
| ||Logic | | || Permission |
| |+-------+ +-----------+| Request |
| +-----------------------+ V
| ^ ^ +-------------+
| Manipulation | | Permission Grant | |
+---------------+ +-------------------| Recipient |
| |
+-------------+
+-----------------------+ Permission +-------------+
| | Request | |
+--------+ | Relay |----------->| Store & Fwd |
| | | | | Server |
| Client | | | | |
| | |+-------+ +-----------+| +-------------+
+--------+ ||Transl.| |Permissions|| |
| ||Logic | | || Permission |
| |+-------+ +-----------+| Request |
| +-----------------------+ V
| ^ ^ +-------------+
| Manipulation | | Permission Grant | |
+---------------+ +-------------------| Recipient |
| |
+-------------+
Figure 3: Reference Architecture
图3：参考体系结构
Relays implementing this framework obtain and store permissions associated to their translation logic. These permissions indicate whether or not a particular recipient has agreed to receive traffic at any given time. Recipients that have not given the relay permission to send them traffic are simply ignored by the relay when performing a translation.
实现此框架的中继获取并存储与其翻译逻辑关联的权限。这些权限指示特定收件人是否同意在任何给定时间接收流量。在执行翻译时，未授予中继权限向其发送流量的收件人将被中继忽略。
In principle, permissions are valid as long as the context where they were granted is valid or until they are revoked. For example, the permissions obtained by a URI-list SIP service that distributes MESSAGE requests to a set of recipients will be valid as long as the URI-list SIP service exists or until the permissions are revoked.
原则上，只要授予权限的上下文有效，或者直到权限被撤销为止，权限都是有效的。例如，只要URI列表SIP服务存在，或者在撤销权限之前，将消息请求分发给一组收件人的URI列表SIP服务所获得的权限都是有效的。
Additionally, if a recipient is removed from a relay's translation logic, the relay SHOULD delete the permissions related to that recipient. For example, if the registration of a contact URI expires or is otherwise terminated, the registrar deletes the permissions related to that contact address.
此外，如果从中继的翻译逻辑中删除了收件人，中继应删除与该收件人相关的权限。例如，如果联系人URI的注册过期或以其他方式终止，则注册器将删除与该联系人地址相关的权限。
It is also RECOMMENDED that relays request recipients to refresh their permissions periodically. If a recipient fails to refresh its permissions for a given period of time, the relay SHOULD delete the permissions related to that recipient.
还建议中继请求收件人定期刷新其权限。如果收件人在给定时间段内未能刷新其权限，则中继应删除与该收件人相关的权限。
This framework does not provide any guidance for the values of the refreshment intervals because different applications can have different requirements to set those values. For example, a relay dealing with recipients that do not implement this framework may choose to use longer intervals between refreshes. The refresh process in such recipients has to be performed manually by their users (since the recipients do not implement this framework), and having too short refresh intervals may become too heavy a burden for those users.
此框架不提供刷新间隔值的任何指导，因为不同的应用程序可能有不同的要求来设置这些值。例如，处理未实现此框架的收件人的中继可能会选择在刷新之间使用更长的间隔。此类收件人中的刷新过程必须由其用户手动执行（因为收件人未实现此框架），刷新间隔过短可能会给这些用户带来过重的负担。
This framework aims to ensure that any particular relay only performs translations towards destinations that have given the relay permission to perform such a translation. Consequently, when the translation logic of a relay is manipulated (e.g., a new recipient URI is added), the relay obtains permission from the new recipient in order to install the new translation logic. Relays ask recipients for permission using MESSAGE [RFC3428] requests.
该框架旨在确保任何特定的中继只执行对已授予中继执行此类翻译权限的目的地的翻译。因此，当操纵中继的翻译逻辑时（例如，添加新的接收者URI），中继从新接收者获得许可以安装新的翻译逻辑。中继使用消息[RFC3428]请求请求收件人的权限。
For example, the relay hosting the URI-list service at 'sip:friends@example.com' performs a translation from that target URI to a set of recipient URIs. When a client (e.g., the administrator of that URI-list service) adds 'bob@example.org' as a new recipient URI, the relay sends a MESSAGE request to 'sip:bob@example.org' asking whether or not it is OK to perform the translation from 'sip:friends@example.com' to 'sip:bob@example.org'. The MESSAGE request carries in its message body a permission document that describes the translation for which permissions are being requested and a human-readable part that also describes the translation. If the answer is positive, the new translation logic is installed at the relay. That is, the new recipient URI is added.
例如，承载URI列表服务的中继位于“sip:friends@example.com'执行从该目标URI到一组收件人URI的转换。当客户端（例如，该URI列表服务的管理员）添加bob@example.org'作为新的收件人URI，中继向'sip:bob@example.org'询问是否可以从'sip:friends@example.com“至”sip：bob@example.org'. 消息请求在其消息体中包含一个权限文档，该文档描述请求权限的翻译，以及一个人类可读的部分，该部分也描述翻译。如果答案是肯定的，则在继电器上安装新的转换逻辑。也就是说，添加了新的收件人URI。
The human-readable part is included so that user agents that do not understand permission documents can still process the request and display it in a sensible way to the user.
包含了人类可读的部分，因此不理解权限文档的用户代理仍然可以处理请求并以合理的方式向用户显示。
The mechanism to be used to manipulate the translation logic of a particular relay depends on the relay. Two existing mechanisms to manipulate translation logic are XML Configuration Access Protocol (XCAP) [RFC4825] and REGISTER transactions.
用于操纵特定继电器的转换逻辑的机制取决于继电器。操作转换逻辑的两种现有机制是XML配置访问协议（XCAP）[RFC4825]和寄存器事务。
Section 5 uses a URI-list service whose translation logic is manipulated with XCAP as an example of a translation, in order to specify this framework. Section 5.10 discusses how to apply this framework to registrations, which are a different type of translation.
第5节使用一个URI列表服务，该服务的翻译逻辑由XCAP操作，作为翻译的示例，以指定该框架。第5.10节讨论了如何将该框架应用于注册，注册是一种不同的翻译类型。
In any case, relays implementing this framework SHOULD have a means to indicate that a particular recipient URI is in the states specified in [RFC5362] (i.e., pending, waiting, error, denied, or granted).
在任何情况下，实现此框架的中继都应该有一种方法来指示特定接收方URI处于[RFC5362]中指定的状态（即，挂起、等待、错误、拒绝或授予）。
When a MESSAGE request with a permission document arrives to the recipient URI to which it was sent by the relay, the receiving user can grant or deny the permission needed to perform the translation. However, the receiving user may not be available when the MESSAGE request arrives, or it may have expressed preferences to block all incoming requests for a certain time period. In such cases, a store-and-forward server can act as a substitute for the user and buffer the incoming MESSAGE requests, which are subsequently delivered to the user when he or she is available again.
当带有权限文档的消息请求到达中继发送到的收件人URI时，接收用户可以授予或拒绝执行翻译所需的权限。然而，当消息请求到达时，接收用户可能不可用，或者它可能已经表示了在特定时间段内阻止所有传入请求的偏好。在这种情况下，存储转发服务器可以充当用户的替代品，并缓冲传入的消息请求，当用户再次可用时，这些请求随后被传递给用户。
There are several mechanisms to implement store-and-forward message services (e.g., with an instant message to email gateway). Any of these mechanisms can be used between a user agent and its store-and-forward server as long as they agree on which mechanism to use. Therefore, this framework does not make any provision for the interface between user agents and their store-and-forward servers.
有几种机制可以实现存储和转发消息服务（例如，通过即时消息到电子邮件网关）。这些机制中的任何一种都可以在用户代理及其存储转发服务器之间使用，只要它们同意使用哪种机制。因此，该框架没有为用户代理与其存储转发服务器之间的接口做出任何规定。
Note that the same store-and-forward message service can handle all incoming MESSAGE requests for a user while they are offline, not only those MESSAGE requests with a permission document in their bodies.
请注意，同一存储转发消息服务可以在用户脱机时处理所有传入的消息请求，而不仅仅是那些正文中包含权限文档的消息请求。
Even though store-and-forward servers perform a useful function and they are expected to be deployed in most domains, some domains will not deploy them from the outset. However, user agents and relays in domains without store-and-forward servers can still use this consent framework.
即使存储和转发服务器执行有用的功能，并且预计它们将部署在大多数域中，但有些域从一开始就不会部署它们。但是，没有存储转发服务器的域中的用户代理和中继仍然可以使用此同意框架。
When a relay requests permissions from an offline user agent that does not have an associated store-and-forward server, the relay will obtain an error response indicating that its MESSAGE request could not be delivered. The client that attempted to add the offline user to the relay's translation logic will be notified about the error (e.g., using the Pending Additions event package [RFC5362]). This client MAY attempt to add the same user at a later point, hopefully when the user is online. Clients can discover whether or not a user is online by using a presence service, for instance.
当中继从没有关联存储转发服务器的脱机用户代理请求权限时，中继将获得错误响应，指示其消息请求无法传递。尝试将脱机用户添加到中继转换逻辑的客户端将收到错误通知（例如，使用挂起的添加事件包[RFC5362]）。此客户端可能会在稍后尝试添加相同的用户，希望在用户联机时添加。例如，客户端可以通过使用状态服务来发现用户是否在线。
Permission documents generated by a relay include URIs that can be used by the recipient of the document to grant or deny the relay the permission described in the document. Relays always include SIP URIs and can include HTTP [RFC2616] URIs for this purpose. Consequently, recipients provide relays with permissions using SIP PUBLISH requests or HTTP GET requests.
中继生成的权限文档包括URI，文档收件人可以使用这些URI授予或拒绝中继文档中描述的权限。中继器始终包括SIP URI，并且为此目的可以包括HTTP[RFC2616]URI。因此，收件人使用SIP发布请求或HTTP GET请求向中继提供权限。
The goal of this framework is to keep relays from executing translations towards unwilling recipients. Therefore, all relays MUST implement this framework in order to avoid being used to perform attacks (e.g., amplification attacks).
该框架的目标是防止中继向不愿意的接收者执行翻译。因此，所有继电器必须实现该框架，以避免被用于执行攻击（例如，放大攻击）。
This framework has been designed with backwards compatibility in mind so that legacy user agents (i.e., user agents that do not implement this framework) can act both as clients and recipients with an acceptable level of functionality. However, it is RECOMMENDED that user agents implement this framework, which includes supporting the Pending Additions event package specified in [RFC5362], the format for permission documents specified in [RFC5361], and the header fields and response code specified in this document, in order to achieve full functionality.
此框架的设计考虑了向后兼容性，以便遗留用户代理（即，未实现此框架的用户代理）可以作为具有可接受功能级别的客户端和接收者。但是，建议用户代理实现此框架，其中包括支持[RFC5362]中指定的挂起添加事件包、[RFC5361]中指定的权限文档格式以及本文档中指定的标题字段和响应代码，以实现完整功能。
The only requirement that this framework places on store-and-forward servers is that they need to be able to deliver encrypted and integrity-protected messages to their user agents, as discussed in Section 7. However, this is not a requirement specific to this framework but a general requirement for store-and-forward servers.
该框架对存储和转发服务器的唯一要求是，它们需要能够向其用户代理传递加密和完整性保护的消息，如第7节所述。但是，这不是此框架的特定要求，而是存储转发服务器的一般要求。
This section specifies this consent framework using an example of the prototypical call flow. The elements described in Section 4 (i.e., relays, translations, and store-and-forward servers) play an essential role in this call flow.
本节使用原型调用流的示例指定此同意框架。第4节中描述的元素（即中继、翻译和存储转发服务器）在该调用流中起着至关重要的作用。
Figure 4 shows the complete process to add a recipient URI ('sip:B@example.com') to the translation logic of a relay. User A attempts to add 'sip:B@example.com' as a new recipient URI to the translation logic of the relay (1). User A uses XCAP [RFC4825] and the XML (Extensible Markup Language) format for representing resource lists [RFC4826] to perform this addition. Since the relay does not have permission from 'sip:B@example.com' to perform translations towards that URI, the relay places 'sip:B@example.com' in the pending state, as specified in [RFC5362].
图4显示了添加收件人URI（“sip:B@example.com“）转换为继电器的转换逻辑。用户A尝试添加“sip:B@example.com'作为中继（1）转换逻辑的新收件人URI。用户A使用XCAP[RFC4825]和XML（可扩展标记语言）格式来表示资源列表[RFC4826]来执行此添加。由于中继没有“sip”的权限：B@example.com'要执行对该URI的翻译，中继放置'sip:B@example.com'处于挂起状态，如[RFC5362]中所述。
A@example.com Relay B's Store & Fwd B@example.com Server
A@example.com继电器B的存储和FwdB@example.com服务器
|(1) Add Recipient | |
| sip:B@example.com | |
|--------------->| | |
|(2) HTTP 202 (Accepted) | |
|<---------------| | |
| |(3) MESSAGE sip:B@example |
| | Permission Document |
| |--------------->| |
| |(4) 202 Accepted| |
| |<---------------| |
|(5) SUBSCRIBE | | |
| Event: pending-additions | |
|--------------->| | |
|(6) 200 OK | | |
|<---------------| | |
|(7) NOTIFY | | |
|<---------------| | |
|(8) 200 OK | | |
|--------------->| | |
| | | |User B goes
| | | | online
| | |(9) Request for |
| | | stored messages
| | |<---------------|
| | |(10) Delivery of|
| | | stored messages
| | |--------------->|
| |(11) PUBLISH uri-up |
| |<--------------------------------|
| |(12) 200 OK | |
| |-------------------------------->|
|(13) NOTIFY | | |
|<---------------| | |
|(14) 200 OK | | |
|--------------->| | |
|(1) Add Recipient | |
| sip:B@example.com | |
|--------------->| | |
|(2) HTTP 202 (Accepted) | |
|<---------------| | |
| |(3) MESSAGE sip:B@example |
| | Permission Document |
| |--------------->| |
| |(4) 202 Accepted| |
| |<---------------| |
|(5) SUBSCRIBE | | |
| Event: pending-additions | |
|--------------->| | |
|(6) 200 OK | | |
|<---------------| | |
|(7) NOTIFY | | |
|<---------------| | |
|(8) 200 OK | | |
|--------------->| | |
| | | |User B goes
| | | | online
| | |(9) Request for |
| | | stored messages
| | |<---------------|
| | |(10) Delivery of|
| | | stored messages
| | |--------------->|
| |(11) PUBLISH uri-up |
| |<--------------------------------|
| |(12) 200 OK | |
| |-------------------------------->|
|(13) NOTIFY | | |
|<---------------| | |
|(14) 200 OK | | |
|--------------->| | |
Figure 4: Prototypical Call Flow
图4：原型调用流
Once 'sip:B@example.com' is in the pending state, the relay needs to ask user B for permission by sending a MESSAGE request to 'sip:B@example.com'. However, the relay needs to ensure that it is not used as an amplifier to launch amplification attacks.
一次的sip：B@example.com'处于挂起状态，中继需要通过向'sip:B@example.com'. 但是，继电器需要确保它不被用作放大器来发起放大攻击。
In such an attack, the attacker would add a large number of recipient URIs to the translation logic of a relay. The relay would then send a MESSAGE request to each of those recipient URIs. The bandwidth generated by the relay would be much higher than the bandwidth used by the attacker to add those recipient URIs to the translation logic of the relay.
在这种攻击中，攻击者会将大量收件人URI添加到中继的转换逻辑中。然后，中继将向每个收件人URI发送消息请求。中继生成的带宽将远高于攻击者将这些收件人URI添加到中继的转换逻辑时使用的带宽。
This framework uses a credit-based authorization mechanism to avoid the attack just described. It requires users adding new recipient URIs to a translation to generate an amount of bandwidth that is comparable to the bandwidth the relay will generate when sending MESSAGE requests towards those recipient URIs. When XCAP is used, this requirement is met by not allowing clients to add more than one URI per HTTP transaction. When a REGISTER transaction is used, this requirement is met by not allowing clients to register more than one contact per REGISTER transaction.
该框架使用基于信用的授权机制来避免上述攻击。它要求用户向翻译添加新的收件人URI，以生成与中继向这些收件人URI发送消息请求时生成的带宽相当的带宽。当使用XCAP时，通过不允许客户端为每个HTTP事务添加多个URI来满足此要求。当使用注册事务时，通过不允许客户在每个注册事务中注册多个联系人来满足此要求。
Relays implementing this framework MUST NOT allow clients to add more than one recipient URI per transaction. If a client using XCAP attempts to add more than one recipient URI in a single HTTP transaction, the XCAP server SHOULD return an HTTP 409 (Conflict) response. The XCAP server SHOULD describe the reason for the refusal in an XML body using the <constraint-failure> element, as described in [RFC4825]. If a client attempts to register more than one contact in a single REGISTER transaction, the registrar SHOULD return a SIP 403 response and explain the reason for the refusal in its reason phrase (e.g., maximum one contact per registration).
实现此框架的中继不得允许客户端为每个事务添加多个收件人URI。如果使用XCAP的客户端试图在单个HTTP事务中添加多个收件人URI，则XCAP服务器应返回HTTP 409（冲突）响应。XCAP服务器应该使用<constraint failure>元素在XML正文中描述拒绝的原因，如[RFC4825]中所述。如果客户试图在单个注册交易中注册多个联系人，注册官应返回SIP 403响应，并在其原因短语中解释拒绝的原因（例如，每次注册最多一个联系人）。
Clients need a way to be informed about the status of the operations they requested. Otherwise, users can be waiting for an operation to succeed when it has actually already failed. In particular, if the target of the request for consent was not reachable and did not have an associated store-and-forward server, the client needs to know to retry the request later. The Pending Additions SIP event package [RFC5362] is a way to provide clients with that information.
客户需要一种方法来了解他们请求的操作状态。否则，当操作实际已经失败时，用户可以等待操作成功。特别是，如果无法访问同意请求的目标，并且没有关联的存储转发服务器，则客户端需要知道稍后是否重试该请求。未决添加SIP事件包[RFC5362]是向客户机提供该信息的一种方法。
Clients can use the Pending Additions SIP event package to be informed about the status of the operations they requested. That is, the client will be informed when an operation (e.g., the addition of a recipient URI to a relay's translation logic) is authorized (and thus executed) or rejected. Clients use the target URI of the SIP translation being manipulated to subscribe to the 'pending-additions' event package.
客户机可以使用挂起的添加SIP事件包来了解其请求的操作的状态。也就是说，当操作（例如，将接收者URI添加到中继的翻译逻辑）被授权（并因此被执行）或被拒绝时，将通知客户端。客户端使用正在处理的SIP转换的目标URI订阅“挂起的添加”事件包。
In our example, after receiving the response from the relay (2), user A subscribes to the Pending Additions event package at the relay (5). This subscription keeps user A informed about the status of the permissions (e.g., granted or denied) the relay will obtain.
在我们的示例中，在接收到来自中继器（2）的响应后，用户A订阅中继器（5）处的未决添加事件包。此订阅使用户A了解中继将获得的权限状态（例如，已授予或已拒绝）。
Relays SHOULD support the Pending Additions SIP event package specified in [RFC5362].
继电器应支持[RFC5362]中规定的待添加SIP事件包。
A relay requests permissions from potential recipients to add them to its translation logic using MESSAGE requests. In our example, on receiving the request to add user B to the translation logic of the relay (1), the relay generates a MESSAGE request (3) towards 'sip:B@example.com'. This MESSAGE request carries a permission document, which describes the translation that needs to be authorized and carries a set of URIs to be used by the recipient to grant or to deny the relay permission to perform that translation. Since user B is offline, the MESSAGE request will be buffered by user B's store-and-forward server. User B will later go online and authorize the translation by using one of those URIs, as described in Section 5.6. The MESSAGE request also carries a body part that contains the same information as the permission document but in a human-readable format.
中继从潜在收件人请求权限，以使用消息请求将其添加到其翻译逻辑中。在我们的示例中，在接收到将用户B添加到中继器（1）的翻译逻辑的请求时，中继器生成朝向“sip:B@example.com'. 此消息请求包含一个权限文档，该文档描述了需要授权的翻译，并包含一组URI，供收件人用于授予或拒绝执行该翻译的中继权限。由于用户B处于脱机状态，消息请求将由用户B的存储转发服务器缓冲。如第5.6节所述，用户B将稍后联机并使用其中一个URI授权翻译。消息请求还包含一个主体部分，该主体部分包含与权限文档相同的信息，但采用人类可读的格式。
When user B uses one of the URIs in the permission document to grant or deny permissions, the relay needs to make sure that it was actually user B using that URI, and not an attacker. The relay can use any of the methods described in Section 5.6 to authenticate the permission document.
当用户B使用权限文档中的一个URI来授予或拒绝权限时，中继需要确保使用该URI的实际上是用户B，而不是攻击者。中继可以使用第5.6节中描述的任何方法来验证许可文件。
Relays that implement this framework MUST obtain permissions from potential recipients before adding them to their translation logic. Relays request permissions from potential recipients using MESSAGE requests.
实现此框架的中继必须先获得潜在收件人的权限，然后才能将其添加到翻译逻辑中。使用邮件请求中继来自潜在收件人的请求权限。
Section 5.6 describes the methods a relay can use to authenticate those recipients giving the relay permission to perform a particular translation. These methods are SIP identity [RFC4474], P-Asserted-Identity [RFC3325], a return routability test, or SIP digest. Relays that use the method consisting of a return routability test have to send their MESSAGE requests to a SIPS URI, as specified in Section 5.6.
第5.6节描述了中继可用于验证授予中继执行特定翻译权限的收件人的方法。这些方法是SIP标识[RFC4474]、P-断言标识[RFC3325]、返回路由性测试或SIP摘要。按照第5.6节的规定，使用返回路由性测试方法的继电器必须将其消息请求发送到SIPS URI。
MESSAGE requests sent to request permissions MUST include a permission document and SHOULD include a human-readable part in their bodies. The human-readable part contains the same information as the permission document (but in a human-readable format), including the URIs to grant and deny permissions. User agents that do not understand permission documents can still process the request and display it in a sensible way to the user, as they would display any other instant message. This way, even if the user agent does not implement this framework, the (human) user will be able to manually click on the correct URI in order to grant or deny permissions. The following is an example of a MESSAGE request that carries a human-readable part and a permission document, which follows the format specified in [RFC5361], in its body. Not all header fields are shown for simplicity reasons.
发送到请求权限的消息请求必须包含权限文档，并且应该在其正文中包含人类可读的部分。人类可读部分包含与权限文档相同的信息（但格式为人类可读），包括授予和拒绝权限的URI。不理解权限文档的用户代理仍然可以处理请求并以合理的方式向用户显示它，就像它们显示任何其他即时消息一样。这样，即使用户代理没有实现这个框架，（人工）用户也可以手动单击正确的URI来授予或拒绝权限。下面是一个消息请求的示例，该消息请求的正文中包含一个人类可读部分和一个权限文档，该文档遵循[RFC5361]中指定的格式。出于简单的原因，并非所有标题字段都显示出来。
MESSAGE sip:bob@example.org SIP/2.0
From: <sip:alices-friends@example.com>;tag=12345678
To: <sip:bob@example.org>
Content-Type: multipart/mixed;boundary="boundary1"
MESSAGE sip:bob@example.org SIP/2.0
From: <sip:alices-friends@example.com>;tag=12345678
To: <sip:bob@example.org>
Content-Type: multipart/mixed;boundary="boundary1"
--boundary1
Content-Type: text/plain
--boundary1
Content-Type: text/plain
If you consent to receive traffic sent to
<sip:alices-friends@example.com>, please use one of the following
URIs: <sips:grant-1awdch5Fasddfce34@example.com> or
<https://example.com/grant-1awdch5Fasddfce34>. Otherwise, use one of
the following URIs: <sips:deny-23rCsdfgvdT5sdfgye@example.com> or
<https://example.com/deny-23rCsdfgvdT5sdfgye>.
--boundary1
Content-Type: application/auth-policy+xml
If you consent to receive traffic sent to
<sip:alices-friends@example.com>, please use one of the following
URIs: <sips:grant-1awdch5Fasddfce34@example.com> or
<https://example.com/grant-1awdch5Fasddfce34>. Otherwise, use one of
the following URIs: <sips:deny-23rCsdfgvdT5sdfgye@example.com> or
<https://example.com/deny-23rCsdfgvdT5sdfgye>.
--boundary1
Content-Type: application/auth-policy+xml
<?xml version="1.0" encoding="UTF-8"?>
<cp:ruleset
xmlns="urn:ietf:params:xml:ns:consent-rules"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<cp:rule id="f1">
<cp:conditions>
<cp:identity>
<cp:many/>
</cp:identity>
<recipient>
<cp:one id="sip:bob@example.org"/>
</recipient>
<target>
<cp:one id="sip:alices-friends@example.com"/>
</target>
<?xml version="1.0" encoding="UTF-8"?>
<cp:ruleset
xmlns="urn:ietf:params:xml:ns:consent-rules"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<cp:rule id="f1">
<cp:conditions>
<cp:identity>
<cp:many/>
</cp:identity>
<recipient>
<cp:one id="sip:bob@example.org"/>
</recipient>
<target>
<cp:one id="sip:alices-friends@example.com"/>
</target>
</cp:conditions>
<cp:actions>
<trans-handling
perm-uri="sips:grant-1awdch5Fasddfce34@example.com">
grant</trans-handling>
<trans-handling
perm-uri="https://example.com/grant-1awdch5Fasddfce34">
grant</trans-handling>
<trans-handling
perm-uri="sips:deny-23rCsdfgvdT5sdfgye@example.com">
deny</trans-handling>
<trans-handling
perm-uri="https://example.com/deny-23rCsdfgvdT5sdfgye">
deny</trans-handling>
</cp:actions>
<cp:transformations/>
</cp:rule>
</cp:ruleset>
--boundary1--
</cp:conditions>
<cp:actions>
<trans-handling
perm-uri="sips:grant-1awdch5Fasddfce34@example.com">
grant</trans-handling>
<trans-handling
perm-uri="https://example.com/grant-1awdch5Fasddfce34">
grant</trans-handling>
<trans-handling
perm-uri="sips:deny-23rCsdfgvdT5sdfgye@example.com">
deny</trans-handling>
<trans-handling
perm-uri="https://example.com/deny-23rCsdfgvdT5sdfgye">
deny</trans-handling>
</cp:actions>
<cp:transformations/>
</cp:rule>
</cp:ruleset>
--boundary1--
A permission document is the representation (e.g., encoded in XML) of a permission. A permission document contains several pieces of data:
权限文档是权限的表示（例如，用XML编码）。权限文档包含多个数据段：
Identity of the Sender: A URI representing the identity of the sender for whom permissions are granted.
发送者标识：表示被授予权限的发送者标识的URI。
Identity of the Original Recipient: A URI representing the identity of the original recipient, which is used as the input for the translation operation. This is also called the target URI.
原始收件人标识：表示原始收件人标识的URI，用作翻译操作的输入。这也称为目标URI。
Identity of the Final Recipient: A URI representing the result of the translation. The permission grants ability for the sender to send requests to the target URI and for a relay receiving those requests to forward them to this URI. This is also called the recipient URI.
最终收件人的标识：表示翻译结果的URI。该权限授予发送方向目标URI发送请求的能力，并授予接收这些请求的中继将请求转发到此URI的能力。这也称为收件人URI。
URIs to Grant Permission: URIs that recipients can use to grant the relay permission to perform the translation described in the document. Relays MUST support the use of SIP and SIPS URIs in permission documents and MAY support the use of HTTP and HTTPS URIs.
授予权限的URI：收件人可用于授予中继权限以执行文档中描述的翻译的URI。中继必须支持在许可文档中使用SIP和SIPS URI，并且可能支持使用HTTP和HTTPS URI。
URIs to Deny Permission: URIs that recipients can use to deny the relay permission to perform the translation described in the document. Relays MUST support the use of SIP and SIPS URIs in permission documents and MAY support the use of HTTP and HTTPS URIs.
拒绝权限的URI：收件人可用于拒绝中继权限以执行文档中描述的翻译的URI。中继必须支持在许可文档中使用SIP和SIPS URI，并且可能支持使用HTTP和HTTPS URI。
Permission documents can contain wildcards. For example, a permission document can request permission for any relay to forward requests coming from a particular sender to a particular recipient. Such a permission document would apply to any target URI. That is, the field containing the identity of the original recipient would match any URI. However, the recipient URI MUST NOT be wildcarded.
权限文档可以包含通配符。例如，权限文档可以请求任何中继的权限，以将来自特定发件人的请求转发给特定收件人。这样的权限文档将应用于任何目标URI。也就是说，包含原始收件人身份的字段将匹配任何URI。但是，收件人URI不能为通配符。
Entities implementing this framework MUST support the format for permission documents defined in [RFC5361] and MAY support other formats.
实现此框架的实体必须支持[RFC5361]中定义的权限文档格式，并且可以支持其他格式。
In our example, the permission document in the MESSAGE request (3) sent by the relay contains the following values:
在我们的示例中，中继发送的消息请求（3）中的权限文档包含以下值：
Identity of the Sender: Any sender
发件人身份：任何发件人
Identity of the Original Recipient: sip:friends@example.com
Identity of the Original Recipient: sip:friends@example.com
Identity of the Final Recipient: sip:B@example.com
Identity of the Final Recipient: sip:B@example.com
URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com
URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com
URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34
URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34
URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com
URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com
URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye
URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye
It is expected that the Sender field often contains a wildcard. However, scenarios involving request-contained URI lists, such as the one described in Section 5.9, can require permission documents that apply to a specific sender. In cases where the identity of the sender matters, relays MUST authenticate senders.
发件人字段通常包含通配符。但是，涉及包含请求的URI列表的场景（如第5.9节所述）可能需要应用于特定发件人的权限文档。在发送方身份重要的情况下，中继必须对发送方进行身份验证。
On receiving the MESSAGE request (3), user B's store-and-forward server stores it because user B is offline at that point. When user B goes online, user B fetches all the requests its store-and-forward server has stored (9).
在接收到消息请求（3）时，用户B的存储转发服务器将其存储，因为此时用户B处于脱机状态。当用户B联机时，用户B获取其存储转发服务器存储的所有请求（9）。
A recipient gives a relay permission to execute the translation described in a permission document by sending a SIP PUBLISH or an HTTP GET request to one of the URIs to grant permissions contained in the document. Similarly, a recipient denies a relay permission to execute the translation described in a permission document by sending a SIP PUBLISH or an HTTP GET request to one of the URIs to deny permissions contained in the document. Requests to grant or deny permissions contain an empty body.
收件人通过向其中一个URI发送SIP PUBLISH或HTTP GET请求来授予文档中包含的权限，从而授予中继权限以执行权限文档中描述的翻译。类似地，收件人通过向其中一个URI发送SIP PUBLISH或HTTP GET请求来拒绝执行权限文档中描述的翻译的中继权限，以拒绝文档中包含的权限。授予或拒绝权限的请求包含空正文。
In our example, user B obtains the permission document (10) that was received earlier by its store-and-forward server in the MESSAGE request (3). User B authorizes the translation described in the permission document received by sending a PUBLISH request (11) to the SIP URI to grant permissions contained in the permission document.
在我们的示例中，用户B获得其存储转发服务器在消息请求（3）中先前接收到的权限文档（10）。用户B通过向SIP URI发送发布请求（11）来授权所接收的许可文档中描述的翻译，以授予包含在许可文档中的许可。
Relays MUST ensure that the SIP PUBLISH or the HTTP GET request received was generated by the recipient of the translation and not by an attacker. Relays can use four methods to authenticate those requests: SIP identity, P-Asserted-Identity [RFC3325], a return routability test, or SIP digest. While return routability tests can be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP identity, P-Asserted-Identity, and SIP digest can only be used to authenticate SIP PUBLISH requests. SIP digest can only be used to authenticate recipients that share a secret with the relay (e.g., recipients that are in the same domain as the relay).
中继必须确保收到的SIP发布或HTTP GET请求是由翻译的接收者生成的，而不是由攻击者生成的。中继可以使用四种方法来验证这些请求：SIP-identity、P-Asserted-identity[RFC3325]、返回路由性测试或SIP摘要。虽然返回路由性测试可用于验证SIP发布和HTTP GET请求，但SIP标识、P-Asserted-identity和SIP摘要只能用于验证SIP发布请求。SIP摘要只能用于验证与中继共享机密的收件人（例如，与中继位于同一域中的收件人）。
The SIP identity [RFC4474] mechanism can be used to authenticate the sender of a PUBLISH request. The relay MUST check that the originator of the PUBLISH request is the owner of the recipient URI in the permission document. Otherwise, the PUBLISH request SHOULD be responded with a 401 (Unauthorized) response and MUST NOT be processed further.
SIP标识[RFC4474]机制可用于验证发布请求的发送方。中继必须检查发布请求的发起人是否是权限文档中收件人URI的所有者。否则，发布请求应以401（未经授权）响应响应，并且不得进一步处理。
The P-Asserted-Identity [RFC3325] mechanism can also be used to authenticate the sender of a PUBLISH request. However, as discussed in [RFC3325], this mechanism is intended to be used only within networks of trusted SIP servers. That is, the use of this mechanism is only applicable inside an administrative domain with previously agreed-upon policies.
P-Asserted-Identity[RFC3325]机制还可用于对发布请求的发送方进行身份验证。但是，如[RFC3325]中所述，该机制仅用于可信SIP服务器的网络中。也就是说，此机制的使用仅适用于具有先前商定的策略的管理域内。
The relay MUST check that the originator of the PUBLISH request is the owner of the recipient URI in the permission document. Otherwise, the PUBLISH request SHOULD be responded with a 401 (Unauthorized) response and MUST NOT be processed further.
中继必须检查发布请求的发起人是否是权限文档中收件人URI的所有者。否则，发布请求应以401（未经授权）响应响应，并且不得进一步处理。
SIP identity provides a good authentication mechanism for incoming PUBLISH requests. Nevertheless, SIP identity is not widely available on the public Internet yet. That is why an authentication mechanism that can already be used at this point is needed.
SIP标识为传入的发布请求提供了良好的身份验证机制。然而，SIP身份尚未在公共互联网上广泛使用。这就是为什么现在需要一个已经可以使用的身份验证机制。
Return routability tests do not provide the same level of security as SIP identity, but they provide a better-than-nothing security level in architectures where the SIP identity mechanism is not available (e.g., the current Internet). The relay generates an unguessable URI (i.e., with a cryptographically random user part) and places it in the permission document in the MESSAGE request (3). The recipient needs to send a SIP PUBLISH request or an HTTP GET request to that URI. Any incoming request sent to that URI SHOULD be considered authenticated by the relay.
返回路由性测试不提供与SIP标识相同的安全级别，但在SIP标识机制不可用的体系结构（例如，当前Internet）中，它们提供了比没有更好的安全级别。中继生成一个不可用的URI（即，具有加密随机用户部分），并将其放置在消息请求（3）中的权限文档中。收件人需要向该URI发送SIP发布请求或HTTP GET请求。发送到该URI的任何传入请求都应被视为已由中继进行身份验证。
Note that the return routability method is the only one that allows the use of HTTP URIs in permission documents. The other methods require the use of SIP URIs.
注意，returnroutability方法是唯一允许在权限文档中使用httpuri的方法。其他方法需要使用SIPURI。
Relays using a return routability test to perform this authentication MUST send the MESSAGE request with the permission document to a SIPS URI. This ensures that attackers do not get access to the (unguessable) URI. Thus, the only user able to use the (unguessable) URI is the receiver of the MESSAGE request. Similarly, permission documents sent by relays using a return routability test MUST only contain secure URIs (i.e., SIPS and HTTPS) to grant and deny permissions. A part of these URIs (e.g., the user part of a SIPS URI) MUST be cryptographically random with at least 32 bits of randomness.
使用返回可路由性测试执行此身份验证的中继必须将带有权限文档的消息请求发送到SIPS URI。这可确保攻击者无法访问（不可用）URI。因此，唯一能够使用（unguessable）URI的用户是消息请求的接收者。类似地，使用返回可路由性测试的中继发送的权限文档必须仅包含用于授予和拒绝权限的安全URI（即SIP和HTTPS）。这些URI的一部分（例如，SIPS URI的用户部分）必须是加密随机的，具有至少32位的随机性。
Relays can transition from return routability tests to SIP identity by simply requiring the use of SIP identity for incoming PUBLISH requests. That is, such a relay would reject PUBLISH requests that did not use SIP identity.
通过简单地要求对传入的发布请求使用SIP标识，中继可以从返回路由性测试过渡到SIP标识。也就是说，这样的中继将拒绝不使用SIP标识的发布请求。
The SIP digest mechanism can be used to authenticate the sender of a PUBLISH request as long as that sender shares a secret with the relay. The relay MUST check that the originator of the PUBLISH request is the owner of the recipient URI in the permission document. Otherwise, the PUBLISH request SHOULD be responded with a 401 (Unauthorized) response and MUST NOT be processed further.
SIP摘要机制可用于对发布请求的发送方进行身份验证，只要该发送方与中继共享一个秘密。中继必须检查发布请求的发起人是否是权限文档中收件人URI的所有者。否则，发布请求应以401（未经授权）响应响应，并且不得进一步处理。
On receiving the PUBLISH request (11), the relay sends a NOTIFY request (13) to inform user A that the permission for the translation has been received and that the translation logic at the relay has been updated. That is, 'sip:B@example.com' has been added as a recipient URI.
在接收到发布请求（11）时，中继器发送通知请求（13），以通知用户a已经接收到翻译的许可并且中继器处的翻译逻辑已经更新。即"sip:B@example.com'已添加为收件人URI。
At any time, if a recipient wants to revoke any permission, it uses the URI it received in the permission document to deny the permissions it previously granted. If a recipient loses this URI for some reason, it needs to wait until it receives a new request produced by the translation. Such a request will contain a Trigger-Consent header field with a URI. That Trigger-Consent header field will have a target-uri header field parameter identifying the target URI of the translation. The recipient needs to send a PUBLISH request with an empty body to the URI in the Trigger-Consent header field in order to receive a MESSAGE request from the relay. Such a MESSAGE request will contain a permission document with a URI to revoke the permission that was previously granted.
在任何时候，如果收件人想要撤销任何权限，它都会使用在权限文档中收到的URI来拒绝以前授予的权限。如果收件人由于某种原因丢失此URI，则需要等待，直到收到翻译生成的新请求。这样的请求将包含一个带有URI的触发器同意标头字段。该触发器同意标头字段将具有一个目标uri标头字段参数，用于标识翻译的目标uri。收件人需要向Trigger Approvement header字段中的URI发送一个正文为空的发布请求，以便从中继接收消息请求。这样的消息请求将包含一个权限文档，该文档具有一个URI，用于撤销先前授予的权限。
Figure 5 shows an example of how a user that lost the URI to revoke permissions at a relay can obtain a new URI using the Trigger-Consent header field of an incoming request. The user rejects an incoming INVITE (1) request, which contains a Trigger-Consent header field. Using the URI in that header field, the user sends a PUBLISH request (4) to the relay. On receiving the PUBLISH request (4), the relay generates a MESSAGE request (6) towards the user. Finally, the user revokes the permissions by sending a PUBLISH request (8) to the relay.
图5显示了一个示例，该示例演示了在中继上丢失URI以撤销权限的用户如何使用传入请求的触发器同意标头字段获得新的URI。用户拒绝包含触发器同意标头字段的传入INVITE（1）请求。使用该头字段中的URI，用户向中继发送发布请求（4）。在接收到发布请求（4）时，中继向用户生成消息请求（6）。最后，用户通过向中继发送发布请求（8）来撤销权限。
Relay B@example.com
|(1) INVITE |
| Trigger-Consent: sip:123@relay.example.com
| ;target-uri="sip:friends@relay.example.com"
|---------------------------->|
|(2) 603 Decline |
|<----------------------------|
|(3) ACK |
|---------------------------->|
|(4) PUBLISH sip:123@relay.example.com
|<----------------------------|
|(5) 200 OK |
|---------------------------->|
|(6) MESSAGE sip:B@example |
| Permission Document |
|---------------------------->|
|(7) 200 OK |
|<----------------------------|
|(8) PUBLISH uri-deny |
|<----------------------------|
|(9) 200 OK |
|---------------------------->|
Relay B@example.com
|(1) INVITE |
| Trigger-Consent: sip:123@relay.example.com
| ;target-uri="sip:friends@relay.example.com"
|---------------------------->|
|(2) 603 Decline |
|<----------------------------|
|(3) ACK |
|---------------------------->|
|(4) PUBLISH sip:123@relay.example.com
|<----------------------------|
|(5) 200 OK |
|---------------------------->|
|(6) MESSAGE sip:B@example |
| Permission Document |
|---------------------------->|
|(7) 200 OK |
|<----------------------------|
|(8) PUBLISH uri-deny |
|<----------------------------|
|(9) 200 OK |
|---------------------------->|
Figure 5: Permission Revocation
图5：权限撤销
In the scenarios described so far, a user adds recipient URIs to the translation logic of a relay. However, the relay does not perform translations towards those recipient URIs until permissions are obtained.
在目前描述的场景中，用户将收件人URI添加到中继的转换逻辑中。但是，在获得权限之前，中继不会对这些收件人URI执行翻译。
URI-list services using request-contained URI lists are a special case because the selection of recipient URIs is performed at the same time as the communication attempt. A user places a set of recipient URIs in a request and sends it to a relay so that the relay sends a similar request to all those recipient URIs.
使用包含请求的URI列表的URI列表服务是一种特殊情况，因为在通信尝试的同时执行收件人URI的选择。用户在请求中放置一组接收方URI，并将其发送到中继，以便中继向所有这些接收方URI发送类似的请求。
Relays implementing this consent framework and providing request-contained URI-list services behave in a slightly different way than the relays described so far. This type of relay also maintains a list of recipient URIs for which permissions have been received. Clients also manipulate this list using a manipulation mechanism (e.g., XCAP). Nevertheless, this list does not represent the recipient URIs of every translation performed by the relay. This list just represents all the recipient URIs for which permissions have been received -- that is, the set of URIs that will be accepted
实现此同意框架并提供包含请求的URI列表服务的中继的行为方式与目前描述的中继稍有不同。这种类型的中继还维护已收到其权限的收件人URI的列表。客户端还使用操纵机制（例如，XCAP）操纵此列表。然而，此列表并不表示中继执行的每个翻译的收件人URI。此列表仅表示已接收权限的所有收件人URI，即将接受的URI集
if a request containing a URI-list arrives to the relay. This set of URIs is a superset of the recipient URIs of any particular translation the relay performs.
如果包含URI列表的请求到达中继。这组URI是中继执行的任何特定转换的收件人URI的超集。
On receiving a request-contained URI list, the relay checks whether or not it has permissions for all the URIs contained in the incoming URI list. If it does, the relay performs the translation. If it lacks permissions for one or more URIs, the relay MUST NOT perform the translation and SHOULD return an error response.
在接收到包含请求的URI列表时，中继将检查它是否具有对传入URI列表中包含的所有URI的权限。如果是，继电器将执行转换。如果它缺少对一个或多个URI的权限，则中继不得执行转换，并应返回错误响应。
A relay that receives a request-contained URI list with a URI for which the relay has no permissions SHOULD return a 470 (Consent Needed) response. The relay SHOULD add a Permission-Missing header field with the URIs for which the relay has no permissions.
如果中继接收到包含URI列表的请求，而该URI的中继没有权限，则该中继应返回470（需要同意）响应。中继应该添加一个Permission Missing标头字段，其中包含中继没有权限的URI。
Figure 6 shows a relay that receives a request (1) that contains URIs for which the relay does not have permission (the INVITE carries the recipient URIs in its message body). The relay rejects the request with a 470 (Consent Needed) response (2). That response contains a Permission-Missing header field with the URIs for which there was no permission.
图6显示了一个接收请求（1）的中继，该请求包含中继无权访问的URI（INVITE在其消息体中携带收件人URI）。中继以470（需要同意）响应拒绝请求（2）。该响应包含一个Permission Missing header字段，其中的URI没有权限。
A@example.com Relay
A@example.com转发
|(1) INVITE |
| sip:B@example.com |
| sip:C@example.com |
|---------------------->|
|(2) 470 Consent Needed |
| Permission-Missing: sip:C@example.com
|<----------------------|
|(3) ACK |
|---------------------->|
|(1) INVITE |
| sip:B@example.com |
| sip:C@example.com |
|---------------------->|
|(2) 470 Consent Needed |
| Permission-Missing: sip:C@example.com
|<----------------------|
|(3) ACK |
|---------------------->|
Figure 6: INVITE with a URI List in Its Body
图6：主体中包含URI列表的INVITE
A 470 (Consent Needed) response indicates that the request that triggered the response contained a URI list with at least one URI for which the relay had no permissions. A user agent server generating a 470 (Consent Needed) response SHOULD include a Permission-Missing header field in it. This header field carries the URI or URIs for which the relay had no permissions.
470（需要同意）响应表示触发响应的请求包含一个URI列表，其中至少有一个URI是中继没有权限的。生成470（需要同意）响应的用户代理服务器应在其中包含权限缺失标头字段。此标头字段包含中继没有权限的URI或URI。
A user agent client receiving a 470 (Consent Needed) response without a Permission-Missing header field needs to use an alternative mechanism (e.g., XCAP) to discover for which URI or URIs there were no permissions.
如果用户代理客户端接收到470（需要同意）响应而没有权限缺失标头字段，则需要使用替代机制（例如，XCAP）来发现没有权限的URI或URI。
A client receiving a 470 (Consent Needed) response uses a manipulation mechanism (e.g., XCAP) to add those URIs to the relay's list of URIs. The relay will obtain permissions for those URIs as usual.
接收470（需要同意）响应的客户端使用操纵机制（例如，XCAP）将这些uri添加到中继的uri列表中。中继将像往常一样获得这些URI的权限。
Permission-Missing header fields carry URIs for which a relay did not have permissions. The following is the augmented Backus-Naur Form (BNF) [RFC5234] syntax of the Permission-Missing header field. Some of its elements are defined in [RFC3261].
Permission Missing标头字段包含中继没有权限的URI。下面是Permission Missing header字段的扩展的Backus Naur Form（BNF）[RFC5234]语法。其某些元素在[RFC3261]中定义。
Permission-Missing = "Permission-Missing" HCOLON per-miss-spec
*( COMMA per-miss-spec )
per-miss-spec = ( name-addr / addr-spec )
*( SEMI generic-param )
Permission-Missing = "Permission-Missing" HCOLON per-miss-spec
*( COMMA per-miss-spec )
per-miss-spec = ( name-addr / addr-spec )
*( SEMI generic-param )
The following is an example of a Permission-Missing header field:
以下是权限缺少标头字段的示例：
Permission-Missing: sip:C@example.com
Permission-Missing: sip:C@example.com
Even though the example used to specify this framework has been a URI-list service, this framework applies to any type of translation (i.e., not only to URI-list services). Registrations are a different type of translations that deserve discussion.
尽管用于指定此框架的示例是URI列表服务，但此框架适用于任何类型的转换（即，不仅适用于URI列表服务）。注册是一种值得讨论的不同类型的翻译。
Registrations are a special type of translations. The user registering has a trust relationship with the registrar in its home domain. This is not the case when a user gives any type of permissions to a relay in a different domain.
注册是一种特殊类型的翻译。注册用户与注册者在其主域中具有信任关系。当用户向不同域中的中继授予任何类型的权限时，情况并非如此。
Traditionally, REGISTER transactions have performed two operations at the same time: setting up a translation and authorizing the use of that translation. For example, a user registering its current contact URI is giving permission to the registrar to forward traffic sent to the user's AoR (Address of Record) to the registered contact URI. This works fine when the entity registering is the same as the one that will be receiving traffic at a later point (e.g., the entity
传统上，注册事务同时执行两个操作：设置翻译和授权使用该翻译。例如，注册其当前联系人URI的用户正在向注册器授予将发送到用户AoR（记录地址）的流量转发到注册联系人URI的权限。当注册的实体与稍后接收流量的实体相同时（例如，实体
receives traffic over the same connection used for the registration as described in [OUTBOUND]). However, this schema creates some potential attacks that relate to third-party registrations.
通过[OUTBOUND]中所述的用于注册的同一连接接收流量。但是，此模式会创建一些与第三方注册相关的潜在攻击。
An attacker binds, via a registration, his or her AoR with the contact URI of a victim. Now the victim will receive unsolicited traffic that was originally addressed to the attacker.
攻击者通过注册将其AoR与受害者的联系人URI绑定。现在，受害者将收到最初发送给攻击者的未经请求的流量。
The process of authorizing a registration is shown in Figure 7. User A performs a third-party registration (1) and receives a 202 (Accepted) response (2).
授权注册的过程如图7所示。用户A执行第三方注册（1）并接收202（接受的）响应（2）。
Since the relay does not have permission from 'sip:a@ws123.example.com' to perform translations towards that recipient URI, the relay places 'sip:a@ws123.example.com' in the 'pending' state. Once 'sip:a@ws123.example.com' is in the 'Permission Pending' state, the registrar needs to ask 'sip:a@ws123.example.com' for permission by sending a MESSAGE request (3).
由于中继没有“sip”的权限：a@ws123.example.com'要执行针对该收件人URI的翻译，中继将放置'sip:a@ws123.example.com'处于“挂起”状态。一次的sip：a@ws123.example.com'处于“许可待定”状态，注册官需要询问'sip:a@ws123.example.com'通过发送消息请求获得权限（3）。
After receiving the response from the relay (2), user A subscribes to the Pending Additions event package at the registrar (5). This subscription keeps the user informed about the status of the permissions (e.g., granted or denied) the registrar will obtain. The rest of the process is similar to the one described in Section 5.
在接收到来自中继器（2）的响应之后，用户A在注册器（5）处订阅未决添加事件包。此订阅可让用户了解注册器将获得的权限状态（例如，已授予或已拒绝）。该过程的其余部分与第5节中描述的过程类似。
A@example.com Registrar a@ws123.example.com
A@example.com登记员a@ws123.example.com
|(1) REGISTER | |
| Contact: sip:a@ws123.example.com |
|------------------>| |
|(2) 202 Accepted OK| |
|<------------------| |
| |(3) MESSAGE sip:a@ws123.example
| | Permission Document
| |------------------>|
| |(4) 200 OK |
| |<------------------|
|(5) SUBSCRIBE | |
| Event: pending-additions |
|------------------>| |
|(6) 200 OK | |
|<------------------| |
|(7) NOTIFY | |
|<------------------| |
|(8) 200 OK | |
|------------------>| |
| |(9) PUBLISH uri-up |
| |<------------------|
| |(10) 200 OK |
| |------------------>|
|(11) NOTIFY | |
|<------------------| |
|(12) 200 OK | |
|------------------>| |
|(1) REGISTER | |
| Contact: sip:a@ws123.example.com |
|------------------>| |
|(2) 202 Accepted OK| |
|<------------------| |
| |(3) MESSAGE sip:a@ws123.example
| | Permission Document
| |------------------>|
| |(4) 200 OK |
| |<------------------|
|(5) SUBSCRIBE | |
| Event: pending-additions |
|------------------>| |
|(6) 200 OK | |
|<------------------| |
|(7) NOTIFY | |
|<------------------| |
|(8) 200 OK | |
|------------------>| |
| |(9) PUBLISH uri-up |
| |<------------------|
| |(10) 200 OK |
| |------------------>|
|(11) NOTIFY | |
|<------------------| |
|(12) 200 OK | |
|------------------>| |
Figure 7: Registration
图7：登记
Permission documents generated by registrars are typically very general. For example, in one such document a registrar can ask a recipient for permission to forward any request from any sender to the recipient's URI. This is the type of granularity that this framework intends to provide for registrations. Users who want to define how incoming requests are treated with a finer granularity (e.g., requests from user A are only accepted between 9:00 and 11:00) will have to use other mechanisms such as Call Processing Language (CPL) [RFC3880].
注册人生成的许可文件通常非常通用。例如，在一个这样的文档中，注册者可以请求接收者允许将来自任何发送者的任何请求转发到接收者的URI。这是该框架打算为注册提供的粒度类型。想要定义如何以更精细的粒度处理传入请求（例如，来自用户a的请求仅在9:00和11:00之间被接受）的用户必须使用其他机制，如呼叫处理语言（CPL）[RFC3880]。
Note that, as indicated previously, user agents using the same connection to register and to receive traffic from the registrar, as described in [OUTBOUND], do not need to use the mechanism described in this section.
请注意，如前所述，如[出站]中所述，使用相同连接注册和接收来自注册器的流量的用户代理不需要使用本节中所述的机制。
A user agent being registered by a third party can be unable to use the SIP Identity, P-Asserted-Identity, or SIP digest mechanisms to prove to the registrar that the user agent is the owner of the URI being registered (e.g., sip:user@192.0.2.1), which is the recipient URI of the translation. In this case, return routability MUST be used.
由第三方注册的用户代理可能无法使用SIP标识、P-Asserted-Identity或SIP摘要机制来向注册器证明该用户代理是正在注册的URI的所有者（例如，SIP：user@192.0.2.1)，它是翻译的收件人URI。在这种情况下，必须使用返回路由性。
Relays generating traffic towards recipients need to make sure that those recipients can revoke the permissions they gave at any time. The Trigger-Consent helps achieve this.
向收件人生成流量的中继需要确保这些收件人可以随时撤销他们授予的权限。触发同意有助于实现这一点。
A relay executing a translation that involves sending a request to a URI from which permissions were obtained previously SHOULD add a Trigger-Consent header field to the request. The URI in the Trigger-Consent header field MUST have a target-uri header field parameter identifying the target URI of the translation.
执行转换的中继（该转换涉及将请求发送到先前从中获得权限的URI）应向请求添加触发器同意标头字段。触发器同意标头字段中的URI必须具有标识翻译的目标URI的目标URI标头字段参数。
On receiving a PUBLISH request addressed to the URI that a relay previously placed in a Trigger-Consent header field, the relay SHOULD send a MESSAGE request to the corresponding recipient URI with a permission document. Therefore, the relay needs to be able to correlate the URI it places in the Trigger-Consent header field with the recipient URI of the translation.
在接收到中继先前放置在触发器同意标头字段中的URI的发布请求时，中继应向相应的接收方URI发送消息请求以及权限文档。因此，中继需要能够将它放置在触发器同意标头字段中的URI与翻译的接收方URI相关联。
The following is the augmented Backus-Naur Form (BNF) [RFC5234] syntax of the Trigger-Consent header field. Some of its elements are defined in [RFC3261].
以下是触发器同意标头字段的扩展的Backus Naur Form（BNF）[RFC5234]语法。其某些元素在[RFC3261]中定义。
Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec
*( COMMA trigger-cons-spec )
trigger-cons-spec = ( SIP-URI / SIPS-URI )
*( SEMI trigger-param )
trigger-param = target-uri / generic-param
target-uri = "target-uri" EQUAL
LDQUOT *( qdtext / quoted-pair ) RDQUOT
Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec
*( COMMA trigger-cons-spec )
trigger-cons-spec = ( SIP-URI / SIPS-URI )
*( SEMI trigger-param )
trigger-param = target-uri / generic-param
target-uri = "target-uri" EQUAL
LDQUOT *( qdtext / quoted-pair ) RDQUOT
The target-uri header field parameter MUST contain a URI.
目标uri标头字段参数必须包含uri。
The following is an example of a Trigger-Consent header field:
以下是触发器同意标头字段的示例：
Trigger-Consent: sip:123@relay.example.com
;target-uri="sip:friends@relay.example.com"
Trigger-Consent: sip:123@relay.example.com
;target-uri="sip:friends@relay.example.com"
Per the following sections, IANA has registered a SIP response code, two SIP header fields, and a SIP header field parameter.
根据以下章节，IANA注册了一个SIP响应代码、两个SIP头字段和一个SIP头字段参数。
IANA has added the following new response code to the Methods and Response Codes subregistry under the SIP Parameters registry.
IANA向SIP参数注册表下的方法和响应代码子区添加了以下新的响应代码。
Response Code Number: 470 Default Reason Phrase: Consent Needed Reference: [RFC5360]
响应代码：470默认原因短语：需要同意参考：[RFC5360]
IANA has added the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry.
IANA已将以下新SIP头字段添加到SIP参数注册表下的头字段子区。
Header Name: Trigger-Consent Compact Form: (none) Reference: [RFC5360]
标题名称：触发同意契约形式：（无）参考：[RFC5360]
IANA has added the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry.
IANA已将以下新SIP头字段添加到SIP参数注册表下的头字段子区。
Header Name: Permission-Missing Compact Form: (none) Reference: [RFC5360]
标题名称：权限缺少压缩表单：（无）引用：[RFC5360]
IANA has registered the 'target-uri' Trigger-Consent header field parameter under the Header Field Parameters and Parameter Values subregistry within the SIP Parameters registry:
IANA已在SIP参数注册表中的header field Parameters和parameter Values子区下注册了“target uri”触发器同意header field参数：
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Trigger-Consent target-uri No [RFC5360]
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Trigger-Consent target-uri No [RFC5360]
Security has been discussed throughout the whole document. However, there are some issues that deserve special attention.
整个文件中都讨论了安全问题。然而，有一些问题值得特别注意。
Relays generally implement several security mechanisms that relate to client authentication and authorization. Clients are typically authenticated before they can manipulate a relay's translation logic. Additionally, clients are typically also authenticated and sometimes need to perform SPAM prevention tasks [RFC5039] when they send traffic to a relay. It is important that relays implement these types of security mechanisms. However, they fall out of the scope of this framework. Even with these mechanisms in place, there is still a need for relays to implement this framework because the use of these mechanisms does not prevent authorized clients to add recipients to a translation without their consent. Consequently, relays performing translations MUST implement this framework.
中继通常实现若干与客户端身份验证和授权相关的安全机制。客户端通常在操作中继的转换逻辑之前经过身份验证。此外，客户端通常也经过身份验证，有时需要在向中继发送流量时执行垃圾邮件预防任务[RFC5039]。继电器实现这些类型的安全机制非常重要。但是，它们不属于本框架的范围。即使有了这些机制，仍然需要中继来实现这一框架，因为使用这些机制并不妨碍授权客户在未经其同意的情况下向译文添加收件人。因此，执行翻译的中继必须实现这个框架。
Note that, as indicated previously, user agents using the same connection to register and to receive traffic from the registrar, as described in [OUTBOUND], do not need to use this framework. Therefore, a registrar that did not accept third-party registrations would not need to implement this framework.
请注意，如前所述，使用相同连接注册和接收来自注册器的流量的用户代理（如[OUTBOUND]中所述）不需要使用此框架。因此，不接受第三方注册的注册人不需要实施该框架。
As pointed out in Section 5.6.1.3, when return routability tests are used to authenticate recipients granting or denying permissions, the URIs used to grant or deny permissions need to be protected from attackers. SIPS URIs provide a good tool to meet this requirement, as described in [RFC5361]. When store-and-forward servers are used, the interface between a user agent and its store-and-forward server is frequently not based on SIP. In such a case, SIPS cannot be used to secure those URIs. Implementations of store-and-forward servers MUST provide a mechanism for delivering encrypted and integrity-protected messages to their user agents.
正如第5.6.1.3节所指出的，当使用返回可路由性测试对授予或拒绝权限的收件人进行身份验证时，需要保护用于授予或拒绝权限的URI免受攻击者的攻击。如[RFC5361]所述，SIPS URI提供了一个很好的工具来满足这一要求。使用存储转发服务器时，用户代理与其存储转发服务器之间的接口通常不基于SIP。在这种情况下，SIP不能用于保护这些URI。存储转发服务器的实现必须提供一种机制，用于将加密和完整性保护的消息传递给其用户代理。
The information provided by the Pending Additions event package can be sensitive. For this reason, as described in [RFC5362], relays need to use strong means for authentication and information confidentiality. SIPS URIs are a good mechanism to meet this requirement.
挂起的添加事件包提供的信息可能是敏感的。因此，如[RFC5362]所述，继电器需要使用强有力的认证和信息保密手段。SIPS URI是满足这一要求的良好机制。
Permission documents can reveal sensitive information. Attackers may attempt to modify them in order to have clients grant or deny permissions different from the ones they think they are granting or denying. For this reason, it is RECOMMENDED that relays use strong means for information integrity protection and confidentiality when sending permission documents to clients.
许可文件可能会泄露敏感信息。攻击者可能试图修改这些权限，以使客户端授予或拒绝与其认为授予或拒绝的权限不同的权限。因此，建议中继在向客户发送许可文件时使用强大的信息完整性保护和保密手段。
The mechanism used for conveying information to clients SHOULD ensure the integrity and confidentially of the information. In order to achieve these, an end-to-end SIP encryption mechanism, such as S/MIME, as described in [RFC3261], SHOULD be used.
用于向客户传达信息的机制应确保信息的完整性和保密性。为了实现这些，应使用端到端SIP加密机制，如[RFC3261]中所述的S/MIME。
If strong end-to-end security means (such as above) are not available, it is RECOMMENDED that hop-by-hop security based on TLS and SIPS URIs, as described in [RFC3261], is used.
如果没有强大的端到端安全手段（如上述），建议使用基于TLS和SIPS URI的逐跳安全，如[RFC3261]中所述。
Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided useful ideas on this document. Ben Campbell, AC Mahendran, Keith Drage, and Mary Barnes performed a thorough review of this document.
Henning Schulzrinne、Jon Peterson和Cullen Jennings就本文件提供了有用的想法。Ben Campbell、AC Mahendran、Keith Drage和Mary Barnes对该文件进行了全面审查。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Ed.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5361] Camarillo, G., "A Document Format for Requesting Consent", RFC 5361, October 2008.
[RFC5361]Camarillo，G.“请求同意的文件格式”，RFC 5361，2008年10月。
[RFC5362] Camarillo, G., "The Session Initiation Protocol (SIP) Pending Additions Event Package", RFC 5362, October 2008.
[RFC5362]Camarillo，G.“会话启动协议（SIP）待添加事件包”，RFC 5362，2008年10月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]Camarillo，G.和A.B.Roach，“会话启动协议（SIP）URI列表服务的框架和安全注意事项”，RFC 5363，2008年10月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004.
[RFC3880]Lennox，J.，Wu，X.，和H.Schulzrinne，“呼叫处理语言（CPL）：互联网电话服务的用户控制语言”，RFC 3880，2004年10月。
[RFC4453] Rosenberg, J., Camarillo, G., Ed., and D. Willis, "Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)", RFC 4453, April 2006.
[RFC4453]Rosenberg，J.，Camarillo，G.，Ed.，和D.Willis，“会话启动协议（SIP）中基于同意的通信要求”，RFC 4453，2006年4月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]Rosenberg，J.，“用于表示资源列表的可扩展标记语言（XML）格式”，RFC 4826，2007年5月。
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC5039]Rosenberg，J.和C.Jennings，“会话启动协议（SIP）和垃圾邮件”，RFC 5039，2008年1月。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, June 2007.
[OUTBOUND]Jennings，C.和R.Mahy，“在会话启动协议（SIP）中管理客户端启动的连接”，正在进行的工作，2007年6月。
Authors' Addresses
作者地址
Jonathan Rosenberg Cisco Iselin, NJ 08830 USA
Jonathan Rosenberg Cisco Iselin，NJ 08830美国
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
冈萨洛·卡马里洛（编辑）爱立信·赫萨兰蒂11号乔瓦斯02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Dean Willis Unaffiliated 3100 Independence Pkwy #311-164 Plano, TX 75075 USA
迪安·威利斯，美国德克萨斯州普莱诺市3100独立公园311-164号，邮编75075
EMail: dean.willis@softarmor.com
EMail: dean.willis@softarmor.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.