summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8599.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8599.txt')
-rw-r--r--doc/rfc/rfc8599.txt2243
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]
+