draft-ietf-sipcore-sip-push-22.txt   draft-ietf-sipcore-sip-push-23.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: July 20, 2019 Metaswitch Networks Expires: July 25, 2019 Metaswitch Networks
January 16, 2019 January 21, 2019
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-22 draft-ietf-sipcore-sip-push-23
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 suspended Session Initiation Protocol (SIP) User Agents
(UAs), using push notifications, for the UA to be able to send (UAs), using push notifications, for the UA to be able to send
binding-refresh REGISTER requests and to receive receive incoming SIP binding-refresh REGISTER requests and to receive receive incoming SIP
requests. The document defines new SIP URI parameters and new requests. The document defines new SIP URI parameters and new
feature-capability indicators that can be used in SIP messages to feature-capability indicators that can be used in SIP messages to
indicate support of the mechanism defined in this document, to indicate support of the mechanism defined in this document, to
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 20, 2019. This Internet-Draft will expire on July 25, 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 17 skipping to change at page 2, line 17
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 7 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 7
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 7 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 7
4.1. Request Push Notifications from Network . . . . . . . . . 7 4.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Query Network Push Notification Capabilities . . . . . . 10 4.1.1. Request Push Notifications . . . . . . . . . . . . . 8
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Disable Push Notifications . . . . . . . . . . . . . 9
5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Receive Push Notifications . . . . . . . . . . . . . 10
5.2. Trigger Periodic Binding Refresh . . . . . . . . . . . . 11 4.1.4. Sending Binding-Refresh Requests Using Non-Push
5.3. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 12 Mechanism . . . . . . . . . . . . . . . . . . . . . . 10
5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 12 4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 11
5.3.2. Initial Request for Dialog or Stand-Alone Request . . 14 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 12
6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 17 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 12
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 19 5.2. SIP Request Push Queue . . . . . . . . . . . . . . . . . 12
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 19 5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 12
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 19 5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 13
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 19 5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 13
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 20 5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 14
6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 20 5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 14
7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 21 5.6.2. Initial Request for Dialog or Stand-Alone Request . . 17
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 20
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 22
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 22
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 22
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 22
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 23
6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 23
7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 24
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. 555 (Push Notification Service Not Supported) Response 8.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 21 8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 25
8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 22 8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 25
8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 22 8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 26
8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 23 8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 26
8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 23 8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 26
8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 23 8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 27
9. PNS Registration Requirements . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . 24 Push Notification service . . . . . . . . . . . . . . . . . . 27
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 . . 25 Firebase Cloud Messaging (FCM) push notification service . . 28
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) . . . . . . . . . . 25 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 29
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 27 14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30
14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 27 14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 30
14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 27 14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 30
14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 27 14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 31
14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 28 14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 31
14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 28 14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 31
14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 28 14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 31
14.2.1. 555 (Push Notification Service Not Supported) . . . 28 14.2.1. 555 (Push Notification Service Not Supported) . . . 31
14.3. SIP Global Feature-Capability Indicator . . . . . . . . 28 14.3. SIP Global Feature-Capability Indicator . . . . . . . . 32
14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 28 14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 32
14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 29 14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 32
14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 29 14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 33
14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 30 14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 33
14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 31 14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 34
14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 31 14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 34
14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 31 14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 35
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . 32 16.1. Normative References . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
In order to save resources (e.g., battery life) some devices In order to save resources (e.g., battery life) some devices
(especially mobile devices) and operating systems will suspend (especially mobile devices) and operating systems will suspend
applications when not used. In some cases, internal timers cannot be applications when not used. In some cases, internal timers cannot be
used to wake such applications, nor will incoming network traffic used to wake such applications, nor will incoming network traffic
wake the application. Instead, one way to wake the application is by wake the application. Instead, one way to wake the application is by
using a Push Notification Service (PNS). A PNS is a service from using a Push Notification Service (PNS). A PNS is a service from
where a user application can receive messages, referred to as push where a user application can receive messages, referred to as push
notifications, requested by other applications. Push notifications notifications, requested by other applications. Push notifications
might contain payload data, depending on the application. An might contain payload data, depending on the application. An
application can requests that a push notification is sent to a single application can request that a push notification is sent to a single
user application, or to multiple user applications. user application, or to multiple user applications.
Typically each operating system uses a dedicated PNS. For example, Typically each operating system uses a dedicated PNS. For example,
Apple iOS devices use the Apple Push Notification service (APNs) Apple iOS devices use the Apple Push Notification service (APNs)
while Android devices use the Firebase Cloud Messaging (FCM) service. while Android devices use the Firebase Cloud Messaging (FCM) service.
Because of the restrictions above, Session Initiation Protocol (SIP) Because of the restrictions above, Session Initiation Protocol (SIP)
User Agents (UAs) [RFC3261] can not be awoken, in order to send User Agents (UAs) [RFC3261] can not be awoken, in order to send
binding-refresh SIP REGISTER requests and to receive incoming SIP binding-refresh SIP REGISTER requests and to receive incoming SIP
requests, without using a PNS to wake the UA in order to perform requests, without using a PNS to wake the UA in order to perform
skipping to change at page 4, line 43 skipping to change at page 4, line 51
request and receive the incoming SIP request. The proxy will receive request and receive the incoming SIP request. The proxy will receive
the REGISTER request. If the push notification request was triggered the REGISTER request. If the push notification request was triggered
by a SIP request addressed towards the UA (see above), once the by a SIP request addressed towards the UA (see above), once the
REGISTER request has been accepted by the SIP registrar [RFC3261], REGISTER request has been accepted by the SIP registrar [RFC3261],
and the associated SIP 2xx response has been forwarded by the proxy and the associated SIP 2xx response has been forwarded by the proxy
towards the UA, the proxy can forward the SIP request towards the UA towards the UA, the proxy can forward the SIP request towards the UA
using normal SIP routing procedures. In some cases the proxy can using normal SIP routing procedures. In some cases the proxy can
forward the SIP request without waiting for the SIP 2xx response to forward the SIP request without waiting for the SIP 2xx response to
the REGISTER request. Note that this mechanism necessarily adds the REGISTER request. Note that this mechanism necessarily adds
delay to responding to requests requiring push notification. The delay to responding to requests requiring push notification. The
consequences of that delay are discussed in Section 5.3.2. 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.
skipping to change at page 7, line 47 skipping to change at page 7, line 47
The format of the PRID varies depending on the PNS. The format of the PRID varies depending on the PNS.
The details regarding discovery of the PNS, and the procedures The details regarding discovery of the PNS, and the procedures
regarding the push notification registration and maintenance are regarding the push notification registration and maintenance are
outside the scope of this document. The information needed to outside the scope of this document. The information needed to
contact the PNS is typically pre-configured in the operating system contact the PNS is typically pre-configured in the operating system
of the device. of the device.
4. SIP User Agent (UA) Behavior 4. SIP User Agent (UA) Behavior
4.1. Request Push Notifications from Network 4.1. REGISTER
The procedures in this section apply to bindings associated with a This section describes how a SIP UA sends SIP REGISTER requests
given PNS. (initial REGISTER request for a binding, or a binding-refresh
REGISTER request) in order to request and disable push notifications
from a SIP network, and to query the types of PNSs supported by the
SIP network.
The mechanism defined in this document assumes that when a SIP UA Unless specified otherwise, the normal SIP UA registration procedures
registers with a PNS it has received the PRID (using the protocol and [RFC3261] apply. The additional procedures described in this section
procedures associated with the PNS). Then, if the UA wants to apply when the REGISTER request contains a pn-provider SIP URI
receive push notifications (requested by the proxy), the UA MUST parameter in the Contact header field URI of the request.
include the following SIP URI parameters in the SIP Contact header
field URI of the REGISTER request: pn-provider, pn-prid and pn-param
(if required for the specific PNS). The pn-provider URI parameter
identifies the type of PNS, the pn-prid URI parameter contains the
PRID value and the pn-param URI parameter contains additional PNS-
specific information.
NOTE: If the SIP UA creates multiple bindings (e.g., one for IPv4 and The procedures in this section apply to individual bindings
one for IPv6), since a push notification will trigger to UA to [RFC3261]. If a UA creates multiple bindings (e.g., one for IPv4 and
refresh all bindings, it is preferable if one can ensure that all one for IPv6) the UA needs to perform the procedures for each
bindings expire at the same time. That will help preventing that binding.
some bindings are refreshed earlier than needed.
When the UA receives a 2xx response to the REGISTER request, if the NOTE: If a SIP UA creates multiple bindings, since a push
response contains a Feature-Caps header field [RFC6809] with a notification will trigger the UA to refresh all bindings, it is
'sip.pns' feature-capability indicator with a parameter value preferable if one can ensure that all bindings expire at the same
identifying the same type of PNS that was identified by the pn- time. That will help preventing that some bindings are refreshed
provider URI parameter in the REGISTER request, the UA can assume earlier than needed.
that a SIP proxy will request that a push notification is sent to the
UA. In other cases, the UA MUST NOT assume that the proxy will
request that push notifications is sent to the UA, and the actions
taken by the UA might be dependent on implementation or deployment
architecture, and are outside the scope of this document.
In addition, if the response contains a Feature-Caps header field For privacy and security reasons, a UA MUST NOT insert the SIP URI
with a 'sip.vapid' feature-capability indicator, the proxy supports parameters (except for the pn-purr parameter) defined in this
use of the Voluntary Application Server Identification (VAPID) specification in non-REGISTER request, to prevent the PNS information
mechanism [RFC8292] to restrict push notifications to the proxy. associated with the UA from reaching the remote peer. For example,
the UA MUST NOT insert the pn-prid SIP URI parameter in the Contact
header field URI of an INVITE request. REGISTER requests will not
reach the remote peer, as they will be terminated by the registrar of
the UA. However, the registrar MUST still ensure that the parameters
are not sent to other users, e.g., using the SIP event package for
registrations mechanism [RFC3680]. See Section 13 for more
information.
4.1.1. Request Push Notifications
This section describes the procedures when a SIP UA requests push
notifications from the SIP network. The procedures assume that the
UA has retrieved a PRID from a PNS. The procedures how the UA
retrieves the PRID from the PNS are PNS-specific, and outside the
scope of this specification. See PNS specific documentation for more
details.
If a SIP UA wants to use push notifications for other usages than to
trigger binding-refresh REGISTER requests (e.g., for sending periodic
subscription-refresh SUBSCRIBE requests [RFC6665]), this
specification does not define a mechanism to explicitly request push
notifications from the SIP network for such usages, and how to
distinguish push notifications associated with such usages from the
push notifications used to trigger binding-refresh REGISTER requests.
However, by using the same refresh interval that is used for the
binding-refreshes, the UA can perform actions associated with such
usages (in addition to sending a binding-refresh REGISTER request)
whenever it receives a push notification.
When a UA requests push notifications, the UA MUST insert the
following SIP URI parameters in the SIP Contact header field URI of
the REGISTER request: pn-provider, pn-prid and pn-param (if required
for the specific PNS). The pn-provider URI parameter parameter
indicates the type of PNS to be used for the push notifications.
If the UA receives a 2xx response to the REGISTER request that
contains a Feature-Caps header field [RFC6809] with a 'sip.pns'
feature-capability indicator, with a indicator value identifying the
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
network will request that push notifications are sent to the UA. In
addition, if the samd Feature-Caps header field contains a
'sip.vapid' feature-capability indicator, it indicates that the proxy
supports use of the Voluntary Application Server Identification
(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.
When the UA receives a push notification, it MUST send a binding- If the UA receives a non-2xx response to the REGISTER, or if the UA
refresh REGISTER request, using normal SIP procedures. Once the UA receives a 2xx response that does not contain a Feature-Caps header
has received a 2xx response to the REGISTER request, the UA might field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA
receive a SIP request for a new dialog (e.g., a SIP INVITE), or a MUST NOT assume a the proxy will request that push notifications are
stand-alone SIP request (e.g., a SIP MESSAGE), if such SIP request sent to the UA. The actions taken by the UA in such cases are
triggered the push notification. Note that, depending on which outside the scope of this document.
transport protocol is used, the SIP request might reach the UA before
the REGISTER response.
If the SIP UA has created multiple bindings (e.g., one for IPv4 and If the PRID is only valid for a limited time then the UA is
one for IPv6), the UA MUST send a binding-refresh REGISTER request responsible for retrieving a new PRID from the PNS and sending a
for each of those bindings when it receives a push notification. 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
PRID, the UA MUST disable the push notifications associated with the
PRID (Section 4.1.2).
If the UA is able to send binding-refresh REGISTER requests using a 4.1.2. Disable Push Notifications
When a UA wants to disable previously requested push notifications,
the UA SHOULD remove the binding [RFC3261], unless the UA is no
longer able to perform SIP procedures (e.g., due to a forced shutdown
of the UA). When the UA sends the REGISTER request for removing the
binding, the UA MUST include the pn-pric SIP URI parameter in the
Contact header field URI of the REGISTER request, in order to inform
the SIP network that the UA no longer wants to receive push
notifications associated with the PRID.
4.1.3. Receive Push Notifications
When a UA receives a push notification, the UA MUST send a binding-
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
request that it inserted when it requested push notifications
(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 SIP URI parameter of the binding-refresh REGISTER request.
Once the UA has received a 2xx response to the REGISTER request, the
UA might receive a SIP request for a new dialog (e.g., a SIP INVITE),
or a stand-alone SIP request (e.g., a SIP MESSAGE), if such SIP
request has triggered a proxy to request that the push notification
is sent to the UA.. Note that, depending on which transport protocol
is used, the SIP request might reach the UA before the REGISTER
response.
If the SIP UA has created multiple bindings, the UA MUST send a
binding-refresh REGISTER request for each of those bindings when it
receives a 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 the UA can discard the payload, but the UA will still send a
binding-refresh REGISTER request.
4.1.4. Sending Binding-Refresh Requests Using Non-Push Mechanism
If a UA is able to send binding-refresh REGISTER requests using a
non-push mechanism (e.g., using an internal timer that periodically non-push mechanism (e.g., using an internal timer that periodically
wakes the UA), the UA MUST insert a 'sip.pnsreg' media feature tag wakes the UA) the UA MUST insert a 'sip.pnsreg' media feature tag
[RFC3840] in each Contact header field URI of each REGISTER request. [RFC3840] in the Contact header field of each REGISTER request.
Then, if the response to the REGISTER request contains a 'sip.pnsreg'
feature-capability indicator with an indicator value, the UA If the UA receives a 2xx response to the REGISTER request that
refreshes the binding prior to the binding expires. The indicator contains a Feature-Caps header field with a 'sip.pnsreq' feature-
value indicates a minimum time (given in seconds), prior to the capability indicator, the UA MUST send a binging-refresh REGISTER
binding expires when the UA MUST send the REGISTER request. Even if request prior to binding expiration. The indicator value indicates
the UA is able to to send REGISTER requests using a non-push the minimum time (given in seconds), prior to the binding expiration
mechanism, the UA MUST still send a REGISTER request when it receives when the UA MUST send the REGISTER request.
a push notification, following the procedures in this section. If
the REGISTER response does not contain a a 'sip.pnsreg' feature- If the UA receives a 2xx response to the REGISTER request that does
not contain a Feature-Caps header field with a 'sip.pnsreq' feature-
capability indicator, the UA SHOULD only send a binding-refresh capability indicator, the UA SHOULD only send a binding-refresh
REGISTER request when it receives a push notification (even if the UA REGISTER request when it receives a push notification (even if the UA
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.
NOTE: If the UA uses a non-push mechanism to wake and send a binding 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
REGISTER request whenever it receives a push notification
(Section 4.1.3).
NOTE: If the UA uses a non-push mechanism to wake and send a binding-
refresh REGISTER request, such REGISTER request will update the refresh REGISTER request, such REGISTER request 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.3.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 and
use push notification to wake the UA to process incoming calls. use push notification to wake the UA to process incoming calls.
NOTE: This specification does not define any usage of a push 4.1.5. Query Network PNS Capabilities
notification payload. As defined in Section 5.3.2, a proxy must not
include any payload in the push notification request. If a SIP UA
receives a push notification that contains a payload the UA can
discard the payload, but the UA will still send a binding-refresh
REGISTER request.
NOTE: If the SIP UA application wants to use push notifications for This section describes how a SIP UA can query the types of PNSs
other purposes than to trigger binding-refresh requests, it needs to supported by a SIP network, and PNS-related capabilities (e.g.,
be able to distinguish between the different purposes when receiving support of the VAPID mechanism). When a UA performs a query, it does
push notifications. Mechanisms for doing that are outside the scope not request push notifications from the SIP network. Therefore, the
of this specification. UA can perform the query before it has registered to a PNS and
received a PRID.
As long as the UA wants to receive push notifications (requested by In order to perform a query, the UA MUST insert a pn-provider SIP URI
the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param parameter in the Contact header field URI of the REGISTER request:
(if required for the specific PNS provider) SIP URI parameter in the
SIP Contact header field URI of each binding-refresh REGISTER
request. Note that, in some cases, the PNS might update the PRID
value, in which case the UA will include the new value in the pn-prid
SIP URI parameter in the binding-refresh REGISTER request.
If the UA no longer wants to receive push notifications (requested by If the UA inserts a pn-provider parameter value, indicating
the proxy), the UA MUST send a binding-refresh REGISTER request support of a type of PNS, the SIP network will only inform the UA
without including the SIP URI parameters described above, or the UA whether that type of PNS is supported.
MUST remove the registration, unless the UA is no longer able to If the UA does not insert a pn-provider parameter value (i.e., it
perform SIP procedures (e.g., due to a forced shutdown). inserts an "empty pn-provider parameter") the SIP network will
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.
Note that it is not possible to insert multiple parameter values
in the pn-provider parameter.
If a UA's subscription to a PNS (and the associated PRID) is only The UA MUST NOT insert a pn-prid SIP URI parameter in the Contact
valid for a limited time then the UA is responsible for retrieving header field URI of the REGISTER request.
new subscription details from the PNS and sending a REGISTER request
with the updated pn parameters to the proxy prior to the expiry of
the existing subscription. If a UA's subscription to a PNS expires
then the UA MUST send a REGISTER without the pn parameters (to tell
the proxy that it no longer wants push notifications) or terminate
the registration. The exact mechanisms for expiry and renewal of
PRIDs will be PNS-specific and are outside the scope of this
document.
For privacy and security reasons, the UA MUST NOT include the SIP URI If the UA receives a 2xx response to the REGISTER request, the
parameters defined in this document in non-REGISTER request, to response will contain one or more Feature-Caps header fields with a
prevent the PNS information associated with the UA from reaching the 'sip.pns' feature-capability indicator, indicating the types of PNSs
remote peer. For example, the UA MUST NOT include the SIP URI supported by the SIP network. If the UA inserted a pn-provider SIP
parameters in the Contact header field of an INVITE request. URI parameter value in the REGISTER request, the response will only
REGISTER requests will not reach the remote peer, as they will be indicate whether the SIP network supports the type of PNS supported
terminated by the registrar of the UA. However, the registrar MUST by the UA.
still ensure that the parameters are not sent to other users, e.g.,
using the SIP event package for registrationss mechanism [RFC3680].
See Section 13 for more information.
4.2. Query Network Push Notification Capabilities If the UA receives a 555 (Push Notification Service Not Supported)
response to the REGISTER request, the response will contain the
response will contain one or more Feature-Caps header fields with a
'sip.pns' feature-capability indicator, indicating the types of PNSs
supported by the SIP network.
A SIP UA might need to query the SIP network for push notification NOTE: It is optional for a UA to perform a query before it requests
capabilities (e.g., related to VAPID) before it registers with the push notifications from the SIP network.
PNS, and before it indicates that it wants to receive push
notifications. The UA can do so by only including the pn-provider
SIP URI parameter in the SIP Contact header field URI of the REGISTER
request, but without including the pn-prid SIP URI parameter. Later,
once the UA has received a response to the REGISTER request with the
push notification information from the network, if the UA wants to
receive push notifications, the UA will send a binding-refresh
REGISTER request, including all pn- SIP URI parameters required by
the specific PNS, following the procedures in Section 4.1.
5. SIP Proxy Behavior 5. SIP Proxy Behavior
5.1. PNS 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
of PNS, while in other cases there might be multiple providers. The
pn-param SIP URI parameter will provide more details associated with
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. Trigger Periodic Binding Refresh 5.2. SIP Request Push Queue
In order to request that a push notification is sent to a SIP UA that When a SIP proxy receives a SIP request, addressed towards a UA, that
will trigger the UA to send binding-refresh SIP REGISTER requests, will trigger the proxy to request that a push notification is sent to
the SIP proxy needs to have information about when a registration the UA, the proxy will place the request in a queue referred to as
will expire. The proxy needs to be able to retrieve the information the SIP Request Push Queue. A SIP request is removed from the queue
from the registrar using some mechanism, or run its own registration once the proxy either forwards the request towards the UA or when the
timers. Such mechanisms are outside the scope of this document, but proxy sends an error response to the request. The detailed
could be implemented e.g., using the SIP event package for procedures are described in the sections below.
registrations mechanism [RFC3680].
Exactly how the SIP Request Push Queue is implemented is outside the
scope of this document. One option is to use the PRID as a key to
search for SIP requests in the queue. Note that mid-dialog requests
(Section 6) do not carry the PRID in the SIP request itself.
5.3. SIP URI Comparison Rules
When a SIP proxy compares two SIP URIs, the proxy uses the URI
comparison rules defined in [RFC3261], with the following addition:
the pn-prid, pn-provider and pn-param SIP URI parameters MUST also
match in order for the comparison to be successful.
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
the comparison successful, based on local policy. This can occur in
a race condition, if a UA modified some parts of the Contact URI in
the most recent REGISTER request, but the Request-URI of a SIP
request addressed towards the UA still contains the old parts.
5.4. Indicate Support of Type of PNS
A SIP proxy uses feature-capability indicators [RFC6809] to indicate
support of types of PNSs, and additional features (e.g., VAPID)
associated associated with a type of PNS. A proxy MUST use a
separate Feature-Cap header fields for each supported type of PNS. A
feature-capability indicator that indicates support of an additional
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
the type of PNS.
This specification defines the following feature-capability
indicators that a proxy can use to indicate support of additional
features associated with a given type of PNS: 'sip.vapid',
'sip.pnsreg' and 'sip.pnspurr'. These feature-capability indicators
MUST only be inserted in a Feature-Caps header field that also
contains a 'sip.pns' feature-capability indicator.
5.5. Trigger Periodic Binding Refresh
In order to request that a push notification is sent to a SIP UA, a
SIP proxy needs to have information about when a binding will expire.
The proxy needs to be able to retrieve the information from the
registrar using some mechanism, or run its own registration timers.
Such mechanisms are outside the scope of this document, but could be
implemented e.g., using the SIP event package for registrations
mechanism [RFC3680].
When the proxy receives an indication that the UA needs to send a When the proxy receives an indication that the UA needs to send a
binding-refresh REGISTER request, the proxy 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 registration expires. It is RECOMMENDED that registrar before the binding expires. It is RECOMMENDED that the
the proxy requests the push notification at least 120 seconds before proxy requests the push notification at least 120 seconds before the
the registration 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 for sending that it is able to wake using a non-push mechanism in order to send
binding-refresh REGISTER requests, if the proxy does not receive a binding-refresh REGISTER requests, and if the proxy does not receive
REGISTER request prior to 120 seconds before the registration a REGISTER request prior to 120 seconds before the binding expires,
expires, the proxy MAY request that a push notification is sent to the proxy MAY request that a push notification is sent to the UA, to
the UA, to trigger the UA to send a REGISTER request. trigger the UA to send a binding-refresh REGISTER request.
NOTE: As described in Section 4.2, a SIP 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.3.2). not provided a pn-prid SIP URI parameter (Section 5.6.2).
If the proxy receives information that a registration has expired, If the proxy receives information that a binding associated with a
the proxy MUST NOT request that further push notifications are sent PRID has expired, or that a binding has been removed, the proxy MUST
to the UA. NOT request that further push notifications are sent to the UA using
that PRID.
5.3. SIP Requests 5.6. SIP Requests
5.3.1. REGISTER 5.6.1. REGISTER
The procedures in this section apply when the SIP proxy receives a This section describes how a SIP proxy processes SIP REGISTER
SIP REGISTER request (initial REGISTER request for a registration, or requests (initial REGISTER request for a binding, or a binding-
a binding-refresh REGISTER request) that contains a pn-provider SIP refresh REGISTER request).
URI parameter identifying a type of PNS. If the proxy receives a
REGISTER request that does not contain a pn-provider SIP URI
parameter, or that removes the registration, the proxy MUST NOT
request that a push notification is sent to the UA associated with
the REGISTER request or perform any other procedures in this section.
As described in Section 4.2, a SIP UA might send a REGISTER request The procedures in this section apply when the REGISTER request
without including a pn-prid SIP URI parameter in the Contact header contains a pn-provider SIP URI parameter in the Contact header field
field URI, in order to retrieve push notification capabilities from URI of the request. In other cases the proxy MUST skip the procdures
the network before the UA the proxy will request that a push in this section, and process the REGISTER request using normal SIP
notification is sent to the UA. The procedures in this section apply procedures.
to both the case when the REGISTER request contains a pn-prid SIP URI
parameter, and when it does not.
When the proxy receives a REGISTER request, if the REGISTER request 5.6.1.1. Request Push Notifications
This section describes the SIP proxy procedures when a SIP UA
requests push notifications from the SIP network.
The procedures in this section apply when the SIP REGISTER request
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.
When a proxy receives a REGISTER request, if the REGISTER request
contains a Feature-Caps header field with a 'sip.pns' feature- contains a Feature-Caps header field with a 'sip.pns' feature-
capability indicator, it indicates that a proxy between this proxy capability indicator, it indicates that a proxy between this proxy
and the UA supports requesting that push notifications are sent to and the UA supports the type of PNS supported by the UA, and will
the UA. The proxy MUST skip the rest of the procedures in this request that push notifications are sent to the UA. In such case,
section, and process the REGISTER request using normal SIP the proxy MUST skip the rest of the procedures in this section, and
procedures. process the REGISTER request using normal SIP procedures.
If the proxy considers the requested registration expiration interval When a proxy receives a REGISTER request, and the request does not
[RFC3261] to be too short, the proxy MUST either send a 423 (Interval contain a Feature-Caps header field with a 'sip.pns' feature-
Too Brief) response to the REGISTER request, or skip the rest of the capability indicator, the proxy processes the request according to
procedures in this section and process the REGISTER request using the procedures below:
normal SIP procedures. If the proxy sends a 423 (Interval Too Brief)
response, the proxy SHOULD insert a Feature-Caps header field with a
'sip.pns' feature-capability indicator in the response, identifying
each type of PNS that the proxy supports. Similarly, when the proxy
receives a 2xx response to the REGISTER request (see below), if the
proxy considers the registration expiration interval indicated by the
registrar too short, the proxy MUST NOT insert a Feature-Caps header
field with a 'sip.pns' feature-capability indicator in the response,
and the proxy MUST NOT request push notifications associated with the
registration.
A registration expiration interval MUST be considered too short if o If the proxy does not support the type of PNS supported by the UA,
the the registration would expire before the proxy would request that or if the REGISTER request does not contain all information
a push notification is sent to the UA, in order to trigger the UA to required for the type of PNS, the proxy SHOULD forward the request
send a REGISTER request. The proxy MAY consider the interval too towards the registrar and skip the rest of the procedures in this
short based on its own policy so as to reduce load on the system. section. If the proxy knows (by means of local configuration)
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
(Push Notification Service Not Supported) response instead of
forwarding the request.
o If the proxy supports the type of PNS supported by the UA, but
considers the requested binding expiration interval [RFC3261] to
be too short (see below), the proxy MUST either send a 423
(Interval Too Brief) response to the REGISTER request or forward
the request towards the registrar and skip the rest of the
procedures in this section. If the proxy sends a 423 (Interval
Too Brief) response, the proxy SHOULD insert one or more Feature-
Caps header fields with a 'sip.pns' feature-capability indicator
in the response, indicating each type of PNS that the proxy
supports.
o If the proxy supports the type of of PNS supported by the UA, the
proxy MUST indicate support of that type of PNS (Section 5.4) in
the REGISTER request before it forwards the request towards the
registrar. This will inform proxies between the proxy and the
registrar that the proxy supports the type of PNS supported by the
UA, and that the proxy will request that push notifications are
sent to the UA.
Otherwise, if the pn-provider SIP URI parameter identifies a type of A binding expiration interval MUST be considered too short if the the
PNS that the proxy does not support, or if the REGISTER request does binding would expire before the proxy would request that a push
not contain all additional information required for the specific type notification is sent to the UA, in order to trigger the UA to send a
of PNS, the proxy SHOULD send a SIP 555 (Push Notification Service binding-refresh REGISTER request. The proxy MAY consider the
Not Supported) response to the REGISTER request, unless the proxy interval too short based on its own policy so as to reduce load on
knows (based on local configuration) that another proxy that will the system.
receive the REGISTER request supports the type of PNS, in which case
it MAY forward the request. If the proxy sends a SIP 555 (Push
Notification Service Not Supported) response Section 8.1, the proxy
SHOULD insert a Feature-Caps header field with a 'sip.pns' feature-
capability indicator in the response, identifying the type of each
PNS that the proxy supports. The decision whether to forward the
request, or to send a response, is done based on local policy.
If the proxy supports the type of PNS identified by the pn-provider If the proxy sends a SIP 555 (Push Notification Service Not
SIP URI parameter, the proxy MUST insert a Feature-Caps header field Supported) response, the proxy SHOULD indicate each type of PNS that
with a 'sip.pns' feature-capability indicator, identifying the type the proxy supports in the response.
of PNS, in the REGISTER request before forwarding the REGISTER
request towards the registrar. This will inform proxies that are not
between the push proxy and the UA that the proxy supports, and will
request (if the Contact header field URI of the REGISTER request
contains a pn-prid SIP URI parameter), that push notifications are
sent to the UA.
If the proxy inserted a Feature-Caps header field with a 'sip.pns' When a proxy receives a 2xx response to the REGISTER request, if the
feature-capability indicator in the REGISTER request (see above), if proxy indicated support of a type of PNS in the REGISTER request (see
the proxy receives a 2xx response to the REGISTER request, the proxy above), the proxy performs the following actions:
MUST insert a Feature-Caps header field with a 'sip.pns' feature-
capability indicator in the response, identifying the type of PNS.
This will inform the UA that the proxy supports, and will request (if
the Contact header field URI of the REGISTER request contained a pn-
prid SIP URI parameter), that push notifications are sent to the UA.
The proxy MUST indicate support only of the same PNS that was
identified in the pn-provider SIP URI parameter in the REGISTER
request. If the proxy receives a SIP 555 (Push Notification Service
Not Supported) response, the proxy SHOULD insert a Feature-Caps
header field with a 'sip.pns' feature-capability indicator in the
response, identifying the type of each PNS that the proxy supports.
In addition, if the proxy receives a 2xx response to the REGISTER o If the proxy considers the binding expiration interval indicated
request: by the registrar too short (see above), the proxy forwards the
response towards the UA and MUST skip the rest of the procedures
in this section.
o The proxy MUST indicate support of the same type of PNS in the
REGISTER response. In addition:
o if the proxy supports, and will use, the VAPID mechanism, the * If the proxy supports the VAPID mechanism [RFC8292], the proxy
proxy MUST insert a Feature-Caps header field with a 'sip.vapid' MUST indicate support of the mechanism, using the 'sip.vapid'
feature-capability indicator in the response. The header field feature-capability indicator, in the REGISTER response. The
parameter contains the public key identifying the proxy [RFC8292]. indicator value contains the public key identifying the proxy .
The proxy MUST determine whether the PNS supports the VAPID The proxy MUST determine whether the PNS provider supports the
mechanism before it inserts the feature-capability indicator. VAPID mechanism before it indicates support of it.
o 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 include a 'sip.pnsreg' feature- REGISTER request, the proxy SHOULD insert a 'sip.pnsreg'
capability indicator with an indicator value bigger than 120 in feature-capability indicator with an indicator value bigger
the response, unless the proxy always wants to request push than 120 in the response, unless the proxy always wants to
notifications to trigger the UA to send a REGISTER request. request that push notifications are sent to the UA in order to
trigger the UA to send a binding-refresh REGISTER request.
5.3.2. Initial Request for Dialog or Stand-Alone Request 5.6.1.2. Query Network PNS Capabilities
The procedures in this section apply when the SIP proxy has indicated This section describes the SIP proxy procedures when a SIP UA queries
that it supports, and will request, that push notifications are sent about the push notification support in the SIP network
to the SIP UA. (Section 4.1.5).
The procedures in this section apply when the REGISTER request
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
REGISTER request.
When a proxy receives a REGISTER request, if the pn-provider SIP URI
parameter contains a parameter value that indicates the type of PNS
supported by the UA, the proxy MUST perform the following actions:
If the proxy supports the type of of PNS supported by the UA, the
proxy MUST indicate support of that type of PNS (Section 5.4) in
the REGISTER request before it forwards the request towards the
registrar. This will inform proxies betwen the proxy and the
registrar that the proxy supports 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
indicating support of one or more types of PNSs, the proxy
forwards the request towards the registrar.
If the proxy does not support the type of PNS supported by the UA,
and if the REGISTER request does not contain Feature-Caps header
fields indicating support of one or more types of PNSs, the proxy
MUST either forward the request towards the registrar, or send a
SIP 555 (Push Notification Service Not Supported) response towards
the UA. The proxy MUST NOT send a SIP 555 (Push Notification
Service Not Supported) response unless it knows (by means of local
configuration) that no other proxy supports any of the types of
PNSs supported by the UA.
If the proxy sends a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD indicate each type of PNS that
the proxy supports in the response.
When a proxy receives a REGISTER request, if the pn-provider SIP URI
parameter does not contain a parameter value, the proxy MUST indicate
support of each type of PNS supported by the proxy before it forwards
the request towards the registrar.
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
request (see above), the proxy MUST indicate support of the same set
of types of PNSs in the response. In addition, if the proxy supports
the VAPID mechanism for one or more types of PNSs, the proxy MUST
indicate support of the mechanism for thoses PNSs in the response.
5.6.2. Initial Request for Dialog or Stand-Alone Request
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
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 PRID included that a push notification is sent to the UA, using the information in
in the pn-prid SIP URI parameter and the PNS identified by the pn- the pn- SIP URI parameters. The proxy then places the SIP request in
provider SIP URI parameter. the SIP Request Push Queue (Section 5.2). The push notification will
trigger the 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 store the Contact URI of the REGISTER request during the
lifetime of the REGISTER transaction.
The push notification will trigger the UA to send a binding-refresh NOTE: If the proxy receives a SIP request does not contain the pn-
REGISTER request. The proxy will process the REGISTER request and SIP URI parameters listed above, the proxy processing of the request
the associated response as described in Section 5.3.1. In case of a is based on local policy. If the proxy also serves requests for UAs
2xx response to the REGISTER request, once the proxy has forwarded that do not use the SIP push mechanism, the proxy can forward the
the REGISTER response towards the UA, if the contact of the SIP request towards the UA. Otherwise the proxy can reject the request.
REGISTER request associated with the REGISTER response matches the
Request-URI of the SIP request to be forwarded, and the contact was
also present (and has not expired) in the REGISTER response, the
proxy can forward the SIP request towards the UA, using normal SIP
procedures. If the contact of the REGISTER request does not match
the Request-URI of the SIP request to be forwarded, or if the contact
was not present in the REGISTER response, the proxy MUST reject the
SIP request. It is RECOMMENDED that the proxy sends either a 404
(Not Found) response or a 480 (Temporarily Unavailable) response, but
other response codes can be used as well. This can happen if the UA
sends a binding-refresh REGISTER request that does not contain the
previously registered contact at the same time the registrar forwards
a SIP request towards a UA using the previously registered contact in
the Request-URI.
NOTE: If the SIP request does not contain the pn- parameters, the When the proxy receives a 2xx response to the REGISTER request, the
proxy processing of the request is based on local policy, e.g., proxy performs the following actions:
depending on whether the proxy servers requests towards UAs that do
not use the SIP push mechanism, in which case the proxy will forward
the request using normal SIP procedures. Otherwise the proxy might
reject the request.
When matching the Request-URI of the SIP request to be forwarded with The proxy processes the REGISTER response as described in
a contact of a REGISTER request, the proxy uses the URI comparison Section 5.6.1.
rules in [RFC8292], with the following addition: the pn-prid SIP URI The proxy checks whether the SIP Request Push Queue contains a SIP
parameter MUST also match. If the parameter is not present in the request associated with the REGISTER transaction. If the queue
Request-URI of the SIP request, or in the contact of the REGISTER, contains such request the proxy compares (Section 5.3) the Contact
there is no match. header field URI in the REGISTER response with the Request-URIs of
the SIP requests in the queue. If there is a match, the proxy
MUST remove the SIP request from the waiting queue and forward it
towards the UA.
The reason the proxy needs to wait for the REGISTER response before The reason the proxy needs to wait for the REGISTER response before
forwarding the SIP request is to make sure that the REGISTER request forwarding a SIP request towards a UA is to make sure that the
has been accepted by the registrar, and that the UA that initiated REGISTER request has been accepted by the registrar, and that the UA
the REGISTER request is authorized to receive messages for the that initiated the REGISTER request is authorized to receive messages
Request-URI. However, if the proxy is able to authorize the sender for the Request-URI.
of the REGISTER request, it does not need to wait for the associated
2xx response before it forwards the SIP request towards the UA. The
mechanism for authorizing the UA is outside the scope of this
document.
As both the SIP request to be forwarded towards the UA and the
binding-refresh REGISTER request triggered by the push notification
request will convey pn- SIP URI parameters associated with the SIP
registration, those can be used to match the SIP request with the
binding-refresh REGISTER request (even if other parts of the most
recent contact and the Request-URI of the SIP request do not match).
NOTE: The proxy needs to store (or be able to retrieve) the contact
of the most recent REGISTER 2xx response, to be able to compare it
with the Request-URI of the request to be forwarded towards the UA.
In case of non-2xx response to the REGISTER request, the proxy MUST If the proxy receives a non-2xx response to the REGISTER request, the
reject the SIP request.It is RECOMMENDED that the proxy sends either proxy compares the Contact URI stored from the REGISTER request (see
a 404 (Not Found) response or a 480 (Temporarily Unavailable) above) with the Request-URIs of the SIP requests in the SIP Request
response, but other response codes can be used as well. Push Queue. If there is a match, the proxy SHOULD remove the
associated request from the queue and send an error response to the
request. It is RECOMMENDED that the proxy sends either a 404 (Not
Found) response or a 480 (Temporarily Unavailable) response to the
SIP request, but other response codes can be used as well. However,
if the REGISTER response is expected to trigger a new REGISTER
request from the UA (e.g., if the registrar is requesting the UA to
perform authentication) the proxy MAY keep the SIP request in the
queue.
If the push notification request fails (see PNS-specific If the push notification request fails (see PNS-specific
documentation for details), the proxy MUST reject the SIP request. documentation for details), the proxy MUST remove the SIP request
It is RECOMMENDED that the proxy sends either a 404 (Not Found) from the queue and send an error response to the SIP request. It is
response or a 480 (Temporarily Unavailable) response, but other RECOMMENDED that the proxy sends either a 404 (Not Found) response or
response codes can be used as well. a 480 (Temporarily Unavailable) response, but other response codes
can be used as well.
If the proxy does not receive the REGISTER request from the UA within When the proxy has requested that a push notification is sent to a
a given time after the proxy has requested the push notification, the UA, if the proxy does not receive a REGISTER response with a Contact
proxy MUST reject the request with a 480 (Temporarily Unavailable) URI that matches the Request-URI of the SIP request, the transaction
response. The time value is set based on local policy. timer of the SIP request will eventually time out. When that happens
the proxy MUST remove the SIP request from the queue and send a 480
(Temporarily Unavailable) response. The timer expiration value is
set based on local policy, taking the 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 that results in stress on
intermediaries and state misalignment at the endpoints. The 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, while waiting for the push notification request to
succeed, and the associated REGISTER request to arrive from the SIP succeed, and the associated REGISTER request to arrive from the SIP
UA, the proxy needs to take into consideration that the transaction UA, the proxy needs to take into consideration that the transaction
associated with the SIP request will eventually time out at the associated with the SIP request will eventually time out at the
skipping to change at page 16, line 40 skipping to change at page 19, line 40
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
vary depending on the characteristics and load of the SIP network and vary depending on the characteristics and load of the SIP network and
the PNS. the PNS.
The proxy MUST NOT include the SIP request as payload in the In addition to the procedures described above there are two cases
requested push message. where a proxy, as an optimization, can forward a SIP request towards
a UA without waiting for a 2xx response to a REGISTER request, or
without even requesting that a push notification is sent to the UA:
If the proxy has knowledge that the UA is awake, and that the UA is If the proxy is able to authorize the sender of the REGISTER
able to receive the SIP request without first sending a REGISTER request, the proxy does not need to wait for the 2xx response
request, the proxy MAY choose to not request that a push notification before it forwards the SIP request towards the UA. In such cases,
is sent to the UA (and wait for the associated REGISTER request and the proxy will use the Contact URI of the REGISTER request when
2xx response) before it tries to forward the SIP request towards the comparing it against the Request-URIs of the SIP requests in the
UA. The mechanisms for getting such knowledge might be dependent on SIP Request Push Queue.
implementation or deployment architecture, and are outside the scope If the proxy has knowledge that the UA is awake, and that the UA
of this document. Similarly, if the Request-URI of the SIP request is able to receive the SIP request without first sending a
only contains any pn-provider SIP URI parameter, but no other pn- SIP binding-refresh REGISTER request, the proxy does not need to
URI parameters, e.g., because the SIP UA has not included them in a request that a push notification is sent to the UA (the UA will
REGISTER request (Section 4.2), the proxy is not able to request that not send a binding-refresh REGISTER request) before it forwards
a push notification is sent to the UA. If the proxy has knowledge the SIP request towards the UA. The mechanisms for getting such
that the UA is awake, and that the UA is able to receive the SIP knowledge might be dependent on implementation or deployment
request, the proxy MAY forwards the request towards the UA. architecture, and are outside the scope of this document.
Otherwise the proxy MUST reject the SIP request with a 480
(Temporarily Unavailable) response. Some PNS providers allow payload in the push notifications. This
specification does not define usage of such payload (in addition to
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 mid-dialog requests are
sent. Because of this a SIP UA might get suspended, and needs to be sent. Because of this a SIP UA might get suspended, and needs to be
awaken in order to be able to receive mid-dialog requests. awaken in order to be able to receive mid-dialog requests.
When the proxy receives a SIP request for a new dialog, or a stand- When the proxy receives a SIP request for a new dialog, or a stand-
alone SIP request, addressed towards a UA, the request will contain alone SIP request, addressed towards a UA, the request will contain
information (pn- SIP URI parameters) that allows proxy to request information (pn- SIP URI parameters) that allows proxy to request
that a push notification is sent to the UA Section 5.3.2. However, that a push notification is sent to the UA Section 5.6.2. However,
this information will not be present in mid-dialog requests towards this information will not be present in mid-dialog requests addressed
the UA. Instead, the proxy need to support a mechanism where it towards the UA. Instead, the proxy need to support a mechanism where
stores the information needed to request that a push notification is it stores the information needed to request that a push notification
sent to the UA and be able to find and retrieve that information when is sent to the UA, and to be able to retrieve that information when
it receives a mid-dialog request. This section defines such it receives a mid-dialog request addressed towards the UA. This
mechanism. The UA and proxy procedures in this section are applied section defines such mechanism. This section describes such
in addition to the generic procedures defined in this specification. mechanism. The SIP UA and SIP proxy procedures in this section are
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 | | | | Subscribe | | |
|---------------->| | | |---------------->| | |
| | | | | | | |
skipping to change at page 19, line 4 skipping to change at page 22, line 9
| | | SIP 200 OK | | | | SIP 200 OK |
| | |<==================| | | |<==================|
| SIP 200 OK | | | | SIP 200 OK | | |
|<===================================| | |<===================================| |
| | | | | | | |
| SIP UPDATE | | | | SIP UPDATE | | |
|<===================================| | |<===================================| |
| | | | | | | |
------- 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 the UA sends an initial request for a dialog, or a 2xx response When a UA sends an initial request for a dialog, or a 2xx response to
to such requests, if the UA is willing to receive push notifications such requests, if the UA is willing to receive push notifications
triggered by incoming mid-dialog requests, the UA MUST include a 'pn- when a proxy receives a mid-dialog request addressed towards the UA,
purr' SIP URI parameter in the Contact header field of the request or the UA MUST insert a 'pn-purr' SIP URI parameter in the Contact
response. The UA MUST include a parameter value identical to the the header field URI of the request or response. The UA MUST insert a
last 'sip.pnspurr' feature-capability indicator that it received in a parameter value identical to the the last 'sip.pnspurr' feature-
REGISTER response (Section 6.2.1). capability indicator that it received in a REGISTER response
(Section 6.2.1). If the UA has not recived a 'sip.pnspurr' feature-
capability indicator, the UA MUST NOT insert a 'pn-purr' SIP URI
parameter in a request or response.
The UA decision whether it is willing to receive push notifications The UA decision whether it is willing to receive push notifications
triggered by incoming mid-dialog requests is done based on local triggered by incoming mid-dialog requests is done based on local
policy. Such policy might be based on the type of SIP dialog, the policy. Such policy might be based on the type of SIP dialog, the
type of media (if any) negotiated for the dialog [RFC3264], etc. type of media (if any) 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 include a 'pn-purr' parameter in the Contact dialog, the UA needs to insert a 'pn-purr' parameter in the Contact
header field of the request or response for each dialog in which the header field URI of the request or response for each dialog in which
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 the proxy receives an initial REGISTER request for a When a proxy receives an initial REGISTER request for a binding from
registration from the UA, if the proxy supports requesting that push the UA, if the proxy supports requesting that push notifications
notifications triggered by mid-dialog requests are sent to the triggered by mid-dialog requests are sent to the registered UA, the
registered UA, the proxy MUST store the information (the pn- SIP URI proxy MUST store the information (the pn- SIP URI parameters) needed
parameters) needed to request that push notifications associated with to request that push notifications are sent to the UA. In addition,
the registration are sent to the UA. In addition the proxy MUST the proxy MUST generate a unique (within the context of the proxy)
generate a unique (within the context of the proxy) value, referred value, referred to as the PURR (Proxy Unique Registration Reference),
to as the PURR (Proxy Unique Registration Reference), that is unique that can be used as a key to retrieve the information.
within the context of the proxy and that can be used as a key to
retrieve the information. When the proxy receives the associated 2xx
REGISTER response, it adds a 'sip.pnspurr' feature-capability
indicator with the PURR value to the associated 2xx REGISTER
response. When the proxy receives a binding-refresh REGISTER
request, it MUST add a 'sip.pnspurr' feature-capability indicator
with the previously generated key as the value to the associated 2xx
REGISTER response.
The PURR value MUST be generated in such a way so that it cannot be In order to prevent client fingerprinting, the proxy MUST
used to retrieve information about the user or associate it with periodically generate a new PURR value (even if pn- parameters did
not change). However, as long as there are ongoing dialogs
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
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
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.
In order to prevent client fingerprinting, the proxy MUST Whenever the proxy receives a 2xx response to a REGISTER request, the
periodically generate a new PURR value (even if pn- parameters did proxy MUST insert a 'sip.pnspurr' feature-capability indicator with
not change) and provide the new value to the UA in a 2xx binding- the latest PURR value (see above) in the response.
refresh REGISTER response. However, as long as there are ongoing
dialogs 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 mid-dialog request addressed towards the UA.
6.2.2. Initial Request for Dialog 6.2.2. Initial Request for Dialog
When the proxy receives an initial request for a dialog from the UA, When a proxy receives an initial request for a dialog from a UA, if
and if the request contains a 'pn-purr' SIP URI parameter in the the request contains a 'pn-purr' SIP URI parameter in the Contact
Contact header field with a PURR value that the proxy has generated header field URI of the request with a PURR value that the proxy has
(Section 6.2.2), the proxy MUST add a Record-Route header to the generated (Section 6.2.2), the proxy MUST add a Record-Route header
request, to insert itself in the dialog route [RFC3261]. to the request, to insert itself in the dialog route [RFC3261] before
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, and if the proxy has generated a PURR value towards the UA, if the proxy has generated a PURR value associated
associated with the pn- parameters included in the SIP-URI of the with the pn- parameters inserted in the SIP URI of the request
request Section 6.2.2, the proxy MUST add a Record-Route header to Section 6.2.2, the proxy MUST add a Record-Route header to the
the request, to insert itself in the dialog route [RFC3261]. request, to insert itself in the dialog route [RFC3261] before
forwarding the request.
6.2.3. Mid-Dialog Request 6.2.3. Mid-Dialog Request
When the proxy receives a mid-dialog request addressed towards the When the proxy receives a mid-dialog SIP request addressed towards
UA, if the request contains a 'pn-purr' SIP URI parameter and if the the UA, if the request contains a 'pn-purr' SIP URI parameter and if
proxy is able to retrieve the stored information needed to request the proxy is able to retrieve the stored information needed to
that a push notification is sent the UA (Section 6.2.1), the proxy request that a push notification is sent the UA (Section 6.2.1), the
MUST request that a push notification is sent to the UA. Once the proxy MUST place the SIP request in the SIP Request Push Queue and
proxy has received the triggered REGISTER request, and the associated request that a push notification is sent to the UA.
successful response, the proxy can forward the mid-dialog request
towards the UA.
As described in Section 5.3.2, while waiting for the push 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,
depending on how the route set [RFC3261] of the mid-dialog SIP
request has been constructed.
When the proxy receives a 2xx response to a REGISTER request, the
proxy checks whether the SIP Request Push Queue contains a mid-dialog
SIP request associated with the REGISTER transaction. If the queue
contains such request the proxy MUST remove the SIP request from the
waiting queue and forward it towards the UA.
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
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
value associated with the REGISTER 2xx response.
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 the associated REGISTER request
to arrive from the SIP UA, the proxy needs to take into consideration and 2xx response, the proxy needs to take into consideration that the
that the transaction associated with the NOTIFY request will transaction associated with the mid-dialog request will eventually
eventually time out at the sender of the request (UAC), and the time out at the sender of the request (UAC), and the sender will
sender will consider the transaction a failure. consider the transaction a failure.
When the proxy rejects a mid-dialog request, it needs to select a When a proxy sends an error response to a mid-dialog request (e.g.,
response code that only impacts the transaction associated with the due to a transaction time out), the proxy SHOULD select a response
request. See [RFC5079] for more information. code that only impacts the transaction associated with the request
([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 the 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
following apply: 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 include 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 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 for o The proxy MUST apply the mechanism defined in Section 6.2.3 to
the initial request, and use the 'pn-purr' SIP URI parameter to place and retrieve the request from the waiting queue.
retrieve the stored information needed to request that a push
notification is sent to the UA.
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
skipping to change at page 21, line 50 skipping to change at page 25, line 23
The 555 response code is added to the "Server-Error" Status-Code The 555 response code is added to the "Server-Error" Status-Code
definition. 555 (Push Notification Service Not Supported) is used to definition. 555 (Push Notification Service Not Supported) is used to
indicate that the server did not support the push notification indicate that the server did not support the push notification
service identified in a 'pn-provider' SIP URI parameter. service identified in a 'pn-provider' SIP URI parameter.
The use of the SIP 555 response code is 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 included 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
indicator supports, and will use, the SIP push mechanism and the push indicator supports the SIP push mechanism and the type of push
notification service identified by the indicator value. When notification service indicated by the indicator value. When inserted
included in a 555 (Push Notification Service Not Supported) response in a 555 (Push Notification Service Not Supported) response to a
to a REGISTER request, the the indicator indicates that the entity REGISTER request, the the indicator indicates that the entity
associated with the indicator supports the SIP push mechanism, and associated with the indicator supports the SIP push mechanism, and
the push notification service(s) identified by the indicator value. the type of push notification service identified by the indicator
The values defined for the pn-provider SIP URI parameter are used as value. The values defined for the pn-provider SIP URI parameter are
indicator values. used as indicator values.
pns-fc = "+sip.pns" EQUAL LDQUOT pns-list RDQUOT pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT
pns-list = pns *(COMMA pns)
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 included 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, indicates that the entity
associated with the indicator supports, and will use, the Voluntary associated with the indicator supports the Voluntary Application
Application Server Identification (VAPID) [RFC8292] mechanism when Server Identification (VAPID) [RFC8292] mechanism when the entity
requesting that a push notification is sent to the SIP UA associated requests that a push notification is sent to a SIP UA. The indicator
with the SIP registration. The indicator value is a public key value is a public key identifying the entity, that can be used by a
identifying the entity, that can be used by a SIP UA to restrict SIP UA to restrict subscriptions to that entity.
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 included 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, indicates that the entity
associated with the indicator expects to receive binding-refresh associated with the indicator expects to receive binding-refresh
REGISTER requests from the SIP UA associated with the registration REGISTER requests for the binding from the SIP UA associated with the
before the registration expires, without the entity having to request binding before the binding expires, even if the entity does not
that a push notification is sent to the SIP UA in order to trigger request that a push notification is sent to the SIP UA in order to
the REGISTER requests. The indicator value is the minimum value trigger the binding-refresh REGISTER requests. The indicator value
(given in seconds) before the registration expiration when the entity indicates the minimum time (given in seconds), prior to the binding
expects to receive the REGISTER request. expiration when the UA 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 included in the SIP Contact The sip.pnsreg media feature tag, when inserted in the Contact header
header field of a SIP REGISTER request, indicates that the SIP UA field of a SIP REGISTER request, indicates that the SIP UA associated
associated with the tag is able to send binding-refresh REGISTER with the tag is able to send binding-refresh REGISTER requests for
requests associated with the registration without being awaken by the associated binding without being awaken by push notifications.
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 included 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, indicates 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]>
The format and semantics of pn-prid and pn-param are The format and semantics of pn-prid and pn-param are
specific to the pn-provider value. specific to the pn-provider value.
skipping to change at page 26, line 51 skipping to change at page 30, line 14
unless the operators know that the signalling is secured using some unless the operators know that the signalling is secured using some
other mechanism that provides strong crypto properties. other mechanism that provides strong crypto properties.
In addition to the information that needs to be exchanged between a In addition to the information that needs to be exchanged between a
device and the PNS in order to establish a push notification device and the PNS in order to establish a push notification
subscription, the mechanism defined in this document does not require subscription, the mechanism defined in this document does not require
any additional information to be exchanged between the device and the any additional information to be exchanged between the device and the
PNS. PNS.
The mechanism defined in this document does not require a proxy to The mechanism defined in this document does not require a proxy to
include any payload (in addition to possible payload used for the PNS insert any payload (in addition to possible payload used for the PNS
itself) when requesting push notifications. itself) when requesting push notifications.
Operators MUST ensure that the PNS-related SIP URI parameters Operators MUST ensure that the PNS-related SIP URI parameters
conveyed by a user in the Contact URI of a REGISTER request are not conveyed by a user in the Contact URI of a REGISTER request are not
sent to other users, or to non-trusted network entities. One way to sent to other users, or to non-trusted network entities. One way to
convey contact information is by using the the SIP event package for convey contact information is by using the the SIP event package for
registrations mechanism [RFC3680]. [RFC3680] defines generic registrations mechanism [RFC3680]. [RFC3680] defines generic
security considerations for the SIP event package for registations. security considerations for the SIP event package for registations.
As the PMS-related SIP URI parameters conveyed in the REGISTER As the PNS-related SIP URI parameters conveyed in the REGISTER
request contain sensitive information, operators that support the request contain sensitive information, operators that support the
event package MUST ensure that event package subscriptions are event package MUST ensure that event package subscriptions are
properly authenticated and authorized, and that the SIP URI properly authenticated and authorized, and that the SIP URI
parameters are not included in event notifications sent to other parameters are not inserted in event notifications sent to other
users, or to non-trusted network entities. users, or to non-trusted network entities.
14. IANA considerations 14. IANA considerations
[RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the
RFC number of this document.] RFC number of this document.]
14.1. SIP URI Parameters 14.1. SIP URI Parameters
This section defines new SIP URI Parameters that extend the "SIP/SIPS This section defines new SIP URI Parameters that extend the "SIP/SIPS
skipping to change at page 29, line 7 skipping to change at page 32, line 16
14.3.1. sip.pns 14.3.1. sip.pns
This section defines a new feature-capability indicator that extends This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.pns Name: sip.pns
Description: This feature-capability indicator, when included in a Description: This feature-capability indicator, when 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, indicates that the entity
associated with the indicator supports, and will use, the SIP associated with the indicator supports the SIP push mechanism
push mechanism and the push notification service identified by and the type of push notification service indicated by the
the indicator value. When included in a 555 (Push Notification indicator value. When inserted in a 555 (Push Notification
Service Not Supported) response to a REGISTER request, the the Service Not Supported) response to a REGISTER request, the
indicator indicates that the entity associated with the indicator indicates that the entity associated with the
indicator supports the SIP push mechanism, and the push indicator supports the SIP push mechanism, and the type of push
notification service(s) identified by the indicator value. notification service indicated 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 included 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, indicates that the
entity associated with the indicator supports, and will use, entity associated with the indicator supports the Voluntary
the Voluntary Application Server Identification (VAPID) Application Server Identification (VAPID) mechanism when the
mechanism when requesting that a push notifications is sent to entity requests that a push notifications is sent to a SIP UA.
the SIP UA associated with the SIP registration. The indicator The indicator value is a public key identifying the entity,
value is a public key identifying the entity, that can be used that can be used by a SIP UA to restrict subscriptions to that
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)
14.3.3. sip.pnsreg 14.3.3. sip.pnsreg
This section defines a new feature-capability indicator that extends This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.pnsreg Name: sip.pnsreg
Description: This feature-capability indicator, when included in a Description: This feature-capability indicator, when inserted in a
SIP 2xx response to a SIP REGISTER request, indicates that the SIP 2xx response to a SIP REGISTER request, indicates that the
entity associated with the indicator expects to receive entity associated with the indicator expects to receive
binding-refresh REGISTER requests from the SIP UA associated binding-refresh REGISTER requests for the binding from the SIP
with the registration before the registration expires, without UA associated with the binding before the binding expires, even
the entity having to request that a push notification is sent if the entity does not request that a push notification is sent
to the SIPvUA in order to trigger the REGISTER requests. The to the SIP UA in order to trigger the binding-refresh REGISTER
indicator value is the minimum value (given in seconds) before requests. The indicator value indicates the minimum time
the registration expireation when the entity expects to receive (given in seconds), prior to the binding expiration when the UA
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 included 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, indicates 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 31, line 17 skipping to change at page 35, line 8
14.4.1. sip.pnsreg 14.4.1. sip.pnsreg
This section defines a new media feature tag that extends the "SIP This section defines a new media feature tag that extends the "SIP
Media Feature Tag Registration Tree" sub-registry [RFC3840] under the Media Feature Tag Registration Tree" sub-registry [RFC3840] under the
Media Feature Tag registry: https://www.iana.org/assignments/media- Media Feature Tag registry: https://www.iana.org/assignments/media-
feature-tags/media-feature-tags.xhtml. feature-tags/media-feature-tags.xhtml.
Media feature tag name: sip.pnsreg Media feature tag name: sip.pnsreg
Summary of the media feature indicated by this feature tag: This Summary of the media feature indicated by this feature tag: This
media feature tag, when included in the SIP Contact header media feature tag, when inserted in the Contact header field
field of a SIP REGISTER request, indicates that the SIP UA of a SIP REGISTER request, indicates 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 awaken by push notifications.
Values appropriate for use with this feature tag: none Values appropriate for use with this feature tag: none
Related standards or documents: [RFCXXXX] Related standards or documents: [RFCXXXX]
Security considerations: This media feature tag does not introduce Security considerations: This media feature tag does not introduce
new security considerations, as it simply indicates support for new security considerations, as it simply indicates support for
 End of changes. 106 change blocks. 
504 lines changed or deleted 675 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/