draft-ietf-sipcore-sip-push-10.txt   draft-ietf-sipcore-sip-push-11.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track M. Arnold Intended status: Standards Track M. Arnold
Expires: September 27, 2018 Metaswitch Networks Expires: October 13, 2018 Metaswitch Networks
March 26, 2018 April 11, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-10 draft-ietf-sipcore-sip-push-11
Abstract Abstract
This document describes how a Push Notification Service (PNS) can be This document describes how a Push Notification Service (PNS) can be
used to awake suspended Session Initiation Protocol (SIP) User Agents used to awake suspended Session Initiation Protocol (SIP) User Agents
(UAs), for the UA to be able to receive and send SIP requests. The (UAs), using push notifications, for the UA to be able to send re-
document defines new SIP URI parameters and new feature-capability registration REGISTER requests and to receive receive incoming SIP
indicators that can be used in SIP messages to indicate support of requests. The document defines new SIP URI parameters and new
the mechanism defined in this document, to exchange PNS information feature-capability indicators that can be used in SIP messages to
between the SIP User Agent (UA) and the SIP entity that will request indicate support of the mechanism defined in this document, to
push notifications towards the UA, and to trigger such push exchange PNS information between the SIP User Agent (UA) and the SIP
notification requests. entity that will request 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 September 27, 2018. This Internet-Draft will expire on October 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 8 4.1. Request Push Notifications from Network . . . . . . . . . 6
5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 8 4.2. Query Network Push Notification Capabilities . . . . . . 8
5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 8 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9
5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 9 5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 9
5.3.2. Initial Request for Dialog or Stand-Alone Request . . 11 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 10
6. Network Address Translator (NAT) Considerations . . . . . . . 12 5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 10
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 12
7.1. 555 (Push Notification Service Not Supported) Response 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. 555 (Push Notification Service Not Supported) Response
7.2. 556 (Push Notification Failed) Response Code . . . . . . 13 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 13 6.2. 556 (Push Notification Failed) Response Code . . . . . . 14
7.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 13 6.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 14
7.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 14 6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 14
7.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 14 6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 15
7.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 15 6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 15
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 15 6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 16
9. pn-provider, pn-param and pn-prid URI Parameters for Apple 7. PNS Registration Requirements . . . . . . . . . . . . . . . . 16
Push Notification service . . . . . . . . . . . . . . . . . . 15 8. pn-provider, pn-param and pn-prid URI Parameters for Apple
10. pn-provider, pn-param and pn-prid URI Parameters for Google Push Notification service . . . . . . . . . . . . . . . . . . 16
Firebase Cloud Messaging (FCM) push notification service . . 16 9. pn-provider, pn-param and pn-prid URI Parameters for Google
11. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 Firebase Cloud Messaging (FCM) push notification service . . 17
(Generic Event Delivery Using HTTP Push) . . . . . . . . . . 16 10. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 17
13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
13.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 18 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
13.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 18 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 19
13.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 18 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 19
13.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 18 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 19
13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 18 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 19
13.2.1. 555 (Push Notification Service Not Supported) . . . 18 12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 19
13.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 19 12.2.1. 555 (Push Notification Service Not Supported) . . . 19
13.3. SIP Global Feature-Capability Indicator . . . . . . . . 19 12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 20
13.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 19 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 20
13.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 20 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 20
13.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 20 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 21
12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 21
13.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 21 12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 22
13.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 21 12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 22
13.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 22 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 23
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
15.1. Normative References . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . 24
15.2. Informative References . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In order to save resources (e.g., battery life) some devices In order to save resources (e.g., battery life) some devices
(especially mobile devices) and operating systems will suspend (especially mobile devices) and operating systems will suspend
applications when not used. In some cases, internal timers cannot be applications when not used. In some cases, internal timers cannot be
used to awake such applications, nor will incoming network traffic used to awake such applications, nor will incoming network traffic
awake the application. Instead, the only way to awake the awake the application. Instead, the only way to awake the
application is by using a Push Notification Service (PNS). Typically application is by using a Push Notification Service (PNS). Typically
each operating system uses a dedicated PNS. For example, Apple iOS each operating system uses a dedicated PNS. For example, Apple iOS
skipping to change at page 3, line 38 skipping to change at page 3, line 39
registration SIP REGISTER requests and to receive incoming SIP registration SIP REGISTER requests and to receive incoming SIP
requests, without using a PNS to awake the UA in order to perform requests, without using a PNS to awake the UA in order to perform
those functions. those functions.
Also, without being able to use internal timers in order to awake Also, without being able to use internal timers in order to awake
applications, a UA will not be able to maintain connections e.g., applications, a UA will not be able to maintain connections e.g.,
using the SIP Outbound Mechanism [RFC5626], as it requires the UA to using the SIP Outbound Mechanism [RFC5626], as it requires the UA to
send periodic keep-alive messages. send periodic keep-alive messages.
This document describes how PNSs can be used to awake suspended UAs, This document describes how PNSs can be used to awake suspended UAs,
to be able to send re-registration REGISTER requests and to receive using push notifications, to be able to send re-registration REGISTER
incoming SIP requests. The document defines new SIP URI parameters requests and to receive incoming SIP requests. The document defines
and new feature-capability indicators [RFC6809] that can be used in new SIP URI parameters and new feature-capability indicators
SIP messages to indicate support of the mechanism defined in this [RFC6809] that can be used in SIP messages to indicate support of the
document, to exchange PNS information between the UA and the SIP mechanism defined in this document, to exchange PNS information
entity (realized as a SIP proxy in this document) that will request between the UA and the SIP entity (realized as a SIP proxy in this
push notifications towards the UA, and to trigger such push document) that will request push notifications towards the UA, and to
notification requests. request such push notification requests.
NOTE: Even if a UA is able to awake (e.g., using internal timers) in NOTE: Even if a UA is able to awake by other means than receiving
order to send periodic re-registration REGISTER requests, it might push notifications (e.g., by using internal timers) in order to send
still be useful to suspend the application between the sending of re- periodic re-registration REGISTER requests, it might still be useful
registration requests (as it will save battery life etc) and use a to suspend the application between the sending of re-registration
PNS to awake the UA when a SIP request addressed towards the UA requests (as it will save battery life etc) and use push
notifications to awake the UA when an incoming SIP request UA
arrives. arrives.
When a UA registers to a PNS, it will receive a unique Push Resource When a UA registers to a PNS, it will receive a unique Push Resource
ID (PRID) associated with the push notification registration. The UA ID (PRID) associated with the push notification registration. The UA
will use a REGISTER request to provide the PRID to the SIP proxy that will use a REGISTER request to provide the PRID to the SIP proxy that
will request push notifications towards the UA. will request push notifications towards the UA.
When the proxy receives (or, if the proxy is the SIP registrar When the proxy receives (or, if the proxy is the SIP registrar
[RFC3261], initiates) a SIP request for a new dialog, or a stand- [RFC3261], initiates) a SIP request for a new dialog, or a stand-
alone SIP request, addressed towards a UA, or when the proxy alone SIP request, addressed towards a UA, or when the proxy
skipping to change at page 6, line 21 skipping to change at page 6, line 27
The format of the PRID may vary depending on the PNS. The format of the PRID may vary depending on the PNS.
The details regarding discovery of the PNS, and the procedures The details regarding discovery of the PNS, and the procedures
regarding the push notification registration and maintenance are regarding the push notification registration and maintenance are
outside the scope of this document. The information needed to outside the scope of this document. The information needed to
contact the PNS is typically pre-configured in the operating system contact the PNS is typically pre-configured in the operating system
of the device. of the device.
4. SIP User Agent (UA) Behavior 4. SIP User Agent (UA) Behavior
4.1. Request Push Notifications from Network
Once the SIP UA has registered with the PNS, has received the PRID 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), if the
the UA wants to receive push notifications, the UA MUST send a SIP UA wants to receive push notifications (requested by the proxy), the
REGISTER request using normal SIP procedures. The UA MUST include UA MUST include the following SIP URI parameters in the SIP Contact
the following SIP URI parameters in the SIP Contact header field URI header field URI of the REGISTER request: pn-provider, pn-prid and
of the REGISTER request: pn-provider, pn-prid and pn-param (if pn-param (if required for the specific PNS). The pn-provider URI
required for the specific PNS). The pn-provider URI parameter parameter identifies the type of PNS, the pn-prid URI parameter
identifies the PNS, the pn-prid URI parameter contains the PRID value contains the PRID value and the pn-param URI parameter contains
and the pn-param URI parameter contains additional PNS-specific additional PNS-specific information.
information.
When the UA receives a 2xx response to the REGISTER request, if the When the UA receives a 2xx response to the REGISTER request, if the
response contains a Feature-Caps header field with a 'sip.pns' response contains a Feature-Caps header field with a 'sip.pns'
feature-capability indicator with a parameter value identifying the feature-capability indicator with a parameter value identifying the
same PNS that was identified by the pn-provider URI parameter in the same type of PNS that was identified by the pn-provider URI parameter
REGISTER request, the UA can assume that a SIP proxy will request in the REGISTER request, the UA can assume that a SIP proxy will
push notifications towards the UA. In other cases, the UA MUST NOT request push notifications towards the UA. In other cases, the UA
assume that push notifications will be requested, and the actions MUST NOT assume that push notifications will be requested, and the
taken by the UA might be dependent on implementation or deployment actions taken by the UA might be dependent on implementation or
architecture, and are outside the scope of this document. deployment architecture, and are outside the scope of this document.
In addition, if the response contains a Feature-Caps header field In addition, if the response contains a Feature-Caps header field
with a 'sip.vapid' feature-capability indicator, the proxy supports with a 'sip.vapid' feature-capability indicator, the proxy supports
use of the Voluntary Application Server Identification (VAPID) use of the Voluntary Application Server Identification (VAPID)
mechanism [RFC8292] to restrict push notifications to the proxy. mechanism [RFC8292] to restrict push notifications to the proxy.
When the UA receives a push notification, it MUST send a re- When the UA receives a push notification, it MUST send a re-
registration REGISTER request, using normal SIP procedures. If there registration REGISTER request, using normal SIP procedures. If there
are Network Address Translators (NATs) between the UA and the proxy, are Network Address Translators (NATs) between the UA and the proxy,
the REGISTER request will create NAT bindings that will allow the REGISTER request will create NAT bindings that will allow
incoming SIP requests to reach the UA. Once the UA has received a 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 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 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 request (e.g., a SIP MESSAGE), if such SIP request triggered the push
notification request. Note that, depending on which transport notification request. Note that, depending on which transport
protocol is used, the SIP request might reach the UA before the protocol is used, the SIP request might reach the UA before the
REGISTER response. REGISTER response.
If the UA is able to generate re-registration REGISTER requests If the UA is able to send re-registration REGISTER requests using a
without recieving push notifications (e.g., using a timer), the UA non-push mechanism (e.g., using an internal timer that periodically
MUST insert a 'sip.pnsreg' media feature tag [RFC3840] in the Contact awakes the UA), the UA MUST insert a 'sip.pnsreg' media feature tag
header field of each REGISTER request. Then, if the response to the [RFC3840] in the Contact header field URI of each REGISTER request.
REGISTER request contains a 'sip.pnsreg' feature-capability indicator Then, if the response to the REGISTER request contains a 'sip.pnsreg'
with an indicator value, the UA MUST send REGISTER requests prior to feature-capability indicator with an indicator value, the UA MUST
the registration expires. The indicator value indicates a minimum send REGISTER requests prior to the registration expires. The
time (given in seconds), prior to the registration expires when the indicator value indicates a minimum time (given in seconds), prior to
UA MUST send the REGISTER request. If the REGISTER response does not the registration expires when the UA MUST send the REGISTER request.
contain a a 'sip.pnsreg' feature-capability indicator, the UA only Even if the UA is able to to send REGISTER requests using a non-push
sends REGISTER requests when it receives a push notification. mechanism, the UA MUST still send a REGISTER request when it receives
a push notification, following the procedures in this section. If
the REGISTER response does not contain a a 'sip.pnsreg' feature-
capability indicator, the UA SHOULD only send a re-registration
REGISTER request when it receives a push notification (even if the UA
is able to use a non-push mechanism for sending re-registration
REGISTER requests).
Note that even if the UA is able to send re-registration REGISTER NOTE: In some cases the UA might be able to use a non-push mechanism
requests without receiving push notifications, the UA MUST still send to awake and send re-registration REGISTER requests. Such REGISTER
a REGISTER request whenever it receives a push notification, request will update the registration expiration timer, and the proxy
according to the procedures in this section. does not need to request a push notification towards the UA in order
to awake the UA. The proxy will still request a push notification
towards the UA when the proxy receives a SIP request addressed
towards the UA (Section 5.3.2). This allows the UA to e.g., use
timers for sending re-registration REGISTER requests, but to be
suspended (in order to save battery resources etc) between sending
the REGISTER requests and use push notification to awaken the UA to
process incoming calls.
NOTE: As described above, in some cases the UA might be able to use a NOTE: This specification does not define any usage of a push
non-push mechanism (e.g., a timer) to awake and send re-registration notification payload. As defined in Section 5.3.2, a proxy must not
REGISTER requests. This allows the UA to e.g., use timers for include any payload in the push notification request. If a SIP UA
sending REGISTER requests, but to be suspended (in order to save receives a push notification that contains a payload the UA can
battery resources etc) between sending the REGISTER requests and use discard the payload, but the UA will still send a re-registration
push notification to awaken the UA to process incoming calls. REGISTER request.
NOTE: If the SIP UA application wants to use push notifications for
other purposes than to trigger re-registration requests, it needs to
be able to distinguish between the different purposes when receiving
push notifications. Mechanisms for doing that are outside the scope
of this specification.
As long as the UA wants to receive push notifications (requested by As long as the UA wants to receive push notifications (requested by
the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param
(if required for the specific PNS provider) SIP URI parameter in each (if required for the specific PNS provider) SIP URI parameter in each
re-registration REGISTER request. Note that, in some cases, the PNS re-registration REGISTER request. Note that, in some cases, the PNS
might update the PRID value, in which case the UA will include the 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 new value in the pn-prid SIP URI parameter in the re-registration
REGISTER request. REGISTER request.
If the UA no longer wants to receive push notifications (requested by If the UA no longer wants to receive push notifications (requested by
skipping to change at page 8, line 16 skipping to change at page 8, line 41
the registration. The exact mechanisms for expiry and renewal of the registration. The exact mechanisms for expiry and renewal of
PRIDs will be PNS-specific and are outside the scope of this PRIDs will be PNS-specific and are outside the scope of this
document. document.
For privacy and security reasons, the UA MUST NOT include the SIP URI For privacy and security reasons, the UA MUST NOT include the SIP URI
parameters defined in this document in non-REGISTER request, to parameters defined in this document in non-REGISTER request, to
prevent the PNS information associated with the UA from reaching the prevent the PNS information associated with the UA from reaching the
remote peer. For example, the UA MUST NOT include the SIP URI remote peer. For example, the UA MUST NOT include the SIP URI
parameters in the Contact header field of an INVITE request. parameters in the Contact header field of an INVITE request.
4.2. Query Network Push Notification Capabilities
A SIP UA might need to query the network for push notification
capabilities (e.g., related to VAPID) before it registers with the
PNS, and before it indicates that it wants to receive push
notifications. The UA can do so by only including the pn-provider
SIP URI parameter in the SIP Contact header field URI of the REGISTER
request, but without including the pn-prid SIP URI parameter. Later,
once the UA has received a response to the REGISTER request, with the
push notification information from the network, if the UA wants to
receive push notifications, the UA will send a re-registration
REGISTER request, including all pn- SIP URI parameters required by
the specific PNS, following the procedures in Section 4.1.
5. SIP Proxy Behavior 5. SIP Proxy Behavior
5.1. PNS Identifier 5.1. PNS Identifier
The PNS is identified by the pn-provider SIP URI parameter. The type of PNS is identified by the pn-provider SIP URI parameter.
The protocol and format used for the push notification requests are The protocol and format used for the push notification requests are
PNS-specific, and the details for constructing and sending a push PNS-specific, and the details for constructing and sending a push
notification request 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
In order to request push notifications towards a SIP UA that will In order to request push notifications towards a SIP UA that will
trigger the UA to send re-registration SIP REGISTER requests, the SIP trigger the UA to send re-registration SIP REGISTER requests, the SIP
proxy MUST have information about when a registration will expire. proxy MUST have information about when a registration will expire.
skipping to change at page 8, line 46 skipping to change at page 9, line 37
registration REGISTER request, the proxy requests a push notification registration REGISTER request, the proxy requests a push notification
towards the UA. towards the UA.
Note that the push notification needs to be requested early enough, Note that the push notification needs to be requested early enough,
in order for the associated re-registration REGISTER request to reach in order for the associated re-registration REGISTER request to reach
the SIP registrar before the registration expires. It is RECOMMENDED the SIP registrar before the registration expires. It is RECOMMENDED
that the proxy requests the push notification at least 120 seconds that the proxy requests the push notification at least 120 seconds
before the registration expires. before the registration expires.
If the UA has indicated, using the 'sip.pnsreg' media feature tag, If the UA has indicated, using the 'sip.pnsreg' media feature tag,
that it is able to sending re-registration REGISTER requests without that it is able to awake using a non-push mechanism for sending re-
receiving push notifications, if the proxy does not receive a registration REGISTER requests, if the proxy does not receive a
REGISTER request prior to 120 seconds before the registration REGISTER request prior to 120 seconds before the registration
expires, the proxy MAY request a push notification towards the UA, to expires, the proxy MAY request a push notification towards the UA, to
trigger the UA to send a REGISTER request. trigger the UA to send a REGISTER request.
NOTE: In some cases the UA might be able to use a non-push mechanism NOTE: As described in Section 4.2, a SIP UA might send a REGISTER
(e.g., a timer) to awake and send re-registration REGISTER requests. request without including a pn-prid SIP URI parameter, in order to
Such REGISTER request will update the registration expiration timer, retrieve push notification capabilities from the network before the
and the proxy does not need to request a push notification towards UA expects to receive push notifications from the network. A proxy
the UA in order to awake the UA. The proxy will still request a push will not request push notifications towards a UA that has not
notification towards the UA when the proxy receives a SIP request provided a pn-prid SIP URI parameter.
addressed towards the UA (Section 5.3.2). This allows the UA to
e.g., use timers for sending re-registration REGISTER requests, but If the proxy receives information that a registration has expired,
to be suspended (in order to save battery resources etc) between the proxy MUST NOT request further push notifications towards the UA.
sending the REGISTER requests and use push notification to awaken the
UA to process incoming calls.
5.3. SIP Request 5.3. SIP Request
5.3.1. REGISTER Request 5.3.1. REGISTER
The procedures in this section apply when the SIP proxy receives a The procedures in this section apply when the SIP proxy receives a
SIP REGISTER request (initial REGISTER request for a registration, or SIP REGISTER request (initial REGISTER request for a registration, or
a re-registration REGISTER request) that contains a pn-provider SIP a re-registration REGISTER request) that contains a pn-provider SIP
URI parameter identifying a PNS. If the proxy receives a REGISTER URI parameter identifying a type of PNS. If the proxy receives a
request that does not contain a pn-provider SIP URI parameter, or REGISTER request that does not contain a pn-provider SIP URI
that removes the registration, the proxy MUST NOT request push parameter, or that removes the registration, the proxy MUST NOT
notifications towards the UA associated with the REGISTER request, or request push notifications towards the UA associated with the
perform any other procedures in this section. REGISTER request, or perform any other procedures in this section.
As described in Section 4.2, a SIP UA might send a REGISTER request
without including a pn-prid SIP URI parameter in the Contact header
field URI, in order to retrieve push notification capabilities from
the network before the UA the proxy will request push notifications
towards the UA. The procedures in this section apply to both the
case when the REGISTER request contains a pn-prid SIP URI parameter,
and when it does not.
When the proxy receives a REGISTER request, if the REGISTER request When the proxy receives a REGISTER request, if the REGISTER request
contains a Feature-Caps header field with a 'sip.pns' feature- contains a Feature-Caps header field with a 'sip.pns' feature-
capability indicator, it indicates that an upstream proxy supports, capability indicator, it indicates that an upstream proxy supports,
and will request, push notifications towards the UA. The proxy MUST and will request (if the Contact header field URI of the REGISTER
skip the rest of the procedures in this section, and process the request contains a pn-prid SIP URI parameter), push notifications
REGISTER request using normal SIP procedures. towards the UA. The proxy MUST skip the rest of the procedures in
this section, and process the REGISTER request using normal SIP
procedures.
If the proxy considers the requested registration expiration interval If the proxy considers the requested registration expiration interval
[RFC3261] to be too short, the proxy MUST either send a 423 (Interval [RFC3261] to be too short, the proxy MUST either send a 423 (Interval
Too Brief) response to the REGISTER request or skip the rest of the Too Brief) response to the REGISTER request, or skip the rest of the
procedures in this section, and process the REGISTER request using procedures in this section and process the REGISTER request using
normal SIP procedures. Similarly, when the proxy receives a 2xx normal SIP procedures. If the proxy sends a 423 (Interval Too Brief)
response to the REGISTER request (see below), if the proxy considers response, the proxy SHOULD insert a Feature-Caps header field with a
the registration expiration internal indicated by the registrar too 'sip.pns' feature-capability indicator in the response, identifying
short, the proxy MUST NOT insert a Feature-Caps header field with a each type of PNS that the proxy supports. Similarly, when the proxy
'sip.pns' feature-capability indicator in the response, and the proxy receives a 2xx response to the REGISTER request (see below), if the
MUST NOT request push notifications associated with the registration. proxy considers the registration expiration interval indicated by the
A registration expiration interval MUST be considered too short if registrar too short, the proxy MUST NOT insert a Feature-Caps header
the interval is smaller than the time prior to expiration that the
proxy would request a push notification. The proxy MAY consider the
interval too small based on its own policy so as to reduce load on
the system.
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, field with a 'sip.pns' feature-capability indicator in the response,
identifying each PNS that the proxy supports. and the proxy MUST NOT request push notifications associated with the
registration. A registration expiration interval MUST be considered
too short if the interval is smaller than the time prior to
expiration that the proxy would request a push notification. The
proxy MAY consider the interval too small based on its own policy so
as to reduce load on the system.
If the proxy supports the PNS identified by the pn-provider SIP URI Otherwise, if the pn-provider SIP URI parameter identifies a type of
parameter, the proxy MUST insert a Feature-Caps header field with a PNS that the proxy does not support, or if the REGISTER request does
'sip.pns' feature-capability indicator, identifying the PNS, in the not contain all additional information required for the specific type
REGISTER request before forwarding the REGISTER request (unless the of PNS, the proxy MUST either forward the request (e.g., if the proxy
proxy is the registrar, in which case the proxy will terminate the knows that a downstream proxy supports the type of PNS) or send a SIP
REGISTER request). This will inform downstream proxies that the 555 (Push Notification Service Not Supported) response to the
proxy supports, and will request, push notifications towards the UA. REGISTER request. If the proxy sends a SIP 555 (Push Notification
Service Not Supported) response, the proxy SHOULD insert a Feature-
Caps header field with a 'sip.pns' feature-capability indicator in
the response, identifying the type of each PNS that the proxy
supports. The decision whether to forward the request, or to send a
response, is done based on local policy.
If the proxy supports the type of PNS identified by the pn-provider
SIP URI parameter, the proxy MUST insert a Feature-Caps header field
with a 'sip.pns' feature-capability indicator, identifying the type
of PNS, in the REGISTER request before forwarding the REGISTER
request (unless the proxy is the registrar, in which case the proxy
will terminate the REGISTER request). This will inform downstream
proxies that the proxy supports, and will request (if the Contact
header field URI of the REGISTER request contains a pn-prid SIP URI
parameter), push notifications towards the UA.
If the proxy inserted a Feature-Caps header field with a 'sip.pns' If the proxy inserted a Feature-Caps header field with a 'sip.pns'
feature-capability indicator in the REGISTER request (see above), if feature-capability indicator in the REGISTER request (see above), if
the proxy receives (or, in case the proxy is the SIP registrar, the proxy receives (or, in case the proxy is the SIP registrar,
creates) a 2xx 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' feature- insert a Feature-Caps header field with a 'sip.pns' feature-
capability indicator in the response, identifying the PNS. This will capability indicator in the response, identifying the type of PNS.
inform the UA that the proxy supports, and will request, push This will inform the UA that the proxy supports, and will request (if
notifications towards the UA. The proxy MUST only indicate support the Contact header field URI of the REGISTER request contained a pn-
of the same PNS that was identified in the pn-provider SIP URI prid SIP URI parameter), push notifications towards the UA. The
parameter in the REGISTER request. If the proxy receives a receives proxy MUST only indicate support of the same PNS that was identified
a SIP 555 (Push Notification Service Not Supported) response, the in the pn-provider SIP URI parameter in the REGISTER request. If the
proxy SHOULD insert a Feature-Caps header field with a 'sip.pns' proxy receives a receives a SIP 555 (Push Notification Service Not
feature-capability indicator in the response, identifying each PNS Supported) response, the proxy SHOULD insert a Feature-Caps header
that the proxy supports. field with a 'sip.pns' feature-capability indicator in the response,
identifying the type of each PNS that the proxy supports.
In addition, if the proxy receives a 2xx response to the REGISTER In addition, if the proxy receives a 2xx response to the REGISTER
request: request:
o if the proxy supports, and will use, the VAPID mechanism, the o if the proxy supports, and will use, the VAPID mechanism, the
proxy MUST insert a Feature-Caps header field with a 'sip.vapid' proxy MUST insert a Feature-Caps header field with a 'sip.vapid'
feature-capability indicator in the response. The header field feature-capability indicator in the response. The header field
parameter contains the public key identifying the proxy [RFC8292]. parameter contains the public key identifying the proxy [RFC8292].
The proxy MUST be able to determine whether the PNS supports the The proxy MUST be able to determine whether the PNS supports the
VAPID mechanism before it inserts the feature-capability VAPID mechanism before it inserts the feature-capability
skipping to change at page 11, line 32 skipping to change at page 12, line 37
The push notification will trigger the UA to send a re-registration The push notification will trigger the UA to send a re-registration
REGISTER request. The proxy will process the REGISTER request and REGISTER request. The proxy will process the REGISTER request and
the associated response as described in Section 5.3.1. In case of a the associated response as described in Section 5.3.1. In case of a
2xx response to the REGISTER request, once the proxy has forwarded 2xx response to the REGISTER request, once the proxy has forwarded
the REGISTER response towards the UA, if the contact in the REGISTER the REGISTER response towards the UA, if the contact in the REGISTER
response matches the Request-URI of the SIP request to be forwarded, response matches the Request-URI of the SIP request to be forwarded,
the proxy can also forward the SIP request towards the UA, using the proxy can also forward the SIP request towards the UA, using
normal SIP procedures. If the contact of the most recent REGISTER normal SIP procedures. If the contact of the most recent REGISTER
2xx response and Request-URI do not match, the proxy MUST reject the 2xx response and Request-URI do not match, the proxy MUST reject the
SIP request with a 404 (Not Found) response. As both the SIP request SIP request with a 404 (Not Found) response. This can happen if the
to be forwarded towards the UA, and the re-registration REGISTER UA sends a re-registration REGISTER request with a new contact at the
request triggered by the push notification request, will convey pn- same time the registrar forwards a SIP request towards a UA using the
URI parameters associated with the SIP registration, those can be previously registered contact in the Request-URI.
used to match the SIP request with the re-registration REGISTER
request (even if the most recent contact and the Request-URI of the As both the SIP request to be forwarded towards the UA, and the re-
SIP request do not match). registration REGISTER request triggered by the push notification
request, will convey pn- SIP URI parameters associated with the SIP
registration, those can be used to match the SIP request with the re-
registration REGISTER request (even if the most recent contact and
the Request-URI of the SIP request do not match).
NOTE: If the proxy is not the registrar, it needs to store (or be NOTE: If the proxy is not the registrar, it needs to store (or be
able to retrieve) the contact of the most recent REGISTER 2xx able to retrieve) the contact of the most recent REGISTER 2xx
response, to be able to compare it with the Request-URI of the response, to be able to compare it with the Request-URI of the
request to be forwarded towards the UA. request to be forwarded towards the UA.
In case of non-2xx response to the REGISTER request, the proxy MUST In case of non-2xx response to the REGISTER request, the proxy MUST
reject the SIP request with a 404 (Not Found) response. reject the SIP request with a 404 (Not Found) response.
If the push notification request fails (see PNS-specific If the push notification request fails (see PNS-specific
skipping to change at page 12, line 26 skipping to change at page 13, line 35
The proxy MUST NOT include the SIP request as payload in the The proxy MUST NOT include the SIP request as payload in the
requested push message. requested push message.
If the proxy has knowledge that the UA is awake, and that the UA is 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 able to receive the SIP request without first sending a REGISTER
request, the proxy MAY choose to not request a push notification request, the proxy MAY choose to not request a push notification
towards the UA (and wait for the associated REGISTER request and 2xx towards the UA (and wait for the associated REGISTER request and 2xx
response) before it tries to forward the SIP request towards the UA. response) before it tries to forward the SIP request towards the UA.
The mechanisms for getting such knowledge might be dependent on The mechanisms for getting such knowledge might be dependent on
implementation or deployment architecture, and are outside the scope implementation or deployment architecture, and are outside the scope
of this document. of this document. Similarly, if the Request-URI of the SIP request
only contains any pn-provider SIP URI parameter, but no other pn- SIP
6. Network Address Translator (NAT) Considerations URI parameters, e.g., because the SIP UA has not included them in a
REGISTER request (Section 4.2), the proxy is not able to request a
Whenever the SIP UA receives a push notification, if the UA is push notification towards the UA. If the proxy has knowledge that
located behind a Network Address Translator (NAT), the UA might need the UA is awake, and that the UA is able to receive the SIP request,
to take actions in order to establish a binding in the NAT, in order the proxy MAY forwards the request towards the UA. Otherwise the
for an incoming SIP request to reach the UA. By sending the re- proxy MUST reject the SIP request with a 556 (Push Notification
registration SIP REQUEST the UA will establish such a NAT binding. Failed) response.
If the UA and the SIP proxy are operating in an environment where one
or more NATs might be located between the UA and the proxy, when the
proxy receives a REGISTER request from the UA it can store the IP
address and port information from where it received the request.
Then, when the proxy forwards a SIP request towards the UA, it uses
that IP address and port, instead of the IP address and port
associated with the Request-URI of the request. If the REGISTER
request created one or more NAT bindings, this will ensure that the
SIP request reaches the UA.
7. Grammar 6. Grammar
7.1. 555 (Push Notification Service Not Supported) Response Code 6.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 identified in a 'pn-provider' SIP URI parameter. service identified in a 'pn-provider' SIP URI parameter.
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. responses.
7.2. 556 (Push Notification Failed) Response Code 6.2. 556 (Push Notification Failed) Response Code
The 556 response code is added to the "Server-Error" Status-Code The 556 response code is added to the "Server-Error" Status-Code
definition. 556 (Push Notification Failed) is used to indicate that definition. 556 (Push Notification Failed) is used to indicate that
the server failed to request a push notification from the push the server failed to request a push notification from the push
notification service identified in a 'pn-provider' SIP URI parameter. notification service identified in a 'pn-provider' SIP URI parameter.
The use of the SIP 556 response code is defined for responses to SIP The use of the SIP 556 response code is defined for responses to SIP
requests initiating dialogs, and responses to stand-alone SIP requests initiating dialogs, and responses to stand-alone SIP
requests. requests.
7.3. sip.pns Feature-Capability Indicator 6.3. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator, when included in a Feature- The sip.pns feature-capability indicator, when included in a Feature-
Caps header field of a SIP REGISTER request or a SIP 2xx response to Caps header field of a SIP REGISTER request or a SIP 2xx response to
a REGISTER request, indicates that the entity associated with the a REGISTER request, indicates that the entity associated with the
indicator supports, and will use, the SIP push mechanism and the push indicator supports, and will use, the SIP push mechanism and the push
notification service identified by the indicator value. When notification service identified by the indicator value. When
included in a 555 (Push Notification Service Not Supported) response included in a 555 (Push Notification Service Not Supported) response
to a REGISTER request, the the indicator indicates that the entity to a REGISTER request, the the indicator indicates that the entity
associated with the indicator supports the SIP push mechanism, and associated with the indicator supports the SIP push mechanism, and
the push notification service(s) identified by the indicator value. the push notification service(s) identified by the indicator value.
The values defined for the pn-provider SIP URI parameter are used as The values defined for the pn-provider SIP URI parameter are used as
indicator values. indicator values.
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
7.4. sip.vapid Feature-Capability Indicator 6.4. sip.vapid Feature-Capability Indicator
The sip.vapid feature-capability indicator, when included in a SIP The sip.vapid feature-capability indicator, when included in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, indicates that the entity
associated with the indicator supports, and will use, the Voluntary associated with the indicator supports, and will use, the Voluntary
Application Server Identification (VAPID) [RFC8292] mechanism when Application Server Identification (VAPID) [RFC8292] mechanism when
requesting push notifications towards the SIP UA associated with the requesting push notifications towards the SIP UA associated with the
SIP registration. The indicator value is a public key identifying SIP registration. The indicator value is a public key identifying
the entity, that can be used by a SIP UA to restrict subscriptions to the entity, that can be used by a SIP UA to restrict subscriptions to
that entity. that entity.
vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT
vapid = tag-value vapid = tag-value
; tag-value as defined in RFC 3840 ; tag-value as defined in RFC 3840
7.5. sip.pnsreg Feature-Capability Indicator 6.5. sip.pnsreg Feature-Capability Indicator
The sip.pnsreg feature-capability indicator, when included in a SIP The sip.pnsreg feature-capability indicator, when included in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, indicates that the entity
associated with the indicator expects to receive re-registration associated with the indicator expects to receive re-registration
REGISTER requests from the SIP UA associated with the registration REGISTER requests from the SIP UA associated with the registration
before the registration expires, without the entity having to request before the registration expires, without the entity having to request
push notifications towards the SIP UA in order to trigger the push notifications towards the SIP UA in order to trigger the
REGISTER requests. The indicator value is the minimum value (given REGISTER requests. The indicator value is the minimum value (given
in seconds) before the registration expireation when the entity in seconds) before the registration expiration when the entity
expects to receive the REGISTER request. expects to receive the REGISTER request.
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT reg = 1*DIGIT
; DIGIT as defined in RFC 3261 ; DIGIT as defined in RFC 3261
7.6. sip.pnsreg Media Feature Tag 6.6. sip.pnsreg Media Feature Tag
The sip.pnsreg media feature tag, when included in the SIP Contact The sip.pnsreg media feature tag, when included in the SIP Contact
header field of a SIP REGISTER request, indciates that the SIP UA header field of a SIP REGISTER request, indicates that the SIP UA
associated with the tag is able to send re-registration REGISTER associated with the tag is able to send re-registration REGISTER
requests associated with the registration without being awaken by requests associated with the registration without being awaken by
push notifications. The media feature tag has no values. push notifications. The media feature tag has no values.
pns-mt = "+sip.pnsreg" pnsreg-mt = "+sip.pnsreg"
7.7. SIP URI Parameters 6.7. 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 uri-parameter =/ pn-provider / pn-param / pn-prid
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
; 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 pn-prid and pn-param are The format and semantics of pn-prid and pn-param are
specific to the pn-provider value. specific to the pn-provider value.
Parameter value chapters that are not part of pvalue needs to be Parameter value chapters that are not part of pvalue needs to be
escaped, as defined in RFC 3261. escaped, as defined in RFC 3261.
8. PNS Registration Requirements 7. 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.
9. pn-provider, pn-param and pn-prid URI Parameters for Apple Push 8. 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
The value of the pn-param URI parameter is the APNs App ID, which is The value of the pn-param URI parameter is the APNs App ID, which is
skipping to change at page 16, line 27 skipping to change at page 17, line 27
https://developer.apple.com/library/content/documentation/General/ https://developer.apple.com/library/content/documentation/General/
Conceptual/DevPedia-CocoaCore/AppID.html Conceptual/DevPedia-CocoaCore/AppID.html
For more information on the APNs device token: For more information on the APNs device token:
https://developer.apple.com/library/content/documentation/NetworkingI https://developer.apple.com/library/content/documentation/NetworkingI
nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re
f/doc/uid/TP40008194-CH8-SW13 f/doc/uid/TP40008194-CH8-SW13
10. pn-provider, pn-param and pn-prid URI Parameters for Google 9. pn-provider, pn-param and pn-prid URI Parameters for Google Firebase
Firebase Cloud Messaging (FCM) push notification service Cloud Messaging (FCM) push notification service
When Firebase Cloud Messaging (FCM) is used, the PNS related URI When Firebase Cloud Messaging (FCM) is used, the PNS related URI
parameters are set as described below. parameters are set as described below.
The value of the pn-provider URI parameter is "fcm". The value of the pn-provider URI parameter is "fcm".
The value of the pn-param URI parameter is the Project ID. The value of the pn-param URI parameter is the Project ID.
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 Project ID and Registration token: For more information on the Project ID and Registration token:
https://firebase.google.com/docs/cloud-messaging/concept-options https://firebase.google.com/docs/cloud-messaging/concept-options
11. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 10. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
(Generic Event Delivery Using HTTP Push) (Generic Event Delivery Using HTTP Push)
When Firebase Cloud Messaging (FCM) is used, the PNS related URI When Generic Event Delivery Using HTTP Push is used, the PNS related
parameters are set as described below. URI parameters are set as described below.
The value of the pn-provider URI parameter is "webpush". The value of the pn-provider URI parameter is "webpush".
The value of the pn-param URI parameter MUST NOT be used. The value of the pn-param URI parameter MUST NOT be used.
The value of the pn-prid URI parameter is the push URI. The value of the pn-prid URI parameter is the push subscription URI.
See RFC 8030 for more details: See RFC 8030 for more details:
https://tools.ietf.org/html/rfc8030
Note that encryption for web push [RFC8291] is not used, therefore Note that encryption for web push [RFC8291] is not used, therefore
parameters for message encryption are not defined in this parameters for message encryption are not defined in this
specification. Web push permits the sending of a push message specification. Web push permits the sending of a push message
without a payload without encryption. without a payload without encryption.
12. Security Considerations 11. Security Considerations
Different mechanisms exist for authenticating and authorizing devices Different mechanisms exist for authenticating and authorizing devices
and users registering with a PNS. The mechanisms for authorizing and and users registering with a PNS. The mechanisms for authorizing and
authenticating the users are PNS-specific, and are outside the scope authenticating the users are PNS-specific, and are outside the scope
of this document. In addition to the information that needs to be 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 exchanged between a device and the PNS in order to establish a push
notification subscription, the mechanism defined in this document notification subscription, the mechanism defined in this document
does not require any additional information to be exchanged between does not require any additional information to be exchanged between
the device and the PNS. the device and the PNS.
skipping to change at page 18, line 5 skipping to change at page 18, line 48
[RFC8292] defines a mechanism which allows a proxy to create a [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 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 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 can be used by devices to restrict push notifications to the proxy
associated with the key. associated with the key.
The mechanism in this document does not require a proxy to include The mechanism in this document does not require a proxy to include
any payload (in addition to possible payload used for the PNS itself) any payload (in addition to possible payload used for the PNS itself)
when requesting push notifications. when requesting push notifications.
13. IANA considerations 12. IANA considerations
12.1. SIP URI Parameters
13.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.
13.1.1. pn-provider 12.1.1. pn-provider
Parameter Name: pn-provider Parameter Name: pn-provider
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
13.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
13.1.3. pn-prid 12.1.3. pn-prid
Parameter Name: pn-prid Parameter Name: pn-prid
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
13.2. SIP Response Codes 12.2. SIP Response Codes
13.2.1. 555 (Push Notification Service Not Supported) 12.2.1. 555 (Push Notification Service Not Supported)
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
13.2.2. 556 (Push Notification Failed) 12.2.2. 556 (Push Notification Failed)
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: 556 Response Code Number: 556
Default Reason Phrase: Push Notififcation Failed Default Reason Phrase: Push Notififcation Failed
13.3. SIP Global Feature-Capability Indicator 12.3. SIP Global Feature-Capability Indicator
13.3.1. sip.pns 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 SIP REGISTER request or a SIP 2xx Feature-Caps header field of a SIP REGISTER request or a SIP 2xx
skipping to change at page 20, line 5 skipping to change at page 21, line 5
the indicator value. When included in a 555 (Push Notification the indicator value. When included in a 555 (Push Notification
Service Not Supported) response to a REGISTER request, the the Service Not Supported) response to a REGISTER request, the the
indicator indicates that the entity associated with the indicator indicates that the entity associated with the
indicator supports the SIP push mechanism, and the push indicator supports the SIP push mechanism, and the push
notification service(s) identified by the indicator value. notification service(s) identified by the indicator value.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
13.3.2. sip.vapid 12.3.2. sip.vapid
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.vapid Name: sip.vapid
Description: This feature-capability indicator, when included in a Description: This feature-capability indicator, when included in a
SIP 2xx response to a SIP REGISTER request, indicates that the SIP 2xx response to a SIP REGISTER request, indicates that the
skipping to change at page 20, line 27 skipping to change at page 21, line 27
the Voluntary Application Server Identification (VAPID) the Voluntary Application Server Identification (VAPID)
mechanism when requesting push notifications towards the SIP UA mechanism when requesting push notifications towards the SIP UA
associated with the SIP registration. The indicator value is a associated with the SIP registration. The indicator value is a
public key identifying the entity, that can be used by a SIP UA public key identifying the entity, that can be used by a SIP UA
to restrict subscriptions to that entity. to restrict subscriptions to that entity.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
13.3.3. sip.pnsreg 12.3.3. sip.pnsreg
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.pnsreg Name: sip.pnsreg
Description: This feature-capability indicator, when included in a Description: This feature-capability indicator, when included in a
SIP 2xx response to a SIP REGISTER request, indicates that the SIP 2xx response to a SIP REGISTER request, indicates that the
skipping to change at page 21, line 22 skipping to change at page 22, line 22
the entity having to request push notifications towards the SIP the entity having to request push notifications towards the SIP
UA in order to trigger the REGISTER requests. The indicator UA in order to trigger the REGISTER requests. The indicator
value is the minimum value (given in seconds) before the value is the minimum value (given in seconds) before the
registration expireation when the entity expects to receive the registration expireation when the entity expects to receive the
REGISTER request. REGISTER request.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
13.4. SIP Media Feature Tag 12.4. SIP Media Feature Tag
13.4.1. sip.pnsreg 12.4.1. sip.pnsreg
This section defines a new media feature tag that extends the "SIP This section defines a new media feature tag that extends the "SIP
Media Feature Tag Registration Tree" sub-registry [RFC3840] under the Media Feature Tag Registration Tree" sub-registry [RFC3840] under the
Media Feature Tag registry: https://www.iana.org/assignments/media- Media Feature Tag registry: https://www.iana.org/assignments/media-
feature-tags/media-feature-tags.xhtml. feature-tags/media-feature-tags.xhtml.
Media feature tag name: sip.pnsreg Media feature tag name: sip.pnsreg
Summary of the media feature indicated by this feature tag: This Summary of the media feature indicated by this feature tag: This
media feature tag, when included in the SIP Contact header media feature tag, when included in the SIP Contact header
field of a SIP REGISTER request, indciates that the SIP UA field of a SIP REGISTER request, indicates that the SIP UA
associated with the tag is able to send re-registration associated with the tag is able to send re-registration
REGISTER requests associated with the registration without REGISTER requests associated with the registration without
being awaken by push notifications. being awaken by push notifications.
Values appropriate for use with this feature tag: none Values appropriate for use with this feature tag: none
Related standards or documents: [RFCXXXX] Related standards or documents: [RFCXXXX]
Security considerations: This media feature tag does not introduce Security considerations: This media feature tag does not introduce
new security considerations, as it simply indicates support for new security considerations, as it simply indicates support for
a basic SIP feature. If an attacker manages to remove the media a basic SIP feature. If an attacker manages to remove the media
feature tag, push notifications towards the client will be feature tag, push notifications towards the client will be
requested. requested.
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
13.5. PNS Sub-registry Establishment 12.5. 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, When a SIP URI pn-provider value is registered in the sub-registry,
it needs to meet the "Expert Review" policies defined in [RFC8126]. it needs to meet the "Expert Review" policies defined in [RFC8126].
skipping to change at page 23, line 13 skipping to change at page 24, line 13
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]
webpush Generic Event Delivery Using HTTP Push [RFC XXXX] webpush Generic Event Delivery Using HTTP Push [RFC XXXX]
14. 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, Kari-Pekka Perttula, Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula,
Liviu Chircu, Roman Shpount and Yehoshua Gev for reading the text, Liviu Chircu, Roman Shpount and Yehoshua Gev for reading the text,
and providing useful feedback. and providing useful feedback.
15. References 14. References
15.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>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
skipping to change at page 24, line 21 skipping to change at page 25, line 21
[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 [RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server
Identification (VAPID) for Web Push", RFC 8292, Identification (VAPID) for Web Push", RFC 8292,
DOI 10.17487/RFC8292, November 2017, <https://www.rfc- DOI 10.17487/RFC8292, November 2017, <https://www.rfc-
editor.org/info/rfc8292>. editor.org/info/rfc8292>.
15.2. Informative References 14.2. Informative References
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session "Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, <https://www.rfc- DOI 10.17487/RFC5626, October 2009, <https://www.rfc-
editor.org/info/rfc5626>. editor.org/info/rfc5626>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
 End of changes. 65 change blocks. 
237 lines changed or deleted 280 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/