draft-ietf-sipcore-sip-push-13.txt   draft-ietf-sipcore-sip-push-14.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: February 18, 2019 Metaswitch Networks Expires: March 3, 2019 Metaswitch Networks
August 17, 2018 August 30, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-13 draft-ietf-sipcore-sip-push-14
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 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
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 February 18, 2019. This Internet-Draft will expire on March 3, 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 21 skipping to change at page 2, line 21
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 . . . . . . 9 4.2. Query Network Push Notification Capabilities . . . . . . 9
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9
5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 9 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Trigger Periodic Binding Refresh . . . . . . . . . . . . 9 5.2. Trigger Periodic Binding Refresh . . . . . . . . . . . . 10
5.3. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. 555 (Push Notification Service Not Supported) Response 6.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. 556 (Push Notification Failed) Response Code . . . . . . 15 6.2. 556 (Push Notification Failed) Response Code . . . . . . 15
6.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 15 6.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 16
6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 16 6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 16
6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 16 6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 17
6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 16 6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 17
6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 17 6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 17
7. PNS Registration Requirements . . . . . . . . . . . . . . . . 17 7. PNS Registration Requirements . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . 17 Push Notification service . . . . . . . . . . . . . . . . . . 18
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 . . 18 Firebase Cloud Messaging (FCM) push notification service . . 19
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) . . . . . . . . . . 18 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 20 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 20
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 20 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 21
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 20 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 21
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 20 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 21
12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 20 12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 21
12.2.1. 555 (Push Notification Service Not Supported) . . . 20 12.2.1. 555 (Push Notification Service Not Supported) . . . 21
12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 21 12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 22
12.3. SIP Global Feature-Capability Indicator . . . . . . . . 21 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 22
12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 21 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 22
12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 22 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 22
12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 22 12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 23
12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 23 12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 23
12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 23 12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 24
12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 24 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 25 14.1. Normative References . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 26 14.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 wake such applications, nor will incoming network traffic
awake the application. Instead, one way to awake the application is wake the application. Instead, one way to wake the application is by
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 awake 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 awake 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 awake 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 awake by other means than receiving NOTE: Even if a UA is able to be awaken 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 binding refresh 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 binding refresh to suspend the application between the sending of binding refresh
requests (as it will save battery life) and use push notifications to requests (as it will save battery life) and use push notifications to
awake the UA when an incoming SIP request UA arrives. 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,
skipping to change at page 4, line 46 skipping to change at page 4, line 46
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 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 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 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 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 UA. The proxy can also be co-located with the proxy responsible for
the UA's domain. the UA's domain. This will also ensure that the Request-URI of SIP
requests (for a new dialog or a stand-alone) can be matched against
contacts in REGISTER requests.
+--------+ +--------------+ +-----------------+ +--------+ +--------------+ +-----------------+
| SIP UA | | Push Service | | SIP Proxy | | SIP UA | | Push Service | | SIP Proxy |
+--------+ +--------------+ +-----------------+ +--------+ +--------------+ +-----------------+
| | | | | |
| Subscribe | | | Subscribe | |
|--------------------->| | |--------------------->| |
| | | | | |
| Push Resource ID | | | Push Resource ID | |
|<---------------------| | |<---------------------| |
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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
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.
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
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
awakes 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 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 binding refresh 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 binding refresh is able to use a non-push mechanism for sending re-registration
REGISTER requests). REGISTER requests), or when there are circumstances (e.g., if the UA
is assigned new contact parameters due to a network configuration
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: In some cases the UA might be able to use a non-push mechanism
to awake and send binding refresh REGISTER requests. Such REGISTER to wake 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 wake 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 binding refresh 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 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
skipping to change at page 10, line 12 skipping to change at page 10, line 25
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 in order for the associated binding refresh REGISTER request to reach
the 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 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
skipping to change at page 11, line 35 skipping to change at page 11, line 48
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 downstream proxy supports the type of PNS) or send a SIP knows that a downstream proxy supports the type of PNS) or send a SIP
555 (Push Notification Service Not Supported) response to the 555 (Push Notification Service Not Supported) response to the
REGISTER request. If the proxy sends a SIP 555 (Push Notification REGISTER request. If the proxy sends a SIP 555 (Push Notification
Service Not Supported) response, the proxy SHOULD insert a Feature- Service Not Supported) response Section 6.1, the proxy SHOULD insert
Caps header field with a 'sip.pns' feature-capability indicator in a Feature-Caps header field with a 'sip.pns' feature-capability
the response, identifying the type of each PNS that the proxy indicator in the response, identifying the type of each PNS that the
supports. The decision whether to forward the request, or to send a proxy supports. The decision whether to forward the request, or to
response, is done based on local policy. send a response, is done based on local policy.
If the proxy supports the type of PNS identified by the pn-provider If the proxy 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 towards the registrar. This will inform downstream proxies request towards the registrar. This will inform downstream proxies
that the proxy supports, and will request (if the Contact header that the proxy supports, and will request (if the Contact header
field URI of the REGISTER request contains a pn-prid SIP URI field URI of the REGISTER request contains a pn-prid SIP URI
parameter), push notifications towards the UA. parameter), push notifications towards the UA.
skipping to change at page 13, line 4 skipping to change at page 13, line 15
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 one of the contacts in the the REGISTER response towards the UA, if the contact of the SIP
REGISTER response matches the Request-URI of the SIP request to be REGISTER request associated with the REGISTER response matches the
forwarded, and if the contact binding has not expired, the proxy can Request-URI of the SIP request to be forwarded, and the contact was
also forward the SIP request towards the UA, using normal SIP also present (and has not expired) in the REGISTER response, the
procedures. If the contact of the most recent REGISTER 2xx response proxy can forward the SIP request towards the UA, using normal SIP
and Request-URI do not match, the proxy MUST reject the SIP request procedures. If the contact of the REGISTER request does not match
with a 404 (Not Found) response. This can happen if the UA sends a the Request-URI of the SIP request to be forwarded, or if the contact
binding refresh REGISTER request with a new contact at the same time was not present in the REGISTER response, the proxy MUST reject the
the registrar forwards a SIP request towards a UA using 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
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.
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
rules in [RFC8292], with the following addition: the pn-prid SIP URI
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,
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.
skipping to change at page 13, line 41 skipping to change at page 14, line 14
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 556 (Push Notification Failed) response. with a 480 (Temporarily Unavailable) or a 556 (Push Notification
Failed) response.
NOTE; Before sending a 556 (Push Notification Failed) response, the
proxy operator needs to determine whether it could have privacy
implications.
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 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
skipping to change at page 14, line 31 skipping to change at page 15, line 8
transaction is not kept short, this mechanism should not be used. transaction is not kept short, this mechanism should not be used.
For networks encountering such conditions, an alternative (left for For networks encountering such conditions, an alternative (left for
possible future work) would be for the proxy to immediately return an possible future work) would be for the proxy to immediately return an
new error code meaning "wait at least the number of seconds specified new error code meaning "wait at least the number of seconds specified
in this response, and retry your request" before initiating the push in this response, and retry your request" before initiating the push
notification. notification.
NOTE: While this work on this document was ongoing, implementation NOTE: While this work on this document was ongoing, implementation
test results showed that the time it takes for a proxy to receive the test results showed that the time it takes for a proxy to receive the
REGISTER request, from when the proxy has requested a push REGISTER request, from when the proxy has requested a push
notification, is typically around 2 seconds. notification, is typically around 2 seconds. However, the time might
vary depending on the characteristics and load of the SIP network and
the PNS.
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 wake, 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
of this document. Similarly, if the Request-URI of the SIP request of this document. Similarly, if the Request-URI of the SIP request
only contains any pn-provider SIP URI parameter, but no other pn- SIP only contains any pn-provider SIP URI parameter, but no other pn- SIP
URI parameters, e.g., because the SIP UA has not included them in a URI parameters, e.g., because the SIP UA has not included them in a
REGISTER request (Section 4.2), the proxy is not able to request a REGISTER request (Section 4.2), the proxy is not able to request a
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 wake, 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 556 (Push Notification proxy MUST reject the SIP request with a 480 (Temporarily
Failed) response. Unavailable) or a 556 (Push Notification Failed) response.
6. Grammar 6. Grammar
6.1. 555 (Push Notification Service Not Supported) Response Code 6.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.
skipping to change at page 19, line 35 skipping to change at page 20, line 27
notification subscription, the mechanism defined in this document notification subscription, the mechanism defined in this document
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.
If the push notification related information carried in SIP could be Operators MUST ensure that the SIP signalling is properly secured,
used by a malicious middleman to trigger push notifications towards a e.g., using encryption, from malicious middlemen, unless they are
device, operators MUST ensure that the SIP signalling is properly sure that the signalling cannot be accessed and used maliciously
secured from malicious middlemen, e.g., using encryption. (e.g., to trigger push notifications towards a device) by a
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 35 skipping to change at page 24, line 41
12.5. PNS Sub-registry Establishment 12.5. PNS Sub-registry Establishment
This section creates a new sub-registry, "PNS", under the sip- This section creates a new sub-registry, "PNS", under the sip-
parameters registry: http://www.iana.org/assignments/sip-parameters. parameters registry: http://www.iana.org/assignments/sip-parameters.
The purpose of the sub-registry is to register SIP URI pn-provider The purpose of the sub-registry is to register SIP URI pn-provider
values. values.
When a SIP URI pn-provider value is registered in the sub-registry, When a SIP URI pn-provider value is registered in the sub-registry,
it needs to meet the "Expert Review" policies defined in [RFC8126]. it needs to meet the "Specification Required" policies defined in
[RFC8126].
This sub-registry is defined as a table that contains the following This sub-registry is defined as a table that contains the following
three columns: three columns:
Value: The token under registration Value: The token under registration
Description: The name of the Push Notification Service (PNS) Description: The name of the Push Notification Service (PNS)
Document: A reference to the document defining the registration Document: A reference to the document defining the registration
This specification registers the following values: This specification registers the following values:
Value Description Document Value Description Document
------- -------------------------------------- ---------- ------- -------------------------------------- ----------
apns Apple Push Notification service [RFC XXXX] apns Apple Push Notification service [RFC XXXX]
fcm Firebase Cloud Messaging [RFC XXXX] fcm Firebase Cloud Messaging [RFC XXXX]
webpush Generic Event Delivery Using HTTP Push [RFC XXXX] webpush Generic Event Delivery Using HTTP Push [RFC XXXX]
13. Acknowledgements 13. Acknowledgements
 End of changes. 41 change blocks. 
66 lines changed or deleted 96 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/