draft-ietf-sipcore-sip-push-25.txt   draft-ietf-sipcore-sip-push-26.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: August 9, 2019 Metaswitch Networks Expires: August 28, 2019 Metaswitch Networks
February 5, 2019 February 24, 2019
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-25 draft-ietf-sipcore-sip-push-26
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 wake suspended Session Initiation Protocol (SIP) User Agents used to wake a suspended Session Initiation Protocol (SIP) User Agent
(UAs), using push notifications, for the UA to be able to send (UA) with push notifications, and also describes how the UA can send
binding-refresh REGISTER requests and to receive incoming SIP binding-refresh REGISTER requests and receive incoming SIP requests
requests. The document defines new SIP URI parameters and new in an environment in which the UA may be suspended. The document
feature-capability indicators that can be used in SIP messages to defines new SIP URI parameters to exchange PNS information between
indicate support of the mechanism defined in this document, to the UA and the SIP entity that will then request that push
exchange PNS information between the SIP User Agent (UA) and the SIP notifications be sent to the UA, and to trigger such push
entity that will request that push notifications are sent to the UA, notification requests. The document also defines new feature-
and to trigger such push notification requests. capability indicators that can be used to indicate support of this
mechanism.
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 August 9, 2019. This Internet-Draft will expire on August 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 36 skipping to change at page 2, line 37
5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 12 5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 12
5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 13 5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 13
5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 13 5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 13
5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 13 5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 13
5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 14 5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 14
5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 14 5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 14
5.6.2. Initial Request for Dialog or Stand-Alone Request . . 17 5.6.2. Initial Request for Dialog or Stand-Alone Request . . 17
6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 20 6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 20
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 22 6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 22
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 22 6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 22
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 23 6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 22
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 23 6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 23
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 23 6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 23
6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 24 6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 23
7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 24 7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 24
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. 555 (Push Notification Service Not Supported) Response 8.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 25 8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 25
8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 26 8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 26
8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 26 8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 26
8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 27 8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 26
8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 27 8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 27
8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 27 8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 27
9. PNS Registration Requirements . . . . . . . . . . . . . . . . 28 9. PNS Registration Requirements . . . . . . . . . . . . . . . . 27
10. pn-provider, pn-param and pn-prid URI Parameters for Apple 10. pn-provider, pn-param and pn-prid URI Parameters for Apple
Push Notification service . . . . . . . . . . . . . . . . . . 28 Push Notification service . . . . . . . . . . . . . . . . . . 28
11. pn-provider, pn-param and pn-prid URI Parameters for Google 11. pn-provider, pn-param and pn-prid URI Parameters for Google
Firebase Cloud Messaging (FCM) push notification service . . 29 Firebase Cloud Messaging (FCM) push notification service . . 29
12. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 12. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
(Generic Event Delivery Using HTTP Push) . . . . . . . . . . 29 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30
14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 31 14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 31
14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 31 14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 31
14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 31 14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 31
14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 32 14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 31
14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 32 14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 31
14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 32 14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 32
14.2.1. 555 (Push Notification Service Not Supported) . . . 32 14.2.1. 555 (Push Notification Service Not Supported) . . . 32
14.3. SIP Global Feature-Capability Indicator . . . . . . . . 32 14.3. SIP Global Feature-Capability Indicator . . . . . . . . 32
14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 32 14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 32
14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 33 14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 33
14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 33 14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 33
14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 34 14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 34
14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 35 14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 35
14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 35 14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 35
14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 35 14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 35
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . 38 16.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
In order to save resources (e.g., battery life) some devices In order to save resources such as battery life, some devices
(especially mobile devices) and operating systems will suspend (especially mobile devices) and operating systems will suspend an
applications when not used. In some cases, internal timers cannot be application that is not in use. A suspended application might not be
used to wake such applications, nor will incoming network traffic able to wake itself with internal timers and might not be awakened by
wake the application. Instead, one way to wake the application is by incoming network traffic. In such an environment, a Push
using a Push Notification Service (PNS). A PNS is a service from Notification Service (PNS) is used to wake the application. A PNS is
where a user application can receive messages, referred to as push a service that sends messages requested by other applications to a
notifications, requested by other applications. Push notifications user application in order to wake the user application. These
might contain payload data, depending on the application. An messages are called push notifications. Push notifications might
application can request that a push notification is sent to a single contain payload data, depending on the application. An application
user application, or to multiple user applications. can request that a push notification is sent to a single user
application or to multiple user applications.
Typically each operating system uses a dedicated PNS. For example,
Apple iOS devices use the Apple Push Notification service (APNs)
while Android devices use the Firebase Cloud Messaging (FCM) service.
Because of the restrictions above, Session Initiation Protocol (SIP) Typically each operating system uses a dedicated PNS. Different PNSs
User Agents (UAs) [RFC3261] can not be awoken, in order to send exist today. Some are based on the standardized mechanism defined in
binding-refresh SIP REGISTER requests and to receive incoming SIP [RFC8030], while others are proprietary. For example, Apple iOS
requests, without using a PNS to wake the UA in order to perform devices use the Apple Push Notification service (APNs) while Android
those functions. devices use the Firebase Cloud Messaging (FCM) service. Each PNS
uses PNS-specific terminology and function names. The terminology in
this document is meant to be PNS-independent. If the PNS is based on
[RFC8030], the SIP proxy takes the role of the application server.
Also, without being able to use internal timers in order to wake When a Session Initiation Protocol (SIP) User Agent (UA)[RFC3261] is
applications, a UA will not be able to maintain connections e.g., suspended in such an environment, it is unable to send binding-
using the SIP Outbound Mechanism [RFC5626], as it requires the UA to refresh SIP REGISTER requests, unable to receive incoming SIP
send periodic keep-alive messages. requests, and might not be able to use internal timers to wake
itself. A suspended UA will not be able to maintain connections
e.g., using the SIP Outbound Mechanism [RFC5626] because it cannot
send periodic keep-alive messages. A PNS is needed to wake the SIP
UA so that the UA can perform these functions.
This document describes how PNSs can be used to wake suspended UAs, This document describes how a PNS can be used to wake a suspended UA,
using push notifications, to be able to send binding-refresh REGISTER using push notifications, so that the UA can be able to send binding-
requests and to receive incoming SIP requests. The document defines refresh REGISTER requests and to receive incoming SIP requests. The
new SIP URI parameters and new feature-capability indicators document defines new SIP URI parameters and new feature-capability
[RFC6809] that can be used in SIP messages to indicate support of the indicators [RFC6809] that can be used in SIP messages to indicate
mechanism defined in this document, to exchange PNS information support of the mechanism defined in this document, to exchange PNS
between the UA and the SIP entity (realized as a SIP proxy in this information between the UA and the SIP entity (realized as a SIP
document) that will request that push notifications are sent to the proxy in this document) that will request that push notifications are
UA, and to request such push notification requests. sent to the UA, and to request such push notification requests.
NOTE: Even if a UA is able to be awakened by other means than NOTE: Even if a UA is able to be awakened by means other than
receiving push notifications (e.g., by using internal timers) in receiving push notifications (e.g., by using internal timers) in
order to send periodic binding-refresh REGISTER requests, it might order to send periodic binding-refresh REGISTER requests, it might
still be useful to suspend the application between the sending of still be useful to suspend the UA between the sending of binding-
binding-refresh requests (as it will save battery life) and use push refresh requests (as it will save battery life) and use push
notifications to wake the UA when an incoming SIP request UA arrives. notifications to wake the UA when an incoming SIP request UA arrives.
When a UA registers to a PNS, it will receive a unique Push Resource When a UA registers with a PNS (Figure 1), it will receive a unique
ID (PRID) associated with the push notification registration. The UA Push Resource ID (PRID) associated with the push notification
will use a REGISTER request to provide the PRID to the SIP proxy that registration. The UA will use a REGISTER request to provide the PRID
will request push that notifications are sent to the UA. to the SIP proxy, which will then request that push notifications are
sent to the UA.
When the proxy receives a SIP request for a new dialog or a stand- When the SIP proxy receives a SIP request for a new dialog or a
alone SIP request addressed towards a UA, or when the proxy stand-alone SIP request addressed towards a UA, or when the SIP proxy
determines that the UA needs to send a binding-refresh REGISTER determines that the UA needs to send a binding-refresh REGISTER
request, the proxy will request that a push notification is sent to request, the SIP proxy will send a push request containing the PRID
the UA, using the PNS of the UA. Once the UA receives the push of the UA to the PNS, which will then send a push notification to the
notification, it will be able to send a binding-refresh REGISTER UA. Once the UA receives the push notification, it will be able to
request and receive the incoming SIP request. The proxy will receive send a binding-refresh REGISTER request. The proxy receives the
the REGISTER request. If the push notification request was triggered REGISTER request from the UA and forwards it to the SIP registrar
by a SIP request addressed towards the UA (see above), once the [RFC3261]. After accepting the REGISTER request, the SIP registrar
REGISTER request has been accepted by the SIP registrar [RFC3261], sends a 2xx response to the proxy, which forwards the response to the
and the associated SIP 2xx response has been forwarded by the proxy UA. If the push notification request was triggered by a SIP request
towards the UA, the proxy can forward the SIP request towards the UA addressed towards the UA, the proxy can then forward the SIP request
using normal SIP routing procedures. In some cases the proxy can to the UA using normal SIP routing procedures. In some cases the
forward the SIP request without waiting for the SIP 2xx response to proxy can forward the SIP request without waiting for the SIP 2xx
the REGISTER request. Note that this mechanism necessarily adds response to the REGISTER request from the SIP registrar. Note that
delay to responding to requests requiring push notification. The this mechanism necessarily adds delay to responding to requests
consequences of that delay are discussed in Section 5.6.2. requiring push notification. The consequences of that delay are
discussed in Section 5.6.2.
If there are Network Address Translators (NATs) between the UA and If there are Network Address Translators (NATs) between the UA and
the proxy, the REGISTER request sent by the UA will create NAT the proxy, the REGISTER request sent by the UA will create NAT
bindings that will allow the incoming SIP request that triggered the bindings that will allow the incoming SIP request that triggered the
push notification to reach the UA. push notification to reach the UA.
NOTE: The lifetime of any NAT binding created by the REGISTER request NOTE: The lifetime of any NAT binding created by the REGISTER request
only needs to be long enough in order for the SIP request that only needs to be long enough in order for the SIP request that
triggered the push notification to reach the UA. triggered the push notification to reach the UA.
Different PNSs exist today. Some are based on the standardized Figure 1 shows the generic push notification architecture supported
mechanism defined in [RFC8030], while others are proprietary (e.g., by the mechanism in this document.
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.
The proxy MUST be in the signalling path of REGISTER requests sent by The SIP proxy MUST be in the signalling path of REGISTER requests
the UA towards the registrar, and of SIP requests (for a new dialog sent by the UA towards the registrar, and of SIP requests (for a new
or a stand-alone) forwarded by the proxy responsible for the UA's dialog or a stand-alone) forwarded by the proxy responsible for the
domain (sometimes referred to as home proxy, S-CSCF, etc) towards the UA's domain (sometimes referred to as home proxy, S-CSCF, etc.)
UA. The proxy can also be co-located with the proxy responsible for towards the UA. The proxy can also be co-located with the proxy
the UA's domain. This will also ensure that the Request-URI of SIP responsible for the UA's domain. This will also ensure that the
requests (for a new dialog or a stand-alone) can be matched against Request-URI of SIP requests (for a new dialog or a stand-alone) can
contacts in REGISTER requests. be matched against contacts in REGISTER requests.
+--------+ +---------+ +-----------+ +-------------+ +--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP | | | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / | | SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy | | | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+ +--------+ +---------+ +-----------+ +-------------+
| | | | | | | |
| Subscribe | | | | Subscribe | | |
|---------------->| | | |---------------->| | |
| | | | | | | |
skipping to change at page 7, line 50 skipping to change at page 7, line 50
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. REGISTER 4.1. REGISTER
This section describes how a SIP UA sends SIP REGISTER requests This section describes how a SIP UA sends SIP REGISTER requests
(initial REGISTER request for a binding, or a binding-refresh (either an initial REGISTER request for a binding or a binding-
REGISTER request) in order to request and disable push notifications refresh REGISTER request) in order to request and disable push
from a SIP network, and to query the types of PNSs supported by the notifications from a SIP network, and to query the types of PNSs
SIP network. supported by the SIP network.
Unless specified otherwise, the normal SIP UA registration procedures Unless specified otherwise, the normal SIP UA registration procedures
[RFC3261] apply. The additional procedures described in this section [RFC3261] apply. The additional procedures described in this section
apply when the REGISTER request contains a pn-provider SIP URI apply when the REGISTER request contains a pn-provider SIP URI
parameter in the Contact header field URI of the request. parameter in the Contact header field URI (Figure 2).
The procedures in this section apply to individual bindings The procedures in this section apply to individual bindings
[RFC3261]. If a UA creates multiple bindings (e.g., one for IPv4 and [RFC3261]. If a UA creates multiple bindings (e.g., one for IPv4 and
one for IPv6) the UA needs to perform the procedures for each one for IPv6) the UA needs to perform the procedures for each
binding. binding.
NOTE: If a SIP UA creates multiple bindings, since a push NOTE: Since a push notification will trigger the UA to refresh all
notification will trigger the UA to refresh all bindings, it is bindings, if a SIP UA has created multiple bindings, it is preferable
preferable if one can ensure that all bindings expire at the same if one can ensure that all bindings expire at the same time to help
time. That will help preventing that some bindings are refreshed prevent some bindings from being refreshed earlier than needed.
earlier than needed.
For privacy and security reasons, a UA MUST NOT insert the SIP URI For privacy and security reasons, a UA MUST NOT insert the SIP URI
parameters (except for the pn-purr parameter) defined in this parameters (except for the pn-purr parameter) defined in this
specification in non-REGISTER request, to prevent the PNS information specification in non-REGISTER request in order to prevent the PNS
associated with the UA from reaching the remote peer. For example, information associated with the UA from reaching the remote peer.
the UA MUST NOT insert the pn-prid SIP URI parameter in the Contact For example, the UA MUST NOT insert the pn-prid SIP URI parameter in
header field URI of an INVITE request. REGISTER requests will not the Contact header field URI of an INVITE request. REGISTER requests
reach the remote peer, as they will be terminated by the registrar of will not reach the remote peer, as they will be terminated by the
the UA. However, the registrar MUST still ensure that the parameters registrar of the UA. However, the registrar MUST still ensure that
are not sent to other users, e.g., using the SIP event package for the parameters are not sent to other users, e.g., using the SIP event
registrations mechanism [RFC3680]. See Section 13 for more package for registrations mechanism [RFC3680]. See Section 13 for
information. more information.
4.1.1. Request Push Notifications 4.1.1. Request Push Notifications
This section describes the procedures when a SIP UA requests push This section describes the procedures that a SIP UA follows to
notifications from the SIP network. The procedures assume that the request push notifications from the SIP network. The procedures
UA has retrieved a PRID from a PNS. The procedures how the UA assume that the UA has retrieved a PRID from a PNS. The procedures
retrieves the PRID from the PNS are PNS-specific, and outside the for retrieving the PRID from the PNS are PNS-specific and outside the
scope of this specification. See PNS specific documentation for more scope of this specification. See PNS-specific documentation for more
details. details.
If a SIP UA wants to use push notifications for other usages than to This specification does not define a mechanism to explicitly request
trigger binding-refresh REGISTER requests (e.g., for sending periodic push notifications from the SIP network for usages other than
subscription-refresh SUBSCRIBE requests [RFC6665]), this triggering binding-refresh REGISTER requests (e.g., for sending
specification does not define a mechanism to explicitly request push periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does
notifications from the SIP network for such usages, and how to it describe how to distinguish push notifications associated with
distinguish push notifications associated with such usages from the such usages from the push notifications used to trigger binding-
push notifications used to trigger binding-refresh REGISTER requests. refresh REGISTER requests. If a SIP UA wants to use push
However, by using the same refresh interval that is used for the notifications for other usages, the UA can perform actions associated
binding-refreshes, the UA can perform actions associated with such with such usages (in addition to sending a binding-refresh REGISTER
usages (in addition to sending a binding-refresh REGISTER request) request) whenever it receives a push notification by using the same
whenever it receives a push notification. refresh interval that is used for the binding-refreshes.
When a UA requests push notifications, the UA MUST insert the To request push notifications from the SIP network, the UA MUST
following SIP URI parameters in the SIP Contact header field URI of insert the following SIP URI parameters in the SIP Contact header
the REGISTER request: pn-provider, pn-prid and pn-param (if required field URI of the REGISTER request: pn-provider, pn-prid and pn-param
for the specific PNS). The pn-provider URI parameter parameter (if required for the specific PNS). The pn-provider URI parameter
indicates the type of PNS to be used for the push notifications. indicates the type of PNS to be used for the push notifications.
If the UA receives a 2xx response to the REGISTER request that If the UA receives a 2xx response to the REGISTER request that
contains a Feature-Caps header field [RFC6809] with a 'sip.pns' contains a Feature-Caps header field [RFC6809] with a 'sip.pns'
feature-capability indicator, with an indicator value identifying the feature-capability indicator, with an indicator value identifying the
same type of PNS that was identified by the pn-provider URI parameter same type of PNS that was identified by the pn-provider URI parameter
in the REGISTER request, it indicates that a SIP Proxy in the SIP in the REGISTER request, it indicates that a SIP Proxy in the SIP
network will request that push notifications are sent to the UA. In network will request that push notifications are sent to the UA. In
addition, if the same Feature-Caps header field contains a addition, if the same Feature-Caps header field contains a
'sip.vapid' feature-capability indicator, it indicates that the proxy 'sip.vapid' feature-capability indicator, it indicates that the proxy
supports use of the Voluntary Application Server Identification supports use of the Voluntary Application Server Identification
(VAPID) mechanism [RFC8292] to restrict push notifications to the UA. (VAPID) mechanism [RFC8292] to restrict push notifications to the UA.
NOTE: The VAPID specific procedures of the SIP UA are outside the NOTE: The VAPID specific procedures of the SIP UA are outside the
scope of this document. scope of this document.
If the UA receives a non-2xx response to the REGISTER, or if the UA If the UA receives a non-2xx response to the REGISTER, or if the UA
receives a 2xx response that does not contain a Feature-Caps header receives a 2xx response that does not contain a Feature-Caps header
field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA
MUST NOT assume a the proxy will request that push notifications are MUST NOT assume the proxy will request that push notifications are
sent to the UA. The actions taken by the UA in such cases are sent to the UA. The actions taken by the UA in such cases are
outside the scope of this document. outside the scope of this document.
If the PRID is only valid for a limited time then the UA is If the PRID is only valid for a limited time then the UA is
responsible for retrieving a new PRID from the PNS and sending a responsible for retrieving a new PRID from the PNS and sending a
binding-refresh REGISTER request with the updated pn- parameters. If binding-refresh REGISTER request with the updated pn- parameters. If
a PRID is no longer valid, and the UA is not able to retrieve a new a PRID is no longer valid, and the UA is not able to retrieve a new
PRID, the UA MUST disable the push notifications associated with the PRID, the UA MUST disable the push notifications associated with the
PRID (Section 4.1.2). PRID (Section 4.1.2).
skipping to change at page 10, line 20 skipping to change at page 10, line 18
refresh REGISTER request. The UA MUST insert the same set of pn- SIP refresh REGISTER request. The UA MUST insert the same set of pn- SIP
URI parameters in the SIP Contact header field URI of the REGISTER URI parameters in the SIP Contact header field URI of the REGISTER
request that it inserted when it requested push notifications request that it inserted when it requested push notifications
(Section 4.1.1). Note that, in some cases the PNS might update the (Section 4.1.1). Note that, in some cases the PNS might update the
PRID value, in which case the UA will insert the new value in the pn- PRID value, in which case the UA will insert the new value in the pn-
prid SIP URI parameter of the binding-refresh REGISTER request. prid SIP URI parameter of the binding-refresh REGISTER request.
Once the UA has received a 2xx response to the REGISTER request, the 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), 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 or a stand-alone SIP request (e.g., a SIP MESSAGE), if such SIP
request has triggered a proxy to request that the push notification request triggered the proxy to request that the push notification was
is sent to the UA.. Note that, depending on which transport protocol sent to the UA. Note that, depending on which transport protocol is
is used, the SIP request might reach the UA before the REGISTER used, the SIP request might reach the UA before the REGISTER
response. response.
If the SIP UA has created multiple bindings, the UA MUST send a If the SIP UA has created multiple bindings, the UA MUST send a
binding-refresh REGISTER request for each of those bindings when it binding-refresh REGISTER request for each of those bindings when it
receives a push notification. receives a push notification.
This specification does not define any usage of push notification This specification does not define any usage of push notification
payload. If a SIP UA receives a push notification that contains a payload. If a SIP UA receives a push notification that contains a
payload the UA can discard the payload, but the UA will still send a payload the UA can discard the payload, but the UA will still send a
binding-refresh REGISTER request. binding-refresh REGISTER request.
skipping to change at page 11, line 14 skipping to change at page 11, line 12
is able to use a non-push mechanism for sending binding-refresh is able to use a non-push mechanism for sending binding-refresh
REGISTER requests), or when there are circumstances (e.g., if the UA REGISTER requests), or when there are circumstances (e.g., if the UA
is assigned new contact parameters due to a network configuration is assigned new contact parameters due to a network configuration
change) that require an immediate REGISTER request to be sent. change) that require an immediate REGISTER request to be sent.
Even if the UA is able to to send binding-refresh REGISTER requests Even if the UA is able to to send binding-refresh REGISTER requests
using a non-push mechanism, the UA MUST still send a binding-refresh using a non-push mechanism, the UA MUST still send a binding-refresh
REGISTER request whenever it receives a push notification REGISTER request whenever it receives a push notification
(Section 4.1.3). (Section 4.1.3).
NOTE: If the UA uses a non-push mechanism to wake and send a binding- NOTE: If the UA uses a non-push mechanism to wake and send binding-
refresh REGISTER request, such REGISTER request will update the refresh REGISTER requests, such REGISTER requests will update the
binding expiration timer, and the proxy does not need to request that binding expiration timer, and the proxy does not need to request that
a push notification is sent to the UA in order to wake the UA. The a push notification is sent to the UA in order to wake the UA. The
proxy will still request that a push notification is sent to the UA proxy will still request that a push notification is sent to the UA
when the proxy receives a SIP request addressed towards the UA when the proxy receives a SIP request addressed towards the UA
(Section 5.6.2). This allows the UA to e.g., use timers for sending (Section 5.6.2). This allows the UA to e.g., use timers for sending
binding-refresh REGISTER requests, but to be suspended (in order to binding-refresh REGISTER requests, but to be suspended (in order to
save battery resources etc) between sending the REGISTER requests and save battery resources, etc.) between sending the REGISTER requests
use push notification to wake the UA to process incoming calls. and use push notification to wake the UA to process incoming calls.
4.1.5. Query Network PNS Capabilities 4.1.5. Query Network PNS Capabilities
This section describes how a SIP UA can query the types of PNSs This section describes how a SIP UA can query the types of PNSs
supported by a SIP network, and PNS-related capabilities (e.g., supported by a SIP network, and PNS-related capabilities (e.g.,
support of the VAPID mechanism). When a UA performs a query, it does support of the VAPID mechanism). When a UA performs a query, it does
not request push notifications from the SIP network. Therefore, the not request push notifications from the SIP network. Therefore, the
UA can perform the query before it has registered to a PNS and UA can perform the query before it has registered to a PNS and
received a PRID. received a PRID.
In order to perform a query, the UA MUST insert a pn-provider SIP URI In order to perform a query, the UA MUST insert a pn-provider SIP URI
parameter in the Contact header field URI of the REGISTER request: parameter in the Contact header field URI of the REGISTER request:
If the UA inserts a pn-provider parameter value, indicating If the UA inserts a pn-provider parameter value, indicating
support of a type of PNS, the SIP network will only inform the UA support of a type of PNS, the SIP network will only inform the UA
whether that type of PNS is supported. whether that type of PNS is supported.
If the UA does not insert a pn-provider parameter value (i.e., it If the UA does not insert a pn-provider parameter value (i.e., it
inserts an "empty pn-provider parameter") the SIP network will inserts an "empty" pn-provider parameter) the SIP network will
inform the UA about all types of PNSs supported by the network. inform the UA about all types of PNSs supported by the network.
This is useful e.g., if the UA supports more than one type of PNS. This is useful e.g., if the UA supports more than one type of PNS.
Note that it is not possible to insert multiple parameter values Note that it is not possible to insert multiple parameter values
in the pn-provider parameter. in the pn-provider parameter.
The UA MUST NOT insert a pn-prid SIP URI parameter in the Contact The UA MUST NOT insert a pn-prid SIP URI parameter in the Contact
header field URI of the REGISTER request. header field URI of the REGISTER request.
If the UA receives a 2xx response to the REGISTER request, the If the UA receives a 2xx response to the REGISTER request, the
response will contain one or more Feature-Caps header fields with a response will contain one or more Feature-Caps header fields with a
'sip.pns' feature-capability indicator, indicating the types of PNSs 'sip.pns' feature-capability indicator, indicating the types of PNSs
supported by the SIP network. If the UA inserted a pn-provider SIP supported by the SIP network. If the UA inserted a pn-provider SIP
URI parameter value in the REGISTER request, the response will only URI parameter value in the REGISTER request, the response will only
indicate whether the SIP network supports the type of PNS supported indicate whether the SIP network supports the type of PNS supported
by the UA. by the UA.
If the UA receives a 555 (Push Notification Service Not Supported) If the UA receives a 555 (Push Notification Service Not Supported)
response to the REGISTER request, the response will contain the response to the REGISTER request, the response will contain one or
response will contain one or more Feature-Caps header fields with a more Feature-Caps header fields with a 'sip.pns' feature-capability
'sip.pns' feature-capability indicator, indicating the types of PNSs indicator, indicating the types of PNSs supported by the SIP network.
supported by the SIP network.
NOTE: It is optional for a UA to perform a query before it requests NOTE: It is optional for a UA to perform a query before it requests
push notifications from the SIP network. push notifications from the SIP network.
5. SIP Proxy Behavior 5. SIP Proxy Behavior
5.1. PNS Provider 5.1. PNS Provider
The type of PNS is identified by the pn-provider SIP URI parameter. The type of PNS is identified by the pn-provider SIP URI parameter.
In some cases there might only be one PNS provider for a given type In some cases there might only be one PNS provider for a given type
of PNS, while in other cases there might be multiple providers. The of PNS, while in other cases there might be multiple providers. The
pn-param SIP URI parameter will provide more details associated with pn-param SIP URI parameter will provide more details associated with
the actual PNS provider to be used. the actual PNS provider to be used.
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. SIP Request Push Bucket 5.2. SIP Request Push Bucket
When a SIP proxy receives a SIP request, addressed towards a UA, that When a SIP proxy receives a SIP request addressed towards a UA, that
will trigger the proxy to request that a push notification is sent to will trigger the proxy to request that a push notification is sent to
the UA, the proxy will place the request in a storage referred to as the UA. The proxy will place the request in storage referred to as
the SIP Request Push Bucket. The proxy starts a timer (referred to the SIP Request Push Bucket, and the proxy starts a timer (referred
as the Bucket Timer) associated with the transaction. A SIP request to as the Bucket Timer) associated with the transaction. A SIP
is removed from the bucket once the proxy forwards the request request is removed from the bucket when one of the following has
towards the UA, when the proxy sends an error response to the occurred: the proxy forwards the request towards the UA, when the
request, or when the Bucket Timer times out. The detailed procedures proxy sends an error response to the request, or when the Bucket
are described in the sections below. Timer times out. The detailed procedures are described in the
sections below.
Exactly how the SIP Request Push Bucket is implemented is outside the Exactly how the SIP Request Push Bucket is implemented is outside the
scope of this document. One option is to use the PRID as a key to scope of this document. One option is to use the PRID as a key to
search for SIP requests in the bucket. Note that mid-dialog requests search for SIP requests in the bucket. Note that mid-dialog requests
(Section 6) do not carry the PRID in the SIP request itself. (Section 6) do not carry the PRID in the SIP request itself.
5.3. SIP URI Comparison Rules 5.3. SIP URI Comparison Rules
By default, a SIP proxy uses the URI comparison rules defined in By default, a SIP proxy uses the URI comparison rules defined in
[RFC3261]. However, when a SIP proxy compares the Contact header [RFC3261]. However, when a SIP proxy compares the Contact header
field URI of a 2xx response to a REGISTER request with a Request-URI field URI of a 2xx response to a REGISTER request with a Request-URI
of a SIP request in the SIP Request Push Bucket (Section 5.2), the of a SIP request in the SIP Request Push Bucket (Section 5.2), the
proxy uses the URI comparison rules with the following additions: the proxy uses the URI comparison rules with the following additions: the
pn-prid, pn-provider and pn-param SIP URI parameters MUST also match. pn-prid, pn-provider and pn-param SIP URI parameters MUST also match.
If a pn- parameter is present in one of the compared URIs but not in If a pn- parameter is present in one of the compared URIs but not in
the other URI there is no match. the other URI, there is no match.
If only the pn- SIP URI parameters listed above match, but other If only the pn- SIP URI parameters listed above match, but other
parts of the compared URIs do not match, a proxy MAY still consider parts of the compared URIs do not match, a proxy MAY still consider
the comparison successful, based on local policy. This can occur in the comparison successful based on local policy. This can occur in a
a race condition when the proxy compares the Contact header field URI race condition when the proxy compares the Contact header field URI
of a 2xx response to a REGISTER request with a Request-URI of a SIP of a 2xx response to a REGISTER request with a Request-URI of a SIP
request in the SIP Request Push Bucket (Section 5.2), if the UA that request in the SIP Request Push Bucket (Section 5.2), if the UA had
sent the associated REGISTER request modified some parts of the modified some parts of the Contact header field URI in the REGISTER
Contact header field URI in the REGISTER request, but the Request-URI request but the Request-URI of the SIP request in the SIP Request
of the SIP request in the SIP Request Push Bucket still contains the Push Bucket still contains the old parts.
old parts.
5.4. Indicate Support of Type of PNS 5.4. Indicate Support of Type of PNS
A SIP proxy uses feature-capability indicators [RFC6809] to indicate A SIP proxy uses feature-capability indicators [RFC6809] to indicate
support of types of PNSs, and additional features (e.g., VAPID) support of types of PNSs and additional features (e.g., VAPID)
associated associated with a type of PNS. A proxy MUST use a associated associated with the type of PNS. A proxy MUST use a
separate Feature-Cap header fields for each supported type of PNS. A separate Feature-Cap header field for each supported type of PNS. A
feature-capability indicator that indicates support of an additional feature-capability indicator that indicates support of an additional
feature associated with a given type of PNS MUST be inserted in the feature associated with a given type of PNS MUST be inserted in the
same Feature-Caps header field that is used to indicate support of same Feature-Caps header field that is used to indicate support of
the type of PNS. the type of PNS.
This specification defines the following feature-capability This specification defines the following feature-capability
indicators that a proxy can use to indicate support of additional indicators that a proxy can use to indicate support of additional
features associated with a given type of PNS: 'sip.vapid', features associated with a given type of PNS: 'sip.vapid',
'sip.pnsreg' and 'sip.pnspurr'. These feature-capability indicators 'sip.pnsreg' and 'sip.pnspurr'. These feature-capability indicators
MUST only be inserted in a Feature-Caps header field that also MUST only be inserted in a Feature-Caps header field that also
skipping to change at page 14, line 18 skipping to change at page 14, line 16
binding-refresh REGISTER request, the proxy will request that a push binding-refresh REGISTER request, the proxy will request that a push
notification is sent to the UA. notification is sent to the UA.
Note that the push notification needs to be requested early enough Note that the push notification needs to be requested early enough
for the associated binding-refresh REGISTER request to reach the for the associated binding-refresh REGISTER request to reach the
registrar before the binding expires. It is RECOMMENDED that the registrar before the binding expires. It is RECOMMENDED that the
proxy requests the push notification at least 120 seconds before the proxy requests the push notification at least 120 seconds before the
binding expires. binding 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 wake using a non-push mechanism in order to send that it is able to wake itself using a non-push mechanism in order to
binding-refresh REGISTER requests, and if the proxy does not receive send binding-refresh REGISTER requests, and if the proxy does not
a REGISTER request prior to 120 seconds before the binding expires, receive a REGISTER request prior to 120 seconds before the binding
the proxy MAY request that a push notification is sent to the UA, to expires, the proxy MAY request that a push notification is sent to
trigger the UA to send a binding-refresh REGISTER request. the UA, to trigger the UA to send a binding-refresh REGISTER request.
NOTE: As described in Section 4.1.5, a UA might send a REGISTER NOTE: As described in Section 4.1.5, a UA might send a REGISTER
request without including a pn-prid SIP URI parameter, in order to request without including a pn-prid SIP URI parameter, in order to
retrieve push notification capabilities from the network before the retrieve push notification capabilities from the network before the
UA expects to receive push notifications from the network. A proxy UA expects to receive push notifications from the network. A proxy
will not request that push notifications are sent to a UA that has will not request that push notifications are sent to a UA that has
not provided a pn-prid SIP URI parameter (Section 5.6.2). not provided a pn-prid SIP URI parameter (Section 5.6.2).
If the proxy receives information that a binding associated with a If the proxy receives information that a binding associated with a
PRID has expired, or that a binding has been removed, the proxy MUST PRID has expired, or that a binding has been removed, the proxy MUST
skipping to change at page 14, line 46 skipping to change at page 14, line 44
5.6. SIP Requests 5.6. SIP Requests
5.6.1. REGISTER 5.6.1. REGISTER
This section describes how a SIP proxy processes SIP REGISTER This section describes how a SIP proxy processes SIP REGISTER
requests (initial REGISTER request for a binding, or a binding- requests (initial REGISTER request for a binding, or a binding-
refresh REGISTER request). refresh REGISTER request).
The procedures in this section apply when the REGISTER request The procedures in this section apply when the REGISTER request
contains a pn-provider SIP URI parameter in the Contact header field contains a pn-provider SIP URI parameter in the Contact header field
URI of the request. In other cases the proxy MUST skip the URI. In other cases the proxy MUST skip the procdeures in this
procedures in this section, and process the REGISTER request using section, and process the REGISTER request using normal SIP
normal SIP procedures. procedures.
5.6.1.1. Request Push Notifications 5.6.1.1. Request Push Notifications
This section describes the SIP proxy procedures when a SIP UA This section describes the SIP proxy procedures when a SIP UA
requests push notifications from the SIP network. requests push notifications from the SIP network.
The procedures in this section apply when the SIP REGISTER request The procedures in this section apply when the SIP REGISTER request
contains, in addition to the pn-provider SIP URI parameter, a pn-prid contains, in addition to the pn-provider SIP URI parameter, a pn-prid
SIP URI parameter in the Contact header field URI of the request. SIP URI parameter in the Contact header field URI of the request.
When a proxy receives a REGISTER request, if the REGISTER request When a proxy receives a REGISTER request that contains a Feature-Caps
contains a Feature-Caps header field with a 'sip.pns' feature- header field with a 'sip.pns' feature-capability indicator, it
capability indicator, it indicates that a proxy between this proxy indicates that a proxy between this proxy and the UA supports the
and the UA supports the type of PNS supported by the UA, and will type of PNS supported by the UA, and will request that push
request that push notifications are sent to the UA. In such case, notifications are sent to the UA. In such case, the proxy MUST skip
the proxy MUST skip the rest of the procedures in this section, and the rest of the procedures in this section, and process the REGISTER
process the REGISTER request using normal SIP procedures. request using normal SIP procedures.
When a proxy receives a REGISTER request, and the request does not When a proxy receives a REGISTER request that does not contain a
contain a Feature-Caps header field with a 'sip.pns' feature- Feature-Caps header field with a 'sip.pns' feature-capability
capability indicator, the proxy processes the request according to indicator, the proxy processes the request according to the
the procedures below: procedures below:
o If the proxy does not support the type of PNS supported by the UA, o If the proxy does not support the type of PNS supported by the UA,
or if the REGISTER request does not contain all information or if the REGISTER request does not contain all information
required for the type of PNS, the proxy SHOULD forward the request required for the type of PNS, the proxy SHOULD forward the request
towards the registrar and skip the rest of the procedures in this towards the registrar and skip the rest of the procedures in this
section. If the proxy knows (by means of local configuration) section. If the proxy knows (by means of local configuration)
that no other proxies between itself and the registrar support the that no other proxies between itself and the registrar support the
type of PNS supported by the UA, the proxy MAY send a SIP 555 type of PNS supported by the UA, the proxy MAY send a SIP 555
(Push Notification Service Not Supported) response instead of (Push Notification Service Not Supported) response instead of
forwarding the request. forwarding the request.
skipping to change at page 16, line 7 skipping to change at page 15, line 51
o If the proxy supports the type of PNS supported by the UA, the o If the proxy supports the type of PNS supported by the UA, the
proxy MUST indicate support of that type of PNS (Section 5.4) in proxy MUST indicate support of that type of PNS (Section 5.4) in
the REGISTER request before it forwards the request towards the the REGISTER request before it forwards the request towards the
registrar. This will inform proxies between the proxy and the registrar. This will inform proxies between the proxy and the
registrar that the proxy supports the type of PNS supported by the registrar that the proxy supports the type of PNS supported by the
UA, and that the proxy will request that push notifications are UA, and that the proxy will request that push notifications are
sent to the UA. sent to the UA.
A binding expiration interval MUST be considered too short if the A binding expiration interval MUST be considered too short if the
binding would expire before the proxy would request that a push binding would expire before the proxy would request that a push
notification is sent to the UA, in order to trigger the UA to send a notification is sent to the UA to trigger the UA to send a binding-
binding-refresh REGISTER request. The proxy MAY consider the refresh REGISTER request. The proxy MAY consider the interval too
interval too short based on its own policy so as to reduce load on short based on its own policy so as to reduce load on the system.
the system.
If the proxy sends a SIP 555 (Push Notification Service Not If the proxy sends a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD indicate each type of PNS that Supported) response, the proxy SHOULD indicate each type of PNS that
the proxy supports in the response. the proxy supports in the response.
When a proxy receives a 2xx response to the REGISTER request, if the When a proxy receives a 2xx response to the REGISTER request, if the
proxy indicated support of a type of PNS in the REGISTER request (see proxy indicated support of a type of PNS in the REGISTER request (see
above), the proxy performs the following actions: above), the proxy performs the following actions:
o If the proxy considers the binding expiration interval indicated o If the proxy considers the binding expiration interval indicated
by the registrar too short (see above), the proxy forwards the by the registrar too short (see above), the proxy forwards the
response towards the UA and MUST skip the rest of the procedures response towards the UA and MUST skip the rest of the procedures
in this section. in this section.
o The proxy MUST indicate support of the same type of PNS in the o The proxy MUST indicate support of the same type of PNS in the
REGISTER response. In addition: REGISTER response. In addition:
* If the proxy supports the VAPID mechanism [RFC8292], the proxy * If the proxy supports the VAPID mechanism [RFC8292], the proxy
MUST indicate support of the mechanism, using the 'sip.vapid' MUST indicate support of the mechanism, using the 'sip.vapid'
feature-capability indicator, in the REGISTER response. The feature-capability indicator, in the REGISTER response. The
indicator value contains the public key identifying the proxy . indicator value contains the public key identifying the proxy.
The proxy MUST determine whether the PNS provider supports the The proxy MUST determine whether the PNS provider supports the
VAPID mechanism before it indicates support of it. VAPID mechanism before it indicates support of it.
* If the proxy received a 'sip.pnsreg' media feature tag in the * If the proxy received a 'sip.pnsreg' media feature tag in the
REGISTER request, the proxy SHOULD insert a 'sip.pnsreg' REGISTER request, the proxy SHOULD insert a 'sip.pnsreg'
feature-capability indicator with an indicator value bigger feature-capability indicator with an indicator value bigger
than 120 in the response, unless the proxy always wants to than 120 in the response, unless the proxy always wants to
request that push notifications are sent to the UA in order to request that push notifications are sent to the UA in order to
trigger the UA to send a binding-refresh REGISTER request. trigger the UA to send a binding-refresh REGISTER request.
5.6.1.2. Query Network PNS Capabilities 5.6.1.2. Query Network PNS Capabilities
This section describes the SIP proxy procedures when a SIP UA queries This section describes the SIP proxy procedures when a SIP UA queries
about the push notification support in the SIP network about the push notification support in the SIP network
(Section 4.1.5). (Section 4.1.5).
The procedures in this section apply when the REGISTER request The procedures in this section apply when the REGISTER request
contains a pn-provider SIP URI parameter, but does not contain a pn- contains a pn-provider SIP URI parameter, but does not contain a pn-
prid SIP URI parameter, in the Contact header field URI of the prid SIP URI parameter in the Contact header field URI of the
REGISTER request. REGISTER request.
When a proxy receives a REGISTER request, if the pn-provider SIP URI When a proxy receives a REGISTER request that contains a pn-provider
parameter contains a parameter value that indicates the type of PNS SIP URI parameter indicating the type of PNS supported by the UA, the
supported by the UA, the proxy MUST perform the following actions: proxy MUST perform the following actions:
If the proxy supports the type of PNS supported by the UA, the If the proxy supports the type of PNS supported by the UA, the
proxy MUST indicate support of that type of PNS (Section 5.4) in proxy MUST indicate support of that type of PNS (Section 5.4) in
the REGISTER request before it forwards the request towards the the REGISTER request before it forwards the request towards the
registrar. This will inform proxies between the proxy and the registrar. This will inform proxies between the proxy and the
registrar that the proxy supports the type of PNS supported by the registrar that the proxy supports the type of PNS supported by the
UA. UA.
If the proxy does not support the type of PNS supported by the UA, If the proxy does not support the type of PNS supported by the UA,
and if the REGISTER request contains Feature-Caps header fields and if the REGISTER request contains Feature-Caps header fields
indicating support of one or more types of PNSs, the proxy indicating support of one or more types of PNSs, the proxy
skipping to change at page 17, line 33 skipping to change at page 17, line 26
SIP 555 (Push Notification Service Not Supported) response towards SIP 555 (Push Notification Service Not Supported) response towards
the UA. The proxy MUST NOT send a SIP 555 (Push Notification the UA. The proxy MUST NOT send a SIP 555 (Push Notification
Service Not Supported) response unless it knows (by means of local Service Not Supported) response unless it knows (by means of local
configuration) that no other proxy supports any of the types of configuration) that no other proxy supports any of the types of
PNSs supported by the UA. PNSs supported by the UA.
If the proxy sends a SIP 555 (Push Notification Service Not If the proxy sends a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD indicate each type of PNS that Supported) response, the proxy SHOULD indicate each type of PNS that
the proxy supports in the response. the proxy supports in the response.
When a proxy receives a REGISTER request, if the pn-provider SIP URI When a proxy receives a REGISTER request, and the pn-provider SIP URI
parameter does not contain a parameter value, the proxy MUST indicate parameter does not contain a parameter value, the proxy MUST indicate
support of each type of PNS supported by the proxy before it forwards support of each type of PNS supported by the proxy before it forwards
the request towards the registrar. the request towards the registrar.
When a proxy receives a 2xx response to the REGISTER request, if the When a proxy receives a 2xx response to the REGISTER request, if the
proxy indicated support of one or more types of PNSs in the REGISTER proxy had indicated support of one or more types of PNSs in the
request (see above), the proxy MUST indicate support of the same set REGISTER request (see above), the proxy MUST indicate support of the
of types of PNSs in the response. In addition, if the proxy supports same set of types of PNSs in the response. In addition, if the proxy
the VAPID mechanism for one or more types of PNSs, the proxy MUST supports the VAPID mechanism for one or more types of PNSs, the proxy
indicate support of the mechanism for those PNSs in the response. MUST indicate support of the mechanism for those PNSs in the
response.
5.6.2. Initial Request for Dialog or Stand-Alone Request 5.6.2. Initial Request for Dialog or Stand-Alone Request
The procedures in this section apply when a SIP proxy has indicated The procedures in this section apply when a SIP proxy has indicated
that the it will request that push notifications are sent to the SIP that the it will request that push notifications are sent to the SIP
UA. UA.
When the proxy receives a SIP request for a new dialog (e.g., a SIP When the proxy receives a SIP request for a new dialog (e.g., a SIP
INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE
request) addressed towards a SIP UA, if the Request-URI of the request) 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 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 for the specific PNS provider) SIP URI parameter, the proxy requests
that a push notification is sent to the UA, using the information in that a push notification is sent to the UA using the information in
the pn- SIP URI parameters. The proxy then places the SIP request in the pn- SIP URI parameters. The proxy then places the SIP request in
the SIP Request Push Bucket. The push notification will trigger the the SIP Request Push Bucket. The push notification will trigger the
UA to send a binding-refresh REGISTER request, that the proxy will UA to send a binding-refresh REGISTER request that the proxy will
process as described in Section 5.6.1. In addition, the proxy MUST process as described in Section 5.6.1. In addition, the proxy MUST
store the Contact URI of the REGISTER request during the lifetime of store the Contact URI of the REGISTER request during the lifetime of
the REGISTER transaction. the REGISTER transaction.
NOTE: If the proxy receives a SIP request that does not contain the NOTE: If the proxy receives a SIP request that does not contain the
pn- SIP URI parameters listed above, the proxy processing of the pn- SIP URI parameters listed above, the proxy processing of the
request is based on local policy. If the proxy also serves requests request is based on local policy. If the proxy also serves requests
for UAs that do not use the SIP push mechanism, the proxy can forward for UAs that do not use the SIP push mechanism, the proxy can forward
the request towards the UA. Otherwise the proxy can reject the the request towards the UA. Otherwise the proxy can reject the
request. request.
skipping to change at page 19, line 12 skipping to change at page 19, line 7
perform authentication) the proxy MAY keep the SIP request in the perform authentication) the proxy MAY keep the SIP request in the
bucket. bucket.
If the push notification request fails (see PNS-specific If the push notification request fails (see PNS-specific
documentation for details), the proxy MUST remove the SIP request documentation for details), the proxy MUST remove the SIP request
from the bucket and send an error response to the SIP request. It is from the bucket and send an error response to the SIP request. It is
RECOMMENDED that the proxy sends either a 404 (Not Found) response or RECOMMENDED that the proxy sends either a 404 (Not Found) response or
a 480 (Temporarily Unavailable) response, but other response codes a 480 (Temporarily Unavailable) response, but other response codes
can be used as well. can be used as well.
When the proxy has requested that a push notification is sent to a After the proxy has requested that a push notification is sent to a
UA, if the proxy does not receive a REGISTER response with a Contact UA, if the proxy does not receive a REGISTER response with a Contact
URI that matches the Request-URI of the SIP request, the Bucket Timer URI that matches the Request-URI of the SIP request before the Bucket
(Section 5.2) associated with the SIP request will eventually time Timer (Section 5.2) associated with the SIP request times out, the
out. When that happens the proxy MUST remove the SIP request from proxy MUST remove the SIP request from the SIP Request Push Bucket
the SIP Request Push Bucket (Section 5.2) and send a 480 (Temporarily (Section 5.2) and send a 480 (Temporarily Unavailable) response. The
Unavailable) response. The Bucket Timer time out value is set based Bucket Timer time-out value is set based on local policy, taking the
on local policy, taking the guidelines below into consideration. guidelines below into consideration.
As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must
complete immediately or risk losing a race that results in stress on complete immediately or risk losing a race, which results in stress
intermediaries and state misalignment at the endpoints. The on intermediaries and state misalignment at the endpoints. The
mechanism defined in this document inherently delays the final mechanism defined in this document inherently delays the final
response to any non-INVITE request that requires a push notification. response to any non-INVITE request that requires a push notification.
In particular, while waiting for the push notification request to In particular, if the proxy forwards the SIP request towards the SIP
succeed, and the associated REGISTER request to arrive from the SIP UA, the SIP UA accepts the request, but the transaction times out at
UA, the proxy needs to take into consideration that the transaction the sender before it receives the successful response, this will
associated with the SIP request will eventually time out at the cause state misalignment between the endpoints (the sender considers
sender of the request (UAC), and the sender will consider the the transaction a failure, while the receiver considers the
transaction a failure. If the proxy forwards the SIP request towards transaction a success). The SIP proxy needs to take this into
the SIP UA, the SIP UA accepts the request and the transaction times
out at the sender before it receives the successful response, this
will cause state misalignment between the endpoints (the sender will
consider the transaction a failure, while the receiver will consider
the transaction a success). The SIP proxy needs to take this into
account when it sets the value of the Bucket Timer associated with account when it sets the value of the Bucket Timer associated with
the transaction, to make sure that the error response (triggered by a the transaction, to make sure that the error response (triggered by a
Bucket Timer time out) reaches the sender before the transaction Bucket Timer time out) reaches the sender before the transaction
times out. If the accumulated delay of this mechanism combined with times out. If the accumulated delay of this mechanism combined with
any other mechanisms in the path of processing the non-INVITE any other mechanisms in the path of processing the non-INVITE
transaction is not kept short, this mechanism should not be used. transaction cannot be kept short, this mechanism should not be used.
For networks encountering such conditions, an alternative (left for For networks encountering such conditions, an alternative (left for
possible future work) would be for the proxy to immediately return an possible future work) would be for the proxy to immediately return an
new error code meaning "wait at least the number of seconds specified new error code meaning "wait at least the number of seconds specified
in this response, and retry your request" before initiating the push in this response, and retry your request" before initiating the push
notification. notification.
NOTE: While this work on this document was ongoing, implementation NOTE: While this work on this document was ongoing, implementation
test results showed that the time it takes for a proxy to receive the test results showed that the time it takes for a proxy to receive the
REGISTER request, from when the proxy has requested a push REGISTER request, from when the proxy has requested a push
notification, is typically around 2 seconds. However, the time might notification, is typically around 2 seconds. However, the time might
skipping to change at page 20, line 33 skipping to change at page 20, line 26
the SIP request towards the UA. The mechanisms for getting such the SIP request towards the UA. The mechanisms for getting such
knowledge might be dependent on implementation or deployment knowledge might be dependent on implementation or deployment
architecture, and are outside the scope of this document. architecture, and are outside the scope of this document.
Some PNS providers allow payload in the push notifications. This Some PNS providers allow payload in the push notifications. This
specification does not define usage of such payload (in addition to specification does not define usage of such payload (in addition to
any payload that might be required by the PNS itself). any payload that might be required by the PNS itself).
6. Support Of Longlived SIP Dialogs 6. Support Of Longlived SIP Dialogs
Some SIP dialogs might have a long lifetime, with little activity. Some SIP dialogs might have a long lifetime with little activity.
For example, when the SIP event notification mechanism [RFC6665] is For example, when the SIP event notification mechanism [RFC6665] is
used, there might be a long period between mid-dialog requests are used, there might be a long period between the sending of mid-dialog
sent. Because of this a SIP UA might get suspended, and needs to be requests. Because of this, a SIP UA may be suspended, and may need
awaken in order to be able to receive mid-dialog requests. to be awakened in order to be able to receive mid-dialog requests.
When the proxy receives a SIP request for a new dialog, or a stand- SIP requests for a new dialog and stand-alone SIP requests addressed
alone SIP request, addressed towards a UA, the request will contain towards a UA will pn- SIP URI parameters that allows the proxy to
information (pn- SIP URI parameters) that allows proxy to request request that a push notification be sent to the UA Section 5.6.2.
that a push notification is sent to the UA Section 5.6.2. However, However, pn- SIP URI parameters will not be present in mid-dialog
this information will not be present in mid-dialog requests addressed requests addressed towards the UA. Instead, the proxy needs to
towards the UA. Instead, the proxy need to support a mechanism where support a mechanism to store the information needed to request that a
it stores the information needed to request that a push notification push notification be sent to the UA, and to be able to retrieve that
is sent to the UA, and to be able to retrieve that information when information when it receives a mid-dialog request addressed towards
it receives a mid-dialog request addressed towards the UA. This the UA. This section defines such mechanism. The SIP UA and SIP
section defines such mechanism. This section describes such proxy procedures in this section are applied in addition to the
mechanism. The SIP UA and SIP proxy procedures in this section are generic procedures defined in this specification.
applied in addition to the generic procedures defined in this
specification.
+--------+ +---------+ +-----------+ +-------------+ +--------+ +---------+ +-----------+ +-------------+
| | | | | | | SIP | | | | | | | | SIP |
| SIP UA | | Push | | SIP Proxy | | Registrar / | | SIP UA | | Push | | SIP Proxy | | Registrar / |
| | | Service | | | | Home Proxy | | | | Service | | | | Home Proxy |
+--------+ +---------+ +-----------+ +-------------+ +--------+ +---------+ +-----------+ +-------------+
| | | | | | | |
| Subscribe | | | | PNS Register | | |
|---------------->| | | |---------------->| | |
| | | | | | | |
| PRID | | | | PRID | | |
|<----------------| | | |<----------------| | |
| | | | | | | |
| SIP REGISTER (PRID) | | | SIP REGISTER (PRID) | |
|===================================>| | |===================================>| |
| | |SIP REGISTER (PRID)| | | |SIP REGISTER (PRID)|
| | |==================>| | | |==================>|
| | | | | | | |
skipping to change at page 22, line 31 skipping to change at page 22, line 24
------- Push Notification API ------- Push Notification API
======= SIP ======= SIP
Figure 3: SIP Push Longlived Dialog Flow Figure 3: SIP Push Longlived Dialog Flow
6.1. SIP UA Behavior 6.1. SIP UA Behavior
6.1.1. Initial Request for Dialog 6.1.1. Initial Request for Dialog
When a UA sends an initial request for a dialog, or a 2xx response to If the UA is willing to receive push notifications when a proxy
such requests, if the UA is willing to receive push notifications receives a mid-dialog request addressed towards the UA, the UA MUST
when a proxy receives a mid-dialog request addressed towards the UA, insert a 'pn-purr' SIP URI parameter in the Contact header field URI
the UA MUST insert a 'pn-purr' SIP URI parameter in the Contact of the initial request for a dialog or the 2xx response to such
header field URI of the request or response. The UA MUST insert a requests. The UA MUST insert a parameter value identical to the last
parameter value identical to the last 'sip.pnspurr' feature- 'sip.pnspurr' feature-capability indicator that it received in a
capability indicator that it received in a REGISTER response REGISTER response (Section 6.2.1). If the UA has not recived a
(Section 6.2.1). If the UA has not recived a 'sip.pnspurr' feature- 'sip.pnspurr' feature-capability indicator, the UA MUST NOT insert a
capability indicator, the UA MUST NOT insert a 'pn-purr' SIP URI 'pn-purr' SIP URI parameter in a request or response.
parameter in a request or response.
The UA decision whether it is willing to receive push notifications The UA makes the decision to receive push notifications triggered by
triggered by incoming mid-dialog requests is done based on local incoming mid-dialog requests based on local policy. Such policy
policy. Such policy might be based on the type of SIP dialog, the might be based on the type of SIP dialog, the type of media (if any)
type of media (if any) negotiated for the dialog [RFC3264], etc. negotiated for the dialog [RFC3264], etc.
NOTE: As the 'pn-purr' SIP URI parameter only applies to a given NOTE: As the 'pn-purr' SIP URI parameter only applies to a given
dialog, the UA needs to insert a 'pn-purr' parameter in the Contact dialog, the UA needs to insert a 'pn-purr' parameter in the Contact
header field URI of the request or response for each dialog in which header field URI of the request or response for each dialog in which
the UA is willing to receive push notifications triggered by incoming the UA is willing to receive push notifications triggered by incoming
mid-dialog requests. mid-dialog requests.
6.2. SIP Proxy Behavior 6.2. SIP Proxy Behavior
6.2.1. REGISTER 6.2.1. REGISTER
When a proxy receives an initial REGISTER request for a binding from If the proxy supports requesting push notifications triggered by mid-
the UA, if the proxy supports requesting that push notifications dialog requests being sent to the registered UA, the proxy MUST store
triggered by mid-dialog requests are sent to the registered UA, the the information (the pn- SIP URI parameters) needed to request that
proxy MUST store the information (the pn- SIP URI parameters) needed push notifications are sent to the UA when a proxy receives an
to request that push notifications are sent to the UA. In addition, initial REGISTER request for a binding from the UA. In addition, the
the proxy MUST generate a unique (within the context of the proxy) proxy MUST generate a unique (within the context of the proxy) value,
value, referred to as the PURR (Proxy Unique Registration Reference), referred to as the PURR (Proxy Unique Registration Reference), that
that can be used as a key to retrieve the information. can be used as a key to retrieve the information.
In order to prevent client fingerprinting, the proxy MUST In order to prevent client fingerprinting, the proxy MUST
periodically generate a new PURR value (even if pn- parameters did periodically generate a new PURR value (even if pn- parameters did
not change). However, as long as there are ongoing dialogs not change). However, as long as there are ongoing dialogs
associated with the old value, the proxy MUST store it so that it can associated with the old value, the proxy MUST store it so that it can
request that push notifications are sent to the UA when it receives a request that push notifications are sent to the UA when it receives a
mid-dialog request addressed towards the UA. In addition, the PURR mid-dialog request addressed towards the UA. In addition, the PURR
value MUST be generated in such a way so that it cannot be used to value MUST be generated in such a way so that it cannot be used to
retrieve information about the user or associate it with retrieve information about the user or associate it with
registrations. It can be generated e.g., by utilizing a registrations. It can be generated e.g., by utilizing a
cryptographically secure random function. cryptographically secure random function.
Whenever the proxy receives a 2xx response to a REGISTER request, the Whenever the proxy receives a 2xx response to a REGISTER request, the
proxy MUST insert a 'sip.pnspurr' feature-capability indicator with proxy MUST insert a 'sip.pnspurr' feature-capability indicator with
the latest PURR value (see above) in the response. the latest PURR value (see above) in the response.
6.2.2. Initial Request for Dialog 6.2.2. Initial Request for Dialog
When a proxy receives an initial request for a dialog from a UA, if When a proxy receives an initial request for a dialog from a UA that
the request contains a 'pn-purr' SIP URI parameter in the Contact contains a 'pn-purr' SIP URI parameter in the Contact header field
header field URI of the request with a PURR value that the proxy has URI with a PURR value that the proxy has generated (Section 6.2.2),
generated (Section 6.2.2), the proxy MUST add a Record-Route header the proxy MUST add a Record-Route header to the request to insert
to the request, to insert itself in the dialog route [RFC3261] before itself in the dialog route [RFC3261] before forwarding the request.
forwarding the request.
When the proxy receives an initial request for a dialog addressed When the proxy receives an initial request for a dialog addressed
towards the UA, if the proxy has generated a PURR value associated towards the UA, and the proxy has generated a PURR value associated
with the pn- parameters inserted in the SIP URI of the request with the pn- parameters inserted in the SIP URI of the request
Section 6.2.2, the proxy MUST add a Record-Route header to the (Section 6.2.2), the proxy MUST add a Record-Route header to the
request, to insert itself in the dialog route [RFC3261] before request, to insert itself in the dialog route [RFC3261] before
forwarding the request. forwarding the request.
6.2.3. Mid-Dialog Request 6.2.3. Mid-Dialog Request
When the proxy receives a mid-dialog SIP request addressed towards When the proxy receives a mid-dialog SIP request addressed towards
the UA, if the request contains a 'pn-purr' SIP URI parameter and if the UA that contains a 'pn-purr' SIP URI parameter, and the proxy is
the proxy is able to retrieve the stored information needed to able to retrieve the stored information needed to request that a push
request that a push notification is sent the UA (Section 6.2.1), the notification is sent the UA (Section 6.2.1), the proxy MUST place the
proxy MUST place the SIP request in the SIP Request Push Bucket and SIP request in the SIP Request Push Bucket and request that a push
request that a push notification is sent to the UA. notification is sent to the UA.
NOTE: The 'pn-purr' SIP URI parameter will either be carried in the NOTE: The 'pn-purr' SIP URI parameter will either be carried in the
Request-URI or in a Route header field [RFC3261] of the SIP request, Request-URI or in a Route header field [RFC3261] of the SIP request,
depending on how the route set [RFC3261] of the mid-dialog SIP depending on how the route set [RFC3261] of the mid-dialog SIP
request has been constructed. request has been constructed.
When the proxy receives a 2xx response to a REGISTER request, the When the proxy receives a 2xx response to a REGISTER request, the
proxy checks whether the SIP Request Push Bucket contains a mid- proxy checks whether the SIP Request Push Bucket contains a mid-
dialog SIP request associated with the REGISTER transaction. If the dialog SIP request associated with the REGISTER transaction. If the
bucket contains such request the proxy MUST remove the SIP request bucket contains such request the proxy MUST remove the SIP request
from the SIP Request Push Bucket and forward it towards the UA. from the SIP Request Push Bucket and forward it towards the UA.
Note that the proxy does not perform a URI comparison (Section 5.3) Note that the proxy does not perform a URI comparison (Section 5.3)
when processing mid-dialog requests, as a mid-dialog request will not when processing mid-dialog requests, as a mid-dialog request will not
contain the pn-prid, pn-provider and pn-param SIP URI parameters. contain the pn-prid, pn-provider and pn-param SIP URI parameters.
The proxy only checks for a mid-dialog request that contains the PURR The proxy only checks for a mid-dialog request that contains the PURR
value associated with the REGISTER 2xx response. value associated with the REGISTER 2xx response.
As described in Section 5.6.2, while waiting for the push As described in Section 5.6.2, while waiting for the push
notification request to succeed, and the associated REGISTER request notification request to succeed, and then for the associated REGISTER
and 2xx response, the proxy needs to take into consideration that the request and 2xx response, the proxy needs to take into consideration
transaction associated with the mid-dialog request will eventually that the transaction associated with the mid-dialog request will
time out at the sender of the request (UAC), and the sender will eventually time out at the sender of the request (UAC), and the
consider the transaction a failure. sender will consider the transaction a failure.
When a proxy sends an error response to a mid-dialog request (e.g., When a proxy sends an error response to a mid-dialog request (e.g.,
due to a transaction time out), the proxy SHOULD select a response due to a transaction time out), the proxy SHOULD select a response
code that only impacts the transaction associated with the request code that only impacts the transaction associated with the request
([RFC5079]). ([RFC5079]).
7. Support Of SIP Replaces 7. Support Of SIP Replaces
[RFC3891] defines a mechanism that allows a SIP UA to replace a [RFC3891] defines a mechanism that allows a SIP UA to replace a
dialog with another dialog. A UA that wants to replace a dialog with dialog with another dialog. A UA that wants to replace a dialog with
another one will send an initial request for the new dialog. The another one will send an initial request for the new dialog. The
Request-URI of the request will contain Contact header field URI of Request-URI of the request will contain Contact header field URI of
the peer. the peer.
If a SIP proxy wants to be able to request that a push notification If a SIP proxy wants to be able to request that a push notification
is sent to a UA when it receives an initial request for a dialog that is sent to a UA when it receives an initial request for a dialog that
replaces an existing dialog, using the mechanism in [RFC3891], the replaces an existing dialog, using the mechanism in [RFC3891], the
proxy and the UA MUST perform the following actions: proxy and the UA MUST perform the following actions:
o The proxy MUST provide a PURR to the UA during registration o The proxy MUST provide a PURR to the UA during registration
Section 6.2.1. (Section 6.2.1).
o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact
header field URI of the initial request for a dialog, or a 2xx header field URI of the initial request for a dialog, or a 2xx
response to such requests Section 6.1.1. This includes dialogs response to such requests (Section 6.1.1). This includes dialogs
replacing other dialogs, as those dialogs might also get replaced. replacing other dialogs, as those dialogs might also get replaced.
o The proxy MUST apply the mechanism defined in Section 6.2.3 to o The proxy MUST apply the mechanism defined in Section 6.2.3 to
place and retrieve the request from the SIP Request Push Bucket. place and retrieve the request from the SIP Request Push Bucket.
In addition, the operator needs to make sure that the initial request In addition, the operator needs to make sure that the initial request
for dialogs, addressed towards the UA using the contact of the for dialogs, addressed towards the UA using the contact of the
replaced dialog, will be routed to the SIP proxy (in order to request replaced dialog, will be routed to the SIP proxy (in order to request
that a push notification is sent to the UA). The procedures for that a push notification is sent to the UA). The procedures for
doing that are operator specific, and are outside the scope of this doing that are operator specific, and are outside the scope of this
specification. specification.
8. Grammar 8. Grammar
8.1. 555 (Push Notification Service Not Supported) Response Code 8.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 does 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 only defined for SIP REGISTER The use of the SIP 555 response code is only defined for SIP REGISTER
responses. responses.
8.2. sip.pns Feature-Capability Indicator 8.2. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator, when inserted in a Feature- The sip.pns feature-capability indicator, when inserted 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
skipping to change at page 26, line 13 skipping to change at page 26, line 8
indicator values. indicator values.
pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT
pns = tag-value pns = tag-value
tag-value = <tag-value defined in [RFC3840]> tag-value = <tag-value defined in [RFC3840]>
8.3. sip.vapid Feature-Capability Indicator 8.3. sip.vapid Feature-Capability Indicator
The sip.vapid feature-capability indicator, when inserted in a SIP The sip.vapid feature-capability indicator, when inserted in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, denotes that the entity
associated with the indicator supports the Voluntary Application associated with the indicator supports the Voluntary Application
Server Identification (VAPID) [RFC8292] mechanism when the entity Server Identification (VAPID) [RFC8292] mechanism when the entity
requests that a push notification is sent to a SIP UA. The indicator requests that a push notification is sent to a SIP UA. The indicator
value is a public key identifying the entity, that can be used by a value is a public key identifying the entity that can be used by a
SIP UA to restrict subscriptions to that entity. SIP UA to restrict subscriptions to 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 = <tag-value defined in [RFC3840]> tag-value = <tag-value defined in [RFC3840]>
8.4. sip.pnsreg Feature-Capability Indicator 8.4. sip.pnsreg Feature-Capability Indicator
The sip.pnsreg feature-capability indicator, when inserted in a SIP The sip.pnsreg feature-capability indicator, when inserted in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, denotes that the entity
associated with the indicator expects to receive binding-refresh associated with the indicator expects to receive binding-refresh
REGISTER requests for the binding from the SIP UA associated with the REGISTER requests from the SIP UA associated with the binding before
binding before the binding expires, even if the entity does not the binding expires, even if the entity does not request that a push
request that a push notification is sent to the SIP UA in order to notification is sent to the SIP UA in order to trigger the binding-
trigger the binding-refresh REGISTER requests. The indicator value refresh REGISTER requests. The indicator value conveys the minimum
indicates the minimum time (given in seconds), prior to the binding time (given in seconds), prior to the binding expiration when the UA
expiration when the UA MUST send the REGISTER request. MUST send 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 = <DIGIT defined in [RFC3261]> DIGIT = <DIGIT defined in [RFC3261]>
8.5. sip.pnsreg Media Feature Tag 8.5. sip.pnsreg Media Feature Tag
The sip.pnsreg media feature tag, when inserted in the Contact header The sip.pnsreg media feature tag, when inserted in the Contact header
field of a SIP REGISTER request, indicates that the SIP UA associated field of a SIP REGISTER request, indicates that the SIP UA associated
with the tag is able to send binding-refresh REGISTER requests for with the tag is able to send binding-refresh REGISTER requests for
the associated binding without being awaken by push notifications. the associated binding without being awakened by push notifications.
The media feature tag has no values. The media feature tag has no values.
pnsreg-mt = "+sip.pnsreg" pnsreg-mt = "+sip.pnsreg"
8.6. sip.pnspurr Feature-Capability Indicator 8.6. sip.pnspurr Feature-Capability Indicator
The sip.pnspurr feature-capability indicator, when inserted in a SIP The sip.pnspurr feature-capability indicator, when inserted in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, denotes that the entity
associated with the indicator will store information that can be used associated with the indicator will store information that can be used
to associate a mid-dialog SIP request with the binding information in to associate a mid-dialog SIP request with the binding information in
the REGISTER request. the REGISTER request.
pnspurr-fc = "+sip.pnspurr" EQUAL LDQUOT pnspurr RDQUOT pnspurr-fc = "+sip.pnspurr" EQUAL LDQUOT pnspurr RDQUOT
pnspurr = tag-value pnspurr = tag-value
tag-value = <tag-value defined in [RFC3840]> tag-value = <tag-value defined in [RFC3840]>
8.7. SIP URI Parameters 8.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 / pn-purr uri-parameter =/ pn-provider / pn-param / pn-prid / pn-purr
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-purr = "pn-purr" EQUAL pvalue pn-purr = "pn-purr" EQUAL pvalue
pvalue = <pvalue defined in [RFC3261]> pvalue = <pvalue defined in [RFC3261]>
EQUAL = <EQUAL defined in [RFC3261]> EQUAL = <EQUAL defined in [RFC3261]>
skipping to change at page 28, line 50 skipping to change at page 28, line 28
https://developer.apple.com/library/archive/documentation/NetworkingI https://developer.apple.com/library/archive/documentation/NetworkingI
nternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html nternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html
[pns-apns]) [pns-apns])
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 a string that is composed The value of the pn-param URI parameter is a string that is composed
by two values, separated by a period (.): Team ID and Topic. The of two values, separated by a period (.): Team ID and Topic. The
Team ID is provided by Apple and is unique to a development team. Team ID is provided by Apple and is unique to a development team.
The Topic consists of the Bundle ID, which uniquely identifies an The Topic consists of the Bundle ID, which uniquely identifies an
application, and a service value that identifies a service associated application, and a service value that identifies a service associated
with the application, separated by a period (.). For VoIP with the application, separated by a period (.). For VoIP
applications the service value is "voip". applications the service value is "voip".
Example: pn-param=DEF123GHIJ.com.example.yourexampleapp.voip Example: pn-param=DEF123GHIJ.com.example.yourexampleapp.voip
NOTE: The Bundle ID might contain one or more periods (.). Hence, NOTE: The Bundle ID might contain one or more periods (.). Hence,
within the pn-param value, the first period will be separating the within the pn-param value, the first period will be separating the
Team ID from the Topic, and within the Topic the last period will be Team ID from the Topic, and within the Topic the last period will be
skipping to change at page 30, line 23 skipping to change at page 30, line 4
The security considerations for the use and operation of any The security considerations for the use and operation of any
particular PNS (e.g., how users and devices are authenticated and particular PNS (e.g., how users and devices are authenticated and
authorized) is out of scope for this document. [RFC8030] documents authorized) is out of scope for this document. [RFC8030] documents
the security considerations for the PNS defined in that the security considerations for the PNS defined in that
specification. Security considerations for other PNSs are left to specification. Security considerations for other PNSs are left to
their respective specifications. their respective specifications.
Typically, the PNS requires the SIP proxy requesting push Typically, the PNS requires the SIP proxy requesting push
notifications to be authenticated and authorized by the PNS. In some notifications to be authenticated and authorized by the PNS. In some
cases the PNS also require the SIP application (or the SIP cases the PNS also requires the SIP application (or the SIP
application developer) to be identified in order for the application application developer) to be identified in order for the application
to request push notifications. Unless the PNS authenticates and to request push notifications. Unless the PNS authenticates and
authorizes the PNS, a malicious endpoint or network entity that authorizes the PNS, a malicious endpoint or network entity that
managed to get access to the parameters transported in the SIP managed to get access to the parameters transported in the SIP
signalling might be able to request that push notifications are sent signalling might be able to request that push notifications are sent
to a UA. Such push notifications will impact the battery life of the to a UA. Such push notifications will impact the battery life of the
UA and trigger unnecessary SIP traffic. UA and trigger unnecessary SIP traffic.
[RFC8292] defines a mechanism that allows a proxy to identity itself [RFC8292] defines a mechanism that allows a proxy to identity itself
to a PNS, by signing a JWT sent to the PNS using a key pair. The to a PNS, by signing a JWT sent to the PNS using a key pair. The
skipping to change at page 33, line 9 skipping to change at page 33, line 9
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 inserted in a Description: This feature-capability indicator, when inserted 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
response to a REGISTER request, indicates that the entity response to a REGISTER request, denotes that the entity
associated with the indicator supports the SIP push mechanism associated with the indicator supports the SIP push mechanism
and the type of push notification service indicated by the and the type of push notification service conveyed by the
indicator value. When inserted in a 555 (Push Notification indicator value. When inserted in a 555 (Push Notification
Service Not Supported) response to a REGISTER request, the Service Not Supported) response to a REGISTER request, the
indicator indicates that the entity associated with the indicator denotes that the entity associated with the
indicator supports the SIP push mechanism, and the type of push indicator supports the SIP push mechanism, and the type of push
notification service indicated by the indicator value. notification service conveyed by the indicator value.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
14.3.2. sip.vapid 14.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 inserted in a Description: This feature-capability indicator, when inserted in a
SIP 2xx response to a SIP REGISTER request, indicates that the SIP 2xx response to a SIP REGISTER request, denotes that the
entity associated with the indicator supports the Voluntary entity associated with the indicator supports the Voluntary
Application Server Identification (VAPID) mechanism when the Application Server Identification (VAPID) mechanism when the
entity requests that a push notifications is sent to a SIP UA. entity requests that a push notifications is sent to a SIP UA.
The indicator value is a public key identifying the entity, The indicator value is a public key identifying the entity,
that can be used by a SIP UA to restrict subscriptions to that that can be used by a SIP UA to restrict subscriptions to that
entity. entity.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
skipping to change at page 34, line 11 skipping to change at page 34, line 11
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 inserted in a Description: This feature-capability indicator, when inserted in a
SIP 2xx response to a SIP REGISTER request, indicates that the SIP 2xx response to a SIP REGISTER request, denotes that the
entity associated with the indicator expects to receive entity associated with the indicator expects to receive
binding-refresh REGISTER requests for the binding from the SIP binding-refresh REGISTER requests for the binding from the SIP
UA associated with the binding before the binding expires, even UA associated with the binding before the binding expires, even
if the entity does not request that a push notification is sent if the entity does not request that a push notification is sent
to the SIP UA in order to trigger the binding-refresh REGISTER to the SIP UA in order to trigger the binding-refresh REGISTER
requests. The indicator value indicates the minimum time requests. The indicator value conveys the minimum time
(given in seconds), prior to the binding expiration when the UA (given in seconds), prior to the binding expiration when the UA
MUST send the REGISTER request. MUST send the REGISTER request.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
14.3.4. sip.pnspurr 14.3.4. sip.pnspurr
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.pnspurr Name: sip.pnspurr
Description: This feature-capability indicator, when inserted in a Description: This feature-capability indicator, when inserted in a
SIP 2xx response to a SIP REGISTER request, indicates that SIP 2xx response to a SIP REGISTER request, conveys that
the entity associated with the indicator will store information the entity associated with the indicator will store information
that can be used to associate a mid-dialog SIP request with the that can be used to associate a mid-dialog SIP request with the
binding information in the REGISTER request. The indicator binding information in the REGISTER request. The indicator
value is an identifier that can be used a key to retrieve the value is an identifier that can be used a key to retrieve the
binding information. binding information.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
skipping to change at page 35, line 18 skipping to change at page 35, line 18
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 inserted in the Contact header field media feature tag, when inserted in the Contact header field
of a SIP REGISTER request, indicates that the SIP UA of a SIP REGISTER request, conveys that the SIP UA
associated with the tag is able to send binding-refresh associated with the tag is able to send binding-refresh
REGISTER requests associated with the registration without REGISTER requests associated with the registration without
being awaken by push notifications. being awakened 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 will not be requested to be sent feature tag, push notifications will not be requested to be sent
to the client. to the client.
skipping to change at page 36, line 27 skipping to change at page 36, line 27
------- -------------------------------------- ---------- ------- -------------------------------------- ----------
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]
15. Acknowledgements 15. 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, Yehoshua Gev and Jean Mahoney for
and providing useful feedback. reading the text, and providing useful feedback.
16. References 16. References
16.1. Normative References 16.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>.
 End of changes. 94 change blocks. 
312 lines changed or deleted 299 lines changed or added

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