draft-ietf-sipcore-sip-push-00.txt   draft-ietf-sipcore-sip-push-01.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track December 13, 2017 Intended status: Standards Track December 19, 2017
Expires: June 16, 2018 Expires: June 22, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-00 draft-ietf-sipcore-sip-push-01
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 16, 2018. This Internet-Draft will expire on June 22, 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 15 skipping to change at page 2, line 15
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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. Push Notification 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 . . . . . . . . . . . . . . . . . . . . . . . 6
6. Network Address Translator (NAT) Considerations . . . . . . . 7 6. Network Address Translator (NAT) Considerations . . . . . . . 7
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 8 8. PNS Registration Requirements . . . . . . . . . . . . . . . . 8
9. pn-prid and pn-type URI parameters for Apple Push 9. pn-provider, pn-param and pn-prid URI parameters for Apple
Notification service . . . . . . . . . . . . . . . . . . . . 8 Push Notification service . . . . . . . . . . . . . . . . . . 8
10. pn-prid and pn-type URI parameters for Google Firebase Cloud 10. pn-provider, pn-param and pn-prid URI parameters for Google
Messaging (FCM) push notification service . . . . . . . . . . 9 Firebase Cloud Messaging (FCM) push notification service . . 9
11. Security considerations . . . . . . . . . . . . . . . . . . . 9 11. Security considerations . . . . . . . . . . . . . . . . . . . 9
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
12.1. pn-prid . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 10
12.2. pn-type . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 10
12.3. pn-enckey . . . . . . . . . . . . . . . . . . . . . . . 10 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 10
12.4. pn-enccode . . . . . . . . . . . . . . . . . . . . . . . 10 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 10
12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 11 12.1.4. pn-enckey . . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1.5. pn-enccode . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative references . . . . . . . . . . . . . . . . . . 11 12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 11
13.2. Informative references . . . . . . . . . . . . . . . . . 12 12.3. PNS Sub-registry Establishment . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative references . . . . . . . . . . . . . . . . . . 12
13.2. Informative references . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
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 3, line 14 skipping to change at page 3, line 19
This document describes how push notification mechanisms can be used This document describes how push notification mechanisms can be used
to wake up suspended SIP UAs, in order to be able to receive and to wake up suspended SIP UAs, in order to be able to receive and
generate SIP requests. The document defines new SIP URI parameters, generate SIP requests. The document defines new SIP URI parameters,
that can be used in a SIP REGISTER request to provide push that can be used in a SIP REGISTER request to provide push
notification information from the SIP UA to the SIP entity (realized notification information from the SIP UA to the SIP entity (realized
as a SIP proxy in this document) that will send a push request to the as a SIP proxy in this document) that will send a push request to the
push server in order to trigger a push notification towards the SIP push server in order to trigger a push notification towards the SIP
UA. UA.
When a SIP UA registers to a push service, it will receive a unique When a SIP UA registers to a Push Notification Service (PNS), it will
Push Resource ID (PRID) associated to that registration. The SIP UA receive a unique Push Resource ID (PRID) associated to that
will provide the PRID to the SIP network in a SIP REGISTER request. registration. The SIP UA will provide the PRID to the SIP network in
A SIP proxy (e.g., the SIP registrar) will store a mapping between a SIP REGISTER request. A SIP proxy (e.g., the SIP registrar) will
the registered contact and the PRID. store a mapping between the registered contact and the PRID.
When the SIP proxy receives a SIP request for a new session, or a When the SIP proxy receives (or, in case the SIP proxy is also
stand-alone SIP request, addressed towards a SIP UA, or when the SIP registrar, initiates) a SIP request for a new session, or a stand-
proxy determines that the SIP UA needs to perform a re-registration, alone SIP request, addressed towards a SIP UA, or when the SIP proxy
the SIP proxy will send a push request to the push notification determines that the SIP UA needs to perform a re-registration, the
service used by the SIP UA, using the push resource ID associated SIP proxy will send a push request to the push notification service
with the registered contact of the SIP UA, in order to trigger a push used by the SIP UA, using the push resource ID associated with the
registered contact of the SIP UA, in order to trigger a push
notification towards the SIP UA. The SIP proxy will then forward the notification towards the SIP UA. The SIP proxy will then forward the
SIP request towards the SIP UA using normal SIP routing procedures. SIP request towards the SIP UA using normal SIP routing procedures.
Once the SIP UA receives the push notification, it will be to receive Once the SIP UA receives the push notification, it will be to receive
the SIP request, and to generate a SIP request (e.g., a SIP REGISTER) the SIP request, and to generate a SIP request (e.g., a SIP REGISTER)
itself. itself.
Different push notification mechanisms exist today. Some are based Different push notification mechanisms exist today. Some are based
on there standardized mechanism defined in [RFC8030], while others on there standardized mechanism defined in [RFC8030], while others
are proprietary (e.g., the Apple Push Notification service). are proprietary (e.g., the Apple Push Notification service).
Figure 1 shows the generic push notification architecture supported Figure 1 shows the generic push notification architecture supported
skipping to change at page 4, line 37 skipping to change at page 4, line 37
======= SIP ======= SIP
REGISTER sip:alice@example.com SIP/2.0 REGISTER sip:alice@example.com SIP/2.0
Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
To: Alice <sip:alice@example.com> To: Alice <sip:alice@example.com>
From: Alice <sip:alice@example.com>;tag=456248 From: Alice <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09 Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER CSeq: 1826 REGISTER
Contact: <sip:alice@alicemobile.example.com; Contact: <sip:alice@alicemobile.example.com;
pn-type=acme:acme-param; pn-provider=acme;
pn-param=acme-param;
pn-prid="ZTY4ZDJlMzODE1NmUgKi0K"> pn-prid="ZTY4ZDJlMzODE1NmUgKi0K">
Expires: 7200 Expires: 7200
Content-Length: 0 Content-Length: 0
Figure 1: SIP Push Notification Architecture Figure 1: SIP Push Notification Architecture
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Push Resource ID (PRID) 3. Push Resource ID (PRID)
When an entity registers with a Push Notification Server (PNS) it When an entity registers with a PNS it receives a unique Push
receives a unique Push Resource ID (PRID), which is a value Resource ID (PRID), which is a value associated with the
associated with the registration. registration.
The format of the PRID may vary depending on the PNS provider. The The format of the PRID may vary depending on the PNS provider. The
PRID may be part of a URI that can be used to retrieve the address PRID may be part of a URI that can be used to retrieve the address
and port of the PNS when sending push requests to the PNS. The PRID and port of the PNS when sending push requests to the PNS. The PRID
may also be a token value, in which case the address and port of the may also be a token value, in which case the address and port of the
PNS needs to be provided using other means. PNS needs to be provided using other means.
The details regarding discovery of the PNS, and the procedures for The details regarding discovery of the PNS, and the procedures for
the push notification registration and maintenance are outside the the push notification registration and maintenance are outside the
scope of this document. The information needed to contact the PNS is scope of this document. The information needed to contact the PNS is
typically pre-configured in the operating system (OS) of the device. typically pre-configured in the operating system (OS) of the device.
4. SIP User Agent (UA) Behavior 4. SIP User Agent (UA) Behavior
Once the SIP UA has registered with the PNS and received the PRID, Once the SIP UA has registered with the PNS and received the PRID
and when the UA wants to receive push notifications triggered by the (using the protocol and procedures associated with the PNS), and when
SIP proxy, the UA MUST send a SIP REGISTER using normal SIP the UA wants to receive push notifications triggered by the SIP
registration procedures. The UA MUST add a pn-prid URI parameter and proxy, the UA MUST send a SIP REGISTER using normal SIP registration
a pn-type URI parameter to the SIP Contact header field URI of the procedures. The UA MUST add a pn-provider, a pn-prid and a pn-param
request. The pn-prid URI parameter contains the PRID value. The pn- (if required for the specific PNS provider) SIP URI parameter to the
type contains additional, PNS-specific, information. SIP Contact header field URI of the request. The pn-provider URI
parameter contains the PNS provider, the pn-prid URI parameter
contains the PRID value and the pn-param URI parameter contains
additional PNS-specific information.
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 SIP REGISTER request will create NAT bindings the SIP proxy, the REGISTER request will create NAT bindings allowing
allowing incoming SIP requests to reach the SIP UA. If the SIP proxy incoming SIP requests to reach the UA. If the SIP proxy triggered
triggered the push notification because it wants to forward a SIP the push notification because it wants to forward a SIP request
request towards the SIP UA, the receival of the SIP REGISTER request towards the UA, the receival of the REGISTER request can be used by
can be used by the SIP proxy as a trigger to forward the SIP request. the proxy as a trigger to forward the request.
As long as the 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 the pn-prid and pn-type URI parameters requests, the UA MUST include a pn-provider, pn-prid and a pn-param
in every re-registration SIP REGISTER request sent towards the SIP (if required for the specific PNS provider) SIP URI parameter in
proxy. Note that, in some cases, the PNS might update the PRID every re-registration SIP REGISTER request sent towards the proxy.
value, in which case the re-registration SIP REGISTER request will Note that, in some cases, the PNS might update the PRID value, in
contain the new value. which case the pn-prid URI parameter within the re-registration
REGISTER request will contain the new value.
If the SIP UA at some point wants to stop the SIP proxy from sending If the SIP UA at some point wants to stop the SIP proxy from sending
push requests, the SIP UA MUST send a SIP REGISTER request without push requests, the UA MUST send a SIP REGISTER request without the
the pn-prid and pn-type URI parameters. URI parameters described above.
If the SIP UA expects to receive payload in the push notification, If the SIP UA expects to receive payload in the push notification,
the SIP UA MAY add a pn-enckey and a pn-encsec Contact header field the UA MAY add a pn-enckey and a pn-encsec SIP Contact header field
URI parameter, in order to allow encryption of the data using the SIP URI parameter, in order to allow encryption of the data using the
mechanism in [RFC8291]. The pn-enckey URI parameter contains the mechanism in [RFC8291]. The pn-enckey URI parameter contains the
public key, and the pn-encsec URI parameter contains the public key, and the pn-encsec URI parameter contains the
authentication secret [RFC8291]. authentication secret [RFC8291].
NOTE: End-to-end encryption of the payload between the SIP proxy and NOTE: End-to-end encryption of the payload between the SIP proxy and
the SIP UA cannot be used if the push notification request payload the SIP UA cannot be used if the push notification request payload
contains information that needs to be accessible by the push contains information that needs to be accessible by the PNS provider.
notification server.
5. SIP Proxy Behavior 5. SIP Proxy Behavior
5.1. Push Notification Provider Information 5.1. PNS Provider Information
In some cases the push notification provider can be retrieved from The PNS provider is retrieved from the pn-provider SIP URI parameter.
the pn-prid URI parameter. In other cases the pn-type URI parameter
is used to identity the push notification provider.
The protocol and format used for the push request depends on the push The protocol and format used for the push request depends on the PNS
notification provider, and the details for constructing and sending provider, and the details for constructing and sending the messages
the messages are outside the scope of this specification. are outside the scope of this specification.
5.2. Trigger Periodic Re-registration 5.2. Trigger Periodic Re-registration
If the SIP UA needs to perform periodic re-registrations, the SIP If the SIP UA needs to perform periodic re-registrations, the proxy
proxy needs to have information about when those re-registrations are needs to have information about when those re-registrations are to be
to be performed. The SIP proxy either needs to contain the SIP performed. The proxy either needs to contain the SIP registrar
registrar functionality, or the SIP proxy needs to retreive the functionality, or the proxy needs to retrieve the information from
information from the registrar using some other mechanism. the registrar using some other mechanism.
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 SIP proxy triggers a push request perform a re-registration, the proxy triggers a push request towards
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 request for a new dialog (e.g., a When the SIP proxy receives a SIP REGISTER request that contains a
SIP INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE pn-provider SIP URI parameter value that the proxy does not support,
or if the REGISTER request does not contain all information required
for the specific PNS provider, the proxy MUST NOT forward the
REGISTER request. If the proxy is aware of another proxy that
supports the PNS provider, the proxy MAY redirect the SIP request
(using a SIP 3xx response code) to that proxy. Otherwise the proxy
MUST send a SIP 555 (Push Notification Service Not Supported)
response to the REGISTER request.
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
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-prid URI parameter, the SIP proxy triggers a push contains a pn-provider, a pn-prid and a pn-param (if required for the
request towards the push notification server associated with the specific PNS provider) SIP URI parameter, the proxy triggers a push
PRID. After that, the SIP proxy forwards the SIP request towards the request towards the PNS associated with the PRID. After that, the
SIP UA using normal SIP procedures. proxy forwards the SIP request towards the UA using normal SIP
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 receival of the SIP REGISTER
request as a trigger to forward SIP request towards the SIP 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 proxy is not able to contact the push notification provider, If the SIP proxy is not able to contact the push notification
or even determine which push notification provider to contact, it provider, or even retrieve the PNS provider, the proxy SHOULD reject
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 SIP UA is able to receive the SIP request, the SIP proxy MAY the UA is able to receive the SIP request, the proxy MAY choose to
choose to not trigger a push notification request before trying to not trigger a push notification request before trying to forward the
forward the SIP request towards the SIP UA. The SIP proxy can make SIP request towards the UA. The proxy can make such assumption e.g.,
such assumption e.g., if a TLS connection previously established by if a TLS connection previously established by the UA is still open.
the SIP UA is still open.
6. Network Address Translator (NAT) Considerations 6. Network Address Translator (NAT) Considerations
Whenever the UA receives a push notification, if the SIP 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 SIP 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
The 555 response code is added to the "Server-Error" Status-Code
definition. 555 (Push Notification Service Not Supported) is used to
indicate that the server did not support the push notification
service specified in a 'pn-provider' SIP URI parameter.
7.2. Syntax
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-prid / pn-type / pn-enccode / pn-enckey uri-parameter =/ pn-provider / pn-param / pn-prid / pn-enccode /
pn-enckey
pn-provider = "pn-provider" EQUAL pvalue
pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" EQUAL pvalue pn-prid = "pn-prid" EQUAL pvalue
pn-type = "pn-type" EQUAL pns-provider COLON pns-param
pn-enccode = "pn-enccode" EQUAL pvalue pn-enccode = "pn-enccode" EQUAL pvalue
pn-enckey = "pn-enckey" EQUAL pvalue pn-enckey = "pn-enckey" EQUAL pvalue
pns-provider = pvalue ; Colon (":") characters MUST be escaped
pns-param = pvalue ; Colon (":") characters MUST be escaped
; pvalue as defined in RFC 3261 ; pvalue as defined in RFC 3261
; EQUAL as defined in RFC 3261 ; EQUAL as defined in RFC 3261
; COLON as defined in RFC 3261 ; COLON as defined in RFC 3261
The format and semantics of pns-param is specific to a given The format and semantics of pns-param is specific to a given
pns-provider value. pns-provider value.
8. PNS Registration Requirements 8. PNS Registration Requirements
When a new value is registered to the PNS Sub-registry, a reference When a new value is registered to the PNS Sub-registry, a reference
to a specification which describes the push notification service to a specification which describes the PNS associated with the value
associated with the value is provided. That specification MUST is provided. That specification MUST contain the following
contain the following information: information:
o How the values for the pn-prid parameter is retrieved and set by o The value of the pn-provider SIP URI parameter.
o How the pn-prid SIP URI parameter value is retrieved and set by
the SIP UA. the SIP UA.
o The format of the pns-param part of the pns-type parameter, and o How the pn-param SIP URI parameter (if required for the specific
how the value of the pns-param part is retrieved and set by the PNS provider) value is retrieved and set by the SIP UA.
SIP UA.
o Whether there are any restrictions regarding usage of payload o Whether there are any restrictions regarding usage of payload
encryption [RFC8291] with the associated push notification encryption [RFC8291] with the associated PNS.
service.
9. pn-prid and pn-type URI parameters for Apple Push Notification 9. pn-provider, pn-param and pn-prid URI parameters for Apple Push
service Notification service
When the Apple Push Notification service (APNs) is used, the value of When the Apple Push Notification service (APNs) is used, the PNS-
the pn-type URI parameter pns-provider parameter part is "apns". The related SIP URI parameters are set as described below.
pns-param part contains the APNs App ID, which is encoded by two
values, separated by a period (.): Team ID and Bundle ID. The Team
ID is provided by Apple and is unique to a development team. The
Bundle ID is unique to a development team, and is a string that will
can match a single application or a group of applications.
Example: pn-type = apns:DEF123GHIJ.com.yourcompany.yourexampleapp The value of the pn-provider URI parameter is "apns".
When the Apple Push Notification service (APNs) is used, pn-type URI Example: pn-provider = apns
parameter pns-prid parameter part contains the device token, which is The value of the pn-param URI parameter is the APNs App ID, which is
encoded by two values, separated by a period (.): Team ID and Bundle
ID. The Team ID is provided by Apple and is unique to a development
team. The Bundle ID is unique to a development team, and is a string
that will can match a single application or a group of applications.
Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp
The value of the pn-prid URI parameter is the device token, which is
a unique identifier assigned by Apple to a specific app on a specific a unique identifier assigned by Apple to a specific app on a specific
device. device.
Example: pn-prid = 00fc13adff78512 Example: pn-prid = 00fc13adff78512
For more information on the APNs App ID: For more information on the APNs App ID:
https://developer.apple.com/library/content/documentation/General/ https://developer.apple.com/library/content/documentation/General/
Conceptual/DevPedia-CocoaCore/AppID.html Conceptual/DevPedia-CocoaCore/AppID.html
For more information on the APNs device token: For more information on the APNs device token:
https://developer.apple.com/library/content/documentation/NetworkingI https://developer.apple.com/library/content/documentation/NetworkingI
nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re
f/doc/uid/TP40008194-CH8-SW13 f/doc/uid/TP40008194-CH8-SW13
10. pn-prid and pn-type URI parameters for Google Firebase Cloud 10. pn-provider, pn-param and pn-prid URI parameters for Google
Messaging (FCM) push notification service Firebase Cloud Messaging (FCM) push notification service
When Firebase Cloud Messaging (FCM) is used, the value of the pn-type When Firebase Cloud Messaging (FCM) is used, the PNS related URI
URI parameter pns-provider parameter part is "fcm". The pns-param parameters are set as described below.
part contains the Sender ID.
When Firebase Cloud Messaging (FCM) is used, pn-type URI parameter The value of the pn-provider URI parameter is "fcm".
pns-prid parameter part contains the Registration token, which
generated by the FCM SDK for each client app instance. The value of the pn-param URI parameter is the Sender ID.
The value of the pn-prid URI parameter is the Registration token,
which is generated by the FCM SDK for each client app instance.
For more information on the Sender ID and Registration token: For more information on the Sender ID and Registration token:
https://firebase.google.com/docs/cloud-messaging/concept-options https://firebase.google.com/docs/cloud-messaging/concept-options
11. Security considerations 11. Security considerations
In addition to the information exchanged between a device and its PNS In addition to the information exchanged between a device and its PNS
in order to establish a push notification subscription, the mechanism in order to establish a push notification subscription, the mechanism
in this document does not require entities to provide any additional in this document does not require entities to provide any additional
skipping to change at page 10, line 7 skipping to change at page 10, line 17
of the mechanism in this document MUST take measures to prevent push of the mechanism in this document MUST take measures to prevent push
notifications from being sent to a device from a malicious user. notifications from being sent to a device from a malicious user.
In case entities do want to include payload in the push In case entities do want to include payload in the push
notifications, this document defines the means for using end-to-end notifications, this document defines the means for using end-to-end
payload encryption between the entity sending the push request and payload encryption between the entity sending the push request and
the entity receiving the associated push notification. the entity receiving the associated push notification.
12. IANA considerations 12. IANA considerations
This specification defines new SIP URI parameters that extend the 12.1. SIP URI Parameters
registry created by [RFC3969]:
12.1. pn-prid This section defines new SIP URI Parameters that extend the "SIP/SIPS
URI Parameters" sub-registry [RFC3969] under the sip-parameters
registry: http://www.iana.org/assignments/sip-parameters.
Parameter Name: pn-prid 12.1.1. pn-provider
Parameter Name: pn-provider
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
12.2. pn-type 12.1.2. pn-param
Parameter Name: pn-type Parameter Name: pn-param
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
12.3. pn-enckey 12.1.3. pn-prid
Parameter Name: pn-prid
Predefined Values: No
Reference: RFC XXXX
12.1.4. pn-enckey
Parameter Name: pn-enckey Parameter Name: pn-enckey
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
12.4. pn-enccode 12.1.5. pn-enccode
Parameter Name: pn-enccode Parameter Name: pn-enccode
Predefined Values: No Predefined Values: No
Reference: RFC XXXX Reference: RFC XXXX
12.5. PNS Sub-registry Establishment 12.2. SIP Response Code
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: 555
Default Reason Phrase: Push Notification Service Not Supported
12.3. 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-type 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:
Value: The token under registration Value: The token under registration
Description: The name of the push notification service Description: The name of the Push Notification Service (PNS)
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]
 End of changes. 54 change blocks. 
133 lines changed or deleted 184 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/