draft-ietf-sipcore-sip-push-04.txt   draft-ietf-sipcore-sip-push-05.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track January 12, 2018 Intended status: Standards Track M. Arnold
Expires: July 16, 2018 Expires: August 17, 2018 Metaswitch Networks
February 13, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-04 draft-ietf-sipcore-sip-push-05
Abstract Abstract
This document describes how push notification mechanisms can be used This document describes how a Push Notification Services (PNS) can be
to wake up suspended Session Initiation Protocol (SIP) User Agents used to awake suspended Session Initiation Protocol (SIP) User Agents
(UAs), in order to be able to receive and generate SIP requests. The (UAs), for the UA to be able to receive and send SIP requests. The
document defines new SIP URI parameters, that can be used in a SIP document defines new SIP URI parameters and new feature-capability
REGISTER request to provide push notification information from the indicators that can be used in SIP messages to indicate support of
SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in the mechanism defined in this document, to exchange PNS information
this document) that will send a push request to the push server in between the SIP User Agent (UA) to the SIP entity that will request
order to trigger a push notification towards the SIP UA. push notifications towards the UA, and to trigger such push
notification requests.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 16, 2018. This Internet-Draft will expire on August 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 5 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 5
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 5 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 6 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 7
5.1. PNS Provider Information . . . . . . . . . . . . . . . . 6 5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 7
5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 6 5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 7
5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 8
6. Network Address Translator (NAT) Considerations . . . . . . . 8 5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 8
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 9
6. Network Address Translator (NAT) Considerations . . . . . . . 10
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. 555 (Push Notification Service Not Supported) Response 7.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 8 7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 10
7.3. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 9 7.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 11
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 9 7.4. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 11
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 12
9. pn-provider, pn-param and pn-prid URI Parameters for Apple 9. pn-provider, pn-param and pn-prid URI Parameters for Apple
Push Notification service . . . . . . . . . . . . . . . . . . 9 Push Notification service . . . . . . . . . . . . . . . . . . 12
10. pn-provider, pn-param and pn-prid URI Parameters for Google 10. pn-provider, pn-param and pn-prid URI Parameters for Google
Firebase Cloud Messaging (FCM) push notification service . . 10 Firebase Cloud Messaging (FCM) push notification service . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 11 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 14
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 11 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 14
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 11 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 14
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 11 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 14
12.1.4. pn-enckey . . . . . . . . . . . . . . . . . . . . . 12 12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 14
12.1.5. pn-enccode . . . . . . . . . . . . . . . . . . . . . 12 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 15
12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 12 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 15
12.3. SIP Global Feature-Capability Indicator . . . . . . . . 12 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 15
12.4. PNS Sub-registry Establishment . . . . . . . . . . . . . 13 12.4. PNS Sub-registry Establishment . . . . . . . . . . . . . 16
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
In order to save resources (e.g, battery life) some devices and In order to save resources (e.g., battery life) some devices
operating systems require suspended Session Initiation Protocol (SIP) (especially mobile devices) and operating systems will suspend
User Agents (UAs) [RFC3261] to be woken up using a push notification applications when not used. In some cases, internal timers cannot be
service. Typically each operating system uses a dedicated push used to awake such application, nor will incoming network traffic
notification service. For example, Apple iOS devices use the Apple awake the application. Instead, the only way to awake the
Push Notification service (APNs). 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.
Due to the restriction above, applications can not be woken up by Because of the restrictions above, Session Initiation Protocol (SIP)
non-push notification traffic. This means that a suspended SIP UA User Agents (UAs) [RFC3261] can not be awoken, in order to send re-
will not be able to receive an incoming SIP request (e.g., a SIP registration SIP REGISTER requests and to receive incoming SIP
INVITE request), or to send periodic re-registration requests. requests, without using a PNS to awake the UA in order to perform
those functions.
This document describes how push notification mechanisms can be used Also, without being able to use internal timers in order to awake
to wake up suspended SIP UAs, in order to be able to receive and applications, a UA will not be able to maintain connections e.g.,
generate SIP requests. The document defines new SIP URI parameters, using the SIP Outbound Mechanism [RFC5626], as it requires the UA to
that can be used in a SIP REGISTER request to provide push send periodic keep-alive messages.
notification information from the SIP 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 to trigger a push notification towards the SIP
UA.
When a SIP UA registers to a Push Notification Service (PNS), it will This document describes how PNSs can be used to awake suspended UAs,
receive a unique Push Resource ID (PRID) associated to that to be able to send re-registration REGISTER requests and to receive
registration. The SIP UA will provide the PRID to the SIP network in incoming SIP requests. The document defines new SIP URI parameters
a SIP REGISTER request. A SIP proxy (e.g., the SIP registrar) will and new feature-capability indicators [RFC6809] that can be used in
store a mapping between the registered contact and the PRID. SIP messages to indicate support of the mechanism defined in this
document, to exchange PNS information between the UA the SIP entity
(realized as a SIP proxy in this document) that will request push
notifications towards the UA, and to trigger such push notification
requests.
When the SIP proxy receives (or, in case the SIP proxy is also NOTE: Even if a UA is able to awake (e.g., using internal timers) in
registrar, initiates) a SIP request for a new dialog, or a stand- order to send periodic re-registration REGISTER requests, it might
alone SIP request, addressed towards a SIP UA, or when the SIP proxy still be useful to suspend the application between the sending of re-
determines that the SIP UA needs to perform a re-registration, the registration requests (as it will save battery life etc) and use a
SIP proxy will send a push request to the push notification service PNS to awake the UA when a SIP request addressed towards the UA
used by the SIP UA, using the push resource ID associated with the arrives.
registered contact 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 to receive the SIP request, and to generate
a SIP request (e.g., a SIP REGISTER) itself. The proxy can use the
receipt of the REGISTER request as a trigger to forward SIP request
towards the UA, using normal SIP routing procedures.
Different push notification mechanisms exist today. Some are based When a UA registers to a PNS, it will receive a unique Push Resource
on there standardized mechanism defined in [RFC8030], while others ID (PRID) associated with the push notification registration. The UA
are proprietary (e.g., the Apple Push Notification service). will provide the PRID to the SIP proxy that will request push
Figure 1 shows the generic push notification architecture supported notifications towards the UA in a REGISTER request.
by the mechanism in this document.
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 | | SIP UA | | Push Service | | SIP Proxy |
+--------+ +--------------+ +-----------------+ +--------+ +--------------+ +-----------------+
| | | | | |
| Subscribe | | | Subscribe | |
|--------------------->| | |--------------------->| |
| | | | | |
| Push Resource ID | | | Push Resource ID | |
|<---------------------| | |<---------------------| |
| | | | | |
| SIP REGISTER (Push Resource ID) | | SIP REGISTER (Push Resource ID) |
|===============================================>| |===============================================>|
| SIP 200 OK | |
|<===============================================|
| | | | | |
| | Push Message | | | |
| | |
| | | SIP INVITE
| | Push Message |<============
| | (Push Resource ID) | | | (Push Resource ID) |
| Push Message |<------------------------| | Push Message |<------------------------|
| (Push Resource ID) | | | (Push Resource ID) | |
|<---------------------| | |<---------------------| |
| | | | | |
| SIP REGISTER (Push Resource ID) |
|===============================================>|
| SIP 200 OK | |
|<===============================================|
| | |
| SIP INVITE | |
|<===============================================|
| | |
------- Push Notification API ------- Push Notification API
======= SIP ======= SIP
REGISTER sip:alice@example.com SIP/2.0 REGISTER sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
To: Alice <sip:alice@example.com> To: Alice <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=456248 From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09 Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com; Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme; pn-provider=acme;
pn-param=acme-param; pn-param=acme-param;
pn-prid="ZTY4ZDJlMzODE1NmUgKi0K"> pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>
Expires: 7200 Expires: 7200
Content-Length: 0 Content-Length: 0
Figure 1: SIP Push Notification Architecture Figure 1: SIP Push Notification Architecture
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Push Resource ID (PRID) 3. Push Resource ID (PRID)
When an entity registers with a PNS it receives a unique Push When a SIP UA registers with a PNS it receives a unique Push Resource
Resource ID (PRID), which is a value associated with the ID (PRID), which is a value associated with the registration.
registration.
The format of the PRID may vary depending on the PNS provider. The format of the PRID may vary depending on the PNS.
The details regarding discovery of the PNS, and the procedures for The details regarding discovery of the PNS, and the procedures
the push notification registration and maintenance are outside the regarding the push notification registration and maintenance are
scope of this document. The information needed to contact the PNS is outside the scope of this document. The information needed to
typically pre-configured in the operating system (OS) of the device. contact the PNS is typically pre-configured in the operating system
of the device.
4. SIP User Agent (UA) Behavior 4. SIP User Agent (UA) Behavior
Once the SIP UA has registered with the PNS and received the PRID Once the SIP UA has registered with the PNS, has received the PRID
(using the protocol and procedures associated with the PNS), and when (using the protocol and procedures associated with the PNS), and when
the UA wants to receive push notifications triggered by the SIP the UA wants to receive push notifications, the UA MUST send a SIP
proxy, the UA MUST send a SIP REGISTER using normal SIP registration REGISTER request using normal SIP procedures. The UA MUST include a
procedures. The UA MUST add a pn-provider, a pn-prid and a pn-param pn-provider, a pn-prid and a pn-param (if required for the specific
(if required for the specific PNS provider) SIP URI parameter to the PNS) SIP URI parameter in the SIP Contact header field URI of the
SIP Contact header field URI of the request. The pn-provider URI REGISTER request. The pn-provider URI parameter identifies the PNS,
parameter contains the PNS provider, the pn-prid URI parameter the pn-prid URI parameter contains the PRID value and the pn-param
contains the PRID value and the pn-param URI parameter contains URI parameter contains additional PNS-specific information.
additional PNS-specific information.
When the SIP UA receives a 200 (OK) 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
with a parameter value that the UA does not support, the UA cannot
assume that push notifications will be triggered by a SIP proxy. The
actions taken by the UA might be dependent on implementation or
deployment architecture, and are outside the scope of this document.
When the SIP UA receives a push notification, it MUST perform a SIP When the UA receives a 2xx response to the REGISTER request, if the
re-registration [RFC3261] by sending a SIP REGISTER request. If response contains a Feature-Caps header field with a 'sip.pns'
there are Network Address Translators (NATs) between the SIP UA and feature-capability indicator with a parameter value identifying the
the SIP proxy, the REGISTER request will create NAT bindings allowing same PNS that was identified by the pn-provider URI parameter in the
incoming SIP requests to reach the UA. If the SIP proxy triggered REGISTER request, the UA can assume that a SIP proxy will request
the push notification because it wants to forward a SIP request push notifications towards the UA. In other cases, the UA MUST NOT
towards the UA, the receipt of the REGISTER request can be used by assume that push notifications will be requested, and the actions
the proxy as a trigger to forward the request. taken by the UA might be dependent on implementation or deployment
architecture, and are outside the scope of this document.
As long as the SIP UA wants the SIP proxy to continue sending push In addition, if the response contains a Feature-Caps header field
requests, the UA MUST include a pn-provider, pn-prid and a pn-param with a 'sip.vapid' feature-capability indicator, the UA can use the
(if required for the specific PNS provider) SIP URI parameter in Voluntary Application Server Identification VAPID) mechanism
every re-registration SIP REGISTER request sent towards the proxy. [RFC8292] to restrict push notifications to the proxy (assuming that
the PNS supports VAPID).
Note that, in some cases, the PNS might update the PRID value, in When the UA receives a push notification, it MUST send a re-
which case the pn-prid URI parameter within the re-registration registration REGISTER request, using normal SIP procedures. If there
REGISTER request will contain the new value. 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 SIP UA at some point wants to stop the SIP proxy from sending As long as the UA wants to receive push notifications (requested by
push requests, the UA MUST send a SIP REGISTER request without the the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param
URI parameters described above, or remove the registration. (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 SIP UA expects to receive payload in the push notification, If the UA no longer wants to receive push notifications (requested by
the UA MAY add a pn-enckey and a pn-encsec SIP Contact header field the proxy), the UA MUST send a re-registration REGISTER request
SIP URI parameter, in order to allow encryption of the data using the without including the SIP URI parameters described above, or the UA
mechanism in [RFC8291]. The pn-enckey URI parameter contains the MUST remove the registration.
public key, and the pn-encsec URI parameter contains the
authentication secret [RFC8291]. The format of such payload is
outside the scope of this document.
NOTE: End-to-end encryption of the payload between the SIP proxy and For privacy and security reasons, the UA MUST NOT include the SIP URI
the SIP UA cannot be used if the push notification request payload parameters defined in this document in non-REGISTER request, to
contains information that needs to be accessible by the PNS provider. 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.
5. SIP Proxy Behavior 5. SIP Proxy Behavior
5.1. PNS Provider Information 5.1. PNS Identifier
The PNS provider is retrieved from the pn-provider SIP URI parameter. The PNS is identified by the pn-provider SIP URI parameter.
The protocol and format used for the push request depends on the PNS The protocol and format used for the push notification requests are
provider, and the details for constructing and sending the messages PNS-specific, and the details for constructing and sending a push
are outside the scope of this specification. notification request are outside the scope of this specification.
5.2. Trigger Periodic Re-registration 5.2. Trigger Periodic Re-registration
If the SIP UA needs to perform periodic re-registrations, the proxy In order to request push notifications towards a SIP UA, that will
needs to have information about when those re-registrations are to be trigger the UA to send re-registration SIP REGISTER requests, the SIP
performed. The proxy either needs to contain the SIP registrar proxy MUST have information about when a registration will expire.
functionality, or the proxy needs to retrieve the information from The proxy either needs to be the SIP registrar, or the proxy needs to
the registrar using some other mechanism. 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 When the proxy receives an indication that the UA needs to send a re-
perform a re-registration, the proxy triggers a push request towards registration REGISTER request, the proxy requests a push notification
the push notification server associated with the PRID. towards the UA.
Note that the re-registration needs to be triggered early enough, in Note that the push notification needs to be requested early enough,
order for the re-registration request to reach the registrar before in order for the associated re-registration REGISTER request to reach
the registration expires. 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 5.3. SIP Request
When the SIP proxy receives a SIP REGISTER request that contains a 5.3.1. REGISTER Request
pn-provider SIP URI parameter value that the proxy does not support,
or if the REGISTER request does not contain all information required
for the specific PNS provider, the proxy MUST either forward the
request (e.g., if the proxy is aware of another proxy that supports
the PNS provider) 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), the proxy SHOULD
insert a Feature-Caps header field with a '+sip.pns' header field
parameter in the response, indicating the PNS supported by the proxy.
If the SIP proxy supports the pn-provider SIP URI parameter value, The procedures in this section apply when the SIP proxy receives a
SIP REGISTER request that contains a pn-provider SIP URI parameter
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, the
proxy MUST either forward the request (e.g., if the proxy knows that
a downstream proxy supports the 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 each PNS that the proxy supports.
If the proxy supports the 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 in the REGISTER request before
forwarding the 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 UA.
If the proxy inserted a Feature-Caps header field with a 'sip.pns'
feature-capability indicator in the REGISTER request (see above),
when the proxy receives (or, in case the proxy is the SIP registrar, when the proxy receives (or, in case the proxy is the SIP registrar,
creates) a 200 (OK) response to the REGISTER request, the proxy MUST creates) a 2xx response to the REGISTER request, the proxy MUST
insert a Feature-Caps header field with a '+sip.pns' header field insert a Feature-Caps header field with a 'sip.pns' feature-
parameter in the response, in order to inform the SIP UA that the capability indicator in the response, identifying the PNS. This will
proxy supports the PNS indicated by the pn-provider SIP URI parameter inform the UA that the proxy supports, and will request, push
value. 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. 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].
When the SIP proxy receives (or, in case the proxy is the SIP 5.3.2. Initial Request for Dialog or Stand-Alone Request
registrar, creates) a SIP request for a new dialog (e.g., a SIP
INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE
request) aimed for 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 triggers a push
request towards the PNS associated with the PRID. After that the
proxy forwards the SIP request towards the UA using normal SIP
procedures.
As the push notification will trigger the SIP UA to perform a re- The procedures in this section apply when the SIP proxy has indicated
registration, the SIP proxy can use the receipt of the SIP REGISTER that it supports, and will request, push notifications towards the
request as a trigger to forward SIP request towards the UA. SIP UA.
The SIP proxy MUST NOT transport the SIP request as push request When the proxy receives (or, in case the proxy is the registrar,
payload, instead of forwarding the request using normal SIP creates) a SIP request for a new dialog (e.g., a SIP INVITE request)
procedures. 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.
If the SIP proxy is able to assume that the SIP UA is awake, and that The push notification will trigger the UA to send a re-registration
the UA is able to receive the SIP request, the proxy MAY choose to REGISTER request. The proxy will process the REGISTER request and
not trigger a push notification request before trying to forward the the associated response as described in Section 5.3.1. In case of a
SIP request towards the UA. The mechanisms for making such 2xx response to the REGISTER request, once the proxy has forwarded
assumption might be dependent on implementation or deployment the REGISTER response towards the UA, if the contact in the REGISTER
architecture, and are outside the scope of this document. response matches the Request-URI of the SIP request to be forwarded,
the proxy can also forwards the SIP request towards the UA, using
normal SIP procedures. If the contact and Request-URI do not match,
the proxy MUST reject the SIP request with a 404 (Not Found)
response.
If the SIP proxy is not able to contact the push notification In case of non-2xx response to the REGISTER request, theproxy MUST
provider, or to forward the SIP request to the SIP UA, the proxy MUST reject the SIP request with a 404 (Not Found) response.
reject the SIP request.
If the push notification request fails (see PNS-specific
documentation for details), the proxy MUST reject the SIP request
with a 555 (Push Notification Service Not Supported) 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.
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 assumption might be
dependent on implementation or deployment architecture, and are
outside the scope of this document.
6. Network Address Translator (NAT) Considerations 6. Network Address Translator (NAT) Considerations
Whenever the SIP UA receives a push notification, if the UA is Whenever the SIP UA receives a push notification, if the UA is
located behind a Network Address Translator (NAT), the UA might need 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 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 the re- for an incoming SIP request to reach the UA. By sending the re-
registration the UA will establish such NAT binding. registration SIP REQUEST the UA will establish such NAT binding.
7. Grammar 7. Grammar
7.1. 555 (Push Notification Service Not Supported) Response Code 7.1. 555 (Push Notification Service Not Supported) Response Code
The 555 response code is added to the "Server-Error" Status-Code The 555 response code is added to the "Server-Error" Status-Code
definition. 555 (Push Notification Service Not Supported) is used to definition. 555 (Push Notification Service Not Supported) is used to
indicate that the server did not support the push notification indicate that the server did not support the push notification
service specified in a 'pn-provider' SIP URI parameter. service identified in a 'pn-provider' SIP URI 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 The use of the SIP 555 response code is defined for SIP REGISTER
responses. Usage with other SIP methods is undefined. responses, responses to SIP requests initiating dialogs and responses
to stand-alone SIP requests.
7.2. sip.pns Feature-Capability Indicator 7.2. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator is used in a SIP 200 (OK) The sip.pns feature-capability indicator is used in a SIP request, or
response or in a 555 (Push Notficiation Service Not Supported) in a SIP 2xx response to a REGISTER request, that the entity
response to indicate which push notification services the sender of associated with the indicator supports, and will use, the push
the response supports. notification service identified by the indicator value. The feature-
capability indicator is used in a SIP 555 (Push Notification Service
Not Supported) response to a REGISTER request to indicate which push
notification services the entity associated with the indicator
supports. The values defined for the pn-provider SIP URI parameter
are used.
pns-fc = "+sip.pns" EQUAL LDQUOT pns-list RDQUOT pns-fc = "+sip.pns" EQUAL LDQUOT pns-list RDQUOT
pns-list = pns *(COMMA pns) pns-list = pns *(COMMA pns)
pns = tag-value pns = tag-value
; tag-value as defined in RFC 3840 ; tag-value as defined in RFC 3840
The value of the pns is identical to the corresponding pn-provider 7.3. sip.vapid Feature-Capability Indicator
SIP URI parameter for the push notification service associated with
the value.
7.3. SIP URI Parameters The sip.vapid feature-capability indicator is used in a SIP 2xx
response to a SIP 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 notifications towards the SIP UA associated with the
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 The section defines new SIP URI parameters, by extending the grammar
for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows:
uri-parameter =/ pn-provider / pn-param / pn-prid / pn-enccode / uri-parameter =/ pn-provider / pn-param / pn-prid
pn-enckey
pn-provider = "pn-provider" EQUAL pvalue pn-provider = "pn-provider" EQUAL pvalue
pn-param = "pn-param" EQUAL pvalue pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" 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 ; pvalue as defined in RFC 3261
; EQUAL as defined in RFC 3261 ; EQUAL as defined in RFC 3261
; COLON as defined in RFC 3261 ; COLON as defined in RFC 3261
The format and semantics of pns-param is specific to a given The format and semantics of pn-prid and pn-param are
pns-provider value. specific to 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 8. PNS Registration Requirements
When a new value is registered to the PNS Sub-registry, a reference When a new value is registered to the PNS Sub-registry, a reference
to a specification which describes the PNS associated with the value to a specification which describes the PNS associated with the value
is provided. That specification MUST contain the following is provided. That specification MUST contain the following
information: information:
o The value of the pn-provider SIP URI parameter. o The value of the pn-provider SIP URI parameter.
o How the pn-prid SIP URI parameter value is retrieved and set by o How the pn-prid SIP URI parameter value is retrieved and set by
the SIP UA. the SIP UA.
o How the pn-param SIP URI parameter (if required for the specific o How the pn-param SIP URI parameter (if required for the specific
PNS provider) value is retrieved and set by the SIP UA. 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 9. pn-provider, pn-param and pn-prid URI Parameters for Apple Push
Notification service Notification service
When the Apple Push Notification service (APNs) is used, the PNS- When the Apple Push Notification service (APNs) is used, the PNS-
related SIP URI parameters are set as described below. related SIP URI parameters are set as described below.
The value of the pn-provider URI parameter is "apns". The value of the pn-provider URI parameter is "apns".
Example: pn-provider = apns Example: pn-provider = apns
skipping to change at page 10, line 48 skipping to change at page 13, line 24
The value of the pn-prid URI parameter is the Registration token, The value of the pn-prid URI parameter is the Registration token,
which is generated by the FCM SDK for each client app instance. which is generated by the FCM SDK for each client app instance.
For more information on the Sender ID and Registration token: For more information on the Sender ID and Registration token:
https://firebase.google.com/docs/cloud-messaging/concept-options https://firebase.google.com/docs/cloud-messaging/concept-options
11. Security Considerations 11. Security Considerations
In addition to the information exchanged between a device and its PNS Different mechanisms exist for authenticating and authorizing devices
in order to establish a push notification subscription, the mechanism and users registering with a PNS. The mechanisms for authorizing and
in this document does not require entities to provide any additional authenticating the users are PNS-specific, and are outside the scope
information to the PNS. 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.
Push notification mechanisms provide different methods to ensure that Typically, the PNS also requires the SIP proxy requesting push
malicious user cannot trigger push notifications to a device. Users notifications to be authenticated and authorized by the PNS. In some
of the mechanism in this document MUST take measures to prevent push cases the PNS also require the SIP application (or the SIP
notifications from being sent to a device from a malicious user. application developer) to be identified in order for the application
to request push notifications.
In case entities do want to include payload in the push If the push notification related information carried in SIP could be
notifications, this document defines the means for using end-to-end used by a malicious middleman to trigger push notifications towards a
payload encryption between the entity sending the push request and device, operators MUST ensure that the SIP signalling is properly
the entity receiving the associated push notification. 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 12. IANA considerations
12.1. SIP URI Parameters 12.1. SIP URI Parameters
This section defines new SIP URI Parameters that extend the "SIP/SIPS This section defines new SIP URI Parameters that extend the "SIP/SIPS
URI Parameters" sub-registry [RFC3969] under the sip-parameters URI Parameters" sub-registry [RFC3969] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters. registry: http://www.iana.org/assignments/sip-parameters.
12.1.1. pn-provider 12.1.1. pn-provider
skipping to change at page 12, line 4 skipping to change at page 14, line 30
12.1.2. pn-param 12.1.2. pn-param
Parameter Name: pn-param Parameter Name: pn-param
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
12.1.3. pn-prid 12.1.3. pn-prid
Parameter Name: pn-prid
Predefined Values: No
Reference: RFC XXXX
12.1.4. pn-enckey
Parameter Name: pn-enckey Parameter Name: pn-prid
Predefined Values: No
Reference: RFC XXXX
12.1.5. pn-enccode
Parameter Name: pn-enccode
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
12.2. SIP Response Code 12.2. SIP Response Code
This section defines a new SIP response code that extends the This section defines a new SIP response code that extends the
"Response Codes" sub-registry [RFC3261] under the sip-parameters "Response Codes" sub-registry [RFC3261] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters. registry: http://www.iana.org/assignments/sip-parameters.
Response Code Number: 555 Response Code Number: 555
Default Reason Phrase: Push Notification Service Not Supported Default Reason Phrase: Push Notification Service Not Supported
12.3. SIP Global Feature-Capability Indicator 12.3. SIP Global Feature-Capability Indicator
12.3.1. sip.pns
This section defines a new feature-capability indicator that extends This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.pns Name: sip.pns
Description: This feature-capability indicator, when included in a 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
indicates the push notification service supported by the server.
Reference: [RFCXXXX]
Contact: 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 Feature-Caps header field of a REGISTER response, indicates that
the server supports the SIP push mechanism. The value is a list the server supports the Voluntary Application Server
of the push notification services supported by the server. Identification (VAPID) mechanism, defined in RFC 8292. The value
is a public key of the server.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: Christer Holmberg (christer.holmberg@ericsson.com) Contact: IESG (iesg@ietf.org)
12.4. PNS Sub-registry Establishment 12.4. PNS Sub-registry Establishment
This section creates a new sub-registry, "PNS", under the sip- This section creates a new sub-registry, "PNS", under the sip-
parameters registry: http://www.iana.org/assignments/sip-parameters. parameters registry: http://www.iana.org/assignments/sip-parameters.
The purpose of the sub-registry is to register SIP URI pn-provider The purpose of the sub-registry is to register SIP URI pn-provider
values. 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 This sub-registry is defined as a table that contains the following
three columns: three columns:
Value: The token under registration Value: The token under registration
Description: The name of the Push Notification Service (PNS) Description: The name of the Push Notification Service (PNS)
Document: A reference to the document defining the registration Document: A reference to the document defining the registration
This specification registers the following values: This specification registers the following values:
Value Description Document Value Description Document
------- ---------------------------------- ---------- ------- ---------------------------------- ----------
apns Apple Push Notification service [RFC XXXX] apns Apple Push Notification service [RFC XXXX]
fcm Firebase Cloud Messaging [RFC XXXX] fcm Firebase Cloud Messaging [RFC XXXX]
13. Acknowledgements 13. Acknowledgements
Thanks to Mickey Arnold, Paul Kyzivat, Dale Worley, Ranjit Avasarala, Thanks to Mickey Arnold, Paul Kyzivat, Dale Worley, Ranjit Avasarala,
Martin Thomson, Mikael Klein, Susanna Sjoholm and Kari-Pekka Perttula Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula,
for reading the text, and providing useful feedback. Liviu Chircu, Roman Shpount and Yehoshua Gev for reading the text,
and providing useful feedback.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
skipping to change at page 14, line 43 skipping to change at page 17, line 44
Indicate Support of Features and Capabilities in the Indicate Support of Features and Capabilities in the
Session Initiation Protocol (SIP)", RFC 6809, Session Initiation Protocol (SIP)", RFC 6809,
DOI 10.17487/RFC6809, November 2012, <https://www.rfc- DOI 10.17487/RFC6809, November 2012, <https://www.rfc-
editor.org/info/rfc6809>. editor.org/info/rfc6809>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030, Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016, <https://www.rfc- DOI 10.17487/RFC8030, December 2016, <https://www.rfc-
editor.org/info/rfc8030>. editor.org/info/rfc8030>.
[RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server
Identification (VAPID) for Web Push", RFC 8292,
DOI 10.17487/RFC8292, November 2017, <https://www.rfc-
editor.org/info/rfc8292>.
14.2. Informative References 14.2. Informative References
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
DOI 10.17487/RFC8291, November 2017, <https://www.rfc- "Managing Client-Initiated Connections in the Session
editor.org/info/rfc8291>. Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, <https://www.rfc-
editor.org/info/rfc5626>.
Author's Address [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 Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
Michael Arnold
Metaswitch Networks
100 Church Street
Enfield EN2 6BQ
United Kingdom
Email: Michael.Arnold@metaswitch.com
 End of changes. 69 change blocks. 
252 lines changed or deleted 417 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/