SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                        January 12, 2018                               M. Arnold
Expires: July 16, August 17, 2018                             Metaswitch Networks
                                                       February 13, 2018

      Push Notification with the Session Initiation Protocol (SIP)
                     draft-ietf-sipcore-sip-push-04
                     draft-ietf-sipcore-sip-push-05

Abstract

   This document describes how push notification mechanisms a Push Notification Services (PNS) can be
   used to wake up awake suspended Session Initiation Protocol (SIP) User Agents
   (UAs), in order for the UA to be able to receive and generate send SIP requests.  The
   document defines new SIP URI parameters, parameters and new feature-capability
   indicators that can be used in a SIP
   REGISTER request messages to provide push notification indicate support of
   the mechanism defined in this document, to exchange PNS information from
   between the SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in
   this document) that will send a push request to the
   push server in
   order notifications towards the UA, and to trigger a such push
   notification towards the SIP UA. 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 July 16, August 17, 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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   3.  Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . .   5
   4.  SIP User Agent (UA) Behavior  . . . . . . . . . . . . . . . .   5   6
   5.  SIP Proxy Behavior  . . . . . . . . . . . . . . . . . . . . .   6   7
     5.1.  PNS Provider Information Identifier  . . . . . . . . . . . . . . . .   6 . . . . .   7
     5.2.  Trigger Periodic Re-registration  . . . . . . . . . . . .   6   7
     5.3.  SIP Request . . . . . . . . . . . . . . . . . . . . . . .   7   8
       5.3.1.  REGISTER Request  . . . . . . . . . . . . . . . . . .   8
       5.3.2.  Initial Request for Dialog or Stand-Alone Request . .   9
   6.  Network Address Translator (NAT) Considerations . . . . . . .   8  10
   7.  Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . .   8  10
     7.1.  555 (Push Notification Service Not Supported) Response
           Code  . . . . . . . . . . . . . . . . . . . . . . . . . .   8  10
     7.2.  sip.pns Feature-Capability Indicator  . . . . . . . . . .   8  10
     7.3.  sip.vapid Feature-Capability Indicator  . . . . . . . . .  11
     7.4.  SIP URI Parameters  . . . . . . . . . . . . . . . . . . .   9  11
   8.  PNS Registration Requirements . . . . . . . . . . . . . . . .   9  12
   9.  pn-provider, pn-param and pn-prid URI Parameters for Apple
       Push Notification service . . . . . . . . . . . . . . . . . .   9  12
   10. pn-provider, pn-param and pn-prid URI Parameters for Google
       Firebase Cloud Messaging (FCM) push notification service  . .  10  13
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  10  13
   12. IANA considerations . . . . . . . . . . . . . . . . . . . . .  11  14
     12.1.  SIP URI Parameters . . . . . . . . . . . . . . . . . . .  11  14
       12.1.1.  pn-provider  . . . . . . . . . . . . . . . . . . . .  11  14
       12.1.2.  pn-param . . . . . . . . . . . . . . . . . . . . . .  11  14
       12.1.3.  pn-prid  . . . . . . . . . . . . . . . . . . . . . .  11
       12.1.4.  pn-enckey  14
     12.2.  SIP Response Code  . . . . . . . . . . . . . . . . . . .  14
     12.3.  SIP Global Feature-Capability Indicator  . . .  12
       12.1.5.  pn-enccode . . . . .  15
       12.3.1.  sip.pns  . . . . . . . . . . . . . . . .  12
     12.2.  SIP Response Code . . . . . .  15
       12.3.2.  sip.vapid  . . . . . . . . . . . . .  12
     12.3.  SIP Global Feature-Capability Indicator . . . . . . . .  12  15
     12.4.  PNS Sub-registry Establishment . . . . . . . . . . . . .  13  16
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14  17
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14  17
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  14  17
     14.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Author's Address  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . .  15  18

