draft-ietf-sipcore-sip-push-11.txt   draft-ietf-sipcore-sip-push-12.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: October 13, 2018 Metaswitch Networks Expires: February 15, 2019 Metaswitch Networks
April 11, 2018 August 14, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-11 draft-ietf-sipcore-sip-push-12
Abstract Abstract
This document describes how a Push Notification Service (PNS) can be This document describes how a Push Notification Service (PNS) can be
used to awake suspended Session Initiation Protocol (SIP) User Agents used to awake suspended Session Initiation Protocol (SIP) User Agents
(UAs), using push notifications, for the UA to be able to send re- (UAs), using push notifications, for the UA to be able to send
registration 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 October 13, 2018. This Internet-Draft will expire on February 15, 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 . . . . . . . . . . . . . . . . 6 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6
4.1. Request Push Notifications from Network . . . . . . . . . 6 4.1. Request Push Notifications from Network . . . . . . . . . 6
4.2. Query Network Push Notification Capabilities . . . . . . 8 4.2. Query Network Push Notification Capabilities . . . . . . 9
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9
5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 9 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 9 5.2. Trigger Periodic Binding Refresh . . . . . . . . . . . . 9
5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 10
5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 10
5.3.2. Initial Request for Dialog or Stand-Alone Request . . 12 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 12
6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. 555 (Push Notification Service Not Supported) Response 6.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. 556 (Push Notification Failed) Response Code . . . . . . 14 6.2. 556 (Push Notification Failed) Response Code . . . . . . 15
6.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 14 6.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 15
6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 14 6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 15
6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 15 6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 16
6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 15 6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 16
6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 16 6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 16
7. PNS Registration Requirements . . . . . . . . . . . . . . . . 16 7. PNS Registration Requirements . . . . . . . . . . . . . . . . 17
8. pn-provider, pn-param and pn-prid URI Parameters for Apple 8. pn-provider, pn-param and pn-prid URI Parameters for Apple
Push Notification service . . . . . . . . . . . . . . . . . . 16 Push Notification service . . . . . . . . . . . . . . . . . . 17
9. pn-provider, pn-param and pn-prid URI Parameters for Google 9. pn-provider, pn-param and pn-prid URI Parameters for Google
Firebase Cloud Messaging (FCM) push notification service . . 17 Firebase Cloud Messaging (FCM) push notification service . . 18
10. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 10. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
(Generic Event Delivery Using HTTP Push) . . . . . . . . . . 17 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 19 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 19
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 19 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 20
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 19 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 20
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 19 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 20
12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 19 12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 20
12.2.1. 555 (Push Notification Service Not Supported) . . . 19 12.2.1. 555 (Push Notification Service Not Supported) . . . 20
12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 20 12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 21
12.3. SIP Global Feature-Capability Indicator . . . . . . . . 20 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 21
12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 20 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 21
12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 21 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 21
12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 21 12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 22
12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 22 12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 22
12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 22 12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 23
12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 23 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 23
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
In order to save resources (e.g., battery life) some devices In order to save resources (e.g., battery life) some devices
(especially mobile devices) and operating systems will suspend (especially mobile devices) and operating systems will suspend
applications when not used. In some cases, internal timers cannot be applications when not used. In some cases, internal timers cannot be
used to awake such applications, nor will incoming network traffic used to awake such applications, nor will incoming network traffic
awake the application. Instead, the only way to awake the awake the application. Instead, one way to awake the application is
application is by using a Push Notification Service (PNS). Typically by using a Push Notification Service (PNS). Typically each operating
each operating system uses a dedicated PNS. For example, Apple iOS system uses a dedicated PNS. For example, Apple iOS devices use the
devices use the Apple Push Notification service (APNs) while Android Apple Push Notification service (APNs) while Android devices use the
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 re- User Agents (UAs) [RFC3261] can not be awoken, in order to send
registration SIP REGISTER requests and to receive incoming SIP binding refresh SIP REGISTER requests and to receive incoming SIP
requests, without using a PNS to awake the UA in order to perform requests, without using a PNS to awake the UA in order to perform
those functions. those functions.
Also, without being able to use internal timers in order to awake Also, without being able to use internal timers in order to awake
applications, a UA will not be able to maintain connections e.g., applications, a UA will not be able to maintain connections e.g.,
using the SIP Outbound Mechanism [RFC5626], as it requires the UA to using the SIP Outbound Mechanism [RFC5626], as it requires the UA to
send periodic keep-alive messages. send periodic keep-alive messages.
This document describes how PNSs can be used to awake suspended UAs, This document describes how PNSs can be used to awake suspended UAs,
using push notifications, to be able to send re-registration 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 awake by other means than receiving NOTE: Even if a UA is able to awake by other means than receiving
push notifications (e.g., by using internal timers) in order to send push notifications (e.g., by using internal timers) in order to send
periodic re-registration REGISTER requests, it might still be useful periodic binding refresh REGISTER requests, it might still be useful
to suspend the application between the sending of re-registration to suspend the application between the sending of binding refresh
requests (as it will save battery life etc) and use push requests (as it will save battery life) and use push notifications to
notifications to awake the UA when an incoming SIP request UA awake the UA when an incoming SIP request UA arrives.
arrives.
When a UA registers to a PNS, it will receive a unique Push Resource When a UA registers to a PNS, it will receive a unique Push Resource
ID (PRID) associated with the push notification registration. The UA ID (PRID) associated with the push notification registration. The UA
will use a REGISTER request to provide the PRID to the SIP proxy that will use a REGISTER request to provide the PRID to the SIP proxy that
will request push notifications towards the UA. will request push notifications towards the UA.
When the proxy receives (or, if the proxy is the SIP registrar When the proxy receives a SIP request for a new dialog, or a stand-
[RFC3261], initiates) a SIP request for a new dialog, or a stand-
alone SIP request, addressed towards a UA, or when the proxy alone SIP request, addressed towards a UA, or when the proxy
determines that the UA needs to send a re-registration 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 re-registration REGISTER request and it will be able to send a binding refresh REGISTER request and
receive the incoming SIP request. The proxy will receive and forward receive the incoming SIP request. The proxy will receive the
(or, if the proxy is the registrar, process) the REGISTER request. REGISTER request. If the push notification request was triggered by
If the push notification request was triggered by a SIP request a SIP request addressed towards the UA (see above), once the REGISTER
addressed towards the UA (see above), once the REGISTER request has request has been accepted by the SIP registrar [RFC3261], and the
been accepted by the registrar, and the associated SIP 2xx response associated SIP 2xx response has been forwarded by the proxy towards
has been forwarded by the proxy towards the UA, the proxy can forward the UA, the proxy can forward the SIP request towards the UA using
the SIP request towards the UA using normal SIP routing procedures. normal SIP routing procedures. In some cases the proxy can forward
the SIP request without waiting for the SIP 2xx response to the
REGISTER request.
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
application server. application server.
The proxy MUST be in the signalling path of REGISTER requests sent by
the UA towards the registrar, and of SIP requests (for a new dialog
or a stand-alone) forwarded by the proxy responsible for the UA's
domain (sometimes referred to as home proxy, S-CSCF, etc) towards the
UA. The proxy can also be co-located with the proxy responsible for
the UA's domain.
+--------+ +--------------+ +-----------------+ +--------+ +--------------+ +-----------------+
| SIP UA | | Push Service | | SIP Proxy | | SIP UA | | Push Service | | SIP Proxy |
+--------+ +--------------+ +-----------------+ +--------+ +--------------+ +-----------------+
| | | | | |
| Subscribe | | | Subscribe | |
|--------------------->| | |--------------------->| |
| | | | | |
| Push Resource ID | | | Push Resource ID | |
|<---------------------| | |<---------------------| |
| | | | | |
| SIP REGISTER (Push Resource ID) | | SIP REGISTER (Push Resource ID) |
|===============================================>| |===============================================>|
| | | SIP REGISTER
| | |============>
| | |
| | | SIP 200 OK
| | |<============
| SIP 200 OK | | | SIP 200 OK | |
|<===============================================| |<===============================================|
| | | | | |
| | | | | |
| | | | | |
| | | SIP INVITE | | | SIP INVITE
| | Push Message |<============ | | Push Message |<============
| | (Push Resource ID) | | | (Push Resource ID) |
| Push Message |<------------------------| | Push Message |<------------------------|
| (Push Resource ID) | | | (Push Resource ID) | |
|<---------------------| | |<---------------------| |
| | | | | |
| SIP REGISTER (Push Resource ID) | | SIP REGISTER (Push Resource ID) |
|===============================================>| |===============================================>|
| | | SIP REGISTER
| | |============>
| | |
| | | SIP 200 OK
| | |<============
| SIP 200 OK | | | SIP 200 OK | |
|<===============================================| |<===============================================|
| | | | | |
| SIP INVITE | | | SIP INVITE | |
|<===============================================| |<===============================================|
| | | | | |
------- Push Notification API ------- Push Notification API
======= SIP ======= SIP
skipping to change at page 6, line 8 skipping to change at page 6, line 24
pn-param=acme-param; pn-param=acme-param;
pn-prid=ZTY4ZDJlMzODE1NmUgKi0K> pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>
Expires: 7200 Expires: 7200
Content-Length: 0 Content-Length: 0
Figure 1: SIP Push Notification Architecture Figure 1: SIP Push Notification Architecture
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
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 may vary depending on the PNS.
The details regarding discovery of the PNS, and the procedures The details regarding discovery of the PNS, and the procedures
skipping to change at page 6, line 40 skipping to change at page 7, line 10
(using the protocol and procedures associated with the PNS), if the (using the protocol and procedures associated with the PNS), if the
UA wants to receive push notifications (requested by the proxy), the UA wants to receive push notifications (requested by the proxy), the
UA MUST include the following SIP URI parameters in the SIP Contact UA MUST include the following SIP URI parameters in the SIP Contact
header field URI of the REGISTER request: pn-provider, pn-prid and header field URI of the REGISTER request: pn-provider, pn-prid and
pn-param (if required for the specific PNS). The pn-provider URI pn-param (if required for the specific PNS). The pn-provider URI
parameter identifies the type of PNS, the pn-prid URI parameter parameter identifies the type of PNS, the pn-prid URI parameter
contains the PRID value and the pn-param URI parameter contains contains the PRID value and the pn-param URI parameter contains
additional PNS-specific information. additional PNS-specific information.
When the UA receives a 2xx response to the REGISTER request, if the When the UA receives a 2xx response to the REGISTER request, if the
response contains a Feature-Caps header field with a 'sip.pns' response contains a Feature-Caps header field [RFC6809] with a
feature-capability indicator with a parameter value identifying the 'sip.pns' feature-capability indicator with a parameter value
same type of PNS that was identified by the pn-provider URI parameter identifying the same type of PNS that was identified by the pn-
in the REGISTER request, the UA can assume that a SIP proxy will provider URI parameter in the REGISTER request, the UA can assume
request push notifications towards the UA. In other cases, the UA that a SIP proxy will request push notifications towards the UA. In
MUST NOT assume that push notifications will be requested, and the other cases, the UA MUST NOT assume that push notifications will be
actions taken by the UA might be dependent on implementation or requested, and the actions taken by the UA might be dependent on
deployment architecture, and are outside the scope of this document. implementation or deployment architecture, and are outside the scope
of this document.
In addition, if the response contains a Feature-Caps header field In addition, if the response contains a Feature-Caps header field
with a 'sip.vapid' feature-capability indicator, the proxy supports with a 'sip.vapid' feature-capability indicator, the proxy supports
use of the Voluntary Application Server Identification (VAPID) use of the Voluntary Application Server Identification (VAPID)
mechanism [RFC8292] to restrict push notifications to the proxy. mechanism [RFC8292] to restrict push notifications to the proxy.
When the UA receives a push notification, it MUST send a re- When the UA receives a push notification, it MUST send a binding
registration REGISTER request, using normal SIP procedures. If there refresh REGISTER request, using normal SIP procedures. If there are
are Network Address Translators (NATs) between the UA and the proxy, Network Address Translators (NATs) between the UA and the proxy, the
the REGISTER request will create NAT bindings that will allow REGISTER request will create NAT bindings that will allow incoming
incoming SIP requests to reach the UA. Once the UA has received a SIP requests to reach the UA. Once the UA has received a 2xx
2xx response to the REGISTER request, the UA might receive a SIP response to the REGISTER request, the UA might receive a SIP request
request for a new dialog (e.g., a SIP INVITE), or a stand-alone SIP for a new dialog (e.g., a SIP INVITE), or a stand-alone SIP request
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.
If the UA is able to send re-registration 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
awakes the UA), the UA MUST insert a 'sip.pnsreg' media feature tag awakes 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 the 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 MUST
send REGISTER requests prior to the registration expires. The send REGISTER requests prior to the registration expires. The
indicator value indicates a minimum time (given in seconds), prior to indicator value indicates a minimum time (given in seconds), prior to
the registration expires when the UA MUST send the REGISTER request. the registration expires when the UA MUST send the REGISTER request.
Even if the UA is able to to send REGISTER requests using a non-push Even if 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 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 re-registration is able to use a non-push mechanism for sending binding refresh
REGISTER requests). REGISTER requests).
NOTE: In some cases the UA might be able to use a non-push mechanism NOTE: In some cases the UA might be able to use a non-push mechanism
to awake and send re-registration REGISTER requests. Such REGISTER to awake and send binding refresh REGISTER requests. Such REGISTER
request will update the registration expiration timer, and the proxy request will update the registration expiration timer, and the proxy
does not need to request a push notification towards the UA in order does not need to request a push notification towards the UA in order
to awake the UA. The proxy will still request a push notification to awake the UA. The proxy will still request a push notification
towards the UA when the proxy receives a SIP request addressed towards the UA when the proxy receives a SIP request addressed
towards the UA (Section 5.3.2). This allows the UA to e.g., use towards the UA (Section 5.3.2). This allows the UA to e.g., use
timers for sending re-registration REGISTER requests, but to be timers for sending binding refresh REGISTER requests, but to be
suspended (in order to save battery resources etc) between sending suspended (in order to save battery resources etc) between sending
the REGISTER requests and use push notification to awaken the UA to the REGISTER requests and use push notification to awaken 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 re-registration 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 re-registration 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
re-registration 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 re-registration 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 re-registration 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 8, line 51 skipping to change at page 9, line 24
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 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 re-registration 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 Identifier 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 Re-registration 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 re-registration SIP REGISTER requests, the SIP trigger the UA to send binding refresh SIP REGISTER requests, the SIP
proxy MUST have information about when a registration will expire. proxy needs to have information about when a registration will
The proxy either needs to be the SIP registrar, or the proxy needs to expire. The proxy needs to be able to retrieve the information from
retrieve the information from the registrar using some mechanism. the registrar using some mechanism. Such mechanisms are outside the
Such mechanisms are outside the scope of this document. scope of this document.
When the proxy receives an indication that the UA needs to send a re- When the proxy receives an indication that the UA needs to send a
registration REGISTER request, the proxy requests a push notification binding refresh REGISTER request, the proxy requests a push
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 re-registration REGISTER request to reach in order for the associated binding refresh REGISTER request to reach
the SIP registrar before the registration expires. It is RECOMMENDED the registrar before the registration expires. It is RECOMMENDED
that the proxy requests the push notification at least 120 seconds that the proxy requests the push notification at least 120 seconds
before the registration expires. before the registration expires.
If the UA has indicated, using the 'sip.pnsreg' media feature tag, If the UA has indicated, using the 'sip.pnsreg' media feature tag,
that it is able to awake using a non-push mechanism for sending re- that it is able to awake using a non-push mechanism for sending
registration 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 Request 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 re-registration 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
skipping to change at page 11, line 22 skipping to change at page 11, line 45
Service Not Supported) response, the proxy SHOULD insert a Feature- Service Not Supported) response, the proxy SHOULD insert a Feature-
Caps header field with a 'sip.pns' feature-capability indicator in Caps header field with a 'sip.pns' feature-capability indicator in
the response, identifying the type of each PNS that the proxy the response, identifying the type of each PNS that the proxy
supports. The decision whether to forward the request, or to send a supports. The decision whether to forward the request, or to send a
response, is done based on local policy. response, is 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
SIP URI parameter, the proxy MUST insert a Feature-Caps header field SIP URI parameter, the proxy MUST insert a Feature-Caps header field
with a 'sip.pns' feature-capability indicator, identifying the type with a 'sip.pns' feature-capability indicator, identifying the type
of PNS, in the REGISTER request before forwarding the REGISTER of PNS, in the REGISTER request before forwarding the REGISTER
request (unless the proxy is the registrar, in which case the proxy request towards the registrar. This will inform downstream proxies
will terminate the REGISTER request). This will inform downstream that the proxy supports, and will request (if the Contact header
proxies that the proxy supports, and will request (if the Contact field URI of the REGISTER request contains a pn-prid SIP URI
header field URI of the REGISTER request contains a pn-prid SIP URI
parameter), push notifications towards the UA. parameter), push notifications towards the UA.
If the proxy inserted a Feature-Caps header field with a 'sip.pns' If the proxy inserted a Feature-Caps header field with a 'sip.pns'
feature-capability indicator in the REGISTER request (see above), if feature-capability indicator in the REGISTER request (see above), if
the proxy receives (or, in case the proxy is the SIP registrar, the proxy receives a 2xx response to the REGISTER request, the proxy
creates) a 2xx response to the REGISTER request, the proxy MUST MUST insert a Feature-Caps header field with a 'sip.pns' feature-
insert a Feature-Caps header field with a 'sip.pns' feature-
capability indicator in the response, identifying the 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 only indicate support 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.
skipping to change at page 12, line 18 skipping to change at page 12, line 39
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
SIP UA. SIP UA.
When the proxy receives (or, in case the proxy is the registrar, When the proxy receives a SIP request for a new dialog (e.g., a SIP
creates) a SIP request for a new dialog (e.g., a SIP INVITE request) INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE
or a stand-alone SIP request (e.g., a SIP MESSAGE request) addressed request) addressed towards a SIP UA, if the Request-URI of the
towards a SIP UA, if the Request-URI of the request contains a pn- request contains a pn-provider, a pn-prid and a pn-param (if required
provider, a pn-prid and a pn-param (if required for the specific PNS for the specific PNS provider) SIP URI parameter, the proxy requests
provider) SIP URI parameter, the proxy requests a push notification a push notification towards the UA, using the PRID included in the
towards the UA, using the PRID included in the pn-prid SIP URI pn-prid SIP URI parameter and the PNS identified by the pn-provider
parameter and the PNS identified by the pn-provider SIP URI SIP URI parameter.
parameter.
The push notification will trigger the UA to send a re-registration 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 in the REGISTER the REGISTER response towards the UA, if one of the contacts in the
response matches the Request-URI of the SIP request to be forwarded, REGISTER response matches the Request-URI of the SIP request to be
the proxy can also forward the SIP request towards the UA, using forwarded, and if the contact binding has not expired, the proxy can
normal SIP procedures. If the contact of the most recent REGISTER also forward the SIP request towards the UA, using normal SIP
2xx response and Request-URI do not match, the proxy MUST reject the procedures. If the contact of the most recent REGISTER 2xx response
SIP request with a 404 (Not Found) response. This can happen if the and Request-URI do not match, the proxy MUST reject the SIP request
UA sends a re-registration REGISTER request with a new contact at the with a 404 (Not Found) response. This can happen if the UA sends a
same time the registrar forwards a SIP request towards a UA using the binding refresh REGISTER request with a new contact at the same time
the registrar forwards a SIP request towards a UA using the
previously registered contact in the Request-URI. previously registered contact in the Request-URI.
As both the SIP request to be forwarded towards the UA, and the re- The reason the proxy needs to wait for the REGISTER response before
registration REGISTER request triggered by the push notification forwarding the SIP request is to make sure that the REGISTER request
has been accepted by the registrar, and that the UA which initiated
the REGISTER request is authorized to receive messages for the
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
2xx response before it forwards the SIP request towards the UA. The
mechanism for authorizing the UA is outside the scope of this
document.
As both the SIP request to be forwarded towards the UA, and the
binding refresh REGISTER request triggered by the push notification
request, will convey pn- SIP URI parameters associated with the SIP request, will convey pn- SIP URI parameters associated with the SIP
registration, those can be used to match the SIP request with the re- registration, those can be used to match the SIP request with the
registration REGISTER request (even if the most recent contact and binding refresh REGISTER request (even if the most recent contact and
the Request-URI of the SIP request do not match). the Request-URI of the SIP request do not match).
NOTE: If the proxy is not the registrar, it needs to store (or be NOTE: The proxy needs to store (or be able to retrieve) the contact
able to retrieve) the contact of the most recent REGISTER 2xx of the most recent REGISTER 2xx response, to be able to compare it
response, to be able to compare it with the Request-URI of the with the Request-URI of the request to be forwarded towards the UA.
request to be forwarded towards the UA.
In case of non-2xx response to the REGISTER request, the proxy MUST In case of non-2xx response to the REGISTER request, and the proxy
has not yet forwarded the SIP request towards the UA, 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 556 (Push Notification Failed) response. with a 556 (Push Notification Failed) response.
NOTE: As described above, the reason the proxy needs to wait for the
REGISTER response before forwarding the SIP request is to make sure
that the REGISTER request has been accepted by the SIP registrar, and
that the registered contact matches the Request-URI of the SIP
request to be forwarded.
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 404 (Not Found) response. The proxy MUST reject the request with a 404 (Not Found) response. The
time value is set based on local policy. time value is set based on local policy.
As describe above, there are cases where the proxy will reject the
SIP request with an error response. While waiting for the push
notification request to succeed, and the associated REGISTER request
to arrive from the SIP UA, the proxy needs to take into consideration
that the transaction associated with the SIP request will eventually
time out at the sender of the request (UAC), and the sender will
consider the transaction a failure. If the proxy forwards the SIP
request towards the SIP UA, the SIP UA accepts the request and the
transaction times out at the sender before it receives the successful
response, this will cause state misalignment between the endpoints
(the sender will consider the transaction a failure, while the
receiver will consider the transaction a success). The SIP proxy
needs to take this into account when deciding for how long to wait
before it considers the transaction associated with the SIP request a
failure, to make sure that the error response reaches the sender
before the transaction times out.
NOTE: While this work on this document was ongoing, implementation
test results showed that the time it takes for a proxy to receive the
REGISTER request, from when the proxy has requested a push
notification, is typically around 2 seconds.
The proxy MUST NOT include the SIP request as payload in the The proxy MUST NOT include the SIP request as payload in the
requested push message. requested push message.
If the proxy has knowledge that the UA is awake, and that the UA is If the proxy has knowledge that the UA is awake, and that the UA is
able to receive the SIP request without first sending a REGISTER able to receive the SIP request without first sending a REGISTER
request, the proxy MAY choose to not request a push notification request, the proxy MAY choose to not request a push notification
towards the UA (and wait for the associated REGISTER request and 2xx towards the UA (and wait for the associated REGISTER request and 2xx
response) before it tries to forward the SIP request towards the UA. response) before it tries to forward the SIP request towards the UA.
The mechanisms for getting such knowledge might be dependent on The mechanisms for getting such knowledge might be dependent on
implementation or deployment architecture, and are outside the scope implementation or deployment architecture, and are outside the scope
skipping to change at page 15, line 16 skipping to change at page 16, line 14
vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT
vapid = tag-value vapid = tag-value
; tag-value as defined in RFC 3840 ; tag-value as defined in RFC 3840
6.5. sip.pnsreg Feature-Capability Indicator 6.5. sip.pnsreg Feature-Capability Indicator
The sip.pnsreg feature-capability indicator, when included in a SIP The sip.pnsreg feature-capability indicator, when included in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, indicates that the entity
associated with the indicator expects to receive re-registration associated with the indicator expects to receive 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 as defined in RFC 3261 ; DIGIT as defined in RFC 3261
6.6. sip.pnsreg Media Feature Tag 6.6. sip.pnsreg Media Feature Tag
The sip.pnsreg media feature tag, when included in the SIP Contact The sip.pnsreg media feature tag, when included in the SIP Contact
header field of a SIP REGISTER request, 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 re-registration 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"
6.7. SIP URI Parameters 6.7. SIP URI Parameters
The section defines new SIP URI parameters, by extending the grammar The section defines new SIP URI parameters, by extending the grammar
for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows:
skipping to change at page 16, line 22 skipping to change at page 17, line 17
pn-param = "pn-param" EQUAL pvalue pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" EQUAL pvalue pn-prid = "pn-prid" EQUAL pvalue
; pvalue as defined in RFC 3261 ; pvalue as defined in RFC 3261
; EQUAL as defined in RFC 3261 ; EQUAL as defined in RFC 3261
; COLON as defined in RFC 3261 ; COLON as defined in RFC 3261
The format and semantics of pn-prid and pn-param are The format and semantics of pn-prid and pn-param are
specific to the pn-provider value. specific to the pn-provider value.
Parameter value chapters that are not part of pvalue needs to be Parameter value characters that are not part of pvalue needs to be
escaped, as defined in RFC 3261. escaped, as defined in RFC 3261.
7. PNS Registration Requirements 7. PNS Registration Requirements
When a new value is registered to the PNS Sub-registry, a reference When a new value is registered to the PNS Sub-registry, a reference
to a specification which describes the PNS associated with the value to a specification which describes the PNS associated with the value
is provided. That specification MUST contain the following is provided. That specification MUST contain the following
information: information:
o The value of the pn-provider SIP URI parameter. o The value of the pn-provider SIP URI parameter.
skipping to change at page 18, line 38 skipping to change at page 19, line 32
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.
If the push notification related information carried in SIP could be If the push notification related information carried in SIP could be
used by a malicious middleman to trigger push notifications towards a used by a malicious middleman to trigger push notifications towards a
device, operators MUST ensure that the SIP signalling is properly device, operators MUST ensure that the SIP signalling is properly
secured from malicious middlemen, e.g., using encryption. secured from malicious middlemen, e.g., using encryption.
[RFC8292] defines a mechanism which allows a proxy to create a [RFC8292] defines a mechanism which allows a proxy to identity itself
identity itself to a PNS, by signing a JWT sent to the PNS using a to a PNS, by signing a JWT sent to the PNS using a key pair. The
key pair. The public key serves as an identifier of the proxy, and public key serves as an identifier of the proxy, and can be used by
can be used by devices to restrict push notifications to the proxy devices to restrict push notifications to the proxy associated with
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.
12. IANA considerations 12. IANA considerations
12.1. SIP URI Parameters 12.1. SIP URI Parameters
This section defines new SIP URI Parameters that extend the "SIP/SIPS This section defines new SIP URI Parameters that extend the "SIP/SIPS
URI Parameters" sub-registry [RFC3969] under the sip-parameters URI Parameters" sub-registry [RFC3969] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters. registry: http://www.iana.org/assignments/sip-parameters.
12.1.1. pn-provider 12.1.1. pn-provider
Parameter Name: pn-provider Parameter Name: pn-provider
skipping to change at page 22, line 10 skipping to change at page 22, line 32
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
re-registration 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)
skipping to change at page 23, line 10 skipping to change at page 23, line 16
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 re-registration 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 25, line 16 skipping to change at page 25, line 28
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-
editor.org/info/rfc6809>. editor.org/info/rfc6809>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030, Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016, <https://www.rfc- DOI 10.17487/RFC8030, December 2016, <https://www.rfc-
editor.org/info/rfc8030>. editor.org/info/rfc8030>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server [RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server
Identification (VAPID) for Web Push", RFC 8292, Identification (VAPID) for Web Push", RFC 8292,
DOI 10.17487/RFC8292, November 2017, <https://www.rfc- DOI 10.17487/RFC8292, November 2017, <https://www.rfc-
editor.org/info/rfc8292>. editor.org/info/rfc8292>.
14.2. Informative References 14.2. Informative References
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session "Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
 End of changes. 67 change blocks. 
153 lines changed or deleted 202 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/