doc: Add RFC documents

1 files changed, 2243 insertions, 0 deletions

diff --git a/doc/rfc/rfc8599.txt b/doc/rfc/rfc8599.txt
new file mode 100644
index 0000000..9509d9d
--- /dev/null
+++ b/doc/rfc/rfc8599.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+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)
+
+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.
+
+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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                    [Page 1]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+Copyright Notice
+
+   Copyright (c) 2019 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+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
+
+
+
+Holmberg & Arnold            Standards Track                    [Page 2]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+     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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                    [Page 3]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+1.  Introduction
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                    [Page 4]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   Figure 1 shows the generic push notification architecture supported
+   by the mechanism in this document.
+
+   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
+
+
+
+Holmberg & Arnold            Standards Track                    [Page 5]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                    [Page 6]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+     +--------+      +---------+        +-----------+    +-------------+
+     |        |      |         |        |           |    | 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
+
+                    Figure 1: SIP Push Information Flow
+
+
+
+Holmberg & Arnold            Standards Track                    [Page 7]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+     Example of a SIP REGISTER request in the flow above:
+
+     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.  Conventions
+
+   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.
+
+3.  Push Resource ID (PRID)
+
+   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.
+
+   The format of the PRID varies depending on the 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                    [Page 8]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+4.  SIP User Agent (UA) Behavior
+
+4.1.  REGISTER
+
+   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.
+
+   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).
+
+   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.
+
+   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.
+
+   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.
+
+4.1.1.  Request Push Notifications
+
+   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.
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                    [Page 9]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+   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.
+
+   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.
+
+   NOTE: The VAPID-specific procedures of the SIP UA are outside the
+   scope of this document.
+
+   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.
+
+   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).
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 10]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+4.1.2.  Disable Push Notifications
+
+   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.
+
+4.1.3.  Receive Push Notifications
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+4.1.4.  Sending Binding-Refresh Requests Using Non-push Mechanism
+
+   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.
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 11]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+   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).
+
+   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).
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 12]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+     Example of a SIP REGISTER request including a 'sip.pnsreg'
+     media feature tag:
+
+     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/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
+
+4.1.5.  Query Network PNS Capabilities
+
+   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.
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 13]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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:
+
+   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  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.
+
+   The UA MUST NOT insert a 'pn-prid' SIP URI parameter in the Contact
+   header field URI of the REGISTER request.
+
+   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.
+
+   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.
+
+   NOTE: It is optional for a UA to perform a query before it requests
+   push notifications from the SIP network.
+
+5.  SIP Proxy Behavior
+
+5.1.  PNS Provider
+
+   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.
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 14]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+5.2.  SIP Request Push Bucket
+
+   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.
+
+   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.
+
+5.3.  SIP URI Comparison Rules
+
+   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.
+
+   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.
+
+5.4.  Indicate Support of Type of PNS
+
+   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-
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 15]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+   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.
+
+5.5.  Trigger Periodic Binding Refresh
+
+   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].
+
+   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.
+
+   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.
+
+   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.
+
+   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).
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 16]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+5.6.  SIP Requests
+
+5.6.1.  REGISTER
+
+   This section describes how a SIP proxy processes SIP REGISTER
+   requests (initial REGISTER request for a binding or a binding-refresh
+   REGISTER request).
+
+   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.
+
+5.6.1.1.  Request Push Notifications
+
+   This section describes the SIP proxy procedures when a SIP UA
+   requests push notifications from the SIP network.
+
+   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.
+
+   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.
+
+   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:
+
+   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
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 17]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+      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.
+
+   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  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.
+
+   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.
+
+   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:
+
+   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  The proxy MUST indicate support of the same type of PNS in the
+      REGISTER response.  In addition:
+
+      *  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.
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 18]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+      *  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.
+
+5.6.1.2.  Query Network PNS Capabilities
+
+   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).
+
+   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.
+
+   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:
+
+   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  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  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.
+
+   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.
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 19]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+5.6.2.  Initial Request for Dialog or Standalone Request
+
+   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.
+
+   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.
+
+   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.
+
+   When the proxy receives a 2xx response to the REGISTER request, the
+   proxy performs the following actions:
+
+   o  The proxy processes the REGISTER response as described in
+      Section 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.
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 20]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 21]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+   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.
+
+   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:
+
+   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  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.
+
+   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).
+
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 22]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+6.  Support of Long-Lived SIP Dialogs
+
+   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 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.
+
+     +--------+      +---------+        +-----------+    +-------------+
+     |        |      |         |        |           |    | 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)                  |                   |
+         |<===================================|                   |
+         |                 |                  |                   |
+         |                 |                  |                   |
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 23]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+         | 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
+
+         ======= SIP
+
+                 Figure 4: SIP Push Long-Lived Dialog Flow
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 24]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+6.1.  SIP UA Behavior
+
+6.1.1.  Initial Request for Dialog
+
+   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.
+
+   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.
+
+   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.
+
+6.2.  SIP Proxy Behavior
+
+6.2.1.  REGISTER
+
+   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.
+
+   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
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 25]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+   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.
+
+6.2.2.  Initial Request for Dialog
+
+   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.
+
+   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.
+
+6.2.3.  Mid-dialog Request
+
+   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.
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 26]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   parameters.  The proxy only checks for a mid-dialog request that
+   contains the PURR value associated with the REGISTER 2xx response.
+
+   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.
+
+   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].
+
+7.  Support of SIP Replaces
+
+   [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.
+
+   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:
+
+   o  The proxy MUST provide a PURR to the UA during registration
+      (Section 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  The proxy MUST apply the mechanism defined in Section 6.2.3 to
+      place and retrieve the request from the SIP Request Push Bucket.
+
+   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.
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 27]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+8.  Grammar
+
+8.1.  555 (Push Notification Service Not Supported) Response Code
+
+   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.
+
+   The use of the SIP 555 response code is only defined for SIP REGISTER
+   responses.
+
+8.2.  'sip.pns' Feature-Capability Indicator
+
+   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.
+
+     pns-fc          = "+sip.pns" EQUAL LDQUOT pns RDQUOT
+     pns             = tag-value
+
+     tag-value = <tag-value defined in [RFC3840]>
+
+8.3.  'sip.vapid' Feature-Capability Indicator
+
+   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.
+
+     vapid-fc          = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT
+     vapid             = tag-value
+
+     tag-value = <tag-value defined in [RFC3840]>
+
+8.4.  'sip.pnsreg' Feature-Capability Indicator
+
+   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
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 28]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+     pns-fc          = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
+     reg             = 1*DIGIT
+
+     DIGIT = <DIGIT defined in [RFC3261]>
+
+8.5.  'sip.pnsreg' Media Feature Tag
+
+   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.
+
+     pnsreg-mt          = "+sip.pnsreg"
+
+8.6.  'sip.pnspurr' Feature-Capability Indicator
+
+   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.
+
+     pnspurr-fc        = "+sip.pnspurr" EQUAL LDQUOT pnspurr RDQUOT
+     pnspurr           = tag-value
+
+     tag-value = <tag-value defined in [RFC3840]>
+
+8.7.  SIP URI Parameters
+
+   This section defines new SIP URI parameters by extending the grammar
+   for "uri-parameter" as defined in [RFC3261].  The ABNF [RFC5234] is
+   as follows:
+
+     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]>
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 29]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   The format and semantics of pn-prid and pn-param are specific to the
+   pn-provider value.
+
+   Parameter value characters that are not part of pvalue need to be
+   escaped, as defined in RFC 3261.
+
+9.  PNS Registration Requirements
+
+   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:
+
+   o  The value of the 'pn-provider' SIP URI parameter.
+
+   o  How the 'pn-prid' SIP URI parameter value is retrieved and set by
+      the SIP UA.
+
+   o  How the 'pn-param' SIP URI parameter (if required for the specific
+      PNS provider) value is retrieved and set by the SIP UA.
+
+10.  'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for Apple
+     Push Notification service
+
+   When the Apple Push Notification service (APNs) is used, the
+   PNS-related SIP URI parameters are set as described below.
+
+   For detailed information about the parameter values, see
+   <https://developer.apple.com/library/archive/documentation/
+   NetworkingInternet/Conceptual/RemoteNotificationsPG/
+   CommunicatingwithAPNs.html> [pns-apns].
+
+   The value of the 'pn-provider' URI parameter is "apns".
+
+   Example: 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".
+
+   Example: pn-param=DEF123GHIJ.com.example.yourexampleapp.voip
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 30]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+   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.
+
+   Example: pn-prid=00fc13adff78512
+
+11.  'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for Google
+     Firebase Cloud Messaging (FCM) Push Notification Service
+
+   When Firebase Cloud Messaging (FCM) is used, the PNS-related URI
+   parameters are set as described below.
+
+   For detailed information about the parameter values, see
+   <https://firebase.google.com/docs/cloud-messaging/concept-options>
+   [pns-fcm].
+
+   The value of the 'pn-provider' URI parameter is "fcm".
+
+   The value of the 'pn-param' URI parameter is the Project 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.
+
+12.  'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for RFC
+     8030 (Generic Event Delivery Using HTTP Push)
+
+   When Generic Event Delivery Using HTTP Push is used, the PNS-related
+   URI parameters are set as described below.
+
+   The value of the 'pn-provider' URI parameter is "webpush".
+
+   The value of the 'pn-param' URI parameter MUST NOT be used.
+
+   The value of the 'pn-prid' URI parameter is the push subscription
+   URI.
+
+   See RFC 8030 [RFC8030] for more details.
+
+   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.
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 31]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+13.  Security Considerations
+
+   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.
+
+   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.
+
+   [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.
+
+   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.
+
+   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.
+
+   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.
+
+   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
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 32]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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.
+
+14.  IANA Considerations
+
+14.1.  SIP URI Parameters
+
+   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).
+
+14.1.1.  pn-provider
+
+     Parameter Name: pn-provider
+
+     Predefined Values:  No
+
+     Reference:  RFC 8599
+
+14.1.2.  pn-param
+
+     Parameter Name: pn-param
+
+     Predefined Values:  No
+
+     Reference:  RFC 8599
+
+14.1.3.  pn-prid
+
+     Parameter Name: pn-prid
+
+     Predefined Values:  No
+
+     Reference:  RFC 8599
+
+14.1.4.  pn-purr
+
+     Parameter Name: pn-purr
+
+     Predefined Values:  No
+
+     Reference:  RFC 8599
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 33]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+14.2.  SIP Response Codes
+
+14.2.1.  555 (Push Notification Service Not Supported)
+
+   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).
+
+      Response Code Number:   555
+
+      Default Reason Phrase:  Push Notification Service Not Supported
+
+14.3.  SIP Global Feature-Capability Indicator
+
+14.3.1.  sip.pns
+
+   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).
+
+    Name: 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.
+
+    Reference: RFC 8599
+
+    Contact: IESG (iesg@ietf.org)
+
+14.3.2.  sip.vapid
+
+   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).
+
+     Name: 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.
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 34]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+          The indicator value is a public key identifying the entity,
+          which can be used by a SIP UA to restrict subscriptions to
+          that entity.
+
+     Reference: RFC 8599
+
+     Contact: IESG (iesg@ietf.org)
+
+14.3.3.  sip.pnsreg
+
+   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).
+
+    Name: 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.
+
+    Reference: RFC 8599
+
+    Contact: IESG (iesg@ietf.org)
+
+14.3.4.  sip.pnspurr
+
+   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).
+
+    Name: 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.
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 35]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+    Reference: RFC 8599
+
+    Contact: IESG (iesg@ietf.org)
+
+14.4.  SIP Media Feature Tag
+
+14.4.1.  sip.pnsreg
+
+   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).
+
+     Media feature tag name: 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.
+
+     Values appropriate for use with this feature tag: none
+
+     Related standards or documents: 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.
+
+     Contact: IESG (iesg@ietf.org)
+
+
+14.5.  PNS Subregistry Establishment
+
+   This section creates a new subregistry, "PNS", under the SIP
+   Parameters registry (https://www.iana.org/assignments/
+   sip-parameters).
+
+   The purpose of the subregistry is to register SIP URI 'pn-provider'
+   values.
+
+   When a SIP URI 'pn-provider' value is registered in the subregistry,
+   it needs to meet the "Specification Required" policies defined in
+   [RFC8126].
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 36]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   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)
+
+     Document:     A reference to the document defining the registration
+
+   This specification registers the following values:
+
+     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
+
+15.  References
+
+15.1.  Normative References
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 37]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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-fcm]  Google Inc., "Firebase Cloud Messaging",
+              <https://firebase.google.com/docs/cloud-messaging/
+              concept-options>.
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 38]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+15.2.  Informative References
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [RFC6665]  Roach, A., "SIP-Specific Event Notification", RFC 6665,
+              DOI 10.17487/RFC6665, July 2012,
+              <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>.
+
+   [RFC8291]  Thomson, M., "Message Encryption for Web Push", RFC 8291,
+              DOI 10.17487/RFC8291, November 2017,
+              <https://www.rfc-editor.org/info/rfc8291>.
+
+
+
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 39]
+
+RFC 8599                        SIP PUSH                        May 2019
+
+
+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.
+
+Authors' Addresses
+
+   Christer Holmberg
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   Email: christer.holmberg@ericsson.com
+
+
+   Michael Arnold
+   Metaswitch Networks
+   100 Church Street
+   Enfield  EN2 6BQ
+   United Kingdom
+
+   Email: Michael.Arnold@metaswitch.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg & Arnold            Standards Track                   [Page 40]
+