draft-ietf-sipcore-sip-push-15.txt   draft-ietf-sipcore-sip-push-16.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 30, 2019 Metaswitch Networks Expires: March 31, 2019 Metaswitch Networks
September 26, 2018 September 27, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-15 draft-ietf-sipcore-sip-push-16
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 30, 2019. This Internet-Draft will expire on March 31, 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, or a stand- When the proxy receives a SIP request for a new dialog, a stand-alone
alone SIP request, addressed towards a UA, or when the proxy SIP request or a SIP mid-dialog request (in case of longlived
determines that the UA needs to send a binding refresh REGISTER dialogs),addressed towards a UA, or when the proxy determines that
request, the proxy will request a push notification towards the UA, the UA needs to send a binding refresh REGISTER request, the proxy
using the PNS of the UA. Once the UA receives the push notification, will request a push notification towards the UA, using the PNS of the
it will be able to send a binding refresh REGISTER request and UA. Once the UA receives the push notification, it will be able to
receive the incoming SIP request. The proxy will receive the send a binding refresh REGISTER request and receive the incoming SIP
REGISTER request. If the push notification request was triggered by request. The proxy will receive the REGISTER request. If the push
a SIP request addressed towards the UA (see above), once the REGISTER notification request was triggered by a SIP request addressed towards
request has been accepted by the SIP registrar [RFC3261], and the the UA (see above), once the REGISTER request has been accepted by
associated SIP 2xx response has been forwarded by the proxy towards the SIP registrar [RFC3261], and the associated SIP 2xx response has
the UA, the proxy can forward the SIP request towards the UA using been forwarded by the proxy towards the UA, the proxy can forward the
normal SIP routing procedures. In some cases the proxy can forward SIP request towards the UA using normal SIP routing procedures. In
the SIP request without waiting for the SIP 2xx response to the some cases the proxy can forward the SIP request without waiting for
REGISTER request. Note that this mechanism necessarily adds delay to the SIP 2xx response to the REGISTER request. Note that this
responding to non-INVITE requests requiring push notification. The mechanism necessarily adds delay to responding to non-INVITE requests
consequences of that delay are discussed in Section 5.3.2. 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
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, of SIP requests (for a new dialog or a
or a stand-alone) forwarded by the proxy responsible for the UA's stand-alone) forwarded by the proxy responsible for the UA's domain
domain (sometimes referred to as home proxy, S-CSCF, etc) towards the (sometimes referred to as home proxy, S-CSCF, etc) towards the UA and
UA. The proxy can also be co-located with the proxy responsible for of mid-dialog requests that can trigger push notification requests.
the UA's domain. This will also ensure that the Request-URI of SIP The proxy can also be co-located with the proxy responsible for 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 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 | |
|--------------------->| | |--------------------->| |
| | | | | |
 End of changes. 5 change blocks. 
26 lines changed or deleted 28 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/