RFC 8599
Push Notification with the Session Initiation Protocol (SIP)
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.
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
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
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.
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
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.
+--------+ +---------+ +-----------+ +-------------+ | | | | | | | 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
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.
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.
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).
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.
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.
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 Example4.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.
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.
(page 14 continued on part 2)
