draft-ietf-sipcore-sip-push-12.txt   draft-ietf-sipcore-sip-push-13.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 15, 2019 Metaswitch Networks Expires: February 18, 2019 Metaswitch Networks
August 14, 2018 August 17, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-12 draft-ietf-sipcore-sip-push-13
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 (UAs), using push notifications, for the UA to be able to send
binding refresh REGISTER requests and to receive receive incoming SIP binding refresh REGISTER requests and to receive receive incoming SIP
requests. The document defines new SIP URI parameters and new requests. The document defines new SIP URI parameters and new
feature-capability indicators that can be used in SIP messages to feature-capability indicators that can be used in SIP messages to
indicate support of the mechanism defined in this document, to indicate support of the mechanism defined in this document, to
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 15, 2019. This Internet-Draft will expire on February 18, 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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. 555 (Push Notification Service Not Supported) Response 6.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . 15
6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 15 6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 16
6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 16 6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 16
6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 16 6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 16
6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 16 6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 17
7. PNS Registration Requirements . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 17 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 . . 18 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) . . . . . . . . . . 18 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 19 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 20
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 20 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 20
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 20 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 20
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 20 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 20
12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 20 12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 20
12.2.1. 555 (Push Notification Service Not Supported) . . . 20 12.2.1. 555 (Push Notification Service Not Supported) . . . 20
12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 21 12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 21
12.3. SIP Global Feature-Capability Indicator . . . . . . . . 21 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 21
12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 21 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 21
12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 21 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 22
12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 22 12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 22
12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 22 12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 23
12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 23 12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 23
12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 23 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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 awake such applications, nor will incoming network traffic
awake the application. Instead, one way to awake the application is awake the application. Instead, one way to awake the application is
by using a Push Notification Service (PNS). Typically each operating by 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
skipping to change at page 4, line 26 skipping to change at page 4, line 26
using the PNS of the UA. Once the UA receives the push notification, using the PNS of the UA. Once the UA receives the push notification,
it will be able to send a binding refresh REGISTER request and it will be able to send a binding refresh REGISTER request and
receive the incoming SIP request. The proxy will receive the receive the incoming SIP request. The proxy will receive the
REGISTER request. If the push notification request was triggered by REGISTER request. If the push notification request was triggered by
a SIP request addressed towards the UA (see above), once the REGISTER a SIP request addressed towards the UA (see above), once the REGISTER
request has been accepted by the SIP registrar [RFC3261], and the request has been accepted by the SIP registrar [RFC3261], and the
associated SIP 2xx response has been forwarded by the proxy towards associated SIP 2xx response has been forwarded by the proxy towards
the UA, the proxy can forward the SIP request towards the UA using the UA, the proxy can forward the SIP request towards the UA using
normal SIP routing procedures. In some cases the proxy can forward normal SIP routing procedures. In some cases the proxy can forward
the SIP request without waiting for the SIP 2xx response to the the SIP request without waiting for the SIP 2xx response to the
REGISTER request. REGISTER request. Note that this mechanism necessarily adds delay to
responding to non-INVITE requests requiring push notification. The
consequences of that delay are discussed in Section 5.3.2.
Different PNSs exist today. Some are based on the standardized Different PNSs exist today. Some are based on the standardized
mechanism defined in [RFC8030], while others are proprietary (e.g., mechanism defined in [RFC8030], while others are proprietary (e.g.,
the Apple Push Notification service). Figure 1 shows the generic the Apple Push Notification service). Figure 1 shows the generic
push notification architecture supported by the mechanism in this push notification architecture supported by the mechanism in this
document. document.
Each PNS uses PNS-specific terminology and function names. The Each PNS uses PNS-specific terminology and function names. The
terminology in this document is meant to be PNS-independent. If the terminology in this document is meant to be PNS-independent. If the
PNS is based on [RFC8030], the SIP proxy takes the role of the PNS is based on [RFC8030], the SIP proxy takes the role of the
skipping to change at page 13, line 36 skipping to change at page 13, line 36
binding refresh REGISTER request triggered by the push notification binding refresh REGISTER request triggered by the push notification
request, will convey pn- SIP URI parameters associated with the SIP request, will convey pn- SIP URI parameters associated with the SIP
registration, those can be used to match the SIP request with the registration, those can be used to match the SIP request with the
binding refresh REGISTER request (even if the most recent contact and binding refresh REGISTER request (even if 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: 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, and the proxy In case of non-2xx response to the REGISTER request, the proxy MUST
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.
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 480 (Temporarily Unavailable)
time value is set based on local policy. response. The time value is set based on local policy.
As describe above, there are cases where the proxy will reject the As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must
SIP request with an error response. While waiting for the push complete immediately or risk losing race that results in stress on
notification request to succeed, and the associated REGISTER request intermediaries and state misalignment at the endpoints. The
to arrive from the SIP UA, the proxy needs to take into consideration mechanism defined in this document inherently delays the final
that the transaction associated with the SIP request will eventually response to any non-INVITE request that requires a push notification.
time out at the sender of the request (UAC), and the sender will In particular, while waiting for the push notification request to
consider the transaction a failure. If the proxy forwards the SIP succeed, and the associated REGISTER request to arrive from the SIP
request towards the SIP UA, the SIP UA accepts the request and the UA, the proxy needs to take into consideration that the transaction
transaction times out at the sender before it receives the successful associated with the SIP request will eventually time out at the
response, this will cause state misalignment between the endpoints sender of the request (UAC), and the sender will consider the
(the sender will consider the transaction a failure, while the transaction a failure. If the proxy forwards the SIP request towards
receiver will consider the transaction a success). The SIP proxy the SIP UA, the SIP UA accepts the request and the transaction times
needs to take this into account when deciding for how long to wait out at the sender before it receives the successful response, this
before it considers the transaction associated with the SIP request a will cause state misalignment between the endpoints (the sender will
failure, to make sure that the error response reaches the sender consider the transaction a failure, while the receiver will consider
before the transaction times out. 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. If the accumulated delay of this mechanism combined with
any other mechanisms in the path of processing the non-INVITE
transaction is not kept short, this mechanism should not be used.
For networks encountering such conditions, an alternative (left for
possible future work) would be for the proxy to immediately return an
new error code meaning "wait at least the number of seconds specified
in this response, and retry your request" before initiating the push
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.
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
skipping to change at page 25, line 39 skipping to change at page 26, line 27
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4320, DOI 10.17487/RFC4320, January
2006, <https://www.rfc-editor.org/info/rfc4320>.
[RFC4321] Sparks, R., "Problems Identified Associated with the
Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4321, DOI 10.17487/RFC4321, January
2006, <https://www.rfc-editor.org/info/rfc4321>.
[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,
DOI 10.17487/RFC5626, October 2009, <https://www.rfc- DOI 10.17487/RFC5626, October 2009, <https://www.rfc-
editor.org/info/rfc5626>. editor.org/info/rfc5626>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
 End of changes. 16 change blocks. 
39 lines changed or deleted 61 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/