draft-ietf-sipcore-sip-push-26.txt   draft-ietf-sipcore-sip-push-27.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track M. Arnold Intended status: Standards Track M. Arnold
Expires: August 28, 2019 Metaswitch Networks Expires: September 5, 2019 Metaswitch Networks
February 24, 2019 March 4, 2019
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-26 draft-ietf-sipcore-sip-push-27
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 a suspended Session Initiation Protocol (SIP) User Agent used to wake a suspended Session Initiation Protocol (SIP) User Agent
(UA) with push notifications, and also describes how the UA can send (UA) with push notifications, and also describes how the UA can send
binding-refresh REGISTER requests and receive incoming SIP requests binding-refresh REGISTER requests and receive incoming SIP requests
in an environment in which the UA may be suspended. The document in an environment in which the UA may be suspended. The document
defines new SIP URI parameters to exchange PNS information between defines new SIP URI parameters to exchange PNS information between
the UA and the SIP entity that will then request that push the UA and the SIP entity that will then request that push
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 28, 2019. This Internet-Draft will expire on September 5, 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 24 skipping to change at page 2, line 24
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. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Request Push Notifications . . . . . . . . . . . . . 8 4.1.1. Request Push Notifications . . . . . . . . . . . . . 8
4.1.2. Disable Push Notifications . . . . . . . . . . . . . 9 4.1.2. Disable Push Notifications . . . . . . . . . . . . . 9
4.1.3. Receive Push Notifications . . . . . . . . . . . . . 10 4.1.3. Receive Push Notifications . . . . . . . . . . . . . 10
4.1.4. Sending Binding-Refresh Requests Using Non-Push 4.1.4. Sending Binding-Refresh Requests Using Non-Push
Mechanism . . . . . . . . . . . . . . . . . . . . . . 10 Mechanism . . . . . . . . . . . . . . . . . . . . . . 10
4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 11 4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 12
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 12 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 13
5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 12 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 13
5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 12 5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 14
5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 13 5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 14
5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 13 5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 14
5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 13 5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 15
5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 14 5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 16
5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 14 5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 16
5.6.2. Initial Request for Dialog or Stand-Alone Request . . 17 5.6.2. Initial Request for Dialog or Stand-Alone Request . . 19
6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 20 6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 21
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 22 6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 23
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 22 6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 23
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 22 6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 24
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 23 6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 24
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 23 6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 24
6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 23 6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 25
7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 24 7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 26
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. 555 (Push Notification Service Not Supported) Response 8.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 25 8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 26
8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 26 8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 27
8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 26 8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 27
8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 26 8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 28
8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 27 8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 28
8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 27 8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 28
9. PNS Registration Requirements . . . . . . . . . . . . . . . . 27 9. PNS Registration Requirements . . . . . . . . . . . . . . . . 29
10. pn-provider, pn-param and pn-prid URI Parameters for Apple 10. pn-provider, pn-param and pn-prid URI Parameters for Apple
Push Notification service . . . . . . . . . . . . . . . . . . 28 Push Notification service . . . . . . . . . . . . . . . . . . 29
11. pn-provider, pn-param and pn-prid URI Parameters for Google 11. pn-provider, pn-param and pn-prid URI Parameters for Google
Firebase Cloud Messaging (FCM) push notification service . . 29 Firebase Cloud Messaging (FCM) push notification service . . 30
12. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 12. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
(Generic Event Delivery Using HTTP Push) . . . . . . . . . . 29 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 31 14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 32
14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 31 14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 32
14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 31 14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 32
14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 31 14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 33
14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 31 14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 33
14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 32 14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 33
14.2.1. 555 (Push Notification Service Not Supported) . . . 32 14.2.1. 555 (Push Notification Service Not Supported) . . . 33
14.3. SIP Global Feature-Capability Indicator . . . . . . . . 32 14.3. SIP Global Feature-Capability Indicator . . . . . . . . 33
14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 32 14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 33
14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 33 14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 34
14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 33 14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 34
14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 34 14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 35
14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 35 14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 36
14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 35 14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 36
14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 35 14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 36
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
16.1. Normative References . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . 38 16.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
In order to save resources such as battery life, some devices In order to save resources such as battery life, some devices
(especially mobile devices) and operating systems will suspend an (especially mobile devices) and operating systems will suspend an
application that is not in use. A suspended application might not be application that is not in use. A suspended application might not be
able to wake itself with internal timers and might not be awakened by able to wake itself with internal timers and might not be awakened by
incoming network traffic. In such an environment, a Push incoming network traffic. In such an environment, a Push
Notification Service (PNS) is used to wake the application. A PNS is Notification Service (PNS) is used to wake the application. A PNS is
a service that sends messages requested by other applications to a a service that sends messages requested by other applications to a
user application in order to wake the user application. These user application in order to wake the user application. These
messages are called push notifications. Push notifications might messages are called push notifications. Push notifications might
contain payload data, depending on the application. An application contain payload data, depending on the application. An application
can request that a push notification is sent to a single user can request that a push notification be sent to a single user
application or to multiple user applications. application or to multiple user applications.
Typically each operating system uses a dedicated PNS. Different PNSs Typically each operating system uses a dedicated PNS. Different PNSs
exist today. Some are based on the standardized mechanism defined in exist today. Some are based on the standardized mechanism defined in
[RFC8030], while others are proprietary. For example, Apple iOS [RFC8030], while others are proprietary. For example, Apple iOS
devices use the Apple Push Notification service (APNs) while Android devices use the Apple Push Notification service (APNs) while Android
devices use the Firebase Cloud Messaging (FCM) service. Each PNS devices use the Firebase Cloud Messaging (FCM) service. Each PNS
uses PNS-specific terminology and function names. The terminology in uses PNS-specific terminology and function names. The terminology in
this document is meant to be PNS-independent. If the PNS is based on this document is meant to be PNS-independent. If the PNS is based on
[RFC8030], the SIP proxy takes the role of the application server. [RFC8030], the SIP proxy takes the role of the application server.
skipping to change at page 8, line 24 skipping to change at page 8, line 24
one for IPv6) the UA needs to perform the procedures for each one for IPv6) the UA needs to perform the procedures for each
binding. binding.
NOTE: Since a push notification will trigger the UA to refresh all NOTE: Since a push notification will trigger the UA to refresh all
bindings, if a SIP UA has created multiple bindings, it is preferable bindings, if a SIP UA has created multiple bindings, it is preferable
if one can ensure that all bindings expire at the same time to help if one can ensure that all bindings expire at the same time to help
prevent some bindings from being refreshed earlier than needed. prevent some bindings from being refreshed earlier than needed.
For privacy and security reasons, a UA MUST NOT insert the SIP URI For privacy and security reasons, a UA MUST NOT insert the SIP URI
parameters (except for the pn-purr parameter) defined in this parameters (except for the pn-purr parameter) defined in this
specification in non-REGISTER request in order to prevent the PNS specification in non-REGISTER requests in order to prevent the PNS
information associated with the UA from reaching the remote peer. information associated with the UA from reaching the remote peer.
For example, the UA MUST NOT insert the pn-prid SIP URI parameter in 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 the Contact header field URI of an INVITE request. REGISTER requests
will not reach the remote peer, as they will be terminated by the will not reach the remote peer, as they will be terminated by the
registrar of the UA. However, the registrar MUST still ensure that 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 the parameters are not sent to other users, e.g., using the SIP event
package for registrations mechanism [RFC3680]. See Section 13 for package for registrations mechanism [RFC3680]. See Section 13 for
more information. more information.
4.1.1. Request Push Notifications 4.1.1. Request Push Notifications
skipping to change at page 9, line 17 skipping to change at page 9, line 17
To request push notifications from the SIP network, the UA MUST To request push notifications from the SIP network, the UA MUST
insert the following SIP URI parameters in the SIP Contact header insert the following SIP URI parameters in the SIP Contact header
field URI of the REGISTER request: pn-provider, pn-prid and pn-param field URI of the REGISTER request: pn-provider, pn-prid and pn-param
(if required for the specific PNS). The pn-provider URI parameter (if required for the specific PNS). The pn-provider URI parameter
indicates the type of PNS to be used for the push notifications. indicates the type of PNS to be used for the push notifications.
If the UA receives a 2xx response to the REGISTER request that If the UA receives a 2xx response to the REGISTER request that
contains a Feature-Caps header field [RFC6809] with a 'sip.pns' contains a Feature-Caps header field [RFC6809] with a 'sip.pns'
feature-capability indicator, with an indicator value identifying the feature-capability indicator, with an indicator value identifying the
same type of PNS that was identified by the pn-provider URI parameter same type of PNS that was identified by the pn-provider URI parameter
in the REGISTER request, it indicates that a SIP Proxy in the SIP in the REGISTER request, it indicates that another SIP Proxy in the
network will request that push notifications are sent to the UA. In SIP network will request that push notifications are sent to the UA.
addition, if the same Feature-Caps header field contains a In addition, if the same Feature-Caps header field contains a
'sip.vapid' feature-capability indicator, it indicates that the proxy 'sip.vapid' feature-capability indicator, it indicates that the proxy
supports use of the Voluntary Application Server Identification supports use of the Voluntary Application Server Identification
(VAPID) mechanism [RFC8292] to restrict push notifications to the UA. (VAPID) mechanism [RFC8292] to restrict push notifications to the UA.
NOTE: The VAPID specific procedures of the SIP UA are outside the NOTE: The VAPID specific procedures of the SIP UA are outside the
scope of this document. scope of this document.
If the UA receives a non-2xx response to the REGISTER, or if the UA If the UA receives a non-2xx response to the REGISTER, or if the UA
receives a 2xx response that does not contain a Feature-Caps header receives a 2xx response that does not contain a Feature-Caps header
field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA
skipping to change at page 9, line 48 skipping to change at page 9, line 48
PRID, the UA MUST disable the push notifications associated with the PRID, the UA MUST disable the push notifications associated with the
PRID (Section 4.1.2). PRID (Section 4.1.2).
4.1.2. Disable Push Notifications 4.1.2. Disable Push Notifications
When a UA wants to disable previously requested push notifications, When a UA wants to disable previously requested push notifications,
the UA SHOULD remove the binding [RFC3261], unless the UA is no 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 longer able to perform SIP procedures (e.g., due to a forced shutdown
of the UA) in which case the registrar will remove the binding once of the UA) in which case the registrar will remove the binding once
it expires. When the UA sends the REGISTER request for removing the it expires. When the UA sends the REGISTER request for removing the
binding, the UA MUST include the pn-prid SIP URI parameter in the binding, the UA MUST NOT insert the pn-prid SIP URI parameter in the
Contact header field URI of the REGISTER request, in order to inform Contact header field URI of the REGISTER request, in order to inform
the SIP network that the UA no longer wants to receive push the SIP network that the UA no longer wants to receive push
notifications associated with the PRID. notifications associated with the PRID.
4.1.3. Receive Push Notifications 4.1.3. Receive Push Notifications
When a UA receives a push notification, the UA MUST send a binding- 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 refresh REGISTER request. The UA MUST insert the same set of pn- SIP
URI parameters in the SIP Contact header field URI of the REGISTER URI parameters in the SIP Contact header field URI of the REGISTER
request that it inserted when it requested push notifications request that it inserted when it requested push notifications
skipping to change at page 10, line 44 skipping to change at page 10, line 44
If a UA is able to send binding-refresh REGISTER requests using a 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 the Contact header field of each REGISTER request. [RFC3840] in the Contact header field of each REGISTER request.
If the UA receives a 2xx response to the REGISTER request that If the UA receives a 2xx response to the REGISTER request that
contains a Feature-Caps header field with a 'sip.pnsreq' feature- contains a Feature-Caps header field with a 'sip.pnsreq' feature-
capability indicator, the UA MUST send a binging-refresh REGISTER capability indicator, the UA MUST send a binging-refresh REGISTER
request prior to binding expiration. The indicator value indicates request prior to binding expiration. The indicator value indicates
the minimum time (given in seconds), prior to the binding expiration the minimum time (given in seconds), prior to the binding expiration
when the UA MUST send the REGISTER request. when the UA needs to send the REGISTER request.
If the UA receives a 2xx response to the REGISTER request that does 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- 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.
Even if the UA is able to to send binding-refresh REGISTER requests Even if the UA is able to to send binding-refresh REGISTER requests
using a non-push mechanism, the UA MUST still send a binding-refresh using a non-push mechanism, the UA MUST still send a binding-refresh
REGISTER request whenever it receives a push notification REGISTER request whenever it receives a push notification
(Section 4.1.3). (Section 4.1.3).
NOTE: If the UA uses a non-push mechanism to wake and send binding- NOTE: If the UA uses a non-push mechanism to wake and send binding-
refresh REGISTER requests, such REGISTER requests will update the refresh REGISTER requests, such REGISTER requests will update the
binding expiration timer, and the proxy does not need to request that binding expiration timer, and the proxy does not need to request that
a push notification is sent to the UA in order to wake the UA. The a push notification be 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 be sent to the UA
when the proxy receives a SIP request addressed towards the UA when the proxy receives a SIP request addressed towards the UA
(Section 5.6.2). This allows the UA to e.g., use timers for sending (Section 5.6.2). This allows the UA to e.g., use timers for sending
binding-refresh REGISTER requests, but to be suspended (in order to binding-refresh REGISTER requests, but to be suspended (in order to
save battery resources, etc.) between sending the REGISTER requests save battery resources, etc.) between sending the REGISTER requests
and use push notification to wake the UA to process incoming calls. and use push notification to wake the UA to process incoming calls.
Example of a SIP REGISTER request including a 'sip.pnsreg'
media feature tag:
REGISTER sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>;
+sip.pnsreg
Expires: 7200
Content-Length: 0
Example of a SIP REGISTER response including a 'sip.pnsreg'
media feature tag and a 'sip.pnsreq' feature-capability indicator:
SIP/2.0 200 OK
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
To: Alice <sip:alice@example.com>;tag=123987
From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com;
pn-provider=acme;
pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>;
+sip.pnsreg
Feature-Caps: *;+sip.pns="acme",*;+sip.pnsreg="121"
Expires: 7200
Content-Length: 0
Figure 3: SIP REGISTER When Using Non-Push Mechanism Example
4.1.5. Query Network PNS Capabilities 4.1.5. Query Network PNS Capabilities
This section describes how a SIP UA can query the types of PNSs This section describes how a SIP UA can query the types of PNSs
supported by a SIP network, and PNS-related capabilities (e.g., supported by a SIP network, and PNS-related capabilities (e.g.,
support of the VAPID mechanism). When a UA performs a query, it does support of the VAPID mechanism). When a UA performs a query, it does
not request push notifications from the SIP network. Therefore, the not request push notifications from the SIP network. Therefore, the
UA can perform the query before it has registered to a PNS and UA can perform the query before it has registered to a PNS and
received a PRID. received a PRID.
In order to perform a query, the UA MUST insert a pn-provider SIP URI In order to perform a query, the UA MUST insert a pn-provider SIP URI
parameter in the Contact header field URI of the REGISTER request: parameter in the Contact header field URI of the REGISTER request:
If the UA inserts a pn-provider parameter value, indicating o If the UA inserts a pn-provider parameter value, indicating
support of a type of PNS, the SIP network will only inform the UA support of a type of PNS, the SIP network will only inform the UA
whether that type of PNS is supported. whether that type of PNS is supported.
If the UA does not insert a pn-provider parameter value (i.e., it o If the UA does not insert a pn-provider parameter value (i.e., it
inserts an "empty" pn-provider parameter) the SIP network will inserts an "empty" pn-provider parameter) the SIP network will
inform the UA about all types of PNSs supported by the network. inform the UA about all types of PNSs supported by the network.
This is useful e.g., if the UA supports more than one type of PNS. This is useful e.g., if the UA supports more than one type of PNS.
Note that it is not possible to insert multiple parameter values Note that it is not possible to insert multiple parameter values
in the pn-provider parameter. in the pn-provider parameter.
The UA MUST NOT insert a pn-prid SIP URI parameter in the Contact The UA MUST NOT insert a pn-prid SIP URI parameter in the Contact
header field URI of the REGISTER request. header field URI of the REGISTER request.
If the UA receives a 2xx response to the REGISTER request, the If the UA receives a 2xx response to the REGISTER request, the
skipping to change at page 12, line 33 skipping to change at page 14, line 8
pn-param SIP URI parameter will provide more details associated with pn-param SIP URI parameter will provide more details associated with
the actual PNS provider to be used. the actual PNS provider to be used.
The protocol and format used for the push notification requests are The protocol and format used for the push notification requests are
PNS-specific, and the details for constructing and sending a push PNS-specific, and the details for constructing and sending a push
notification request are outside the scope of this specification. notification request are outside the scope of this specification.
5.2. SIP Request Push Bucket 5.2. SIP Request Push Bucket
When a SIP proxy receives a SIP request addressed towards a UA, that When a SIP proxy receives a SIP request addressed towards a UA, that
will trigger the proxy to request that a push notification is sent to will trigger the proxy to request that a push notification be sent to
the UA. The proxy will place the request in storage referred to as the UA. The proxy will place the request in storage referred to as
the SIP Request Push Bucket, and the proxy starts a timer (referred the SIP Request Push Bucket, and the proxy starts a timer (referred
to as the Bucket Timer) associated with the transaction. A SIP to as the Bucket Timer) associated with the transaction. A SIP
request is removed from the bucket when one of the following has request is removed from the bucket when one of the following has
occurred: the proxy forwards the request towards the UA, when the occurred: the proxy forwards the request towards the UA, when the
proxy sends an error response to the request, or when the Bucket proxy sends an error response to the request, or when the Bucket
Timer times out. The detailed procedures are described in the Timer times out. The detailed procedures are described in the
sections below. sections below.
Exactly how the SIP Request Push Bucket is implemented is outside the Exactly how the SIP Request Push Bucket is implemented is outside the
skipping to change at page 13, line 46 skipping to change at page 15, line 16
This specification defines the following feature-capability This specification defines the following feature-capability
indicators that a proxy can use to indicate support of additional indicators that a proxy can use to indicate support of additional
features associated with a given type of PNS: 'sip.vapid', features associated with a given type of PNS: 'sip.vapid',
'sip.pnsreg' and 'sip.pnspurr'. These feature-capability indicators 'sip.pnsreg' and 'sip.pnspurr'. These feature-capability indicators
MUST only be inserted in a Feature-Caps header field that also MUST only be inserted in a Feature-Caps header field that also
contains a 'sip.pns' feature-capability indicator. contains a 'sip.pns' feature-capability indicator.
5.5. Trigger Periodic Binding Refresh 5.5. Trigger Periodic Binding Refresh
In order to request that a push notification is sent to a SIP UA, a In order to request that a push notification be sent to a SIP UA, a
SIP proxy needs to have information about when a binding will expire. SIP proxy needs to have information about when a binding will expire.
The proxy needs to be able to retrieve the information from the The proxy needs to be able to retrieve the information from the
registrar using some mechanism, or run its own registration timers. registrar using some mechanism, or run its own registration timers.
Such mechanisms are outside the scope of this document, but could be Such mechanisms are outside the scope of this document, but could be
implemented e.g., using the SIP event package for registrations implemented e.g., using the SIP event package for registrations
mechanism [RFC3680]. 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 will request that a push binding-refresh REGISTER request, the proxy will request that a push
notification is sent to the UA. notification be sent to the UA.
Note that the push notification needs to be requested early enough Note that the push notification needs to be requested early enough
for the associated binding-refresh REGISTER request to reach the for the associated binding-refresh REGISTER request to reach the
registrar before the binding expires. It is RECOMMENDED that the registrar before the binding expires. It is RECOMMENDED that the
proxy requests the push notification at least 120 seconds before the proxy requests the push notification at least 120 seconds before the
binding expires. binding expires.
If the UA has indicated, using the 'sip.pnsreg' media feature tag, If the UA has indicated, using the 'sip.pnsreg' media feature tag,
that it is able to wake itself using a non-push mechanism in order to that it is able to wake itself using a non-push mechanism in order to
send binding-refresh REGISTER requests, and if the proxy does not send binding-refresh REGISTER requests, and if the proxy does not
receive a REGISTER request prior to 120 seconds before the binding receive a REGISTER request prior to 120 seconds before the binding
expires, the proxy MAY request that a push notification is sent to expires, the proxy MAY request that a push notification be sent to
the UA, to trigger the UA to send a binding-refresh REGISTER request. the UA, to trigger the UA to send a binding-refresh REGISTER request.
NOTE: As described in Section 4.1.5, a UA might send a REGISTER NOTE: As described in Section 4.1.5, a UA might send a REGISTER
request without including a pn-prid SIP URI parameter, in order to request without including a pn-prid SIP URI parameter, in order to
retrieve push notification capabilities from the network before the retrieve push notification capabilities from the network before the
UA expects to receive push notifications from the network. A proxy UA expects to receive push notifications from the network. A proxy
will not request that push notifications are sent to a UA that has will not request that push notifications are sent to a UA that has
not provided a pn-prid SIP URI parameter (Section 5.6.2). not provided a pn-prid SIP URI parameter (Section 5.6.2).
If the proxy receives information that a binding associated with a If the proxy receives information that a binding associated with a
skipping to change at page 15, line 11 skipping to change at page 16, line 30
This section describes the SIP proxy procedures when a SIP UA This section describes the SIP proxy procedures when a SIP UA
requests push notifications from the SIP network. requests push notifications from the SIP network.
The procedures in this section apply when the SIP REGISTER request The procedures in this section apply when the SIP REGISTER request
contains, in addition to the pn-provider SIP URI parameter, a pn-prid contains, in addition to the pn-provider SIP URI parameter, a pn-prid
SIP URI parameter in the Contact header field URI of the request. SIP URI parameter in the Contact header field URI of the request.
When a proxy receives a REGISTER request that contains a Feature-Caps When a proxy receives a REGISTER request that contains a Feature-Caps
header field with a 'sip.pns' feature-capability indicator, it header field with a 'sip.pns' feature-capability indicator, it
indicates that a proxy between this proxy and the UA supports the indicates that another proxy between this proxy and the UA supports
type of PNS supported by the UA, and will request that push the type of PNS supported by the UA, and will request that push
notifications are sent to the UA. In such case, the proxy MUST skip notifications are sent to the UA. In such case, the proxy MUST skip
the rest of the procedures in this section, and process the REGISTER the rest of the procedures in this section, and process the REGISTER
request using normal SIP procedures. request using normal SIP procedures.
When a proxy receives a REGISTER request that does not contain a When a proxy receives a REGISTER request that does not contain a
Feature-Caps header field with a 'sip.pns' feature-capability Feature-Caps header field with a 'sip.pns' feature-capability
indicator, the proxy processes the request according to the indicator, the proxy processes the request according to the
procedures below: procedures below:
o If the proxy does not support the type of PNS supported by the UA, o If the proxy does not support the type of PNS supported by the UA,
skipping to change at page 15, line 50 skipping to change at page 17, line 20
supports. supports.
o If the proxy supports the type of PNS supported by the UA, the o If the proxy supports the type of PNS supported by the UA, the
proxy MUST indicate support of that type of PNS (Section 5.4) in proxy MUST indicate support of that type of PNS (Section 5.4) in
the REGISTER request before it forwards the request towards the the REGISTER request before it forwards the request towards the
registrar. This will inform proxies between the proxy and the registrar. This will inform proxies between the proxy and the
registrar that the proxy supports the type of PNS supported by the registrar that the proxy supports the type of PNS supported by the
UA, and that the proxy will request that push notifications are UA, and that the proxy will request that push notifications are
sent to the UA. sent to the UA.
A binding expiration interval MUST be considered too short if the A binding expiration interval MUST be considered too short if the
binding would expire before the proxy would request that a push binding would expire before the proxy can request that a push
notification is sent to the UA to trigger the UA to send a binding- notification be sent to the UA to trigger the UA to send a binding-
refresh REGISTER request. The proxy MAY consider the interval too refresh REGISTER request. The proxy MAY consider the interval too
short based on its own policy so as to reduce load on the system. short based on its own policy so as to reduce load on the system.
If the proxy sends a SIP 555 (Push Notification Service Not If the proxy sends a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD indicate each type of PNS that Supported) response, the proxy SHOULD indicate each type of PNS that
the proxy supports in the response. the proxy supports in the response.
When a proxy receives a 2xx response to the REGISTER request, if the When a proxy receives a 2xx response to the REGISTER request, if the
proxy indicated support of a type of PNS in the REGISTER request (see proxy indicated support of a type of PNS in the REGISTER request (see
above), the proxy performs the following actions: above), the proxy performs the following actions:
skipping to change at page 16, line 50 skipping to change at page 18, line 20
The procedures in this section apply when the REGISTER request The procedures in this section apply when the REGISTER request
contains a pn-provider SIP URI parameter, but does not contain a pn- contains a pn-provider SIP URI parameter, but does not contain a pn-
prid SIP URI parameter in the Contact header field URI of the prid SIP URI parameter in the Contact header field URI of the
REGISTER request. REGISTER request.
When a proxy receives a REGISTER request that contains a pn-provider When a proxy receives a REGISTER request that contains a pn-provider
SIP URI parameter indicating the type of PNS supported by the UA, the SIP URI parameter indicating the type of PNS supported by the UA, the
proxy MUST perform the following actions: proxy MUST perform the following actions:
If the proxy supports the type of PNS supported by the UA, the o If the proxy supports the type of PNS supported by the UA, the
proxy MUST indicate support of that type of PNS (Section 5.4) in proxy MUST indicate support of that type of PNS (Section 5.4) in
the REGISTER request before it forwards the request towards the the REGISTER request before it forwards the request towards the
registrar. This will inform proxies between the proxy and the registrar. This will inform any other proxies between the proxy
registrar that the proxy supports the type of PNS supported by the and the registrar that the proxy supports the type of PNS
UA. supported by the UA.
If the proxy does not support the type of PNS supported by the UA, o If the proxy does not support the type of PNS supported by the UA,
and if the REGISTER request contains Feature-Caps header fields and if the REGISTER request contains Feature-Caps header fields
indicating support of one or more types of PNSs, the proxy indicating support of one or more types of PNSs, the proxy
forwards the request towards the registrar. forwards the request towards the registrar.
If the proxy does not support the type of PNS supported by the UA, o If the proxy does not support the type of PNS supported by the UA,
and if the REGISTER request does not contain Feature-Caps header and if the REGISTER request does not contain Feature-Caps header
fields indicating support of one or more types of PNSs, the proxy fields indicating support of one or more types of PNSs, the proxy
MUST either forward the request towards the registrar, or send a MUST either forward the request towards the registrar, or send a
SIP 555 (Push Notification Service Not Supported) response towards SIP 555 (Push Notification Service Not Supported) response towards
the UA. The proxy MUST NOT send a SIP 555 (Push Notification the UA. The proxy MUST NOT send a SIP 555 (Push Notification
Service Not Supported) response unless it knows (by means of local Service Not Supported) response unless it knows (by means of local
configuration) that no other proxy supports any of the types of configuration) that no other proxy supports any of the types of
PNSs supported by the UA. PNSs supported by the UA.
If the proxy sends a SIP 555 (Push Notification Service Not If the proxy sends a SIP 555 (Push Notification Service Not
skipping to change at page 17, line 50 skipping to change at page 19, line 19
The procedures in this section apply when a SIP proxy has indicated The procedures in this section apply when a SIP proxy has indicated
that the it will request that push notifications are sent to the SIP that the it will request that push notifications are sent to the SIP
UA. UA.
When the proxy receives a SIP request for a new dialog (e.g., a SIP When the proxy receives a SIP request for a new dialog (e.g., a SIP
INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE
request) addressed towards a SIP UA, if the Request-URI of the request) addressed towards a SIP UA, if the Request-URI of the
request contains a pn-provider, a pn-prid and a pn-param (if required request contains a pn-provider, a pn-prid and a pn-param (if required
for the specific PNS provider) SIP URI parameter, the proxy requests for the specific PNS provider) SIP URI parameter, the proxy requests
that a push notification is sent to the UA using the information in that a push notification be sent to the UA using the information in
the pn- SIP URI parameters. The proxy then places the SIP request in the pn- SIP URI parameters. The proxy then places the SIP request in
the SIP Request Push Bucket. The push notification will trigger the the SIP Request Push Bucket. The push notification will trigger the
UA to send a binding-refresh REGISTER request that the proxy will UA to send a binding-refresh REGISTER request that the proxy will
process as described in Section 5.6.1. In addition, the proxy MUST process as described in Section 5.6.1. In addition, the proxy MUST
store the Contact URI of the REGISTER request during the lifetime of store the Contact URI of the REGISTER request during the lifetime of
the REGISTER transaction. the REGISTER transaction.
NOTE: If the proxy receives a SIP request that does not contain the NOTE: If the proxy receives a SIP request that does not contain the
pn- SIP URI parameters listed above, the proxy processing of the pn- SIP URI parameters listed above, the proxy processing of the
request is based on local policy. If the proxy also serves requests request is based on local policy. If the proxy also serves requests
for UAs that do not use the SIP push mechanism, the proxy can forward for UAs that do not use the SIP push mechanism, the proxy can forward
the request towards the UA. Otherwise the proxy can reject the the request towards the UA. Otherwise the proxy can reject the
request. request.
When the proxy receives a 2xx response to the REGISTER request, the When the proxy receives a 2xx response to the REGISTER request, the
proxy performs the following actions: proxy performs the following actions:
The proxy processes the REGISTER response as described in o The proxy processes the REGISTER response as described in
Section 5.6.1. Section 5.6.1.
The proxy checks whether the SIP Request Push Bucket contains a o The proxy checks whether the SIP Request Push Bucket contains a
SIP request associated with the REGISTER transaction, by comparing SIP request associated with the REGISTER transaction, by comparing
(Section 5.3) the Contact header field URI in the REGISTER (Section 5.3) the Contact header field URI in the REGISTER
response with the Request-URIs of the SIP requests in the queue. response with the Request-URIs of the SIP requests in the bucket.
If there is a match, the proxy MUST remove the SIP request from If there is a match, the proxy MUST remove the SIP request from
the bucket and forward it towards the UA. the bucket 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 a SIP request towards a UA is to make sure that the forwarding a SIP request towards a UA is to make sure that the
REGISTER request has been accepted by the registrar, and that the UA REGISTER request has been accepted by the registrar, and that the UA
that initiated the REGISTER request is authorized to receive messages that initiated the REGISTER request is authorized to receive messages
for the Request-URI. for the Request-URI.
If the proxy receives a non-2xx response to the REGISTER request, the If the proxy receives a non-2xx response to the REGISTER request, the
skipping to change at page 19, line 7 skipping to change at page 20, line 25
perform authentication) the proxy MAY keep the SIP request in the perform authentication) the proxy MAY keep the SIP request in the
bucket. bucket.
If the push notification request fails (see PNS-specific If the push notification request fails (see PNS-specific
documentation for details), the proxy MUST remove the SIP request documentation for details), the proxy MUST remove the SIP request
from the bucket and send an error response to the SIP request. It is from the bucket and send an error response to the SIP request. It is
RECOMMENDED that the proxy sends either a 404 (Not Found) response or RECOMMENDED that the proxy sends either a 404 (Not Found) response or
a 480 (Temporarily Unavailable) response, but other response codes a 480 (Temporarily Unavailable) response, but other response codes
can be used as well. can be used as well.
After the proxy has requested that a push notification is sent to a After the proxy has requested that a push notification be sent to a
UA, if the proxy does not receive a REGISTER response with a Contact UA, if the proxy does not receive a REGISTER response with a Contact
URI that matches the Request-URI of the SIP request before the Bucket URI that matches the Request-URI of the SIP request before the Bucket
Timer (Section 5.2) associated with the SIP request times out, the Timer (Section 5.2) associated with the SIP request times out, the
proxy MUST remove the SIP request from the SIP Request Push Bucket proxy MUST remove the SIP request from the SIP Request Push Bucket
(Section 5.2) and send a 480 (Temporarily Unavailable) response. The (Section 5.2) and send a 480 (Temporarily Unavailable) response. The
Bucket Timer time-out value is set based on local policy, taking the Bucket Timer time-out value is set based on local policy, taking the
guidelines below into consideration. guidelines below into consideration.
As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must
complete immediately or risk losing a race, which results in stress complete immediately or risk losing a race, which results in stress
skipping to change at page 19, line 49 skipping to change at page 21, line 18
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.
In addition to the procedures described above there are two cases In addition to the procedures described above there are two cases
where a proxy, as an optimization, can forward a SIP request towards 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 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: without even requesting that a push notification be sent to the UA:
If the proxy is able to authenticate the sender of the REGISTER o If the proxy is able to authenticate the sender of the REGISTER
request, the proxy does not need to wait for the 2xx response request and verify that it is allowed by authorization policy, the
before it forwards the SIP request towards the UA. In such cases, proxy does not need to wait for the 2xx response before it
the proxy will use the Contact URI of the REGISTER request when forwards the SIP request towards the UA. In such cases, the proxy
comparing it against the Request-URIs of the SIP requests in the will use the Contact URI of the REGISTER request when comparing it
SIP Request Push Bucket. against the Request-URIs of the SIP requests in the SIP Request
If the proxy has knowledge that the UA is awake, and that the UA Push Bucket.
o If the proxy has knowledge that the UA is awake, and that the UA
is able to receive the SIP request without first sending a is able to receive the SIP request without first sending a
binding-refresh REGISTER request, the proxy does not need to binding-refresh REGISTER request, the proxy does not need to
request that a push notification is sent to the UA (the UA will request that a push notification be sent to the UA (the UA will
not send a binding-refresh REGISTER request) before it forwards not send a binding-refresh REGISTER request) before it forwards
the SIP request towards the UA. The mechanisms for getting such the SIP request towards the UA. The mechanisms for getting such
knowledge might be dependent on implementation or deployment knowledge might be dependent on implementation or deployment
architecture, and are outside the scope of this document. architecture, and are outside the scope of this document.
Some PNS providers allow payload in the push notifications. This Some PNS providers allow payload in the push notifications. This
specification does not define usage of such payload (in addition to specification does not define usage of such payload (in addition to
any payload that might be required by the PNS itself). any payload that might be required by the PNS itself).
6. Support Of Longlived SIP Dialogs 6. Support Of Longlived SIP Dialogs
skipping to change at page 22, line 7 skipping to change at page 23, line 24
|Push Message (PRID) | | |Push Message (PRID) | |
|<----------------| | | |<----------------| | |
| | | | | | | |
| SIP REGISTER (PRID) | | | SIP REGISTER (PRID) | |
|===================================>| | |===================================>| |
| | |SIP REGISTER (PRID)| | | |SIP REGISTER (PRID)|
| | |==================>| | | |==================>|
| | | | | | | |
| | | SIP 200 OK | | | | SIP 200 OK |
| | |<==================| | | |<==================|
| SIP 200 OK | | | | SIP 200 OK (PURR) | |
|<===================================| | |<===================================| |
| | | | | | | |
| SIP UPDATE | | | | SIP UPDATE | | |
|<===================================| | |<===================================| |
| | | | | | | |
------- Push Notification API ------- Push Notification API
======= SIP ======= SIP
Figure 3: SIP Push Longlived Dialog Flow Figure 4: 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
If the UA is willing to receive push notifications when a proxy If the UA is willing to receive push notifications when a proxy
receives a mid-dialog request addressed towards the UA, the UA MUST receives a mid-dialog request addressed towards the UA, the UA MUST
insert a 'pn-purr' SIP URI parameter in the Contact header field URI insert a 'pn-purr' SIP URI parameter (Section 6.2.1) in the Contact
of the initial request for a dialog or the 2xx response to such header field URI of the initial request for a dialog or the 2xx
requests. The UA MUST insert a parameter value identical to the last response to such requests. XXX The UA MUST insert a parameter value
'sip.pnspurr' feature-capability indicator that it received in a identical to the last 'sip.pnspurr' feature-capability indicator
REGISTER response (Section 6.2.1). If the UA has not recived a (Section 6.2.1) that it received in a REGISTER response. If the UA
'sip.pnspurr' feature-capability indicator, the UA MUST NOT insert a has not recived a 'sip.pnspurr' feature-capability indicator, the UA
'pn-purr' SIP URI parameter in a request or response. MUST NOT insert a 'pn-purr' SIP URI parameter in a request or
response.
The UA makes the decision to receive push notifications triggered by The UA makes the decision to receive push notifications triggered by
incoming mid-dialog requests based on local policy. Such policy incoming mid-dialog requests based on local policy. Such policy
might be based on the type of SIP dialog, the type of media (if any) might be based on the type of SIP dialog, the type of media (if any)
negotiated for the dialog [RFC3264], etc. negotiated for the dialog [RFC3264], etc.
NOTE: As the 'pn-purr' SIP URI parameter only applies to a given NOTE: As the 'pn-purr' SIP URI parameter only applies to a given
dialog, the UA needs to insert a 'pn-purr' parameter in the Contact dialog, the UA needs to insert a 'pn-purr' parameter in the Contact
header field URI of the request or response for each dialog in which header field URI of the request or response for each dialog in which
the UA is willing to receive push notifications triggered by incoming the UA is willing to receive push notifications triggered by incoming
skipping to change at page 23, line 34 skipping to change at page 24, line 50
cryptographically secure random function. cryptographically secure random function.
Whenever the proxy receives a 2xx response to a REGISTER request, the Whenever the proxy receives a 2xx response to a REGISTER request, the
proxy MUST insert a 'sip.pnspurr' feature-capability indicator with proxy MUST insert a 'sip.pnspurr' feature-capability indicator with
the latest PURR value (see above) in the response. the latest PURR value (see above) in the response.
6.2.2. Initial Request for Dialog 6.2.2. Initial Request for Dialog
When a proxy receives an initial request for a dialog from a UA that When a proxy receives an initial request for a dialog from a UA that
contains a 'pn-purr' SIP URI parameter in the Contact header field contains a 'pn-purr' SIP URI parameter in the Contact header field
URI with a PURR value that the proxy has generated (Section 6.2.2), URI with a PURR value that the proxy has generated (Section 6.2.1),
the proxy MUST add a Record-Route header to the request to insert the proxy MUST add a Record-Route header to the request to insert
itself in the dialog route [RFC3261] before forwarding the request. 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 the proxy has generated a PURR value associated towards the UA, and the proxy has generated a PURR value associated
with the pn- parameters inserted in the SIP URI of the request with the pn- parameters inserted in the SIP URI of the request
(Section 6.2.2), the proxy MUST add a Record-Route header to the (Section 6.2.2), the proxy MUST add a Record-Route header to the
request, to insert itself in the dialog route [RFC3261] before request, to insert itself in the dialog route [RFC3261] before
forwarding the request. forwarding the request.
6.2.3. Mid-Dialog Request 6.2.3. Mid-Dialog Request
When the proxy receives a mid-dialog SIP request addressed towards When the proxy receives a mid-dialog SIP request addressed towards
the UA that contains a 'pn-purr' SIP URI parameter, and the proxy is the UA that contains a 'pn-purr' SIP URI parameter, and the proxy is
able to retrieve the stored information needed to request that a push able to retrieve the stored information needed to request that a push
notification is sent the UA (Section 6.2.1), the proxy MUST place the notification be sent to the UA (Section 6.2.1), the proxy MUST place
SIP request in the SIP Request Push Bucket and request that a push the SIP request in the SIP Request Push Bucket and request that a
notification is sent to the UA. push notification be sent to the UA.
NOTE: The 'pn-purr' SIP URI parameter will either be carried in the NOTE: The 'pn-purr' SIP URI parameter will either be carried in the
Request-URI or in a Route header field [RFC3261] of the SIP request, Request-URI or in a Route header field [RFC3261] of the SIP request,
depending on how the route set [RFC3261] of the mid-dialog SIP depending on how the route set [RFC3261] of the mid-dialog SIP
request has been constructed. request has been constructed.
When the proxy receives a 2xx response to a REGISTER request, the When the proxy receives a 2xx response to a REGISTER request, the
proxy checks whether the SIP Request Push Bucket contains a mid- proxy checks whether the SIP Request Push Bucket contains a mid-
dialog SIP request associated with the REGISTER transaction. If the dialog SIP request associated with the REGISTER transaction. If the
bucket contains such request the proxy MUST remove the SIP request bucket contains such request the proxy MUST remove the SIP request
skipping to change at page 24, line 34 skipping to change at page 25, line 50
As described in Section 5.6.2, while waiting for the push As described in Section 5.6.2, while waiting for the push
notification request to succeed, and then for the associated REGISTER notification request to succeed, and then for the associated REGISTER
request and 2xx response, the proxy needs to take into consideration request and 2xx response, the proxy needs to take into consideration
that the transaction associated with the mid-dialog request will that the transaction associated with the mid-dialog request will
eventually time out at the sender of the request (UAC), and the eventually time out at the sender of the request (UAC), and the
sender will consider the transaction a failure. sender will consider the transaction a failure.
When a proxy sends an error response to a mid-dialog request (e.g., When a proxy sends an error response to a mid-dialog request (e.g.,
due to a transaction time out), the proxy SHOULD select a response due to a transaction time out), the proxy SHOULD select a response
code that only impacts the transaction associated with the request code that only impacts the transaction associated with the request
([RFC5079]). [RFC5079].
7. Support Of SIP Replaces 7. Support Of SIP Replaces
[RFC3891] defines a mechanism that allows a SIP UA to replace a [RFC3891] defines a mechanism that allows a SIP UA to replace a
dialog with another dialog. A UA that wants to replace a dialog with dialog with another dialog. A UA that wants to replace a dialog with
another one will send an initial request for the new dialog. The another one will send an initial request for the new dialog. The
Request-URI of the request will contain Contact header field URI of Request-URI of the request will contain Contact header field URI of
the peer. the peer.
If a SIP proxy wants to be able to request that a push notification If a SIP proxy wants to be able to request that a push notification
is sent to a UA when it receives an initial request for a dialog that be sent to a UA when it receives an initial request for a dialog that
replaces an existing dialog, using the mechanism in [RFC3891], the replaces an existing dialog, using the mechanism in [RFC3891], the
proxy and the UA MUST perform the following actions: proxy and the UA MUST perform the following actions:
o The proxy MUST provide a PURR to the UA during registration o The proxy MUST provide a PURR to the UA during registration
(Section 6.2.1). (Section 6.2.1).
o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact
header field URI of the initial request for a dialog, or a 2xx header field URI of the initial request for a dialog, or a 2xx
response to such requests (Section 6.1.1). This includes dialogs response to such requests (Section 6.1.1). This includes dialogs
replacing other dialogs, as those dialogs might also get replaced. replacing other dialogs, as those dialogs might also get replaced.
o The proxy MUST apply the mechanism defined in Section 6.2.3 to o The proxy MUST apply the mechanism defined in Section 6.2.3 to
place and retrieve the request from the SIP Request Push Bucket. place and retrieve the request from the SIP Request Push Bucket.
In addition, the operator needs to make sure that the initial request In addition, the operator needs to make sure that the initial request
for dialogs, addressed towards the UA using the contact of the for dialogs, addressed towards the UA using the contact of the
replaced dialog, will be routed to the SIP proxy (in order to request replaced dialog, will be routed to the SIP proxy (in order to request
skipping to change at page 25, line 15 skipping to change at page 26, line 30
o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact
header field URI of the initial request for a dialog, or a 2xx header field URI of the initial request for a dialog, or a 2xx
response to such requests (Section 6.1.1). This includes dialogs response to such requests (Section 6.1.1). This includes dialogs
replacing other dialogs, as those dialogs might also get replaced. replacing other dialogs, as those dialogs might also get replaced.
o The proxy MUST apply the mechanism defined in Section 6.2.3 to o The proxy MUST apply the mechanism defined in Section 6.2.3 to
place and retrieve the request from the SIP Request Push Bucket. place and retrieve the request from the SIP Request Push Bucket.
In addition, the operator needs to make sure that the initial request In addition, the operator needs to make sure that the initial request
for dialogs, addressed towards the UA using the contact of the for dialogs, addressed towards the UA using the contact of the
replaced dialog, will be routed to the SIP proxy (in order to request replaced dialog, will be routed to the SIP proxy (in order to request
that a push notification is sent to the UA). The procedures for that a push notification be sent to the UA). The procedures for
doing that are operator specific, and are outside the scope of this doing that are operator specific, and are outside the scope of this
specification. specification.
8. Grammar 8. Grammar
8.1. 555 (Push Notification Service Not Supported) Response Code 8.1. 555 (Push Notification Service Not Supported) Response Code
The 555 response code is added to the "Server-Error" Status-Code The 555 response code is added to the "Server-Error" Status-Code
definition. 555 (Push Notification Service Not Supported) is used to definition. 555 (Push Notification Service Not Supported) is used to
indicate that the server does not support the push notification indicate that the server does not support the push notification
skipping to change at page 26, line 11 skipping to change at page 27, line 22
pns = tag-value pns = tag-value
tag-value = <tag-value defined in [RFC3840]> tag-value = <tag-value defined in [RFC3840]>
8.3. sip.vapid Feature-Capability Indicator 8.3. sip.vapid Feature-Capability Indicator
The sip.vapid feature-capability indicator, when inserted in a SIP The sip.vapid feature-capability indicator, when inserted in a SIP
2xx response to a SIP REGISTER request, denotes that the entity 2xx response to a SIP REGISTER request, denotes that the entity
associated with the indicator supports the Voluntary Application associated with the indicator supports the Voluntary Application
Server Identification (VAPID) [RFC8292] mechanism when the entity Server Identification (VAPID) [RFC8292] mechanism when the entity
requests that a push notification is sent to a SIP UA. The indicator requests that a push notification be sent to a SIP UA. The indicator
value is a public key identifying the entity that can be used by a value is a public key identifying the entity that can be used by a
SIP UA to restrict subscriptions to that entity. SIP UA to restrict subscriptions to that entity.
vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT
vapid = tag-value vapid = tag-value
tag-value = <tag-value defined in [RFC3840]> tag-value = <tag-value defined in [RFC3840]>
8.4. sip.pnsreg Feature-Capability Indicator 8.4. sip.pnsreg Feature-Capability Indicator
The sip.pnsreg feature-capability indicator, when inserted in a SIP The sip.pnsreg feature-capability indicator, when inserted in a SIP
2xx response to a SIP REGISTER request, denotes that the entity 2xx response to a SIP REGISTER request, denotes that the entity
associated with the indicator expects to receive binding-refresh associated with the indicator expects to receive binding-refresh
REGISTER requests from the SIP UA associated with the binding before REGISTER requests from the SIP UA associated with the binding before
the binding expires, even if the entity does not request that a push the binding expires, even if the entity does not request that a push
notification is sent to the SIP UA in order to trigger the binding- notification be sent to the SIP UA in order to trigger the binding-
refresh REGISTER requests. The indicator value conveys the minimum refresh REGISTER requests. The indicator value conveys the minimum
time (given in seconds), prior to the binding expiration when the UA time (given in seconds), prior to the binding expiration when the UA
MUST send the REGISTER request. MUST send the REGISTER request.
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT reg = 1*DIGIT
DIGIT = <DIGIT defined in [RFC3261]> DIGIT = <DIGIT defined in [RFC3261]>
8.5. sip.pnsreg Media Feature Tag 8.5. sip.pnsreg Media Feature Tag
skipping to change at page 29, line 14 skipping to change at page 30, line 32
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 Firebase Cloud Messaging (FCM) push notification service
When Firebase Cloud Messaging (FCM) is used, the PNS related URI When Firebase Cloud Messaging (FCM) is used, the PNS related URI
parameters are set as described below. parameters are set as described below.
For detailed information about the parameter values: For detailed information about the parameter values:
https://firebase.google.com/docs/cloud-messaging/concept-options https://firebase.google.com/docs/cloud-messaging/concept-options
([pns-fcm]) [pns-fcm]
The value of the pn-provider URI parameter is "fcm". The value of the pn-provider URI parameter is "fcm".
The value of the pn-param URI parameter is the Project ID. The value of the pn-param URI parameter is the Project ID.
The value of the pn-prid URI parameter is the Registration token, The value of the pn-prid URI parameter is the Registration token,
which is generated by the FCM SDK for each client app instance. which is generated by the FCM SDK for each client app instance.
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) (Generic Event Delivery Using HTTP Push)
skipping to change at page 33, line 35 skipping to change at page 34, line 35
the "SIP Feature-Capability Indicator Registration Tree" sub-registry the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.vapid Name: sip.vapid
Description: This feature-capability indicator, when inserted in a Description: This feature-capability indicator, when inserted in a
SIP 2xx response to a SIP REGISTER request, denotes that the SIP 2xx response to a SIP REGISTER request, denotes that the
entity associated with the indicator supports the Voluntary entity associated with the indicator supports the Voluntary
Application Server Identification (VAPID) mechanism when the Application Server Identification (VAPID) mechanism when the
entity requests that a push notifications is sent to a SIP UA. entity requests that a push notifications be sent to a SIP UA.
The indicator value is a public key identifying the entity, The indicator value is a public key identifying the entity,
that can be used by a SIP UA to restrict subscriptions to that that can be used by a SIP UA to restrict subscriptions to that
entity. entity.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
14.3.3. sip.pnsreg 14.3.3. sip.pnsreg
skipping to change at page 34, line 15 skipping to change at page 35, line 15
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.pnsreg Name: sip.pnsreg
Description: This feature-capability indicator, when inserted in a Description: This feature-capability indicator, when inserted in a
SIP 2xx response to a SIP REGISTER request, denotes that the SIP 2xx response to a SIP REGISTER request, denotes that the
entity associated with the indicator expects to receive entity associated with the indicator expects to receive
binding-refresh REGISTER requests for the binding from the SIP binding-refresh REGISTER requests for the binding from the SIP
UA associated with the binding before the binding expires, even UA associated with the binding before the binding expires, even
if the entity does not request that a push notification is sent if the entity does not request that a push notification be sent
to the SIP UA in order to trigger the binding-refresh REGISTER to the SIP UA in order to trigger the binding-refresh REGISTER
requests. The indicator value conveys the minimum time requests. The indicator value conveys the minimum time
(given in seconds), prior to the binding expiration when the UA (given in seconds), prior to the binding expiration when the UA
MUST send the REGISTER request. MUST send the REGISTER request.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
14.3.4. sip.pnspurr 14.3.4. sip.pnspurr
 End of changes. 48 change blocks. 
117 lines changed or deleted 156 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/