draft-ietf-sipcore-sip-push-16.txt   draft-ietf-sipcore-sip-push-17.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: March 31, 2019 Metaswitch Networks Expires: April 1, 2019 Metaswitch Networks
September 27, 2018 September 28, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-16 draft-ietf-sipcore-sip-push-17
Abstract Abstract
This document describes how a Push Notification Service (PNS) can be This document describes how a Push Notification Service (PNS) can be
used to wake suspended Session Initiation Protocol (SIP) User Agents used to wake suspended Session Initiation Protocol (SIP) User Agents
(UAs), using push notifications, for the UA to be able to send (UAs), using push notifications, for the UA to be able to send
binding refresh REGISTER requests and to receive receive incoming SIP binding refresh REGISTER requests and to receive receive incoming SIP
requests. The document defines new SIP URI parameters and new requests. The document defines new SIP URI parameters and new
feature-capability indicators that can be used in SIP messages to feature-capability indicators that can be used in SIP messages to
indicate support of the mechanism defined in this document, to indicate support of the mechanism defined in this document, to
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 March 31, 2019. This Internet-Draft will expire on April 1, 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 4, line 19 skipping to change at page 4, line 19
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
wake 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, a stand-alone When the proxy receives a SIP request for a new dialog, or a stand-
SIP request or a SIP mid-dialog request (in case of longlived alone SIP request, addressed towards a UA, or when the proxy
dialogs),addressed towards a UA, or when the proxy determines that determines that the UA needs to send a binding refresh REGISTER
the UA needs to send a binding refresh REGISTER request, the proxy request, the proxy will request a push notification towards the UA,
will request a push notification towards the UA, using the PNS of the using the PNS of the UA. Once the UA receives the push notification,
UA. Once the UA receives the push notification, it will be able to it will be able to send a binding refresh REGISTER request and
send a binding refresh REGISTER request and receive the incoming SIP receive the incoming SIP request. The proxy will receive the
request. The proxy will receive the REGISTER request. If the push REGISTER request. If the push notification request was triggered by
notification request was triggered by a SIP request addressed towards a SIP request addressed towards the UA (see above), once the REGISTER
the UA (see above), once the REGISTER request has been accepted by request has been accepted by the SIP registrar [RFC3261], and the
the SIP registrar [RFC3261], and the associated SIP 2xx response has associated SIP 2xx response has been forwarded by the proxy towards
been forwarded by the proxy towards the UA, the proxy can forward the the UA, the proxy can forward the SIP request towards the UA using
SIP request towards the UA using normal SIP routing procedures. In normal SIP routing procedures. In some cases the proxy can forward
some cases the proxy can forward the SIP request without waiting for the SIP request without waiting for the SIP 2xx response to the
the SIP 2xx response to the REGISTER request. Note that this REGISTER request. Note that this mechanism necessarily adds delay to
mechanism necessarily adds delay to responding to non-INVITE requests responding to non-INVITE requests requiring push notification. The
requiring push notification. The consequences of that delay are consequences of that delay are discussed in Section 5.3.2.
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
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, of SIP requests (for a new dialog or a the UA towards the registrar, and of SIP requests (for a new dialog
stand-alone) forwarded by the proxy responsible for the UA's domain or a stand-alone) forwarded by the proxy responsible for the UA's
(sometimes referred to as home proxy, S-CSCF, etc) towards the UA and domain (sometimes referred to as home proxy, S-CSCF, etc) towards the
of mid-dialog requests that can trigger push notification requests. UA. The proxy can also be co-located with the proxy responsible for
The proxy can also be co-located with the proxy responsible for the the UA's domain. This will also ensure that the Request-URI of SIP
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 requests (for a new dialog or a stand-alone) can be matched against
contacts in REGISTER requests. contacts in REGISTER requests.
+--------+ +--------------+ +-----------------+ +--------+ +--------------+ +-----------------+
| SIP UA | | Push Service | | SIP Proxy | | SIP UA | | Push Service | | SIP Proxy |
+--------+ +--------------+ +-----------------+ +--------+ +--------------+ +-----------------+
| | | | | |
| Subscribe | | | Subscribe | |
|--------------------->| | |--------------------->| |
| | | | | |
skipping to change at page 16, line 26 skipping to change at page 16, line 26
proxy procedures in this section are applied in addition to the proxy procedures in this section are applied in addition to the
generic procedures defined in this specification. generic procedures defined in this specification.
6.1. SIP UA Behavior 6.1. SIP UA Behavior
6.1.1. Initial Request for Dialog 6.1.1. Initial Request for Dialog
When the UA sends in initial request for a dialog, or a 2xx response When the UA sends in initial request for a dialog, or a 2xx response
to such requests, if the UA is willing to receive push notifications to such requests, if the UA is willing to receive push notifications
triggered by incoming mid-dialog requests, the UA MUST include a 'pn- triggered by incoming mid-dialog requests, the UA MUST include a 'pn-
purk' SIP URI parameter in the Contact header of the request or purr' SIP URI parameter in the Contact header of the request or
response. The UA MUST include a parameter value identical to the the response. The UA MUST include a parameter value identical to the the
last 'sip.pnspurk' feature-capability indicator that it received in a last 'sip.pnspurr' feature-capability indicator that it received in a
REGISTER response. REGISTER response.
The UA decision whether it is willing to receive push notifications The UA decision whether it is willing to receive push notifications
triggered by incoming mid-dialog requests is done based on local triggered by incoming mid-dialog requests is done based on local
policy. Such policy might be based on the type of SIP dialog, the policy. Such policy might be based on the type of SIP dialog, the
type of media (if any) negotiated for the dialog [RFC3264], etc. type of media (if any) negotiated for the dialog [RFC3264], etc.
6.2. SIP Proxy Behavior 6.2. SIP Proxy Behavior
6.2.1. REGISTER 6.2.1. REGISTER
When the proxy receives an initial REGISTER request for a When the proxy receives an initial REGISTER request for a
registration from the UA, if the proxy supports requesting push registration from the UA, if the proxy supports requesting push
notifications, triggered by mid-dialog requests, towards the notifications, triggered by mid-dialog requests, towards the
registered UA, the proxy MUST store the information (the pn- SIP URI registered UA, the proxy MUST store the information (the pn- SIP URI
parameters) needed to request push notifications associated with the parameters) needed to request push notifications associated with the
registration towards the UA. In addition the proxy MUST generate a registration towards the UA. In addition the proxy MUST generate a
unique (within the context of the proxy) value, referred to as the unique (within the context of the proxy) value, referred to as the
PURK (Proxy Unique Registration Key), that is unique within the PURR (Proxy Unique Registration Reference), that is unique within the
context of the proxy and that can be used as a key to retrieve the context of the proxy and that can be used as a key to retrieve the
information. When the proxy receives the associated 2xx REGISTER information. When the proxy receives the associated 2xx REGISTER
response, it adds a 'sip.pnspurk' feature-capability indicator with response, it adds a 'sip.pnspurr' feature-capability indicator with
the PURK value to the associated 2xx REGISTER response. When the the PURR value to the associated 2xx REGISTER response. When the
proxy receives a binding refresh REGISTER request, it MUST add a proxy receives a binding refresh REGISTER request, it MUST add a
'sip.pnspurk' feature-capability indicator with the previously 'sip.pnspurr' feature-capability indicator with the previously
generated key as the value to the associated 2xx REGISTER response. generated key as the value to the associated 2xx REGISTER response.
The PURK value MUST be generated in such a way so that it cannot be The PURR value MUST be generated in such a way so that it cannot be
used to retrieve information about the user or associate it with used to retrieve information about the user or associate it with
registrations. It can be generated e.g., by utilizing a registrations. It can be generated e.g., by utilizing a
cryptographically secure random function. cryptographically secure random function.
In order to prevent client fingerprinting, the proxy MUST In order to prevent client fingerprinting, the proxy MUST
periodically generate a new PURK value (even if pn- parameters did periodically generate a new PURR value (even if pn- parameters did
not change) and provide the new value to the UA in a 2xx binding not change) and provide the new value to the UA in a 2xx binding
refresh REGISTER response. However, as long as there are ongoing refresh REGISTER response. However, as long as there are ongoing
dialogs associated with the old value, the proxy MUST store it so dialogs associated with the old value, the proxy MUST store it so
that it can request push notifications towards the UA when it that it can request push notifications towards the UA when it
receives a mid-dialog request addressed towards the UA. receives a mid-dialog request addressed towards the UA.
6.2.2. Initial Request for Dialog 6.2.2. Initial Request for Dialog
When the proxy receives an initial request for a dialog from the UA, When the proxy receives an initial request for a dialog from the UA,
and if the request contains a 'pn-purk' SIP URI parameter in the and if the request contains a 'pn-purr' SIP URI parameter in the
Contact header field with a PURK value that the proxy has generated Contact header field with a PURR value that the proxy has generated
Section 6.2.2, the proxy MUST add a Record-Route header to the Section 6.2.2, the proxy MUST add a Record-Route header to the
request, to insert itself in the dialog route [RFC3261]. request, to insert itself in the dialog route [RFC3261].
When the proxy receives an initial request for a dialog addressed When the proxy receives an initial request for a dialog addressed
towards the UA, and if the proxy has generated a PURK value towards the UA, and if the proxy has generated a PURR value
associated with the pn- parameters included in the SIP-URI of the associated with the pn- parameters included in the SIP-URI of the
request Section 6.2.2, the proxy MUST add a Record-Route header to request Section 6.2.2, the proxy MUST add a Record-Route header to
the request, to insert itself in the dialog route [RFC3261]. the request, to insert itself in the dialog route [RFC3261].
6.2.3. Mid-Dialog Request 6.2.3. Mid-Dialog Request
When the proxy receives a mid-dialog request addressed towards the When the proxy receives a mid-dialog request addressed towards the
UA, if the request contains a 'pn-purk' SIP URI parameter and if the UA, if the request contains a 'pn-purr' SIP URI parameter and if the
proxy is able to retrieve the stored information needed to request a proxy is able to retrieve the stored information needed to request a
push notification towards the UA (Section 6.2.1), the proxy MUST push notification towards the UA (Section 6.2.1), the proxy MUST
request a push notification towards the UA. Once the proxy has request a push notification towards the UA. Once the proxy has
received the triggered REGISTER request, and the associated received the triggered REGISTER request, and the associated
successful response, the proxy can forward the mid-dialog request successful response, the proxy can forward the mid-dialog request
towards the UA. towards the UA.
As described in Section 5.3.2, while waiting for the push As described in Section 5.3.2, while waiting for the push
notification request to succeed, and the associated REGISTER request notification request to succeed, and the associated REGISTER request
to arrive from the SIP UA, the proxy needs to take into consideration to arrive from the SIP UA, the proxy needs to take into consideration
 End of changes. 15 change blocks. 
40 lines changed or deleted 38 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/