draft-ietf-sipcore-sip-push-19.txt   draft-ietf-sipcore-sip-push-20.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: April 15, 2019 Metaswitch Networks Expires: April 22, 2019 Metaswitch Networks
October 12, 2018 October 19, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-19 draft-ietf-sipcore-sip-push-20
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 April 15, 2019. This Internet-Draft will expire on April 22, 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 36 skipping to change at page 2, line 36
6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 16 6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 16
6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 16 6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 16
6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 16 6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 16
6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 16 6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 16
6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 17 6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 17
6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 17 6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 17
7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 18 7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 18
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. 555 (Push Notification Service Not Supported) Response 8.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. 556 (Push Notification Failed) Response Code . . . . . . 18 8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 19
8.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 19 8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 19
8.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 19 8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 19
8.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 20 8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 20
8.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 20 8.6. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 20
8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 20
9. PNS Registration Requirements . . . . . . . . . . . . . . . . 21 9. PNS Registration Requirements . . . . . . . . . . . . . . . . 21
10. pn-provider, pn-param and pn-prid URI Parameters for Apple 10. pn-provider, pn-param and pn-prid URI Parameters for Apple
Push Notification service . . . . . . . . . . . . . . . . . . 21 Push Notification service . . . . . . . . . . . . . . . . . . 21
11. pn-provider, pn-param and pn-prid URI Parameters for Google 11. pn-provider, pn-param and pn-prid URI Parameters for Google
Firebase Cloud Messaging (FCM) push notification service . . 22 Firebase Cloud Messaging (FCM) push notification service . . 22
12. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 12. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
(Generic Event Delivery Using HTTP Push) . . . . . . . . . . 22 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 22
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23
14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 23 14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 23
14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 24 14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 24
14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 24 14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 24
14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 24 14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 24
14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 24 14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 24
14.2.1. 555 (Push Notification Service Not Supported) . . . 24 14.2.1. 555 (Push Notification Service Not Supported) . . . 24
14.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 25
14.3. SIP Global Feature-Capability Indicator . . . . . . . . 25 14.3. SIP Global Feature-Capability Indicator . . . . . . . . 25
14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 25 14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 25
14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 25 14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 25
14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 26 14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 26
14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 26 14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 26
14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 27 14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 27
14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 27 14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 27
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
16.1. Normative References . . . . . . . . . . . . . . . . . . 28 16.1. Normative References . . . . . . . . . . . . . . . . . . 28
skipping to change at page 7, line 23 skipping to change at page 7, line 23
UA wants to receive push notifications (requested by the proxy), the UA wants to receive push notifications (requested by the proxy), the
UA MUST include the following SIP URI parameters in the SIP Contact UA MUST include the following SIP URI parameters in the SIP Contact
header field URI of the REGISTER request: pn-provider, pn-prid and header field URI of the REGISTER request: pn-provider, pn-prid and
pn-param (if required for the specific PNS). The pn-provider URI pn-param (if required for the specific PNS). The pn-provider URI
parameter identifies the type of PNS, the pn-prid URI parameter parameter identifies the type of PNS, the pn-prid URI parameter
contains the PRID value and the pn-param URI parameter contains contains the PRID value and the pn-param URI parameter contains
additional PNS-specific information. additional PNS-specific information.
If the SIP UA creates multiple bindings (e.g., one for IPv4 and one If the SIP UA creates multiple bindings (e.g., one for IPv4 and one
for IPv6), the UA SHOULD use the same 'expires' Contact header field for IPv6), the UA SHOULD use the same 'expires' Contact header field
parameter value [RFC3261] for each binding. The UA MUST NOT create parameter value [RFC3261] for each binding.
bindings for other UAs (using a different PRID).
When the UA receives a 2xx response to the REGISTER request, if the When the UA receives a 2xx response to the REGISTER request, if the
response contains a Feature-Caps header field [RFC6809] with a response contains a Feature-Caps header field [RFC6809] with a
'sip.pns' feature-capability indicator with a parameter value 'sip.pns' feature-capability indicator with a parameter value
identifying the same type of PNS that was identified by the pn- identifying the same type of PNS that was identified by the pn-
provider URI parameter in the REGISTER request, the UA can assume provider URI parameter in the REGISTER request, the UA can assume
that a SIP proxy will request push notifications towards the UA. In that a SIP proxy will request push notifications towards the UA. In
other cases, the UA MUST NOT assume that push notifications will be other cases, the UA MUST NOT assume that push notifications will be
requested, and the actions taken by the UA might be dependent on requested, and the actions taken by the UA might be dependent on
implementation or deployment architecture, and are outside the scope implementation or deployment architecture, and are outside the scope
skipping to change at page 10, line 24 skipping to change at page 10, line 24
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. Trigger Periodic Binding Refresh 5.2. Trigger Periodic Binding Refresh
In order to request push notifications towards a SIP UA that will In order to request push notifications towards a SIP UA that will
trigger the UA to send binding refresh SIP REGISTER requests, the SIP trigger the UA to send binding refresh SIP REGISTER requests, the SIP
proxy needs to have information about when a registration will proxy needs to have information about when a registration will
expire. The proxy needs to be able to retrieve the information from expire. The proxy needs to be able to retrieve the information from
the registrar using some mechanism. Such mechanisms are outside the the registrar using some mechanism. Such mechanisms are outside the
scope of this document. scope of this document, but could be implemented e.g., using the
SIPregistration event package mechanism [RFC3680].
When the proxy receives an indication that the UA needs to send a When the proxy receives an indication that the UA needs to send a
binding refresh REGISTER request, the proxy requests a push binding refresh REGISTER request, the proxy requests a push
notification towards the UA. notification towards the UA.
Note that the push notification needs to be requested early enough, Note that the push notification needs to be requested early enough,
in order for the associated binding refresh REGISTER request to reach in order for the associated binding refresh REGISTER request to reach
the registrar before the registration expires. It is RECOMMENDED the registrar before the registration expires. It is RECOMMENDED
that the proxy requests the push notification at least 120 seconds that the proxy requests the push notification at least 120 seconds
before the registration expires. before the registration expires.
skipping to change at page 11, line 28 skipping to change at page 11, line 31
As described in Section 4.2, a SIP UA might send a REGISTER request As described in Section 4.2, a SIP UA might send a REGISTER request
without including a pn-prid SIP URI parameter in the Contact header without including a pn-prid SIP URI parameter in the Contact header
field URI, in order to retrieve push notification capabilities from field URI, in order to retrieve push notification capabilities from
the network before the UA the proxy will request push notifications the network before the UA the proxy will request push notifications
towards the UA. The procedures in this section apply to both the towards the UA. The procedures in this section apply to both the
case when the REGISTER request contains a pn-prid SIP URI parameter, case when the REGISTER request contains a pn-prid SIP URI parameter,
and when it does not. and when it does not.
When the proxy receives a REGISTER request, if the REGISTER request When the proxy receives a REGISTER request, if the REGISTER request
contains a Feature-Caps header field with a 'sip.pns' feature- contains a Feature-Caps header field with a 'sip.pns' feature-
capability indicator, it indicates that an upstream proxy supports, capability indicator, it indicates that a proxy between this proxy
and will request (if the Contact header field URI of the REGISTER and the UA supports, and will request (if the Contact header field
request contains a pn-prid SIP URI parameter), push notifications URI of the REGISTER request contains a pn-prid SIP URI parameter),
towards the UA. The proxy MUST skip the rest of the procedures in push notifications towards the UA. The proxy MUST skip the rest of
this section, and process the REGISTER request using normal SIP the procedures in this section, and process the REGISTER request
procedures. using normal SIP procedures.
If the proxy considers the requested registration expiration interval If the proxy considers the requested registration expiration interval
[RFC3261] to be too short, the proxy MUST either send a 423 (Interval [RFC3261] to be too short, the proxy MUST either send a 423 (Interval
Too Brief) response to the REGISTER request, or skip the rest of the Too Brief) response to the REGISTER request, or skip the rest of the
procedures in this section and process the REGISTER request using procedures in this section and process the REGISTER request using
normal SIP procedures. If the proxy sends a 423 (Interval Too Brief) normal SIP procedures. If the proxy sends a 423 (Interval Too Brief)
response, the proxy SHOULD insert a Feature-Caps header field with a response, the proxy SHOULD insert a Feature-Caps header field with a
'sip.pns' feature-capability indicator in the response, identifying 'sip.pns' feature-capability indicator in the response, identifying
each type of PNS that the proxy supports. Similarly, when the proxy each type of PNS that the proxy supports. Similarly, when the proxy
receives a 2xx response to the REGISTER request (see below), if the receives a 2xx response to the REGISTER request (see below), if the
skipping to change at page 12, line 9 skipping to change at page 12, line 12
registration. A registration expiration interval MUST be considered registration. A registration expiration interval MUST be considered
too short if the interval is smaller than the time prior to too short if the interval is smaller than the time prior to
expiration that the proxy would request a push notification. The expiration that the proxy would request a push notification. The
proxy MAY consider the interval too small based on its own policy so proxy MAY consider the interval too small based on its own policy so
as to reduce load on the system. as to reduce load on the system.
Otherwise, if the pn-provider SIP URI parameter identifies a type of Otherwise, if the pn-provider SIP URI parameter identifies a type of
PNS that the proxy does not support, or if the REGISTER request does PNS that the proxy does not support, or if the REGISTER request does
not contain all additional information required for the specific type not contain all additional information required for the specific type
of PNS, the proxy MUST either forward the request (e.g., if the proxy of PNS, the proxy MUST either forward the request (e.g., if the proxy
knows that a downstream proxy supports the type of PNS) or send a SIP knows that a proxy that is not between the push proxy and the UA
555 (Push Notification Service Not Supported) response to the supports the type of PNS) or send a SIP 555 (Push Notification
REGISTER request. If the proxy sends a SIP 555 (Push Notification Service Not Supported) response to the REGISTER request. If the
Service Not Supported) response Section 8.1, the proxy SHOULD insert proxy sends a SIP 555 (Push Notification Service Not Supported)
a Feature-Caps header field with a 'sip.pns' feature-capability response Section 8.1, the proxy SHOULD insert a Feature-Caps header
indicator in the response, identifying the type of each PNS that the field with a 'sip.pns' feature-capability indicator in the response,
proxy supports. The decision whether to forward the request, or to identifying the type of each PNS that the proxy supports. The
send a response, is done based on local policy. decision whether to forward the request, or to send a response, is
done based on local policy.
If the proxy supports the type of PNS identified by the pn-provider If the proxy supports the type of PNS identified by the pn-provider
SIP URI parameter, the proxy MUST insert a Feature-Caps header field SIP URI parameter, the proxy MUST insert a Feature-Caps header field
with a 'sip.pns' feature-capability indicator, identifying the type with a 'sip.pns' feature-capability indicator, identifying the type
of PNS, in the REGISTER request before forwarding the REGISTER of PNS, in the REGISTER request before forwarding the REGISTER
request towards the registrar. This will inform downstream proxies request towards the registrar. This will inform proxies that are not
that the proxy supports, and will request (if the Contact header between the push proxy and the UA that the proxy supports, and will
field URI of the REGISTER request contains a pn-prid SIP URI request (if the Contact header field URI of the REGISTER request
parameter), push notifications towards the UA. contains a pn-prid SIP URI parameter), push notifications towards the
UA.
If the proxy inserted a Feature-Caps header field with a 'sip.pns' If the proxy inserted a Feature-Caps header field with a 'sip.pns'
feature-capability indicator in the REGISTER request (see above), if feature-capability indicator in the REGISTER request (see above), if
the proxy receives a 2xx response to the REGISTER request, the proxy the proxy receives a 2xx response to the REGISTER request, the proxy
MUST insert a Feature-Caps header field with a 'sip.pns' feature- MUST insert a Feature-Caps header field with a 'sip.pns' feature-
capability indicator in the response, identifying the type of PNS. capability indicator in the response, identifying the type of PNS.
This will inform the UA that the proxy supports, and will request (if This will inform the UA that the proxy supports, and will request (if
the Contact header field URI of the REGISTER request contained a pn- the Contact header field URI of the REGISTER request contained a pn-
prid SIP URI parameter), push notifications towards the UA. The prid SIP URI parameter), push notifications towards the UA. The
proxy MUST only indicate support of the same PNS that was identified proxy MUST only indicate support of the same PNS that was identified
skipping to change at page 14, line 27 skipping to change at page 14, line 33
NOTE: The proxy needs to store (or be able to retrieve) the contact NOTE: The proxy needs to store (or be able to retrieve) the contact
of the most recent REGISTER 2xx response, to be able to compare it of the most recent REGISTER 2xx response, to be able to compare it
with the Request-URI of the request to be forwarded towards the UA. with the Request-URI of the request to be forwarded towards the UA.
In case of non-2xx response to the REGISTER request, the proxy MUST In case of non-2xx response to the REGISTER request, the proxy MUST
reject the SIP request with a 404 (Not Found) response. reject the SIP request with a 404 (Not Found) response.
If the push notification request fails (see PNS-specific If the push notification request fails (see PNS-specific
documentation for details), the proxy MUST reject the SIP request documentation for details), the proxy MUST reject the SIP request
with a 480 (Temporarily Unavailable) or a 556 (Push Notification with a 480 (Temporarily Unavailable) response.
Failed) response.
NOTE; Before sending a 556 (Push Notification Failed) response, the
proxy operator needs to determine whether it could have privacy
implications.
If the proxy does not receive the REGISTER request from the UA within If the proxy does not receive the REGISTER request from the UA within
a given time after the proxy has requested the push notification, the a given time after the proxy has requested the push notification, the
proxy MUST reject the request with a 480 (Temporarily Unavailable) proxy MUST reject the request with a 480 (Temporarily Unavailable)
response. The time value is set based on local policy. response. The time value is set based on local policy.
As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must
complete immediately or risk losing race that results in stress on complete immediately or risk losing race that results in stress on
intermediaries and state misalignment at the endpoints. The intermediaries and state misalignment at the endpoints. The
mechanism defined in this document inherently delays the final mechanism defined in this document inherently delays the final
skipping to change at page 15, line 29 skipping to change at page 15, line 30
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. 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.
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 wake, and that the UA is 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 REGISTER able to receive the SIP request without first sending a REGISTER
request, the proxy MAY choose to not request a push notification request, the proxy MAY choose to not request a push notification
towards the UA (and wait for the associated REGISTER request and 2xx towards the UA (and wait for the associated REGISTER request and 2xx
response) before it tries to forward the SIP request towards the UA. response) before it tries to forward the SIP request towards the UA.
The mechanisms for getting such knowledge might be dependent on The mechanisms for getting such knowledge might be dependent on
implementation or deployment architecture, and are outside the scope implementation or deployment architecture, and are outside the scope
of this document. Similarly, if the Request-URI of the SIP request of this document. Similarly, if the Request-URI of the SIP request
only contains any pn-provider SIP URI parameter, but no other pn- SIP only contains any pn-provider SIP URI parameter, but no other pn- SIP
URI parameters, e.g., because the SIP UA has not included them in a URI parameters, e.g., because the SIP UA has not included them in a
REGISTER request (Section 4.2), the proxy is not able to request a REGISTER request (Section 4.2), the proxy is not able to request a
push notification towards the UA. If the proxy has knowledge that push notification towards the UA. If the proxy has knowledge that
the UA is wake, and that the UA is able to receive the SIP request, the UA is awake, and that the UA is able to receive the SIP request,
the proxy MAY forwards the request towards the UA. Otherwise the the proxy MAY forwards the request towards the UA. Otherwise the
proxy MUST reject the SIP request with a 480 (Temporarily proxy MUST reject the SIP request with a 480 (Temporarily
Unavailable) or a 556 (Push Notification Failed) response. Unavailable) response.
6. Support Of Longlived SIP Dialogs 6. Support Of Longlived SIP Dialogs
Some SIP dialogs might have a long lifetime, with little activity. Some SIP dialogs might have a long lifetime, with little activity.
For example, when the SIP event notification mechanism [RFC6665] is For example, when the SIP event notification mechanism [RFC6665] is
used, there might be a long period between mid-dialog SIP NOTIFY used, there might be a long period between mid-dialog SIP NOTIFY
requests are sent. Because of this a SIP UA might get suspended, and requests are sent. Because of this a SIP UA might get suspended, and
needs to be awaken in order to be able to receive mid-dialog needs to be awaken in order to be able to receive mid-dialog
requests. requests.
skipping to change at page 18, line 47 skipping to change at page 19, line 5
8.1. 555 (Push Notification Service Not Supported) Response Code 8.1. 555 (Push Notification Service Not Supported) Response Code
The 555 response code is added to the "Server-Error" Status-Code The 555 response code is added to the "Server-Error" Status-Code
definition. 555 (Push Notification Service Not Supported) is used to definition. 555 (Push Notification Service Not Supported) is used to
indicate that the server did not support the push notification indicate that the server did not support the push notification
service identified in a 'pn-provider' SIP URI parameter. service identified in a 'pn-provider' SIP URI parameter.
The use of the SIP 555 response code is defined for SIP REGISTER The use of the SIP 555 response code is defined for SIP REGISTER
responses. responses.
8.2. 556 (Push Notification Failed) Response Code 8.2. sip.pns Feature-Capability Indicator
The 556 response code is added to the "Server-Error" Status-Code
definition. 556 (Push Notification Failed) is used to indicate that
the server failed to request a push notification from the push
notification service identified in a 'pn-provider' SIP URI parameter.
The use of the SIP 556 response code is defined for responses to SIP
requests initiating dialogs, and responses to stand-alone SIP
requests.
8.3. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator, when included in a Feature- The sip.pns feature-capability indicator, when included 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, and will use, the SIP push mechanism and the push indicator supports, and will use, the SIP push mechanism and the push
notification service identified by the indicator value. When notification service identified by the indicator value. When
included in a 555 (Push Notification Service Not Supported) response included in a 555 (Push Notification Service Not Supported) response
to a REGISTER request, the the indicator indicates that the entity to a REGISTER request, the the indicator indicates that the entity
associated with the indicator supports the SIP push mechanism, and associated with the indicator supports the SIP push mechanism, and
the push notification service(s) identified by the indicator value. the push notification service(s) identified by the indicator value.
The values defined for the pn-provider SIP URI parameter are used as The values defined for the pn-provider SIP URI parameter are used as
indicator values. indicator values.
pns-fc = "+sip.pns" EQUAL LDQUOT pns-list RDQUOT pns-fc = "+sip.pns" EQUAL LDQUOT pns-list RDQUOT
pns-list = pns *(COMMA pns) pns-list = pns *(COMMA pns)
pns = tag-value pns = tag-value
tag-value = <tag-value defined in [RFC3840]> tag-value = <tag-value defined in [RFC3840]>
8.4. sip.vapid Feature-Capability Indicator 8.3. sip.vapid Feature-Capability Indicator
The sip.vapid feature-capability indicator, when included in a SIP The sip.vapid feature-capability indicator, when included 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
associated with the indicator supports, and will use, the Voluntary associated with the indicator supports, and will use, the Voluntary
Application Server Identification (VAPID) [RFC8292] mechanism when Application Server Identification (VAPID) [RFC8292] mechanism when
requesting push notifications towards the SIP UA associated with the requesting push notifications towards the SIP UA associated with the
SIP registration. The indicator value is a public key identifying SIP registration. The indicator value is a public key identifying
the entity, that can be used by a SIP UA to restrict subscriptions to the entity, that can be used by a SIP UA to restrict subscriptions to
that entity. that entity.
vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT
vapid = tag-value vapid = tag-value
tag-value = <tag-value defined in [RFC3840]> tag-value = <tag-value defined in [RFC3840]>
8.5. sip.pnsreg Feature-Capability Indicator 8.4. sip.pnsreg Feature-Capability Indicator
The sip.pnsreg feature-capability indicator, when included in a SIP The sip.pnsreg feature-capability indicator, when included 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
associated with the indicator expects to receive binding refresh associated with the indicator expects to receive binding refresh
REGISTER requests from the SIP UA associated with the registration REGISTER requests from the SIP UA associated with the registration
before the registration expires, without the entity having to request before the registration expires, without the entity having to request
push notifications towards the SIP UA in order to trigger the push notifications towards the SIP UA in order to trigger the
REGISTER requests. The indicator value is the minimum value (given REGISTER requests. The indicator value is the minimum value (given
in seconds) before the registration expiration when the entity in seconds) before the registration expiration when the entity
expects to receive the REGISTER request. expects to receive the REGISTER request.
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT reg = 1*DIGIT
DIGIT = <DIGIT defined in [RFC3261]> DIGIT = <DIGIT defined in [RFC3261]>
8.6. sip.pnsreg Media Feature Tag 8.5. sip.pnsreg Media Feature Tag
The sip.pnsreg media feature tag, when included in the SIP Contact The sip.pnsreg media feature tag, when included in the SIP Contact
header field of a SIP REGISTER request, indicates that the SIP UA header field of a SIP REGISTER request, indicates that the SIP UA
associated with the tag is able to send binding refresh REGISTER associated with the tag is able to send binding refresh REGISTER
requests associated with the registration without being awaken by requests associated with the registration without being awaken by
push notifications. The media feature tag has no values. push notifications. The media feature tag has no values.
pnsreg-mt = "+sip.pnsreg" pnsreg-mt = "+sip.pnsreg"
8.7. SIP URI Parameters 8.6. SIP URI Parameters
The section defines new SIP URI parameters, by extending the grammar The section defines new SIP URI parameters, by extending the grammar
for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows:
uri-parameter =/ pn-provider / pn-param / pn-prid uri-parameter =/ pn-provider / pn-param / pn-prid
pn-provider = "pn-provider" EQUAL pvalue pn-provider = "pn-provider" EQUAL pvalue
pn-param = "pn-param" EQUAL pvalue pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" EQUAL pvalue pn-prid = "pn-prid" EQUAL pvalue
pvalue = <pvalue defined in [RFC3261]> pvalue = <pvalue defined in [RFC3261]>
skipping to change at page 25, line 5 skipping to change at page 25, line 5
14.2.1. 555 (Push Notification Service Not Supported) 14.2.1. 555 (Push Notification Service Not Supported)
This section defines a new SIP response code that extends the This section defines a new SIP response code that extends the
"Response Codes" sub-registry [RFC3261] under the sip-parameters "Response Codes" sub-registry [RFC3261] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters. registry: http://www.iana.org/assignments/sip-parameters.
Response Code Number: 555 Response Code Number: 555
Default Reason Phrase: Push Notification Service Not Supported Default Reason Phrase: Push Notification Service Not Supported
14.2.2. 556 (Push Notification Failed)
This section defines a new SIP response code that extends the
"Response Codes" sub-registry [RFC3261] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters.
Response Code Number: 556
Default Reason Phrase: Push Notififcation Failed
14.3. SIP Global Feature-Capability Indicator 14.3. SIP Global Feature-Capability Indicator
14.3.1. sip.pns 14.3.1. sip.pns
This section defines a new feature-capability indicator that extends This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry: [RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Name: sip.pns Name: sip.pns
skipping to change at page 29, line 44 skipping to change at page 29, line 44
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>.
16.2. Informative References 16.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, <https://www.rfc- DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
editor.org/info/rfc3264>. editor.org/info/rfc3264>.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680,
DOI 10.17487/RFC3680, March 2004, <https://www.rfc-
editor.org/info/rfc3680>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, Protocol (SIP) "Replaces" Header", RFC 3891,
DOI 10.17487/RFC3891, September 2004, <https://www.rfc- DOI 10.17487/RFC3891, September 2004, <https://www.rfc-
editor.org/info/rfc3891>. editor.org/info/rfc3891>.
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4320, DOI 10.17487/RFC4320, January Transaction", RFC 4320, DOI 10.17487/RFC4320, January
2006, <https://www.rfc-editor.org/info/rfc4320>. 2006, <https://www.rfc-editor.org/info/rfc4320>.
 End of changes. 21 change blocks. 
67 lines changed or deleted 46 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/