idnits 2.17.1 draft-ietf-sipcore-sip-push-29.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2019) is 1852 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1579, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 1617, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track M. Arnold 5 Expires: September 27, 2019 Metaswitch Networks 6 March 26, 2019 8 Push Notification with the Session Initiation Protocol (SIP) 9 draft-ietf-sipcore-sip-push-29 11 Abstract 13 This document describes how a Push Notification Service (PNS) can be 14 used to wake a suspended Session Initiation Protocol (SIP) User Agent 15 (UA) with push notifications, and also describes how the UA can send 16 binding-refresh REGISTER requests and receive incoming SIP requests 17 in an environment in which the UA may be suspended. The document 18 defines new SIP URI parameters to exchange PNS information between 19 the UA and the SIP entity that will then request that push 20 notifications be sent to the UA, and to trigger such push 21 notification requests. The document also defines new feature- 22 capability indicators that can be used to indicate support of this 23 mechanism. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 27, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 7 62 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 7 63 4.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.1.1. Request Push Notifications . . . . . . . . . . . . . 8 65 4.1.2. Disable Push Notifications . . . . . . . . . . . . . 9 66 4.1.3. Receive Push Notifications . . . . . . . . . . . . . 10 67 4.1.4. Sending Binding-Refresh Requests Using Non-Push 68 Mechanism . . . . . . . . . . . . . . . . . . . . . . 10 69 4.1.5. Query Network PNS Capabilities . . . . . . . . . . . 12 70 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 13 71 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 13 72 5.2. SIP Request Push Bucket . . . . . . . . . . . . . . . . . 14 73 5.3. SIP URI Comparison Rules . . . . . . . . . . . . . . . . 14 74 5.4. Indicate Support of Type of PNS . . . . . . . . . . . . . 14 75 5.5. Trigger Periodic Binding Refresh . . . . . . . . . . . . 15 76 5.6. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 16 77 5.6.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 16 78 5.6.2. Initial Request for Dialog or Stand-Alone Request . . 19 79 6. Support Of Longlived SIP Dialogs . . . . . . . . . . . . . . 21 80 6.1. SIP UA Behavior . . . . . . . . . . . . . . . . . . . . . 23 81 6.1.1. Initial Request for Dialog . . . . . . . . . . . . . 23 82 6.2. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . 24 83 6.2.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 24 84 6.2.2. Initial Request for Dialog . . . . . . . . . . . . . 24 85 6.2.3. Mid-Dialog Request . . . . . . . . . . . . . . . . . 25 86 7. Support Of SIP Replaces . . . . . . . . . . . . . . . . . . . 26 87 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 8.1. 555 (Push Notification Service Not Supported) Response 89 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 8.2. sip.pns Feature-Capability Indicator . . . . . . . . . . 26 91 8.3. sip.vapid Feature-Capability Indicator . . . . . . . . . 27 92 8.4. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 27 93 8.5. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 28 94 8.6. sip.pnspurr Feature-Capability Indicator . . . . . . . . 28 95 8.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 28 96 9. PNS Registration Requirements . . . . . . . . . . . . . . . . 29 97 10. pn-provider, pn-param and pn-prid URI Parameters for Apple 98 Push Notification service . . . . . . . . . . . . . . . . . . 29 99 11. pn-provider, pn-param and pn-prid URI Parameters for Google 100 Firebase Cloud Messaging (FCM) push notification service . . 30 101 12. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 102 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 30 103 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 104 14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 105 14.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 32 106 14.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 32 107 14.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 32 108 14.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 33 109 14.1.4. pn-purr . . . . . . . . . . . . . . . . . . . . . . 33 110 14.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 33 111 14.2.1. 555 (Push Notification Service Not Supported) . . . 33 112 14.3. SIP Global Feature-Capability Indicator . . . . . . . . 33 113 14.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 33 114 14.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 34 115 14.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 34 116 14.3.4. sip.pnspurr . . . . . . . . . . . . . . . . . . . . 35 117 14.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 35 118 14.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 36 119 14.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 36 120 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 121 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 122 16.1. Normative References . . . . . . . . . . . . . . . . . . 37 123 16.2. Informative References . . . . . . . . . . . . . . . . . 39 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 126 1. Introduction 128 In order to save resources such as battery life, some devices 129 (especially mobile devices) and operating systems will suspend an 130 application that is not in use. A suspended application might not be 131 able to wake itself with internal timers and might not be awakened by 132 incoming network traffic. In such an environment, a Push 133 Notification Service (PNS) is used to wake the application. A PNS is 134 a service that sends messages requested by other applications to a 135 user application in order to wake the user application. These 136 messages are called push notifications. Push notifications might 137 contain payload data, depending on the application. An application 138 can request that a push notification be sent to a single user 139 application or to multiple user applications. 141 Typically each operating system uses a dedicated PNS. Different PNSs 142 exist today. Some are based on the standardized mechanism defined in 143 [RFC8030], while others are proprietary. For example, Apple iOS 144 devices use the Apple Push Notification service (APNs) while Android 145 devices use the Firebase Cloud Messaging (FCM) service. Each PNS 146 uses PNS-specific terminology and function names. The terminology in 147 this document is meant to be PNS-independent. If the PNS is based on 148 [RFC8030], the SIP proxy takes the role of the application server. 150 When a Session Initiation Protocol (SIP) User Agent (UA)[RFC3261] is 151 suspended in such an environment, it is unable to send binding- 152 refresh SIP REGISTER requests, unable to receive incoming SIP 153 requests, and might not be able to use internal timers to wake 154 itself. A suspended UA will not be able to maintain connections 155 e.g., using the SIP Outbound Mechanism [RFC5626] because it cannot 156 send periodic keep-alive messages. A PNS is needed to wake the SIP 157 UA so that the UA can perform these functions. 159 This document describes how a PNS can be used to wake a suspended UA, 160 using push notifications, so that the UA can be able to send binding- 161 refresh REGISTER requests and to receive incoming SIP requests. The 162 document defines new SIP URI parameters and new feature-capability 163 indicators [RFC6809] that can be used in SIP messages to indicate 164 support of the mechanism defined in this document, to exchange PNS 165 information between the UA and the SIP entity (realized as a SIP 166 proxy in this document) that will request that push notifications are 167 sent to the UA, and to request such push notification requests. 169 NOTE: Even if a UA is able to be awakened by means other than 170 receiving push notifications (e.g., by using internal timers) in 171 order to send periodic binding-refresh REGISTER requests, it might 172 still be useful to suspend the UA between the sending of binding- 173 refresh requests (as it will save battery life) and use push 174 notifications to wake the UA when an incoming SIP request UA arrives. 176 When a UA registers with a PNS (Figure 1), it will receive a unique 177 Push Resource ID (PRID) associated with the push notification 178 registration. The UA will use a REGISTER request to provide the PRID 179 to the SIP proxy, which will then request that push notifications are 180 sent to the UA. 182 When the SIP proxy receives a SIP request for a new dialog or a 183 stand-alone SIP request addressed towards a UA, or when the SIP proxy 184 determines that the UA needs to send a binding-refresh REGISTER 185 request, the SIP proxy will send a push request containing the PRID 186 of the UA to the PNS, which will then send a push notification to the 187 UA. Once the UA receives the push notification, it will be able to 188 send a binding-refresh REGISTER request. The proxy receives the 189 REGISTER request from the UA and forwards it to the SIP registrar 190 [RFC3261]. After accepting the REGISTER request, the SIP registrar 191 sends a 2xx response to the proxy, which forwards the response to the 192 UA. If the push notification request was triggered by a SIP request 193 addressed towards the UA, the proxy can then forward the SIP request 194 to the UA using normal SIP routing procedures. In some cases the 195 proxy can forward the SIP request without waiting for the SIP 2xx 196 response to the REGISTER request from the SIP registrar. Note that 197 this mechanism necessarily adds delay to responding to requests 198 requiring push notification. The consequences of that delay are 199 discussed in Section 5.6.2. 201 If there are Network Address Translators (NATs) between the UA and 202 the proxy, the REGISTER request sent by the UA will create NAT 203 bindings that will allow the incoming SIP request that triggered the 204 push notification to reach the UA. 206 NOTE: The lifetime of any NAT binding created by the REGISTER request 207 only needs to be long enough in order for the SIP request that 208 triggered the push notification to reach the UA. 210 Figure 1 shows the generic push notification architecture supported 211 by the mechanism in this document. 213 The SIP proxy MUST be in the signalling path of REGISTER requests 214 sent by the UA towards the registrar, and of SIP requests (for a new 215 dialog or a stand-alone) forwarded by the proxy responsible for the 216 UA's domain (sometimes referred to as home proxy, S-CSCF, etc.) 217 towards the UA. The proxy can also be co-located with the proxy 218 responsible for the UA's domain. This will also ensure that the 219 Request-URI of SIP requests (for a new dialog or a stand-alone) can 220 be matched against contacts in REGISTER requests. 222 +--------+ +---------+ +-----------+ +-------------+ 223 | | | | | | | SIP | 224 | SIP UA | | Push | | SIP Proxy | | Registrar / | 225 | | | Service | | | | Home Proxy | 226 +--------+ +---------+ +-----------+ +-------------+ 227 | | | | 228 | Subscribe | | | 229 |---------------->| | | 230 | | | | 231 | PRID | | | 232 |<----------------| | | 233 | | | | 234 | SIP REGISTER (PRID) | | 235 |===================================>| | 236 | | |SIP REGISTER (PRID)| 237 | | |==================>| 238 | | | | 239 | | | SIP 200 OK | 240 | | |<==================| 241 | SIP 200 OK | | | 242 |<===================================| | 243 | | | | 244 | | | | 245 | | | | 246 | | | SIP INVITE (PRID) | 247 | | |<==================| 248 | | | | 249 | |Push Request (PRID) | 250 | |<-----------------| | 251 |Push Message (PRID) | | 252 |<----------------| | | 253 | | | | 254 | SIP REGISTER (PRID) | | 255 |===================================>| | 256 | | |SIP REGISTER (PRID)| 257 | | |==================>| 258 | | | | 259 | | | SIP 200 OK | 260 | | |<==================| 261 | SIP 200 OK | | | 262 |<===================================| | 263 | | | | 264 | SIP INVITE | | | 265 |<===================================| | 266 | | | | 268 ------- Push Notification API 270 ======= SIP 272 Figure 1: SIP Push Information Flow 274 Example of a SIP REGISTER request in the flow above: 276 REGISTER sip:alice@example.com SIP/2.0 277 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 278 Max-Forwards: 70 279 To: Alice 280 From: Alice ;tag=456248 281 Call-ID: 843817637684230@998sdasdh09 282 CSeq: 1826 REGISTER 283 Contact: 287 Expires: 7200 288 Content-Length: 0 290 Figure 2: SIP REGISTER Example 292 2. Conventions 294 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 295 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 296 "OPTIONAL" in this document are to be interpreted as described in BCP 297 14 [RFC2119] [RFC8174] when, and only when, they appear in all 298 capitals, as shown here. 300 3. Push Resource ID (PRID) 302 When a SIP UA registers with a PNS it receives a unique Push Resource 303 ID (PRID), which is a value associated with the registration that can 304 be used to generate push notifications. 306 The format of the PRID varies depending on the PNS. 308 The details regarding discovery of the PNS, and the procedures 309 regarding the push notification registration and maintenance are 310 outside the scope of this document. The information needed to 311 contact the PNS is typically pre-configured in the operating system 312 of the device. 314 4. SIP User Agent (UA) Behavior 316 4.1. REGISTER 318 This section describes how a SIP UA sends SIP REGISTER requests 319 (either an initial REGISTER request for a binding or a binding- 320 refresh REGISTER request) in order to request and disable push 321 notifications from a SIP network, and to query the types of PNSs 322 supported by the SIP network. 324 Unless specified otherwise, the normal SIP UA registration procedures 325 [RFC3261] apply. The additional procedures described in this section 326 apply when the REGISTER request contains a pn-provider SIP URI 327 parameter in the Contact header field URI (Figure 2). 329 The procedures in this section apply to individual bindings 330 [RFC3261]. If a UA creates multiple bindings (e.g., one for IPv4 and 331 one for IPv6) the UA needs to perform the procedures for each 332 binding. 334 NOTE: Since a push notification will trigger the UA to refresh all 335 bindings, if a SIP UA has created multiple bindings, it is preferable 336 if one can ensure that all bindings expire at the same time to help 337 prevent some bindings from being refreshed earlier than needed. 339 For privacy and security reasons, a UA MUST NOT insert the SIP URI 340 parameters (except for the pn-purr parameter) defined in this 341 specification in non-REGISTER requests in order to prevent the PNS 342 information associated with the UA from reaching the remote peer. 343 For example, the UA MUST NOT insert the pn-prid SIP URI parameter in 344 the Contact header field URI of an INVITE request. REGISTER requests 345 will not reach the remote peer, as they will be terminated by the 346 registrar of the UA. However, the registrar MUST still ensure that 347 the parameters are not sent to other users, e.g., using the SIP event 348 package for registrations mechanism [RFC3680]. See Section 13 for 349 more information. 351 4.1.1. Request Push Notifications 353 This section describes the procedures that a SIP UA follows to 354 request push notifications from the SIP network. The procedures 355 assume that the UA has retrieved a PRID from a PNS. The procedures 356 for retrieving the PRID from the PNS are PNS-specific and outside the 357 scope of this specification. See PNS-specific documentation for more 358 details. 360 This specification does not define a mechanism to explicitly request 361 push notifications from the SIP network for usages other than 362 triggering binding-refresh REGISTER requests (e.g., for sending 363 periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does 364 it describe how to distinguish push notifications associated with 365 such usages from the push notifications used to trigger binding- 366 refresh REGISTER requests. If a SIP UA wants to use push 367 notifications for other usages, the UA can perform actions associated 368 with such usages (in addition to sending a binding-refresh REGISTER 369 request) whenever it receives a push notification by using the same 370 refresh interval that is used for the binding-refreshes. 372 To request push notifications from the SIP network, the UA MUST 373 insert the following SIP URI parameters in the SIP Contact header 374 field URI of the REGISTER request: pn-provider, pn-prid and pn-param 375 (if required for the specific PNS). The pn-provider URI parameter 376 indicates the type of PNS to be used for the push notifications. 378 If the UA receives a 2xx response to the REGISTER request that 379 contains a Feature-Caps header field [RFC6809] with a 'sip.pns' 380 feature-capability indicator, with an indicator value identifying the 381 same type of PNS that was identified by the pn-provider URI parameter 382 in the REGISTER request, it indicates that another SIP Proxy in the 383 SIP network will request that push notifications are sent to the UA. 384 In addition, if the same Feature-Caps header field contains a 385 'sip.vapid' feature-capability indicator, it indicates that the proxy 386 supports use of the Voluntary Application Server Identification 387 (VAPID) mechanism [RFC8292] to restrict push notifications to the UA. 389 NOTE: The VAPID specific procedures of the SIP UA are outside the 390 scope of this document. 392 If the UA receives a non-2xx response to the REGISTER, or if the UA 393 receives a 2xx response that does not contain a Feature-Caps header 394 field [RFC6809] with a 'sip.pns' feature-capability indicator, the UA 395 MUST NOT assume the proxy will request that push notifications are 396 sent to the UA. The actions taken by the UA in such cases are 397 outside the scope of this document. 399 If the PRID is only valid for a limited time then the UA is 400 responsible for retrieving a new PRID from the PNS and sending a 401 binding-refresh REGISTER request with the updated pn- parameters. If 402 a PRID is no longer valid, and the UA is not able to retrieve a new 403 PRID, the UA MUST disable the push notifications associated with the 404 PRID (Section 4.1.2). 406 4.1.2. Disable Push Notifications 408 When a UA wants to disable previously requested push notifications, 409 the UA SHOULD remove the binding [RFC3261], unless the UA is no 410 longer able to perform SIP procedures (e.g., due to a forced shutdown 411 of the UA) in which case the registrar will remove the binding once 412 it expires. When the UA sends the REGISTER request for removing the 413 binding, the UA MUST NOT insert the pn-prid SIP URI parameter in the 414 Contact header field URI of the REGISTER request, in order to inform 415 the SIP network that the UA no longer wants to receive push 416 notifications associated with the PRID. 418 4.1.3. Receive Push Notifications 420 When a UA receives a push notification, the UA MUST send a binding- 421 refresh REGISTER request. The UA MUST insert the same set of pn- SIP 422 URI parameters in the SIP Contact header field URI of the REGISTER 423 request that it inserted when it requested push notifications 424 (Section 4.1.1). Note that, in some cases the PNS might update the 425 PRID value, in which case the UA will insert the new value in the pn- 426 prid SIP URI parameter of the binding-refresh REGISTER request. 428 Once the UA has received a 2xx response to the REGISTER request, the 429 UA might receive a SIP request for a new dialog (e.g., a SIP INVITE), 430 or a stand-alone SIP request (e.g., a SIP MESSAGE), if such SIP 431 request triggered the proxy to request that the push notification was 432 sent to the UA. Note that, depending on which transport protocol is 433 used, the SIP request might reach the UA before the REGISTER 434 response. 436 If the SIP UA has created multiple bindings, the UA MUST send a 437 binding-refresh REGISTER request for each of those bindings when it 438 receives a push notification. 440 This specification does not define any usage of push notification 441 payload. If a SIP UA receives a push notification that contains a 442 payload the UA can discard the payload, but the UA will still send a 443 binding-refresh REGISTER request. 445 4.1.4. Sending Binding-Refresh Requests Using Non-Push Mechanism 447 If a UA is able to send binding-refresh REGISTER requests using a 448 non-push mechanism (e.g., using an internal timer that periodically 449 wakes the UA) the UA MUST insert a 'sip.pnsreg' media feature tag 450 [RFC3840] in the Contact header field of each REGISTER request. 452 If the UA receives a 2xx response to the REGISTER request that 453 contains a Feature-Caps header field with a 'sip.pnsreq' feature- 454 capability indicator, the UA MUST send a binging-refresh REGISTER 455 request prior to binding expiration. The indicator value indicates 456 the minimum time (given in seconds), prior to the binding expiration 457 when the UA needs to send the REGISTER request. 459 If the UA receives a 2xx response to the REGISTER request that does 460 not contain a Feature-Caps header field with a 'sip.pnsreq' feature- 461 capability indicator, the UA SHOULD only send a binding-refresh 462 REGISTER request when it receives a push notification (even if the UA 463 is able to use a non-push mechanism for sending binding-refresh 464 REGISTER requests), or when there are circumstances (e.g., if the UA 465 is assigned new contact parameters due to a network configuration 466 change) that require an immediate REGISTER request to be sent. 468 Even if the UA is able to to send binding-refresh REGISTER requests 469 using a non-push mechanism, the UA MUST still send a binding-refresh 470 REGISTER request whenever it receives a push notification 471 (Section 4.1.3). 473 NOTE: If the UA uses a non-push mechanism to wake and send binding- 474 refresh REGISTER requests, such REGISTER requests will update the 475 binding expiration timer, and the proxy does not need to request that 476 a push notification be sent to the UA in order to wake the UA. The 477 proxy will still request that a push notification be sent to the UA 478 when the proxy receives a SIP request addressed towards the UA 479 (Section 5.6.2). This allows the UA to e.g., use timers for sending 480 binding-refresh REGISTER requests, but to be suspended (in order to 481 save battery resources, etc.) between sending the REGISTER requests 482 and use push notification to wake the UA to process incoming calls. 484 Example of a SIP REGISTER request including a 'sip.pnsreg' 485 media feature tag: 487 REGISTER sip:alice@example.com SIP/2.0 488 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 489 Max-Forwards: 70 490 To: Alice 491 From: Alice ;tag=456248 492 Call-ID: 843817637684230@998sdasdh09 493 CSeq: 1826 REGISTER 494 Contact: ; 498 +sip.pnsreg 499 Expires: 7200 500 Content-Length: 0 502 Example of a SIP REGISTER response including a 'sip.pnsreg' 503 media feature tag and a 'sip.pnsreq' feature-capability indicator: 505 SIP/2.0 200 OK 506 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 507 To: Alice ;tag=123987 508 From: Alice ;tag=456248 509 Call-ID: 843817637684230@998sdasdh09 510 CSeq: 1826 REGISTER 511 Contact: ; 515 +sip.pnsreg 516 Feature-Caps: *;+sip.pns="acme";+sip.pnsreg="121" 517 Expires: 7200 518 Content-Length: 0 520 Figure 3: SIP REGISTER When Using Non-Push Mechanism Example 522 4.1.5. Query Network PNS Capabilities 524 This section describes how a SIP UA can query the types of PNSs 525 supported by a SIP network, and PNS-related capabilities (e.g., 526 support of the VAPID mechanism). When a UA performs a query, it does 527 not request push notifications from the SIP network. Therefore, the 528 UA can perform the query before it has registered to a PNS and 529 received a PRID. 531 In order to perform a query, the UA MUST insert a pn-provider SIP URI 532 parameter in the Contact header field URI of the REGISTER request: 534 o If the UA inserts a pn-provider parameter value, indicating 535 support of a type of PNS, the SIP network will only inform the UA 536 whether that type of PNS is supported. 537 o If the UA does not insert a pn-provider parameter value (i.e., it 538 inserts an "empty" pn-provider parameter) the SIP network will 539 inform the UA about all types of PNSs supported by the network. 540 This is useful e.g., if the UA supports more than one type of PNS. 541 Note that it is not possible to insert multiple parameter values 542 in the pn-provider parameter. 544 The UA MUST NOT insert a pn-prid SIP URI parameter in the Contact 545 header field URI of the REGISTER request. 547 If the UA receives a 2xx response to the REGISTER request, the 548 response will contain one or more Feature-Caps header fields with a 549 'sip.pns' feature-capability indicator, indicating the types of PNSs 550 supported by the SIP network. If the UA inserted a pn-provider SIP 551 URI parameter value in the REGISTER request, the response will only 552 indicate whether the SIP network supports the type of PNS supported 553 by the UA. 555 If the UA receives a 555 (Push Notification Service Not Supported) 556 response to the REGISTER request, and if the UA inserted a pn- 557 provider SIP URI parameter in the REGISTER request, the response 558 indicates that the network does not support the type of PNS that the 559 UA indicated support of. If the UA did not insert a pn-provider 560 parameter in the REGISTER request, the response indicates that the 561 network does not support any type of PNS, while still supporting the 562 555 (Push Notification Service Not Supported) response. 564 NOTE: It is optional for a UA to perform a query before it requests 565 push notifications from the SIP network. 567 5. SIP Proxy Behavior 569 5.1. PNS Provider 571 The type of PNS is identified by the pn-provider SIP URI parameter. 572 In some cases there might only be one PNS provider for a given type 573 of PNS, while in other cases there might be multiple providers. The 574 pn-param SIP URI parameter will provide more details associated with 575 the actual PNS provider to be used. 577 The protocol and format used for the push notification requests are 578 PNS-specific, and the details for constructing and sending a push 579 notification request are outside the scope of this specification. 581 5.2. SIP Request Push Bucket 583 When a SIP proxy receives a SIP request addressed towards a UA, that 584 will trigger the proxy to request that a push notification be sent to 585 the UA. The proxy will place the request in storage referred to as 586 the SIP Request Push Bucket, and the proxy starts a timer (referred 587 to as the Bucket Timer) associated with the transaction. A SIP 588 request is removed from the bucket when one of the following has 589 occurred: the proxy forwards the request towards the UA, when the 590 proxy sends an error response to the request, or when the Bucket 591 Timer times out. The detailed procedures are described in the 592 sections below. 594 Exactly how the SIP Request Push Bucket is implemented is outside the 595 scope of this document. One option is to use the PRID as a key to 596 search for SIP requests in the bucket. Note that mid-dialog requests 597 (Section 6) do not carry the PRID in the SIP request itself. 599 5.3. SIP URI Comparison Rules 601 By default, a SIP proxy uses the URI comparison rules defined in 602 [RFC3261]. However, when a SIP proxy compares the Contact header 603 field URI of a 2xx response to a REGISTER request with a Request-URI 604 of a SIP request in the SIP Request Push Bucket (Section 5.2), the 605 proxy uses the URI comparison rules with the following additions: the 606 pn-prid, pn-provider and pn-param SIP URI parameters MUST also match. 607 If a pn- parameter is present in one of the compared URIs but not in 608 the other URI, there is no match. 610 If only the pn- SIP URI parameters listed above match, but other 611 parts of the compared URIs do not match, a proxy MAY still consider 612 the comparison successful based on local policy. This can occur in a 613 race condition when the proxy compares the Contact header field URI 614 of a 2xx response to a REGISTER request with a Request-URI of a SIP 615 request in the SIP Request Push Bucket (Section 5.2), if the UA had 616 modified some parts of the Contact header field URI in the REGISTER 617 request but the Request-URI of the SIP request in the SIP Request 618 Push Bucket still contains the old parts. 620 5.4. Indicate Support of Type of PNS 622 A SIP proxy uses feature-capability indicators [RFC6809] to indicate 623 support of types of PNSs and additional features (e.g., VAPID) 624 associated associated with the type of PNS. A proxy MUST use a 625 separate Feature-Cap header field for each supported type of PNS. A 626 feature-capability indicator that indicates support of an additional 627 feature associated with a given type of PNS MUST be inserted in the 628 same Feature-Caps header field that is used to indicate support of 629 the type of PNS. 631 This specification defines the following feature-capability 632 indicators that a proxy can use to indicate support of additional 633 features associated with a given type of PNS: 'sip.vapid', 634 'sip.pnsreg' and 'sip.pnspurr'. These feature-capability indicators 635 MUST only be inserted in a Feature-Caps header field that also 636 contains a 'sip.pns' feature-capability indicator. 638 5.5. Trigger Periodic Binding Refresh 640 In order to request that a push notification be sent to a SIP UA, a 641 SIP proxy needs to have information about when a binding will expire. 642 The proxy needs to be able to retrieve the information from the 643 registrar using some mechanism, or run its own registration timers. 644 Such mechanisms are outside the scope of this document, but could be 645 implemented e.g., using the SIP event package for registrations 646 mechanism [RFC3680]. 648 When the proxy receives an indication that the UA needs to send a 649 binding-refresh REGISTER request, the proxy will request that a push 650 notification be sent to the UA. 652 Note that the push notification needs to be requested early enough 653 for the associated binding-refresh REGISTER request to reach the 654 registrar before the binding expires. It is RECOMMENDED that the 655 proxy requests the push notification at least 120 seconds before the 656 binding expires. 658 If the UA has indicated, using the 'sip.pnsreg' media feature tag, 659 that it is able to wake itself using a non-push mechanism in order to 660 send binding-refresh REGISTER requests, and if the proxy does not 661 receive a REGISTER request prior to 120 seconds before the binding 662 expires, the proxy MAY request that a push notification be sent to 663 the UA, to trigger the UA to send a binding-refresh REGISTER request. 665 NOTE: As described in Section 4.1.5, a UA might send a REGISTER 666 request without including a pn-prid SIP URI parameter, in order to 667 retrieve push notification capabilities from the network before the 668 UA expects to receive push notifications from the network. A proxy 669 will not request that push notifications are sent to a UA that has 670 not provided a pn-prid SIP URI parameter (Section 5.6.2). 672 If the proxy receives information that a binding associated with a 673 PRID has expired, or that a binding has been removed, the proxy MUST 674 NOT request that further push notifications are sent to the UA using 675 that PRID. 677 5.6. SIP Requests 679 5.6.1. REGISTER 681 This section describes how a SIP proxy processes SIP REGISTER 682 requests (initial REGISTER request for a binding, or a binding- 683 refresh REGISTER request). 685 The procedures in this section apply when the REGISTER request 686 contains a pn-provider SIP URI parameter in the Contact header field 687 URI. In other cases the proxy MUST skip the procdeures in this 688 section, and process the REGISTER request using normal SIP 689 procedures. 691 5.6.1.1. Request Push Notifications 693 This section describes the SIP proxy procedures when a SIP UA 694 requests push notifications from the SIP network. 696 The procedures in this section apply when the SIP REGISTER request 697 contains, in addition to the pn-provider SIP URI parameter, a pn-prid 698 SIP URI parameter in the Contact header field URI of the request. 700 When a proxy receives a REGISTER request that contains a Feature-Caps 701 header field with a 'sip.pns' feature-capability indicator, it 702 indicates that another proxy between this proxy and the UA supports 703 the type of PNS supported by the UA, and will request that push 704 notifications are sent to the UA. In such case, the proxy MUST skip 705 the rest of the procedures in this section, and process the REGISTER 706 request using normal SIP procedures. 708 When a proxy receives a REGISTER request that does not contain a 709 Feature-Caps header field with a 'sip.pns' feature-capability 710 indicator, the proxy processes the request according to the 711 procedures below: 713 o If the proxy does not support the type of PNS supported by the UA, 714 or if the REGISTER request does not contain all information 715 required for the type of PNS, the proxy SHOULD forward the request 716 towards the registrar and skip the rest of the procedures in this 717 section. If the proxy knows (by means of local configuration) 718 that no other proxies between itself and the registrar support the 719 type of PNS supported by the UA, the proxy MAY send a SIP 555 720 (Push Notification Service Not Supported) response instead of 721 forwarding the request. 722 o If the proxy supports the type of PNS supported by the UA, but 723 considers the requested binding expiration interval [RFC3261] to 724 be too short (see below), the proxy MUST either send a 423 725 (Interval Too Brief) response to the REGISTER request or forward 726 the request towards the registrar and skip the rest of the 727 procedures in this section. 728 o If the proxy supports the type of PNS supported by the UA, the 729 proxy MUST indicate support of that type of PNS (Section 5.4) in 730 the REGISTER request before it forwards the request towards the 731 registrar. This will inform proxies between the proxy and the 732 registrar that the proxy supports the type of PNS supported by the 733 UA, and that the proxy will request that push notifications are 734 sent to the UA. 736 A binding expiration interval MUST be considered too short if the 737 binding would expire before the proxy can request that a push 738 notification be sent to the UA to trigger the UA to send a binding- 739 refresh REGISTER request. The proxy MAY consider the interval too 740 short based on its own policy so as to reduce load on the system. 742 When a proxy receives a 2xx response to the REGISTER request, if the 743 proxy indicated support of a type of PNS in the REGISTER request (see 744 above), the proxy performs the following actions: 746 o If the proxy considers the binding expiration interval indicated 747 by the registrar too short (see above), the proxy forwards the 748 response towards the UA and MUST skip the rest of the procedures 749 in this section. 750 o The proxy MUST indicate support of the same type of PNS in the 751 REGISTER response. In addition: 753 * If the proxy supports the VAPID mechanism [RFC8292], the proxy 754 MUST indicate support of the mechanism, using the 'sip.vapid' 755 feature-capability indicator, in the REGISTER response. The 756 indicator value contains the public key identifying the proxy. 757 The proxy MUST determine whether the PNS provider supports the 758 VAPID mechanism before it indicates support of it. 759 * If the proxy received a 'sip.pnsreg' media feature tag in the 760 REGISTER request, the proxy SHOULD insert a 'sip.pnsreg' 761 feature-capability indicator with an indicator value bigger 762 than 120 in the response, unless the proxy always wants to 763 request that push notifications are sent to the UA in order to 764 trigger the UA to send a binding-refresh REGISTER request. 766 5.6.1.2. Query Network PNS Capabilities 768 This section describes the SIP proxy procedures when a SIP UA queries 769 about the push notification support in the SIP network 770 (Section 4.1.5). 772 The procedures in this section apply when the REGISTER request 773 contains a pn-provider SIP URI parameter, but does not contain a pn- 774 prid SIP URI parameter in the Contact header field URI of the 775 REGISTER request. 777 When a proxy receives a REGISTER request that contains a pn-provider 778 SIP URI parameter indicating the type of PNS supported by the UA, the 779 proxy MUST perform the following actions: 781 o If the proxy supports the type of PNS supported by the UA, the 782 proxy MUST indicate support of that type of PNS (Section 5.4) in 783 the REGISTER request before it forwards the request towards the 784 registrar. This will inform any other proxies between the proxy 785 and the registrar that the proxy supports the type of PNS 786 supported by the UA. 787 o If the proxy does not support the type of PNS supported by the UA, 788 and if the REGISTER request contains Feature-Caps header fields 789 indicating support of one or more types of PNSs, the proxy 790 forwards the request towards the registrar. 791 o If the proxy does not support the type of PNS supported by the UA, 792 and if the REGISTER request does not contain Feature-Caps header 793 fields indicating support of one or more types of PNSs, the proxy 794 MUST either forward the request towards the registrar, or send a 795 SIP 555 (Push Notification Service Not Supported) response towards 796 the UA. The proxy MUST NOT send a SIP 555 (Push Notification 797 Service Not Supported) response unless it knows (by means of local 798 configuration) that no other proxy supports any of the types of 799 PNSs supported by the UA. 801 When a proxy receives a REGISTER request, and the pn-provider SIP URI 802 parameter does not contain a parameter value, the proxy MUST indicate 803 support of each type of PNS supported by the proxy before it forwards 804 the request towards the registrar. 806 When a proxy receives a 2xx response to the REGISTER request, if the 807 proxy had indicated support of one or more types of PNSs in the 808 REGISTER request (see above), the proxy MUST indicate support of the 809 same set of types of PNSs in the response. In addition, if the proxy 810 supports the VAPID mechanism for one or more types of PNSs, the proxy 811 MUST indicate support of the mechanism for those PNSs in the 812 response. 814 5.6.2. Initial Request for Dialog or Stand-Alone Request 816 The procedures in this section apply when a SIP proxy has indicated 817 that the it will request that push notifications are sent to the SIP 818 UA. 820 When the proxy receives a SIP request for a new dialog (e.g., a SIP 821 INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE 822 request) addressed towards a SIP UA, if the Request-URI of the 823 request contains a pn-provider, a pn-prid and a pn-param (if required 824 for the specific PNS provider) SIP URI parameter, the proxy requests 825 that a push notification be sent to the UA using the information in 826 the pn- SIP URI parameters. The proxy then places the SIP request in 827 the SIP Request Push Bucket. The push notification will trigger the 828 UA to send a binding-refresh REGISTER request that the proxy will 829 process as described in Section 5.6.1. In addition, the proxy MUST 830 store the Contact URI of the REGISTER request during the lifetime of 831 the REGISTER transaction. 833 NOTE: If the proxy receives a SIP request that does not contain the 834 pn- SIP URI parameters listed above, the proxy processing of the 835 request is based on local policy. If the proxy also serves requests 836 for UAs that do not use the SIP push mechanism, the proxy can forward 837 the request towards the UA. Otherwise the proxy can reject the 838 request. 840 When the proxy receives a 2xx response to the REGISTER request, the 841 proxy performs the following actions: 843 o The proxy processes the REGISTER response as described in 844 Section 5.6.1. 845 o The proxy checks whether the SIP Request Push Bucket contains a 846 SIP request associated with the REGISTER transaction, by comparing 847 (Section 5.3) the Contact header field URI in the REGISTER 848 response with the Request-URIs of the SIP requests in the bucket. 849 If there is a match, the proxy MUST remove the SIP request from 850 the bucket and forward it towards the UA. 852 The reason the proxy needs to wait for the REGISTER response before 853 forwarding a SIP request towards a UA is to make sure that the 854 REGISTER request has been accepted by the registrar, and that the UA 855 that initiated the REGISTER request is authorized to receive messages 856 for the Request-URI. 858 If the proxy receives a non-2xx response to the REGISTER request, the 859 proxy compares the Contact URI stored from the REGISTER request (see 860 above) with the Request-URIs of the SIP requests in the SIP Request 861 Push Bucket. If there is a match, the proxy SHOULD remove the 862 associated request from the bucket and send an error response to the 863 request. It is RECOMMENDED that the proxy sends either a 404 (Not 864 Found) response or a 480 (Temporarily Unavailable) response to the 865 SIP request, but other response codes can be used as well. However, 866 if the REGISTER response is expected to trigger a new REGISTER 867 request from the UA (e.g., if the registrar is requesting the UA to 868 perform authentication) the proxy MAY keep the SIP request in the 869 bucket. 871 If the push notification request fails (see PNS-specific 872 documentation for details), the proxy MUST remove the SIP request 873 from the bucket and send an error response to the SIP request. It is 874 RECOMMENDED that the proxy sends either a 404 (Not Found) response or 875 a 480 (Temporarily Unavailable) response, but other response codes 876 can be used as well. 878 After the proxy has requested that a push notification be sent to a 879 UA, if the proxy does not receive a REGISTER response with a Contact 880 URI that matches the Request-URI of the SIP request before the Bucket 881 Timer (Section 5.2) associated with the SIP request times out, the 882 proxy MUST remove the SIP request from the SIP Request Push Bucket 883 (Section 5.2) and send a 480 (Temporarily Unavailable) response. The 884 Bucket Timer time-out value is set based on local policy, taking the 885 guidelines below into consideration. 887 As discussed in [RFC4320] and [RFC4321], non-INVITE transactions must 888 complete immediately or risk losing a race, which results in stress 889 on intermediaries and state misalignment at the endpoints. The 890 mechanism defined in this document inherently delays the final 891 response to any non-INVITE request that requires a push notification. 892 In particular, if the proxy forwards the SIP request towards the SIP 893 UA, the SIP UA accepts the request, but the transaction times out at 894 the sender before it receives the successful response, this will 895 cause state misalignment between the endpoints (the sender considers 896 the transaction a failure, while the receiver considers the 897 transaction a success). The SIP proxy needs to take this into 898 account when it sets the value of the Bucket Timer associated with 899 the transaction, to make sure that the error response (triggered by a 900 Bucket Timer time out) reaches the sender before the transaction 901 times out. If the accumulated delay of this mechanism combined with 902 any other mechanisms in the path of processing the non-INVITE 903 transaction cannot be kept short, this mechanism should not be used. 904 For networks encountering such conditions, an alternative (left for 905 possible future work) would be for the proxy to immediately return an 906 new error code meaning "wait at least the number of seconds specified 907 in this response, and retry your request" before initiating the push 908 notification. 910 NOTE: While this work on this document was ongoing, implementation 911 test results showed that the time it takes for a proxy to receive the 912 REGISTER request, from when the proxy has requested a push 913 notification, is typically around 2 seconds. However, the time might 914 vary depending on the characteristics and load of the SIP network and 915 the PNS. 917 In addition to the procedures described above there are two cases 918 where a proxy, as an optimization, can forward a SIP request towards 919 a UA without waiting for a 2xx response to a REGISTER request, or 920 without even requesting that a push notification be sent to the UA: 922 o If the proxy is able to authenticate the sender of the REGISTER 923 request and verify that it is allowed by authorization policy, the 924 proxy does not need to wait for the 2xx response before it 925 forwards the SIP request towards the UA. In such cases, the proxy 926 will use the Contact URI of the REGISTER request when comparing it 927 against the Request-URIs of the SIP requests in the SIP Request 928 Push Bucket. 929 o If the proxy has knowledge that the UA is awake, and that the UA 930 is able to receive the SIP request without first sending a 931 binding-refresh REGISTER request, the proxy does not need to 932 request that a push notification be sent to the UA (the UA will 933 not send a binding-refresh REGISTER request) before it forwards 934 the SIP request towards the UA. The mechanisms for getting such 935 knowledge might be dependent on implementation or deployment 936 architecture, and are outside the scope of this document. 938 Some PNS providers allow payload in the push notifications. This 939 specification does not define usage of such payload (in addition to 940 any payload that might be required by the PNS itself). 942 6. Support Of Longlived SIP Dialogs 944 Some SIP dialogs might have a long lifetime with little activity. 945 For example, when the SIP event notification mechanism [RFC6665] is 946 used, there might be a long period between the sending of mid-dialog 947 requests. Because of this, a SIP UA may be suspended, and may need 948 to be awakened in order to be able to receive mid-dialog requests. 950 SIP requests for a new dialog and stand-alone SIP requests addressed 951 towards a UA will pn- SIP URI parameters that allows the proxy to 952 request that a push notification be sent to the UA Section 5.6.2. 953 However, pn- SIP URI parameters will not be present in mid-dialog 954 requests addressed towards the UA. Instead, the proxy needs to 955 support a mechanism to store the information needed to request that a 956 push notification be sent to the UA, and to be able to retrieve that 957 information when it receives a mid-dialog request addressed towards 958 the UA. This section defines such mechanism. The SIP UA and SIP 959 proxy procedures in this section are applied in addition to the 960 generic procedures defined in this specification. 962 +--------+ +---------+ +-----------+ +-------------+ 963 | | | | | | | SIP | 964 | SIP UA | | Push | | SIP Proxy | | Registrar / | 965 | | | Service | | | | Home Proxy | 966 +--------+ +---------+ +-----------+ +-------------+ 967 | | | | 968 | PNS Register | | | 969 |---------------->| | | 970 | | | | 971 | PRID | | | 972 |<----------------| | | 973 | | | | 974 | SIP REGISTER (PRID) | | 975 |===================================>| | 976 | | |SIP REGISTER (PRID)| 977 | | |==================>| 978 | | | | 979 | | +-----------------------+ | 980 | | | Store PRID (key=PURR) | | 981 | | +-----------------------+ | 982 | | | | 983 | | | SIP 200 OK | 984 | | |<==================| 985 | SIP 200 OK (PURR) | | 986 |<===================================| | 987 | | | | 988 | | | | 989 | SIP INVITE (PURR) | | 990 |===================================>| | 991 | | |SIP INVITE (PURR) | 992 | | |==================>| 993 | | | | 994 | | | SIP 200 OK | 995 | | |<==================| 996 | SIP 200 OK | | | 997 |<===================================| | 998 | | | | 999 | | | | 1000 | | | | 1001 | | |SIP UPDATE (PURR) | 1002 | | |<==================| 1003 | | | | 1004 | | +-----------------------+ | 1005 | | | Fetch PRID (key=PURR) | | 1006 | | +-----------------------+ | 1007 | | | | 1008 | |Push Request (PRID) | 1009 | |<-----------------| | 1010 |Push Message (PRID) | | 1011 |<----------------| | | 1012 | | | | 1013 | SIP REGISTER (PRID) | | 1014 |===================================>| | 1015 | | |SIP REGISTER (PRID)| 1016 | | |==================>| 1017 | | | | 1018 | | | SIP 200 OK | 1019 | | |<==================| 1020 | SIP 200 OK (PURR) | | 1021 |<===================================| | 1022 | | | | 1023 | SIP UPDATE | | | 1024 |<===================================| | 1025 | | | | 1027 ------- Push Notification API 1029 ======= SIP 1031 Figure 4: SIP Push Longlived Dialog Flow 1033 6.1. SIP UA Behavior 1035 6.1.1. Initial Request for Dialog 1037 If the UA is willing to receive push notifications when a proxy 1038 receives a mid-dialog request addressed towards the UA, the UA MUST 1039 insert a 'pn-purr' SIP URI parameter (Section 6.2.1) in the Contact 1040 header field URI of the initial request for a dialog or the 2xx 1041 response to such requests. XXX The UA MUST insert a parameter value 1042 identical to the last 'sip.pnspurr' feature-capability indicator 1043 (Section 6.2.1) that it received in a REGISTER response. If the UA 1044 has not recived a 'sip.pnspurr' feature-capability indicator, the UA 1045 MUST NOT insert a 'pn-purr' SIP URI parameter in a request or 1046 response. 1048 The UA makes the decision to receive push notifications triggered by 1049 incoming mid-dialog requests based on local policy. Such policy 1050 might be based on the type of SIP dialog, the type of media (if any) 1051 negotiated for the dialog [RFC3264], etc. 1053 NOTE: As the 'pn-purr' SIP URI parameter only applies to a given 1054 dialog, the UA needs to insert a 'pn-purr' parameter in the Contact 1055 header field URI of the request or response for each dialog in which 1056 the UA is willing to receive push notifications triggered by incoming 1057 mid-dialog requests. 1059 6.2. SIP Proxy Behavior 1061 6.2.1. REGISTER 1063 If the proxy supports requesting push notifications triggered by mid- 1064 dialog requests being sent to the registered UA, the proxy MUST store 1065 the information (the pn- SIP URI parameters) needed to request that 1066 push notifications are sent to the UA when a proxy receives an 1067 initial REGISTER request for a binding from the UA. In addition, the 1068 proxy MUST generate a unique (within the context of the proxy) value, 1069 referred to as the PURR (Proxy Unique Registration Reference), that 1070 can be used as a key to retrieve the information. 1072 In order to prevent client fingerprinting, the proxy MUST 1073 periodically generate a new PURR value (even if pn- parameters did 1074 not change). However, as long as there are ongoing dialogs 1075 associated with the old value, the proxy MUST store it so that it can 1076 request that push notifications are sent to the UA when it receives a 1077 mid-dialog request addressed towards the UA. In addition, the PURR 1078 value MUST be generated in such a way so that it is unforgeable, 1079 anonymous, and unlinkable to entities other than the proxy. It must 1080 not be possible for an attacker to generate a valid PURR, to 1081 associate a PURR with a specific user, or to determine when two PURRs 1082 correspond to the same user. It can be generated e.g., by utilizing 1083 a cryptographically secure random function with an appropriately 1084 large output size. 1086 Whenever the proxy receives a 2xx response to a REGISTER request, the 1087 proxy MUST insert a 'sip.pnspurr' feature-capability indicator with 1088 the latest PURR value (see above) in the response. 1090 6.2.2. Initial Request for Dialog 1092 When a proxy receives an initial request for a dialog from a UA that 1093 contains a 'pn-purr' SIP URI parameter in the Contact header field 1094 URI with a PURR value that the proxy has generated (Section 6.2.1), 1095 the proxy MUST add a Record-Route header to the request to insert 1096 itself in the dialog route [RFC3261] before forwarding the request. 1098 When the proxy receives an initial request for a dialog addressed 1099 towards the UA, and the proxy has generated a PURR value associated 1100 with the pn- parameters inserted in the SIP URI of the request 1101 (Section 6.2.2), the proxy MUST add a Record-Route header to the 1102 request, to insert itself in the dialog route [RFC3261] before 1103 forwarding the request. 1105 6.2.3. Mid-Dialog Request 1107 When the proxy receives a mid-dialog SIP request addressed towards 1108 the UA that contains a 'pn-purr' SIP URI parameter, and the proxy is 1109 able to retrieve the stored information needed to request that a push 1110 notification be sent to the UA (Section 6.2.1), the proxy MUST place 1111 the SIP request in the SIP Request Push Bucket and request that a 1112 push notification be sent to the UA. 1114 NOTE: The 'pn-purr' SIP URI parameter will either be carried in the 1115 Request-URI or in a Route header field [RFC3261] of the SIP request, 1116 depending on how the route set [RFC3261] of the mid-dialog SIP 1117 request has been constructed. 1119 When the proxy receives a 2xx response to a REGISTER request, the 1120 proxy checks whether the SIP Request Push Bucket contains a mid- 1121 dialog SIP request associated with the REGISTER transaction. If the 1122 bucket contains such request the proxy MUST remove the SIP request 1123 from the SIP Request Push Bucket and forward it towards the UA. 1125 Note that the proxy does not perform a URI comparison (Section 5.3) 1126 when processing mid-dialog requests, as a mid-dialog request will not 1127 contain the pn-prid, pn-provider and pn-param SIP URI parameters. 1128 The proxy only checks for a mid-dialog request that contains the PURR 1129 value associated with the REGISTER 2xx response. 1131 As described in Section 5.6.2, while waiting for the push 1132 notification request to succeed, and then for the associated REGISTER 1133 request and 2xx response, the proxy needs to take into consideration 1134 that the transaction associated with the mid-dialog request will 1135 eventually time out at the sender of the request (UAC), and the 1136 sender will consider the transaction a failure. 1138 When a proxy sends an error response to a mid-dialog request (e.g., 1139 due to a transaction time out), the proxy SHOULD select a response 1140 code that only impacts the transaction associated with the request 1141 [RFC5079]. 1143 7. Support Of SIP Replaces 1145 [RFC3891] defines a mechanism that allows a SIP UA to replace a 1146 dialog with another dialog. A UA that wants to replace a dialog with 1147 another one will send an initial request for the new dialog. The 1148 Request-URI of the request will contain Contact header field URI of 1149 the peer. 1151 If a SIP proxy wants to be able to request that a push notification 1152 be sent to a UA when it receives an initial request for a dialog that 1153 replaces an existing dialog, using the mechanism in [RFC3891], the 1154 proxy and the UA MUST perform the following actions: 1156 o The proxy MUST provide a PURR to the UA during registration 1157 (Section 6.2.1). 1158 o The UA MUST insert a 'pn-purr' SIP URI parameter in the Contact 1159 header field URI of the initial request for a dialog, or a 2xx 1160 response to such requests (Section 6.1.1). This includes dialogs 1161 replacing other dialogs, as those dialogs might also get replaced. 1162 o The proxy MUST apply the mechanism defined in Section 6.2.3 to 1163 place and retrieve the request from the SIP Request Push Bucket. 1165 In addition, the operator needs to make sure that the initial request 1166 for dialogs, addressed towards the UA using the contact of the 1167 replaced dialog, will be routed to the SIP proxy (in order to request 1168 that a push notification be sent to the UA). The procedures for 1169 doing that are operator specific, and are outside the scope of this 1170 specification. 1172 8. Grammar 1174 8.1. 555 (Push Notification Service Not Supported) Response Code 1176 The 555 response code is added to the "Server-Error" Status-Code 1177 definition. 555 (Push Notification Service Not Supported) is used to 1178 indicate that the server does not support the push notification 1179 service identified in a 'pn-provider' SIP URI parameter. 1181 The use of the SIP 555 response code is only defined for SIP REGISTER 1182 responses. 1184 8.2. sip.pns Feature-Capability Indicator 1186 The sip.pns feature-capability indicator, when inserted in a Feature- 1187 Caps header field of a SIP REGISTER request or a SIP 2xx response to 1188 a REGISTER request, indicates that the entity associated with the 1189 indicator supports the SIP push mechanism and the type of push 1190 notification service indicated by the indicator value. The values 1191 defined for the pn-provider SIP URI parameter are used as indicator 1192 values. 1194 pns-fc = "+sip.pns" EQUAL LDQUOT pns RDQUOT 1195 pns = tag-value 1197 tag-value = 1199 8.3. sip.vapid Feature-Capability Indicator 1201 The sip.vapid feature-capability indicator, when inserted in a SIP 1202 2xx response to a SIP REGISTER request, denotes that the entity 1203 associated with the indicator supports the Voluntary Application 1204 Server Identification (VAPID) [RFC8292] mechanism when the entity 1205 requests that a push notification be sent to a SIP UA. The indicator 1206 value is a public key identifying the entity that can be used by a 1207 SIP UA to restrict subscriptions to that entity. 1209 vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT 1210 vapid = tag-value 1212 tag-value = 1214 8.4. sip.pnsreg Feature-Capability Indicator 1216 The sip.pnsreg feature-capability indicator, when inserted in a SIP 1217 2xx response to a SIP REGISTER request, denotes that the entity 1218 associated with the indicator expects to receive binding-refresh 1219 REGISTER requests from the SIP UA associated with the binding before 1220 the binding expires, even if the entity does not request that a push 1221 notification be sent to the SIP UA in order to trigger the binding- 1222 refresh REGISTER requests. The indicator value conveys the minimum 1223 time (given in seconds), prior to the binding expiration when the UA 1224 MUST send the REGISTER request. 1226 pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT 1227 reg = 1*DIGIT 1229 DIGIT = 1231 8.5. sip.pnsreg Media Feature Tag 1233 The sip.pnsreg media feature tag, when inserted in the Contact header 1234 field of a SIP REGISTER request, indicates that the SIP UA associated 1235 with the tag is able to send binding-refresh REGISTER requests for 1236 the associated binding without being awakened by push notifications. 1237 The media feature tag has no values. 1239 pnsreg-mt = "+sip.pnsreg" 1241 8.6. sip.pnspurr Feature-Capability Indicator 1243 The sip.pnspurr feature-capability indicator, when inserted in a SIP 1244 2xx response to a SIP REGISTER request, denotes that the entity 1245 associated with the indicator will store information that can be used 1246 to associate a mid-dialog SIP request with the binding information in 1247 the REGISTER request. 1249 pnspurr-fc = "+sip.pnspurr" EQUAL LDQUOT pnspurr RDQUOT 1250 pnspurr = tag-value 1252 tag-value = 1254 8.7. SIP URI Parameters 1256 The section defines new SIP URI parameters by extending the grammar 1257 for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: 1259 uri-parameter =/ pn-provider / pn-param / pn-prid / pn-purr 1260 pn-provider = "pn-provider" [EQUAL pvalue] 1261 pn-param = "pn-param" EQUAL pvalue 1262 pn-prid = "pn-prid" EQUAL pvalue 1263 pn-purr = "pn-purr" EQUAL pvalue 1265 pvalue = 1266 EQUAL = 1268 The format and semantics of pn-prid and pn-param are 1269 specific to the pn-provider value. 1271 Parameter value characters that are not part of pvalue need to be 1272 escaped, as defined in RFC 3261. 1274 9. PNS Registration Requirements 1276 When a new value is registered to the PNS Sub-registry, a reference 1277 to a specification that describes the usage of the PNS associated 1278 with the value is provided. That specification MUST contain the 1279 following information: 1281 o The value of the pn-provider SIP URI parameter. 1282 o How the pn-prid SIP URI parameter value is retrieved and set by 1283 the SIP UA. 1284 o How the pn-param SIP URI parameter (if required for the specific 1285 PNS provider) value is retrieved and set by the SIP UA. 1287 10. pn-provider, pn-param and pn-prid URI Parameters for Apple Push 1288 Notification service 1290 When the Apple Push Notification service (APNs) is used, the PNS- 1291 related SIP URI parameters are set as described below. 1293 For detailed information about the parameter values: 1295 https://developer.apple.com/library/archive/documentation/NetworkingI 1296 nternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html 1297 [pns-apns]) 1299 The value of the pn-provider URI parameter is "apns". 1301 Example: pn-provider=apns 1303 The value of the pn-param URI parameter is a string that is composed 1304 of two values, separated by a period (.): Team ID and Topic. The 1305 Team ID is provided by Apple and is unique to a development team. 1307 The Topic consists of the Bundle ID, which uniquely identifies an 1308 application, and a service value that identifies a service associated 1309 with the application, separated by a period (.). For VoIP 1310 applications the service value is "voip". 1312 Example: pn-param=DEF123GHIJ.com.example.yourexampleapp.voip 1314 NOTE: The Bundle ID might contain one or more periods (.). Hence, 1315 within the pn-param value, the first period will be separating the 1316 Team ID from the Topic, and within the Topic the last period will be 1317 separating the Bundle ID from the service. 1319 The value of the pn-prid URI parameter is the device token, which is 1320 a unique identifier assigned by Apple to a specific app on a specific 1321 device. 1323 Example: pn-prid=00fc13adff78512 1325 11. pn-provider, pn-param and pn-prid URI Parameters for Google 1326 Firebase Cloud Messaging (FCM) push notification service 1328 When Firebase Cloud Messaging (FCM) is used, the PNS related URI 1329 parameters are set as described below. 1331 For detailed information about the parameter values: 1333 https://firebase.google.com/docs/cloud-messaging/concept-options 1334 [pns-fcm] 1336 The value of the pn-provider URI parameter is "fcm". 1338 The value of the pn-param URI parameter is the Project ID. 1340 The value of the pn-prid URI parameter is the Registration token, 1341 which is generated by the FCM SDK for each client app instance. 1343 12. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 1344 (Generic Event Delivery Using HTTP Push) 1346 When Generic Event Delivery Using HTTP Push is used, the PNS related 1347 URI parameters are set as described below. 1349 The value of the pn-provider URI parameter is "webpush". 1351 The value of the pn-param URI parameter MUST NOT be used. 1353 The value of the pn-prid URI parameter is the push subscription URI. 1355 See RFC 8030 [RFC8030] for more details. 1357 Note that encryption for web push [RFC8291] is not used, therefore 1358 parameters for message encryption are not defined in this 1359 specification. Web push permits the sending of a push message 1360 without a payload without encryption. 1362 13. Security Considerations 1364 The security considerations for the use and operation of any 1365 particular PNS (e.g., how users and devices are authenticated and 1366 authorized) is out of scope for this document. [RFC8030] documents 1367 the security considerations for the PNS defined in that 1368 specification. Security considerations for other PNSs are left to 1369 their respective specifications. 1371 Typically, the PNS requires the SIP proxy requesting push 1372 notifications to be authenticated and authorized by the PNS. In some 1373 cases the PNS also requires the SIP application (or the SIP 1374 application developer) to be identified in order for the application 1375 to request push notifications. Unless the PNS authenticates and 1376 authorizes the PNS, a malicious endpoint or network entity that 1377 managed to get access to the parameters transported in the SIP 1378 signalling might be able to request that push notifications are sent 1379 to a UA. Such push notifications will impact the battery life of the 1380 UA and trigger unnecessary SIP traffic. 1382 [RFC8292] defines a mechanism that allows a proxy to identity itself 1383 to a PNS, by signing a JWT sent to the PNS using a key pair. The 1384 public key serves as an identifier of the proxy, and can be used by 1385 devices to restrict push notifications to the proxy associated with 1386 the key. 1388 Operators MUST ensure that the SIP signalling is properly secured, 1389 e.g., using encryption, from malicious network entities. TLS MUST be 1390 used, unless the operators know that the signalling is secured using 1391 some other mechanism that provides strong crypto properties. 1393 In addition to the information that needs to be exchanged between a 1394 device and the PNS in order to establish a push notification 1395 subscription, the mechanism defined in this document does not require 1396 any additional information to be exchanged between the device and the 1397 PNS. 1399 The mechanism defined in this document does not require a proxy to 1400 insert any payload (in addition to possible payload used for the PNS 1401 itself) when requesting push notifications. 1403 Operators MUST ensure that the PNS-related SIP URI parameters 1404 conveyed by a user in the Contact URI of a REGISTER request are not 1405 sent to other users, or to non-trusted network entities. One way to 1406 convey contact information is by using the the SIP event package for 1407 registrations mechanism [RFC3680]. [RFC3680] defines generic 1408 security considerations for the SIP event package for registrations. 1409 As the PNS-related SIP URI parameters conveyed in the REGISTER 1410 request contain sensitive information, operators that support the 1411 event package MUST ensure that event package subscriptions are 1412 properly authenticated and authorized, and that the SIP URI 1413 parameters are not inserted in event notifications sent to other 1414 users, or to non-trusted network entities. 1416 14. IANA considerations 1418 [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the 1419 RFC number of this document.] 1421 14.1. SIP URI Parameters 1423 This section defines new SIP URI Parameters that extend the "SIP/SIPS 1424 URI Parameters" sub-registry [RFC3969] under the sip-parameters 1425 registry: http://www.iana.org/assignments/sip-parameters. 1427 14.1.1. pn-provider 1429 Parameter Name: pn-provider 1431 Predefined Values: No 1433 Reference: RFC XXXX 1435 14.1.2. pn-param 1437 Parameter Name: pn-param 1439 Predefined Values: No 1441 Reference: RFC XXXX 1443 14.1.3. pn-prid 1445 Parameter Name: pn-prid 1447 Predefined Values: No 1449 Reference: RFC XXXX 1451 14.1.4. pn-purr 1453 Parameter Name: pn-purr 1455 Predefined Values: No 1457 Reference: RFC XXXX 1459 14.2. SIP Response Codes 1461 14.2.1. 555 (Push Notification Service Not Supported) 1463 This section defines a new SIP response code that extends the 1464 "Response Codes" sub-registry [RFC3261] under the sip-parameters 1465 registry: http://www.iana.org/assignments/sip-parameters. 1467 Response Code Number: 555 1469 Default Reason Phrase: Push Notification Service Not Supported 1471 14.3. SIP Global Feature-Capability Indicator 1473 14.3.1. sip.pns 1475 This section defines a new feature-capability indicator that extends 1476 the "SIP Feature-Capability Indicator Registration Tree" sub-registry 1477 [RFC6809] under the sip-parameters registry: 1478 http://www.iana.org/assignments/sip-parameters. 1480 Name: sip.pns 1482 Description: This feature-capability indicator, when inserted in a 1483 Feature-Caps header field of a SIP REGISTER request or a SIP 2xx 1484 response to a REGISTER request, denotes that the entity 1485 associated with the indicator supports the SIP push mechanism 1486 and the type of push notification service conveyed by the 1487 indicator value. 1489 Reference: [RFCXXXX] 1491 Contact: IESG (iesg@ietf.org) 1493 14.3.2. sip.vapid 1495 This section defines a new feature-capability indicator that extends 1496 the "SIP Feature-Capability Indicator Registration Tree" sub-registry 1497 [RFC6809] under the sip-parameters registry: 1498 http://www.iana.org/assignments/sip-parameters. 1500 Name: sip.vapid 1502 Description: This feature-capability indicator, when inserted in a 1503 SIP 2xx response to a SIP REGISTER request, denotes that the 1504 entity associated with the indicator supports the Voluntary 1505 Application Server Identification (VAPID) mechanism when the 1506 entity requests that a push notifications be sent to a SIP UA. 1507 The indicator value is a public key identifying the entity, 1508 that can be used by a SIP UA to restrict subscriptions to that 1509 entity. 1511 Reference: [RFCXXXX] 1513 Contact: IESG (iesg@ietf.org) 1515 14.3.3. sip.pnsreg 1517 This section defines a new feature-capability indicator that extends 1518 the "SIP Feature-Capability Indicator Registration Tree" sub-registry 1519 [RFC6809] under the sip-parameters registry: 1520 http://www.iana.org/assignments/sip-parameters. 1522 Name: sip.pnsreg 1524 Description: This feature-capability indicator, when inserted in a 1525 SIP 2xx response to a SIP REGISTER request, denotes that the 1526 entity associated with the indicator expects to receive 1527 binding-refresh REGISTER requests for the binding from the SIP 1528 UA associated with the binding before the binding expires, even 1529 if the entity does not request that a push notification be sent 1530 to the SIP UA in order to trigger the binding-refresh REGISTER 1531 requests. The indicator value conveys the minimum time 1532 (given in seconds), prior to the binding expiration when the UA 1533 MUST send the REGISTER request. 1535 Reference: [RFCXXXX] 1537 Contact: IESG (iesg@ietf.org) 1539 14.3.4. sip.pnspurr 1541 This section defines a new feature-capability indicator that extends 1542 the "SIP Feature-Capability Indicator Registration Tree" sub-registry 1543 [RFC6809] under the sip-parameters registry: 1544 http://www.iana.org/assignments/sip-parameters. 1546 Name: sip.pnspurr 1548 Description: This feature-capability indicator, when inserted in a 1549 SIP 2xx response to a SIP REGISTER request, conveys that 1550 the entity associated with the indicator will store information 1551 that can be used to associate a mid-dialog SIP request with the 1552 binding information in the REGISTER request. The indicator 1553 value is an identifier that can be used a key to retrieve the 1554 binding information. 1556 Reference: [RFCXXXX] 1558 Contact: IESG (iesg@ietf.org) 1560 14.4. SIP Media Feature Tag 1561 14.4.1. sip.pnsreg 1563 This section defines a new media feature tag that extends the "SIP 1564 Media Feature Tag Registration Tree" sub-registry [RFC3840] under the 1565 Media Feature Tag registry: https://www.iana.org/assignments/media- 1566 feature-tags/media-feature-tags.xhtml. 1568 Media feature tag name: sip.pnsreg 1570 Summary of the media feature indicated by this feature tag: This 1571 media feature tag, when inserted in the Contact header field 1572 of a SIP REGISTER request, conveys that the SIP UA 1573 associated with the tag is able to send binding-refresh 1574 REGISTER requests associated with the registration without 1575 being awakened by push notifications. 1577 Values appropriate for use with this feature tag: none 1579 Related standards or documents: [RFCXXXX] 1581 Security considerations: This media feature tag does not introduce 1582 new security considerations, as it simply indicates support for 1583 a basic SIP feature. If an attacker manages to remove the media 1584 feature tag, push notifications will not be requested to be sent 1585 to the client. 1587 Contact: IESG (iesg@ietf.org) 1589 14.5. PNS Sub-registry Establishment 1591 This section creates a new sub-registry, "PNS", under the sip- 1592 parameters registry: http://www.iana.org/assignments/sip-parameters. 1594 The purpose of the sub-registry is to register SIP URI pn-provider 1595 values. 1597 When a SIP URI pn-provider value is registered in the sub-registry, 1598 it needs to meet the "Specification Required" policies defined in 1599 [RFC8126]. 1601 This sub-registry is defined as a table that contains the following 1602 three columns: 1604 Value: The token under registration 1606 Description: The name of the Push Notification Service (PNS) 1608 Document: A reference to the document defining the registration 1610 This specification registers the following values: 1612 Value Description Document 1613 ------- -------------------------------------- ---------- 1615 apns Apple Push Notification service [RFC XXXX] 1616 fcm Firebase Cloud Messaging [RFC XXXX] 1617 webpush Generic Event Delivery Using HTTP Push [RFC XXXX] 1619 15. Acknowledgements 1621 Thanks to Mickey Arnold, Paul Kyzivat, Dale Worley, Ranjit Avasarala, 1622 Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula, 1623 Liviu Chircu, Roman Shpount, Yehoshua Gev and Jean Mahoney for 1624 reading the text, and providing useful feedback. 1626 16. References 1628 16.1. Normative References 1630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1631 Requirement Levels", BCP 14, RFC 2119, 1632 DOI 10.17487/RFC2119, March 1997, . 1635 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1636 A., Peterson, J., Sparks, R., Handley, M., and E. 1637 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1638 DOI 10.17487/RFC3261, June 2002, . 1641 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1642 "Indicating User Agent Capabilities in the Session 1643 Initiation Protocol (SIP)", RFC 3840, 1644 DOI 10.17487/RFC3840, August 2004, . 1647 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1648 Protocol (SIP) "Replaces" Header", RFC 3891, 1649 DOI 10.17487/RFC3891, September 2004, . 1652 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1653 (IANA) Uniform Resource Identifier (URI) Parameter 1654 Registry for the Session Initiation Protocol (SIP)", 1655 BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, 1656 . 1658 [RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the 1659 Session Initiation Protocol (SIP)", RFC 5079, 1660 DOI 10.17487/RFC5079, December 2007, . 1663 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 1664 Indicate Support of Features and Capabilities in the 1665 Session Initiation Protocol (SIP)", RFC 6809, 1666 DOI 10.17487/RFC6809, November 2012, . 1669 [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic 1670 Event Delivery Using HTTP Push", RFC 8030, 1671 DOI 10.17487/RFC8030, December 2016, . 1674 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1675 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1676 May 2017, . 1678 [RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server 1679 Identification (VAPID) for Web Push", RFC 8292, 1680 DOI 10.17487/RFC8292, November 2017, . 1683 [pns-apns] 1684 Apple Inc, "Apple Push Notification Service", January 1685 2019, . 1689 [pns-fcm] Google Inc, "Firebase Cloud Messaging", January 2019, < 1690 https://firebase.google.com/docs/cloud-messaging/concept- 1691 options>. 1693 16.2. Informative References 1695 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1696 with Session Description Protocol (SDP)", RFC 3264, 1697 DOI 10.17487/RFC3264, June 2002, . 1700 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1701 Package for Registrations", RFC 3680, 1702 DOI 10.17487/RFC3680, March 2004, . 1705 [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the 1706 Session Initiation Protocol's (SIP) Non-INVITE 1707 Transaction", RFC 4320, DOI 10.17487/RFC4320, January 1708 2006, . 1710 [RFC4321] Sparks, R., "Problems Identified Associated with the 1711 Session Initiation Protocol's (SIP) Non-INVITE 1712 Transaction", RFC 4321, DOI 10.17487/RFC4321, January 1713 2006, . 1715 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1716 "Managing Client-Initiated Connections in the Session 1717 Initiation Protocol (SIP)", RFC 5626, 1718 DOI 10.17487/RFC5626, October 2009, . 1721 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1722 DOI 10.17487/RFC6665, July 2012, . 1725 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1726 Writing an IANA Considerations Section in RFCs", BCP 26, 1727 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1728 . 1730 [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, 1731 DOI 10.17487/RFC8291, November 2017, . 1734 Authors' Addresses 1736 Christer Holmberg 1737 Ericsson 1738 Hirsalantie 11 1739 Jorvas 02420 1740 Finland 1742 Email: christer.holmberg@ericsson.com 1744 Michael Arnold 1745 Metaswitch Networks 1746 100 Church Street 1747 Enfield EN2 6BQ 1748 United Kingdom 1750 Email: Michael.Arnold@metaswitch.com