1.  Introduction

   In order to save resources (e.g, (e.g., battery life) some devices
   (especially mobile devices) and operating systems require suspended Session Initiation Protocol (SIP)
   User Agents (UAs) [RFC3261] to will suspend
   applications when not used.  In some cases, internal timers cannot be woken up
   used to awake such application, nor will incoming network traffic
   awake the application.  Instead, the only way to awake the
   application is by using a push notification
   service. Push Notification Service (PNS).  Typically
   each operating system uses a dedicated push
   notification service. PNS.  For example, Apple iOS
   devices use the Apple Push Notification service (APNs).

   Due to (APNs) while Android
   devices use the Firebase Cloud Messaging (FCM) service.

   Because of the restriction restrictions above, applications Session Initiation Protocol (SIP)
   User Agents (UAs) [RFC3261] can not be woken up by
   non-push notification traffic.  This means that a suspended 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 receive an incoming SIP request (e.g., a maintain connections e.g.,
   using the SIP
   INVITE request), or Outbound Mechanism [RFC5626], as it requires the UA to
   send periodic re-registration requests. keep-alive messages.

   This document describes how push notification mechanisms PNSs can be used to wake up awake suspended SIP UAs, in order
   to be able to receive send re-registration REGISTER requests and
   generate to receive
   incoming SIP requests.  The document defines new SIP URI parameters, parameters
   and new feature-capability indicators [RFC6809] that can be used in a
   SIP REGISTER request messages to provide push
   notification indicate support of the mechanism defined in this
   document, to exchange PNS information from between the SIP UA to the SIP entity
   (realized as a SIP proxy in this document) that will send a push request to push
   notifications towards the UA, and to trigger such push server notification
   requests.

   NOTE: Even if a UA is able to awake (e.g., using internal timers) in
   order to trigger send periodic re-registration REGISTER requests, it might
   still be useful to suspend the application between the sending of re-
   registration requests (as it will save battery life etc) and use a push notification towards
   PNS to awake the UA when a SIP
   UA. request addressed towards the UA
   arrives.

   When a SIP UA registers to a Push Notification Service (PNS), PNS, it will receive a unique Push Resource
   ID (PRID) associated to that with the push notification registration.  The SIP UA
   will provide the PRID to the SIP network proxy that will request push
   notifications towards the UA in a SIP REGISTER request.  A SIP proxy (e.g., the SIP registrar) will
   store a mapping between the registered contact and the PRID.

   When the SIP proxy receives (or, in case if the SIP proxy is also
   registrar, the SIP registrar
   [RFC3261], initiates) a SIP request for a new dialog, or a stand-
   alone SIP request, addressed towards a SIP UA, or when the SIP proxy
   determines that the SIP UA needs to perform send a re-registration, re-registration REGISTER
   request, the
   SIP proxy will send a push request to the a push notification service
   used by towards the SIP UA,
   using the push resource ID associated with the
   registered contact PNS of the SIP UA, in order to trigger a push
   notification towards the SIP UA.  Once the SIP UA receives the push notification,
   it will be able to send a re-registration REGISTER request and
   receive the incoming SIP request, request.  The proxy will receive and to generate
   a SIP forward
   (or, if the proxy is the registrar, process) the REGISTER request.
   If the push notification request (e.g., was triggered by a SIP REGISTER) itself.  The proxy can use request
   addressed towards the
   receipt of UA (see above), once the REGISTER request as a trigger to 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, UA using normal SIP routing procedures.

   Different push notification mechanisms PNSs exist today.  Some are based on there 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)       |
         |===============================================>|
         |          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 <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">
       pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>
     Expires: 7200
     Content-Length: 0

               Figure 1: SIP Push Notification Architecture

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 an entity a SIP UA registers with a PNS it receives a unique Push Resource
   ID (PRID), which is a value associated with the registration.

   The format of the PRID may vary depending on the PNS provider. PNS.

   The details regarding discovery of the PNS, and the procedures for
   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 (OS)
   of the device.

