Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8599 Ericsson
Category: Standards Track M. Arnold
ISSN: 2070-1721 Metaswitch Networks
May 2019
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8599 Ericsson
Category: Standards Track M. Arnold
ISSN: 2070-1721 Metaswitch Networks
May 2019
Push Notification with the Session Initiation Protocol (SIP)
使用会话启动协议（SIP）的推送通知
Abstract
摘要
This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism.
本文档描述了如何使用推送通知服务（PNS）唤醒具有推送通知的挂起会话发起协议（SIP）用户代理（UA），并且还描述了UA如何在UA可能被挂起的环境中发送绑定刷新寄存器请求和接收传入SIP请求。该文档定义了新的SIP URI参数，以在UA和SIP实体之间交换PNS信息，然后SIP实体将请求向UA发送推送通知。它还定义了触发此类推送通知请求的参数。该文档还定义了新的功能能力指标，可用于指示对该机制的支持。
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 https://www.rfc-editor.org/info/rfc8599.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8599.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 8
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 9
4.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Request Push Notifications . . . . . . . . . . . . . 9
4.1.2. Disable Push Notifications . . . . . . . . . . . . . 11
4.1.3. Receive Push Notifications . . . . . . . . . . . . . 11
4.1.4. Sending Binding-Refresh Requests Using Non-push
Mechanism . . . . . . . . . . . . . . . . . . . . . . 11
4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 13
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 14
5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 14
5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 15
5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 15
5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 15
5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 16
5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 17
5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 17
5.6.2. Initial Request for Dialog or Standalone Request . . 20
6. Support of Long-Lived SIP Dialogs . . . . . . . . . . . . . . 23
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 25
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 25
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 25
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 26
6.2.3. Mid-dialog Request . . . . . . . . . . . . . . . . . 26
7. Support of SIP Replaces . . . . . . . . . . . . . . . . . . . 27
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 8
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 9
4.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Request Push Notifications . . . . . . . . . . . . . 9
4.1.2. Disable Push Notifications . . . . . . . . . . . . . 11
4.1.3. Receive Push Notifications . . . . . . . . . . . . . 11
4.1.4. Sending Binding-Refresh Requests Using Non-push
Mechanism . . . . . . . . . . . . . . . . . . . . . . 11
4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 13
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 14
5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 14
5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 15
5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 15
5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 15
5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 16
5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 17
5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 17
5.6.2. Initial Request for Dialog or Standalone Request . . 20
6. Support of Long-Lived SIP Dialogs . . . . . . . . . . . . . . 23
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 25
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 25
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 25
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 26
6.2.3. Mid-dialog Request . . . . . . . . . . . . . . . . . 26
7. Support of SIP Replaces . . . . . . . . . . . . . . . . . . . 27
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. 'sip.pns' Feature-Capability Indicator . . . . . . . . . 28
8.3. 'sip.vapid' Feature-Capability Indicator . . . . . . . . 28
8.4. 'sip.pnsreg' Feature-Capability Indicator . . . . . . . . 28
8.5. 'sip.pnsreg' Media Feature Tag . . . . . . . . . . . . . 29
8.6. 'sip.pnspurr' Feature-Capability Indicator . . . . . . . 29
8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 29
9. PNS Registration Requirements . . . . . . . . . . . . . . . . 30
10. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for
Apple Push Notification service . . . . . . . . . . . . . . . 30
11. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for
Google Firebase Cloud Messaging (FCM) Push Notification
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for
RFC 8030 (Generic Event Delivery Using HTTP Push) . . . . . . 31
13. Security Considerations . . . . . . . . . . . . . . . . . . . 32
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 33
14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 33
14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 33
14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 33
14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 33
14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 34
14.2.1. 555 (Push Notification Service Not Supported) . . . 34
14.3. SIP Global Feature-Capability Indicator . . . . . . . . 34
14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 34
14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 34
14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 35
14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 35
14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 36
14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 36
14.5. PNS Subregistry Establishment . . . . . . . . . . . . . 36
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.1. Normative References . . . . . . . . . . . . . . . . . . 37
15.2. Informative References . . . . . . . . . . . . . . . . . 39
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. 'sip.pns' Feature-Capability Indicator . . . . . . . . . 28
8.3. 'sip.vapid' Feature-Capability Indicator . . . . . . . . 28
8.4. 'sip.pnsreg' Feature-Capability Indicator . . . . . . . . 28
8.5. 'sip.pnsreg' Media Feature Tag . . . . . . . . . . . . . 29
8.6. 'sip.pnspurr' Feature-Capability Indicator . . . . . . . 29
8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 29
9. PNS Registration Requirements . . . . . . . . . . . . . . . . 30
10. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for
Apple Push Notification service . . . . . . . . . . . . . . . 30
11. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for
Google Firebase Cloud Messaging (FCM) Push Notification
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for
RFC 8030 (Generic Event Delivery Using HTTP Push) . . . . . . 31
13. Security Considerations . . . . . . . . . . . . . . . . . . . 32
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 33
14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 33
14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 33
14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 33
14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 33
14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 34
14.2.1. 555 (Push Notification Service Not Supported) . . . 34
14.3. SIP Global Feature-Capability Indicator . . . . . . . . 34
14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 34
14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 34
14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 35
14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 35
14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 36
14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 36
14.5. PNS Subregistry Establishment . . . . . . . . . . . . . 36
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.1. Normative References . . . . . . . . . . . . . . . . . . 37
15.2. Informative References . . . . . . . . . . . . . . . . . 39
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
In order to save resources such as battery life, some devices (especially mobile devices) and operating systems will suspend an application that is not in use. A suspended application might not be able to wake itself with internal timers and might not be awakened by incoming network traffic. In such an environment, a Push Notification Service (PNS) is used to wake the application. A PNS is a service that sends messages requested by other applications to a user application in order to wake the user application. These messages are called push notifications. Push notifications might contain payload data, depending on the application. An application can request that a push notification be sent to a single user application or to multiple user applications.
为了节省电池寿命等资源，某些设备（尤其是移动设备）和操作系统将暂停未使用的应用程序。挂起的应用程序可能无法使用内部计时器唤醒自身，也可能无法被传入的网络流量唤醒。在这样的环境中，推送通知服务（PNS）用于唤醒应用程序。PNS是将其他应用程序请求的消息发送到用户应用程序以唤醒用户应用程序的服务。这些消息称为推送通知。推送通知可能包含有效负载数据，具体取决于应用程序。应用程序可以请求向单个用户应用程序或多个用户应用程序发送推送通知。
Typically, each operating system uses a dedicated PNS. Different PNSs exist today. Some are based on the standardized mechanism defined in [RFC8030], while others are proprietary. For example, Apple iOS devices use the Apple Push Notification service (APNs) while Android devices use the Firebase Cloud Messaging (FCM) service. Each PNS uses PNS-specific terminology and function names. The terminology in this document is meant to be PNS-independent. If the PNS is based on [RFC8030], the SIP proxy takes the role of the application server.
通常，每个操作系统都使用专用的PNS。今天存在着不同的PNS。一些基于[RFC8030]中定义的标准化机制，而另一些是专有的。例如，苹果iOS设备使用苹果推送通知服务（APNs），而Android设备使用Firebase云消息服务（FCM）。每个PNS使用特定于PNS的术语和函数名。本文件中的术语与PNS无关。如果PNS基于[RFC8030]，SIP代理将扮演应用服务器的角色。
When a Session Initiation Protocol (SIP) User Agent (UA)[RFC3261] is suspended in such an environment, it is unable to send binding-refresh SIP REGISTER requests, unable to receive incoming SIP requests, and might not be able to use internal timers to wake itself. A suspended UA will not be able to maintain connections, e.g., using the SIP Outbound Mechanism [RFC5626], because it cannot send periodic keep-alive messages. A PNS is needed to wake the SIP UA so that the UA can perform these functions.
当会话发起协议（SIP）用户代理（UA）[RFC3261]在这种环境中挂起时，它无法发送绑定刷新SIP寄存器请求，无法接收传入SIP请求，并且可能无法使用内部计时器来唤醒自身。挂起的UA将无法维持连接，例如，使用SIP出站机制[RFC5626]，因为它无法发送定期保持活动的消息。需要PNS来唤醒SIP UA，以便UA能够执行这些功能。
This document describes how a PNS can be used to wake a suspended UA using push notifications, so that the UA can send binding-refresh REGISTER requests and receive incoming SIP requests. The document defines new SIP URI parameters and new feature-capability indicators [RFC6809] that can be used in SIP messages to indicate support of the mechanism defined in this document; be used to exchange PNS information between the UA and the SIP entity (realized as a SIP proxy in this document) that will request that push notifications are sent to the UA; and be used to request such push notification requests.
本文档描述了如何使用PNS使用推送通知唤醒挂起的UA，以便UA可以发送绑定刷新寄存器请求并接收传入的SIP请求。本文件定义了新的SIP URI参数和新的功能能力指标[RFC6809]，可在SIP消息中使用，以表明对本文件中定义的机制的支持；用于在UA和SIP实体（在本文档中实现为SIP代理）之间交换PNS信息，该实体将请求向UA发送推送通知；并用于请求此类推送通知请求。
NOTE: Even if a UA is able to be awakened by means other than receiving push notifications (e.g., by using internal timers) in order to send periodic binding-refresh REGISTER requests, it might still be useful to suspend the UA between the sending of binding-refresh requests (as it will save battery life) and use push notifications to wake the UA when an incoming SIP request UA arrives.
注意：即使UA能够通过接收推送通知以外的方式（例如，通过使用内部定时器）被唤醒，以便发送定期绑定刷新寄存器请求，在发送绑定刷新请求之间暂停UA可能仍然有用（因为这将节省电池寿命）当传入SIP请求UA到达时，使用推送通知唤醒UA。
When a UA registers with a PNS (Figure 1), it will receive a unique Push Resource ID (PRID) associated with the push notification registration. The UA will use a REGISTER request to provide the PRID to the SIP proxy, which will then request that push notifications are sent to the UA.
当UA向PNS注册时（图1），它将收到与推送通知注册相关联的唯一推送资源ID（PRID）。UA将使用注册请求向SIP代理提供PRID，然后SIP代理将请求向UA发送推送通知。
When the SIP proxy receives a SIP request for a new dialog or a standalone SIP request addressed towards a UA, or when the SIP proxy determines that the UA needs to send a binding-refresh REGISTER request, the SIP proxy will send a push request containing the PRID of the UA to the PNS, which will then send a push notification to the UA. Once the UA receives the push notification, it will be able to send a binding-refresh REGISTER request. The proxy receives the REGISTER request from the UA and forwards it to the SIP registrar [RFC3261]. After accepting the REGISTER request, the SIP registrar sends a 2xx response to the proxy, which forwards the response to the UA. If the push notification request was triggered by a SIP request addressed towards the UA, the proxy can then forward the SIP request to the UA using normal SIP routing procedures. In some cases, the proxy can forward the SIP request without waiting for the SIP 2xx response to the REGISTER request from the SIP registrar. Note that this mechanism necessarily adds delay to responding to requests requiring push notification. The consequences of that delay are discussed in Section 5.6.2.
当SIP代理收到针对新对话的SIP请求或针对UA的独立SIP请求时，或者当SIP代理确定UA需要发送绑定刷新寄存器请求时，SIP代理将向PNS发送包含UA PRID的推送请求，然后PNS将向UA发送推送通知。UA收到推送通知后，将能够发送绑定刷新寄存器请求。代理从UA接收注册请求并将其转发给SIP注册器[RFC3261]。接受注册请求后，SIP注册器向代理发送2xx响应，代理将响应转发给UA。如果推送通知请求是由指向UA的SIP请求触发的，那么代理可以使用正常的SIP路由过程将SIP请求转发给UA。在某些情况下，代理可以转发SIP请求，而无需等待SIP注册器对注册请求的SIP 2xx响应。请注意，此机制必然会增加对需要推送通知的请求的响应延迟。第5.6.2节讨论了延迟的后果。
If there are Network Address Translators (NATs) between the UA and the proxy, the REGISTER request sent by the UA will create NAT bindings that will allow the incoming SIP request that triggered the push notification to reach the UA.
如果UA和代理之间存在网络地址转换器（NAT），则UA发送的注册请求将创建NAT绑定，以允许触发推送通知的传入SIP请求到达UA。
NOTE: The lifetime of any NAT binding created by the REGISTER request only needs to be long enough for the SIP request that triggered the push notification to reach the UA.
注意：注册请求创建的任何NAT绑定的生存期只需要足够长，就可以让触发推送通知的SIP请求到达UA。
Figure 1 shows the generic push notification architecture supported by the mechanism in this document.
图1显示了本文档中的机制支持的通用推送通知体系结构。
The SIP proxy MUST be in the signaling path of REGISTER requests sent by the UA towards the registrar, and of SIP requests (for a new dialog or a standalone) forwarded by the proxy responsible for the UA's domain (sometimes referred to as home proxy, Serving Call
SIP代理必须位于UA向注册器发送的注册请求的信令路径中，以及由负责UA域的代理转发的SIP请求（用于新对话或独立会话）的信令路径中（有时称为归属代理，服务于呼叫）
Session Control Function (S-CSCF), etc.) towards the UA. The proxy can also be co-located with the proxy responsible for the UA's domain. This will also ensure that the Request-URI of SIP requests (for a new dialog or a standalone) can be matched against contacts in REGISTER requests.
针对UA的会话控制功能（S-CSCF）等。代理还可以与负责UA域的代理位于同一位置。这还将确保SIP请求的请求URI（对于新对话框或独立对话框）可以与REGISTER请求中的联系人相匹配。
+--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+
| | | |
| Subscribe | | |
|---------------->| | |
| | | |
| PRID | | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| | | SIP INVITE (PRID) |
| | |<==================|
| | | |
| |Push Request (PRID) |
| |<-----------------| |
|Push Message (PRID) | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| SIP INVITE | | |
|<===================================| |
| | | |
+--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+
| | | |
| Subscribe | | |
|---------------->| | |
| | | |
| PRID | | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| | | SIP INVITE (PRID) |
| | |<==================|
| | | |
| |Push Request (PRID) |
| |<-----------------| |
|Push Message (PRID) | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| SIP INVITE | | |
|<===================================| |
| | | |
------- Push Notification API
======= SIP
------- Push Notification API
======= SIP
Figure 1: SIP Push Information Flow
图1:SIP推送信息流
Example of a SIP REGISTER request in the flow above:
上述流程中的SIP注册请求示例：
REGISTER sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>
Expires: 7200
Content-Length: 0
REGISTER sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>
Expires: 7200
Content-Length: 0
Figure 2: SIP REGISTER Example
图2:SIP寄存器示例
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
When a SIP UA registers with a PNS it receives a unique Push Resource ID (PRID), which is a value associated with the registration that can be used to generate push notifications.
当SIP UA向PNS注册时，它会收到一个唯一的推送资源ID（PRID），该ID是一个与注册相关联的值，可用于生成推送通知。
The format of the PRID varies depending on the PNS.
PRID的格式因PNS而异。
The details regarding discovery of the PNS, and the procedures regarding the push notification registration and maintenance, are outside the scope of this document. The information needed to contact the PNS is typically preconfigured in the operating system of the device.
有关PNS发现的详细信息以及有关推送通知注册和维护的程序不在本文档的范围内。联系PNS所需的信息通常在设备的操作系统中预配置。
This section describes how a SIP UA sends SIP REGISTER requests (either an initial REGISTER request for a binding or a binding-refresh REGISTER request) in order to request and disable push notifications from a SIP network, and to query the types of PNSs supported by the SIP network.
本节描述SIP UA如何发送SIP注册请求（绑定的初始注册请求或绑定刷新注册请求），以便从SIP网络请求和禁用推送通知，并查询SIP网络支持的PNS类型。
Unless specified otherwise, the normal SIP UA registration procedures [RFC3261] apply. The additional procedures described in this section apply when the REGISTER request contains a 'pn-provider' SIP URI parameter in the Contact header field URI (Figure 2).
除非另有规定，否则正常的SIP UA注册程序[RFC3261]适用。当REGISTER请求在Contact header字段URI（图2）中包含“pn provider”SIP URI参数时，本节中描述的附加过程适用。
The procedures in this section apply to individual bindings [RFC3261]. If a UA creates multiple bindings (e.g., one for IPv4 and one for IPv6), the UA needs to perform the procedures for each binding.
本节中的步骤适用于单个绑定[RFC3261]。如果UA创建多个绑定（例如，一个用于IPv4，一个用于IPv6），UA需要为每个绑定执行过程。
NOTE: Since a push notification will trigger the UA to refresh all bindings, if a SIP UA has created multiple bindings, it is preferable if one can ensure that all bindings expire at the same time to help prevent some bindings from being refreshed earlier than needed.
注意：由于推送通知将触发UA刷新所有绑定，因此如果SIP UA已创建多个绑定，最好确保所有绑定同时过期，以帮助防止某些绑定在需要之前被刷新。
For privacy and security reasons, a UA MUST NOT insert the SIP URI parameters (except for the 'pn-purr' parameter) defined in this specification in non-REGISTER requests in order to prevent the PNS information associated with the UA from reaching the remote peer. For example, the UA MUST NOT insert the 'pn-prid' SIP URI parameter in the Contact header field URI of an INVITE request. REGISTER requests will not reach the remote peer, as they will be terminated by the registrar of the UA. However, the registrar MUST still ensure that the parameters are not sent to other users, e.g., using the mechanism defined by the SIP event package for registrations [RFC3680]. See Section 13 for more information.
出于隐私和安全原因，UA不得在非注册请求中插入本规范中定义的SIP URI参数（pn purr参数除外），以防止与UA关联的PNS信息到达远程对等方。例如，UA不得在INVITE请求的联系人标头字段URI中插入'pn prid'SIP URI参数。注册请求不会到达远程对等方，因为它们将被UA的注册官终止。但是，注册机构必须确保参数不会发送给其他用户，例如，使用SIP事件包定义的机制进行注册[RFC3680]。更多信息请参见第13节。
This section describes the procedures that a SIP UA follows to request push notifications from the SIP network. The procedures assume that the UA has retrieved a PRID from a PNS. The procedures for retrieving the PRID from the PNS are PNS-specific and outside the scope of this specification. See PNS-specific documentation for more details.
本节描述SIP UA从SIP网络请求推送通知所遵循的过程。程序假设UA已从PNS检索到PRID。从PNS检索PRID的程序是特定于PNS的，不在本规范的范围内。有关更多详细信息，请参阅PNS特定文档。
This specification does not define a mechanism to explicitly request push notifications from the SIP network for usages other than triggering binding-refresh REGISTER requests (e.g., for sending periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does it describe how to distinguish push notifications associated with such usages from the push notifications used to trigger binding-refresh REGISTER requests. If a SIP UA wants to use push notifications for other usages, the UA can perform actions associated with such usages (in addition to sending a binding-refresh REGISTER request) whenever it receives a push notification by using the same refresh interval that is used for the binding refreshes.
本规范未定义明确请求SIP网络推送通知的机制，用于触发绑定刷新寄存器请求（例如，用于发送定期订阅刷新订阅请求[RFC6665]）以外的用途，它也没有描述如何区分与此类用法相关联的推送通知和用于触发绑定刷新寄存器请求的推送通知。如果SIP UA希望将推送通知用于其他用途，则UA可以通过使用用于绑定刷新的相同刷新间隔，在收到推送通知时执行与此类用途相关联的操作（除了发送绑定刷新寄存器请求之外）。
To request push notifications from the SIP network, the UA MUST insert the following SIP URI parameters in the SIP Contact header field URI of the REGISTER request: 'pn-provider', 'pn-prid', and 'pn-param' (if required for the specific PNS). The 'pn-provider' URI parameter indicates the type of PNS to be used for the push notifications.
要从SIP网络请求推送通知，UA必须在注册请求的SIP Contact header字段URI中插入以下SIP URI参数：“pn provider”、“pn prid”和“pn param”（如果特定pn需要）。“pn provider”URI参数指示用于推送通知的pn类型。
If the UA receives a 2xx response to the REGISTER request that contains a Feature-Caps header field [RFC6809] with a 'sip.pns' feature-capability indicator, with an indicator value identifying the same type of PNS that was identified by the 'pn-provider' URI parameter in the REGISTER request, it indicates that another SIP Proxy in the SIP network will request that push notifications are sent to the UA. In addition, if the same Feature-Caps header field contains a 'sip.vapid' feature-capability indicator, it indicates that the proxy supports use of the Voluntary Application Server Identification (VAPID) mechanism [RFC8292] to restrict push notifications to the UA.
如果UA接收到对注册请求的2xx响应，该响应包含带有“sip.pns”功能能力指示符的功能Caps头字段[RFC6809]，指示符值标识注册请求中“pn provider”URI参数标识的相同类型的pns，它表示SIP网络中的另一个SIP代理将请求向UA发送推送通知。此外，如果相同的Feature Caps标头字段包含“sip.vapid”功能功能指示器，则表示代理支持使用自愿应用程序服务器标识（vapid）机制[RFC8292]来限制向UA发送推送通知。
NOTE: The VAPID-specific procedures of the SIP UA are outside the scope of this document.
注：SIP UA乏味的具体程序不在本文件范围内。
If the UA receives a non-2xx response to the REGISTER, or if the UA receives a 2xx response that does not contain a Feature-Caps header field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA MUST NOT assume the proxy will request that push notifications are sent to the UA. The actions taken by the UA in such cases are outside the scope of this document.
如果UA接收到对寄存器的非2xx响应，或者如果UA接收到的2xx响应不包含带有“sip.pns”功能能力指示符的Feature Caps标头字段[RFC6809]，则UA不得假设代理将请求向UA发送推送通知。UA在此类情况下采取的行动不在本文件范围内。
If the PRID is only valid for a limited time, then the UA is responsible for retrieving a new PRID from the PNS and sending a binding-refresh REGISTER request with the updated 'pn-*' parameters. If a PRID is no longer valid, and the UA is not able to retrieve a new PRID, the UA MUST disable the push notifications associated with the PRID (Section 4.1.2).
如果PRID仅在有限的时间内有效，则UA负责从PNS检索新的PRID，并使用更新的“pn-*”参数发送绑定刷新寄存器请求。如果PRID不再有效，且UA无法检索新的PRID，UA必须禁用与PRID相关的推送通知（第4.1.2节）。
When a UA wants to disable previously requested push notifications, the UA SHOULD remove the binding [RFC3261], unless the UA is no longer able to perform SIP procedures (e.g., due to a forced shutdown of the UA), in which case the registrar will remove the binding once it expires. When the UA sends the REGISTER request for removing the binding, the UA MUST NOT insert the 'pn-prid' SIP URI parameter in the Contact header field URI of the REGISTER request. The lack of the parameter informs the SIP network that the UA no longer wants to receive push notifications associated with the PRID.
当UA想要禁用先前请求的推送通知时，UA应该删除绑定[RFC3261]，除非UA不再能够执行SIP过程（例如，由于UA的强制关闭），在这种情况下，一旦绑定过期，注册器将删除绑定。当UA发送删除绑定的注册请求时，UA不得在注册请求的联系人标头字段URI中插入'pn prid'SIP URI参数。缺少该参数会通知SIP网络UA不再希望接收与PRID相关联的推送通知。
When a UA receives a push notification, the UA MUST send a binding-refresh REGISTER request. The UA MUST insert the same set of 'pn-*' SIP URI parameters in the SIP Contact header field URI of the REGISTER request that it inserted when it requested push notifications (Section 4.1.1). Note that, in some cases, the PNS might update the PRID value, in which case the UA will insert the new value in the 'pn-prid' SIP URI parameter of the binding-refresh REGISTER request.
当UA收到推送通知时，UA必须发送绑定刷新寄存器请求。UA必须在其请求推送通知时插入的注册请求的SIP联系人头字段URI中插入相同的“pn-*”SIP URI参数集（第4.1.1节）。注意，在某些情况下，PNS可能会更新PRID值，在这种情况下，UA将在绑定刷新寄存器请求的“pn PRID”SIP URI参数中插入新值。
Once the UA has received a 2xx response to the REGISTER request, the UA might receive a SIP request for a new dialog (e.g., a SIP INVITE) or a standalone SIP request (e.g., a SIP MESSAGE) if such a SIP request triggered the proxy to request that the push notification was sent to the UA. Note that, depending on which transport protocol is used, the SIP request might reach the UA before the REGISTER response.
一旦UA收到对注册请求的2xx响应，UA可能会收到新对话的SIP请求（例如，SIP INVITE）或独立SIP请求（例如，SIP消息），如果这样的SIP请求触发代理请求向UA发送推送通知。注意，根据使用的传输协议，SIP请求可能在寄存器响应之前到达UA。
If the SIP UA has created multiple bindings, the UA MUST send a binding-refresh REGISTER request for each of those bindings when it receives a push notification.
如果SIP UA创建了多个绑定，则UA在收到推送通知时必须为每个绑定发送绑定刷新寄存器请求。
This specification does not define any usage of push-notification payload. If a SIP UA receives a push notification that contains a payload, the UA can discard the payload but will still send a binding-refresh REGISTER request.
本规范未定义推送通知有效负载的任何用法。如果SIP UA收到包含有效负载的推送通知，UA可以丢弃有效负载，但仍将发送绑定刷新寄存器请求。
If a UA is able to send binding-refresh REGISTER requests using a non-push mechanism (e.g., using an internal timer that periodically wakes the UA), the UA MUST insert a 'sip.pnsreg' media feature tag [RFC3840] in the Contact header field of each REGISTER request.
如果UA能够使用非推送机制（例如，使用定期唤醒UA的内部计时器）发送绑定刷新寄存器请求，则UA必须在每个寄存器请求的联系人标头字段中插入“sip.pnsreg”媒体功能标签[RFC3840]。
If the UA receives a 2xx response to the REGISTER request that contains a Feature-Caps header field with a 'sip.pnsreq' feature-capability indicator, the UA MUST send a binding-refresh REGISTER request prior to binding expiration. The indicator value indicates the minimum time (given in seconds), prior to the binding expiration when the UA needs to send the REGISTER request.
如果UA收到对注册请求的2xx响应，该响应包含带有“sip.pnsreq”功能能力指示器的功能Caps标头字段，则UA必须在绑定到期之前发送绑定刷新注册请求。指示符值表示UA需要发送注册请求的绑定到期之前的最短时间（以秒为单位）。
If the UA receives a 2xx response to the REGISTER request that does not contain a Feature-Caps header field with a 'sip.pnsreq' feature-capability indicator, the UA SHOULD only send a binding-refresh REGISTER request when it receives a push notification (even if the UA is able to use a non-push mechanism for sending binding-refresh REGISTER requests) or when there are circumstances that require an immediate REGISTER request to be sent (e.g., if the UA is assigned new contact parameters due to a network configuration change).
如果UA接收到对注册请求的2xx响应，该响应不包含带有“sip.pnsreq”功能能力指示符的功能Caps标头字段，则UA应仅在收到推送通知时发送绑定刷新注册请求（即使UA能够使用非推送机制发送绑定刷新寄存器请求）或存在需要立即发送寄存器请求的情况（例如，如果由于网络配置更改而为UA分配了新的联系人参数）。
Even if the UA is able to send binding-refresh REGISTER requests using a non-push mechanism, the UA MUST still send a binding-refresh REGISTER request whenever it receives a push notification (Section 4.1.3).
即使UA能够使用非推送机制发送绑定刷新寄存器请求，UA仍必须在收到推送通知时发送绑定刷新寄存器请求（第4.1.3节）。
NOTE: If the UA uses a non-push mechanism to wake and send binding-refresh REGISTER requests, such REGISTER requests will update the binding expiration timer, and the proxy does not need to request that a push notification be sent to the UA in order to wake the UA. The proxy will still request that a push notification be sent to the UA when the proxy receives a SIP request addressed towards the UA (Section 5.6.2). This allows the UA to, e.g., use timers for sending binding-refresh REGISTER requests but be suspended (in order to save battery resources, etc.) between sending the REGISTER requests and using push notifications to wake the UA to process incoming calls.
注意：如果UA使用非推送机制来唤醒和发送绑定刷新寄存器请求，则此类寄存器请求将更新绑定过期计时器，并且代理不需要请求向UA发送推送通知来唤醒UA。当代理收到指向UA的SIP请求时，代理仍将请求向UA发送推送通知（第5.6.2节）。这允许UA（例如）使用定时器发送绑定刷新寄存器请求，但在发送寄存器请求和使用推送通知唤醒UA以处理传入呼叫之间暂停（以节省电池资源等）。
Example of a SIP REGISTER request including a 'sip.pnsreg' media feature tag:
包含“SIP.pnsreg”媒体功能标签的SIP注册请求示例：
REGISTER sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>;
+sip.pnsreg
Expires: 7200
Content-Length: 0
REGISTER sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>;
+sip.pnsreg
Expires: 7200
Content-Length: 0
Example of a SIP REGISTER response including a 'sip.pnsreg' media feature tag and a 'sip.pnsreq' feature-capability indicator:
SIP寄存器响应示例，包括“SIP.pnsreg”媒体功能标签和“SIP.pnsreq”功能功能指示器：
SIP/2.0 200 OK
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
To: Alice <sip:alice@example.com>;tag=123987
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>;
+sip.pnsreg
Feature-Caps: *;+sip.pns="acme";+sip.pnsreg="121"
Expires: 7200
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
To: Alice <sip:alice@example.com>;tag=123987
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>;
+sip.pnsreg
Feature-Caps: *;+sip.pns="acme";+sip.pnsreg="121"
Expires: 7200
Content-Length: 0
Figure 3: SIP REGISTER When Using Non-push Mechanism Example
图3：使用非推送机制示例时的SIP寄存器
This section describes how a SIP UA can query the types of PNSs supported by a SIP network, and PNS-related capabilities (e.g., support of the VAPID mechanism). When a UA performs a query, it does not request push notifications from the SIP network. Therefore, the UA can perform the query before it has registered to a PNS and received a PRID.
本节描述SIP UA如何查询SIP网络支持的PNS类型，以及PNS相关功能（例如，支持VAPID机制）。UA执行查询时，不会从SIP网络请求推送通知。因此，UA可以在注册到PNS并收到PRID之前执行查询。
In order to perform a query, the UA MUST insert a 'pn-provider' SIP URI parameter in the Contact header field URI of the REGISTER request:
为了执行查询，UA必须在注册请求的联系人标头字段URI中插入“pn provider”SIP URI参数：
o If the UA inserts a 'pn-provider' parameter value, indicating support of a type of PNS, the SIP network will only inform the UA whether that type of PNS is supported.
o 如果UA插入“pn provider”参数值，表示支持某一类型的pn，则SIP网络将仅通知UA是否支持该类型的pn。
o If the UA does not insert a 'pn-provider' parameter value (i.e., it inserts an "empty" 'pn-provider' parameter), the SIP network will inform the UA about all types of PNSs supported by the network. This is useful, e.g., if the UA supports more than one type of PNS. Note that it is not possible to insert multiple parameter values in the 'pn-provider' parameter.
o 如果UA没有插入“pn提供者”参数值（即，它插入了一个“空”的“pn提供者”参数），SIP网络将通知UA网络支持的所有类型的PNS。这是有用的，例如，如果UA支持多种类型的PN。请注意，无法在“pn provider”参数中插入多个参数值。
The UA MUST NOT insert a 'pn-prid' SIP URI parameter in the Contact header field URI of the REGISTER request.
UA不得在注册请求的联系人标头字段URI中插入“pn prid”SIP URI参数。
If the UA receives a 2xx response to the REGISTER request, the response will contain one or more Feature-Caps header fields with a 'sip.pns' feature-capability indicator, indicating the types of PNSs supported by the SIP network. If the UA inserted a 'pn-provider' SIP URI parameter value in the REGISTER request, the response will only indicate whether the SIP network supports the type of PNS supported by the UA.
如果UA收到对注册请求的2xx响应，则响应将包含一个或多个带有“sip.pns”功能能力指示器的功能Caps头字段，指示sip网络支持的pns类型。如果UA在注册请求中插入了“pn provider”SIP URI参数值，则响应将仅指示SIP网络是否支持UA支持的pn类型。
If the UA receives a 555 (Push Notification Service Not Supported) response to the REGISTER request, and if the UA inserted a 'pn-provider' SIP URI parameter in the REGISTER request, the response indicates that the network does not support the type of PNS that the UA indicated support of. If the UA did not insert a 'pn-provider' parameter in the REGISTER request, the response indicates that the network does not support any type of PNS while still supporting the 555 (Push Notification Service Not Supported) response.
如果UA收到对注册请求的555（推送通知服务不受支持）响应，并且如果UA在注册请求中插入了“pn provider”SIP URI参数，则响应指示网络不支持UA指示支持的pn类型。如果UA未在注册请求中插入“pn provider”参数，则响应表明网络不支持任何类型的pn，同时仍支持555（推送通知服务不受支持）响应。
NOTE: It is optional for a UA to perform a query before it requests push notifications from the SIP network.
注意：UA在从SIP网络请求推送通知之前执行查询是可选的。
The type of PNS is identified by the 'pn-provider' SIP URI parameter. In some cases, there might only be one PNS provider for a given type of PNS, while in other cases there might be multiple providers. The 'pn-param' SIP URI parameter will provide more details associated with the actual PNS provider to be used.
pn的类型由“pn provider”SIP URI参数标识。在某些情况下，对于给定类型的PNS，可能只有一个PNS提供程序，而在其他情况下，可能有多个提供程序。“pn param”SIP URI参数将提供与要使用的实际PNS提供程序相关的更多详细信息。
The protocol and format used for the push notification requests are PNS-specific, and the details for constructing and sending a push notification request are outside the scope of this specification.
推送通知请求使用的协议和格式是特定于PNS的，构造和发送推送通知请求的详细信息不在本规范的范围内。
When a SIP proxy receives a SIP request addressed towards a UA, that will trigger the proxy to request that a push notification be sent to the UA. The proxy will place the request in storage (referred to as the SIP Request Push Bucket) and the proxy will start a timer (referred to as the Bucket Timer) associated with the transaction. A SIP request is removed from the bucket when one of the following has occurred: the proxy forwards the request towards the UA, the proxy sends an error response to the request, or the Bucket Timer times out. The detailed procedures are described in the sections below.
当SIP代理收到指向UA的SIP请求时，将触发代理请求向UA发送推送通知。代理将请求放入存储器（称为SIP请求推送桶），代理将启动与事务相关联的计时器（称为桶计时器）。当发生以下情况之一时，SIP请求将从bucket中删除：代理将请求转发给UA，代理向请求发送错误响应，或者bucket计时器超时。以下各节介绍了详细的程序。
Exactly how the SIP Request Push Bucket is implemented is outside the scope of this document. One option is to use the PRID as a key to search for SIP requests in the bucket. Note that mid-dialog requests (Section 6) do not carry the PRID in the SIP request itself.
SIP请求推送桶的具体实现方式超出了本文档的范围。一种选择是使用PRID作为密钥来搜索bucket中的SIP请求。请注意，mid对话请求（第6节）在SIP请求本身中不携带PRID。
By default, a SIP proxy uses the URI comparison rules defined in [RFC3261]. However, when a SIP proxy compares the Contact header field URI of a 2xx response to a REGISTER request with a Request-URI of a SIP request in the SIP Request Push Bucket (Section 5.2), the proxy uses the URI comparison rules with the following additions: the 'pn-prid', 'pn-provider', and 'pn-param' SIP URI parameters MUST also match. If a 'pn-*' parameter is present in one of the compared URIs but not in the other URI, there is no match.
默认情况下，SIP代理使用[RFC3261]中定义的URI比较规则。但是，当SIP代理将2xx响应的注册请求的联系人标头字段URI与SIP请求推送桶（第5.2节）中SIP请求的请求URI进行比较时，代理使用URI比较规则，并添加以下内容：“pn prid”、“pn provider”和“pn param”SIP URI参数也必须匹配。如果一个比较的URI中存在“pn-*”参数，但另一个URI中不存在该参数，则不存在匹配项。
If only the 'pn-*' SIP URI parameters listed above match, but other parts of the compared URIs do not match, a proxy MAY still consider the comparison successful based on local policy. This can occur in a race condition when the proxy compares the Contact header field URI of a 2xx response to a REGISTER request with a Request-URI of a SIP request in the SIP Request Push Bucket (Section 5.2) if the UA had modified some parts of the Contact header field URI in the REGISTER request but the Request-URI of the SIP request in the SIP Request Push Bucket still contains the old parts.
如果上面列出的“PN-*”SIP URI参数匹配，但比较URI的其他部分不匹配，则代理仍然可以考虑基于本地策略的比较成功。当代理将2xx响应到注册请求的联系人标头字段URI与SIP请求推送桶中SIP请求的请求URI进行比较时，这可能会在竞争条件下发生（第5.2节）如果UA修改了REGISTER请求中Contact header字段URI的某些部分，但是SIP请求推送桶中SIP请求的请求URI仍然包含旧部分。
A SIP proxy uses feature-capability indicators [RFC6809] to indicate support of types of PNSs and additional features (e.g., VAPID) associated with the type of PNS. A proxy MUST use a separate Feature-Cap header field for each supported type of PNS. A feature-
SIP代理使用功能能力指示器[RFC6809]来指示对PNS类型的支持以及与PNS类型相关的附加功能（例如，VAPID）。代理必须为每种支持的PNS类型使用单独的Feature Cap标头字段。特色-
capability indicator that indicates support of an additional feature associated with a given type of PNS MUST be inserted in the same Feature-Caps header field that is used to indicate support of the type of PNS.
指示支持与给定类型PNS关联的附加功能的能力指示器必须插入用于指示支持该类型PNS的相同功能Caps标题字段中。
This specification defines the following feature-capability indicators that a proxy can use to indicate support of additional features associated with a given type of PNS: 'sip.vapid', 'sip.pnsreg', and 'sip.pnspurr'. These feature-capability indicators MUST only be inserted in a Feature-Caps header field that also contains a 'sip.pns' feature-capability indicator.
本规范定义了以下特性功能指示器，代理可以使用这些指示器来指示对与给定类型的PNS关联的其他特性的支持：“sip.vapid”、“sip.pnsreg”和“sip.pnspurr”。这些功能能力指标只能插入到功能Caps标题字段中，该字段还包含“sip.pns”功能能力指标。
In order to request that a push notification be sent to a SIP UA, a SIP proxy needs to have information about when a binding will expire. The proxy needs to be able to retrieve the information from the registrar using some mechanism or run its own registration timers. Such mechanisms are outside the scope of this document but could be implemented, e.g., by using the SIP event package for registrations mechanism [RFC3680].
为了请求向SIP UA发送推送通知，SIP代理需要有绑定何时过期的信息。代理需要能够使用某种机制从注册器检索信息，或者运行自己的注册计时器。此类机制不在本文档的范围内，但可以通过使用SIP事件包注册机制[RFC3680]来实现。
When the proxy receives an indication that the UA needs to send a binding-refresh REGISTER request, the proxy will request that a push notification be sent to the UA.
当代理收到UA需要发送绑定刷新寄存器请求的指示时，代理将请求向UA发送推送通知。
Note that the push notification needs to be requested early enough for the associated binding-refresh REGISTER request to reach the registrar before the binding expires. It is RECOMMENDED that the proxy requests the push notification at least 120 seconds before the binding expires.
请注意，需要尽早请求推送通知，以便关联的绑定刷新寄存器请求在绑定过期之前到达注册器。建议代理在绑定到期前至少120秒请求推送通知。
If the UA has indicated, using the 'sip.pnsreg' media feature tag, that it is able to wake itself using a non-push mechanism in order to send binding-refresh REGISTER requests, and if the proxy does not receive a REGISTER request prior to 120 seconds before the binding expires, the proxy MAY request that a push notification be sent to the UA to trigger the UA to send a binding-refresh REGISTER request.
如果UA已使用“sip.pnsreg”媒体功能标签指示其能够使用非推送机制唤醒自身以发送绑定刷新寄存器请求，并且如果代理在绑定到期前120秒未收到寄存器请求，代理可以请求向UA发送推送通知，以触发UA发送绑定刷新寄存器请求。
NOTE: As described in Section 4.1.5, a UA might send a REGISTER request without including a 'pn-prid' SIP URI parameter in order to retrieve push notification capabilities from the network before the UA expects to receive push notifications from the network. A proxy will not request that push notifications are sent to a UA that has not provided a 'pn-prid' SIP URI parameter (Section 5.6.2).
注：如第4.1.5节所述，UA可能会在不包含“pn prid”SIP URI参数的情况下发送注册请求，以便在UA预期从网络接收推送通知之前从网络检索推送通知功能。代理不会请求向未提供“pn prid”SIP URI参数的UA发送推送通知（第5.6.2节）。
If the proxy receives information that a binding associated with a PRID has expired, or that a binding has been removed, the proxy MUST NOT request that further push notifications are sent to the UA using that PRID.
如果代理收到与PRID关联的绑定已过期或绑定已删除的信息，则代理不得请求使用该PRID向UA发送进一步的推送通知。
This section describes how a SIP proxy processes SIP REGISTER requests (initial REGISTER request for a binding or a binding-refresh REGISTER request).
本节描述SIP代理如何处理SIP注册请求（绑定的初始注册请求或绑定刷新注册请求）。
The procedures in this section apply when the REGISTER request contains a 'pn-provider' SIP URI parameter in the Contact header field URI. In other cases, the proxy MUST skip the procedures in this section and process the REGISTER request using normal SIP procedures.
当注册请求在联系人标头字段URI中包含“pn provider”SIP URI参数时，本节中的过程适用。在其他情况下，代理必须跳过本节中的过程，并使用正常的SIP过程处理注册请求。
This section describes the SIP proxy procedures when a SIP UA requests push notifications from the SIP network.
本节描述SIP UA从SIP网络请求推送通知时的SIP代理过程。
The procedures in this section apply when the SIP REGISTER request contains, in addition to the 'pn-provider' SIP URI parameter, a 'pn-prid' SIP URI parameter in the Contact header field URI of the request.
当SIP REGISTER请求在请求的Contact header字段URI中除包含“pn provider”SIP URI参数外，还包含“pn prid”SIP URI参数时，本节中的过程适用。
When a proxy receives a REGISTER request that contains a Feature-Caps header field with a 'sip.pns' feature-capability indicator, it indicates that another proxy between this proxy and the UA supports the type of PNS supported by the UA, and will request that push notifications are sent to the UA. In such case, the proxy MUST skip the rest of the procedures in this section and process the REGISTER request using normal SIP procedures.
当代理接收到包含带有“sip.pns”功能能力指示器的功能Caps标头字段的注册请求时，它表示此代理和UA之间的另一个代理支持UA支持的pns类型，并将请求向UA发送推送通知。在这种情况下，代理必须跳过本节中的其余过程，并使用正常的SIP过程处理注册请求。
When a proxy receives a REGISTER request that does not contain a Feature-Caps header field with a 'sip.pns' feature-capability indicator, the proxy processes the request according to the procedures below:
当代理收到不包含带有“sip.pns”功能能力指示器的功能Caps标头字段的注册请求时，代理将根据以下过程处理该请求：
o If the proxy does not support the type of PNS supported by the UA, or if the REGISTER request does not contain all information required for the type of PNS, the proxy SHOULD forward the request towards the registrar and skip the rest of the procedures in this section. If the proxy knows (by means of local configuration) that no other proxies between itself and the registrar support the
o 如果代理不支持UA支持的PNS类型，或者如果注册请求不包含PNS类型所需的所有信息，则代理应将请求转发给注册官，并跳过本节中的其余程序。如果代理知道（通过本地配置）自身和注册器之间没有其他代理支持
type of PNS supported by the UA, the proxy MAY send a SIP 555 (Push Notification Service Not Supported) response instead of forwarding the request.
UA支持的PNS类型，代理可以发送SIP 555（不支持推送通知服务）响应，而不是转发请求。
o If the proxy supports the type of PNS supported by the UA, but considers the requested binding expiration interval [RFC3261] to be too short (see below), the proxy MUST either send a 423 (Interval Too Brief) response to the REGISTER request or forward the request towards the registrar and skip the rest of the procedures in this section.
o 如果代理支持UA支持的PNS类型，但认为请求的绑定过期时间间隔[RFC3261]太短（见下文），则代理必须向注册请求发送423（时间间隔太短）响应，或将请求转发给注册器，并跳过本节中的其余过程。
o If the proxy supports the type of PNS supported by the UA, the proxy MUST indicate support of that type of PNS (Section 5.4) in the REGISTER request before it forwards the request towards the registrar. This will inform proxies between the proxy and the registrar that the proxy supports the type of PNS supported by the UA, and that the proxy will request that push notifications are sent to the UA.
o 如果代理支持UA支持的PNS类型，则代理必须在将请求转发给注册官之前，在注册请求中指明对该类型PNS的支持（第5.4节）。这将通知代理和注册商之间的代理，代理支持UA支持的PN类型，并且代理将请求向UA发送推送通知。
A binding expiration interval MUST be considered too short if the binding would expire before the proxy can request that a push notification be sent to the UA to trigger the UA to send a binding-refresh REGISTER request. The proxy MAY consider the interval too short based on its own policy so as to reduce load on the system.
如果绑定在代理可以请求向UA发送推送通知以触发UA发送绑定刷新寄存器请求之前过期，则必须认为绑定过期时间间隔太短。代理可以根据自己的策略考虑间隔太短，以减少系统上的负载。
When a proxy receives a 2xx response to the REGISTER request, if the proxy indicated support of a type of PNS in the REGISTER request (see above), the proxy performs the following actions:
当代理收到对注册请求的2xx响应时，如果代理指示在注册请求中支持某种类型的PNS（见上文），则代理将执行以下操作：
o If the proxy considers the binding expiration interval indicated by the registrar too short (see above), the proxy forwards the response towards the UA and MUST skip the rest of the procedures in this section.
o 如果代理认为注册商指示的绑定到期时间间隔太短（见上文），则代理将响应转发给UA，并且必须跳过本节中的其余过程。
o The proxy MUST indicate support of the same type of PNS in the REGISTER response. In addition:
o 代理必须在寄存器响应中指示支持相同类型的PNS。此外：
* If the proxy supports the VAPID mechanism [RFC8292], the proxy MUST indicate support of the mechanism, using the 'sip.vapid' feature-capability indicator, in the REGISTER response. The indicator value contains the public key identifying the proxy. The proxy MUST determine whether the PNS provider supports the VAPID mechanism before it indicates support of it.
* 如果代理支持VAPID机制[RFC8292]，则代理必须在寄存器响应中使用“sip.VAPID”特性功能指示器指示支持该机制。指示符值包含标识代理的公钥。代理必须先确定PNS提供程序是否支持VAPID机制，然后才能表示支持该机制。
* If the proxy received a 'sip.pnsreg' media feature tag in the REGISTER request, the proxy SHOULD insert a 'sip.pnsreg' feature-capability indicator with an indicator value bigger than 120 in the response, unless the proxy always wants to request that push notifications are sent to the UA in order to trigger the UA to send a binding-refresh REGISTER request.
* 如果代理在注册请求中收到“sip.pnsreg”媒体功能标签，则代理应在响应中插入一个“sip.pnsreg”功能功能指示器，其指示器值大于120，除非代理总是希望请求向UA发送推送通知，以触发UA发送绑定刷新寄存器请求。
This section describes the SIP proxy procedures when a SIP UA queries about the push-notification support in the SIP network (Section 4.1.5).
本节描述SIP UA查询SIP网络中的推送通知支持时的SIP代理过程（第4.1.5节）。
The procedures in this section apply when the REGISTER request contains a 'pn-provider' SIP URI parameter, but does not contain a 'pn-prid' SIP URI parameter in the Contact header field URI of the REGISTER request.
当注册请求包含“pn provider”SIP URI参数，但在注册请求的联系人标头字段URI中不包含“pn prid”SIP URI参数时，本节中的过程适用。
When a proxy receives a REGISTER request that contains a 'pn-provider' SIP URI parameter indicating the type of PNS supported by the UA, the proxy MUST perform the following actions:
当代理收到包含指示UA支持的pn类型的“pn provider”SIP URI参数的注册请求时，代理必须执行以下操作：
o If the proxy supports the type of PNS supported by the UA, the proxy MUST indicate support of that type of PNS (Section 5.4) in the REGISTER request before it forwards the request towards the registrar. This will inform any other proxies between the proxy and the registrar that the proxy supports the type of PNS supported by the UA.
o 如果代理支持UA支持的PNS类型，则代理必须在将请求转发给注册官之前，在注册请求中指明对该类型PNS的支持（第5.4节）。这将通知代理和注册官之间的任何其他代理，代理支持UA支持的PNS类型。
o If the proxy does not support the type of PNS supported by the UA, and if the REGISTER request contains Feature-Caps header fields indicating support of one or more types of PNSs, the proxy forwards the request towards the registrar.
o 如果代理不支持UA支持的PNS类型，并且如果注册请求包含表示支持一种或多种PNS类型的Feature Caps头字段，则代理将请求转发给注册器。
o If the proxy does not support the type of PNS supported by the UA, and if the REGISTER request does not contain Feature-Caps header fields indicating support of one or more types of PNSs, the proxy MUST either forward the request towards the registrar or send a SIP 555 (Push Notification Service Not Supported) response towards the UA. The proxy MUST NOT send a SIP 555 (Push Notification Service Not Supported) response unless it knows (by means of local configuration) that no other proxy supports any of the types of PNSs supported by the UA.
o 如果代理不支持UA支持的PNS类型，并且如果注册请求不包含表示支持一种或多种PNS类型的Feature Caps头字段，则代理必须将请求转发给注册器，或者向UA发送SIP 555（推送通知服务不受支持）响应。代理不得发送SIP 555（不支持推送通知服务）响应，除非它知道（通过本地配置）没有其他代理支持UA支持的任何类型的PNS。
When a proxy receives a REGISTER request, and the 'pn-provider' SIP URI parameter does not contain a parameter value, the proxy MUST indicate support of each type of PNS supported by the proxy before it forwards the request towards the registrar.
当代理收到注册请求，并且“pn provider”SIP URI参数不包含参数值时，代理必须在将请求转发给注册器之前指示代理支持的每种类型的pn。
When a proxy receives a 2xx response to the REGISTER request, if the proxy had indicated support of one or more types of PNSs in the REGISTER request (see above), the proxy MUST indicate support of the same set of types of PNSs in the response. In addition, if the proxy supports the VAPID mechanism for one or more types of PNSs, the proxy MUST indicate support of the mechanism for those PNSs in the response.
当代理收到对注册请求的2xx响应时，如果代理在注册请求中表示支持一种或多种类型的PNS（见上文），则代理必须在响应中表示支持同一组类型的PNS。此外，如果代理支持一种或多种类型的PNS的VAPID机制，则代理必须在响应中指示对这些PNS的机制的支持。
The procedures in this section apply when a SIP proxy has indicated that it will request that push notifications are sent to the SIP UA.
当SIP代理表示将请求向SIP UA发送推送通知时，本节中的过程适用。
When the proxy receives a SIP request for a new dialog (e.g., a SIP INVITE request) or a standalone SIP request (e.g., a SIP MESSAGE request) addressed towards a SIP UA, if the Request-URI of the request contains a 'pn-provider', a 'pn-prid', and a 'pn-param' (if required for the specific PNS provider) SIP URI parameter, the proxy requests that a push notification be sent to the UA using the information in the 'pn-*' SIP URI parameters. The proxy then places the SIP request in the SIP Request Push Bucket. The push notification will trigger the UA to send a binding-refresh REGISTER request that the proxy will process as described in Section 5.6.1. In addition, the proxy MUST store the Contact URI of the REGISTER request during the lifetime of the REGISTER transaction.
当代理收到针对SIP UA寻址的新对话（例如SIP INVITE请求）的SIP请求或独立SIP请求（例如SIP消息请求）时，如果请求的请求URI包含“pn provider”、“pn prid”和“pn param”（如果特定PNS提供程序需要）SIP URI参数，代理请求使用“pn-*”SIP URI参数中的信息向UA发送推送通知。然后，代理将SIP请求放入SIP请求推送桶中。推送通知将触发UA发送绑定刷新寄存器请求，代理将按照第5.6.1节所述处理该请求。此外，代理必须在注册事务的生存期内存储注册请求的联系人URI。
NOTE: If the proxy receives a SIP request that does not contain the 'pn-*' SIP URI parameters listed above, the proxy processing of the request is based on local policy. If the proxy also serves requests for UAs that do not use the SIP push mechanism, the proxy can forward the request towards the UA. Otherwise, the proxy can reject the request.
注意：如果代理收到的SIP请求不包含上面列出的'pn-*'SIP URI参数，则该请求的代理处理基于本地策略。如果代理还为不使用SIP推送机制的UAs提供请求，则代理可以将请求转发给UA。否则，代理可以拒绝请求。
When the proxy receives a 2xx response to the REGISTER request, the proxy performs the following actions:
当代理收到对注册请求的2xx响应时，代理将执行以下操作：
o The proxy processes the REGISTER response as described in Section 5.6.1.
o 代理按照第5.6.1节所述处理寄存器响应。
o The proxy checks whether the SIP Request Push Bucket contains a SIP request associated with the REGISTER transaction by comparing (Section 5.3) the Contact header field URI in the REGISTER response with the Request-URIs of the SIP requests in the bucket. If there is a match, the proxy MUST remove the SIP request from the bucket and forward it towards the UA.
o 代理通过比较（第5.3节）寄存器响应中的联系人标头字段URI与桶中SIP请求的请求URI，检查SIP请求推送桶是否包含与寄存器事务相关联的SIP请求。如果存在匹配，代理必须从bucket中删除SIP请求，并将其转发给UA。
The reason the proxy needs to wait for the REGISTER response before forwarding a SIP request towards a UA is to make sure that the REGISTER request has been accepted by the registrar, and that the UA that initiated the REGISTER request is authorized to receive messages for the Request-URI.
代理在向UA转发SIP请求之前需要等待注册响应的原因是确保注册器已接受注册请求，并且发起注册请求的UA已被授权接收请求URI的消息。
If the proxy receives a non-2xx response to the REGISTER request, the proxy compares the Contact URI stored from the REGISTER request (see above) with the Request-URIs of the SIP requests in the SIP Request Push Bucket. If there is a match, the proxy SHOULD remove the associated request from the bucket and send an error response to the request. It is RECOMMENDED that the proxy sends either a 404 (Not Found) response or a 480 (Temporarily Unavailable) response to the SIP request, but other response codes can be used as well. However, if the REGISTER response is expected to trigger a new REGISTER request from the UA (e.g., if the registrar is requesting the UA to perform authentication), the proxy MAY keep the SIP request in the bucket.
如果代理收到对注册请求的非2xx响应，则代理会将从注册请求（见上文）存储的联系人URI与SIP请求推送桶中SIP请求的请求URI进行比较。如果存在匹配，代理应该从bucket中删除关联的请求，并向请求发送错误响应。建议代理向SIP请求发送404（未找到）响应或480（暂时不可用）响应，但也可以使用其他响应代码。然而，如果预期寄存器响应将触发来自UA的新的寄存器请求（例如，如果注册器正在请求UA执行认证），则代理可以将SIP请求保持在bucket中。
If the push notification request fails (see PNS-specific documentation for details), the proxy MUST remove the SIP request from the bucket and send an error response to the SIP request. It is RECOMMENDED that the proxy sends either a 404 (Not Found) response or a 480 (Temporarily Unavailable) response, but other response codes can be used as well.
如果推送通知请求失败（有关详细信息，请参阅PNS特定文档），则代理必须从bucket中删除SIP请求，并向SIP请求发送错误响应。建议代理发送404（未找到）响应或480（暂时不可用）响应，但也可以使用其他响应代码。
After the proxy has requested that a push notification be sent to a UA, if the proxy does not receive a REGISTER response with a Contact URI that matches the Request-URI of the SIP request before the Bucket Timer (Section 5.2) associated with the SIP request times out, the proxy MUST remove the SIP request from the SIP Request Push Bucket (Section 5.2) and send a 480 (Temporarily Unavailable) response. The Bucket Timer time-out value is set based on local policy, taking the guidelines below into consideration.
在代理请求向UA发送推送通知后，如果在与SIP请求相关联的Bucket计时器（第5.2节）超时之前，代理没有收到具有与SIP请求的请求URI匹配的联系人URI的注册响应，则代理必须从SIP请求推送Bucket中删除SIP请求（第5.2节）并发送480（暂时不可用）响应。桶定时器超时值根据本地策略设置，并考虑以下准则。
As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must complete immediately or risk losing a race, which results in stress on intermediaries and state misalignment at the endpoints. The mechanism defined in this document inherently delays the final response to any non-INVITE request that requires a push notification. In particular, if the proxy forwards the SIP request towards the SIP UA, the SIP UA accepts the request, but the transaction times out at the sender before it receives the successful response, this will cause state misalignment between the endpoints (the sender considers the transaction a failure, while the receiver considers the transaction a success). The SIP proxy needs to take this into account when it sets the value of the Bucket Timer associated with the transaction, to make sure that the error response (triggered by a
正如[RFC4320]和[RFC4321]中所讨论的，非邀请事务必须立即完成，否则就有可能失去竞争，这会对中介机构造成压力，并导致端点的状态不一致。本文档中定义的机制本质上延迟了对任何需要推送通知的非INVITE请求的最终响应。特别是，如果代理将SIP请求转发给SIP UA，则SIP UA接受该请求，但事务在其接收到成功响应之前在发送方超时，这将导致端点之间的状态不一致（发送方将事务视为失败，接收方将事务视为成功）。SIP代理在设置与事务相关联的Bucket Timer值时需要考虑这一点，以确保错误响应（由
Bucket Timer time out) reaches the sender before the transaction times out. If the accumulated delay of this mechanism combined with any other mechanisms in the path of processing the non-INVITE transaction cannot be kept short, this mechanism should not be used. For networks encountering such conditions, an alternative (left for possible future work) would be for the proxy to immediately return a new error code meaning "wait at least the number of seconds specified in this response and retry your request" before initiating the push notification.
Bucket Timer timeout）在事务超时之前到达发送方。如果此机制与处理非INVITE事务的路径中的任何其他机制组合的累积延迟不能保持较短，则不应使用此机制。对于遇到这种情况的网络，另一种选择（留给未来可能的工作）是代理在启动推送通知之前立即返回一个新的错误代码，意思是“至少等待此响应中指定的秒数，然后重试您的请求”。
NOTE: While the work on this document was ongoing, implementation test results showed that the time it takes for a proxy to receive the REGISTER request, from when the proxy has requested a push notification, is typically around 2 seconds. However, the time might vary depending on the characteristics and load of the SIP network and the PNS.
注意：当本文档的工作正在进行时，实现测试结果表明，从代理请求推送通知开始，代理接收注册请求所需的时间通常为2秒左右。然而，时间可能会根据SIP网络和PNS的特性和负载而变化。
In addition to the procedures described above, there are two cases where a proxy, as an optimization, can forward a SIP request towards a UA without either waiting for a 2xx response to a REGISTER request or requesting that a push notification be sent to the UA:
除了上述过程外，还有两种情况，其中作为优化，代理可以向UA转发SIP请求，而无需等待对注册请求的2xx响应或请求向UA发送推送通知：
o If the proxy is able to authenticate the sender of the REGISTER request and verify that it is allowed by authorization policy, the proxy does not need to wait for the 2xx response before it forwards the SIP request towards the UA. In such cases, the proxy will use the Contact URI of the REGISTER request when comparing it against the Request-URIs of the SIP requests in the SIP Request Push Bucket.
o 如果代理能够对注册请求的发送方进行身份验证，并验证授权策略是否允许该请求，则代理在将SIP请求转发给UA之前无需等待2xx响应。在这种情况下，代理将使用注册请求的联系人URI与SIP请求推送桶中SIP请求的请求URI进行比较。
o If the proxy has knowledge that the UA is awake, and that the UA is able to receive the SIP request without first sending a binding-refresh REGISTER request, the proxy does not need to request that a push notification be sent to the UA (the UA will not send a binding-refresh REGISTER request) before it forwards the SIP request towards the UA. The mechanisms for getting such knowledge might be dependent on implementation or deployment architecture, and are outside the scope of this document.
o 如果代理知道UA处于唤醒状态，并且UA能够在不首先发送绑定刷新寄存器请求的情况下接收SIP请求，则代理在将SIP请求转发给UA之前不需要请求向UA发送推送通知（UA将不发送绑定刷新寄存器请求）。获取此类知识的机制可能取决于实现或部署体系结构，不在本文档的范围之内。
Some PNS providers allow payload in the push notifications. This specification does not define usage of such payload (in addition to any payload that might be required by the PNS itself).
某些PNS提供程序允许推送通知中包含有效负载。本规范未定义此类有效载荷的使用（除了PNS本身可能需要的任何有效载荷）。
Some SIP dialogs might have a long lifetime with little activity. For example, when the SIP event notification mechanism [RFC6665] is used, there might be a long period between the sending of mid-dialog requests. Because of this, a SIP UA may be suspended and may need to be awakened in order to be able to receive mid-dialog requests.
某些SIP对话框的生命周期可能很长，但活动很少。例如，当使用SIP事件通知机制[RFC6665]时，在发送mid对话请求之间可能存在较长的时间间隔。因此，SIP UA可能被挂起，并且可能需要被唤醒，以便能够接收mid对话请求。
SIP requests for a new dialog and standalone SIP requests addressed towards a UA with 'pn-*' SIP URI parameters allow the proxy to request that a push notification be sent to the UA (Section 5.6.2). However, 'pn-*' SIP URI parameters will not be present in mid-dialog requests addressed towards the UA. Instead, the proxy needs to support a mechanism to store the information needed to request that a push notification be sent to the UA, and to be able to retrieve that information when it receives a mid-dialog request addressed towards the UA. This section defines such a mechanism. The SIP UA and SIP proxy procedures in this section are applied in addition to the generic procedures defined in this specification.
针对具有“pn-*”SIP URI参数的UA的新对话SIP请求和独立SIP请求允许代理请求向UA发送推送通知（第5.6.2节）。但是，“pn-*”SIP URI参数将不会出现在指向UA的mid对话请求中。相反，代理需要支持一种机制来存储请求向UA发送推送通知所需的信息，并在接收到指向UA的mid对话请求时能够检索该信息。本节定义了这种机制。本节中的SIP UA和SIP代理程序适用于本规范中定义的通用程序之外。
+--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+
| | | |
| PNS Register | | |
|---------------->| | |
| | | |
| PRID | | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | +-----------------------+ |
| | | Store PRID (key=PURR) | |
| | +-----------------------+ |
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK (PURR) | |
|<===================================| |
| | | |
| | | |
+--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+
| | | |
| PNS Register | | |
|---------------->| | |
| | | |
| PRID | | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | +-----------------------+ |
| | | Store PRID (key=PURR) | |
| | +-----------------------+ |
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK (PURR) | |
|<===================================| |
| | | |
| | | |
| SIP INVITE (PURR) | |
|===================================>| |
| | |SIP INVITE (PURR) |
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| | | |
| | | |
| | |SIP UPDATE (PURR) |
| | |<==================|
| | | |
| | +-----------------------+ |
| | | Fetch PRID (key=PURR) | |
| | +-----------------------+ |
| | | |
| |Push Request (PRID) |
| |<-----------------| |
|Push Message (PRID) | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK (PURR) | |
|<===================================| |
| | | |
| SIP UPDATE | | |
|<===================================| |
| | | |
| SIP INVITE (PURR) | |
|===================================>| |
| | |SIP INVITE (PURR) |
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK | | |
|<===================================| |
| | | |
| | | |
| | | |
| | |SIP UPDATE (PURR) |
| | |<==================|
| | | |
| | +-----------------------+ |
| | | Fetch PRID (key=PURR) | |
| | +-----------------------+ |
| | | |
| |Push Request (PRID) |
| |<-----------------| |
|Push Message (PRID) | |
|<----------------| | |
| | | |
| SIP REGISTER (PRID) | |
|===================================>| |
| | |SIP REGISTER (PRID)|
| | |==================>|
| | | |
| | | SIP 200 OK |
| | |<==================|
| SIP 200 OK (PURR) | |
|<===================================| |
| | | |
| SIP UPDATE | | |
|<===================================| |
| | | |
------- Push Notification API
------- Push Notification API
======= SIP
======= SIP
Figure 4: SIP Push Long-Lived Dialog Flow
图4:SIP推送长寿命对话框流
If the UA is willing to receive push notifications when a proxy receives a mid-dialog request addressed towards the UA, the UA MUST insert a 'pn-purr' SIP URI parameter (Section 6.2.1) in the Contact header field URI of the initial request for a dialog or the 2xx response to such requests. The UA MUST insert a parameter value identical to the last 'sip.pnspurr' feature-capability indicator (Section 6.2.1) that it received in a REGISTER response. If the UA has not received a 'sip.pnspurr' feature-capability indicator, the UA MUST NOT insert a 'pn-purr' SIP URI parameter in a request or response.
如果UA愿意在代理收到指向UA的mid对话请求时接收推送通知，UA必须在对话初始请求或对此类请求的2xx响应的联系人标头字段URI中插入“pn purr”SIP URI参数（第6.2.1节）。UA必须插入一个参数值，该参数值与它在寄存器响应中接收到的最后一个“sip.PNSPUR”功能能力指示器（第6.2.1节）相同。如果UA未收到“sip.pnspur”功能能力指示器，则UA不得在请求或响应中插入“pn purr”sip URI参数。
The UA makes the decision to receive push notifications triggered by incoming mid-dialog requests based on local policy. Such policy might be based on the type of SIP dialog, the type of media (if any) negotiated for the dialog [RFC3264], etc.
UA根据本地策略决定接收由传入的mid对话请求触发的推送通知。此类策略可能基于SIP对话的类型、为对话[RFC3264]协商的媒体类型（如果有）等。
NOTE: As the 'pn-purr' SIP URI parameter only applies to a given dialog, the UA needs to insert a 'pn-purr' parameter in the Contact header field URI of the request or response for each dialog in which the UA is willing to receive push notifications triggered by incoming mid-dialog requests.
注意：“pn purr”SIP URI参数仅适用于给定的对话，UA需要在每个对话的请求或响应的联系人标头字段URI中插入“pn purr”参数，UA希望在其中接收由传入的mid对话请求触发的推送通知。
If the proxy supports requesting push notifications triggered by mid-dialog requests being sent to the registered UA, the proxy MUST store the information (the 'pn-*' SIP URI parameters) needed to request that push notifications are sent to the UA when a proxy receives an initial REGISTER request for a binding from the UA. In addition, the proxy MUST generate a unique (within the context of the proxy) value, referred to as the PURR (Proxy Unique Registration Reference), that can be used as a key to retrieve the information.
如果代理支持请求由发送到注册UA的mid对话请求触发的推送通知，则代理必须存储在代理收到UA的绑定初始注册请求时请求将推送通知发送到UA所需的信息（“pn-*”SIP URI参数）。此外，代理必须生成唯一（在代理上下文中）值，称为PURR（代理唯一注册引用），该值可用作检索信息的密钥。
In order to prevent client fingerprinting, the proxy MUST periodically generate a new PURR value (even if 'pn-*'parameters did not change). However, as long as there are ongoing dialogs associated with the old value, the proxy MUST store it so that it can request that push notifications are sent to the UA when it receives a mid-dialog request addressed towards the UA. In addition, the PURR value MUST be generated in such a way so that it is unforgeable, anonymous, and unlinkable to entities other than the proxy. It must not be possible for an attacker to generate a valid PURR, to
为了防止客户端指纹，代理必须定期生成新的PURR值（即使“pn-*”参数没有更改）。但是，只要存在与旧值相关联的正在进行的对话，代理就必须存储该对话，以便在收到指向UA的mid对话请求时，能够请求向UA发送推送通知。此外，PURR值的生成方式必须确保其不可伪造、匿名且与代理以外的实体不可链接。攻击者不得生成有效的PURR，以
associate a PURR with a specific user, or to determine when two PURRs correspond to the same user. It can be generated, e.g., by utilizing a cryptographically secure random function with an appropriately large output size.
将PURR与特定用户关联，或确定两个PURR何时对应于同一用户。例如，可以通过使用具有适当大输出大小的加密安全随机函数来生成。
Whenever the proxy receives a 2xx response to a REGISTER request, the proxy MUST insert a 'sip.pnspurr' feature-capability indicator with the latest PURR value (see above) in the response.
每当代理收到对注册请求的2xx响应时，代理必须在响应中插入具有最新PURR值（见上文）的“sip.pnspurr”功能能力指示器。
When a proxy receives an initial request for a dialog from a UA that contains a 'pn-purr' SIP URI parameter in the Contact header field URI with a PURR value that the proxy has generated (Section 6.2.1), the proxy MUST add a Record-Route header to the request to insert itself in the dialog route [RFC3261] before forwarding the request.
当代理收到UA发出的对话初始请求时，该请求在联系人标头字段URI中包含“pn purr”SIP URI参数以及代理生成的purr值（第6.2.1节），代理必须在转发请求之前向请求添加记录路由标头，以将其自身插入对话路由[RFC3261]。
When the proxy receives an initial request for a dialog addressed towards the UA, and the proxy has generated a PURR value associated with the 'pn-*' parameters inserted in the SIP URI of the request (Section 6.2.2), the proxy MUST add a Record-Route header to the request to insert itself in the dialog route [RFC3261] before forwarding the request.
当代理收到指向UA的对话的初始请求，并且代理已生成与该请求的SIP URI（第6.2.2节）中插入的“pn-*”参数相关联的PURR值时，代理必须向该请求添加一个记录路由头，以将自身插入对话路由[RFC3261]在转发请求之前。
When the proxy receives a mid-dialog SIP request addressed towards the UA that contains a 'pn-purr' SIP URI parameter, and the proxy is able to retrieve the stored information needed to request that a push notification be sent to the UA (Section 6.2.1), the proxy MUST place the SIP request in the SIP Request Push Bucket and request that a push notification be sent to the UA.
当代理收到指向UA的mid对话SIP请求，该请求包含“pn purr”SIP URI参数，并且代理能够检索请求向UA发送推送通知所需的存储信息时（第6.2.1节），代理必须将SIP请求放入SIP请求推送桶中，并请求向UA发送推送通知。
NOTE: The 'pn-purr' SIP URI parameter will either be carried in the Request-URI or in a Route header field [RFC3261] of the SIP request depending on how the route set [RFC3261] of the mid-dialog SIP request has been constructed.
注意：“pn purr”SIP URI参数将在请求URI或SIP请求的路由头字段[RFC3261]中携带，具体取决于mid对话SIP请求的路由集[RFC3261]的构造方式。
When the proxy receives a 2xx response to a REGISTER request, the proxy checks whether the SIP Request Push Bucket contains a mid-dialog SIP request associated with the REGISTER transaction. If the bucket contains such a request, the proxy MUST remove the SIP request from the SIP Request Push Bucket and forward it towards the UA.
当代理收到对注册请求的2xx响应时，代理将检查SIP请求推送桶是否包含与注册事务关联的mid对话SIP请求。如果bucket包含这样的请求，那么代理必须从SIP请求推送bucket中删除SIP请求，并将其转发给UA。
Note that the proxy does not perform a URI comparison (Section 5.3) when processing mid-dialog requests, as a mid-dialog request will not contain the 'pn-prid', 'pn-provider', and 'pn-param' SIP URI
请注意，代理在处理mid对话请求时不执行URI比较（第5.3节），因为mid对话请求不包含“pn prid”、“pn provider”和“pn param”SIP URI
parameters. The proxy only checks for a mid-dialog request that contains the PURR value associated with the REGISTER 2xx response.
参数。代理仅检查包含与寄存器2xx响应关联的PURR值的mid对话请求。
As described in Section 5.6.2, while waiting for the push notification request to succeed, and then for the associated REGISTER request and 2xx response, the proxy needs to take into consideration that the transaction associated with the mid-dialog request will eventually time out at the sender of the request (User Agent Client), and the sender will consider the transaction a failure.
如第5.6.2节所述，在等待推送通知请求成功，然后等待关联的注册请求和2xx响应时，代理需要考虑与mid对话请求关联的事务最终将在请求的发送方（用户代理客户端）超时，发送者会认为交易失败。
When a proxy sends an error response to a mid-dialog request (e.g., due to a transaction time out), the proxy SHOULD select a response code that only impacts the transaction associated with the request [RFC5079].
当代理向mid对话请求发送错误响应时（例如，由于事务超时），代理应选择仅影响与请求相关联的事务的响应代码[RFC5079]。
[RFC3891] defines a mechanism that allows a SIP UA to replace a dialog with another dialog. A UA that wants to replace a dialog with another one will send an initial request for the new dialog. The Request-URI of the request will contain the Contact header field URI of the peer.
[RFC3891]定义了一种机制，允许SIP UA用另一个对话框替换一个对话框。想要用另一个对话框替换对话框的UA将发送新对话框的初始请求。请求的请求URI将包含对等方的联系人标头字段URI。
If a SIP proxy wants to be able to request that a push notification be sent to a UA when it receives an initial request for a dialog that replaces an existing dialog, using the mechanism in [RFC3891], the proxy and the UA MUST perform the following actions:
如果SIP代理希望能够在收到替换现有对话框的对话框的初始请求时，使用[RFC3891]中的机制，请求向UA发送推送通知，则代理和UA必须执行以下操作：
o The proxy MUST provide a PURR to the UA during registration (Section 6.2.1).
o 代理人必须在注册期间向UA提供PURR（第6.2.1节）。
o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact header field URI of either the initial request for a dialog or a 2xx response to such requests (Section 6.1.1). This includes dialogs replacing other dialogs, as those dialogs might also get replaced.
o UA必须在对话初始请求或此类请求的2xx响应的联系人标头字段URI中插入“pn purr”SIP URI参数（第6.1.1节）。这包括替换其他对话框的对话框，因为这些对话框也可能被替换。
o The proxy MUST apply the mechanism defined in Section 6.2.3 to place and retrieve the request from the SIP Request Push Bucket.
o 代理必须应用第6.2.3节中定义的机制，从SIP请求推送桶中放置和检索请求。
In addition, the operator needs to make sure that the initial request for dialogs, addressed towards the UA using the contact of the replaced dialog, will be routed to the SIP proxy (in order to request that a push notification be sent to the UA). The procedures for doing that are operator-specific and are outside the scope of this specification.
此外，操作员需要确保使用替换对话框的联系人向UA发送的初始对话框请求将路由到SIP代理（以请求向UA发送推送通知）。进行此操作的程序是特定于操作员的，不在本规范的范围内。
The 555 response code is added to the "Server-Error" Status-Code definition. 555 (Push Notification Service Not Supported) is used to indicate that the server does not support the push notification service identified in a 'pn-provider' SIP URI parameter.
555响应代码添加到“服务器错误”状态代码定义中。555（不支持推送通知服务）用于指示服务器不支持在“pn provider”SIP URI参数中标识的推送通知服务。
The use of the SIP 555 response code is only defined for SIP REGISTER responses.
SIP 555响应代码的使用仅针对SIP寄存器响应进行定义。
The sip.pns feature-capability indicator, when inserted in a Feature-Caps header field of a SIP REGISTER request or a SIP 2xx response to a REGISTER request, indicates that the entity associated with the indicator supports the SIP push mechanism and the type of push notification service indicated by the indicator value. The values defined for the 'pn-provider' SIP URI parameter are used as indicator values.
sip.pns功能能力指示符插入到sip注册请求或注册请求的sip 2xx响应的feature Caps头字段中时，表示与该指示符关联的实体支持sip推送机制和由指示符值指示的推送通知服务的类型。为“pn provider”SIP URI参数定义的值用作指示符值。
pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT pns = tag-value
pns fc=“+sip.pns”等于LDQUOT pns RDQUOT pns=标签值
tag-value = <tag-value defined in [RFC3840]>
tag-value = <tag-value defined in [RFC3840]>
The sip.vapid feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator supports the Voluntary Application Server Identification (VAPID) [RFC8292] mechanism when the entity requests that a push notification be sent to a SIP UA. The indicator value is a public key identifying the entity that can be used by a SIP UA to restrict subscriptions to that entity.
当sip.vapid特性能力指示符插入到对sip寄存器请求的sip 2xx响应中时，表示当实体请求向sip UA发送推送通知时，与指示符相关联的实体支持自愿应用服务器标识（vapid）[RFC8292]机制。指示符值是标识SIP UA可用于限制对该实体的订阅的实体的公钥。
vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid = tag-value
vapid fc=“+sip.vapid”等于LDQUOT vapid RDQUOT vapid=标记值
tag-value = <tag-value defined in [RFC3840]>
tag-value = <tag-value defined in [RFC3840]>
The sip.pnsreg feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator expects to receive binding-refresh REGISTER requests from the SIP UA associated with the binding before
sip.pnsreg功能部件能力指示符插入到对sip寄存器请求的sip 2xx响应中时，表示与该指示符相关联的实体期望从与该绑定相关联的sip UA接收绑定刷新寄存器请求
the binding expires, even if the entity does not request that a push notification be sent to the SIP UA in order to trigger the binding-refresh REGISTER requests. The indicator value conveys the minimum time (given in seconds) prior to the binding expiration when the UA MUST send the REGISTER request.
即使实体没有请求向SIP UA发送推送通知以触发绑定刷新寄存器请求，绑定也会过期。指示值表示UA必须发送注册请求时，绑定到期前的最短时间（以秒为单位）。
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT
DIGIT = <DIGIT defined in [RFC3261]>
DIGIT = <DIGIT defined in [RFC3261]>
The sip.pnsreg media feature tag, when inserted in the Contact header field of a SIP REGISTER request, indicates that the SIP UA associated with the tag is able to send binding-refresh REGISTER requests for the associated binding without being awakened by push notifications. The media feature tag has no values.
sip.pnsreg media feature标记插入sip REGISTER请求的联系人标头字段时，表示与该标记关联的sip UA能够发送关联绑定的绑定刷新寄存器请求，而不会被推送通知唤醒。媒体功能标签没有值。
pnsreg-mt = "+sip.pnsreg"
pnsreg mt=“+sip.pnsreg”
The sip.pnspurr feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator will store information that can be used to associate a mid-dialog SIP request with the binding information in the REGISTER request.
sip.PNSPUR功能能力指示符插入到sip注册请求的sip 2xx响应中时，表示与指示符关联的实体将存储可用于将mid对话sip请求与注册请求中的绑定信息关联的信息。
pnspurr-fc = "+sip.pnspurr" EQUAL LDQUOT pnspurr RDQUOT pnspurr = tag-value
pnspurr fc=“+sip.pnspurr”等于LDQUOT pnspurr RDQUOT pnspurr=标记值
tag-value = <tag-value defined in [RFC3840]>
tag-value = <tag-value defined in [RFC3840]>
This section defines new SIP URI parameters by extending the grammar for "uri-parameter" as defined in [RFC3261]. The ABNF [RFC5234] is as follows:
本节通过扩展[RFC3261]中定义的“URI参数”语法来定义新的SIP URI参数。ABNF[RFC5234]如下所示：
uri-parameter =/ pn-provider / pn-param / pn-prid / pn-purr
pn-provider = "pn-provider" [EQUAL pvalue]
pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" EQUAL pvalue
pn-purr = "pn-purr" EQUAL pvalue
uri-parameter =/ pn-provider / pn-param / pn-prid / pn-purr
pn-provider = "pn-provider" [EQUAL pvalue]
pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" EQUAL pvalue
pn-purr = "pn-purr" EQUAL pvalue
pvalue = <pvalue defined in [RFC3261]>
EQUAL = <EQUAL defined in [RFC3261]>
pvalue = <pvalue defined in [RFC3261]>
EQUAL = <EQUAL defined in [RFC3261]>
The format and semantics of pn-prid and pn-param are specific to the pn-provider value.
pn prid和pn param的格式和语义特定于pn provider值。
Parameter value characters that are not part of pvalue need to be escaped, as defined in RFC 3261.
根据RFC 3261中的定义，不属于pvalue的参数值字符需要转义。
When a new value is registered to the PNS subregistry, a reference to a specification that describes the usage of the PNS associated with the value is provided. That specification MUST contain the following information:
当新值注册到PNS子区域时，将提供对描述与该值相关联的PNS使用的规范的引用。该规范必须包含以下信息：
o The value of the 'pn-provider' SIP URI parameter.
o “pn provider”SIP URI参数的值。
o How the 'pn-prid' SIP URI parameter value is retrieved and set by the SIP UA.
o SIP UA如何检索和设置“pn prid”SIP URI参数值。
o How the 'pn-param' SIP URI parameter (if required for the specific PNS provider) value is retrieved and set by the SIP UA.
o SIP UA如何检索和设置“pn param”SIP URI参数（如果特定PNS提供程序需要）值。
10. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for Apple Push Notification service
10. Apple推送通知服务的“pn提供程序”、“pn参数”和“pn prid”URI参数
When the Apple Push Notification service (APNs) is used, the PNS-related SIP URI parameters are set as described below.
使用Apple推送通知服务（APNs）时，与PNS相关的SIP URI参数设置如下所述。
For detailed information about the parameter values, see <https://developer.apple.com/library/archive/documentation/ NetworkingInternet/Conceptual/RemoteNotificationsPG/ CommunicatingwithAPNs.html> [pns-apns].
有关参数值的详细信息，请参见<https://developer.apple.com/library/archive/documentation/ NetworkingInternet/Conceptual/RemoteNotificationsPG/communicationwithapns.html>[pns-apns]。
The value of the 'pn-provider' URI parameter is "apns".
“pn provider”URI参数的值为“apns”。
Example: pn-provider=apns
示例：pn provider=apns
The value of the 'pn-param' URI parameter is a string that is composed of two values separated by a period (.): Team ID and Topic. The Team ID is provided by Apple and is unique to a development team. The Topic consists of the Bundle ID, which uniquely identifies an application, and a service value that identifies a service associated with the application, separated by a period (.). For Voice over IP (VoIP) applications, the service value is "voip".
“pn param”URI参数的值是一个字符串，由两个值组成，两个值之间用句点（.）分隔：团队ID和主题。团队ID由Apple提供，是开发团队独有的。主题由Bundle ID和service值组成，Bundle ID唯一标识应用程序，service值标识与应用程序关联的服务，并用句点（.）分隔。对于IP语音（VoIP）应用程序，服务价值为“VoIP”。
Example: pn-param=DEF123GHIJ.com.example.yourexampleapp.voip
示例：pn param=DEF123GHIJ.com.Example.yourexampleapp.voip
NOTE: The Bundle ID might contain one or more periods (.). Hence, within the 'pn-param' value, the first period will be separating the Team ID from the Topic, and within the Topic, the last period will be separating the Bundle ID from the service.
注意：包ID可能包含一个或多个句点（.）。因此，在“pn param”值内，第一个周期将把团队ID与主题分开，而在主题内，最后一个周期将把Bundle ID与服务分开。
The value of the 'pn-prid' URI parameter is the device token, which is a unique identifier assigned by Apple to a specific app on a specific device.
“pn prid”URI参数的值是设备令牌，它是苹果为特定设备上的特定应用程序分配的唯一标识符。
Example: pn-prid=00fc13adff78512
示例：pn prid=00fc13adff78512
11. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for Google Firebase Cloud Messaging (FCM) Push Notification Service
11. Google Firebase云消息传递（FCM）推送通知服务的“pn provider”、“pn param”和“pn prid”URI参数
When Firebase Cloud Messaging (FCM) is used, the PNS-related URI parameters are set as described below.
使用Firebase云消息传递（FCM）时，与PNS相关的URI参数设置如下所述。
For detailed information about the parameter values, see <https://firebase.google.com/docs/cloud-messaging/concept-options> [pns-fcm].
有关参数值的详细信息，请参见<https://firebase.google.com/docs/cloud-messaging/concept-options>[pns fcm]。
The value of the 'pn-provider' URI parameter is "fcm".
“pn provider”URI参数的值为“fcm”。
The value of the 'pn-param' URI parameter is the Project ID.
“pn param”URI参数的值是项目ID。
The value of the 'pn-prid' URI parameter is the Registration token, which is generated by the FCM SDK for each client app instance.
“pn prid”URI参数的值是注册令牌，由FCM SDK为每个客户端应用程序实例生成。
12. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for RFC 8030 (Generic Event Delivery Using HTTP Push)
12. RFC 8030的“pn provider”、“pn param”和“pn prid”URI参数（使用HTTP推送的通用事件传递）
When Generic Event Delivery Using HTTP Push is used, the PNS-related URI parameters are set as described below.
使用HTTP推送的通用事件传递时，与PNS相关的URI参数设置如下所述。
The value of the 'pn-provider' URI parameter is "webpush".
“pn provider”URI参数的值为“webpush”。
The value of the 'pn-param' URI parameter MUST NOT be used.
不能使用'pn param'URI参数的值。
The value of the 'pn-prid' URI parameter is the push subscription URI.
“pn prid”URI参数的值是推送订阅URI。
See RFC 8030 [RFC8030] for more details.
详见RFC 8030[RFC8030]。
Note that encryption for web push [RFC8291] is not used; therefore, parameters for message encryption are not defined in this specification. Web push permits the sending of a push message without a payload without encryption.
请注意，未使用web推送加密[RFC8291]；因此，本规范中未定义消息加密的参数。Web推送允许在没有有效负载的情况下发送推送消息，而无需加密。
The security considerations for the use and operation of any particular PNS (e.g., how users and devices are authenticated and authorized) are out of scope for this document. [RFC8030] documents the security considerations for the PNS defined in that specification. Security considerations for other PNSs are left to their respective specifications.
使用和操作任何特定PNS的安全注意事项（例如，用户和设备的身份验证和授权方式）不在本文件范围内。[RFC8030]记录了该规范中定义的PNS的安全注意事项。其他PNS的安全注意事项由其各自的规范决定。
Typically, the PNS requires the SIP proxy requesting push notifications to be authenticated and authorized by the PNS. In some cases, the PNS also requires the SIP application (or the SIP application developer) to be identified in order for the application to request push notifications. Unless the PNS authenticates and authorizes the PNS, a malicious endpoint or network entity that managed to get access to the parameters transported in the SIP signaling might be able to request that push notifications are sent to a UA. Such push notifications will impact the battery life of the UA and trigger unnecessary SIP traffic.
通常，PNS要求请求推送通知的SIP代理由PNS进行身份验证和授权。在某些情况下，PNS还要求识别SIP应用程序（或SIP应用程序开发人员），以便应用程序请求推送通知。除非PNS认证和授权PNS，否则设法访问SIP信令中传输的参数的恶意端点或网络实体可能能够请求向UA发送推送通知。此类推送通知将影响UA的电池寿命，并触发不必要的SIP流量。
[RFC8292] defines a mechanism that allows a proxy to identify itself to a PNS by signing a JSON Web Token (JWT) sent to the PNS using a key pair. The public key serves as an identifier of the proxy and can be used by devices to restrict push notifications to the proxy associated with the key.
[RFC8292]定义了一种机制，允许代理通过使用密钥对发送给PNS的JSON Web令牌（JWT）进行签名，从而向PNS标识自己。公钥用作代理的标识符，可由设备用于将推送通知限制到与密钥关联的代理。
Operators MUST ensure that the SIP signaling is properly secured, e.g., using encryption, from malicious network entities. TLS MUST be used unless the operators know that the signaling is secured using some other mechanism that provides strong crypto properties.
运营商必须确保SIP信令受到恶意网络实体的适当保护，例如使用加密。必须使用TLS，除非运营商知道信令是使用提供强加密属性的其他机制进行安全保护的。
In addition to the information that needs to be exchanged between a device and the PNS in order to establish a push notification subscription, the mechanism defined in this document does not require any additional information to be exchanged between the device and the PNS.
除了为了建立推送通知订阅而需要在设备和PNS之间交换的信息外，本文档中定义的机制不需要在设备和PNS之间交换任何附加信息。
The mechanism defined in this document does not require a proxy to insert any payload (in addition to possible payload used for the PNS itself) when requesting push notifications.
本文档中定义的机制不需要代理在请求推送通知时插入任何有效负载（除了用于PNS本身的可能有效负载）。
Operators MUST ensure that the PNS-related SIP URI parameters conveyed by a user in the Contact URI of a REGISTER request are not sent to other users or to non-trusted network entities. One way to convey contact information is by using the SIP event package for registrations mechanism [RFC3680]. [RFC3680] defines generic security considerations for the SIP event package for registrations. As the PNS-related SIP URI parameters conveyed in the REGISTER
运营商必须确保用户在注册请求的联系人URI中传递的与PNS相关的SIP URI参数不会发送给其他用户或不受信任的网络实体。传递联系信息的一种方法是使用SIP事件包注册机制[RFC3680]。[RFC3680]定义注册SIP事件包的一般安全注意事项。作为在寄存器中传输的与PNS相关的SIP URI参数
request contain sensitive information, operators that support the event package MUST ensure that event package subscriptions are properly authenticated and authorized, and that the SIP URI parameters are not inserted in event notifications sent to other users or to non-trusted network entities.
请求包含敏感信息，支持事件包的操作员必须确保事件包订阅经过正确的身份验证和授权，并且SIP URI参数不会插入发送给其他用户或不受信任的网络实体的事件通知中。
This section defines new SIP URI Parameters that extend the "SIP/SIPS URI Parameters" subregistry [RFC3969] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
本节定义了扩展SIP参数注册表下“SIP/SIPS URI参数”子区[RFC3969]的新SIP URI参数(https://www.iana.org/assignments/sip-parameters).
Parameter Name: pn-provider
参数名称：pn提供程序
Predefined Values: No
预定义值：否
Reference: RFC 8599
参考：RFC 8599
Parameter Name: pn-param
参数名称：pn param
Predefined Values: No
预定义值：否
Reference: RFC 8599
参考：RFC 8599
Parameter Name: pn-prid
参数名称：pn prid
Predefined Values: No
预定义值：否
Reference: RFC 8599
参考：RFC 8599
Parameter Name: pn-purr
参数名称：pn purr
Predefined Values: No
预定义值：否
Reference: RFC 8599
参考：RFC 8599
This section defines a new SIP response code that extends the "Response Codes" subregistry [RFC3261] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
本节定义了一个新的SIP响应代码，该代码扩展了SIP参数注册表下的“响应代码”子区[RFC3261](https://www.iana.org/assignments/sip-parameters).
Response Code Number: 555
响应代码：555
Default Reason Phrase: Push Notification Service Not Supported
默认原因短语：不支持推送通知服务
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
本节定义了一个新的功能能力指标，该指标扩展了SIP参数注册表下的“SIP功能能力指标注册树”子区[RFC6809](https://www.iana.org/assignments/sip-parameters).
Name: sip.pns
姓名：sip.pns
Description: This feature-capability indicator, when inserted in a Feature-Caps header field of a SIP REGISTER request or a SIP 2xx response to a REGISTER request, denotes that the entity associated with the indicator supports the SIP push mechanism and the type of push notification service conveyed by the indicator value.
描述：当插入SIP注册请求的feature Caps头字段或注册请求的SIP 2xx响应中时，此功能能力指示符表示与指示符关联的实体支持SIP推送机制和指示符值所传递的推送通知服务的类型。
Reference: RFC 8599
参考：RFC 8599
Contact: IESG (iesg@ietf.org)
联系人：IESG(iesg@ietf.org)
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
本节定义了一个新的功能能力指标，该指标扩展了SIP参数注册表下的“SIP功能能力指标注册树”子区[RFC6809](https://www.iana.org/assignments/sip-parameters).
Name: sip.vapid
姓名：sip.vapid
Description: This feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator supports the Voluntary Application Server Identification (VAPID) mechanism when the entity requests that a push notification be sent to a SIP UA.
描述：当在SIP注册请求的SIP 2xx响应中插入此功能能力指示器时，表示当实体请求向SIP UA发送推送通知时，与该指示器关联的实体支持自愿应用程序服务器标识（VAPID）机制。
The indicator value is a public key identifying the entity, which can be used by a SIP UA to restrict subscriptions to that entity.
指示符值是标识实体的公钥，SIP UA可以使用该公钥来限制对该实体的订阅。
Reference: RFC 8599
参考：RFC 8599
Contact: IESG (iesg@ietf.org)
联系人：IESG(iesg@ietf.org)
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
本节定义了一个新的功能能力指标，该指标扩展了SIP参数注册表下的“SIP功能能力指标注册树”子区[RFC6809](https://www.iana.org/assignments/sip-parameters).
Name: sip.pnsreg
姓名：sip.pnsreg
Description: This feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator expects to receive binding-refresh REGISTER requests for the binding from the SIP UA associated with the binding before the binding expires, even if the entity does not request that a push notification be sent to the SIP UA in order to trigger the binding-refresh REGISTER requests. The indicator value conveys the minimum time (given in seconds) prior to the binding expiration when the UA MUST send the REGISTER request.
描述：当将此功能能力指示符插入SIP 2xx对SIP寄存器请求的响应中时，表示与指示符关联的实体期望在绑定到期之前从与绑定关联的SIP UA接收绑定刷新寄存器请求，即使实体没有请求向SIP UA发送推送通知以触发绑定刷新寄存器请求。指示值表示UA必须发送注册请求时，绑定到期前的最短时间（以秒为单位）。
Reference: RFC 8599
参考：RFC 8599
Contact: IESG (iesg@ietf.org)
联系人：IESG(iesg@ietf.org)
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).
本节定义了一个新的功能能力指标，该指标扩展了SIP参数注册表下的“SIP功能能力指标注册树”子区[RFC6809](https://www.iana.org/assignments/sip-parameters).
Name: sip.pnspurr
姓名：sip.pnspurr
Description: This feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, conveys that the entity associated with the indicator will store information that can be used to associate a mid-dialog SIP request with the binding information in the REGISTER request. The indicator value is an identifier that can be used as a key to retrieve the binding information.
描述：当插入SIP注册请求的SIP 2xx响应中时，此功能能力指示器表示与指示器关联的实体将存储可用于将mid对话SIP请求与注册请求中的绑定信息关联的信息。指示符值是一个标识符，可用作检索绑定信息的键。
Reference: RFC 8599
参考：RFC 8599
Contact: IESG (iesg@ietf.org)
联系人：IESG(iesg@ietf.org)
This section defines a new media feature tag that extends the "SIP Media Feature Tag Registration Tree" subregistry [RFC3840] under the "Media Feature Tags" registry (https://www.iana.org/assignments/ media-feature-tags).
本节定义了一个新的媒体功能标签，该标签扩展了“媒体功能标签”注册表下的“SIP媒体功能标签注册树”子区[RFC3840](https://www.iana.org/assignments/ 媒体功能标签）。
Media feature tag name: sip.pnsreg
媒体功能标签名称：sip.pnsreg
Summary of the media feature indicated by this feature tag: This media feature tag, when inserted in the Contact header field of a SIP REGISTER request, conveys that the SIP UA associated with the tag is able to send binding-refresh REGISTER requests associated with the registration without being awakened by push notifications.
此功能标签指示的媒体功能摘要：此媒体功能标签插入SIP注册请求的联系人标头字段时，表示与该标签相关联的SIP UA能够发送与注册相关联的绑定刷新注册请求，而不会被推送通知唤醒。
Values appropriate for use with this feature tag: none
适用于此功能标记的值：无
Related standards or documents: RFC 8599
相关标准或文件：RFC 8599
Security considerations: This media feature tag does not introduce new security considerations, as it simply indicates support for a basic SIP feature. If an attacker manages to remove the media feature tag, push notifications will not be requested to be sent to the client.
安全注意事项：此媒体功能标签不会引入新的安全注意事项，因为它只是表示支持基本的SIP功能。如果攻击者成功删除媒体功能标签，则不会请求向客户端发送推送通知。
Contact: IESG (iesg@ietf.org)
联系人：IESG(iesg@ietf.org)
This section creates a new subregistry, "PNS", under the SIP Parameters registry (https://www.iana.org/assignments/ sip-parameters).
本节在SIP参数注册表下创建一个新的子区域“PNS”(https://www.iana.org/assignments/ sip参数）。
The purpose of the subregistry is to register SIP URI 'pn-provider' values.
子区域的目的是注册SIP URI“pn provider”值。
When a SIP URI 'pn-provider' value is registered in the subregistry, it needs to meet the "Specification Required" policies defined in [RFC8126].
当SIP URI“pn provider”值在子域中注册时，它需要满足[RFC8126]中定义的“所需规范”策略。
This subregistry is defined as a table that contains the following three columns:
该子区域定义为包含以下三列的表：
Value: The token under registration
值：正在注册的令牌
Description: The name of the Push Notification Service (PNS)
描述：推送通知服务（PNS）的名称
Document: A reference to the document defining the registration
文档：对定义注册的文档的引用
This specification registers the following values:
本规范登记了以下值：
Value Description Document
------- -------------------------------------- ----------
Value Description Document
------- -------------------------------------- ----------
apns Apple Push Notification service RFC 8599 fcm Firebase Cloud Messaging RFC 8599 webpush Generic Event Delivery Using HTTP Push RFC 8599
apns苹果推送通知服务RFC 8599 fcm Firebase云消息RFC 8599 webpush使用HTTP推送RFC 8599进行一般事件传递
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc3261>.
[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, <https://www.rfc-editor.org/info/rfc3840>.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，DOI 10.17487/RFC3840，2004年8月<https://www.rfc-editor.org/info/rfc3840>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004, <https://www.rfc-editor.org/info/rfc3891>.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 3891，DOI 10.17487/RFC3891，2004年9月<https://www.rfc-editor.org/info/rfc3891>.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, <https://www.rfc-editor.org/info/rfc3969>.
[RFC3969]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，DOI 10.17487/RFC3969，2004年12月<https://www.rfc-editor.org/info/rfc3969>.
[RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)", RFC 5079, DOI 10.17487/RFC5079, December 2007, <https://www.rfc-editor.org/info/rfc5079>.
[RFC5079]Rosenberg，J.，“拒绝会话启动协议（SIP）中的匿名请求”，RFC 5079，DOI 10.17487/RFC5079，2007年12月<https://www.rfc-editor.org/info/rfc5079>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809, November 2012, <https://www.rfc-editor.org/info/rfc6809>.
[RFC6809]Holmberg，C.，Sedlacek，I.，和H.Kaplan，“表明支持会话启动协议（SIP）中的功能和能力的机制”，RFC 6809，DOI 10.17487/RFC6809，2012年11月<https://www.rfc-editor.org/info/rfc6809>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, <https://www.rfc-editor.org/info/rfc8030>.
[RFC8030]Thomson，M.，Damaggio，E.，和B.Raymor，Ed.，“使用HTTP推送的通用事件交付”，RFC 8030，DOI 10.17487/RFC80302016年12月<https://www.rfc-editor.org/info/rfc8030>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server Identification (VAPID) for Web Push", RFC 8292, DOI 10.17487/RFC8292, November 2017, <https://www.rfc-editor.org/info/rfc8292>.
[RFC8292]Thomson，M.和P.Beverloo，“Web推送的自愿应用程序服务器识别（VAPID）”，RFC 8292，DOI 10.17487/RFC8292，2017年11月<https://www.rfc-editor.org/info/rfc8292>.
[pns-apns] Apple Inc., "Local and Remote Notification Programming Guide: Communicating with APNs", <https://developer.apple. com/library/archive/documentation/NetworkingInternet/Conce ptual/RemoteNotificationsPG/CommunicatingwithAPNs.html>.
[pns apns]苹果公司，“本地和远程通知编程指南：与apns通信”<https://developer.apple. com/library/archive/documentation/NetworkingInternet/conceptual/RemoteNotificationsPG/communicationwithapns.html>。
[pns-fcm] Google Inc., "Firebase Cloud Messaging", <https://firebase.google.com/docs/cloud-messaging/ concept-options>.
[pns fcm]谷歌公司，“Firebase云消息传递”<https://firebase.google.com/docs/cloud-messaging/ 概念选项>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<https://www.rfc-editor.org/info/rfc3264>.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, DOI 10.17487/RFC3680, March 2004, <https://www.rfc-editor.org/info/rfc3680>.
[RFC3680]Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC 3680，DOI 10.17487/RFC3680，2004年3月<https://www.rfc-editor.org/info/rfc3680>.
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, DOI 10.17487/RFC4320, January 2006, <https://www.rfc-editor.org/info/rfc4320>.
[RFC4320]Sparks，R.“解决会话启动协议（SIP）非邀请事务已识别问题的措施”，RFC 4320，DOI 10.17487/RFC4320，2006年1月<https://www.rfc-editor.org/info/rfc4320>.
[RFC4321] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, DOI 10.17487/RFC4321, January 2006, <https://www.rfc-editor.org/info/rfc4321>.
[RFC4321]Sparks，R.“与会话启动协议（SIP）非邀请事务相关的问题”，RFC 4321，DOI 10.17487/RFC4321，2006年1月<https://www.rfc-editor.org/info/rfc4321>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc5626>.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, DOI 10.17487/RFC6665, July 2012, <https://www.rfc-editor.org/info/rfc6665>.
[RFC6665]Roach，A.，“SIP特定事件通知”，RFC 6665，DOI 10.17487/RFC66652012年7月<https://www.rfc-editor.org/info/rfc6665>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, DOI 10.17487/RFC8291, November 2017, <https://www.rfc-editor.org/info/rfc8291>.
[RFC8291]Thomson，M.，“Web推送的消息加密”，RFC 8291，DOI 10.17487/RFC8291，2017年11月<https://www.rfc-editor.org/info/rfc8291>.
Acknowledgements
致谢
Thanks to Paul Kyzivat, Dale Worley, Ranjit Avasarala, Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula, Liviu Chircu, Roman Shpount, Yehoshua Gev, and Jean Mahoney for reading the text and providing useful feedback.
感谢Paul Kyzivat、Dale Worley、Ranjit Avasarala、Martin Thomson、Mikael Klein、Susanna Sjoholm、Kari Pekka Perttula、Liviu Chircu、Roman Sppount、Yehoshua Gev和Jean Mahoney阅读文本并提供有用的反馈。
Authors' Addresses
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420芬兰
Email: christer.holmberg@ericsson.com
Email: christer.holmberg@ericsson.com
Michael Arnold Metaswitch Networks 100 Church Street Enfield EN2 6BQ United Kingdom
Michael Arnold Metaswitch Networks 100 Church Street Enfield EN2 6BQ英国
Email: Michael.Arnold@metaswitch.com
Email: Michael.Arnold@metaswitch.com