From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8599.txt | 2243 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2243 insertions(+) create mode 100644 doc/rfc/rfc8599.txt (limited to 'doc/rfc/rfc8599.txt') diff --git a/doc/rfc/rfc8599.txt b/doc/rfc/rfc8599.txt new file mode 100644 index 0000000..9509d9d --- /dev/null +++ b/doc/rfc/rfc8599.txt @@ -0,0 +1,2243 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Holmberg +Request for Comments: 8599 Ericsson +Category: Standards Track M. Arnold +ISSN: 2070-1721 Metaswitch Networks + May 2019 + + + Push Notification with the Session Initiation Protocol (SIP) + +Abstract + + This document describes how a Push Notification Service (PNS) can be + used to wake a suspended Session Initiation Protocol (SIP) User Agent + (UA) with push notifications, and it also describes how the UA can + send binding-refresh REGISTER requests and receive incoming SIP + requests in an environment in which the UA may be suspended. The + document defines new SIP URI parameters to exchange PNS information + between the UA and the SIP entity that will then request that push + notifications be sent to the UA. It also defines the parameters to + trigger such push notification requests. The document also defines + new feature-capability indicators that can be used to indicate + support of this mechanism. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8599. + + + + + + + + + + + + + + + +Holmberg & Arnold Standards Track [Page 1] + +RFC 8599 SIP PUSH May 2019 + + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 8 + 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 9 + 4.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1.1. Request Push Notifications . . . . . . . . . . . . . 9 + 4.1.2. Disable Push Notifications . . . . . . . . . . . . . 11 + 4.1.3. Receive Push Notifications . . . . . . . . . . . . . 11 + 4.1.4. Sending Binding-Refresh Requests Using Non-push + Mechanism . . . . . . . . . . . . . . . . . . . . . . 11 + 4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 13 + 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 14 + 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 14 + 5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 15 + 5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 15 + 5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 15 + 5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 16 + 5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 17 + 5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 17 + 5.6.2. Initial Request for Dialog or Standalone Request . . 20 + 6. Support of Long-Lived SIP Dialogs . . . . . . . . . . . . . . 23 + 6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 25 + 6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 25 + 6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 25 + 6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 25 + 6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 26 + 6.2.3. Mid-dialog Request . . . . . . . . . . . . . . . . . 26 + 7. Support of SIP Replaces . . . . . . . . . . . . . . . . . . . 27 + 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 8.1. 555 (Push Notification Service Not Supported) Response + Code . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + + + +Holmberg & Arnold Standards Track [Page 2] + +RFC 8599 SIP PUSH May 2019 + + + 8.2. 'sip.pns' Feature-Capability Indicator . . . . . . . . . 28 + 8.3. 'sip.vapid' Feature-Capability Indicator . . . . . . . . 28 + 8.4. 'sip.pnsreg' Feature-Capability Indicator . . . . . . . . 28 + 8.5. 'sip.pnsreg' Media Feature Tag . . . . . . . . . . . . . 29 + 8.6. 'sip.pnspurr' Feature-Capability Indicator . . . . . . . 29 + 8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 29 + 9. PNS Registration Requirements . . . . . . . . . . . . . . . . 30 + 10. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for + Apple Push Notification service . . . . . . . . . . . . . . . 30 + 11. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for + Google Firebase Cloud Messaging (FCM) Push Notification + Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 12. 'pn-provider', 'pn-param', and 'pn-prid' URI Parameters for + RFC 8030 (Generic Event Delivery Using HTTP Push) . . . . . . 31 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 33 + 14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 33 + 14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 33 + 14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 33 + 14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 33 + 14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 34 + 14.2.1. 555 (Push Notification Service Not Supported) . . . 34 + 14.3. SIP Global Feature-Capability Indicator . . . . . . . . 34 + 14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 34 + 14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 34 + 14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 35 + 14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 35 + 14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 36 + 14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 36 + 14.5. PNS Subregistry Establishment . . . . . . . . . . . . . 36 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 15.2. Informative References . . . . . . . . . . . . . . . . . 39 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + + + + + + + + + + + + + + + +Holmberg & Arnold Standards Track [Page 3] + +RFC 8599 SIP PUSH May 2019 + + +1. Introduction + + In order to save resources such as battery life, some devices + (especially mobile devices) and operating systems will suspend an + application that is not in use. A suspended application might not be + able to wake itself with internal timers and might not be awakened by + incoming network traffic. In such an environment, a Push + Notification Service (PNS) is used to wake the application. A PNS is + a service that sends messages requested by other applications to a + user application in order to wake the user application. These + messages are called push notifications. Push notifications might + contain payload data, depending on the application. An application + can request that a push notification be sent to a single user + application or to multiple user applications. + + Typically, each operating system uses a dedicated PNS. Different + PNSs exist today. Some are based on the standardized mechanism + defined in [RFC8030], while others are proprietary. For example, + Apple iOS devices use the Apple Push Notification service (APNs) + while Android devices use the Firebase Cloud Messaging (FCM) service. + Each PNS uses PNS-specific terminology and function names. The + terminology in this document is meant to be PNS-independent. If the + PNS is based on [RFC8030], the SIP proxy takes the role of the + application server. + + When a Session Initiation Protocol (SIP) User Agent (UA)[RFC3261] is + suspended in such an environment, it is unable to send binding- + refresh SIP REGISTER requests, unable to receive incoming SIP + requests, and might not be able to use internal timers to wake + itself. A suspended UA will not be able to maintain connections, + e.g., using the SIP Outbound Mechanism [RFC5626], because it cannot + send periodic keep-alive messages. A PNS is needed to wake the SIP + UA so that the UA can perform these functions. + + This document describes how a PNS can be used to wake a suspended UA + using push notifications, so that the UA can send binding-refresh + REGISTER requests and receive incoming SIP requests. The document + defines new SIP URI parameters and new feature-capability indicators + [RFC6809] that can be used in SIP messages to indicate support of the + mechanism defined in this document; be used to exchange PNS + information between the UA and the SIP entity (realized as a SIP + proxy in this document) that will request that push notifications are + sent to the UA; and be used to request such push notification + requests. + + + + + + + +Holmberg & Arnold Standards Track [Page 4] + +RFC 8599 SIP PUSH May 2019 + + + NOTE: Even if a UA is able to be awakened by means other than + receiving push notifications (e.g., by using internal timers) in + order to send periodic binding-refresh REGISTER requests, it might + still be useful to suspend the UA between the sending of binding- + refresh requests (as it will save battery life) and use push + notifications to wake the UA when an incoming SIP request UA arrives. + + When a UA registers with a PNS (Figure 1), it will receive a unique + Push Resource ID (PRID) associated with the push notification + registration. The UA will use a REGISTER request to provide the PRID + to the SIP proxy, which will then request that push notifications are + sent to the UA. + + When the SIP proxy receives a SIP request for a new dialog or a + standalone SIP request addressed towards a UA, or when the SIP proxy + determines that the UA needs to send a binding-refresh REGISTER + request, the SIP proxy will send a push request containing the PRID + of the UA to the PNS, which will then send a push notification to the + UA. Once the UA receives the push notification, it will be able to + send a binding-refresh REGISTER request. The proxy receives the + REGISTER request from the UA and forwards it to the SIP registrar + [RFC3261]. After accepting the REGISTER request, the SIP registrar + sends a 2xx response to the proxy, which forwards the response to the + UA. If the push notification request was triggered by a SIP request + addressed towards the UA, the proxy can then forward the SIP request + to the UA using normal SIP routing procedures. In some cases, the + proxy can forward the SIP request without waiting for the SIP 2xx + response to the REGISTER request from the SIP registrar. Note that + this mechanism necessarily adds delay to responding to requests + requiring push notification. The consequences of that delay are + discussed in Section 5.6.2. + + If there are Network Address Translators (NATs) between the UA and + the proxy, the REGISTER request sent by the UA will create NAT + bindings that will allow the incoming SIP request that triggered the + push notification to reach the UA. + + NOTE: The lifetime of any NAT binding created by the REGISTER request + only needs to be long enough for the SIP request that triggered the + push notification to reach the UA. + + Figure 1 shows the generic push notification architecture supported + by the mechanism in this document. + + The SIP proxy MUST be in the signaling path of REGISTER requests sent + by the UA towards the registrar, and of SIP requests (for a new + dialog or a standalone) forwarded by the proxy responsible for the + UA's domain (sometimes referred to as home proxy, Serving Call + + + +Holmberg & Arnold Standards Track [Page 5] + +RFC 8599 SIP PUSH May 2019 + + + Session Control Function (S-CSCF), etc.) towards the UA. The proxy + can also be co-located with the proxy responsible for the UA's + domain. This will also ensure that the Request-URI of SIP requests + (for a new dialog or a standalone) can be matched against contacts in + REGISTER requests. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Holmberg & Arnold Standards Track [Page 6] + +RFC 8599 SIP PUSH May 2019 + + + +--------+ +---------+ +-----------+ +-------------+ + | | | | | | | SIP | + | SIP UA | | Push | | SIP Proxy | | Registrar / | + | | | Service | | | | Home Proxy | + +--------+ +---------+ +-----------+ +-------------+ + | | | | + | Subscribe | | | + |---------------->| | | + | | | | + | PRID | | | + |<----------------| | | + | | | | + | SIP REGISTER (PRID) | | + |===================================>| | + | | |SIP REGISTER (PRID)| + | | |==================>| + | | | | + | | | SIP 200 OK | + | | |<==================| + | SIP 200 OK | | | + |<===================================| | + | | | | + | | | SIP INVITE (PRID) | + | | |<==================| + | | | | + | |Push Request (PRID) | + | |<-----------------| | + |Push Message (PRID) | | + |<----------------| | | + | | | | + | SIP REGISTER (PRID) | | + |===================================>| | + | | |SIP REGISTER (PRID)| + | | |==================>| + | | | | + | | | SIP 200 OK | + | | |<==================| + | SIP 200 OK | | | + |<===================================| | + | | | | + | SIP INVITE | | | + |<===================================| | + | | | | + + ------- Push Notification API + ======= SIP + + Figure 1: SIP Push Information Flow + + + +Holmberg & Arnold Standards Track [Page 7] + +RFC 8599 SIP PUSH May 2019 + + + Example of a SIP REGISTER request in the flow above: + + REGISTER sip:alice@example.com SIP/2.0 + Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 + Max-Forwards: 70 + To: Alice + From: Alice ;tag=456248 + Call-ID: 843817637684230@998sdasdh09 + CSeq: 1826 REGISTER + Contact: + Expires: 7200 + Content-Length: 0 + + Figure 2: SIP REGISTER Example + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Push Resource ID (PRID) + + When a SIP UA registers with a PNS it receives a unique Push Resource + ID (PRID), which is a value associated with the registration that can + be used to generate push notifications. + + The format of the PRID varies depending on the PNS. + + The details regarding discovery of the PNS, and the procedures + regarding the push notification registration and maintenance, are + outside the scope of this document. The information needed to + contact the PNS is typically preconfigured in the operating system of + the device. + + + + + + + + + + + + +Holmberg & Arnold Standards Track [Page 8] + +RFC 8599 SIP PUSH May 2019 + + +4. SIP User Agent (UA) Behavior + +4.1. REGISTER + + This section describes how a SIP UA sends SIP REGISTER requests + (either an initial REGISTER request for a binding or a binding- + refresh REGISTER request) in order to request and disable push + notifications from a SIP network, and to query the types of PNSs + supported by the SIP network. + + Unless specified otherwise, the normal SIP UA registration procedures + [RFC3261] apply. The additional procedures described in this section + apply when the REGISTER request contains a 'pn-provider' SIP URI + parameter in the Contact header field URI (Figure 2). + + The procedures in this section apply to individual bindings + [RFC3261]. If a UA creates multiple bindings (e.g., one for IPv4 and + one for IPv6), the UA needs to perform the procedures for each + binding. + + NOTE: Since a push notification will trigger the UA to refresh all + bindings, if a SIP UA has created multiple bindings, it is preferable + if one can ensure that all bindings expire at the same time to help + prevent some bindings from being refreshed earlier than needed. + + For privacy and security reasons, a UA MUST NOT insert the SIP URI + parameters (except for the 'pn-purr' parameter) defined in this + specification in non-REGISTER requests in order to prevent the PNS + information associated with the UA from reaching the remote peer. + For example, the UA MUST NOT insert the 'pn-prid' SIP URI parameter + in the Contact header field URI of an INVITE request. REGISTER + requests will not reach the remote peer, as they will be terminated + by the registrar of the UA. However, the registrar MUST still ensure + that the parameters are not sent to other users, e.g., using the + mechanism defined by the SIP event package for registrations + [RFC3680]. See Section 13 for more information. + +4.1.1. Request Push Notifications + + This section describes the procedures that a SIP UA follows to + request push notifications from the SIP network. The procedures + assume that the UA has retrieved a PRID from a PNS. The procedures + for retrieving the PRID from the PNS are PNS-specific and outside the + scope of this specification. See PNS-specific documentation for more + details. + + + + + + +Holmberg & Arnold Standards Track [Page 9] + +RFC 8599 SIP PUSH May 2019 + + + This specification does not define a mechanism to explicitly request + push notifications from the SIP network for usages other than + triggering binding-refresh REGISTER requests (e.g., for sending + periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does + it describe how to distinguish push notifications associated with + such usages from the push notifications used to trigger binding- + refresh REGISTER requests. If a SIP UA wants to use push + notifications for other usages, the UA can perform actions associated + with such usages (in addition to sending a binding-refresh REGISTER + request) whenever it receives a push notification by using the same + refresh interval that is used for the binding refreshes. + + To request push notifications from the SIP network, the UA MUST + insert the following SIP URI parameters in the SIP Contact header + field URI of the REGISTER request: 'pn-provider', 'pn-prid', and + 'pn-param' (if required for the specific PNS). The 'pn-provider' URI + parameter indicates the type of PNS to be used for the push + notifications. + + If the UA receives a 2xx response to the REGISTER request that + contains a Feature-Caps header field [RFC6809] with a 'sip.pns' + feature-capability indicator, with an indicator value identifying the + same type of PNS that was identified by the 'pn-provider' URI + parameter in the REGISTER request, it indicates that another SIP + Proxy in the SIP network will request that push notifications are + sent to the UA. In addition, if the same Feature-Caps header field + contains a 'sip.vapid' feature-capability indicator, it indicates + that the proxy supports use of the Voluntary Application Server + Identification (VAPID) mechanism [RFC8292] to restrict push + notifications to the UA. + + NOTE: The VAPID-specific procedures of the SIP UA are outside the + scope of this document. + + If the UA receives a non-2xx response to the REGISTER, or if the UA + receives a 2xx response that does not contain a Feature-Caps header + field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA + MUST NOT assume the proxy will request that push notifications are + sent to the UA. The actions taken by the UA in such cases are + outside the scope of this document. + + If the PRID is only valid for a limited time, then the UA is + responsible for retrieving a new PRID from the PNS and sending a + binding-refresh REGISTER request with the updated 'pn-*' parameters. + If a PRID is no longer valid, and the UA is not able to retrieve a + new PRID, the UA MUST disable the push notifications associated with + the PRID (Section 4.1.2). + + + + +Holmberg & Arnold Standards Track [Page 10] + +RFC 8599 SIP PUSH May 2019 + + +4.1.2. Disable Push Notifications + + When a UA wants to disable previously requested push notifications, + the UA SHOULD remove the binding [RFC3261], unless the UA is no + longer able to perform SIP procedures (e.g., due to a forced shutdown + of the UA), in which case the registrar will remove the binding once + it expires. When the UA sends the REGISTER request for removing the + binding, the UA MUST NOT insert the 'pn-prid' SIP URI parameter in + the Contact header field URI of the REGISTER request. The lack of + the parameter informs the SIP network that the UA no longer wants to + receive push notifications associated with the PRID. + +4.1.3. Receive Push Notifications + + When a UA receives a push notification, the UA MUST send a binding- + refresh REGISTER request. The UA MUST insert the same set of 'pn-*' + SIP URI parameters in the SIP Contact header field URI of the + REGISTER request that it inserted when it requested push + notifications (Section 4.1.1). Note that, in some cases, the PNS + might update the PRID value, in which case the UA will insert the new + value in the 'pn-prid' SIP URI parameter of the binding-refresh + REGISTER request. + + Once the UA has received a 2xx response to the REGISTER request, the + UA might receive a SIP request for a new dialog (e.g., a SIP INVITE) + or a standalone SIP request (e.g., a SIP MESSAGE) if such a SIP + request triggered the proxy to request that the push notification was + sent to the UA. Note that, depending on which transport protocol is + used, the SIP request might reach the UA before the REGISTER + response. + + If the SIP UA has created multiple bindings, the UA MUST send a + binding-refresh REGISTER request for each of those bindings when it + receives a push notification. + + This specification does not define any usage of push-notification + payload. If a SIP UA receives a push notification that contains a + payload, the UA can discard the payload but will still send a + binding-refresh REGISTER request. + +4.1.4. Sending Binding-Refresh Requests Using Non-push Mechanism + + If a UA is able to send binding-refresh REGISTER requests using a + non-push mechanism (e.g., using an internal timer that periodically + wakes the UA), the UA MUST insert a 'sip.pnsreg' media feature tag + [RFC3840] in the Contact header field of each REGISTER request. + + + + + +Holmberg & Arnold Standards Track [Page 11] + +RFC 8599 SIP PUSH May 2019 + + + If the UA receives a 2xx response to the REGISTER request that + contains a Feature-Caps header field with a 'sip.pnsreq' feature- + capability indicator, the UA MUST send a binding-refresh REGISTER + request prior to binding expiration. The indicator value indicates + the minimum time (given in seconds), prior to the binding expiration + when the UA needs to send the REGISTER request. + + If the UA receives a 2xx response to the REGISTER request that does + not contain a Feature-Caps header field with a 'sip.pnsreq' feature- + capability indicator, the UA SHOULD only send a binding-refresh + REGISTER request when it receives a push notification (even if the UA + is able to use a non-push mechanism for sending binding-refresh + REGISTER requests) or when there are circumstances that require an + immediate REGISTER request to be sent (e.g., if the UA is assigned + new contact parameters due to a network configuration change). + + Even if the UA is able to send binding-refresh REGISTER requests + using a non-push mechanism, the UA MUST still send a binding-refresh + REGISTER request whenever it receives a push notification + (Section 4.1.3). + + NOTE: If the UA uses a non-push mechanism to wake and send binding- + refresh REGISTER requests, such REGISTER requests will update the + binding expiration timer, and the proxy does not need to request that + a push notification be sent to the UA in order to wake the UA. The + proxy will still request that a push notification be sent to the UA + when the proxy receives a SIP request addressed towards the UA + (Section 5.6.2). This allows the UA to, e.g., use timers for sending + binding-refresh REGISTER requests but be suspended (in order to save + battery resources, etc.) between sending the REGISTER requests and + using push notifications to wake the UA to process incoming calls. + + + + + + + + + + + + + + + + + + + + +Holmberg & Arnold Standards Track [Page 12] + +RFC 8599 SIP PUSH May 2019 + + + Example of a SIP REGISTER request including a 'sip.pnsreg' + media feature tag: + + REGISTER sip:alice@example.com SIP/2.0 + Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 + Max-Forwards: 70 + To: Alice + From: Alice ;tag=456248 + Call-ID: 843817637684230@998sdasdh09 + CSeq: 1826 REGISTER + Contact: ; + +sip.pnsreg + Expires: 7200 + Content-Length: 0 + + Example of a SIP REGISTER response including a 'sip.pnsreg' + media feature tag and a 'sip.pnsreq' feature-capability indicator: + + SIP/2.0 200 OK + Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 + To: Alice ;tag=123987 + From: Alice ;tag=456248 + Call-ID: 843817637684230@998sdasdh09 + CSeq: 1826 REGISTER + Contact: ; + +sip.pnsreg + Feature-Caps: *;+sip.pns="acme";+sip.pnsreg="121" + Expires: 7200 + Content-Length: 0 + + Figure 3: SIP REGISTER When Using Non-push Mechanism Example + +4.1.5. Query Network PNS Capabilities + + This section describes how a SIP UA can query the types of PNSs + supported by a SIP network, and PNS-related capabilities (e.g., + support of the VAPID mechanism). When a UA performs a query, it does + not request push notifications from the SIP network. Therefore, the + UA can perform the query before it has registered to a PNS and + received a PRID. + + + + + +Holmberg & Arnold Standards Track [Page 13] + +RFC 8599 SIP PUSH May 2019 + + + In order to perform a query, the UA MUST insert a 'pn-provider' SIP + URI parameter in the Contact header field URI of the REGISTER + request: + + o If the UA inserts a 'pn-provider' parameter value, indicating + support of a type of PNS, the SIP network will only inform the UA + whether that type of PNS is supported. + + o If the UA does not insert a 'pn-provider' parameter value (i.e., + it inserts an "empty" 'pn-provider' parameter), the SIP network + will inform the UA about all types of PNSs supported by the + network. This is useful, e.g., if the UA supports more than one + type of PNS. Note that it is not possible to insert multiple + parameter values in the 'pn-provider' parameter. + + The UA MUST NOT insert a 'pn-prid' SIP URI parameter in the Contact + header field URI of the REGISTER request. + + If the UA receives a 2xx response to the REGISTER request, the + response will contain one or more Feature-Caps header fields with a + 'sip.pns' feature-capability indicator, indicating the types of PNSs + supported by the SIP network. If the UA inserted a 'pn-provider' SIP + URI parameter value in the REGISTER request, the response will only + indicate whether the SIP network supports the type of PNS supported + by the UA. + + If the UA receives a 555 (Push Notification Service Not Supported) + response to the REGISTER request, and if the UA inserted a + 'pn-provider' SIP URI parameter in the REGISTER request, the response + indicates that the network does not support the type of PNS that the + UA indicated support of. If the UA did not insert a 'pn-provider' + parameter in the REGISTER request, the response indicates that the + network does not support any type of PNS while still supporting the + 555 (Push Notification Service Not Supported) response. + + NOTE: It is optional for a UA to perform a query before it requests + push notifications from the SIP network. + +5. SIP Proxy Behavior + +5.1. PNS Provider + + The type of PNS is identified by the 'pn-provider' SIP URI parameter. + In some cases, there might only be one PNS provider for a given type + of PNS, while in other cases there might be multiple providers. The + 'pn-param' SIP URI parameter will provide more details associated + with the actual PNS provider to be used. + + + + +Holmberg & Arnold Standards Track [Page 14] + +RFC 8599 SIP PUSH May 2019 + + + The protocol and format used for the push notification requests are + PNS-specific, and the details for constructing and sending a push + notification request are outside the scope of this specification. + +5.2. SIP Request Push Bucket + + When a SIP proxy receives a SIP request addressed towards a UA, that + will trigger the proxy to request that a push notification be sent to + the UA. The proxy will place the request in storage (referred to as + the SIP Request Push Bucket) and the proxy will start a timer + (referred to as the Bucket Timer) associated with the transaction. A + SIP request is removed from the bucket when one of the following has + occurred: the proxy forwards the request towards the UA, the proxy + sends an error response to the request, or the Bucket Timer times + out. The detailed procedures are described in the sections below. + + Exactly how the SIP Request Push Bucket is implemented is outside the + scope of this document. One option is to use the PRID as a key to + search for SIP requests in the bucket. Note that mid-dialog requests + (Section 6) do not carry the PRID in the SIP request itself. + +5.3. SIP URI Comparison Rules + + By default, a SIP proxy uses the URI comparison rules defined in + [RFC3261]. However, when a SIP proxy compares the Contact header + field URI of a 2xx response to a REGISTER request with a Request-URI + of a SIP request in the SIP Request Push Bucket (Section 5.2), the + proxy uses the URI comparison rules with the following additions: the + 'pn-prid', 'pn-provider', and 'pn-param' SIP URI parameters MUST also + match. If a 'pn-*' parameter is present in one of the compared URIs + but not in the other URI, there is no match. + + If only the 'pn-*' SIP URI parameters listed above match, but other + parts of the compared URIs do not match, a proxy MAY still consider + the comparison successful based on local policy. This can occur in a + race condition when the proxy compares the Contact header field URI + of a 2xx response to a REGISTER request with a Request-URI of a SIP + request in the SIP Request Push Bucket (Section 5.2) if the UA had + modified some parts of the Contact header field URI in the REGISTER + request but the Request-URI of the SIP request in the SIP Request + Push Bucket still contains the old parts. + +5.4. Indicate Support of Type of PNS + + A SIP proxy uses feature-capability indicators [RFC6809] to indicate + support of types of PNSs and additional features (e.g., VAPID) + associated with the type of PNS. A proxy MUST use a separate + Feature-Cap header field for each supported type of PNS. A feature- + + + +Holmberg & Arnold Standards Track [Page 15] + +RFC 8599 SIP PUSH May 2019 + + + capability indicator that indicates support of an additional feature + associated with a given type of PNS MUST be inserted in the same + Feature-Caps header field that is used to indicate support of the + type of PNS. + + This specification defines the following feature-capability + indicators that a proxy can use to indicate support of additional + features associated with a given type of PNS: 'sip.vapid', + 'sip.pnsreg', and 'sip.pnspurr'. These feature-capability indicators + MUST only be inserted in a Feature-Caps header field that also + contains a 'sip.pns' feature-capability indicator. + +5.5. Trigger Periodic Binding Refresh + + In order to request that a push notification be sent to a SIP UA, a + SIP proxy needs to have information about when a binding will expire. + The proxy needs to be able to retrieve the information from the + registrar using some mechanism or run its own registration timers. + Such mechanisms are outside the scope of this document but could be + implemented, e.g., by using the SIP event package for registrations + mechanism [RFC3680]. + + When the proxy receives an indication that the UA needs to send a + binding-refresh REGISTER request, the proxy will request that a push + notification be sent to the UA. + + Note that the push notification needs to be requested early enough + for the associated binding-refresh REGISTER request to reach the + registrar before the binding expires. It is RECOMMENDED that the + proxy requests the push notification at least 120 seconds before the + binding expires. + + If the UA has indicated, using the 'sip.pnsreg' media feature tag, + that it is able to wake itself using a non-push mechanism in order to + send binding-refresh REGISTER requests, and if the proxy does not + receive a REGISTER request prior to 120 seconds before the binding + expires, the proxy MAY request that a push notification be sent to + the UA to trigger the UA to send a binding-refresh REGISTER request. + + NOTE: As described in Section 4.1.5, a UA might send a REGISTER + request without including a 'pn-prid' SIP URI parameter in order to + retrieve push notification capabilities from the network before the + UA expects to receive push notifications from the network. A proxy + will not request that push notifications are sent to a UA that has + not provided a 'pn-prid' SIP URI parameter (Section 5.6.2). + + + + + + +Holmberg & Arnold Standards Track [Page 16] + +RFC 8599 SIP PUSH May 2019 + + + If the proxy receives information that a binding associated with a + PRID has expired, or that a binding has been removed, the proxy MUST + NOT request that further push notifications are sent to the UA using + that PRID. + +5.6. SIP Requests + +5.6.1. REGISTER + + This section describes how a SIP proxy processes SIP REGISTER + requests (initial REGISTER request for a binding or a binding-refresh + REGISTER request). + + The procedures in this section apply when the REGISTER request + contains a 'pn-provider' SIP URI parameter in the Contact header + field URI. In other cases, the proxy MUST skip the procedures in + this section and process the REGISTER request using normal SIP + procedures. + +5.6.1.1. Request Push Notifications + + This section describes the SIP proxy procedures when a SIP UA + requests push notifications from the SIP network. + + The procedures in this section apply when the SIP REGISTER request + contains, in addition to the 'pn-provider' SIP URI parameter, a + 'pn-prid' SIP URI parameter in the Contact header field URI of the + request. + + When a proxy receives a REGISTER request that contains a Feature-Caps + header field with a 'sip.pns' feature-capability indicator, it + indicates that another proxy between this proxy and the UA supports + the type of PNS supported by the UA, and will request that push + notifications are sent to the UA. In such case, the proxy MUST skip + the rest of the procedures in this section and process the REGISTER + request using normal SIP procedures. + + When a proxy receives a REGISTER request that does not contain a + Feature-Caps header field with a 'sip.pns' feature-capability + indicator, the proxy processes the request according to the + procedures below: + + o If the proxy does not support the type of PNS supported by the UA, + or if the REGISTER request does not contain all information + required for the type of PNS, the proxy SHOULD forward the request + towards the registrar and skip the rest of the procedures in this + section. If the proxy knows (by means of local configuration) + that no other proxies between itself and the registrar support the + + + +Holmberg & Arnold Standards Track [Page 17] + +RFC 8599 SIP PUSH May 2019 + + + type of PNS supported by the UA, the proxy MAY send a SIP 555 + (Push Notification Service Not Supported) response instead of + forwarding the request. + + o If the proxy supports the type of PNS supported by the UA, but + considers the requested binding expiration interval [RFC3261] to + be too short (see below), the proxy MUST either send a 423 + (Interval Too Brief) response to the REGISTER request or forward + the request towards the registrar and skip the rest of the + procedures in this section. + + o If the proxy supports the type of PNS supported by the UA, the + proxy MUST indicate support of that type of PNS (Section 5.4) in + the REGISTER request before it forwards the request towards the + registrar. This will inform proxies between the proxy and the + registrar that the proxy supports the type of PNS supported by the + UA, and that the proxy will request that push notifications are + sent to the UA. + + A binding expiration interval MUST be considered too short if the + binding would expire before the proxy can request that a push + notification be sent to the UA to trigger the UA to send a binding- + refresh REGISTER request. The proxy MAY consider the interval too + short based on its own policy so as to reduce load on the system. + + When a proxy receives a 2xx response to the REGISTER request, if the + proxy indicated support of a type of PNS in the REGISTER request (see + above), the proxy performs the following actions: + + o If the proxy considers the binding expiration interval indicated + by the registrar too short (see above), the proxy forwards the + response towards the UA and MUST skip the rest of the procedures + in this section. + + o The proxy MUST indicate support of the same type of PNS in the + REGISTER response. In addition: + + * If the proxy supports the VAPID mechanism [RFC8292], the proxy + MUST indicate support of the mechanism, using the 'sip.vapid' + feature-capability indicator, in the REGISTER response. The + indicator value contains the public key identifying the proxy. + The proxy MUST determine whether the PNS provider supports the + VAPID mechanism before it indicates support of it. + + + + + + + + +Holmberg & Arnold Standards Track [Page 18] + +RFC 8599 SIP PUSH May 2019 + + + * If the proxy received a 'sip.pnsreg' media feature tag in the + REGISTER request, the proxy SHOULD insert a 'sip.pnsreg' + feature-capability indicator with an indicator value bigger + than 120 in the response, unless the proxy always wants to + request that push notifications are sent to the UA in order to + trigger the UA to send a binding-refresh REGISTER request. + +5.6.1.2. Query Network PNS Capabilities + + This section describes the SIP proxy procedures when a SIP UA queries + about the push-notification support in the SIP network + (Section 4.1.5). + + The procedures in this section apply when the REGISTER request + contains a 'pn-provider' SIP URI parameter, but does not contain a + 'pn-prid' SIP URI parameter in the Contact header field URI of the + REGISTER request. + + When a proxy receives a REGISTER request that contains a + 'pn-provider' SIP URI parameter indicating the type of PNS supported + by the UA, the proxy MUST perform the following actions: + + o If the proxy supports the type of PNS supported by the UA, the + proxy MUST indicate support of that type of PNS (Section 5.4) in + the REGISTER request before it forwards the request towards the + registrar. This will inform any other proxies between the proxy + and the registrar that the proxy supports the type of PNS + supported by the UA. + + o If the proxy does not support the type of PNS supported by the UA, + and if the REGISTER request contains Feature-Caps header fields + indicating support of one or more types of PNSs, the proxy + forwards the request towards the registrar. + + o If the proxy does not support the type of PNS supported by the UA, + and if the REGISTER request does not contain Feature-Caps header + fields indicating support of one or more types of PNSs, the proxy + MUST either forward the request towards the registrar or send a + SIP 555 (Push Notification Service Not Supported) response towards + the UA. The proxy MUST NOT send a SIP 555 (Push Notification + Service Not Supported) response unless it knows (by means of local + configuration) that no other proxy supports any of the types of + PNSs supported by the UA. + + When a proxy receives a REGISTER request, and the 'pn-provider' SIP + URI parameter does not contain a parameter value, the proxy MUST + indicate support of each type of PNS supported by the proxy before it + forwards the request towards the registrar. + + + +Holmberg & Arnold Standards Track [Page 19] + +RFC 8599 SIP PUSH May 2019 + + + When a proxy receives a 2xx response to the REGISTER request, if the + proxy had indicated support of one or more types of PNSs in the + REGISTER request (see above), the proxy MUST indicate support of the + same set of types of PNSs in the response. In addition, if the proxy + supports the VAPID mechanism for one or more types of PNSs, the proxy + MUST indicate support of the mechanism for those PNSs in the + response. + +5.6.2. Initial Request for Dialog or Standalone Request + + The procedures in this section apply when a SIP proxy has indicated + that it will request that push notifications are sent to the SIP UA. + + When the proxy receives a SIP request for a new dialog (e.g., a SIP + INVITE request) or a standalone SIP request (e.g., a SIP MESSAGE + request) addressed towards a SIP UA, if the Request-URI of the + request contains a 'pn-provider', a 'pn-prid', and a 'pn-param' (if + required for the specific PNS provider) SIP URI parameter, the proxy + requests that a push notification be sent to the UA using the + information in the 'pn-*' SIP URI parameters. The proxy then places + the SIP request in the SIP Request Push Bucket. The push + notification will trigger the UA to send a binding-refresh REGISTER + request that the proxy will process as described in Section 5.6.1. + In addition, the proxy MUST store the Contact URI of the REGISTER + request during the lifetime of the REGISTER transaction. + + NOTE: If the proxy receives a SIP request that does not contain the + 'pn-*' SIP URI parameters listed above, the proxy processing of the + request is based on local policy. If the proxy also serves requests + for UAs that do not use the SIP push mechanism, the proxy can forward + the request towards the UA. Otherwise, the proxy can reject the + request. + + When the proxy receives a 2xx response to the REGISTER request, the + proxy performs the following actions: + + o The proxy processes the REGISTER response as described in + Section 5.6.1. + + o The proxy checks whether the SIP Request Push Bucket contains a + SIP request associated with the REGISTER transaction by comparing + (Section 5.3) the Contact header field URI in the REGISTER + response with the Request-URIs of the SIP requests in the bucket. + If there is a match, the proxy MUST remove the SIP request from + the bucket and forward it towards the UA. + + + + + + +Holmberg & Arnold Standards Track [Page 20] + +RFC 8599 SIP PUSH May 2019 + + + The reason the proxy needs to wait for the REGISTER response before + forwarding a SIP request towards a UA is to make sure that the + REGISTER request has been accepted by the registrar, and that the UA + that initiated the REGISTER request is authorized to receive messages + for the Request-URI. + + If the proxy receives a non-2xx response to the REGISTER request, the + proxy compares the Contact URI stored from the REGISTER request (see + above) with the Request-URIs of the SIP requests in the SIP Request + Push Bucket. If there is a match, the proxy SHOULD remove the + associated request from the bucket and send an error response to the + request. It is RECOMMENDED that the proxy sends either a 404 (Not + Found) response or a 480 (Temporarily Unavailable) response to the + SIP request, but other response codes can be used as well. However, + if the REGISTER response is expected to trigger a new REGISTER + request from the UA (e.g., if the registrar is requesting the UA to + perform authentication), the proxy MAY keep the SIP request in the + bucket. + + If the push notification request fails (see PNS-specific + documentation for details), the proxy MUST remove the SIP request + from the bucket and send an error response to the SIP request. It is + RECOMMENDED that the proxy sends either a 404 (Not Found) response or + a 480 (Temporarily Unavailable) response, but other response codes + can be used as well. + + After the proxy has requested that a push notification be sent to a + UA, if the proxy does not receive a REGISTER response with a Contact + URI that matches the Request-URI of the SIP request before the Bucket + Timer (Section 5.2) associated with the SIP request times out, the + proxy MUST remove the SIP request from the SIP Request Push Bucket + (Section 5.2) and send a 480 (Temporarily Unavailable) response. The + Bucket Timer time-out value is set based on local policy, taking the + guidelines below into consideration. + + As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must + complete immediately or risk losing a race, which results in stress + on intermediaries and state misalignment at the endpoints. The + mechanism defined in this document inherently delays the final + response to any non-INVITE request that requires a push notification. + In particular, if the proxy forwards the SIP request towards the SIP + UA, the SIP UA accepts the request, but the transaction times out at + the sender before it receives the successful response, this will + cause state misalignment between the endpoints (the sender considers + the transaction a failure, while the receiver considers the + transaction a success). The SIP proxy needs to take this into + account when it sets the value of the Bucket Timer associated with + the transaction, to make sure that the error response (triggered by a + + + +Holmberg & Arnold Standards Track [Page 21] + +RFC 8599 SIP PUSH May 2019 + + + Bucket Timer time out) reaches the sender before the transaction + times out. If the accumulated delay of this mechanism combined with + any other mechanisms in the path of processing the non-INVITE + transaction cannot be kept short, this mechanism should not be used. + For networks encountering such conditions, an alternative (left for + possible future work) would be for the proxy to immediately return a + new error code meaning "wait at least the number of seconds specified + in this response and retry your request" before initiating the push + notification. + + NOTE: While the work on this document was ongoing, implementation + test results showed that the time it takes for a proxy to receive the + REGISTER request, from when the proxy has requested a push + notification, is typically around 2 seconds. However, the time might + vary depending on the characteristics and load of the SIP network and + the PNS. + + In addition to the procedures described above, there are two cases + where a proxy, as an optimization, can forward a SIP request towards + a UA without either waiting for a 2xx response to a REGISTER request + or requesting that a push notification be sent to the UA: + + o If the proxy is able to authenticate the sender of the REGISTER + request and verify that it is allowed by authorization policy, the + proxy does not need to wait for the 2xx response before it + forwards the SIP request towards the UA. In such cases, the proxy + will use the Contact URI of the REGISTER request when comparing it + against the Request-URIs of the SIP requests in the SIP Request + Push Bucket. + + o 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 + binding-refresh REGISTER request, the proxy does not need to + request that a push notification be sent to the UA (the UA will + not send a binding-refresh REGISTER request) before it forwards + the SIP request towards the UA. The mechanisms for getting such + knowledge might be dependent on implementation or deployment + architecture, and are outside the scope of this document. + + Some PNS providers allow payload in the push notifications. This + specification does not define usage of such payload (in addition to + any payload that might be required by the PNS itself). + + + + + + + + + +Holmberg & Arnold Standards Track [Page 22] + +RFC 8599 SIP PUSH May 2019 + + +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) | | + |<===================================| | + | | | | + | | | | + + + + +Holmberg & Arnold Standards Track [Page 23] + +RFC 8599 SIP PUSH May 2019 + + + | 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 + + + + + + + + +Holmberg & Arnold Standards Track [Page 24] + +RFC 8599 SIP PUSH May 2019 + + +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 + + + +Holmberg & Arnold Standards Track [Page 25] + +RFC 8599 SIP PUSH May 2019 + + + 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 + + + + +Holmberg & Arnold Standards Track [Page 26] + +RFC 8599 SIP PUSH May 2019 + + + 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. + + + + + +Holmberg & Arnold Standards Track [Page 27] + +RFC 8599 SIP PUSH May 2019 + + +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 = + +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 = + +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 + + + +Holmberg & Arnold Standards Track [Page 28] + +RFC 8599 SIP PUSH May 2019 + + + 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 = + +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 = + +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 = + EQUAL = + + + +Holmberg & Arnold Standards Track [Page 29] + +RFC 8599 SIP PUSH May 2019 + + + 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 + [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 + + + + + + +Holmberg & Arnold Standards Track [Page 30] + +RFC 8599 SIP PUSH May 2019 + + + 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=00fc13adff78512 + +11. '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 + + [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. + + + + +Holmberg & Arnold Standards Track [Page 31] + +RFC 8599 SIP PUSH May 2019 + + +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 + + + +Holmberg & Arnold Standards Track [Page 32] + +RFC 8599 SIP PUSH May 2019 + + + 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 8599 + +14.1.2. pn-param + + Parameter Name: pn-param + + Predefined Values: No + + Reference: RFC 8599 + +14.1.3. pn-prid + + Parameter Name: pn-prid + + Predefined Values: No + + Reference: RFC 8599 + +14.1.4. pn-purr + + Parameter Name: pn-purr + + Predefined Values: No + + Reference: RFC 8599 + + + + + + +Holmberg & Arnold Standards Track [Page 33] + +RFC 8599 SIP PUSH May 2019 + + +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 Supported + +14.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. + + + +Holmberg & Arnold Standards Track [Page 34] + +RFC 8599 SIP PUSH May 2019 + + + 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. + + + +Holmberg & Arnold Standards Track [Page 35] + +RFC 8599 SIP PUSH May 2019 + + + 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]. + + + + +Holmberg & Arnold Standards Track [Page 36] + +RFC 8599 SIP PUSH May 2019 + + + 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, + . + + [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, + . + + [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, + . + + [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation + Protocol (SIP) "Replaces" Header", RFC 3891, + DOI 10.17487/RFC3891, September 2004, + . + + + + + + + + +Holmberg & Arnold Standards Track [Page 37] + +RFC 8599 SIP PUSH May 2019 + + + [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, + . + + [RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the + Session Initiation Protocol (SIP)", RFC 5079, + DOI 10.17487/RFC5079, December 2007, + . + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [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, + . + + [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic + Event Delivery Using HTTP Push", RFC 8030, + DOI 10.17487/RFC8030, December 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server + Identification (VAPID) for Web Push", RFC 8292, + DOI 10.17487/RFC8292, November 2017, + . + + [pns-apns] Apple Inc., "Local and Remote Notification Programming + Guide: Communicating with APNs", . + + [pns-fcm] Google Inc., "Firebase Cloud Messaging", + . + + + + + + + +Holmberg & Arnold Standards Track [Page 38] + +RFC 8599 SIP PUSH May 2019 + + +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, + . + + [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event + Package for Registrations", RFC 3680, + DOI 10.17487/RFC3680, March 2004, + . + + [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, . + + [RFC4321] Sparks, R., "Problems Identified Associated with the + Session Initiation Protocol's (SIP) Non-INVITE + Transaction", RFC 4321, DOI 10.17487/RFC4321, January + 2006, . + + [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, + . + + [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, + DOI 10.17487/RFC6665, July 2012, + . + + [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, + . + + [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, + DOI 10.17487/RFC8291, November 2017, + . + + + + + + + + + + + +Holmberg & Arnold Standards Track [Page 39] + +RFC 8599 SIP PUSH May 2019 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + +Holmberg & Arnold Standards Track [Page 40] + -- cgit v1.2.3