4.  SIP User Agent (UA) Behavior

   Once the SIP UA has registered with the PNS and PNS, has received the PRID
   (using the protocol and procedures associated with the PNS), and when
   the UA wants to receive push notifications triggered by the SIP
   proxy, notifications, the UA MUST send a SIP
   REGISTER request using normal SIP registration procedures.  The UA MUST add include a
   pn-provider, a pn-prid and a pn-param (if required for the specific PNS provider)
   PNS) SIP URI parameter to in the SIP Contact header field URI of the
   REGISTER request.  The pn-provider URI parameter contains identifies the PNS provider, PNS,
   the pn-prid URI parameter contains the PRID value and the pn-param
   URI parameter contains additional PNS-specific information.

   When the SIP UA receives a 200 (OK) 2xx response to the SIP REGISTER request, if the
   response does not contain a Feature-Caps header field
   with a '+sip.pns' header field parameter, or if the response contains a Feature-Caps header field with a '+sip.pns' header field parameter 'sip.pns'
   feature-capability indicator with a parameter value identifying the
   same PNS that was identified by the pn-provider URI parameter in the
   REGISTER request, the UA does not support, can assume that a SIP proxy will request
   push notifications towards the UA.  In other cases, the UA cannot MUST NOT
   assume that push notifications will be triggered by a SIP proxy.  The requested, and the actions
   taken by the UA might be dependent on implementation or deployment
   architecture, and are outside the scope of this document.

   When

   In addition, if the SIP UA receives a push notification, it MUST perform response contains a SIP
   re-registration [RFC3261] by sending Feature-Caps header field
   with a SIP 'sip.vapid' feature-capability indicator, the UA can use the
   Voluntary Application Server Identification VAPID) mechanism
   [RFC8292] to restrict push notifications to the proxy (assuming that
   the PNS supports VAPID).

   When the UA receives a push notification, it MUST send a re-
   registration REGISTER request. request, using normal SIP procedures.  If there
   are Network Address Translators (NATs) between the SIP UA and the SIP proxy,
   the REGISTER request will create NAT bindings allowing that will allow
   incoming SIP requests to reach the UA.  If  Once the UA has received a
   2xx response to the REGISTER request, the UA might receive a SIP proxy
   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 because it wants to forward a request.  Note that, depending on which transport
   protocol is used, the SIP request
   towards the UA, might reach the receipt of UA before the
   REGISTER request can be used by
   the proxy as a trigger to forward the request. response.

   As long as the SIP UA wants the SIP proxy to continue sending receive push
   requests, 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
   every each
   re-registration SIP REGISTER request sent towards the proxy. 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 within in the re-registration
   REGISTER request will contain the new value. request.

   If the SIP UA at some point no longer wants to stop the SIP proxy from sending receive push requests, notifications (requested by
   the proxy), the UA MUST send a SIP re-registration REGISTER request
   without including the SIP URI parameters described above, or the UA
   MUST remove the registration.

   If

   For privacy and security reasons, the SIP UA expects to receive payload in the push notification, MUST NOT include the UA MAY add a pn-enckey and a pn-encsec SIP Contact header field SIP URI parameter,
   parameters defined in order this document in non-REGISTER request, to allow encryption of
   prevent the data using PNS information associated with the
   mechanism in [RFC8291].  The pn-enckey URI parameter contains UA from reaching the
   public key, and
   remote peer.  For example, the UA MUST NOT include the pn-encsec SIP URI parameter contains
   parameters in the
   authentication secret [RFC8291].  The format Contact header field of such payload an INVITE request.

5.  SIP Proxy Behavior

5.1.  PNS Identifier

   The PNS is
   outside the scope of this document.

   NOTE: End-to-end encryption of the payload between the SIP proxy and
   the SIP UA cannot be used if the push notification request payload
   contains information that needs to be accessible by the PNS provider.

5.  SIP Proxy Behavior

5.1.  PNS Provider Information

   The PNS provider is retrieved from identified by the pn-provider SIP URI parameter.

   The protocol and format used for the push request depends on the PNS
   provider, notification requests are
   PNS-specific, and the details for constructing and sending the messages a push
   notification request are outside the scope of this specification.

5.2.  Trigger Periodic Re-registration

   If the

   In order to request push notifications towards a SIP UA, that will
   trigger the UA needs to perform periodic re-registrations, send re-registration SIP REGISTER requests, the SIP
   proxy
   needs to MUST have information about when those re-registrations are to be
   performed. a registration will expire.
   The proxy either needs to contain be the SIP registrar
   functionality, registrar, or the proxy needs to
   retrieve the information from the registrar using some other
   mechanism.  Such mechanisms are outside the scope of this document.

   When the SIP proxy receives an indication that the SIP UA needs to
   perform send a re-registration, re-
   registration REGISTER request, the proxy triggers requests a push request towards
   the push notification server associated with
   towards the PRID. UA.

   Note that the re-registration push notification needs to be triggered 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 10 seconds
   before the registration expires.

   NOTE: In some cases the UA might be able to use a non-push mechanism
   (e.g., a timer) 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.

5.3.  SIP Request

   When

