RFC 8599
Push Notification with the Session Initiation Protocol (SIP)
6. Support of Long-Lived SIP Dialogs
Some SIP dialogs might have a long lifetime with little activity. For example, when the SIP event notification mechanism [RFC6665] is used, there might be a long period between the sending of mid-dialog requests. Because of this, a SIP UA may be suspended and may need to be awakened in order to be able to receive mid-dialog requests. SIP requests for a new dialog and standalone SIP requests addressed towards a UA with 'pn-*' SIP URI parameters allow the proxy to request that a push notification be sent to the UA (Section 5.6.2). However, 'pn-*' SIP URI parameters will not be present in mid-dialog requests addressed towards the UA. Instead, the proxy needs to support a mechanism to store the information needed to request that a push notification be sent to the UA, and to be able to retrieve that information when it receives a mid-dialog request addressed towards the UA. This section defines such a mechanism. The SIP UA and SIP proxy procedures in this section are applied in addition to the generic procedures defined in this specification. +--------+ +---------+ +-----------+ +-------------+ | | | | | | | SIP | | SIP UA | | Push | | SIP Proxy | | Registrar / | | | | Service | | | | Home Proxy | +--------+ +---------+ +-----------+ +-------------+ | | | | | PNS Register | | | |---------------->| | | | | | | | PRID | | | |<----------------| | | | | | | | SIP REGISTER (PRID) | | |===================================>| | | | |SIP REGISTER (PRID)| | | |==================>| | | | | | | +-----------------------+ | | | | Store PRID (key=PURR) | | | | +-----------------------+ | | | | | | | | SIP 200 OK | | | |<==================| | SIP 200 OK (PURR) | | |<===================================| | | | | | | | | |
| SIP INVITE (PURR) | | |===================================>| | | | |SIP INVITE (PURR) | | | |==================>| | | | | | | | SIP 200 OK | | | |<==================| | SIP 200 OK | | | |<===================================| | | | | | | | | | | | | | | | |SIP UPDATE (PURR) | | | |<==================| | | | | | | +-----------------------+ | | | | Fetch PRID (key=PURR) | | | | +-----------------------+ | | | | | | |Push Request (PRID) | | |<-----------------| | |Push Message (PRID) | | |<----------------| | | | | | | | SIP REGISTER (PRID) | | |===================================>| | | | |SIP REGISTER (PRID)| | | |==================>| | | | | | | | SIP 200 OK | | | |<==================| | SIP 200 OK (PURR) | | |<===================================| | | | | | | SIP UPDATE | | | |<===================================| | | | | | ------- Push Notification API ======= SIP Figure 4: SIP Push Long-Lived Dialog Flow
6.1. SIP UA Behavior
6.1.1. Initial Request for Dialog
If the UA is willing to receive push notifications when a proxy receives a mid-dialog request addressed towards the UA, the UA MUST insert a 'pn-purr' SIP URI parameter (Section 6.2.1) in the Contact header field URI of the initial request for a dialog or the 2xx response to such requests. The UA MUST insert a parameter value identical to the last 'sip.pnspurr' feature-capability indicator (Section 6.2.1) that it received in a REGISTER response. If the UA has not received a 'sip.pnspurr' feature-capability indicator, the UA MUST NOT insert a 'pn-purr' SIP URI parameter in a request or response. The UA makes the decision to receive push notifications triggered by incoming mid-dialog requests based on local policy. Such policy might be based on the type of SIP dialog, the type of media (if any) negotiated for the dialog [RFC3264], etc. NOTE: As the 'pn-purr' SIP URI parameter only applies to a given dialog, the UA needs to insert a 'pn-purr' parameter in the Contact header field URI of the request or response for each dialog in which the UA is willing to receive push notifications triggered by incoming mid-dialog requests.6.2. SIP Proxy Behavior
6.2.1. REGISTER
If the proxy supports requesting push notifications triggered by mid- dialog requests being sent to the registered UA, the proxy MUST store the information (the 'pn-*' SIP URI parameters) needed to request that push notifications are sent to the UA when a proxy receives an initial REGISTER request for a binding from the UA. In addition, the proxy MUST generate a unique (within the context of the proxy) value, referred to as the PURR (Proxy Unique Registration Reference), that can be used as a key to retrieve the information. In order to prevent client fingerprinting, the proxy MUST periodically generate a new PURR value (even if 'pn-*'parameters did not change). However, as long as there are ongoing dialogs associated with the old value, the proxy MUST store it so that it can request that push notifications are sent to the UA when it receives a mid-dialog request addressed towards the UA. In addition, the PURR value MUST be generated in such a way so that it is unforgeable, anonymous, and unlinkable to entities other than the proxy. It must not be possible for an attacker to generate a valid PURR, to
associate a PURR with a specific user, or to determine when two PURRs correspond to the same user. It can be generated, e.g., by utilizing a cryptographically secure random function with an appropriately large output size. Whenever the proxy receives a 2xx response to a REGISTER request, the proxy MUST insert a 'sip.pnspurr' feature-capability indicator with the latest PURR value (see above) in the response.6.2.2. Initial Request for Dialog
When a proxy receives an initial request for a dialog from a UA that contains a 'pn-purr' SIP URI parameter in the Contact header field URI with a PURR value that the proxy has generated (Section 6.2.1), the proxy MUST add a Record-Route header to the request to insert itself in the dialog route [RFC3261] before forwarding the request. When the proxy receives an initial request for a dialog addressed towards the UA, and the proxy has generated a PURR value associated with the 'pn-*' parameters inserted in the SIP URI of the request (Section 6.2.2), the proxy MUST add a Record-Route header to the request to insert itself in the dialog route [RFC3261] before forwarding the request.6.2.3. Mid-dialog Request
When the proxy receives a mid-dialog SIP request addressed towards the UA that contains a 'pn-purr' SIP URI parameter, and the proxy is able to retrieve the stored information needed to request that a push notification be sent to the UA (Section 6.2.1), the proxy MUST place the SIP request in the SIP Request Push Bucket and request that a push notification be sent to the UA. NOTE: The 'pn-purr' SIP URI parameter will either be carried in the Request-URI or in a Route header field [RFC3261] of the SIP request depending on how the route set [RFC3261] of the mid-dialog SIP request has been constructed. When the proxy receives a 2xx response to a REGISTER request, the proxy checks whether the SIP Request Push Bucket contains a mid- dialog SIP request associated with the REGISTER transaction. If the bucket contains such a request, the proxy MUST remove the SIP request from the SIP Request Push Bucket and forward it towards the UA. Note that the proxy does not perform a URI comparison (Section 5.3) when processing mid-dialog requests, as a mid-dialog request will not contain the 'pn-prid', 'pn-provider', and 'pn-param' SIP URI
parameters. The proxy only checks for a mid-dialog request that contains the PURR value associated with the REGISTER 2xx response. As described in Section 5.6.2, while waiting for the push notification request to succeed, and then for the associated REGISTER request and 2xx response, the proxy needs to take into consideration that the transaction associated with the mid-dialog request will eventually time out at the sender of the request (User Agent Client), and the sender will consider the transaction a failure. When a proxy sends an error response to a mid-dialog request (e.g., due to a transaction time out), the proxy SHOULD select a response code that only impacts the transaction associated with the request [RFC5079].7. Support of SIP Replaces
[RFC3891] defines a mechanism that allows a SIP UA to replace a dialog with another dialog. A UA that wants to replace a dialog with another one will send an initial request for the new dialog. The Request-URI of the request will contain the Contact header field URI of the peer. If a SIP proxy wants to be able to request that a push notification be sent to a UA when it receives an initial request for a dialog that replaces an existing dialog, using the mechanism in [RFC3891], the proxy and the UA MUST perform the following actions: o The proxy MUST provide a PURR to the UA during registration (Section 6.2.1). o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact header field URI of either the initial request for a dialog or a 2xx response to such requests (Section 6.1.1). This includes dialogs replacing other dialogs, as those dialogs might also get replaced. o The proxy MUST apply the mechanism defined in Section 6.2.3 to place and retrieve the request from the SIP Request Push Bucket. In addition, the operator needs to make sure that the initial request for dialogs, addressed towards the UA using the contact of the replaced dialog, will be routed to the SIP proxy (in order to request that a push notification be sent to the UA). The procedures for doing that are operator-specific and are outside the scope of this specification.
8. Grammar
8.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 does not support the push notification service identified in a 'pn-provider' SIP URI parameter. The use of the SIP 555 response code is only defined for SIP REGISTER responses.8.2. 'sip.pns' Feature-Capability Indicator
The sip.pns feature-capability indicator, when inserted in a Feature- Caps header field of a SIP REGISTER request or a SIP 2xx response to a REGISTER request, indicates that the entity associated with the indicator supports the SIP push mechanism and the type of push notification service indicated by the indicator value. The values defined for the 'pn-provider' SIP URI parameter are used as indicator values. pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT pns = tag-value tag-value = <tag-value defined in [RFC3840]>8.3. 'sip.vapid' Feature-Capability Indicator
The sip.vapid feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator supports the Voluntary Application Server Identification (VAPID) [RFC8292] mechanism when the entity requests that a push notification be sent to a SIP UA. The indicator value is a public key identifying the entity that can be used by a SIP UA to restrict subscriptions to that entity. vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT vapid = tag-value tag-value = <tag-value defined in [RFC3840]>8.4. 'sip.pnsreg' Feature-Capability Indicator
The sip.pnsreg feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator expects to receive binding-refresh REGISTER requests from the SIP UA associated with the binding before
the binding expires, even if the entity does not request that a push
notification be sent to the SIP UA in order to trigger the binding-
refresh REGISTER requests. The indicator value conveys the minimum
time (given in seconds) prior to the binding expiration when the UA
MUST send the REGISTER request.
pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT
reg = 1*DIGIT
DIGIT = <DIGIT defined in [RFC3261]>
8.5. 'sip.pnsreg' Media Feature Tag
The sip.pnsreg media feature tag, when inserted in the Contact header
field of a SIP REGISTER request, indicates that the SIP UA associated
with the tag is able to send binding-refresh REGISTER requests for
the associated binding without being awakened by push notifications.
The media feature tag has no values.
pnsreg-mt = "+sip.pnsreg"
8.6. 'sip.pnspurr' Feature-Capability Indicator
The sip.pnspurr feature-capability indicator, when inserted in a SIP
2xx response to a SIP REGISTER request, denotes that the entity
associated with the indicator will store information that can be used
to associate a mid-dialog SIP request with the binding information in
the REGISTER request.
pnspurr-fc = "+sip.pnspurr" EQUAL LDQUOT pnspurr RDQUOT
pnspurr = tag-value
tag-value = <tag-value defined in [RFC3840]>
8.7. SIP URI Parameters
This section defines new SIP URI parameters by extending the grammar
for "uri-parameter" as defined in [RFC3261]. The ABNF [RFC5234] is
as follows:
uri-parameter =/ pn-provider / pn-param / pn-prid / pn-purr
pn-provider = "pn-provider" [EQUAL pvalue]
pn-param = "pn-param" EQUAL pvalue
pn-prid = "pn-prid" EQUAL pvalue
pn-purr = "pn-purr" EQUAL pvalue
pvalue = <pvalue defined in [RFC3261]>
EQUAL = <EQUAL defined in [RFC3261]>
The format and semantics of pn-prid and pn-param are specific to the pn-provider value. Parameter value characters that are not part of pvalue need to be escaped, as defined in RFC 3261.9. PNS Registration Requirements
When a new value is registered to the PNS subregistry, a reference to a specification that describes the usage of the PNS associated with the value is provided. That specification MUST contain the following information: 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. o How the 'pn-param' SIP URI parameter (if required for the specific PNS provider) value is retrieved and set by the SIP UA.10. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for Apple Push Notification service
When the Apple Push Notification service (APNs) is used, the PNS-related SIP URI parameters are set as described below. For detailed information about the parameter values, see <https://developer.apple.com/library/archive/documentation/ NetworkingInternet/Conceptual/RemoteNotificationsPG/ CommunicatingwithAPNs.html> [pns-apns]. The value of the 'pn-provider' URI parameter is "apns". Example: pn-provider=apns The value of the 'pn-param' URI parameter is a string that is composed of two values separated by a period (.): Team ID and Topic. The Team ID is provided by Apple and is unique to a development team. The Topic consists of the Bundle ID, which uniquely identifies an application, and a service value that identifies a service associated with the application, separated by a period (.). For Voice over IP (VoIP) applications, the service value is "voip". Example: pn-param=DEF123GHIJ.com.example.yourexampleapp.voip
NOTE: The Bundle ID might contain one or more periods (.). Hence, within the 'pn-param' value, the first period will be separating the Team ID from the Topic, and within the Topic, the last period will be separating the Bundle ID from the service. 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 device. Example: pn-prid=00fc13adff7851211. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for Google Firebase Cloud Messaging (FCM) Push Notification Service
When Firebase Cloud Messaging (FCM) is used, the PNS-related URI parameters are set as described below. For detailed information about the parameter values, see <https://firebase.google.com/docs/cloud-messaging/concept-options> [pns-fcm]. The value of the 'pn-provider' URI parameter is "fcm". The value of the 'pn-param' URI parameter is the Project 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.12. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for RFC 8030 (Generic Event Delivery Using HTTP Push)
When Generic Event Delivery Using HTTP Push is used, the PNS-related URI parameters are set as described below. The value of the 'pn-provider' URI parameter is "webpush". The value of the 'pn-param' URI parameter MUST NOT be used. The value of the 'pn-prid' URI parameter is the push subscription URI. See RFC 8030 [RFC8030] for more details. Note that encryption for web push [RFC8291] is not used; therefore, parameters for message encryption are not defined in this specification. Web push permits the sending of a push message without a payload without encryption.
13. Security Considerations
The security considerations for the use and operation of any particular PNS (e.g., how users and devices are authenticated and authorized) are out of scope for this document. [RFC8030] documents the security considerations for the PNS defined in that specification. Security considerations for other PNSs are left to their respective specifications. Typically, the PNS requires the SIP proxy requesting push notifications to be authenticated and authorized by the PNS. In some cases, the PNS also requires the SIP application (or the SIP application developer) to be identified in order for the application to request push notifications. Unless the PNS authenticates and authorizes the PNS, a malicious endpoint or network entity that managed to get access to the parameters transported in the SIP signaling might be able to request that push notifications are sent to a UA. Such push notifications will impact the battery life of the UA and trigger unnecessary SIP traffic. [RFC8292] defines a mechanism that allows a proxy to identify itself to a PNS by signing a JSON Web Token (JWT) sent to the PNS using a key pair. The public key serves as an identifier of the proxy and can be used by devices to restrict push notifications to the proxy associated with the key. Operators MUST ensure that the SIP signaling is properly secured, e.g., using encryption, from malicious network entities. TLS MUST be used unless the operators know that the signaling is secured using some other mechanism that provides strong crypto properties. In addition to the information that needs to be exchanged between a device and the PNS in order to establish a push notification subscription, the mechanism defined in this document does not require any additional information to be exchanged between the device and the PNS. The mechanism defined in this document does not require a proxy to insert any payload (in addition to possible payload used for the PNS itself) when requesting push notifications. Operators MUST ensure that the PNS-related SIP URI parameters conveyed by a user in the Contact URI of a REGISTER request are not sent to other users or to non-trusted network entities. One way to convey contact information is by using the SIP event package for registrations mechanism [RFC3680]. [RFC3680] defines generic security considerations for the SIP event package for registrations. As the PNS-related SIP URI parameters conveyed in the REGISTER
request contain sensitive information, operators that support the event package MUST ensure that event package subscriptions are properly authenticated and authorized, and that the SIP URI parameters are not inserted in event notifications sent to other users or to non-trusted network entities.14. IANA Considerations
14.1. SIP URI Parameters
This section defines new SIP URI Parameters that extend the "SIP/SIPS URI Parameters" subregistry [RFC3969] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters).14.1.1. pn-provider
Parameter Name: pn-provider Predefined Values: No Reference: RFC 859914.1.2. pn-param
Parameter Name: pn-param Predefined Values: No Reference: RFC 859914.1.3. pn-prid
Parameter Name: pn-prid Predefined Values: No Reference: RFC 859914.1.4. pn-purr
Parameter Name: pn-purr Predefined Values: No Reference: RFC 8599
14.2. SIP Response Codes
14.2.1. 555 (Push Notification Service Not Supported)
This section defines a new SIP response code that extends the "Response Codes" subregistry [RFC3261] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters). Response Code Number: 555 Default Reason Phrase: Push Notification Service Not Supported14.3. SIP Global Feature-Capability Indicator
14.3.1. sip.pns
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters). Name: sip.pns Description: This feature-capability indicator, when inserted in a Feature-Caps header field of a SIP REGISTER request or a SIP 2xx response to a REGISTER request, denotes that the entity associated with the indicator supports the SIP push mechanism and the type of push notification service conveyed by the indicator value. Reference: RFC 8599 Contact: IESG (iesg@ietf.org)14.3.2. sip.vapid
This section defines a new feature-capability indicator that extends the "SIP Feature-Capability Indicator Registration Tree" subregistry [RFC6809] under the SIP Parameters registry (https://www.iana.org/assignments/sip-parameters). Name: sip.vapid Description: This feature-capability indicator, when inserted in a SIP 2xx response to a SIP REGISTER request, denotes that the entity associated with the indicator supports the Voluntary Application Server Identification (VAPID) mechanism when the entity requests that a push notification be sent to a SIP UA.
The indicator value is a public key identifying the entity,
which can be used by a SIP UA to restrict subscriptions to
that entity.
Reference: RFC 8599
Contact: IESG (iesg@ietf.org)
14.3.3. sip.pnsreg
This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" subregistry
[RFC6809] under the SIP Parameters registry
(https://www.iana.org/assignments/sip-parameters).
Name: sip.pnsreg
Description: This feature-capability indicator, when inserted in a
SIP 2xx response to a SIP REGISTER request, denotes that the
entity associated with the indicator expects to receive
binding-refresh REGISTER requests for the binding from the SIP
UA associated with the binding before the binding expires, even
if the entity does not request that a push notification be sent
to the SIP UA in order to trigger the binding-refresh REGISTER
requests. The indicator value conveys the minimum time
(given in seconds) prior to the binding expiration when the UA
MUST send the REGISTER request.
Reference: RFC 8599
Contact: IESG (iesg@ietf.org)
14.3.4. sip.pnspurr
This section defines a new feature-capability indicator that extends
the "SIP Feature-Capability Indicator Registration Tree" subregistry
[RFC6809] under the SIP Parameters registry
(https://www.iana.org/assignments/sip-parameters).
Name: sip.pnspurr
Description: This feature-capability indicator, when inserted in a
SIP 2xx response to a SIP REGISTER request, conveys that
the entity associated with the indicator will store information
that can be used to associate a mid-dialog SIP request with the
binding information in the REGISTER request. The indicator
value is an identifier that can be used as a key to retrieve
the binding information.
Reference: RFC 8599
Contact: IESG (iesg@ietf.org)
14.4. SIP Media Feature Tag
14.4.1. sip.pnsreg
This section defines a new media feature tag that extends the "SIP
Media Feature Tag Registration Tree" subregistry [RFC3840] under the
"Media Feature Tags" registry (https://www.iana.org/assignments/
media-feature-tags).
Media feature tag name: sip.pnsreg
Summary of the media feature indicated by this feature tag: This
media feature tag, when inserted in the Contact header field
of a SIP REGISTER request, conveys that the SIP UA
associated with the tag is able to send binding-refresh
REGISTER requests associated with the registration without
being awakened by push notifications.
Values appropriate for use with this feature tag: none
Related standards or documents: RFC 8599
Security considerations: This media feature tag does not introduce
new security considerations, as it simply indicates support for
a basic SIP feature. If an attacker manages to remove the media
feature tag, push notifications will not be requested to be sent
to the client.
Contact: IESG (iesg@ietf.org)
14.5. PNS Subregistry Establishment
This section creates a new subregistry, "PNS", under the SIP
Parameters registry (https://www.iana.org/assignments/
sip-parameters).
The purpose of the subregistry is to register SIP URI 'pn-provider'
values.
When a SIP URI 'pn-provider' value is registered in the subregistry,
it needs to meet the "Specification Required" policies defined in
[RFC8126].
This subregistry is defined as a table that contains the following
three columns:
Value: The token under registration
Description: The name of the Push Notification Service (PNS)
Document: A reference to the document defining the registration
This specification registers the following values:
Value Description Document
------- -------------------------------------- ----------
apns Apple Push Notification service RFC 8599
fcm Firebase Cloud Messaging RFC 8599
webpush Generic Event Delivery Using HTTP Push RFC 8599
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004,
<https://www.rfc-editor.org/info/rfc3840>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
DOI 10.17487/RFC3891, September 2004,
<https://www.rfc-editor.org/info/rfc3891>.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, <https://www.rfc-editor.org/info/rfc3969>. [RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)", RFC 5079, DOI 10.17487/RFC5079, December 2007, <https://www.rfc-editor.org/info/rfc5079>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [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 Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, <https://www.rfc-editor.org/info/rfc8030>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server Identification (VAPID) for Web Push", RFC 8292, DOI 10.17487/RFC8292, November 2017, <https://www.rfc-editor.org/info/rfc8292>. [pns-apns] Apple Inc., "Local and Remote Notification Programming Guide: Communicating with APNs", <https://developer.apple. com/library/archive/documentation/NetworkingInternet/Conce ptual/RemoteNotificationsPG/CommunicatingwithAPNs.html>. [pns-fcm] Google Inc., "Firebase Cloud Messaging", <https://firebase.google.com/docs/cloud-messaging/ concept-options>.
15.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>. [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, DOI 10.17487/RFC3680, March 2004, <https://www.rfc-editor.org/info/rfc3680>. [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, DOI 10.17487/RFC4320, January 2006, <https://www.rfc-editor.org/info/rfc4320>. [RFC4321] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, DOI 10.17487/RFC4321, January 2006, <https://www.rfc-editor.org/info/rfc4321>. [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <https://www.rfc-editor.org/info/rfc5626>. [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, DOI 10.17487/RFC6665, July 2012, <https://www.rfc-editor.org/info/rfc6665>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, DOI 10.17487/RFC8291, November 2017, <https://www.rfc-editor.org/info/rfc8291>.
Acknowledgements
Thanks to Paul Kyzivat, Dale Worley, Ranjit Avasarala, Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula, Liviu Chircu, Roman Shpount, Yehoshua Gev, and Jean Mahoney for reading the text and providing useful feedback.Authors' Addresses
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Michael Arnold Metaswitch Networks 100 Church Street Enfield EN2 6BQ United Kingdom Email: Michael.Arnold@metaswitch.com