draft-ietf-sipcore-sip-push-05.txt   draft-ietf-sipcore-sip-push-06.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: August 17, 2018 Metaswitch Networks Expires: August 18, 2018 Metaswitch Networks
February 13, 2018 February 14, 2018
Push Notification with the Session Initiation Protocol (SIP) Push Notification with the Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-push-05 draft-ietf-sipcore-sip-push-06
Abstract Abstract
This document describes how a Push Notification Services (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) to the SIP entity that will request between the SIP User Agent (UA) and the SIP entity that will request
push notifications towards the UA, and to trigger such push push notifications towards the UA, and to trigger such push
notification requests. notification requests.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 17, 2018. This Internet-Draft will expire on August 18, 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 26 skipping to change at page 2, line 26
5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 7 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 7
5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 7 5.1. PNS Identifier . . . . . . . . . . . . . . . . . . . . . 7
5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 7 5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 7
5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 8
5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 8 5.3.1. REGISTER Request . . . . . . . . . . . . . . . . . . 8
5.3.2. Initial Request for Dialog or Stand-Alone Request . . 9 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 9
6. Network Address Translator (NAT) Considerations . . . . . . . 10 6. Network Address Translator (NAT) Considerations . . . . . . . 10
7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. 555 (Push Notification Service Not Supported) Response 7.1. 555 (Push Notification Service Not Supported) Response
Code . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 10 7.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 11
7.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 11 7.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 11
7.4. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 11 7.4. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 11
8. PNS Registration Requirements . . . . . . . . . . . . . . . . 12 8. PNS Registration Requirements . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . 12 Push Notification service . . . . . . . . . . . . . . . . . . 12
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 . . 13 Firebase Cloud Messaging (FCM) push notification service . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 14 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 14
12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 14 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 14
12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 14 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 14
12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 14 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 15
12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 14 12.2. SIP Response Code . . . . . . . . . . . . . . . . . . . 15
12.3. SIP Global Feature-Capability Indicator . . . . . . . . 15 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 15
12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 15 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 15
12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 15 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 16
12.4. PNS Sub-registry Establishment . . . . . . . . . . . . . 16 12.4. PNS Sub-registry Establishment . . . . . . . . . . . . . 16
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 application, 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
devices use the Apple Push Notification service (APNs) while Android devices use the Apple Push Notification service (APNs) while Android
devices use the Firebase Cloud Messaging (FCM) service. devices use the Firebase Cloud Messaging (FCM) service.
Because of the restrictions above, Session Initiation Protocol (SIP) Because of the restrictions above, Session Initiation Protocol (SIP)
User Agents (UAs) [RFC3261] can not be awoken, in order to send re- User Agents (UAs) [RFC3261] can not be awoken, in order to send re-
registration SIP REGISTER requests and to receive incoming SIP registration SIP REGISTER requests and to receive incoming SIP
requests, without using a PNS to awake the UA in order to perform requests, without using a PNS to awake the UA in order to perform
skipping to change at page 3, line 33 skipping to change at page 3, line 33
Also, without being able to use internal timers in order to awake Also, without being able to use internal timers in order to awake
applications, a UA will not be able to maintain connections e.g., applications, a UA will not be able to maintain connections e.g.,
using the SIP Outbound Mechanism [RFC5626], as it requires the UA to using the SIP Outbound Mechanism [RFC5626], as it requires the UA to
send periodic keep-alive messages. send periodic keep-alive messages.
This document describes how PNSs can be used to awake suspended UAs, This document describes how PNSs can be used to awake suspended UAs,
to be able to send re-registration REGISTER requests and to receive to be able to send re-registration REGISTER requests and to receive
incoming SIP requests. The document defines new SIP URI parameters incoming SIP requests. The document defines new SIP URI parameters
and new feature-capability indicators [RFC6809] that can be used in and new feature-capability indicators [RFC6809] that can be used in
SIP messages to indicate support of the mechanism defined in this SIP messages to indicate support of the mechanism defined in this
document, to exchange PNS information between the UA the SIP entity document, to exchange PNS information between the UA and the SIP
(realized as a SIP proxy in this document) that will request push entity (realized as a SIP proxy in this document) that will request
notifications towards the UA, and to trigger such push notification push notifications towards the UA, and to trigger such push
requests. notification requests.
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
skipping to change at page 5, line 43 skipping to change at page 5, line 43
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 a SIP UA registers with a PNS it receives a unique Push Resource When a SIP UA registers with a PNS it receives a unique Push Resource
ID (PRID), which is a value associated with the registration. ID (PRID), which is a value associated with the registration that can
be used to generate push notifications.
The format of the PRID may vary depending on the PNS. The format of the PRID may vary depending on the PNS.
The details regarding discovery of the PNS, and the procedures The details regarding discovery of the PNS, and the procedures
regarding the push notification registration and maintenance are regarding the push notification registration and maintenance are
outside the scope of this document. The information needed to outside the scope of this document. The information needed to
contact the PNS is typically pre-configured in the operating system contact the PNS is typically pre-configured in the operating system
of the device. of the device.
4. SIP User Agent (UA) Behavior 4. SIP User Agent (UA) Behavior
skipping to change at page 7, line 12 skipping to change at page 7, line 13
re-registration REGISTER request. Note that, in some cases, the PNS re-registration REGISTER request. Note that, in some cases, the PNS
might update the PRID value, in which case the UA will include the might update the PRID value, in which case the UA will include the
new value in the pn-prid SIP URI parameter in the re-registration new value in the pn-prid SIP URI parameter in the re-registration
REGISTER request. REGISTER request.
If the UA no longer wants to receive push notifications (requested by If the UA no longer wants to receive push notifications (requested by
the proxy), the UA MUST send a re-registration REGISTER request the proxy), the UA MUST send a re-registration REGISTER request
without including the SIP URI parameters described above, or the UA without including the SIP URI parameters described above, or the UA
MUST remove the registration. MUST remove the registration.
If a UA's subscription to a PNS (and the associated PRID) is only
valid for a limited time then the UA is responsible for retrieving
new subscription details from the PNS and sending a REGISTER request
with the updated pn parameters to the proxy prior to the expiry of
the existing subscription. If a UA's subscription to a PNS expires
then the UA MUST send a REGISTER without the pn parameters (to tell
the proxy that it no longer wants push notifications) or terminate
the registration. The exact mechanisms for expiry and renewal of
PRIDs will be PNS-specific and are outside the scope of this
document.
For privacy and security reasons, the UA MUST NOT include the SIP URI For privacy and security reasons, the UA MUST NOT include the SIP URI
parameters defined in this document in non-REGISTER request, to parameters defined in this document in non-REGISTER request, to
prevent the PNS information associated with the UA from reaching the prevent the PNS information associated with the UA from reaching the
remote peer. For example, the UA MUST NOT include the SIP URI remote peer. For example, the UA MUST NOT include the SIP URI
parameters in the Contact header field of an INVITE request. parameters in the Contact header field of an INVITE request.
5. SIP Proxy Behavior 5. SIP Proxy Behavior
5.1. PNS Identifier 5.1. PNS Identifier
The PNS is identified by the pn-provider SIP URI parameter. The PNS is identified by the pn-provider SIP URI parameter.
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 other
mechanism. Such mechanisms are outside the scope of this document. mechanism. 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.
skipping to change at page 8, line 40 skipping to change at page 8, line 52
a downstream proxy supports the PNS) or send a SIP 555 (Push a downstream proxy supports the PNS) or send a SIP 555 (Push
Notification Service Not Supported) response to the REGISTER request. Notification Service Not Supported) response to the REGISTER request.
If the proxy sends a SIP 555 (Push Notification Service Not If the proxy sends a SIP 555 (Push Notification Service Not
Supported) response, the proxy SHOULD insert a Feature-Caps header Supported) response, the proxy SHOULD insert a Feature-Caps header
field with a 'sip.pns' feature-capability indicator in the response, field with a 'sip.pns' feature-capability indicator in the response,
identifying each PNS that the proxy supports. identifying each PNS that the proxy supports.
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 in the REGISTER request before 'sip.pns' feature-capability indicator in the REGISTER request before
forwarding the REGISTER request (in case the proxy is not the forwarding the REGISTER request (unless the proxy is the registrar,
registrar, in which case the proxy will terminate the REGISTER in which case the proxy will terminate the REGISTER request). This
request). This will inform downstream proxies that the proxy will inform downstream proxies that the proxy supports, and will
supports, and will request, push notifications towards the UA. 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),
when the proxy receives (or, in case the proxy is the SIP registrar, when 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
skipping to change at page 9, line 34 skipping to change at page 9, line 45
towards the UA, using the PRID included in the pn-prid SIP URI towards the UA, using the PRID included in the pn-prid SIP URI
parameter and the PNS identified by the pn-provider SIP URI parameter and the PNS identified by the pn-provider SIP URI
parameter. parameter.
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 forwards 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 and Request-URI do not match, normal SIP procedures. If the contact and Request-URI do not match,
the proxy MUST reject the SIP request with a 404 (Not Found) the proxy MUST reject the SIP request with a 404 (Not Found)
response. response.
In case of non-2xx response to the REGISTER request, theproxy 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 555 (Push Notification Service Not Supported) 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.
The proxy MUST NOT include the SIP request as payload in the The proxy MUST NOT include the SIP request as payload in the
requested push message. requested push message.
If the proxy has knowledge that the UA is awake, and that the UA is If the proxy has knowledge that the UA is awake, and that the UA is
able to receive the SIP request without first sending a REGISTER able to receive the SIP request without first sending a REGISTER
request, the proxy MAY choose to not request a push notification request, the proxy MAY choose to not request a push notification
towards the UA (and wait for the associated REGISTER request and 2xx towards the UA (and wait for the associated REGISTER request and 2xx
response) before it tries to forward the SIP request towards the UA. response) before it tries to forward the SIP request towards the UA.
The mechanisms for getting such knowledge assumption might be The mechanisms for getting such knowledge might be dependent on
dependent on implementation or deployment architecture, and are implementation or deployment architecture, and are outside the scope
outside the scope of this document. 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 sending the re- for an incoming SIP request to reach the UA. By sending the re-
registration SIP REQUEST the UA will establish such NAT binding. registration SIP REQUEST the UA will establish such a 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 identified in a 'pn-provider' SIP URI parameter, or that the service identified in a 'pn-provider' SIP URI parameter, or that the
server failed to request a push notification from the push server failed to request a push notification from the push
notification service. 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, responses to SIP requests initiating dialogs and responses
to stand-alone SIP requests. to stand-alone SIP requests.
7.2. sip.pns Feature-Capability Indicator 7.2. sip.pns Feature-Capability Indicator
The sip.pns feature-capability indicator is used in a SIP request, or The sip.pns feature-capability indicator is used in a SIP request, or
in a SIP 2xx response to a REGISTER request, that the entity in a SIP 2xx response to a REGISTER request, to indicate that the
associated with the indicator supports, and will use, the push entity associated with the indicator supports, and will use, the push
notification service identified by the indicator value. The feature- notification service identified by the indicator value. The feature-
capability indicator is used in a SIP 555 (Push Notification Service capability indicator is used in a SIP 555 (Push Notification Service
Not Supported) response to a REGISTER request to indicate which push Not Supported) response to a REGISTER request to indicate which push
notification services the entity associated with the indicator notification services the entity associated with the indicator
supports. The values defined for the pn-provider SIP URI parameter supports. The values defined for the pn-provider SIP URI parameter
are used. are used.
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
skipping to change at page 12, line 32 skipping to change at page 12, line 47
related SIP URI parameters are set as described below. related SIP URI parameters are set as described below.
The value of the pn-provider URI parameter is "apns". The value of the pn-provider URI parameter is "apns".
Example: pn-provider = apns Example: pn-provider = apns
The value of the pn-param URI parameter is the APNs App ID, 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 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 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 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. that will match a single application or a group of applications.
Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp
The value of the pn-prid URI parameter is the device token, which is 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
 End of changes. 21 change blocks. 
31 lines changed or deleted 42 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/