5.3.1.  REGISTER Request

   The procedures in this section apply when the SIP proxy receives a
   SIP REGISTER request that contains a pn-provider SIP URI parameter value
   identifying a PNS.

   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, 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.

   Otherwise, if the pn-provider SIP URI parameter identifies a PNS that
   the proxy does not support, or if the REGISTER request does not
   contain all additional information required for the specific PNS provider, PNS, the
   proxy MUST either forward the request (e.g., if the proxy is aware of another proxy knows that
   a downstream proxy supports the PNS provider) PNS) or send a SIP 555 (Push
   Notification Service Not Supported) response to the REGISTER request.
   If the proxy sends a 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 each PNS that the proxy supports.

   If the proxy supports the PNS identified by the pn-provider SIP 555 (Push Notification Service Not Supported), URI
   parameter, the proxy SHOULD MUST insert a Feature-Caps header field with a '+sip.pns' header field
   parameter
   'sip.pns' feature-capability indicator in the response, indicating REGISTER request before
   forwarding the PNS supported by REGISTER request (in case the proxy is not the
   registrar, in which case the proxy will terminate the REGISTER
   request).  This will inform downstream proxies that the proxy
   supports, and will request, push notifications towards the proxy. UA.

   If the SIP proxy supports inserted a Feature-Caps header field with a 'sip.pns'
   feature-capability indicator in the pn-provider SIP URI parameter value, REGISTER request (see above),
   when the proxy receives (or, in case the proxy is the SIP registrar,
   creates) a 200 (OK) 2xx response to the REGISTER request, the proxy MUST
   insert a Feature-Caps header field with a '+sip.pns' header field
   parameter 'sip.pns' feature-
   capability indicator in the response, in order to identifying the PNS.  This will
   inform the SIP UA that the proxy supports supports, and will request, push
   notifications towards the UA.  The proxy MUST only indicate support
   of the same PNS indicated by that was identified in the pn-provider SIP URI
   parameter
   value.

   When in the REGISTER request.  In addition, 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].

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 SIP registrar,
   creates) a SIP request for a new dialog (e.g., a SIP INVITE request)
   or a non-dialog stand-alone SIP request (e.g., a SIP MESSAGE request) aimed for addressed
   towards a SIP UA, if the Request-URI of the request contains a pn-provider, pn-
   provider, a pn-prid and a pn-param (if required for the specific PNS
   provider) SIP URI parameter, the proxy triggers requests a push
   request 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 with 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 PRID.  After that Request-URI of the SIP request to be forwarded,
   the proxy can also forwards the SIP request towards the UA UA, using
   normal SIP procedures.

   As  If the push notification will trigger contact and Request-URI do not match,
   the proxy MUST reject the SIP UA to perform request with a re-
   registration, 404 (Not Found)
   response.

   In case of non-2xx response to the REGISTER request, theproxy MUST
   reject the SIP proxy can use request with a 404 (Not Found) response.

   If the receipt of push notification request fails (see PNS-specific
   documentation for details), the proxy MUST reject the SIP REGISTER request as
   with a trigger 555 (Push Notification Service Not Supported) response.

   NOTE: As described above, the reason the proxy needs to forward wait for the
   REGISTER response before forwarding the SIP request towards 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 UA.

   The SIP
   request to be forwarded.

   The proxy MUST NOT transport include the SIP request as push request
   payload, instead of forwarding payload in the request using normal SIP
   procedures.
   requested push message.

   If the SIP proxy is able to assume has knowledge that the SIP 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 trigger request a push notification
   towards the UA (and wait for the associated REGISTER request and 2xx
   response) before trying it tries to forward the SIP request towards the UA.
   The mechanisms for making getting such knowledge assumption might be
   dependent on implementation or deployment architecture, and are
   outside the scope of this document.

   If the SIP proxy is not able to contact the push notification
   provider, or to forward the SIP request to the SIP UA, the proxy MUST
   reject the SIP request.

6.  Network Address Translator (NAT) Considerations

   Whenever the SIP UA receives a push notification, if the UA is
   located behind a Network Address Translator (NAT), the UA might need
   to take actions in order to establish a binding in the NAT, in order
   for an incoming SIP request to reach the UA.  By performing sending the re-
   registration SIP REQUEST the UA will establish such NAT binding.

7.  Grammar

7.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 did not support the push notification
   service specified identified in a 'pn-provider' SIP URI parameter. parameter, or that the
   server failed to request a push notification from the push
   notification service.

   The use of the SIP 555 response code is defined for SIP REGISTER
   responses.  Usage with other
   responses, responses to SIP methods is undefined. requests initiating dialogs and responses
   to stand-alone SIP requests.

7.2.  sip.pns Feature-Capability Indicator

   The sip.pns feature-capability indicator is used in a SIP 200 (OK)
   response request, or
   in a SIP 2xx response to a REGISTER request, that the entity
   associated with the indicator supports, and will use, the push
   notification service identified by the indicator value.  The feature-
   capability indicator is used in a SIP 555 (Push Notficiation Notification Service
   Not Supported) response to a REGISTER request to indicate which push
   notification services the sender of entity associated with the response indicator
   supports.  The values defined for the pn-provider SIP URI parameter
   are used.

     pns-fc          = "+sip.pns" EQUAL LDQUOT pns-list RDQUOT
     pns-list        = pns *(COMMA pns)
     pns             = tag-value

     ; tag-value as defined in RFC 3840

