draft-ietf-sipcore-sip-push-24.txt   draft-ietf-sipcore-sip-push-25.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: July 26, 2019 Metaswitch Networks Expires: August 9, 2019 Metaswitch Networks
January 22, 2019 February 5, 2019
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-24 draft-ietf-sipcore-sip-push-25
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 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 that push notifications are sent to the UA, entity that will request that push notifications are sent to the UA,
and to trigger such push notification requests. and to trigger such push notification requests.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 26, 2019. This Internet-Draft will expire on August 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 26 skipping to change at page 2, line 26
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 7 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 7
4.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Request Push Notifications . . . . . . . . . . . . . 8 4.1.1. Request Push Notifications . . . . . . . . . . . . . 8
4.1.2. Disable Push Notifications . . . . . . . . . . . . . 9 4.1.2. Disable Push Notifications . . . . . . . . . . . . . 9
4.1.3. Receive Push Notifications . . . . . . . . . . . . . 10 4.1.3. Receive Push Notifications . . . . . . . . . . . . . 10
4.1.4. Sending Binding-Refresh Requests Using Non-Push 4.1.4. Sending Binding-Refresh Requests Using Non-Push
Mechanism . . . . . . . . . . . . . . . . . . . . . . 10 Mechanism . . . . . . . . . . . . . . . . . . . . . . 10
4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 11 4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 11
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 12 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 12
5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 12 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 12
5.2. SIP Request Push Queue . . . . . . . . . . . . . . . . . 12 5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 12
5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 12 5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 13
5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 13 5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 13
5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 13 5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 13
5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 14 5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 14
5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 14 5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 14
5.6.2. Initial Request for Dialog or Stand-Alone Request . . 17 5.6.2. Initial Request for Dialog or Stand-Alone Request . . 17
6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 20 6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 20
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 22 6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 22
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 22 6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 22
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 23 6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 23
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 23 6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 9, line 16 skipping to change at page 9, line 16
whenever it receives a push notification. whenever it receives a push notification.
When a UA requests push notifications, the UA MUST insert the When a UA requests push notifications, the UA MUST insert the
following SIP URI parameters in the SIP Contact header field URI of following SIP URI parameters in the SIP Contact header field URI of
the REGISTER request: pn-provider, pn-prid and pn-param (if required the REGISTER request: pn-provider, pn-prid and pn-param (if required
for the specific PNS). The pn-provider URI parameter parameter for the specific PNS). The pn-provider URI parameter parameter
indicates the type of PNS to be used for the push notifications. indicates the type of PNS to be used for the push notifications.
If the UA receives a 2xx response to the REGISTER request that If the UA receives a 2xx response to the REGISTER request that
contains a Feature-Caps header field [RFC6809] with a 'sip.pns' contains a Feature-Caps header field [RFC6809] with a 'sip.pns'
feature-capability indicator, with a indicator value identifying the feature-capability indicator, with an indicator value identifying the
same type of PNS that was identified by the pn-provider URI parameter same type of PNS that was identified by the pn-provider URI parameter
in the REGISTER request, it indicates that a SIP Proxy in the SIP in the REGISTER request, it indicates that a SIP Proxy in the SIP
network will request that push notifications are sent to the UA. In network will request that push notifications are sent to the UA. In
addition, if the samd Feature-Caps header field contains a addition, if the same Feature-Caps header field contains a
'sip.vapid' feature-capability indicator, it indicates that the proxy 'sip.vapid' feature-capability indicator, it indicates that the proxy
supports use of the Voluntary Application Server Identification supports use of the Voluntary Application Server Identification
(VAPID) mechanism [RFC8292] to restrict push notifications to the UA. (VAPID) mechanism [RFC8292] to restrict push notifications to the UA.
NOTE: The VAPID specific procedures of the SIP UA are outside the NOTE: The VAPID specific procedures of the SIP UA are outside the
scope of this document. scope of this document.
If the UA receives a non-2xx response to the REGISTER, or if the UA If the UA receives a non-2xx response to the REGISTER, or if the UA
receives a 2xx response that does not contain a Feature-Caps header receives a 2xx response that does not contain a Feature-Caps header
field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA
skipping to change at page 9, line 47 skipping to change at page 9, line 47
binding-refresh REGISTER request with the updated pn- parameters. If binding-refresh REGISTER request with the updated pn- parameters. If
a PRID is no longer valid, and the UA is not able to retrieve a new a PRID is no longer valid, and the UA is not able to retrieve a new
PRID, the UA MUST disable the push notifications associated with the PRID, the UA MUST disable the push notifications associated with the
PRID (Section 4.1.2). PRID (Section 4.1.2).
4.1.2. Disable Push Notifications 4.1.2. Disable Push Notifications
When a UA wants to disable previously requested push notifications, When a UA wants to disable previously requested push notifications,
the UA SHOULD remove the binding [RFC3261], unless the UA is no the UA SHOULD remove the binding [RFC3261], unless the UA is no
longer able to perform SIP procedures (e.g., due to a forced shutdown longer able to perform SIP procedures (e.g., due to a forced shutdown
of the UA). When the UA sends the REGISTER request for removing the of the UA) in which case the registrar will remove the binding once
binding, the UA MUST include the pn-pric SIP URI parameter in the it expires. When the UA sends the REGISTER request for removing the
binding, the UA MUST include the pn-prid SIP URI parameter in the
Contact header field URI of the REGISTER request, in order to inform Contact header field URI of the REGISTER request, in order to inform
the SIP network that the UA no longer wants to receive push the SIP network that the UA no longer wants to receive push
notifications associated with the PRID. notifications associated with the PRID.
4.1.3. Receive Push Notifications 4.1.3. Receive Push Notifications
When a UA receives a push notification, the UA MUST send a binding- When a UA receives a push notification, the UA MUST send a binding-
refresh REGISTER request. The UA MUST insert the same set of pn- SIP refresh REGISTER request. The UA MUST insert the same set of pn- SIP
URI parameters in the SIP Contact header field URI of the REGISTER URI parameters in the SIP Contact header field URI of the REGISTER
request that it inserted when it requested push notifications request that it inserted when it requested push notifications
skipping to change at page 12, line 31 skipping to change at page 12, line 33
The type of PNS is identified by the pn-provider SIP URI parameter. The type of PNS is identified by the pn-provider SIP URI parameter.
In some cases there might only be one PNS provider for a given type In some cases there might only be one PNS provider for a given type
of PNS, while in other cases there might be multiple providers. The of PNS, while in other cases there might be multiple providers. The
pn-param SIP URI parameter will provide more details associated with pn-param SIP URI parameter will provide more details associated with
the actual PNS provider to be used. the actual PNS provider to be used.
The protocol and format used for the push notification requests are The protocol and format used for the push notification requests are
PNS-specific, and the details for constructing and sending a push PNS-specific, and the details for constructing and sending a push
notification request are outside the scope of this specification. notification request are outside the scope of this specification.
5.2. SIP Request Push Queue 5.2. SIP Request Push Bucket
When a SIP proxy receives a SIP request, addressed towards a UA, that When a SIP proxy receives a SIP request, addressed towards a UA, that
will trigger the proxy to request that a push notification is sent to will trigger the proxy to request that a push notification is sent to
the UA, the proxy will place the request in a queue referred to as the UA, the proxy will place the request in a storage referred to as
the SIP Request Push Queue. A SIP request is removed from the queue the SIP Request Push Bucket. The proxy starts a timer (referred to
once the proxy either forwards the request towards the UA or when the as the Bucket Timer) associated with the transaction. A SIP request
proxy sends an error response to the request. The detailed is removed from the bucket once the proxy forwards the request
procedures are described in the sections below. towards the UA, when the proxy sends an error response to the
request, or when the Bucket Timer times out. The detailed procedures
are described in the sections below.
Exactly how the SIP Request Push Queue is implemented is outside the Exactly how the SIP Request Push Bucket is implemented is outside the
scope of this document. One option is to use the PRID as a key to scope of this document. One option is to use the PRID as a key to
search for SIP requests in the queue. Note that mid-dialog requests search for SIP requests in the bucket. Note that mid-dialog requests
(Section 6) do not carry the PRID in the SIP request itself. (Section 6) do not carry the PRID in the SIP request itself.
5.3. SIP URI Comparison Rules 5.3. SIP URI Comparison Rules
When a SIP proxy compares two SIP URIs, the proxy uses the URI By default, a SIP proxy uses the URI comparison rules defined in
comparison rules defined in [RFC3261], meaning that in order for a [RFC3261]. However, when a SIP proxy compares the Contact header
comparison to be successful the pn-prid, pn-provider and pn-param SIP field URI of a 2xx response to a REGISTER request with a Request-URI
URI parameters must also match. of a SIP request in the SIP Request Push Bucket (Section 5.2), the
proxy uses the URI comparison rules with the following additions: the
pn-prid, pn-provider and pn-param SIP URI parameters MUST also match.
If a pn- parameter is present in one of the compared URIs but not in
the other URI there is no match.
If only the pn- SIP URI parameters listed above match, but other If only the pn- SIP URI parameters listed above match, but other
parts of the compared URIs do not match, a proxy MAY still consider parts of the compared URIs do not match, a proxy MAY still consider
the comparison successful, based on local policy. This can occur in the comparison successful, based on local policy. This can occur in
a race condition when the proxy compares the Contact header field URI a race condition when the proxy compares the Contact header field URI
of a 2xx response to a REGISTER request with a Request-URI of a SIP of a 2xx response to a REGISTER request with a Request-URI of a SIP
request in the SIP Request Push Queue (Section 5.2), if the UA that request in the SIP Request Push Bucket (Section 5.2), if the UA that
sent the associated REGISTER request modified some parts of the sent the associated REGISTER request modified some parts of the
Contact header field URI in the REGISTER request, but the Request-URI Contact header field URI in the REGISTER request, but the Request-URI
of the SIP request in the SIP Request Push Queue still contains the of the SIP request in the SIP Request Push Bucket still contains the
old parts. old parts.
5.4. Indicate Support of Type of PNS 5.4. Indicate Support of Type of PNS
A SIP proxy uses feature-capability indicators [RFC6809] to indicate A SIP proxy uses feature-capability indicators [RFC6809] to indicate
support of types of PNSs, and additional features (e.g., VAPID) support of types of PNSs, and additional features (e.g., VAPID)
associated associated with a type of PNS. A proxy MUST use a associated associated with a type of PNS. A proxy MUST use a
separate Feature-Cap header fields for each supported type of PNS. A separate Feature-Cap header fields for each supported type of PNS. A
feature-capability indicator that indicates support of an additional feature-capability indicator that indicates support of an additional
feature associated with a given type of PNS MUST be inserted in the feature associated with a given type of PNS MUST be inserted in the
skipping to change at page 14, line 34 skipping to change at page 14, line 46
5.6. SIP Requests 5.6. SIP Requests
5.6.1. REGISTER 5.6.1. REGISTER
This section describes how a SIP proxy processes SIP REGISTER This section describes how a SIP proxy processes SIP REGISTER
requests (initial REGISTER request for a binding, or a binding- requests (initial REGISTER request for a binding, or a binding-
refresh REGISTER request). refresh REGISTER request).
The procedures in this section apply when the REGISTER request The procedures in this section apply when the REGISTER request
contains a pn-provider SIP URI parameter in the Contact header field contains a pn-provider SIP URI parameter in the Contact header field
URI of the request. In other cases the proxy MUST skip the procdures URI of the request. In other cases the proxy MUST skip the
in this section, and process the REGISTER request using normal SIP procedures in this section, and process the REGISTER request using
procedures. normal SIP procedures.
5.6.1.1. Request Push Notifications 5.6.1.1. Request Push Notifications
This section describes the SIP proxy procedures when a SIP UA This section describes the SIP proxy procedures when a SIP UA
requests push notifications from the SIP network. requests push notifications from the SIP network.
The procedures in this section apply when the SIP REGISTER request The procedures in this section apply when the SIP REGISTER request
contains, in addition to the pn-provider SIP URI parameter, a pn-prid contains, in addition to the pn-provider SIP URI parameter, a pn-prid
SIP URI parameter in the Contact header field URI of the request. SIP URI parameter in the Contact header field URI of the request.
skipping to change at page 15, line 31 skipping to change at page 15, line 46
o If the proxy supports the type of PNS supported by the UA, but o If the proxy supports the type of PNS supported by the UA, but
considers the requested binding expiration interval [RFC3261] to considers the requested binding expiration interval [RFC3261] to
be too short (see below), the proxy MUST either send a 423 be too short (see below), the proxy MUST either send a 423
(Interval Too Brief) response to the REGISTER request or forward (Interval Too Brief) response to the REGISTER request or forward
the request towards the registrar and skip the rest of the the request towards the registrar and skip the rest of the
procedures in this section. If the proxy sends a 423 (Interval procedures in this section. If the proxy sends a 423 (Interval
Too Brief) response, the proxy SHOULD insert one or more Feature- Too Brief) response, the proxy SHOULD insert one or more Feature-
Caps header fields with a 'sip.pns' feature-capability indicator Caps header fields with a 'sip.pns' feature-capability indicator
in the response, indicating each type of PNS that the proxy in the response, indicating each type of PNS that the proxy
supports. supports.
o If the proxy supports the type of of PNS supported by the UA, the o If the proxy supports the type of PNS supported by the UA, the
proxy MUST indicate support of that type of PNS (Section 5.4) in proxy MUST indicate support of that type of PNS (Section 5.4) in
the REGISTER request before it forwards the request towards the the REGISTER request before it forwards the request towards the
registrar. This will inform proxies between the proxy and the registrar. This will inform proxies between the proxy and the
registrar that the proxy supports the type of PNS supported by the registrar that the proxy supports the type of PNS supported by the
UA, and that the proxy will request that push notifications are UA, and that the proxy will request that push notifications are
sent to the UA. sent to the UA.
A binding expiration interval MUST be considered too short if the the A binding expiration interval MUST be considered too short if the
binding would expire before the proxy would request that a push binding would expire before the proxy would request that a push
notification is sent to the UA, in order to trigger the UA to send a notification is sent to the UA, in order to trigger the UA to send a
binding-refresh REGISTER request. The proxy MAY consider the binding-refresh REGISTER request. The proxy MAY consider the
interval too short based on its own policy so as to reduce load on interval too short based on its own policy so as to reduce load on
the system. the system.
If the proxy sends a SIP 555 (Push Notification Service Not If the proxy sends a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD indicate each type of PNS that Supported) response, the proxy SHOULD indicate each type of PNS that
the proxy supports in the response. the proxy supports in the response.
skipping to change at page 16, line 44 skipping to change at page 17, line 9
The procedures in this section apply when the REGISTER request The procedures in this section apply when the REGISTER request
contains a pn-provider SIP URI parameter, but does not contain a pn- contains a pn-provider SIP URI parameter, but does not contain a pn-
prid SIP URI parameter, in the Contact header field URI of the prid SIP URI parameter, in the Contact header field URI of the
REGISTER request. REGISTER request.
When a proxy receives a REGISTER request, if the pn-provider SIP URI When a proxy receives a REGISTER request, if the pn-provider SIP URI
parameter contains a parameter value that indicates the type of PNS parameter contains a parameter value that indicates the type of PNS
supported by the UA, the proxy MUST perform the following actions: supported by the UA, the proxy MUST perform the following actions:
If the proxy supports the type of of PNS supported by the UA, the If the proxy supports the type of PNS supported by the UA, the
proxy MUST indicate support of that type of PNS (Section 5.4) in proxy MUST indicate support of that type of PNS (Section 5.4) in
the REGISTER request before it forwards the request towards the the REGISTER request before it forwards the request towards the
registrar. This will inform proxies betwen the proxy and the registrar. This will inform proxies between the proxy and the
registrar that the proxy supports the type of PNS supported by the registrar that the proxy supports the type of PNS supported by the
UA. UA.
If the proxy does not support the type of PNS supported by the UA, If the proxy does not support the type of PNS supported by the UA,
and if the REGISTER request contains Feature-Caps header fields and if the REGISTER request contains Feature-Caps header fields
indicating support of one or more types of PNSs, the proxy indicating support of one or more types of PNSs, the proxy
forwards the request towards the registrar. forwards the request towards the registrar.
If the proxy does not support the type of PNS supported by the UA, If the proxy does not support the type of PNS supported by the UA,
and if the REGISTER request does not contain Feature-Caps header and if the REGISTER request does not contain Feature-Caps header
fields indicating support of one or more types of PNSs, the proxy fields indicating support of one or more types of PNSs, the proxy
MUST either forward the request towards the registrar, or send a MUST either forward the request towards the registrar, or send a
skipping to change at page 17, line 30 skipping to change at page 17, line 43
When a proxy receives a REGISTER request, if the pn-provider SIP URI When a proxy receives a REGISTER request, if the pn-provider SIP URI
parameter does not contain a parameter value, the proxy MUST indicate parameter does not contain a parameter value, the proxy MUST indicate
support of each type of PNS supported by the proxy before it forwards support of each type of PNS supported by the proxy before it forwards
the request towards the registrar. the request towards the registrar.
When a proxy receives a 2xx response to the REGISTER request, if the When a proxy receives a 2xx response to the REGISTER request, if the
proxy indicated support of one or more types of PNSs in the REGISTER proxy indicated support of one or more types of PNSs in the REGISTER
request (see above), the proxy MUST indicate support of the same set request (see above), the proxy MUST indicate support of the same set
of types of PNSs in the response. In addition, if the proxy supports of types of PNSs in the response. In addition, if the proxy supports
the VAPID mechanism for one or more types of PNSs, the proxy MUST the VAPID mechanism for one or more types of PNSs, the proxy MUST
indicate support of the mechanism for thoses PNSs in the response. indicate support of the mechanism for those PNSs in the response.
5.6.2. Initial Request for Dialog or Stand-Alone Request 5.6.2. Initial Request for Dialog or Stand-Alone Request
The procedures in this section apply when a SIP proxy has indicated The procedures in this section apply when a SIP proxy has indicated
that the it will request that push notifications are sent to the SIP that the it will request that push notifications are sent to the SIP
UA. UA.
When the proxy receives a SIP request for a new dialog (e.g., a SIP When the proxy receives a SIP request for a new dialog (e.g., a SIP
INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE
request) addressed towards a SIP UA, if the Request-URI of the request) addressed towards a SIP UA, if the Request-URI of the
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
that a push notification is sent to the UA, using the information in that a push notification is sent to the UA, using the information in
the pn- SIP URI parameters. The proxy then places the SIP request in the pn- SIP URI parameters. The proxy then places the SIP request in
the SIP Request Push Queue (Section 5.2). The push notification will the SIP Request Push Bucket. The push notification will trigger the
trigger the UA to send a binding-refresh REGISTER request, that the UA to send a binding-refresh REGISTER request, that the proxy will
proxy will process as described in Section 5.6.1. In addition, the process as described in Section 5.6.1. In addition, the proxy MUST
proxy MUST store the Contact URI of the REGISTER request during the store the Contact URI of the REGISTER request during the lifetime of
lifetime of the REGISTER transaction. the REGISTER transaction.
NOTE: If the proxy receives a SIP request does not contain the pn- NOTE: If the proxy receives a SIP request that does not contain the
SIP URI parameters listed above, the proxy processing of the request pn- SIP URI parameters listed above, the proxy processing of the
is based on local policy. If the proxy also serves requests for UAs request is based on local policy. If the proxy also serves requests
that do not use the SIP push mechanism, the proxy can forward the for UAs that do not use the SIP push mechanism, the proxy can forward
request towards the UA. Otherwise the proxy can reject the request. the request towards the UA. Otherwise the proxy can reject the
request.
When the proxy receives a 2xx response to the REGISTER request, the When the proxy receives a 2xx response to the REGISTER request, the
proxy performs the following actions: proxy performs the following actions:
The proxy processes the REGISTER response as described in The proxy processes the REGISTER response as described in
Section 5.6.1. Section 5.6.1.
The proxy checks whether the SIP Request Push Queue contains a SIP The proxy checks whether the SIP Request Push Bucket contains a
request associated with the REGISTER transaction. If the queue SIP request associated with the REGISTER transaction, by comparing
contains such request the proxy compares (Section 5.3) the Contact (Section 5.3) the Contact header field URI in the REGISTER
header field URI in the REGISTER response with the Request-URIs of response with the Request-URIs of the SIP requests in the queue.
the SIP requests in the queue. If there is a match, the proxy If there is a match, the proxy MUST remove the SIP request from
MUST remove the SIP request from the waiting queue and forward it the bucket and forward it towards the UA.
towards the UA.
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 a SIP request towards a UA is to make sure that the forwarding a SIP request towards a UA is to make sure that the
REGISTER request has been accepted by the registrar, and that the UA REGISTER request has been accepted by the registrar, and that the UA
that initiated the REGISTER request is authorized to receive messages that initiated the REGISTER request is authorized to receive messages
for the Request-URI. for the Request-URI.
If the proxy receives a non-2xx response to the REGISTER request, the If the proxy receives a non-2xx response to the REGISTER request, the
proxy compares the Contact URI stored from the REGISTER request (see proxy compares the Contact URI stored from the REGISTER request (see
above) with the Request-URIs of the SIP requests in the SIP Request above) with the Request-URIs of the SIP requests in the SIP Request
Push Queue. If there is a match, the proxy SHOULD remove the Push Bucket. If there is a match, the proxy SHOULD remove the
associated request from the queue and send an error response to the associated request from the bucket and send an error response to the
request. It is RECOMMENDED that the proxy sends either a 404 (Not request. It is RECOMMENDED that the proxy sends either a 404 (Not
Found) response or a 480 (Temporarily Unavailable) response to the Found) response or a 480 (Temporarily Unavailable) response to the
SIP request, but other response codes can be used as well. However, SIP request, but other response codes can be used as well. However,
if the REGISTER response is expected to trigger a new REGISTER if the REGISTER response is expected to trigger a new REGISTER
request from the UA (e.g., if the registrar is requesting the UA to request from the UA (e.g., if the registrar is requesting the UA to
perform authentication) the proxy MAY keep the SIP request in the perform authentication) the proxy MAY keep the SIP request in the
queue. bucket.
If the push notification request fails (see PNS-specific If the push notification request fails (see PNS-specific
documentation for details), the proxy MUST remove the SIP request documentation for details), the proxy MUST remove the SIP request
from the queue and send an error response to the SIP request. It is from the bucket and send an error response to the SIP request. It is
RECOMMENDED that the proxy sends either a 404 (Not Found) response or RECOMMENDED that the proxy sends either a 404 (Not Found) response or
a 480 (Temporarily Unavailable) response, but other response codes a 480 (Temporarily Unavailable) response, but other response codes
can be used as well. can be used as well.
When the proxy has requested that a push notification is sent to a When the proxy has requested that a push notification is sent to a
UA, if the proxy does not receive a REGISTER response with a Contact UA, if the proxy does not receive a REGISTER response with a Contact
URI that matches the Request-URI of the SIP request, the transaction URI that matches the Request-URI of the SIP request, the Bucket Timer
timer of the SIP request will eventually time out. When that happens (Section 5.2) associated with the SIP request will eventually time
the proxy MUST remove the SIP request from the queue and send a 480 out. When that happens the proxy MUST remove the SIP request from
(Temporarily Unavailable) response. The timer expiration value is the SIP Request Push Bucket (Section 5.2) and send a 480 (Temporarily
set based on local policy, taking the guidelines below into Unavailable) response. The Bucket Timer time out value is set based
consideration. on local policy, taking the guidelines below into consideration.
As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must
complete immediately or risk losing a race that results in stress on complete immediately or risk losing a 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
response to any non-INVITE request that requires a push notification. response to any non-INVITE request that requires a push notification.
In particular, while waiting for the push notification request to In particular, while waiting for the push notification request to
succeed, and the associated REGISTER request to arrive from the SIP succeed, and the associated REGISTER request to arrive from the SIP
UA, the proxy needs to take into consideration that the transaction UA, the proxy needs to take into consideration that the transaction
associated with the SIP request will eventually time out at the associated with the SIP request will eventually time out at the
sender of the request (UAC), and the sender will consider the sender of the request (UAC), and the sender will consider the
transaction a failure. If the proxy forwards the SIP request towards transaction a failure. If the proxy forwards the SIP request towards
the SIP UA, the SIP UA accepts the request and the transaction times the SIP UA, the SIP UA accepts the request and the transaction times
out at the sender before it receives the successful response, this out at the sender before it receives the successful response, this
will cause state misalignment between the endpoints (the sender will will cause state misalignment between the endpoints (the sender will
consider the transaction a failure, while the receiver will consider consider the transaction a failure, while the receiver will consider
the transaction a success). The SIP proxy needs to take this into the transaction a success). The SIP proxy needs to take this into
account when deciding for how long to wait before it considers the account when it sets the value of the Bucket Timer associated with
transaction associated with the SIP request a failure, to make sure the transaction, to make sure that the error response (triggered by a
that the error response reaches the sender before the transaction Bucket Timer time out) reaches the sender before the transaction
times out. If the accumulated delay of this mechanism combined with times out. If the accumulated delay of this mechanism combined with
any other mechanisms in the path of processing the non-INVITE any other mechanisms in the path of processing the non-INVITE
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
skipping to change at page 19, line 50 skipping to change at page 20, line 12
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. However, the time might notification, is typically around 2 seconds. However, the time might
vary depending on the characteristics and load of the SIP network and vary depending on the characteristics and load of the SIP network and
the PNS. the PNS.
In addition to the procedures described above there are two cases In addition to the procedures described above there are two cases
where a proxy, as an optimization, can forward a SIP request towards where a proxy, as an optimization, can forward a SIP request towards
a UA without waiting for a 2xx response to a REGISTER request, or a UA without waiting for a 2xx response to a REGISTER request, or
without even requesting that a push notification is sent to the UA: without even requesting that a push notification is sent to the UA:
If the proxy is able to authorize the sender of the REGISTER If the proxy is able to authenticate the sender of the REGISTER
request, the proxy does not need to wait for the 2xx response request, the proxy does not need to wait for the 2xx response
before it forwards the SIP request towards the UA. In such cases, before it forwards the SIP request towards the UA. In such cases,
the proxy will use the Contact URI of the REGISTER request when the proxy will use the Contact URI of the REGISTER request when
comparing it against the Request-URIs of the SIP requests in the comparing it against the Request-URIs of the SIP requests in the
SIP Request Push Queue. SIP Request Push Bucket.
If the proxy has knowledge that the UA is awake, and that the UA If the proxy has knowledge that the UA is awake, and that the UA
is able to receive the SIP request without first sending a is able to receive the SIP request without first sending a
binding-refresh REGISTER request, the proxy does not need to binding-refresh REGISTER request, the proxy does not need to
request that a push notification is sent to the UA (the UA will request that a push notification is sent to the UA (the UA will
not send a binding-refresh REGISTER request) before it forwards not send a binding-refresh REGISTER request) before it forwards
the SIP request towards the UA. The mechanisms for getting such the SIP request towards the UA. The mechanisms for getting such
knowledge might be dependent on implementation or deployment knowledge might be dependent on implementation or deployment
architecture, and are outside the scope of this document. architecture, and are outside the scope of this document.
Some PNS providers allow payload in the push notifications. This Some PNS providers allow payload in the push notifications. This
skipping to change at page 22, line 29 skipping to change at page 22, line 36
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 a UA sends an initial request for a dialog, or a 2xx response to When a UA sends an initial request for a dialog, or a 2xx response to
such requests, if the UA is willing to receive push notifications such requests, if the UA is willing to receive push notifications
when a proxy receives a mid-dialog request addressed towards the UA, when a proxy receives a mid-dialog request addressed towards the UA,
the UA MUST insert a 'pn-purr' SIP URI parameter in the Contact the UA MUST insert a 'pn-purr' SIP URI parameter in the Contact
header field URI of the request or response. The UA MUST insert a header field URI of the request or response. The UA MUST insert a
parameter value identical to the the last 'sip.pnspurr' feature- parameter value identical to the last 'sip.pnspurr' feature-
capability indicator that it received in a REGISTER response capability indicator that it received in a REGISTER response
(Section 6.2.1). If the UA has not recived a 'sip.pnspurr' feature- (Section 6.2.1). If the UA has not recived a 'sip.pnspurr' feature-
capability indicator, the UA MUST NOT insert a 'pn-purr' SIP URI capability indicator, the UA MUST NOT insert a 'pn-purr' SIP URI
parameter in a request or response. parameter in a request or 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.
skipping to change at page 24, line 11 skipping to change at page 24, line 11
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] before request, to insert itself in the dialog route [RFC3261] before
forwarding the request. forwarding the request.
6.2.3. Mid-Dialog Request 6.2.3. Mid-Dialog Request
When the proxy receives a mid-dialog SIP request addressed towards When the proxy receives a mid-dialog SIP request addressed towards
the UA, if the request contains a 'pn-purr' 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 the proxy is able to retrieve the stored information needed to
request that a push notification is sent the UA (Section 6.2.1), the request that a push notification is sent the UA (Section 6.2.1), the
proxy MUST place the SIP request in the SIP Request Push Queue and proxy MUST place the SIP request in the SIP Request Push Bucket and
request that a push notification is sent to the UA. request that a push notification is sent to the UA.
NOTE: The 'pn-purr' SIP URI parameter will either be carried in the NOTE: The 'pn-purr' SIP URI parameter will either be carried in the
Request-URI or in a Route header field [RFC3261] of the SIP request, Request-URI or in a Route header field [RFC3261] of the SIP request,
depending on how the route set [RFC3261] of the mid-dialog SIP depending on how the route set [RFC3261] of the mid-dialog SIP
request has been constructed. request has been constructed.
When the proxy receives a 2xx response to a REGISTER request, the When the proxy receives a 2xx response to a REGISTER request, the
proxy checks whether the SIP Request Push Queue contains a mid-dialog proxy checks whether the SIP Request Push Bucket contains a mid-
SIP request associated with the REGISTER transaction. If the queue dialog SIP request associated with the REGISTER transaction. If the
contains such request the proxy MUST remove the SIP request from the bucket contains such request the proxy MUST remove the SIP request
waiting queue and forward it towards the UA. from the SIP Request Push Bucket and forward it towards the UA.
Note that the proxy does not perform a URI comparison (Section 5.3) Note that the proxy does not perform a URI comparison (Section 5.3)
when processing mid-dialog requests, as a mid-dialog request will not when processing mid-dialog requests, as a mid-dialog request will not
contain the pn-prid, pn-provider and pn-param SIP URI parameters. contain the pn-prid, pn-provider and pn-param SIP URI parameters.
The proxy only checks for a mid-dialog request that contains the PURR The proxy only checks for a mid-dialog request that contains the PURR
value associated with the REGISTER 2xx response. value associated with the REGISTER 2xx response.
As described in Section 5.6.2, while waiting for the push As described in Section 5.6.2, while waiting for the push
notification request to succeed, and the associated REGISTER request notification request to succeed, and the associated REGISTER request
and 2xx response, the proxy needs to take into consideration that the and 2xx response, the proxy needs to take into consideration that the
skipping to change at page 25, line 14 skipping to change at page 25, line 14
replaces an existing dialog, using the mechanism in [RFC3891], the replaces an existing dialog, using the mechanism in [RFC3891], the
proxy and the UA MUST perform the following actions: proxy and the UA MUST perform the following actions:
o The proxy MUST provide a PURR to the UA during registration o The proxy MUST provide a PURR to the UA during registration
Section 6.2.1. Section 6.2.1.
o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact
header field URI of the initial request for a dialog, or a 2xx header field URI of the initial request for a dialog, or a 2xx
response to such requests Section 6.1.1. This includes dialogs response to such requests Section 6.1.1. This includes dialogs
replacing other dialogs, as those dialogs might also get replaced. replacing other dialogs, as those dialogs might also get replaced.
o The proxy MUST apply the mechanism defined in Section 6.2.3 to o The proxy MUST apply the mechanism defined in Section 6.2.3 to
place and retrieve the request from the waiting queue. place and retrieve the request from the SIP Request Push Bucket.
In addition, the operator needs to make sure that the initial request In addition, the operator needs to make sure that the initial request
for dialogs, addressed towards the UA using the contact of the for dialogs, addressed towards the UA using the contact of the
replaced dialog, will be routed to the SIP proxy (in order to request replaced dialog, will be routed to the SIP proxy (in order to request
that a push notification is sent to the UA). The procedures for that a push notification is sent to the UA). The procedures for
doing that are operator specific, and are outside the scope of this doing that are operator specific, and are outside the scope of this
specification. specification.
8. Grammar 8. Grammar
skipping to change at page 25, line 43 skipping to change at page 25, line 43
responses. responses.
8.2. sip.pns Feature-Capability Indicator 8.2. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator, when inserted in a Feature- The sip.pns feature-capability indicator, when inserted in a Feature-
Caps header field of a SIP REGISTER request or a SIP 2xx response to Caps header field of a SIP REGISTER request or a SIP 2xx response to
a REGISTER request, indicates that the entity associated with the a REGISTER request, indicates that the entity associated with the
indicator supports the SIP push mechanism and the type of push indicator supports the SIP push mechanism and the type of push
notification service indicated by the indicator value. When inserted notification service indicated by the indicator value. When inserted
in a 555 (Push Notification Service Not Supported) response to a in a 555 (Push Notification Service Not Supported) response to a
REGISTER request, the the indicator indicates that the entity REGISTER request, the indicator indicates that the entity associated
associated with the indicator supports the SIP push mechanism, and with the indicator supports the SIP push mechanism, and the type of
the type of push notification service identified by the indicator push notification service identified by the indicator value. The
value. The values defined for the pn-provider SIP URI parameter are values defined for the pn-provider SIP URI parameter are used as
used as indicator values. indicator values.
pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT
pns = tag-value pns = tag-value
tag-value = <tag-value defined in [RFC3840]> tag-value = <tag-value defined in [RFC3840]>
8.3. sip.vapid Feature-Capability Indicator 8.3. sip.vapid Feature-Capability Indicator
The sip.vapid feature-capability indicator, when inserted in a SIP The sip.vapid feature-capability indicator, when inserted in a SIP
2xx response to a SIP REGISTER request, indicates that the entity 2xx response to a SIP REGISTER request, indicates that the entity
skipping to change at page 30, line 26 skipping to change at page 30, line 26
authorized) is out of scope for this document. [RFC8030] documents authorized) is out of scope for this document. [RFC8030] documents
the security considerations for the PNS defined in that the security considerations for the PNS defined in that
specification. Security considerations for other PNSs are left to specification. Security considerations for other PNSs are left to
their respective specifications. their respective specifications.
Typically, the PNS requires the SIP proxy requesting push Typically, the PNS 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. Unless the PNS authenticates and to request push notifications. Unless the PNS authenticates and
authorizes the PNS, a malicious endpoint that managed to get access authorizes the PNS, a malicious endpoint or network entity that
to the parameters transported in the SIP signalling might be able to managed to get access to the parameters transported in the SIP
request that push notifications are sent to a UA. Which such push signalling might be able to request that push notifications are sent
notifications will not have any security related impacts, they will to a UA. Such push notifications will impact the battery life of the
impact the battery life of the UA and trigger unnecessary SIP UA and trigger unnecessary SIP traffic.
traffic.
[RFC8292] defines a mechanism that allows a proxy to identity itself [RFC8292] defines a mechanism that 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.
Operators MUST ensure that the SIP signalling is properly secured, Operators MUST ensure that the SIP signalling is properly secured,
e.g., using encryption, from malicious endpoints. TLS MUST be used, e.g., using encryption, from malicious network entities. TLS MUST be
unless the operators know that the signalling is secured using some used, unless the operators know that the signalling is secured using
other mechanism that provides strong crypto properties. some other mechanism that provides strong crypto properties.
In addition to the information that needs to be exchanged between a In addition to the information that needs to be exchanged between a
device and the PNS in order to establish a push notification device and the PNS in order to establish a push notification
subscription, the mechanism defined in this document does not require subscription, the mechanism defined in this document does not require
any additional information to be exchanged between the device and the any additional information to be exchanged between the device and the
PNS. PNS.
The mechanism defined in this document does not require a proxy to The mechanism defined in this document does not require a proxy to
insert any payload (in addition to possible payload used for the PNS insert any payload (in addition to possible payload used for the PNS
itself) when requesting push notifications. itself) when requesting push notifications.
Operators MUST ensure that the PNS-related SIP URI parameters Operators MUST ensure that the PNS-related SIP URI parameters
conveyed by a user in the Contact URI of a REGISTER request are not conveyed by a user in the Contact URI of a REGISTER request are not
sent to other users, or to non-trusted network entities. One way to sent to other users, or to non-trusted network entities. One way to
convey contact information is by using the the SIP event package for convey contact information is by using the the SIP event package for
registrations mechanism [RFC3680]. [RFC3680] defines generic registrations mechanism [RFC3680]. [RFC3680] defines generic
security considerations for the SIP event package for registations. security considerations for the SIP event package for registrations.
As the PNS-related SIP URI parameters conveyed in the REGISTER As the PNS-related SIP URI parameters conveyed in the REGISTER
request contain sensitive information, operators that support the request contain sensitive information, operators that support the
event package MUST ensure that event package subscriptions are event package MUST ensure that event package subscriptions are
properly authenticated and authorized, and that the SIP URI properly authenticated and authorized, and that the SIP URI
parameters are not inserted in event notifications sent to other parameters are not inserted in event notifications sent to other
users, or to non-trusted network entities. users, or to non-trusted network entities.
14. IANA considerations 14. IANA considerations
[RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the
 End of changes. 39 change blocks. 
87 lines changed or deleted 93 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/