draft-ietf-sipcore-sip-push-01.txt   draft-ietf-sipcore-sip-push-02.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track December 19, 2017 Intended status: Standards Track December 21, 2017
Expires: June 22, 2018 Expires: June 24, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-01 draft-ietf-sipcore-sip-push-02
Abstract Abstract
This document describes how push notification mechanisms can be used This document describes how push notification mechanisms can be used
to wake up suspended Session Initiation Protocol (SIP) User Agents to wake up suspended Session Initiation Protocol (SIP) User Agents
(UAs), in order to be able to receive and generate SIP requests. The (UAs), in order to be able to receive and generate SIP requests. The
document defines new SIP URI parameters, that can be used in a SIP document defines new SIP URI parameters, that can be used in a SIP
REGISTER request to provide push notification information from the REGISTER request to provide push notification information from the
SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in
this document) that will send a push request to the push server in this document) that will send a push request to the push server in
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 June 22, 2018. This Internet-Draft will expire on June 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 5 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 5
4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 5 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 5
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 6 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 6
5.1. PNS Provider Information . . . . . . . . . . . . . . . . 6 5.1. PNS Provider Information . . . . . . . . . . . . . . . . 6
5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 6 5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 6
5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 7
6. Network Address Translator (NAT) Considerations . . . . . . . 7 6. Network Address Translator (NAT) Considerations . . . . . . . 8
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. 555 (Push Notification Service Not Supported) Response 7.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 8
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 8 7.3. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 8
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 8 Push Notification service . . . . . . . . . . . . . . . . . . 9
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 . . 9 Firebase Cloud Messaging (FCM) push notification service . . 10
11. Security considerations . . . . . . . . . . . . . . . . . . . 9 11. Security considerations . . . . . . . . . . . . . . . . . . . 10
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 10 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 11
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 10 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 11
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 10 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 11
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 10 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 11
12.1.4. pn-enckey . . . . . . . . . . . . . . . . . . . . . 11 12.1.4. pn-enckey . . . . . . . . . . . . . . . . . . . . . 12
12.1.5. pn-enccode . . . . . . . . . . . . . . . . . . . . . 11 12.1.5. pn-enccode . . . . . . . . . . . . . . . . . . . . . 12
12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 11 12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 12
12.3. PNS Sub-registry Establishment . . . . . . . . . . . . . 11 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.4. PNS Sub-registry Establishment . . . . . . . . . . . . . 13
13.1. Normative references . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
13.2. Informative references . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 14.1. Normative references . . . . . . . . . . . . . . . . . . 14
14.2. Informative references . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In order to save resources (e.g, battery life) some devices and In order to save resources (e.g, battery life) some devices and
operating systems require suspended Session Initiation Protocol (SIP) operating systems require suspended Session Initiation Protocol (SIP)
User Agents (UAs) [RFC3261] to be woken up using a push notification User Agents (UAs) [RFC3261] to be woken up using a push notification
service. Typically each operating system uses a dedicated push service. Typically each operating system uses a dedicated push
notification service. For example, Apple iOS devices use the Apple notification service. For example, Apple iOS devices use the Apple
Push Notification service (APNs). Push Notification service (APNs).
skipping to change at page 5, line 35 skipping to change at page 5, line 35
(using the protocol and procedures associated with the PNS), and when (using the protocol and procedures associated with the PNS), and when
the UA wants to receive push notifications triggered by the SIP the UA wants to receive push notifications triggered by the SIP
proxy, the UA MUST send a SIP REGISTER using normal SIP registration proxy, the UA MUST send a SIP REGISTER using normal SIP registration
procedures. The UA MUST add a pn-provider, a pn-prid and a pn-param procedures. The UA MUST add a pn-provider, a pn-prid and a pn-param
(if required for the specific PNS provider) SIP URI parameter to the (if required for the specific PNS provider) SIP URI parameter to the
SIP Contact header field URI of the request. The pn-provider URI SIP Contact header field URI of the request. The pn-provider URI
parameter contains the PNS provider, the pn-prid URI parameter parameter contains the PNS provider, 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.
When the SIP UA receives a 200 (OK) response to the SIP REGISTER
request, if the response does not contain a Feature-Caps header field
with a '+sip.pns' header field parameter, or if the response contains
a Feature-Caps header field with a '+sip.pns' header field parameter
with a parameter value that the UA does not support, the UA cannot
assume that push notifications will be triggered by a SIP proxy. The
actions taken by the UA might be dependent on implementation or
deployment architecture, and are outside the scope of this document.
When the SIP UA receives a push notification, it MUST perform a SIP When the SIP UA receives a push notification, it MUST perform a SIP
re-registration [RFC3261] by sending a SIP REGISTER request. If re-registration [RFC3261] by sending a SIP REGISTER request. If
there are Network Address Translators (NATs) between the SIP UA and there are Network Address Translators (NATs) between the SIP UA and
the SIP proxy, the REGISTER request will create NAT bindings allowing the SIP proxy, the REGISTER request will create NAT bindings allowing
incoming SIP requests to reach the UA. If the SIP proxy triggered incoming SIP requests to reach the UA. If the SIP proxy triggered
the push notification because it wants to forward a SIP request the push notification because it wants to forward a SIP request
towards the UA, the receival of the REGISTER request can be used by towards the UA, the receipt of the REGISTER request can be used by
the proxy as a trigger to forward the request. the proxy as a trigger to forward the request.
As long as the SIP UA wants the SIP proxy to continue sending push As long as the SIP UA wants the SIP proxy to continue sending push
requests, the UA MUST include a pn-provider, pn-prid and a pn-param requests, the UA MUST include a pn-provider, pn-prid and a pn-param
(if required for the specific PNS provider) SIP URI parameter in (if required for the specific PNS provider) SIP URI parameter in
every re-registration SIP REGISTER request sent towards the proxy. every re-registration SIP REGISTER request sent towards the proxy.
Note that, in some cases, the PNS might update the PRID value, in Note that, in some cases, the PNS might update the PRID value, in
which case the pn-prid URI parameter within the re-registration which case the pn-prid URI parameter within the re-registration
REGISTER request will contain the new value. REGISTER request will contain the new value.
skipping to change at page 6, line 47 skipping to change at page 7, line 10
When the SIP proxy receives an indication that the SIP UA needs to When the SIP proxy receives an indication that the SIP UA needs to
perform a re-registration, the proxy triggers a push request towards perform a re-registration, the proxy triggers a push request towards
the push notification server associated with the PRID. the push notification server associated with the PRID.
5.3. SIP Request 5.3. SIP Request
When the SIP proxy receives a SIP REGISTER request that contains a When the SIP proxy receives a SIP REGISTER request that contains a
pn-provider SIP URI parameter value that the proxy does not support, pn-provider SIP URI parameter value that the proxy does not support,
or if the REGISTER request does not contain all information required or if the REGISTER request does not contain all information required
for the specific PNS provider, the proxy MUST NOT forward the for the specific PNS provider, the proxy MUST either forward the
REGISTER request. If the proxy is aware of another proxy that request (e.g., if the proxy is aware of another proxy that supports
supports the PNS provider, the proxy MAY redirect the SIP request the PNS provider) or send a SIP 555 (Push Notification Service Not
(using a SIP 3xx response code) to that proxy. Otherwise the proxy Supported) response to the REGISTER request. If the proxy sends a
MUST send a SIP 555 (Push Notification Service Not Supported) SIP 555 (Push Notification Service Not Supported), the proxy SHOULD
response to the REGISTER request. insert a Feature-Caps header field with a '+sip.pns' header field
parameter in the response, indicating the PNS supported by the proxy.
If the SIP proxy supports the pn-provider SIP URI parameter value,
when the proxy receives (or, in case the proxy is the SIP registrar,
creates) a 200 (OK) response to the REGISTER request, the proxy MUST
insert a Feature-Caps header field with a '+sip.pns' header field
parameter in the response, in order to inform the SIP UA that the
proxy supports the PNS indicated by the pn-provider SIP URI parameter
value.
When the SIP proxy receives (or, in case the proxy is the SIP When the SIP proxy receives (or, in case the proxy is the SIP
registrar, creates) a SIP request for a new dialog (e.g., a SIP registrar, creates) a SIP request for a new dialog (e.g., a SIP
INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE
request) aimed for a SIP UA, if the Request-URI of the request request) aimed for a SIP UA, if the Request-URI of the request
contains a pn-provider, a pn-prid and a pn-param (if required for the contains a pn-provider, a pn-prid and a pn-param (if required for the
specific PNS provider) SIP URI parameter, the proxy triggers a push specific PNS provider) SIP URI parameter, the proxy triggers a push
request towards the PNS associated with the PRID. After that, the request towards the PNS associated with the PRID. After that, the
proxy forwards the SIP request towards the UA using normal SIP proxy forwards the SIP request towards the UA using normal SIP
procedures. procedures.
As the push notification will trigger the SIP UA to perform a re- As the push notification will trigger the SIP UA to perform a re-
registration, the SIP proxy can use the receival of the SIP REGISTER registration, the SIP proxy can use the receipt of the SIP REGISTER
request as a trigger to forward SIP request towards the UA. request as a trigger to forward SIP request towards the UA.
The SIP proxy MUST NOT transport the SIP request as push request The SIP proxy MUST NOT transport the SIP request as push request
payload, instead of forwarding the request using normal SIP payload, instead of forwarding the request using normal SIP
procedures. procedures.
If the SIP proxy is not able to contact the push notification If the SIP proxy is not able to contact the push notification
provider, or even retrieve the PNS provider, the proxy SHOULD reject provider, or even retrieve the PNS provider, the proxy SHOULD reject
the SIP request. the SIP request.
If the SIP proxy is able to assume that the SIP UA is awake, and that If the SIP proxy is able to assume that the SIP UA is awake, and that
the UA is able to receive the SIP request, the proxy MAY choose to the UA is able to receive the SIP request, the proxy MAY choose to
not trigger a push notification request before trying to forward the not trigger a push notification request before trying to forward the
SIP request towards the UA. The proxy can make such assumption e.g., SIP request towards the UA. The mechanisms for making such
if a TLS connection previously established by the UA is still open. assumption might be dependent on implementation or deployment
architecture, and are outside the scope of this document.
6. Network Address Translator (NAT) Considerations 6. Network Address Translator (NAT) Considerations
Whenever the SIP UA receives a push notification, if the UA is Whenever the SIP UA receives a push notification, if the UA is
located behind a Network Address Translator (NAT), the UA might need located behind a Network Address Translator (NAT), the UA might need
to take actions in order to establish a binding in the NAT, in order to take actions in order to establish a binding in the NAT, in order
for an incoming SIP request to reach the UA. By performing the re- for an incoming SIP request to reach the UA. By performing the re-
registration the UA will establish such NAT binding. registration the UA will establish such NAT binding.
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 specified in a 'pn-provider' SIP URI parameter. service specified in a 'pn-provider' SIP URI parameter.
7.2. Syntax The use of the SIP 555 response code is defined for SIP REGISTER
responses. Usage with other SIP methods is undefined.
7.2. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator is used in a SIP 555 (Push
Notficiation Service Not Supported) response to indicate which push
notification services the sender of the response supports.
sip.pns = "<" pns-list ">"
pns-list = pns *(COMMA pns)
pns = pvalue
; pvalue as defined in RFC 3261
The value of the pns is identical to the corresponding pn-provider
SIP URI parameter for the push notification service associated with
the value.
7.3. 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 / pn-enccode / uri-parameter =/ pn-provider / pn-param / pn-prid / pn-enccode /
pn-enckey pn-enckey
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
pn-enccode = "pn-enccode" EQUAL pvalue pn-enccode = "pn-enccode" EQUAL pvalue
skipping to change at page 11, line 33 skipping to change at page 12, line 28
Reference: RFC XXXX Reference: RFC XXXX
12.2. SIP Response Code 12.2. SIP Response Code
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
12.3. PNS Sub-registry Establishment 12.3. SIP Global Feature-Capability Indicator
This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" sub-registry
[RFC6809] under the sip-parameters registry:
http://www.iana.org/assignments/sip-parameters.
Name: sip.pns
Description: This feature-capability indicator, when included in a
Feature-Caps header field of a REGISTER response, indicates that
the server supports the SIP push mechanism. The value is a list
of the push notification services supported by the server.
Reference: [RFCXXXX]
12.4. PNS Sub-registry Establishment
This section creates a new sub-registry, "PNS", under the sip- This section creates a new sub-registry, "PNS", under the sip-
parameters registry: http://www.iana.org/assignments/sip-parameters. parameters registry: http://www.iana.org/assignments/sip-parameters.
The purpose of the sub-registry is to register SIP URI pn-provider The purpose of the sub-registry is to register SIP URI pn-provider
values. values.
This sub-registry is defined as a table that contains the following This sub-registry is defined as a table that contains the following
three columns: three columns:
skipping to change at page 12, line 22 skipping to change at page 13, line 39
Document: A reference to the document defining the registration Document: A reference to the document defining the registration
This specification registers the following values: This specification registers the following values:
Value Description Document Value Description Document
------- ---------------------------------- ---------- ------- ---------------------------------- ----------
apns Apple Push Notification service [RFC XXXX] apns Apple Push Notification service [RFC XXXX]
fcm Firebase Cloud Messaging [RFC XXXX] fcm Firebase Cloud Messaging [RFC XXXX]
13. References 13. Acknowledgements
13.1. Normative references Thanks to Mickey Arnold, Paul Kyzivat, Dale Worley, Ranjit Avasarala,
Martin Thomson, Mikael Klein, Susanna Sjoholm and Kari-Pekka Perttula
for reading the text, and providing useful feedback.
14. References
14.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority [RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter (IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)", Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004,
<https://www.rfc-editor.org/info/rfc3969>. <https://www.rfc-editor.org/info/rfc3969>.
[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
Indicate Support of Features and Capabilities in the
Session Initiation Protocol (SIP)", RFC 6809,
DOI 10.17487/RFC6809, November 2012, <https://www.rfc-
editor.org/info/rfc6809>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030, Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016, <https://www.rfc- DOI 10.17487/RFC8030, December 2016, <https://www.rfc-
editor.org/info/rfc8030>. editor.org/info/rfc8030>.
13.2. Informative references 14.2. Informative references
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291,
DOI 10.17487/RFC8291, November 2017, <https://www.rfc- DOI 10.17487/RFC8291, November 2017, <https://www.rfc-
editor.org/info/rfc8291>. editor.org/info/rfc8291>.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
 End of changes. 19 change blocks. 
41 lines changed or deleted 111 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/