SIPCORE Working Group C. Holmberg Internet-Draft Ericsson Intended status: Standards Track M. Arnold Expires: October 13, 2018 Metaswitch Networks April 11, 2018 Push Notification with the Session Initiation Protocol (SIP) draft-ietf-sipcore-sip-push-11 Abstract This document describes how a Push Notification Service (PNS) can be used to awake suspended Session Initiation Protocol (SIP) User Agents (UAs), using push notifications, for the UA to be able to send re- registration REGISTER requests and to receive receive incoming SIP requests. The document defines new SIP URI parameters and new feature-capability indicators that can be used in SIP messages to indicate support of the mechanism defined in this document, to exchange PNS information between the SIP User Agent (UA) and the SIP entity that will request push notifications towards the UA, and to trigger such push notification requests. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 13, 2018. Copyright Notice Copyright (c) 2018 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 (http://trustee.ietf.org/license-info) in effect on the date of Holmberg & Arnold Expires October 13, 2018 [Page 1] Internet-Draft SIP PUSH April 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6 4.1. Request Push Notifications from Network . . . . . . . . . 6 4.2. Query Network Push Notification Capabilities . . . . . . 8 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9 5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 9 5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 9 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 10 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 12 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. 555 (Push Notification Service Not Supported) Response Code . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. 556 (Push Notification Failed) Response Code . . . . . . 14 6.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 14 6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 14 6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 15 6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 15 6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 16 7. PNS Registration Requirements . . . . . . . . . . . . . . . . 16 8. pn-provider, pn-param and pn-prid URI Parameters for Apple Push Notification service . . . . . . . . . . . . . . . . . . 16 9. pn-provider, pn-param and pn-prid URI Parameters for Google Firebase Cloud Messaging (FCM) push notification service . . 17 10. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 19 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 19 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 19 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 19 12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 19 12.2.1. 555 (Push Notification Service Not Supported) . . . 19 12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 20 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 20 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 20 Holmberg & Arnold Expires October 13, 2018 [Page 2] Internet-Draft SIP PUSH April 2018 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 21 12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 21 12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 22 12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 22 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 23 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction In order to save resources (e.g., battery life) some devices (especially mobile devices) and operating systems will suspend applications when not used. In some cases, internal timers cannot be used to awake such applications, nor will incoming network traffic awake the application. Instead, the only way to awake the application is by using a Push Notification Service (PNS). Typically each operating system uses a dedicated PNS. For example, Apple iOS devices use the Apple Push Notification service (APNs) while Android devices use the Firebase Cloud Messaging (FCM) service. Because of the restrictions above, Session Initiation Protocol (SIP) User Agents (UAs) [RFC3261] can not be awoken, in order to send re- registration SIP REGISTER requests and to receive incoming SIP requests, without using a PNS to awake the UA in order to perform those functions. Also, without being able to use internal timers in order to awake applications, a UA will not be able to maintain connections e.g., using the SIP Outbound Mechanism [RFC5626], as it requires the UA to send periodic keep-alive messages. This document describes how PNSs can be used to awake suspended UAs, using push notifications, to be able to send re-registration REGISTER requests and to 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, to exchange PNS information between the UA and the SIP entity (realized as a SIP proxy in this document) that will request push notifications towards the UA, and to request such push notification requests. NOTE: Even if a UA is able to awake by other means than receiving push notifications (e.g., by using internal timers) in order to send periodic re-registration REGISTER requests, it might still be useful to suspend the application between the sending of re-registration Holmberg & Arnold Expires October 13, 2018 [Page 3] Internet-Draft SIP PUSH April 2018 requests (as it will save battery life etc) and use push notifications to awake the UA when an incoming SIP request UA arrives. When a UA registers to a PNS, 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 that will request push notifications towards the UA. When the proxy receives (or, if the proxy is the SIP registrar [RFC3261], initiates) a SIP request for a new dialog, or a stand- alone SIP request, addressed towards a UA, or when the proxy determines that the UA needs to send a re-registration REGISTER request, the proxy will request a push notification towards the UA, using the PNS of the UA. Once the UA receives the push notification, it will be able to send a re-registration REGISTER request and receive the incoming SIP request. The proxy will receive and forward (or, if the proxy is the registrar, process) the REGISTER request. If the push notification request was triggered by a SIP request addressed towards the UA (see above), once the REGISTER request has been accepted by the registrar, and the associated SIP 2xx response has been forwarded by the proxy towards the UA, the proxy can forward the SIP request towards the UA using normal SIP routing procedures. Different PNSs exist today. Some are based on the standardized mechanism defined in [RFC8030], while others are proprietary (e.g., the Apple Push Notification service). Figure 1 shows the generic push notification architecture supported by the mechanism in this document. 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. +--------+ +--------------+ +-----------------+ | SIP UA | | Push Service | | SIP Proxy | +--------+ +--------------+ +-----------------+ | | | | Subscribe | | |--------------------->| | | | | | Push Resource ID | | |<---------------------| | | | | | SIP REGISTER (Push Resource ID) | Holmberg & Arnold Expires October 13, 2018 [Page 4] Internet-Draft SIP PUSH April 2018 |===============================================>| | SIP 200 OK | | |<===============================================| | | | | | | | | | | | | SIP INVITE | | Push Message |<============ | | (Push Resource ID) | | Push Message |<------------------------| | (Push Resource ID) | | |<---------------------| | | | | | SIP REGISTER (Push Resource ID) | |===============================================>| | SIP 200 OK | | |<===============================================| | | | | SIP INVITE | | |<===============================================| | | | ------- Push Notification API ======= SIP REGISTER sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 Figure 1: SIP Push Notification Architecture Holmberg & Arnold Expires October 13, 2018 [Page 5] Internet-Draft SIP PUSH April 2018 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 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 may vary 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 pre-configured in the operating system of the device. 4. SIP User Agent (UA) Behavior 4.1. Request Push Notifications from Network Once the SIP UA has registered with the PNS, has received the PRID (using the protocol and procedures associated with the PNS), if the UA wants to receive push notifications (requested by the proxy), the UA MUST include 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 identifies the type of PNS, the pn-prid URI parameter contains the PRID value and the pn-param URI parameter contains additional PNS-specific information. When the UA receives a 2xx response to the REGISTER request, if the response contains a Feature-Caps header field with a 'sip.pns' feature-capability indicator with a parameter value identifying the same type of PNS that was identified by the pn-provider URI parameter in the REGISTER request, the UA can assume that a SIP proxy will request push notifications towards the UA. In other cases, the UA MUST NOT assume that push notifications will be requested, and the actions taken by the UA might be dependent on implementation or deployment architecture, and are outside the scope of this document. In addition, if the response contains a Feature-Caps header field with a 'sip.vapid' feature-capability indicator, the proxy supports use of the Voluntary Application Server Identification (VAPID) mechanism [RFC8292] to restrict push notifications to the proxy. Holmberg & Arnold Expires October 13, 2018 [Page 6] Internet-Draft SIP PUSH April 2018 When the UA receives a push notification, it MUST send a re- registration REGISTER request, using normal SIP procedures. If there are Network Address Translators (NATs) between the UA and the proxy, the REGISTER request will create NAT bindings that will allow incoming SIP requests to reach the UA. 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 stand-alone SIP request (e.g., a SIP MESSAGE), if such SIP request triggered the push notification request. Note that, depending on which transport protocol is used, the SIP request might reach the UA before the REGISTER response. If the UA is able to send re-registration REGISTER requests using a non-push mechanism (e.g., using an internal timer that periodically awakes the UA), the UA MUST insert a 'sip.pnsreg' media feature tag [RFC3840] in the Contact header field URI of each REGISTER request. Then, if the response to the REGISTER request contains a 'sip.pnsreg' feature-capability indicator with an indicator value, the UA MUST send REGISTER requests prior to the registration expires. The indicator value indicates a minimum time (given in seconds), prior to the registration expires when the UA MUST send the REGISTER request. Even if the UA is able to to send REGISTER requests using a non-push mechanism, the UA MUST still send a REGISTER request when it receives a push notification, following the procedures in this section. If the REGISTER response does not contain a a 'sip.pnsreg' feature- capability indicator, the UA SHOULD only send a re-registration REGISTER request when it receives a push notification (even if the UA is able to use a non-push mechanism for sending re-registration REGISTER requests). NOTE: In some cases the UA might be able to use a non-push mechanism to awake and send re-registration REGISTER requests. Such REGISTER request will update the registration expiration timer, and the proxy does not need to request a push notification towards the UA in order to awake the UA. The proxy will still request a push notification towards the UA when the proxy receives a SIP request addressed towards the UA (Section 5.3.2). This allows the UA to e.g., use timers for sending re-registration REGISTER requests, but to be suspended (in order to save battery resources etc) between sending the REGISTER requests and use push notification to awaken the UA to process incoming calls. NOTE: This specification does not define any usage of a push notification payload. As defined in Section 5.3.2, a proxy must not include any payload in the push notification request. If a SIP UA receives a push notification that contains a payload the UA can discard the payload, but the UA will still send a re-registration REGISTER request. Holmberg & Arnold Expires October 13, 2018 [Page 7] Internet-Draft SIP PUSH April 2018 NOTE: If the SIP UA application wants to use push notifications for other purposes than to trigger re-registration requests, it needs to be able to distinguish between the different purposes when receiving push notifications. Mechanisms for doing that are outside the scope of this specification. As long as the UA wants to receive push notifications (requested by the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param (if required for the specific PNS provider) SIP URI parameter in each re-registration REGISTER request. Note that, in some cases, the PNS might update the PRID value, in which case the UA will include the new value in the pn-prid SIP URI parameter in the re-registration REGISTER request. If the UA no longer wants to receive push notifications (requested by the proxy), the UA MUST send a re-registration REGISTER request without including the SIP URI parameters described above, or the UA MUST remove the registration. If a UA's subscription to a PNS (and the associated PRID) is only valid for a limited time then the UA is responsible for retrieving new subscription details from the PNS and sending a REGISTER request with the updated pn parameters to the proxy prior to the expiry of the existing subscription. If a UA's subscription to a PNS expires then the UA MUST send a REGISTER without the pn parameters (to tell the proxy that it no longer wants push notifications) or terminate the registration. The exact mechanisms for expiry and renewal of PRIDs will be PNS-specific and are outside the scope of this document. For privacy and security reasons, the UA MUST NOT include the SIP URI parameters defined in this document in non-REGISTER request, to prevent the PNS information associated with the UA from reaching the remote peer. For example, the UA MUST NOT include the SIP URI parameters in the Contact header field of an INVITE request. 4.2. Query Network Push Notification Capabilities A SIP UA might need to query the network for push notification capabilities (e.g., related to VAPID) before it registers with the PNS, and before it indicates that it wants to receive push notifications. The UA can do so by only including the pn-provider SIP URI parameter in the SIP Contact header field URI of the REGISTER request, but without including the pn-prid SIP URI parameter. Later, once the UA has received a response to the REGISTER request, with the push notification information from the network, if the UA wants to receive push notifications, the UA will send a re-registration Holmberg & Arnold Expires October 13, 2018 [Page 8] Internet-Draft SIP PUSH April 2018 REGISTER request, including all pn- SIP URI parameters required by the specific PNS, following the procedures in Section 4.1. 5. SIP Proxy Behavior 5.1. PNS Identifier The type of PNS is identified by the pn-provider SIP URI parameter. 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. Trigger Periodic Re-registration In order to request push notifications towards a SIP UA that will trigger the UA to send re-registration SIP REGISTER requests, the SIP proxy MUST have information about when a registration will expire. The proxy either needs to be the SIP registrar, or the proxy needs to retrieve the information from the registrar using some mechanism. Such mechanisms are outside the scope of this document. When the proxy receives an indication that the UA needs to send a re- registration REGISTER request, the proxy requests a push notification towards the UA. Note that the push notification needs to be requested early enough, in order for the associated re-registration REGISTER request to reach the SIP registrar before the registration expires. It is RECOMMENDED that the proxy requests the push notification at least 120 seconds before the registration expires. If the UA has indicated, using the 'sip.pnsreg' media feature tag, that it is able to awake using a non-push mechanism for sending re- registration REGISTER requests, if the proxy does not receive a REGISTER request prior to 120 seconds before the registration expires, the proxy MAY request a push notification towards the UA, to trigger the UA to send a REGISTER request. NOTE: As described in Section 4.2, a SIP 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 push notifications towards a UA that has not provided a pn-prid SIP URI parameter. If the proxy receives information that a registration has expired, the proxy MUST NOT request further push notifications towards the UA. Holmberg & Arnold Expires October 13, 2018 [Page 9] Internet-Draft SIP PUSH April 2018 5.3. SIP Request 5.3.1. REGISTER The procedures in this section apply when the SIP proxy receives a SIP REGISTER request (initial REGISTER request for a registration, or a re-registration REGISTER request) that contains a pn-provider SIP URI parameter identifying a type of PNS. If the proxy receives a REGISTER request that does not contain a pn-provider SIP URI parameter, or that removes the registration, the proxy MUST NOT request push notifications towards the UA associated with the REGISTER request, or perform any other procedures in this section. As described in Section 4.2, a SIP UA might send a REGISTER request without including a pn-prid SIP URI parameter in the Contact header field URI, in order to retrieve push notification capabilities from the network before the UA the proxy will request push notifications towards the UA. The procedures in this section apply to both the case when the REGISTER request contains a pn-prid SIP URI parameter, and when it does not. When the proxy receives a REGISTER request, if the REGISTER request contains a Feature-Caps header field with a 'sip.pns' feature- capability indicator, it indicates that an upstream proxy supports, and will request (if the Contact header field URI of the REGISTER request contains a pn-prid SIP URI parameter), push notifications towards the UA. The proxy MUST skip the rest of the procedures in this section, and process the REGISTER request using normal SIP procedures. If the proxy considers the requested registration expiration interval [RFC3261] to be too short, the proxy MUST either send a 423 (Interval Too Brief) response to the REGISTER request, or skip the rest of the procedures in this section and process the REGISTER request using normal SIP procedures. If the proxy sends a 423 (Interval Too Brief) response, the proxy SHOULD insert a Feature-Caps header field with a 'sip.pns' feature-capability indicator in the response, identifying each type of PNS that the proxy supports. Similarly, when the proxy receives a 2xx response to the REGISTER request (see below), if the proxy considers the registration expiration interval indicated by the registrar too short, the proxy MUST NOT insert a Feature-Caps header field with a 'sip.pns' feature-capability indicator in the response, and the proxy MUST NOT request push notifications associated with the registration. A registration expiration interval MUST be considered too short if the interval is smaller than the time prior to expiration that the proxy would request a push notification. The proxy MAY consider the interval too small based on its own policy so as to reduce load on the system. Holmberg & Arnold Expires October 13, 2018 [Page 10] Internet-Draft SIP PUSH April 2018 Otherwise, if the pn-provider SIP URI parameter identifies a type of PNS that the proxy does not support, or if the REGISTER request does not contain all additional information required for the specific type of PNS, the proxy MUST either forward the request (e.g., if the proxy knows that a downstream proxy supports the type of PNS) or send a SIP 555 (Push Notification Service Not Supported) response to the REGISTER request. If the proxy sends a SIP 555 (Push Notification Service Not Supported) response, the proxy SHOULD insert a Feature- Caps header field with a 'sip.pns' feature-capability indicator in the response, identifying the type of each PNS that the proxy supports. The decision whether to forward the request, or to send a response, is done based on local policy. If the proxy supports the type of PNS identified by the pn-provider SIP URI parameter, the proxy MUST insert a Feature-Caps header field with a 'sip.pns' feature-capability indicator, identifying the type of PNS, in the REGISTER request before forwarding the REGISTER request (unless the proxy is the registrar, in which case the proxy will terminate the REGISTER request). This will inform downstream proxies that the proxy supports, and will request (if the Contact header field URI of the REGISTER request contains a pn-prid SIP URI parameter), push notifications towards the UA. If the proxy inserted a Feature-Caps header field with a 'sip.pns' feature-capability indicator in the REGISTER request (see above), if the proxy receives (or, in case the proxy is the SIP registrar, creates) a 2xx response to the REGISTER request, the proxy MUST insert a Feature-Caps header field with a 'sip.pns' feature- capability indicator in the response, identifying the type of PNS. This will inform the UA that the proxy supports, and will request (if the Contact header field URI of the REGISTER request contained a pn- prid SIP URI parameter), push notifications towards the UA. The proxy MUST only indicate support of the same PNS that was identified in the pn-provider SIP URI parameter in the REGISTER request. If the proxy receives a receives a SIP 555 (Push Notification Service Not Supported) response, the proxy SHOULD insert a Feature-Caps header field with a 'sip.pns' feature-capability indicator in the response, identifying the type of each PNS that the proxy supports. In addition, if the proxy receives a 2xx response to the REGISTER request: o if the proxy supports, and will use, the VAPID mechanism, the proxy MUST insert a Feature-Caps header field with a 'sip.vapid' feature-capability indicator in the response. The header field parameter contains the public key identifying the proxy [RFC8292]. The proxy MUST be able to determine whether the PNS supports the Holmberg & Arnold Expires October 13, 2018 [Page 11] Internet-Draft SIP PUSH April 2018 VAPID mechanism before it inserts the feature-capability indicator. o if the proxy received a 'sip.pnsreg' media feature tag in the REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature- capability indicator with an indicator value bigger than 120 in the response, unless the proxy always want to request push notifications to trigger the UA to send a REGISTER request. 5.3.2. Initial Request for Dialog or Stand-Alone Request The procedures in this section apply when the SIP proxy has indicated that it supports, and will request, push notifications towards the SIP UA. When the proxy receives (or, in case the proxy is the registrar, creates) a SIP request for a new dialog (e.g., a SIP INVITE request) or a stand-alone 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 a push notification towards the UA, using the PRID included in the pn-prid SIP URI parameter and the PNS identified by the pn-provider SIP URI parameter. The push notification will trigger the UA to send a re-registration REGISTER request. The proxy will process the REGISTER request and the associated response as described in Section 5.3.1. In case of a 2xx response to the REGISTER request, once the proxy has forwarded the REGISTER response towards the UA, if the contact in the REGISTER response matches the Request-URI of the SIP request to be forwarded, the proxy can also forward the SIP request towards the UA, using normal SIP procedures. If the contact of the most recent REGISTER 2xx response and Request-URI do not match, the proxy MUST reject the SIP request with a 404 (Not Found) response. This can happen if the UA sends a re-registration REGISTER request with a new contact at the same time the registrar forwards a SIP request towards a UA using the previously registered contact in the Request-URI. As both the SIP request to be forwarded towards the UA, and the re- registration REGISTER request triggered by the push notification request, will convey pn- SIP URI parameters associated with the SIP registration, those can be used to match the SIP request with the re- registration REGISTER request (even if the most recent contact and the Request-URI of the SIP request do not match). NOTE: If the proxy is not the registrar, it needs to store (or be able to retrieve) the contact of the most recent REGISTER 2xx Holmberg & Arnold Expires October 13, 2018 [Page 12] Internet-Draft SIP PUSH April 2018 response, to be able to compare it with the Request-URI of the request to be forwarded towards the UA. In case of non-2xx response to the REGISTER request, the proxy MUST reject the SIP request with a 404 (Not Found) response. If the push notification request fails (see PNS-specific documentation for details), the proxy MUST reject the SIP request with a 556 (Push Notification Failed) response. NOTE: As described above, the reason the proxy needs to wait for the REGISTER response before forwarding the SIP request is to make sure that the REGISTER request has been accepted by the SIP registrar, and that the registered contact matches the Request-URI of the SIP request to be forwarded. If the proxy does not receive the REGISTER request from the UA within a given time after the proxy has requested the push notification, the proxy MUST reject the request with a 404 (Not Found) response. The time value is set based on local policy. The proxy MUST NOT include the SIP request as payload in the requested push message. 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 REGISTER request, the proxy MAY choose to not request a push notification towards the UA (and wait for the associated REGISTER request and 2xx response) before it tries to forward 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. Similarly, if the Request-URI of the SIP request only contains any pn-provider SIP URI parameter, but no other pn- SIP URI parameters, e.g., because the SIP UA has not included them in a REGISTER request (Section 4.2), the proxy is not able to request a push notification towards the UA. If the proxy has knowledge that the UA is awake, and that the UA is able to receive the SIP request, the proxy MAY forwards the request towards the UA. Otherwise the proxy MUST reject the SIP request with a 556 (Push Notification Failed) response. 6. Grammar 6.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 Holmberg & Arnold Expires October 13, 2018 [Page 13] Internet-Draft SIP PUSH April 2018 indicate that the server did not support the push notification service identified in a 'pn-provider' SIP URI parameter. The use of the SIP 555 response code is defined for SIP REGISTER responses. 6.2. 556 (Push Notification Failed) Response Code The 556 response code is added to the "Server-Error" Status-Code definition. 556 (Push Notification Failed) is used to indicate that the server failed to request a push notification from the push notification service identified in a 'pn-provider' SIP URI parameter. The use of the SIP 556 response code is defined for responses to SIP requests initiating dialogs, and responses to stand-alone SIP requests. 6.3. sip.pns Feature-Capability Indicator The sip.pns feature-capability indicator, when included 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, and will use, the SIP push mechanism and the push notification service identified by the indicator value. When included in a 555 (Push Notification Service Not Supported) response to a REGISTER request, the the indicator indicates that the entity associated with the indicator supports the SIP push mechanism, and the push notification service(s) identified 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-list RDQUOT pns-list = pns *(COMMA pns) pns = tag-value ; tag-value as defined in RFC 3840 6.4. sip.vapid Feature-Capability Indicator The sip.vapid feature-capability indicator, when included in a SIP 2xx response to a SIP REGISTER request, indicates that the entity associated with the indicator supports, and will use, the Voluntary Application Server Identification (VAPID) [RFC8292] mechanism when requesting push notifications towards the SIP UA associated with the SIP registration. The indicator value is a public key identifying Holmberg & Arnold Expires October 13, 2018 [Page 14] Internet-Draft SIP PUSH April 2018 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 as defined in RFC 3840 6.5. sip.pnsreg Feature-Capability Indicator The sip.pnsreg feature-capability indicator, when included in a SIP 2xx response to a SIP REGISTER request, indicates that the entity associated with the indicator expects to receive re-registration REGISTER requests from the SIP UA associated with the registration before the registration expires, without the entity having to request push notifications towards the SIP UA in order to trigger the REGISTER requests. The indicator value is the minimum value (given in seconds) before the registration expiration when the entity expects to receive the REGISTER request. pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT reg = 1*DIGIT ; DIGIT as defined in RFC 3261 6.6. sip.pnsreg Media Feature Tag The sip.pnsreg media feature tag, when included in the SIP Contact header field of a SIP REGISTER request, indicates that the SIP UA associated with the tag is able to send re-registration REGISTER requests associated with the registration without being awaken by push notifications. The media feature tag has no values. pnsreg-mt = "+sip.pnsreg" Holmberg & Arnold Expires October 13, 2018 [Page 15] Internet-Draft SIP PUSH April 2018 6.7. SIP URI Parameters The section defines new SIP URI parameters, by extending the grammar for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: uri-parameter =/ pn-provider / pn-param / pn-prid pn-provider = "pn-provider" EQUAL pvalue pn-param = "pn-param" EQUAL pvalue pn-prid = "pn-prid" EQUAL pvalue ; pvalue as defined in RFC 3261 ; EQUAL as defined in RFC 3261 ; COLON as defined in RFC 3261 The format and semantics of pn-prid and pn-param are specific to the pn-provider value. Parameter value chapters that are not part of pvalue needs to be escaped, as defined in RFC 3261. 7. PNS Registration Requirements When a new value is registered to the PNS Sub-registry, a reference to a specification which describes 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. 8. 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. The value of the pn-provider URI parameter is "apns". Example: pn-provider = apns The value of the pn-param URI parameter is the APNs App ID, which is encoded by two values, separated by a period (.): Team ID and Bundle Holmberg & Arnold Expires October 13, 2018 [Page 16] Internet-Draft SIP PUSH April 2018 ID. The Team ID is provided by Apple and is unique to a development team. The Bundle ID is unique to a development team, and is a string that will match a single application or a group of applications. Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp 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 For more information on the APNs App ID: https://developer.apple.com/library/content/documentation/General/ Conceptual/DevPedia-CocoaCore/AppID.html For more information on the APNs device token: https://developer.apple.com/library/content/documentation/NetworkingI nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re f/doc/uid/TP40008194-CH8-SW13 9. 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. 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. For more information on the Project ID and Registration token: https://firebase.google.com/docs/cloud-messaging/concept-options 10. 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". Holmberg & Arnold Expires October 13, 2018 [Page 17] Internet-Draft SIP PUSH April 2018 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 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. 11. Security Considerations Different mechanisms exist for authenticating and authorizing devices and users registering with a PNS. The mechanisms for authorizing and authenticating the users are PNS-specific, and are outside the scope of this document. 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. Typically, the PNS also requires the SIP proxy requesting push notifications to be authenticated and authorized by the PNS. In some cases the PNS also require the SIP application (or the SIP application developer) to be identified in order for the application to request push notifications. If the push notification related information carried in SIP could be used by a malicious middleman to trigger push notifications towards a device, operators MUST ensure that the SIP signalling is properly secured from malicious middlemen, e.g., using encryption. [RFC8292] defines a mechanism which allows a proxy to create a identity itself to a PNS, by signing a 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. The mechanism in this document does not require a proxy to include any payload (in addition to possible payload used for the PNS itself) when requesting push notifications. 12. IANA considerations Holmberg & Arnold Expires October 13, 2018 [Page 18] Internet-Draft SIP PUSH April 2018 12.1. SIP URI Parameters This section defines new SIP URI Parameters that extend the "SIP/SIPS URI Parameters" sub-registry [RFC3969] under the sip-parameters registry: http://www.iana.org/assignments/sip-parameters. 12.1.1. pn-provider Parameter Name: pn-provider Predefined Values: No Reference: RFC XXXX 12.1.2. pn-param Parameter Name: pn-param Predefined Values: No Reference: RFC XXXX 12.1.3. pn-prid Parameter Name: pn-prid Predefined Values: No Reference: RFC XXXX 12.2. SIP Response Codes 12.2.1. 555 (Push Notification Service Not Supported) This section defines a new SIP response code that extends the "Response Codes" sub-registry [RFC3261] under the sip-parameters registry: http://www.iana.org/assignments/sip-parameters. Holmberg & Arnold Expires October 13, 2018 [Page 19] Internet-Draft SIP PUSH April 2018 Response Code Number: 555 Default Reason Phrase: Push Notification Service Not Supported 12.2.2. 556 (Push Notification Failed) This section defines a new SIP response code that extends the "Response Codes" sub-registry [RFC3261] under the sip-parameters registry: http://www.iana.org/assignments/sip-parameters. Response Code Number: 556 Default Reason Phrase: Push Notififcation Failed 12.3. SIP Global Feature-Capability Indicator 12.3.1. sip.pns This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" sub-registry [RFC6809] under the sip-parameters registry: http://www.iana.org/assignments/sip-parameters. Name: sip.pns Description: This feature-capability indicator, when included 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, and will use, the SIP push mechanism and the push notification service identified by the indicator value. When included in a 555 (Push Notification Service Not Supported) response to a REGISTER request, the the indicator indicates that the entity associated with the indicator supports the SIP push mechanism, and the push notification service(s) identified by the indicator value. Reference: [RFCXXXX] Contact: IESG (iesg@ietf.org) Holmberg & Arnold Expires October 13, 2018 [Page 20] Internet-Draft SIP PUSH April 2018 12.3.2. sip.vapid This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" sub-registry [RFC6809] under the sip-parameters registry: http://www.iana.org/assignments/sip-parameters. Name: sip.vapid Description: This feature-capability indicator, when included in a SIP 2xx response to a SIP REGISTER request, indicates that the entity associated with the indicator supports, and will use, the Voluntary Application Server Identification (VAPID) mechanism when requesting push notifications towards the SIP UA associated with the SIP registration. The indicator value is a public key identifying the entity, that can be used by a SIP UA to restrict subscriptions to that entity. Reference: [RFCXXXX] Contact: IESG (iesg@ietf.org) 12.3.3. sip.pnsreg This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" sub-registry [RFC6809] under the sip-parameters registry: http://www.iana.org/assignments/sip-parameters. Holmberg & Arnold Expires October 13, 2018 [Page 21] Internet-Draft SIP PUSH April 2018 Name: sip.pnsreg Description: This feature-capability indicator, when included in a SIP 2xx response to a SIP REGISTER request, indicates that the entity associated with the indicator expects to receive re-registration REGISTER requests from the SIP UA associated with the registration before the registration expires, without the entity having to request push notifications towards the SIP UA in order to trigger the REGISTER requests. The indicator value is the minimum value (given in seconds) before the registration expireation when the entity expects to receive the REGISTER request. Reference: [RFCXXXX] Contact: IESG (iesg@ietf.org) 12.4. SIP Media Feature Tag 12.4.1. sip.pnsreg This section defines a new media feature tag that extends the "SIP Media Feature Tag Registration Tree" sub-registry [RFC3840] under the Media Feature Tag registry: https://www.iana.org/assignments/media- feature-tags/media-feature-tags.xhtml. Holmberg & Arnold Expires October 13, 2018 [Page 22] Internet-Draft SIP PUSH April 2018 Media feature tag name: sip.pnsreg Summary of the media feature indicated by this feature tag: This media feature tag, when included in the SIP Contact header field of a SIP REGISTER request, indicates that the SIP UA associated with the tag is able to send re-registration REGISTER requests associated with the registration without being awaken by push notifications. Values appropriate for use with this feature tag: none Related standards or documents: [RFCXXXX] 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 towards the client will be requested. Contact: IESG (iesg@ietf.org) 12.5. PNS Sub-registry Establishment This section creates a new sub-registry, "PNS", under the sip- parameters registry: http://www.iana.org/assignments/sip-parameters. The purpose of the sub-registry is to register SIP URI pn-provider values. When a SIP URI pn-provider value is registered in the sub-registry, it needs to meet the "Expert Review" policies defined in [RFC8126]. This sub-registry 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 Holmberg & Arnold Expires October 13, 2018 [Page 23] Internet-Draft SIP PUSH April 2018 This specification registers the following values: Value Description Document ------- -------------------------------------- ---------- apns Apple Push Notification service [RFC XXXX] fcm Firebase Cloud Messaging [RFC XXXX] webpush Generic Event Delivery Using HTTP Push [RFC XXXX] 13. Acknowledgements Thanks to Mickey Arnold, Paul Kyzivat, Dale Worley, Ranjit Avasarala, Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula, Liviu Chircu, Roman Shpount and Yehoshua Gev for reading the text, and providing useful feedback. 14. References 14.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, . [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, . [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, . [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, . Holmberg & Arnold Expires October 13, 2018 [Page 24] Internet-Draft SIP PUSH April 2018 [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, . [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, . [RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server Identification (VAPID) for Web Push", RFC 8292, DOI 10.17487/RFC8292, November 2017, . 14.2. Informative References [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, . [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, . [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, DOI 10.17487/RFC8291, November 2017, . Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg & Arnold Expires October 13, 2018 [Page 25] Internet-Draft SIP PUSH April 2018 Michael Arnold Metaswitch Networks 100 Church Street Enfield EN2 6BQ United Kingdom Email: Michael.Arnold@metaswitch.com Holmberg & Arnold Expires October 13, 2018 [Page 26]