7.3.  sip.vapid Feature-Capability Indicator

   The value of the pns sip.vapid feature-capability indicator is identical used in a SIP 2xx
   response to the corresponding pn-provider a SIP URI parameter for REGISTER request to indicate that the entity
   associated with the indicator supports, and will use, the Voluntary
   Application Server Identification (VAPID) [RFC8292] mechanism when
   requesting push notification service notifications towards the SIP UA associated with the value.

7.3.
   SIP registration.  The indicator value contains 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 as defined in RFC 3840

7.4.  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-enccode /
                        pn-enckey
     pn-provider     = "pn-provider" EQUAL pvalue
     pn-param        = "pn-param" EQUAL pvalue
     pn-prid         = "pn-prid" EQUAL pvalue
     pn-enccode      = "pn-enccode" EQUAL pvalue
     pn-enckey       = "pn-enckey" 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 pns-param is pn-prid and pn-param are
     specific to a given
     pns-provider the pn-provider value.

     Parameter value chapters that are not part of pvalue needs to be
     escaped, as defined in RFC 3261.

8.  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.
   o  Whether there are any restrictions regarding usage of payload
      encryption [RFC8291] with the associated PNS.

9.  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
   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 can 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

10.  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 Sender 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 Sender ID and Registration token:

   https://firebase.google.com/docs/cloud-messaging/concept-options

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 device and its PNS
   in order proxy to establish create a push notification subscription, the mechanism
   in this document does not require entities
   identity itself to provide any additional
   information a PNS, by signing a JWT sent to the PNS.

   Push notification mechanisms provide different methods PNS using a
   key pair.  The public key serves as an identifier of the proxy, and
   can be used by devices to ensure that
   malicious user cannot trigger restrict push notifications to a device.  Users
   of the proxy
   associated with the key.

   The mechanism in this document MUST take measures to prevent push
   notifications from being sent to a device from does not require a malicious user.

   In case entities do want proxy to include
   any payload in the push
   notifications, this document defines the means for using end-to-end (in addition to possible payload encryption between the entity sending the push request and
   the entity receiving used for the associated PNS itself)
   when requesting push notification. notifications.

12.  IANA considerations

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.1.4.  pn-enckey

     Parameter Name: pn-enckey

     Predefined Values:  No

     Reference:  RFC XXXX

12.1.5.  pn-enccode

     Parameter Name: pn-enccode

     Predefined Values:  No

     Reference:  RFC XXXX

12.2.  SIP Response Code

   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:   555

      Default Reason Phrase:  Push Notification Service Not Supported

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 REGISTER response, indicates
        that the server supports the SIP push mechanism. The value is a list
        of
        indicates the push notification services service supported by the server.

     Reference: [RFCXXXX]

     Contact: Christer Holmberg (christer.holmberg@ericsson.com) IESG (iesg@ietf.org)

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
        Feature-Caps header field of a REGISTER response, indicates that
        the server supports the Voluntary Application Server
        Identification (VAPID) mechanism, defined in RFC 8292. The value
        is a public key of the server.

     Reference: [RFCXXXX]

     Contact: IESG (iesg@ietf.org)

12.4.  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

     This specification registers the following values:

     Value         Description                         Document
     -------       ----------------------------------  ----------

     apns          Apple Push Notification service     [RFC XXXX]
     fcm           Firebase Cloud Messaging            [RFC XXXX]

13.  Acknowledgements

   Thanks to Mickey Arnold, Paul Kyzivat, Dale Worley, Ranjit Avasarala,
   Martin Thomson, Mikael Klein, Susanna Sjoholm and Sjoholm, Kari-Pekka Perttula 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, <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>.

   [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>.

   [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>.

14.2.  Informative References

   [RFC8291]

   [RFC8292]  Thomson, M., "Message Encryption M. and P. Beverloo, "Voluntary Application Server
              Identification (VAPID) for Web Push", RFC 8291, 8292,
              DOI 10.17487/RFC8291, 10.17487/RFC8292, November 2017, <https://www.rfc-
              editor.org/info/rfc8291>.

Author's Address
              editor.org/info/rfc8292>.

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, <https://www.rfc-
              editor.org/info/rfc5626>.

   [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>.

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