draft-ietf-sipcore-sip-push-09.txt   draft-ietf-sipcore-sip-push-10.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: September 16, 2018 Metaswitch Networks Expires: September 27, 2018 Metaswitch Networks
March 15, 2018 March 26, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-09 draft-ietf-sipcore-sip-push-10
Abstract Abstract
This document describes how a Push Notification Service (PNS) can be This document describes how a Push Notification Service (PNS) can be
used to awake suspended Session Initiation Protocol (SIP) User Agents used to awake suspended Session Initiation Protocol (SIP) User Agents
(UAs), for the UA to be able to receive and send SIP requests. The (UAs), for the UA to be able to receive and send SIP requests. The
document defines new SIP URI parameters and new feature-capability document defines new SIP URI parameters and new feature-capability
indicators that can be used in SIP messages to indicate support of indicators that can be used in SIP messages to indicate support of
the mechanism defined in this document, to exchange PNS information the mechanism defined in this document, to exchange PNS information
between the SIP User Agent (UA) and the SIP entity that will request between the SIP User Agent (UA) and the SIP entity that will request
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 16, 2018. This Internet-Draft will expire on September 27, 2018.
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 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 8 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 8
5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 8 5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 8
5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 8 5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 8
5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 9 5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 9
5.3.2. Initial Request for Dialog or Stand-Alone Request . . 10 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 11
6. Network Address Translator (NAT) Considerations . . . . . . . 12 6. Network Address Translator (NAT) Considerations . . . . . . . 12
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. 555 (Push Notification Service Not Supported) Response 7.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 12 7.2. 556 (Push Notification Failed) Response Code . . . . . . 13
7.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 13 7.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 13
7.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 13 7.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 13
7.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 14 7.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 14
7.6. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 14 7.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 14
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 14 7.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 15
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 15
9. pn-provider, pn-param and pn-prid URI Parameters for Apple 9. pn-provider, pn-param and pn-prid URI Parameters for Apple
Push Notification service . . . . . . . . . . . . . . . . . . 15 Push Notification service . . . . . . . . . . . . . . . . . . 15
10. pn-provider, pn-param and pn-prid URI Parameters for Google 10. pn-provider, pn-param and pn-prid URI Parameters for Google
Firebase Cloud Messaging (FCM) push notification service . . 15 Firebase Cloud Messaging (FCM) push notification service . . 16
11. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 11. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
(Generic Event Delivery Using HTTP Push) . . . . . . . . . . 16 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 13. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
13.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 17 13.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 18
13.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 17 13.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 18
13.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 17 13.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 18
13.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 18 13.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 18
13.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 18 13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 18
13.3. SIP Global Feature-Capability Indicator . . . . . . . . 18 13.2.1. 555 (Push Notification Service Not Supported) . . . 18
13.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 18 13.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 19
13.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 19 13.3. SIP Global Feature-Capability Indicator . . . . . . . . 19
13.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 19 13.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 19
13.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 20 13.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 20
13.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 20 13.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 20
13.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 21
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 13.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 13.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . 22 13.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 23 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
In order to save resources (e.g., battery life) some devices In order to save resources (e.g., battery life) some devices
(especially mobile devices) and operating systems will suspend (especially mobile devices) and operating systems will suspend
applications when not used. In some cases, internal timers cannot be applications when not used. In some cases, internal timers cannot be
used to awake such applications, nor will incoming network traffic used to awake such applications, nor will incoming network traffic
awake the application. Instead, the only way to awake the awake the application. Instead, the only way to awake the
application is by using a Push Notification Service (PNS). Typically application is by using a Push Notification Service (PNS). Typically
each operating system uses a dedicated PNS. For example, Apple iOS each operating system uses a dedicated PNS. For example, Apple iOS
skipping to change at page 4, line 4 skipping to change at page 4, line 7
NOTE: Even if a UA is able to awake (e.g., using internal timers) in NOTE: Even if a UA is able to awake (e.g., using internal timers) in
order to send periodic re-registration REGISTER requests, it might order to send periodic re-registration REGISTER requests, it might
still be useful to suspend the application between the sending of re- still be useful to suspend the application between the sending of re-
registration requests (as it will save battery life etc) and use a registration requests (as it will save battery life etc) and use a
PNS to awake the UA when a SIP request addressed towards the UA PNS to awake the UA when a SIP request addressed towards the UA
arrives. arrives.
When a UA registers to a PNS, it will receive a unique Push Resource When a UA registers to a PNS, it will receive a unique Push Resource
ID (PRID) associated with the push notification registration. The UA ID (PRID) associated with the push notification registration. The UA
will provide the PRID to the SIP proxy that will request push will use a REGISTER request to provide the PRID to the SIP proxy that
notifications towards the UA in a REGISTER request. will request push notifications towards the UA.
When the proxy receives (or, if the proxy is the SIP registrar When the proxy receives (or, if the proxy is the SIP registrar
[RFC3261], initiates) a SIP request for a new dialog, or a stand- [RFC3261], initiates) a SIP request for a new dialog, or a stand-
alone SIP request, addressed towards a UA, or when the proxy alone SIP request, addressed towards a UA, or when the proxy
determines that the UA needs to send a re-registration REGISTER determines that the UA needs to send a re-registration REGISTER
request, the proxy will request a push notification towards the UA, request, the proxy will request a push notification towards the UA,
using the PNS of the UA. Once the UA receives the push notification, using the PNS of the UA. Once the UA receives the push notification,
it will be able to send a re-registration REGISTER request and it will be able to send a re-registration REGISTER request and
receive the incoming SIP request. The proxy will receive and forward receive the incoming SIP request. The proxy will receive and forward
(or, if the proxy is the registrar, process) the REGISTER request. (or, if the proxy is the registrar, process) the REGISTER request.
skipping to change at page 6, line 43 skipping to change at page 6, line 43
response contains a Feature-Caps header field with a 'sip.pns' response contains a Feature-Caps header field with a 'sip.pns'
feature-capability indicator with a parameter value identifying the feature-capability indicator with a parameter value identifying the
same PNS that was identified by the pn-provider URI parameter in the same PNS that was identified by the pn-provider URI parameter in the
REGISTER request, the UA can assume that a SIP proxy will request REGISTER request, the UA can assume that a SIP proxy will request
push notifications towards the UA. In other cases, the UA MUST NOT push notifications towards the UA. In other cases, the UA MUST NOT
assume that push notifications will be requested, and the actions assume that push notifications will be requested, and the actions
taken by the UA might be dependent on implementation or deployment taken by the UA 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.
In addition, if the response contains a Feature-Caps header field In addition, if the response contains a Feature-Caps header field
with a 'sip.vapid' feature-capability indicator, the UA can use the with a 'sip.vapid' feature-capability indicator, the proxy supports
Voluntary Application Server Identification VAPID) mechanism use of the Voluntary Application Server Identification (VAPID)
[RFC8292] to restrict push notifications to the proxy (assuming that mechanism [RFC8292] to restrict push notifications to the proxy.
the PNS supports VAPID).
When the UA receives a push notification, it MUST send a re- When the UA receives a push notification, it MUST send a re-
registration REGISTER request, using normal SIP procedures. If there registration REGISTER request, using normal SIP procedures. If there
are Network Address Translators (NATs) between the UA and the proxy, are Network Address Translators (NATs) between the UA and the proxy,
the REGISTER request will create NAT bindings that will allow the REGISTER request will create NAT bindings that will allow
incoming SIP requests to reach the UA. Once the UA has received a incoming SIP requests to reach the UA. Once the UA has received a
2xx response to the REGISTER request, the UA might receive a SIP 2xx response to the REGISTER request, the UA might receive a SIP
request for a new dialog (e.g., a SIP INVITE), or a stand-alone SIP request for a new dialog (e.g., a SIP INVITE), or a stand-alone SIP
request (e.g., a SIP MESSAGE), if such SIP request triggered the push request (e.g., a SIP MESSAGE), if such SIP request triggered the push
notification request. Note that, depending on which transport notification request. Note that, depending on which transport
skipping to change at page 8, line 33 skipping to change at page 8, line 32
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. Trigger Periodic Re-registration 5.2. Trigger Periodic Re-registration
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 re-registration SIP REGISTER requests, the SIP trigger the UA to send re-registration SIP REGISTER requests, the SIP
proxy MUST have information about when a registration will expire. proxy MUST have information about when a registration will expire.
The proxy either needs to be the SIP registrar, or the proxy needs to The proxy either needs to be the SIP registrar, or the proxy needs to
retrieve the information from the registrar using some other retrieve the information from the registrar using some mechanism.
mechanism. Such mechanisms are outside the scope of this document. Such mechanisms are outside the scope of this document.
When the proxy receives an indication that the UA needs to send a re- When the proxy receives an indication that the UA needs to send a re-
registration REGISTER request, the proxy requests a push notification registration REGISTER request, the proxy requests a push notification
towards the UA. 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 re-registration REGISTER request to reach in order for the associated re-registration REGISTER request to reach
the SIP registrar before the registration expires. It is RECOMMENDED the SIP 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.
If the UA has indicated, using the 'sip.pnsreg' media feature tag, If the UA has indicated, using the 'sip.pnsreg' media feature tag,
that it is able to sending re-registration REGISTER requests without that it is able to sending re-registration REGISTER requests without
receiving push notifications, if the proxy does not receive a receiving push notifications, if the proxy does not receive a
REGISTER request prior to 120 seconds before the registration REGISTER request prior to 120 seconds before the registration
expires, the proxy SHOULD request a push notification towards the UA, expires, the proxy MAY request a push notification towards the UA, to
to trigger the UA to send a REGISTER request. trigger the UA to send a REGISTER request.
NOTE: In some cases the UA might be able to use a non-push mechanism NOTE: In some cases the UA might be able to use a non-push mechanism
(e.g., a timer) to awake and send re-registration REGISTER requests. (e.g., a timer) to awake and send re-registration REGISTER requests.
Such REGISTER request will update the registration expiration timer, Such REGISTER request will update the registration expiration timer,
and the proxy does not need to request a push notification towards and the proxy does not need to request a push notification towards
the UA in order to awake the UA. The proxy will still request a push the UA in order to awake the UA. The proxy will still request a push
notification towards the UA when the proxy receives a SIP request notification towards the UA when the proxy receives a SIP request
addressed towards the UA (Section 5.3.2). This allows the UA to addressed towards the UA (Section 5.3.2). This allows the UA to
e.g., use timers for sending re-registration REGISTER requests, but e.g., use timers for sending re-registration REGISTER requests, but
to be suspended (in order to save battery resources etc) between to be suspended (in order to save battery resources etc) between
skipping to change at page 10, line 25 skipping to change at page 10, line 25
If the proxy supports the PNS identified by the pn-provider SIP URI If the proxy supports the PNS identified by the pn-provider SIP URI
parameter, the proxy MUST insert a Feature-Caps header field with a parameter, the proxy MUST insert a Feature-Caps header field with a
'sip.pns' feature-capability indicator, identifying the PNS, in the 'sip.pns' feature-capability indicator, identifying the PNS, in the
REGISTER request before forwarding the REGISTER request (unless the REGISTER request before forwarding the REGISTER request (unless the
proxy is the registrar, in which case the proxy will terminate the proxy is the registrar, in which case the proxy will terminate the
REGISTER request). This will inform downstream proxies that the REGISTER request). This will inform downstream proxies that the
proxy supports, and will request, push notifications towards the UA. proxy supports, and will request, 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), feature-capability indicator in the REGISTER request (see above), if
when the proxy receives (or, in case the proxy is the SIP registrar, the proxy receives (or, in case the proxy is the SIP registrar,
creates) a 2xx response to the REGISTER request, the proxy MUST creates) a 2xx response to the REGISTER request, the proxy MUST
insert a Feature-Caps header field with a 'sip.pns' feature- insert a Feature-Caps header field with a 'sip.pns' feature-
capability indicator in the response, identifying the PNS. This will capability indicator in the response, identifying the PNS. This will
inform the UA that the proxy supports, and will request, push inform the UA that the proxy supports, and will request, push
notifications towards the UA. The proxy MUST only indicate support notifications towards the UA. The proxy MUST only indicate support
of the same PNS that was identified in the pn-provider SIP URI of the same PNS that was identified in the pn-provider SIP URI
parameter in the REGISTER request. parameter in the REGISTER request. If the proxy receives a receives
a SIP 555 (Push Notification Service Not Supported) response, the
proxy SHOULD insert a Feature-Caps header field with a 'sip.pns'
feature-capability indicator in the response, identifying each PNS
that the proxy supports.
In addition, if the proxy supports, and will use, the VAPID In addition, if the proxy receives a 2xx response to the REGISTER
mechanism, the proxy MUST insert a Feature-Caps header field with a request:
'sip.vapid' feature-capability indicator in the response. The header
field parameter contains the public key identifying the proxy
[RFC8292].
In addition, if the proxy received a 'sip.pnsreg' media feature tag o if the proxy supports, and will use, the VAPID mechanism, the
in the REGISTER request, the proxy SHOULD include a 'sip.pnsreg' proxy MUST insert a Feature-Caps header field with a 'sip.vapid'
feature-capability indicator with an indicator value bigger than 120 feature-capability indicator in the response. The header field
in the response, unless the proxy always want to request push parameter contains the public key identifying the proxy [RFC8292].
notifications to trigger the UA to send a REGISTER request. The proxy MUST be able to determine whether the PNS supports the
VAPID mechanism before it inserts the feature-capability
indicator.
o if the proxy received a 'sip.pnsreg' media feature tag in the
REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature-
capability indicator with an indicator value bigger than 120 in
the response, unless the proxy always want to request push
notifications to trigger the UA to send a REGISTER request.
5.3.2. Initial Request for Dialog or Stand-Alone Request 5.3.2. Initial Request for Dialog or Stand-Alone Request
The procedures in this section apply when the SIP proxy has indicated The procedures in this section apply when the SIP proxy has indicated
that it supports, and will request, push notifications towards the that it supports, and will request, push notifications towards the
SIP UA. SIP UA.
When the proxy receives (or, in case the proxy is the registrar, When the proxy receives (or, in case the proxy is the registrar,
creates) a SIP request for a new dialog (e.g., a SIP INVITE request) creates) a SIP request for a new dialog (e.g., a SIP INVITE request)
or a stand-alone SIP request (e.g., a SIP MESSAGE request) addressed or a stand-alone SIP request (e.g., a SIP MESSAGE request) addressed
skipping to change at page 11, line 24 skipping to change at page 11, line 32
The push notification will trigger the UA to send a re-registration The push notification will trigger the UA to send a re-registration
REGISTER request. The proxy will process the REGISTER request and REGISTER request. The proxy will process the REGISTER request and
the associated response as described in Section 5.3.1. In case of a the associated response as described in Section 5.3.1. In case of a
2xx response to the REGISTER request, once the proxy has forwarded 2xx response to the REGISTER request, once the proxy has forwarded
the REGISTER response towards the UA, if the contact in the REGISTER the REGISTER response towards the UA, if the contact in the REGISTER
response matches the Request-URI of the SIP request to be forwarded, response matches the Request-URI of the SIP request to be forwarded,
the proxy can also forward the SIP request towards the UA, using the proxy can also forward the SIP request towards the UA, using
normal SIP procedures. If the contact of the most recent REGISTER normal SIP procedures. If the contact of the most recent REGISTER
2xx response and Request-URI do not match, the proxy MUST reject the 2xx response and Request-URI do not match, the proxy MUST reject the
SIP request with a 404 (Not Found) response. SIP request with a 404 (Not Found) response. As both the SIP request
to be forwarded towards the UA, and the re-registration REGISTER
request triggered by the push notification request, will convey pn-
URI parameters associated with the SIP registration, those can be
used to match the SIP request with the re-registration REGISTER
request (even if the most recent contact and the Request-URI of the
SIP request do not match).
NOTE: If the proxy is not the registrar, it needs to store (or be NOTE: If the proxy is not the registrar, it needs to store (or be
able to retrieve) the contact of the most recent REGISTER 2xx able to retrieve) the contact of the most recent REGISTER 2xx
response, to be able to compare it with the Request-URI of the response, to be able to compare it with the Request-URI of the
request to be forwarded towards the UA. 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 555 (Push Notification Service Not Supported) response. with a 556 (Push Notification Failed) response.
NOTE: As described above, the reason the proxy needs to wait for the NOTE: As described above, the reason the proxy needs to wait for the
REGISTER response before forwarding the SIP request is to make sure REGISTER response before forwarding the SIP request is to make sure
that the REGISTER request has been accepted by the SIP registrar, and that the REGISTER request has been accepted by the SIP registrar, and
that the registered contact matches the Request-URI of the SIP that the registered contact matches the Request-URI of the SIP
request to be forwarded. request to be forwarded.
If the proxy does not receive the REGISTER request from the UA within If the proxy does not receive the REGISTER request from the UA within
a given time after the proxy has requested the push notification, the a given time after the proxy has requested the push notification, the
proxy MUST reject the request with a 404 (Not Found) response. The proxy MUST reject the request with a 404 (Not Found) response. The
skipping to change at page 12, line 39 skipping to change at page 13, line 5
request created one or more NAT bindings, this will ensure that the request created one or more NAT bindings, this will ensure that the
SIP request reaches the UA. SIP request reaches the UA.
7. Grammar 7. Grammar
7.1. 555 (Push Notification Service Not Supported) Response Code 7.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, or that the service identified in a 'pn-provider' SIP URI parameter.
server failed to request a push notification from the push
notification service.
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 to SIP requests initiating dialogs and responses responses.
to stand-alone SIP requests.
7.2. sip.pns Feature-Capability Indicator 7.2. 556 (Push Notification Failed) Response Code
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.
7.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 as defined in RFC 3840 ; tag-value as defined in RFC 3840
7.3. sip.vapid Feature-Capability Indicator 7.4. 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 as defined in RFC 3840 ; tag-value as defined in RFC 3840
7.4. sip.pnsreg Feature-Capability Indicator 7.5. 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 re-registration associated with the indicator expects to receive re-registration
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 expireation when the entity in seconds) before the registration expireation 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 as defined in RFC 3261 ; DIGIT as defined in RFC 3261
7.5. sip.pnsreg Media Feature Tag 7.6. 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, indciates that the SIP UA header field of a SIP REGISTER request, indciates that the SIP UA
associated with the tag is able to send re-registration REGISTER associated with the tag is able to send re-registration 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.
pns-mt = "+sip.pnsreg" pns-mt = "+sip.pnsreg"
7.6. SIP URI Parameters 7.7. 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 as defined in RFC 3261 ; pvalue as defined in RFC 3261
skipping to change at page 16, line 22 skipping to change at page 17, line 5
https://firebase.google.com/docs/cloud-messaging/concept-options https://firebase.google.com/docs/cloud-messaging/concept-options
11. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 11. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030
(Generic Event Delivery Using HTTP Push) (Generic Event Delivery Using HTTP Push)
When Firebase Cloud Messaging (FCM) is used, the PNS related URI When Firebase Cloud Messaging (FCM) is used, the PNS related URI
parameters are set as described below. parameters are set as described below.
The value of the pn-provider URI parameter is "webpush". The value of the pn-provider URI parameter is "webpush".
The value of the pn-param URI parameter is the push message The value of the pn-param URI parameter MUST NOT be used.
subscription resource URI.
The value of the pn-prid URI parameter is the push URI. The value of the pn-prid URI parameter is the push URI.
See RFC 8030 for more details: See RFC 8030 for more details:
https://tools.ietf.org/html/rfc8030 https://tools.ietf.org/html/rfc8030
Note that encryption for web push [RFC8291] is not used, therefore Note that encryption for web push [RFC8291] is not used, therefore
parameters for message encryption are not defined in this parameters for message encryption are not defined in this
specification. Web push permits the sending of a push message specification. Web push permits the sending of a push message
skipping to change at page 18, line 13 skipping to change at page 18, line 37
Reference: RFC XXXX Reference: RFC XXXX
13.1.3. pn-prid 13.1.3. pn-prid
Parameter Name: pn-prid Parameter Name: pn-prid
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
13.2. SIP Response Code 13.2. SIP Response Codes
13.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
13.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
13.3. SIP Global Feature-Capability Indicator 13.3. SIP Global Feature-Capability Indicator
13.3.1. sip.pns 13.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
 End of changes. 29 change blocks. 
68 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/