draft-ietf-sipcore-sip-push-20.txt   draft-ietf-sipcore-sip-push-21.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: April 22, 2019 Metaswitch Networks Expires: June 10, 2019 Metaswitch Networks
October 19, 2018 December 7, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-20 draft-ietf-sipcore-sip-push-21
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
exchange PNS information between the SIP User Agent (UA) and the SIP exchange PNS information between the SIP User Agent (UA) and the SIP
entity that will request push notifications towards the UA, and to entity that will request push notifications towards the UA, and to
trigger such push notification requests. trigger such push notification requests.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
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 April 22, 2019. This Internet-Draft will expire on June 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 7 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 7
4.1. Request Push Notifications from Network . . . . . . . . . 7 4.1. Request Push Notifications from Network . . . . . . . . . 7
4.2. Query Network Push Notification Capabilities . . . . . . 9 4.2. Query Network Push Notification Capabilities . . . . . . 10
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 10 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 10
5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 10 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Trigger Periodic Binding Refresh . . . . . . . . . . . . 10 5.2. Trigger Periodic Binding Refresh . . . . . . . . . . . . 10
5.3. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 11 5.3. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 11 5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 11
5.3.2. Initial Request for Dialog or Stand-Alone Request . . 13 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 13
6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 15 6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 16
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 16 6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 16
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 16 6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 16
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 16 6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 17
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 16 6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 17
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 17 6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 17
6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 17 6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 18
7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 18 7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 18
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. 555 (Push Notification Service Not Supported) Response 8.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 19 8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 19
8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 19 8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 19
8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 19 8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 20
8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 20 8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 20
8.6. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 20 8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 21
8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 21
9. PNS Registration Requirements . . . . . . . . . . . . . . . . 21 9. PNS Registration Requirements . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . 21 Push Notification service . . . . . . . . . . . . . . . . . . 22
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 . . 22 Firebase Cloud Messaging (FCM) push notification service . . 22
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) . . . . . . . . . . 22 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23
14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24
14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 23 14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 24
14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 24 14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 24
14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 24 14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 24
14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 24 14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 24
14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 24 14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 25
14.2.1. 555 (Push Notification Service Not Supported) . . . 24 14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 25
14.2.1. 555 (Push Notification Service Not Supported) . . . 25
14.3. SIP Global Feature-Capability Indicator . . . . . . . . 25 14.3. SIP Global Feature-Capability Indicator . . . . . . . . 25
14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 25 14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 25
14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 25 14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 26
14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 26 14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 26
14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 26 14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 27
14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 27 14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 28
14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 27 14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 28
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 28
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
16.1. Normative References . . . . . . . . . . . . . . . . . . 28 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
16.2. Informative References . . . . . . . . . . . . . . . . . 29 16.1. Normative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 16.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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). Typically each operating using a Push Notification Service (PNS). Typically each operating
system uses a dedicated PNS. For example, Apple iOS devices use the system uses a dedicated PNS. 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. 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
those functions. those functions.
Also, without being able to use internal timers in order to wake Also, without being able to use internal timers in order to wake
applications, a UA will not be able to maintain connections e.g., applications, a UA will not be able to maintain connections e.g.,
using the SIP Outbound Mechanism [RFC5626], as it requires the UA to using the SIP Outbound Mechanism [RFC5626], as it requires the UA to
send periodic keep-alive messages. send periodic keep-alive messages.
This document describes how PNSs can be used to wake suspended UAs, This document describes how PNSs can be used to wake suspended UAs,
using push notifications, to be able to send binding refresh REGISTER using push notifications, to be able to send binding-refresh REGISTER
requests and to receive incoming SIP requests. The document defines requests and to receive incoming SIP requests. The document defines
new SIP URI parameters and new feature-capability indicators new SIP URI parameters and new feature-capability indicators
[RFC6809] that can be used in SIP messages to indicate support of the [RFC6809] that can be used in SIP messages to indicate support of the
mechanism defined in this document, to exchange PNS information mechanism defined in this document, to exchange PNS information
between the UA and the SIP entity (realized as a SIP proxy in this between the UA and the SIP entity (realized as a SIP proxy in this
document) that will request push notifications towards the UA, and to document) that will request push notifications towards the UA, and to
request such push notification requests. request such push notification requests.
NOTE: Even if a UA is able to be awaken other means than receiving NOTE: Even if a UA is able to be awakened by other means than
push notifications (e.g., by using internal timers) in order to send receiving push notifications (e.g., by using internal timers) in
periodic binding refresh REGISTER requests, it might still be useful order to send periodic binding-refresh REGISTER requests, it might
to suspend the application between the sending of binding refresh still be useful to suspend the application between the sending of
requests (as it will save battery life) and use push notifications to binding-refresh requests (as it will save battery life) and use push
wake the UA when an incoming SIP request UA arrives. notifications to wake the UA when an incoming SIP request UA arrives.
When a UA registers to a PNS, it will receive a unique Push Resource When a UA registers to a PNS, it will receive a unique Push Resource
ID (PRID) associated with the push notification registration. The UA ID (PRID) associated with the push notification registration. The UA
will use a REGISTER request to provide the PRID to the SIP proxy that will use a REGISTER request to provide the PRID to the SIP proxy that
will request push notifications towards the UA. will request push notifications towards the UA.
When the proxy receives 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, or when the proxy alone SIP request addressed towards a UA, or when the proxy
determines that the UA needs to send a binding refresh REGISTER determines that the UA needs to send a binding-refresh REGISTER
request, the proxy will request a push notification towards the UA, request, the proxy will request a push notification towards the UA,
using the PNS of the UA. Once the UA receives the push notification, using the PNS of the UA. Once the UA receives the push notification,
it will be able to send a binding refresh REGISTER request and it will be able to send a binding-refresh REGISTER request and
receive the incoming SIP request. The proxy will receive the receive the incoming SIP request. The proxy will receive the
REGISTER request. If the push notification request was triggered by REGISTER request. If the push notification request was triggered by
a SIP request addressed towards the UA (see above), once the REGISTER a SIP request addressed towards the UA (see above), once the REGISTER
request has been accepted by the SIP registrar [RFC3261], and the request has been accepted by the SIP registrar [RFC3261], and the
associated SIP 2xx response has been forwarded by the proxy towards associated SIP 2xx response has been forwarded by the proxy towards
the UA, the proxy can forward the SIP request towards the UA using the UA, the proxy can forward the SIP request towards the UA using
normal SIP routing procedures. In some cases the proxy can forward normal SIP routing procedures. In some cases the proxy can forward
the SIP request without waiting for the SIP 2xx response to the the SIP request without waiting for the SIP 2xx response to the
REGISTER request. Note that this mechanism necessarily adds delay to REGISTER request. Note that this mechanism necessarily adds delay to
responding to non-INVITE requests requiring push notification. The responding to requests requiring push notification. The consequences
consequences of that delay are discussed in Section 5.3.2. of that delay are discussed in Section 5.3.2.
Different PNSs exist today. Some are based on the standardized Different PNSs exist today. Some are based on the standardized
mechanism defined in [RFC8030], while others are proprietary (e.g., mechanism defined in [RFC8030], while others are proprietary (e.g.,
the Apple Push Notification service). Figure 1 shows the generic the Apple Push Notification service). Figure 1 shows the generic
push notification architecture supported by the mechanism in this push notification architecture supported by the mechanism in this
document. document.
Each PNS uses PNS-specific terminology and function names. The Each PNS uses PNS-specific terminology and function names. The
terminology in this document is meant to be PNS-independent. If the terminology in this document is meant to be PNS-independent. If the
PNS is based on [RFC8030], the SIP proxy takes the role of the PNS is based on [RFC8030], the SIP proxy takes the role of the
skipping to change at page 6, line 44 skipping to change at page 6, line 46
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Push Resource ID (PRID) 3. Push Resource ID (PRID)
When a SIP UA registers with a PNS it receives a unique Push Resource When a SIP UA registers with a PNS it receives a unique Push Resource
ID (PRID), which is a value associated with the registration that can ID (PRID), which is a value associated with the registration that can
be used to generate push notifications. be used to generate push notifications.
The format of the PRID may vary 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. Request Push Notifications from Network
Once the SIP UA has registered with the PNS, has received the PRID The procedures in this section apply to bindings associated with a
(using the protocol and procedures associated with the PNS), if the given PNS.
UA wants to receive push notifications (requested by the proxy), the
UA MUST 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.
If the SIP UA creates multiple bindings (e.g., one for IPv4 and one The mechanism defined in this document assumes that when a SIP UA
for IPv6), the UA SHOULD use the same 'expires' Contact header field registers with a PNS it has received the PRID (using the protocol and
parameter value [RFC3261] for each binding. procedures associated with the PNS). Then, if the UA wants to
receive push notifications (requested by the proxy), the UA MUST
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
one for IPv6), since a push notification will trigger to UA to
refresh all bindings, it is preferable if one can ensure that all
bindings expire at the same time. That will help preventing that
some bindings are refreshed earlier than needed.
When the UA receives a 2xx response to the REGISTER request, if the When the UA receives a 2xx response to the REGISTER request, if the
response contains a Feature-Caps header field [RFC6809] with a response contains a Feature-Caps header field [RFC6809] with a
'sip.pns' feature-capability indicator with a parameter value 'sip.pns' feature-capability indicator with a parameter value
identifying the same type of PNS that was identified by the pn- identifying the same type of PNS that was identified by the pn-
provider URI parameter in the REGISTER request, the UA can assume provider URI parameter in the REGISTER request, the UA can assume
that a SIP proxy will request push notifications towards the UA. In that a SIP proxy will request push notifications towards the UA. In
other cases, the UA MUST NOT assume that push notifications will be other cases, the UA MUST NOT assume that push notifications will be
requested, and the actions taken by the UA might be dependent on requested, and the actions taken by the UA might be dependent on
implementation or deployment architecture, and are outside the scope implementation or deployment architecture, and are outside the scope
of this document. of this document.
In addition, if the response contains a Feature-Caps header field In addition, if the response contains a Feature-Caps header field
with a 'sip.vapid' feature-capability indicator, the proxy supports with a 'sip.vapid' feature-capability indicator, the proxy supports
use of the Voluntary Application Server Identification (VAPID) use of the Voluntary Application Server Identification (VAPID)
mechanism [RFC8292] to restrict push notifications to the proxy. mechanism [RFC8292] to restrict push notifications to the proxy.
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 When the UA receives a push notification, it MUST send a binding-
refresh REGISTER request, using normal SIP procedures. If there are refresh REGISTER request, using normal SIP procedures. If there are
Network Address Translators (NATs) between the UA and the proxy, the Network Address Translators (NATs) between the UA and the proxy, the
REGISTER request will create NAT bindings that will allow incoming REGISTER request will create NAT bindings that will allow incoming
SIP requests to reach the UA. Once the UA has received a 2xx SIP requests to reach the UA. Once the UA has received a 2xx
response to the REGISTER request, the UA might receive a SIP request response to the REGISTER request, the UA might receive a SIP request
for a new dialog (e.g., a SIP INVITE), or a stand-alone SIP request for a new dialog (e.g., a SIP INVITE), or a stand-alone SIP request
(e.g., a SIP MESSAGE), if such SIP request triggered the push (e.g., a SIP MESSAGE), if such SIP request triggered the push
notification request. Note that, depending on which transport notification request. Note that, depending on which transport
protocol is used, the SIP request might reach the UA before the protocol is used, the SIP request might reach the UA before the
REGISTER response. REGISTER response.
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
triggered the push notification to reach the UA.
If the SIP UA has created multiple bindings (e.g., one for IPv4 and If the SIP UA has created multiple bindings (e.g., one for IPv4 and
one for IPv6), the UA MUST send a binding refresh REGISTER request one for IPv6), the UA MUST send a binding-refresh REGISTER request
for each of those bindings when it receives a push notification. for each of those bindings when it receives a push notification.
If the UA is able to send binding refresh REGISTER requests using a If the 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 URI of each REGISTER request. [RFC3840] in each Contact header field URI of each REGISTER request.
Then, if the response to the REGISTER request contains a 'sip.pnsreg' Then, if the response to the REGISTER request contains a 'sip.pnsreg'
feature-capability indicator with an indicator value, the UA MUST feature-capability indicator with an indicator value, the UA
send REGISTER requests prior to the registration expires. The refreshes the binding prior to the binding expires. The indicator
indicator value indicates a minimum time (given in seconds), prior to value indicates a minimum time (given in seconds), prior to the
the registration expires when the UA MUST send the REGISTER request. binding expires when the UA MUST send the REGISTER request. Even if
Even if the UA is able to to send REGISTER requests using a non-push the UA is able to to send REGISTER requests using a non-push
mechanism, the UA MUST still send a REGISTER request when it receives mechanism, the UA MUST still send a REGISTER request when it receives
a push notification, following the procedures in this section. If a push notification, following the procedures in this section. If
the REGISTER response does not contain a a 'sip.pnsreg' feature- the REGISTER response does not contain a a 'sip.pnsreg' feature-
capability indicator, the UA SHOULD only send a re-registration capability indicator, the UA SHOULD only send a re-registration
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 re-registration is able to use a non-push mechanism for sending re-registration
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: In some cases the UA might be able to use a non-push mechanism NOTE: If the UA uses a non-push mechanism to wake and send a binding
to wake and send binding refresh REGISTER requests. Such REGISTER refresh REGISTER request, such REGISTER request will update the
request will update the registration expiration timer, and the proxy binding expiration timer, and the proxy does not need to request a
does not need to request a push notification towards the UA in order push notification towards the UA in order to wake the UA. The proxy
to wake the UA. The proxy will still request a push notification will still request a push notification towards the UA when the proxy
towards the UA when the proxy receives a SIP request addressed receives a SIP request addressed towards the UA (Section 5.3.2).
towards the UA (Section 5.3.2). This allows the UA to e.g., use This allows the UA to e.g., use timers for sending binding-refresh
timers for sending binding refresh REGISTER requests, but to be REGISTER requests, but to be suspended (in order to save battery
suspended (in order to save battery resources etc) between sending resources etc) between sending the REGISTER requests and use push
the REGISTER requests and use push notification to wake the UA to notification to wake the UA to process incoming calls.
process incoming calls.
NOTE: This specification does not define any usage of a push NOTE: This specification does not define any usage of a push
notification payload. As defined in Section 5.3.2, a proxy must not 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 include any payload in the push notification request. If a SIP UA
receives a push notification that contains a payload the UA can receives a push notification that contains a payload the UA can
discard the payload, but the UA will still send a binding refresh discard the payload, but the UA will still send a binding-refresh
REGISTER request. REGISTER request.
NOTE: If the SIP UA application wants to use push notifications for NOTE: If the SIP UA application wants to use push notifications for
other purposes than to trigger binding refresh requests, it needs to other purposes than to trigger binding-refresh requests, it needs to
be able to distinguish between the different purposes when receiving be able to distinguish between the different purposes when receiving
push notifications. Mechanisms for doing that are outside the scope push notifications. Mechanisms for doing that are outside the scope
of this specification. of this specification.
As long as the UA wants to receive push notifications (requested by As long as the UA wants to receive push notifications (requested by
the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param
(if required for the specific PNS provider) SIP URI parameter in each (if required for the specific PNS provider) SIP URI parameter in each
binding refresh REGISTER request. Note that, in some cases, the PNS binding-refresh REGISTER request. Note that, in some cases, the PNS
might update the PRID value, in which case the UA will include the might update the PRID value, in which case the UA will include the
new value in the pn-prid SIP URI parameter in the binding refresh new value in the pn-prid SIP URI parameter in the binding-refresh
REGISTER request. REGISTER request.
If the UA no longer wants to receive push notifications (requested by If the UA no longer wants to receive push notifications (requested by
the proxy), the UA MUST send a binding refresh REGISTER request the proxy), the UA MUST send a binding-refresh REGISTER request
without including the SIP URI parameters described above, or the UA without including the SIP URI parameters described above, or the UA
MUST remove the registration. MUST remove the registration.
If a UA's subscription to a PNS (and the associated PRID) is only If a UA's subscription to a PNS (and the associated PRID) is only
valid for a limited time then the UA is responsible for retrieving valid for a limited time then the UA is responsible for retrieving
new subscription details from the PNS and sending a 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 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 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 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 proxy that it no longer wants push notifications) or terminate
skipping to change at page 9, line 43 skipping to change at page 10, line 7
document. document.
For privacy and security reasons, the UA MUST NOT include the SIP URI For privacy and security reasons, the UA MUST NOT include the SIP URI
parameters defined in this document in non-REGISTER request, to parameters defined in this document in non-REGISTER request, to
prevent the PNS information associated with the UA from reaching the prevent the PNS information associated with the UA from reaching the
remote peer. For example, the UA MUST NOT include the SIP URI remote peer. For example, the UA MUST NOT include the SIP URI
parameters in the Contact header field of an INVITE request. parameters in the Contact header field of an INVITE request.
4.2. Query Network Push Notification Capabilities 4.2. Query Network Push Notification Capabilities
A SIP UA might need to query the network for push notification A SIP UA might need to query the SIP network for push notification
capabilities (e.g., related to VAPID) before it registers with the capabilities (e.g., related to VAPID) before it registers with the
PNS, and before it indicates that it wants to receive push PNS, and before it indicates that it wants to receive push
notifications. The UA can do so by only including the pn-provider 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 SIP URI parameter in the SIP Contact header field URI of the REGISTER
request, but without including the pn-prid SIP URI parameter. Later, request, but without including the pn-prid SIP URI parameter. Later,
once the UA has received a response to the REGISTER request, with the once the UA has received a response to the REGISTER request with the
push notification information from the network, if the UA wants to push notification information from the network, if the UA wants to
receive push notifications, the UA will send a binding refresh receive push notifications, the UA will send a binding-refresh
REGISTER request, including all pn- SIP URI parameters required by REGISTER request, including all pn- SIP URI parameters required by
the specific PNS, following the procedures in Section 4.1. 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.
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. Trigger Periodic Binding Refresh
In order to request push notifications towards a SIP UA that will In order to request push notifications towards a SIP UA that will
trigger the UA to send binding refresh SIP REGISTER requests, the SIP trigger the UA to send binding-refresh SIP REGISTER requests, the SIP
proxy needs to have information about when a registration will proxy needs to have information about when a registration will
expire. The proxy needs to be able to retrieve the information from expire. The proxy needs to be able to retrieve the information from
the registrar using some mechanism. Such mechanisms are outside the the registrar using some mechanism. Such mechanisms are outside the
scope of this document, but could be implemented e.g., using the scope of this document, but could be implemented e.g., using the
SIPregistration event package mechanism [RFC3680]. SIPregistration event package 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 requests a push binding-refresh REGISTER request, the proxy requests a push
notification towards the UA. notification towards the UA.
Note that the push notification needs to be requested early enough, Note that the push notification needs to be requested early enough
in order for the associated binding refresh REGISTER request to reach for the associated binding-refresh REGISTER request to reach the
the registrar before the registration expires. It is RECOMMENDED registrar before the registration expires. It is RECOMMENDED that
that the proxy requests the push notification at least 120 seconds the proxy requests the push notification at least 120 seconds before
before the registration expires. the registration expires.
If the UA has indicated, using the 'sip.pnsreg' media feature tag, If the UA has indicated, using the 'sip.pnsreg' media feature tag,
that it is able to wake using a non-push mechanism for sending that it is able to wake using a non-push mechanism for sending
binding refresh REGISTER requests, if the proxy does not receive a binding-refresh REGISTER requests, if the proxy does not receive a
REGISTER request prior to 120 seconds before the registration REGISTER request prior to 120 seconds before the registration
expires, the proxy MAY request a push notification towards the UA, to expires, the proxy MAY request a push notification towards the UA, to
trigger the UA to send a REGISTER request. trigger the UA to send a REGISTER request.
NOTE: As described in Section 4.2, a SIP UA might send a REGISTER NOTE: As described in Section 4.2, a SIP 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 push notifications towards a UA that has not will not request push notifications towards a UA that has not
provided a pn-prid SIP URI parameter. provided a pn-prid SIP URI parameter.
If the proxy receives information that a registration has expired, If the proxy receives information that a registration has expired,
the proxy MUST NOT request further push notifications towards the UA. the proxy MUST NOT request further push notifications towards the UA.
5.3. SIP Requests 5.3. SIP Requests
5.3.1. REGISTER 5.3.1. REGISTER
The procedures in this section apply when the SIP proxy receives a The procedures in this section apply when the SIP proxy receives a
SIP REGISTER request (initial REGISTER request for a registration, or SIP REGISTER request (initial REGISTER request for a registration, or
a binding refresh REGISTER request) that contains a pn-provider SIP a binding-refresh REGISTER request) that contains a pn-provider SIP
URI parameter identifying a type of PNS. If the proxy receives a URI parameter identifying a type of PNS. If the proxy receives a
REGISTER request that does not contain a pn-provider SIP URI REGISTER request that does not contain a pn-provider SIP URI
parameter, or that removes the registration, the proxy MUST NOT parameter, or that removes the registration, the proxy MUST NOT
request push notifications towards the UA associated with the request push notifications towards the UA associated with the
REGISTER request, or perform any other procedures in this section. REGISTER request or perform any other procedures in this section.
As described in Section 4.2, a SIP UA might send a REGISTER request As described in Section 4.2, a SIP UA might send a REGISTER request
without including a pn-prid SIP URI parameter in the Contact header without including a pn-prid SIP URI parameter in the Contact header
field URI, in order to retrieve push notification capabilities from field URI, in order to retrieve push notification capabilities from
the network before the UA the proxy will request push notifications the network before the UA the proxy will request push notifications
towards the UA. The procedures in this section apply to both the towards the UA. The procedures in this section apply to both the
case when the REGISTER request contains a pn-prid SIP URI parameter, case when the REGISTER request contains a pn-prid SIP URI parameter,
and when it does not. and when it does not.
When the proxy receives a REGISTER request, if the REGISTER request When the proxy receives a REGISTER request, if the REGISTER request
contains a Feature-Caps header field with a 'sip.pns' feature- contains a Feature-Caps header field with a 'sip.pns' feature-
capability indicator, it indicates that a proxy between this proxy capability indicator, it indicates that a proxy between this proxy
and the UA supports, and will request (if the Contact header field and the UA supports requesting push notifications towards the UA.
URI of the REGISTER request contains a pn-prid SIP URI parameter), The proxy MUST skip the rest of the procedures in this section, and
push notifications towards the UA. The proxy MUST skip the rest of process the REGISTER request using normal SIP procedures.
the procedures in this section, and process the REGISTER request
using normal SIP procedures.
If the proxy considers the requested registration expiration interval If the proxy considers the requested registration expiration interval
[RFC3261] to be too short, the proxy MUST either send a 423 (Interval [RFC3261] to be too short, the proxy MUST either send a 423 (Interval
Too Brief) response to the REGISTER request, or skip the rest of the Too Brief) response to the REGISTER request, or skip the rest of the
procedures in this section and process the REGISTER request using procedures in this section and process the REGISTER request using
normal SIP procedures. If the proxy sends a 423 (Interval Too Brief) normal SIP procedures. If the proxy sends a 423 (Interval Too Brief)
response, the proxy SHOULD insert a Feature-Caps header field with a response, the proxy SHOULD insert a Feature-Caps header field with a
'sip.pns' feature-capability indicator in the response, identifying 'sip.pns' feature-capability indicator in the response, identifying
each type of PNS that the proxy supports. Similarly, when the proxy each type of PNS that the proxy supports. Similarly, when the proxy
receives a 2xx response to the REGISTER request (see below), if the receives a 2xx response to the REGISTER request (see below), if the
skipping to change at page 12, line 12 skipping to change at page 12, line 20
registration. A registration expiration interval MUST be considered registration. A registration expiration interval MUST be considered
too short if the interval is smaller than the time prior to too short if the interval is smaller than the time prior to
expiration that the proxy would request a push notification. The expiration that the proxy would request a push notification. The
proxy MAY consider the interval too small based on its own policy so proxy MAY consider the interval too small based on its own policy so
as to reduce load on the system. as to reduce load on the system.
Otherwise, if the pn-provider SIP URI parameter identifies a type of Otherwise, if the pn-provider SIP URI parameter identifies a type of
PNS that the proxy does not support, or if the REGISTER request does PNS that the proxy does not support, or if the REGISTER request does
not contain all additional information required for the specific type not contain all additional information required for the specific type
of PNS, the proxy MUST either forward the request (e.g., if the proxy of PNS, the proxy MUST either forward the request (e.g., if the proxy
knows that a proxy that is not between the push proxy and the UA knows that another proxy that will receive the REGISTER request
supports the type of PNS) or send a SIP 555 (Push Notification supports the type of PNS) or send a SIP 555 (Push Notification
Service Not Supported) response to the REGISTER request. If the Service Not Supported) response to the REGISTER request. If the
proxy sends a SIP 555 (Push Notification Service Not Supported) proxy sends a SIP 555 (Push Notification Service Not Supported)
response Section 8.1, the proxy SHOULD insert a Feature-Caps header response Section 8.1, the proxy SHOULD insert a Feature-Caps header
field with a 'sip.pns' feature-capability indicator in the response, field with a 'sip.pns' feature-capability indicator in the response,
identifying the type of each PNS that the proxy supports. The identifying the type of each PNS that the proxy supports. The
decision whether to forward the request, or to send a response, is decision whether to forward the request, or to send a response, is
done based on local policy. done based on local policy.
If the proxy supports the type of PNS identified by the pn-provider If the proxy supports the type of PNS identified by the pn-provider
skipping to change at page 12, line 40 skipping to change at page 12, line 48
UA. UA.
If the proxy inserted a Feature-Caps header field with a 'sip.pns' If the proxy inserted a Feature-Caps header field with a 'sip.pns'
feature-capability indicator in the REGISTER request (see above), if feature-capability indicator in the REGISTER request (see above), if
the proxy receives a 2xx response to the REGISTER request, the proxy the proxy receives a 2xx response to the REGISTER request, the proxy
MUST insert a Feature-Caps header field with a 'sip.pns' feature- MUST insert a Feature-Caps header field with a 'sip.pns' feature-
capability indicator in the response, identifying the type of PNS. capability indicator in the response, identifying the type of PNS.
This will inform the UA that the proxy supports, and will request (if 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- the Contact header field URI of the REGISTER request contained a pn-
prid SIP URI parameter), push notifications towards the UA. The prid SIP URI parameter), push notifications towards the UA. The
proxy MUST only indicate support of the same PNS that was identified 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 in the pn-provider SIP URI parameter in the REGISTER request. If the
proxy receives a receives a SIP 555 (Push Notification Service Not proxy receives a receives a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD insert a Feature-Caps header Supported) response, the proxy SHOULD insert a Feature-Caps header
field with a 'sip.pns' feature-capability indicator in the response, field with a 'sip.pns' feature-capability indicator in the response,
identifying the type of each PNS that the proxy supports. identifying the type of each PNS that the proxy supports.
In addition, if the proxy receives a 2xx response to the REGISTER In addition, if the proxy receives a 2xx response to the REGISTER
request: request:
o if the proxy supports, and will use, the VAPID mechanism, the o if the proxy supports, and will use, the VAPID mechanism, the
proxy MUST insert a Feature-Caps header field with a 'sip.vapid' proxy MUST insert a Feature-Caps header field with a 'sip.vapid'
feature-capability indicator in the response. The header field feature-capability indicator in the response. The header field
parameter contains the public key identifying the proxy [RFC8292]. parameter contains the public key identifying the proxy [RFC8292].
The proxy MUST be able to determine whether the PNS supports the The proxy MUST determine whether the PNS supports the VAPID
VAPID mechanism before it inserts the feature-capability mechanism before it inserts the feature-capability indicator.
indicator.
o if the proxy received a 'sip.pnsreg' media feature tag in the o 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 include a 'sip.pnsreg' feature-
capability indicator with an indicator value bigger than 120 in capability indicator with an indicator value bigger than 120 in
the response, unless the proxy always want to request push the response, unless the proxy always want to request push
notifications to trigger the UA to send a REGISTER request. notifications to trigger the UA to send a REGISTER request.
5.3.2. Initial Request for Dialog or Stand-Alone Request 5.3.2. Initial Request for Dialog or Stand-Alone Request
The procedures in this section apply when the SIP proxy has indicated The procedures in this section apply when the SIP proxy has indicated
that it supports, and will request, push notifications towards the that it supports, and will request, push notifications towards the
skipping to change at page 13, line 30 skipping to change at page 13, line 37
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
a push notification towards the UA, using the PRID included in the a push notification towards the UA, using the PRID included in the
pn-prid SIP URI parameter and the PNS identified by the pn-provider pn-prid SIP URI parameter and the PNS identified by the pn-provider
SIP URI parameter. SIP URI parameter.
The push notification will trigger the UA to send a binding refresh The push notification will trigger the UA to send a binding-refresh
REGISTER request. The proxy will process the REGISTER request and REGISTER request. The proxy will process the REGISTER request and
the associated response as described in Section 5.3.1. In case of a the associated response as described in Section 5.3.1. In case of a
2xx response to the REGISTER request, once the proxy has forwarded 2xx response to the REGISTER request, once the proxy has forwarded
the REGISTER response towards the UA, if the contact of the SIP the REGISTER response towards the UA, if the contact of the SIP
REGISTER request associated with the REGISTER response matches the REGISTER request associated with the REGISTER response matches the
Request-URI of the SIP request to be forwarded, and the contact was Request-URI of the SIP request to be forwarded, and the contact was
also present (and has not expired) in the REGISTER response, the also present (and has not expired) in the REGISTER response, the
proxy can forward the SIP request towards the UA, using normal SIP proxy can forward the SIP request towards the UA, using normal SIP
procedures. If the contact of the REGISTER request does not match 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 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 was not present in the REGISTER response, the proxy MUST reject the
SIP request with a 404 (Not Found) response. This can happen if the SIP request with a 404 (Not Found) response. This can happen if the
UA sends a binding refresh REGISTER request with a new contact at the UA sends a binding-refresh REGISTER request that does not contain the
same time the registrar forwards a SIP request towards a UA using the previously registered contact at the same time the registrar forwards
previously registered contact in the Request-URI. 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
proxy processing of the request is based on local policy, e.g.,
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 When matching the Request-URI of the SIP request to be forwarded with
a contact of a REGISTER request, the proxy uses the URI comparison a contact of a REGISTER request, the proxy uses the URI comparison
rules in [RFC8292], with the following addition: the pn-prid SIP URI rules in [RFC8292], with the following addition: the pn-prid SIP URI
parameter MUST also match. If the parameter is not present in the parameter MUST also match. If the parameter is not present in the
Request-URI of the SIP request, or in the contact of the REGISTER, Request-URI of the SIP request, or in the contact of the REGISTER,
there is no match. there is no match.
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 the SIP request is to make sure that the REGISTER request
has been accepted by the registrar, and that the UA which initiated has been accepted by the registrar, and that the UA which initiated
the REGISTER request is authorized to receive messages for the the REGISTER request is authorized to receive messages for the
Request-URI. However, if the proxy is able to authorize the sender Request-URI. However, if the proxy is able to authorize the sender
of the REGISTER request, it does not need to wait for the associated 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 2xx response before it forwards the SIP request towards the UA. The
mechanism for authorizing the UA is outside the scope of this mechanism for authorizing the UA is outside the scope of this
document. document.
As both the SIP request to be forwarded towards the UA, and the As both the SIP request to be forwarded towards the UA and the
binding refresh REGISTER request triggered by the push notification binding-refresh REGISTER request triggered by the push notification
request, will convey pn- SIP URI parameters associated with the SIP request will convey pn- SIP URI parameters associated with the SIP
registration, those can be used to match the SIP request with the registration, those can be used to match the SIP request with the
binding refresh REGISTER request (even if the most recent contact and binding-refresh REGISTER request (even if other parts of the most
the Request-URI of the SIP request do not match). 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 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 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. 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 In case of non-2xx response to the REGISTER request, the proxy MUST
reject the SIP request with a 404 (Not Found) response. reject the SIP request with a 404 (Not Found) response.
If the push notification request fails (see PNS-specific If the push notification request fails (see PNS-specific
documentation for details), the proxy MUST reject the SIP request documentation for details), the proxy MUST reject the SIP request
with a 480 (Temporarily Unavailable) response. with a 480 (Temporarily Unavailable) response.
If the proxy does not receive the REGISTER request from the UA within If the proxy does not receive the REGISTER request from the UA within
a given time after the proxy has requested the push notification, the a given time after the proxy has requested the push notification, the
proxy MUST reject the request with a 480 (Temporarily Unavailable) proxy MUST reject the request with a 480 (Temporarily Unavailable)
response. The time value is set based on local policy. response. The time value is set based on local policy.
As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must
complete immediately or risk losing 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
sender of the request (UAC), and the sender will consider the sender of the request (UAC), and the sender will consider the
transaction a failure. If the proxy forwards the SIP request towards transaction a failure. If the proxy forwards the SIP request towards
the SIP UA, the SIP UA accepts the request and the transaction times the SIP UA, the SIP UA accepts the request and the transaction times
skipping to change at page 15, line 51 skipping to change at page 16, line 18
push notification towards the UA. If the proxy has knowledge that push notification towards the UA. If the proxy has knowledge that
the UA is awake, and that the UA is able to receive the SIP request, the UA is awake, and that the UA is able to receive the SIP request,
the proxy MAY forwards the request towards the UA. Otherwise the the proxy MAY forwards the request towards the UA. Otherwise the
proxy MUST reject the SIP request with a 480 (Temporarily proxy MUST reject the SIP request with a 480 (Temporarily
Unavailable) response. Unavailable) response.
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 SIP NOTIFY used, there might be a long period between mid-dialog requests are
requests are sent. Because of this a SIP UA might get suspended, and sent. Because of this a SIP UA might get suspended, and needs to be
needs to be awaken in order to be able to receive mid-dialog awaken in order to be able to receive mid-dialog requests.
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
push notifications towards the UA Section 5.3.2. However, this push notifications towards the UA Section 5.3.2. However, this
information will not be present in mid-dialog requests towards the information will not be present in mid-dialog requests towards the
UA. Instead, the proxy need to support a mechanism where it stores UA. Instead, the proxy need to support a mechanism where it stores
the information needed to request a push notification towards the UA the information needed to request a push notification towards the UA
and be able to find and retrieve that information when it receives a and be able to find and retrieve that information when it receives a
mid-dialog request. This section defines such mechanism. The UA and mid-dialog request. This section defines such mechanism. The UA and
skipping to change at page 16, line 37 skipping to change at page 17, line 5
purr' SIP URI parameter in the Contact header of the request or purr' SIP URI parameter in the Contact header of the request or
response. The UA MUST include a parameter value identical to the the response. The UA MUST include a parameter value identical to the the
last 'sip.pnspurr' feature-capability indicator that it received in a last 'sip.pnspurr' feature-capability indicator that it received in a
REGISTER response. REGISTER 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 give
dialog, the UA needs to include a 'pn-purr' parameter in the Contact
header of the request or response for each dialog in which the UA is
willing to receive push notifications triggered by incoming 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 the proxy receives an initial REGISTER request for a
registration from the UA, if the proxy supports requesting push registration from the UA, if the proxy supports requesting push
notifications, triggered by mid-dialog requests, towards the notifications, triggered by mid-dialog requests, towards the
registered UA, the proxy MUST store the information (the pn- SIP URI registered UA, the proxy MUST store the information (the pn- SIP URI
parameters) needed to request push notifications associated with the parameters) needed to request push notifications associated with the
registration towards the UA. In addition the proxy MUST generate a registration towards the UA. In addition the proxy MUST generate a
unique (within the context of the proxy) value, referred to as the unique (within the context of the proxy) value, referred to as the
PURR (Proxy Unique Registration Reference), that is unique within the PURR (Proxy Unique Registration Reference), that is unique within the
context of the proxy and that can be used as a key to retrieve 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 information. When the proxy receives the associated 2xx REGISTER
response, it adds a 'sip.pnspurr' feature-capability indicator with response, it adds a 'sip.pnspurr' feature-capability indicator with
the PURR value to the associated 2xx REGISTER response. When the the PURR value to the associated 2xx REGISTER response. When the
proxy receives a binding refresh REGISTER request, it MUST add a proxy receives a binding-refresh REGISTER request, it MUST add a
'sip.pnspurr' feature-capability indicator with the previously 'sip.pnspurr' feature-capability indicator with the previously
generated key as the value to the associated 2xx REGISTER response. 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 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 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 In order to prevent client fingerprinting, the proxy MUST
periodically generate a new PURR value (even if pn- parameters did periodically generate a new PURR value (even if pn- parameters did
not change) and provide the new value to the UA in a 2xx binding not change) and provide the new value to the UA in a 2xx binding-
refresh REGISTER response. However, as long as there are ongoing refresh REGISTER response. However, as long as there are ongoing
dialogs associated with the old value, the proxy MUST store it so dialogs associated with the old value, the proxy MUST store it so
that it can request push notifications towards the UA when it that it can request push notifications towards the UA when it
receives a mid-dialog request addressed towards the UA. 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 the proxy receives an initial request for a dialog from the UA,
and if the request contains a 'pn-purr' SIP URI parameter in the and if the request contains a 'pn-purr' SIP URI parameter in the
Contact header field with a PURR value that the proxy has generated Contact header field with a PURR value that the proxy has generated
skipping to change at page 18, line 46 skipping to change at page 19, line 20
8. Grammar 8. Grammar
8.1. 555 (Push Notification Service Not Supported) Response Code 8.1. 555 (Push Notification Service Not Supported) Response Code
The 555 response code is added to the "Server-Error" Status-Code The 555 response code is added to the "Server-Error" Status-Code
definition. 555 (Push Notification Service Not Supported) is used to definition. 555 (Push Notification Service Not Supported) is used to
indicate that the server did not support the push notification indicate that the server did not support the push notification
service identified in a 'pn-provider' SIP URI parameter. service identified in a 'pn-provider' SIP URI parameter.
The use of the SIP 555 response code is defined for SIP REGISTER The use of the SIP 555 response code is 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 included in a Feature-
Caps header field of a SIP REGISTER request or a SIP 2xx response to Caps header field of a SIP REGISTER request or a SIP 2xx response to
a REGISTER request, indicates that the entity associated with the a REGISTER request, indicates that the entity associated with the
indicator supports, and will use, the SIP push mechanism and the push indicator supports, and will use, the SIP push mechanism and the push
notification service identified by the indicator value. When notification service identified by the indicator value. When
included in a 555 (Push Notification Service Not Supported) response included in a 555 (Push Notification Service Not Supported) response
skipping to change at page 19, line 45 skipping to change at page 20, line 17
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 included in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, indicates that the entity
associated with the indicator expects to receive binding refresh associated with the indicator expects to receive binding-refresh
REGISTER requests from the SIP UA associated with the registration REGISTER requests from the SIP UA associated with the registration
before the registration expires, without the entity having to request before the registration expires, without the entity having to request
push notifications towards the SIP UA in order to trigger the push notifications towards the SIP UA in order to trigger the
REGISTER requests. The indicator value is the minimum value (given REGISTER requests. The indicator value is the minimum value (given
in seconds) before the registration expiration when the entity in seconds) before the registration expiration when the entity
expects to receive the REGISTER request. expects to receive the REGISTER request.
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT reg = 1*DIGIT
DIGIT = <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 included in the SIP Contact
header field of a SIP REGISTER request, indicates that the SIP UA header field of a SIP REGISTER request, indicates that the SIP UA
associated with the tag is able to send binding refresh REGISTER associated with the tag is able to send binding-refresh REGISTER
requests associated with the registration without being awaken by requests associated with the registration without being awaken by
push notifications. The media feature tag has no values. push notifications. The media feature tag has no values.
pnsreg-mt = "+sip.pnsreg" pnsreg-mt = "+sip.pnsreg"
8.6. SIP URI Parameters 8.6. sip.pnspurr Feature-Capability Indicator
The sip.pnspurr feature-capability indicator, when included in a SIP
2xx response to a SIP REGISTER request, indicates that the entity
associated with the indicator will store information that can be used
to associate a mid-dialog SIP request with the binding information in
the REGISTER request.
pnspurr-fc = "+sip.pnspurr" EQUAL LDQUOT pnspurr RDQUOT
pnspurr = tag-value
tag-value = <tag-value defined in [RFC3840]>
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 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
pvalue = <pvalue defined in [RFC3261]> pvalue = <pvalue defined in [RFC3261]>
EQUAL = <EQUAL defined in [RFC3261]> EQUAL = <EQUAL defined in [RFC3261]>
COLON = <COLON defined in [RFC3261]> COLON = <COLON 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.
Parameter value characters that are not part of pvalue needs to be Parameter value characters that are not part of pvalue needs to be
escaped, as defined in RFC 3261. escaped, as defined in RFC 3261.
9. PNS Registration Requirements 9. PNS Registration Requirements
When a new value is registered to the PNS Sub-registry, a reference When a new value is registered to the PNS Sub-registry, a reference
to a specification which describes the PNS associated with the value to a specification which describes the usage of the PNS associated
is provided. That specification MUST contain the following with the value is provided. That specification MUST contain the
information: following information:
o The value of the pn-provider SIP URI parameter. o The value of the pn-provider SIP URI parameter.
o How the pn-prid SIP URI parameter value is retrieved and set by o How the pn-prid SIP URI parameter value is retrieved and set by
the SIP UA. the SIP UA.
o How the pn-param SIP URI parameter (if required for the specific o How the pn-param SIP URI parameter (if required for the specific
PNS provider) value is retrieved and set by the SIP UA. PNS provider) value is retrieved and set by the SIP UA.
10. pn-provider, pn-param and pn-prid URI Parameters for Apple Push 10. pn-provider, pn-param and pn-prid URI Parameters for Apple Push
Notification service Notification service
When the Apple Push Notification service (APNs) is used, the PNS- When the Apple Push Notification service (APNs) is used, the PNS-
related SIP URI parameters are set as described below. related SIP URI parameters are set as described below.
skipping to change at page 21, line 43 skipping to change at page 22, line 20
10. pn-provider, pn-param and pn-prid URI Parameters for Apple Push 10. pn-provider, pn-param and pn-prid URI Parameters for Apple Push
Notification service Notification service
When the Apple Push Notification service (APNs) is used, the PNS- When the Apple Push Notification service (APNs) is used, the PNS-
related SIP URI parameters are set as described below. related SIP URI parameters are set as described below.
The value of the pn-provider URI parameter is "apns". The value of the pn-provider URI parameter is "apns".
Example: pn-provider = apns Example: pn-provider = apns
The value of the pn-param URI parameter is the APNs App ID, which is The value of the pn-param URI parameter is a string that is composed
encoded by two values, separated by a period (.): Team ID and Bundle by two values, separated by a period (.): Team ID and Topic. The
ID. The Team ID is provided by Apple and is unique to a development Team ID is provided by Apple and is unique to a development team.
team. The Bundle ID is unique to a development team, and is a string The Topic consists of the Bundle ID, which uniquelly identifies an
that will match a single application or a group of applications. appliciation, and a service value that identifies a service
associated with the application, separated by a period (.). For VoIP
applications the service value is "voip".
Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip
Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp
The value of the pn-prid URI parameter is the device token, which is The value of the pn-prid URI parameter is the device token, which is
a unique identifier assigned by Apple to a specific app on a specific a unique identifier assigned by Apple to a specific app on a specific
device. device.
Example: pn-prid = 00fc13adff78512 Example: pn-prid = 00fc13adff78512
For more information on the APNs App ID: For more information about the APNs Topic and device token:
https://developer.apple.com/library/content/documentation/General/
Conceptual/DevPedia-CocoaCore/AppID.html
For more information on the APNs device token:
https://developer.apple.com/library/content/documentation/NetworkingI https://developer.apple.com/library/archive/documentation/NetworkingI
nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re nternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html
f/doc/uid/TP40008194-CH8-SW13
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.
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.
skipping to change at page 23, line 28 skipping to change at page 23, line 46
does not require any additional information to be exchanged between does not require any additional information to be exchanged between
the device and the PNS. the device and the PNS.
Typically, the PNS also requires the SIP proxy requesting push Typically, the PNS also requires the SIP proxy requesting push
notifications to be authenticated and authorized by the PNS. In some notifications to be authenticated and authorized by the PNS. In some
cases the PNS also require the SIP application (or the SIP cases the PNS also require the SIP application (or the SIP
application developer) to be identified in order for the application application developer) to be identified in order for the application
to request push notifications. to request push notifications.
Operators MUST ensure that the SIP signalling is properly secured, Operators MUST ensure that the SIP signalling is properly secured,
e.g., using encryption, from malicious middlemen, unless they are e.g., using encryption, from malicious middlemen. TLS MUST be used,
sure that the signalling cannot be accessed and used maliciously unless the operators know that the signalling is secured using some
(e.g., to trigger push notifications towards a device) by a other mechanism.
middleman.
[RFC8292] defines a mechanism which allows a proxy to identity itself [RFC8292] defines a mechanism which allows a proxy to identity itself
to a PNS, by signing a JWT sent to the PNS using a key pair. The to a PNS, by signing a JWT sent to the PNS using a key pair. The
public key serves as an identifier of the proxy, and can be used by public key serves as an identifier of the proxy, and can be used by
devices to restrict push notifications to the proxy associated with devices to restrict push notifications to the proxy associated with
the key. the key.
The mechanism in this document does not require a proxy to include The mechanism in this document does not require a proxy to include
any payload (in addition to possible payload used for the PNS itself) any payload (in addition to possible payload used for the PNS itself)
when requesting push notifications. when requesting push notifications.
skipping to change at page 24, line 29 skipping to change at page 25, line 5
Reference: RFC XXXX Reference: RFC XXXX
14.1.3. pn-prid 14.1.3. pn-prid
Parameter Name: pn-prid Parameter Name: pn-prid
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
14.1.4. pn-purr
Parameter Name: pn-purr
Predefined Values: No
Reference: RFC XXXX
14.2. SIP Response Codes 14.2. SIP Response Codes
14.2.1. 555 (Push Notification Service Not Supported) 14.2.1. 555 (Push Notification Service Not Supported)
This section defines a new SIP response code that extends the This section defines a new SIP response code that extends the
"Response Codes" sub-registry [RFC3261] under the sip-parameters "Response Codes" sub-registry [RFC3261] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters. registry: http://www.iana.org/assignments/sip-parameters.
Response Code Number: 555 Response Code Number: 555
skipping to change at page 26, line 24 skipping to change at page 27, line 4
to restrict subscriptions to that entity. to restrict subscriptions to that entity.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
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 included in a
SIP 2xx response to a SIP REGISTER request, indicates that the SIP 2xx response to a SIP REGISTER request, indicates that the
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 from the SIP UA associated
with the registration before the registration expires, without with the registration before the registration expires, without
the entity having to request push notifications towards the SIP the entity having to request push notifications towards the SIP
UA in order to trigger the REGISTER requests. The indicator UA in order to trigger the REGISTER requests. The indicator
value is the minimum value (given in seconds) before the value is the minimum value (given in seconds) before the
registration expireation when the entity expects to receive the registration expireation when the entity expects to receive the
REGISTER request. REGISTER request.
Reference: [RFCXXXX] Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org) Contact: IESG (iesg@ietf.org)
14.3.4. sip.pnspurr
This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters.
Name: sip.pnspurr
Description: This feature-capability indicator, when included in a
SIP 2xx response to a SIP REGISTER request, indicates that
the entity associated with the indicator will store information
that can be used to associate a mid-dialog SIP request with the
binding information in the REGISTER request. The indicator
value is an identifier that can be used a key to retrieve the
binding information.
Reference: [RFCXXXX]
Contact: IESG (iesg@ietf.org)
14.4. SIP Media Feature Tag 14.4. SIP Media Feature Tag
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
skipping to change at page 27, line 16 skipping to change at page 28, line 19
This section defines a new media feature tag that extends the "SIP This section defines a new media feature tag that extends the "SIP
Media Feature Tag Registration Tree" sub-registry [RFC3840] under the Media Feature Tag Registration Tree" sub-registry [RFC3840] under the
Media Feature Tag registry: https://www.iana.org/assignments/media- Media Feature Tag registry: https://www.iana.org/assignments/media-
feature-tags/media-feature-tags.xhtml. feature-tags/media-feature-tags.xhtml.
Media feature tag name: sip.pnsreg Media feature tag name: sip.pnsreg
Summary of the media feature indicated by this feature tag: This Summary of the media feature indicated by this feature tag: This
media feature tag, when included in the SIP Contact header media feature tag, when included in the SIP Contact header
field of a SIP REGISTER request, indicates that the SIP UA field 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
a basic SIP feature. If an attacker manages to remove the media a basic SIP feature. If an attacker manages to remove the media
skipping to change at page 29, line 11 skipping to change at page 30, line 11
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004, <https://www.rfc- DOI 10.17487/RFC3840, August 2004, <https://www.rfc-
editor.org/info/rfc3840>. editor.org/info/rfc3840>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
DOI 10.17487/RFC3891, September 2004, <https://www.rfc-
editor.org/info/rfc3891>.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority [RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter (IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)", Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004,
<https://www.rfc-editor.org/info/rfc3969>. <https://www.rfc-editor.org/info/rfc3969>.
[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
Indicate Support of Features and Capabilities in the Indicate Support of Features and Capabilities in the
Session Initiation Protocol (SIP)", RFC 6809, Session Initiation Protocol (SIP)", RFC 6809,
DOI 10.17487/RFC6809, November 2012, <https://www.rfc- DOI 10.17487/RFC6809, November 2012, <https://www.rfc-
skipping to change at page 29, line 49 skipping to change at page 31, line 5
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, <https://www.rfc- DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
editor.org/info/rfc3264>. editor.org/info/rfc3264>.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, Package for Registrations", RFC 3680,
DOI 10.17487/RFC3680, March 2004, <https://www.rfc- DOI 10.17487/RFC3680, March 2004, <https://www.rfc-
editor.org/info/rfc3680>. editor.org/info/rfc3680>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
DOI 10.17487/RFC3891, September 2004, <https://www.rfc-
editor.org/info/rfc3891>.
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4320, DOI 10.17487/RFC4320, January Transaction", RFC 4320, DOI 10.17487/RFC4320, January
2006, <https://www.rfc-editor.org/info/rfc4320>. 2006, <https://www.rfc-editor.org/info/rfc4320>.
[RFC4321] Sparks, R., "Problems Identified Associated with the [RFC4321] Sparks, R., "Problems Identified Associated with the
Session Initiation Protocol's (SIP) Non-INVITE Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4321, DOI 10.17487/RFC4321, January Transaction", RFC 4321, DOI 10.17487/RFC4321, January
2006, <https://www.rfc-editor.org/info/rfc4321>. 2006, <https://www.rfc-editor.org/info/rfc4321>.
 End of changes. 82 change blocks. 
154 lines changed or deleted 218 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/