idnits 2.17.1 draft-ietf-sipcore-sip-push-14.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 (August 30, 2018) is 2059 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 1061, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 1099, 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: March 3, 2019 Metaswitch Networks 6 August 30, 2018 8 Push Notification with the Session Initiation Protocol (SIP) 9 draft-ietf-sipcore-sip-push-14 11 Abstract 13 This document describes how a Push Notification Service (PNS) can be 14 used to wake suspended Session Initiation Protocol (SIP) User Agents 15 (UAs), using push notifications, for the UA to be able to send 16 binding refresh REGISTER requests and to receive receive incoming SIP 17 requests. The document defines new SIP URI parameters and new 18 feature-capability indicators that can be used in SIP messages to 19 indicate support of the mechanism defined in this document, to 20 exchange PNS information between the SIP User Agent (UA) and the SIP 21 entity that will request push notifications towards the UA, and to 22 trigger such push notification requests. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 3, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 6 61 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 6 62 4.1. Request Push Notifications from Network . . . . . . . . . 6 63 4.2. Query Network Push Notification Capabilities . . . . . . 9 64 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. PNS Provider . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. Trigger Periodic Binding Refresh . . . . . . . . . . . . 10 67 5.3. SIP Requests . . . . . . . . . . . . . . . . . . . . . . 10 68 5.3.1. REGISTER . . . . . . . . . . . . . . . . . . . . . . 10 69 5.3.2. Initial Request for Dialog or Stand-Alone Request . . 12 70 6. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 6.1. 555 (Push Notification Service Not Supported) Response 72 Code . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 6.2. 556 (Push Notification Failed) Response Code . . . . . . 15 74 6.3. sip.pns Feature-Capability Indicator . . . . . . . . . . 16 75 6.4. sip.vapid Feature-Capability Indicator . . . . . . . . . 16 76 6.5. sip.pnsreg Feature-Capability Indicator . . . . . . . . . 17 77 6.6. sip.pnsreg Media Feature Tag . . . . . . . . . . . . . . 17 78 6.7. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 17 79 7. PNS Registration Requirements . . . . . . . . . . . . . . . . 18 80 8. pn-provider, pn-param and pn-prid URI Parameters for Apple 81 Push Notification service . . . . . . . . . . . . . . . . . . 18 82 9. pn-provider, pn-param and pn-prid URI Parameters for Google 83 Firebase Cloud Messaging (FCM) push notification service . . 19 84 10. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 85 (Generic Event Delivery Using HTTP Push) . . . . . . . . . . 19 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 88 12.1. SIP URI Parameters . . . . . . . . . . . . . . . . . . . 20 89 12.1.1. pn-provider . . . . . . . . . . . . . . . . . . . . 21 90 12.1.2. pn-param . . . . . . . . . . . . . . . . . . . . . . 21 91 12.1.3. pn-prid . . . . . . . . . . . . . . . . . . . . . . 21 92 12.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 21 93 12.2.1. 555 (Push Notification Service Not Supported) . . . 21 94 12.2.2. 556 (Push Notification Failed) . . . . . . . . . . . 22 95 12.3. SIP Global Feature-Capability Indicator . . . . . . . . 22 96 12.3.1. sip.pns . . . . . . . . . . . . . . . . . . . . . . 22 97 12.3.2. sip.vapid . . . . . . . . . . . . . . . . . . . . . 22 98 12.3.3. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 23 99 12.4. SIP Media Feature Tag . . . . . . . . . . . . . . . . . 23 100 12.4.1. sip.pnsreg . . . . . . . . . . . . . . . . . . . . . 24 101 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 24 102 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 14.1. Normative References . . . . . . . . . . . . . . . . . . 25 105 14.2. Informative References . . . . . . . . . . . . . . . . . 26 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 108 1. Introduction 110 In order to save resources (e.g., battery life) some devices 111 (especially mobile devices) and operating systems will suspend 112 applications when not used. In some cases, internal timers cannot be 113 used to wake such applications, nor will incoming network traffic 114 wake the application. Instead, one way to wake the application is by 115 using a Push Notification Service (PNS). Typically each operating 116 system uses a dedicated PNS. For example, Apple iOS devices use the 117 Apple Push Notification service (APNs) while Android devices use the 118 Firebase Cloud Messaging (FCM) service. 120 Because of the restrictions above, Session Initiation Protocol (SIP) 121 User Agents (UAs) [RFC3261] can not be awoken, in order to send 122 binding refresh SIP REGISTER requests and to receive incoming SIP 123 requests, without using a PNS to wake the UA in order to perform 124 those functions. 126 Also, without being able to use internal timers in order to wake 127 applications, a UA will not be able to maintain connections e.g., 128 using the SIP Outbound Mechanism [RFC5626], as it requires the UA to 129 send periodic keep-alive messages. 131 This document describes how PNSs can be used to wake suspended UAs, 132 using push notifications, to be able to send binding refresh REGISTER 133 requests and to receive incoming SIP requests. The document defines 134 new SIP URI parameters and new feature-capability indicators 135 [RFC6809] that can be used in SIP messages to indicate support of the 136 mechanism defined in this document, to exchange PNS information 137 between the UA and the SIP entity (realized as a SIP proxy in this 138 document) that will request push notifications towards the UA, and to 139 request such push notification requests. 141 NOTE: Even if a UA is able to be awaken other means than receiving 142 push notifications (e.g., by using internal timers) in order to send 143 periodic binding refresh REGISTER requests, it might still be useful 144 to suspend the application between the sending of binding refresh 145 requests (as it will save battery life) and use push notifications to 146 wake the UA when an incoming SIP request UA arrives. 148 When a UA registers to a PNS, it will receive a unique Push Resource 149 ID (PRID) associated with the push notification registration. The UA 150 will use a REGISTER request to provide the PRID to the SIP proxy that 151 will request push notifications towards the UA. 153 When the proxy receives a SIP request for a new dialog, or a stand- 154 alone SIP request, addressed towards a UA, or when the proxy 155 determines that the UA needs to send a binding refresh REGISTER 156 request, the proxy will request a push notification towards the UA, 157 using the PNS of the UA. Once the UA receives the push notification, 158 it will be able to send a binding refresh REGISTER request and 159 receive the incoming SIP request. The proxy will receive the 160 REGISTER request. If the push notification request was triggered by 161 a SIP request addressed towards the UA (see above), once the REGISTER 162 request has been accepted by the SIP registrar [RFC3261], and the 163 associated SIP 2xx response has been forwarded by the proxy towards 164 the UA, the proxy can forward the SIP request towards the UA using 165 normal SIP routing procedures. In some cases the proxy can forward 166 the SIP request without waiting for the SIP 2xx response to the 167 REGISTER request. Note that this mechanism necessarily adds delay to 168 responding to non-INVITE requests requiring push notification. The 169 consequences of that delay are discussed in Section 5.3.2. 171 Different PNSs exist today. Some are based on the standardized 172 mechanism defined in [RFC8030], while others are proprietary (e.g., 173 the Apple Push Notification service). Figure 1 shows the generic 174 push notification architecture supported by the mechanism in this 175 document. 177 Each PNS uses PNS-specific terminology and function names. The 178 terminology in this document is meant to be PNS-independent. If the 179 PNS is based on [RFC8030], the SIP proxy takes the role of the 180 application server. 182 The proxy MUST be in the signalling path of REGISTER requests sent by 183 the UA towards the registrar, and of SIP requests (for a new dialog 184 or a stand-alone) forwarded by the proxy responsible for the UA's 185 domain (sometimes referred to as home proxy, S-CSCF, etc) towards the 186 UA. The proxy can also be co-located with the proxy responsible for 187 the UA's domain. This will also ensure that the Request-URI of SIP 188 requests (for a new dialog or a stand-alone) can be matched against 189 contacts in REGISTER requests. 191 +--------+ +--------------+ +-----------------+ 192 | SIP UA | | Push Service | | SIP Proxy | 193 +--------+ +--------------+ +-----------------+ 194 | | | 195 | Subscribe | | 196 |--------------------->| | 197 | | | 198 | Push Resource ID | | 199 |<---------------------| | 200 | | | 201 | SIP REGISTER (Push Resource ID) | 202 |===============================================>| 203 | | | SIP REGISTER 204 | | |============> 205 | | | 206 | | | SIP 200 OK 207 | | |<============ 208 | SIP 200 OK | | 209 |<===============================================| 210 | | | 211 | | | 212 | | | 213 | | | SIP INVITE 214 | | Push Message |<============ 215 | | (Push Resource ID) | 216 | Push Message |<------------------------| 217 | (Push Resource ID) | | 218 |<---------------------| | 219 | | | 220 | SIP REGISTER (Push Resource ID) | 221 |===============================================>| 222 | | | SIP REGISTER 223 | | |============> 224 | | | 225 | | | SIP 200 OK 226 | | |<============ 227 | SIP 200 OK | | 228 |<===============================================| 229 | | | 230 | SIP INVITE | | 231 |<===============================================| 232 | | | 234 ------- Push Notification API 236 ======= SIP 238 REGISTER sip:alice@example.com SIP/2.0 239 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 240 Max-Forwards: 70 241 To: Alice 242 From: Alice ;tag=456248 243 Call-ID: 843817637684230@998sdasdh09 244 CSeq: 1826 REGISTER 245 Contact: 249 Expires: 7200 250 Content-Length: 0 252 Figure 1: SIP Push Notification Architecture 254 2. Conventions 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 258 "OPTIONAL" in this document are to be interpreted as described in BCP 259 14 [RFC2119] [RFC8174] when, and only when, they appear in all 260 capitals, as shown here. 262 3. Push Resource ID (PRID) 264 When a SIP UA registers with a PNS it receives a unique Push Resource 265 ID (PRID), which is a value associated with the registration that can 266 be used to generate push notifications. 268 The format of the PRID may vary depending on the PNS. 270 The details regarding discovery of the PNS, and the procedures 271 regarding the push notification registration and maintenance are 272 outside the scope of this document. The information needed to 273 contact the PNS is typically pre-configured in the operating system 274 of the device. 276 4. SIP User Agent (UA) Behavior 278 4.1. Request Push Notifications from Network 280 Once the SIP UA has registered with the PNS, has received the PRID 281 (using the protocol and procedures associated with the PNS), if the 282 UA wants to receive push notifications (requested by the proxy), the 283 UA MUST include the following SIP URI parameters in the SIP Contact 284 header field URI of the REGISTER request: pn-provider, pn-prid and 285 pn-param (if required for the specific PNS). The pn-provider URI 286 parameter identifies the type of PNS, the pn-prid URI parameter 287 contains the PRID value and the pn-param URI parameter contains 288 additional PNS-specific information. 290 When the UA receives a 2xx response to the REGISTER request, if the 291 response contains a Feature-Caps header field [RFC6809] with a 292 'sip.pns' feature-capability indicator with a parameter value 293 identifying the same type of PNS that was identified by the pn- 294 provider URI parameter in the REGISTER request, the UA can assume 295 that a SIP proxy will request push notifications towards the UA. In 296 other cases, the UA MUST NOT assume that push notifications will be 297 requested, and the actions taken by the UA might be dependent on 298 implementation or deployment architecture, and are outside the scope 299 of this document. 301 In addition, if the response contains a Feature-Caps header field 302 with a 'sip.vapid' feature-capability indicator, the proxy supports 303 use of the Voluntary Application Server Identification (VAPID) 304 mechanism [RFC8292] to restrict push notifications to the proxy. 306 NOTE: The VAPID specific procedures of the SIP UA are outside the 307 scope of this document. 309 When the UA receives a push notification, it MUST send a binding 310 refresh REGISTER request, using normal SIP procedures. If there are 311 Network Address Translators (NATs) between the UA and the proxy, the 312 REGISTER request will create NAT bindings that will allow incoming 313 SIP requests to reach the UA. Once the UA has received a 2xx 314 response to the REGISTER request, the UA might receive a SIP request 315 for a new dialog (e.g., a SIP INVITE), or a stand-alone SIP request 316 (e.g., a SIP MESSAGE), if such SIP request triggered the push 317 notification request. Note that, depending on which transport 318 protocol is used, the SIP request might reach the UA before the 319 REGISTER response. 321 If the SIP UA has created multiple bindings (e.g., one for IPv4 and 322 one for IPv6), the UA MUST send a binding refresh REGISTER request 323 for each of those bindings when it receives a push notification. 325 If the UA is able to send binding refresh REGISTER requests using a 326 non-push mechanism (e.g., using an internal timer that periodically 327 wakes the UA), the UA MUST insert a 'sip.pnsreg' media feature tag 328 [RFC3840] in the Contact header field URI of each REGISTER request. 329 Then, if the response to the REGISTER request contains a 'sip.pnsreg' 330 feature-capability indicator with an indicator value, the UA MUST 331 send REGISTER requests prior to the registration expires. The 332 indicator value indicates a minimum time (given in seconds), prior to 333 the registration expires when the UA MUST send the REGISTER request. 334 Even if the UA is able to to send REGISTER requests using a non-push 335 mechanism, the UA MUST still send a REGISTER request when it receives 336 a push notification, following the procedures in this section. If 337 the REGISTER response does not contain a a 'sip.pnsreg' feature- 338 capability indicator, the UA SHOULD only send a re-registration 339 REGISTER request when it receives a push notification (even if the UA 340 is able to use a non-push mechanism for sending re-registration 341 REGISTER requests), or when there are circumstances (e.g., if the UA 342 is assigned new contact parameters due to a network configuration 343 change) that require an immediate REGISTER request to be sent. 345 NOTE: In some cases the UA might be able to use a non-push mechanism 346 to wake and send binding refresh REGISTER requests. Such REGISTER 347 request will update the registration expiration timer, and the proxy 348 does not need to request a push notification towards the UA in order 349 to wake the UA. The proxy will still request a push notification 350 towards the UA when the proxy receives a SIP request addressed 351 towards the UA (Section 5.3.2). This allows the UA to e.g., use 352 timers for sending binding refresh REGISTER requests, but to be 353 suspended (in order to save battery resources etc) between sending 354 the REGISTER requests and use push notification to wake the UA to 355 process incoming calls. 357 NOTE: This specification does not define any usage of a push 358 notification payload. As defined in Section 5.3.2, a proxy must not 359 include any payload in the push notification request. If a SIP UA 360 receives a push notification that contains a payload the UA can 361 discard the payload, but the UA will still send a binding refresh 362 REGISTER request. 364 NOTE: If the SIP UA application wants to use push notifications for 365 other purposes than to trigger binding refresh requests, it needs to 366 be able to distinguish between the different purposes when receiving 367 push notifications. Mechanisms for doing that are outside the scope 368 of this specification. 370 As long as the UA wants to receive push notifications (requested by 371 the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param 372 (if required for the specific PNS provider) SIP URI parameter in each 373 binding refresh REGISTER request. Note that, in some cases, the PNS 374 might update the PRID value, in which case the UA will include the 375 new value in the pn-prid SIP URI parameter in the binding refresh 376 REGISTER request. 378 If the UA no longer wants to receive push notifications (requested by 379 the proxy), the UA MUST send a binding refresh REGISTER request 380 without including the SIP URI parameters described above, or the UA 381 MUST remove the registration. 383 If a UA's subscription to a PNS (and the associated PRID) is only 384 valid for a limited time then the UA is responsible for retrieving 385 new subscription details from the PNS and sending a REGISTER request 386 with the updated pn parameters to the proxy prior to the expiry of 387 the existing subscription. If a UA's subscription to a PNS expires 388 then the UA MUST send a REGISTER without the pn parameters (to tell 389 the proxy that it no longer wants push notifications) or terminate 390 the registration. The exact mechanisms for expiry and renewal of 391 PRIDs will be PNS-specific and are outside the scope of this 392 document. 394 For privacy and security reasons, the UA MUST NOT include the SIP URI 395 parameters defined in this document in non-REGISTER request, to 396 prevent the PNS information associated with the UA from reaching the 397 remote peer. For example, the UA MUST NOT include the SIP URI 398 parameters in the Contact header field of an INVITE request. 400 4.2. Query Network Push Notification Capabilities 402 A SIP UA might need to query the network for push notification 403 capabilities (e.g., related to VAPID) before it registers with the 404 PNS, and before it indicates that it wants to receive push 405 notifications. The UA can do so by only including the pn-provider 406 SIP URI parameter in the SIP Contact header field URI of the REGISTER 407 request, but without including the pn-prid SIP URI parameter. Later, 408 once the UA has received a response to the REGISTER request, with the 409 push notification information from the network, if the UA wants to 410 receive push notifications, the UA will send a binding refresh 411 REGISTER request, including all pn- SIP URI parameters required by 412 the specific PNS, following the procedures in Section 4.1. 414 5. SIP Proxy Behavior 416 5.1. PNS Provider 418 The type of PNS is identified by the pn-provider SIP URI parameter. 420 The protocol and format used for the push notification requests are 421 PNS-specific, and the details for constructing and sending a push 422 notification request are outside the scope of this specification. 424 5.2. Trigger Periodic Binding Refresh 426 In order to request push notifications towards a SIP UA that will 427 trigger the UA to send binding refresh SIP REGISTER requests, the SIP 428 proxy needs to have information about when a registration will 429 expire. The proxy needs to be able to retrieve the information from 430 the registrar using some mechanism. Such mechanisms are outside the 431 scope of this document. 433 When the proxy receives an indication that the UA needs to send a 434 binding refresh REGISTER request, the proxy requests a push 435 notification towards the UA. 437 Note that the push notification needs to be requested early enough, 438 in order for the associated binding refresh REGISTER request to reach 439 the registrar before the registration expires. It is RECOMMENDED 440 that the proxy requests the push notification at least 120 seconds 441 before the registration expires. 443 If the UA has indicated, using the 'sip.pnsreg' media feature tag, 444 that it is able to wake using a non-push mechanism for sending 445 binding refresh REGISTER requests, if the proxy does not receive a 446 REGISTER request prior to 120 seconds before the registration 447 expires, the proxy MAY request a push notification towards the UA, to 448 trigger the UA to send a REGISTER request. 450 NOTE: As described in Section 4.2, a SIP UA might send a REGISTER 451 request without including a pn-prid SIP URI parameter, in order to 452 retrieve push notification capabilities from the network before the 453 UA expects to receive push notifications from the network. A proxy 454 will not request push notifications towards a UA that has not 455 provided a pn-prid SIP URI parameter. 457 If the proxy receives information that a registration has expired, 458 the proxy MUST NOT request further push notifications towards the UA. 460 5.3. SIP Requests 462 5.3.1. REGISTER 464 The procedures in this section apply when the SIP proxy receives a 465 SIP REGISTER request (initial REGISTER request for a registration, or 466 a binding refresh REGISTER request) that contains a pn-provider SIP 467 URI parameter identifying a type of PNS. If the proxy receives a 468 REGISTER request that does not contain a pn-provider SIP URI 469 parameter, or that removes the registration, the proxy MUST NOT 470 request push notifications towards the UA associated with the 471 REGISTER request, or perform any other procedures in this section. 473 As described in Section 4.2, a SIP UA might send a REGISTER request 474 without including a pn-prid SIP URI parameter in the Contact header 475 field URI, in order to retrieve push notification capabilities from 476 the network before the UA the proxy will request push notifications 477 towards the UA. The procedures in this section apply to both the 478 case when the REGISTER request contains a pn-prid SIP URI parameter, 479 and when it does not. 481 When the proxy receives a REGISTER request, if the REGISTER request 482 contains a Feature-Caps header field with a 'sip.pns' feature- 483 capability indicator, it indicates that an upstream proxy supports, 484 and will request (if the Contact header field URI of the REGISTER 485 request contains a pn-prid SIP URI parameter), push notifications 486 towards the UA. The proxy MUST skip the rest of the procedures in 487 this section, and process the REGISTER request using normal SIP 488 procedures. 490 If the proxy considers the requested registration expiration interval 491 [RFC3261] to be too short, the proxy MUST either send a 423 (Interval 492 Too Brief) response to the REGISTER request, or skip the rest of the 493 procedures in this section and process the REGISTER request using 494 normal SIP procedures. If the proxy sends a 423 (Interval Too Brief) 495 response, the proxy SHOULD insert a Feature-Caps header field with a 496 'sip.pns' feature-capability indicator in the response, identifying 497 each type of PNS that the proxy supports. Similarly, when the proxy 498 receives a 2xx response to the REGISTER request (see below), if the 499 proxy considers the registration expiration interval indicated by the 500 registrar too short, the proxy MUST NOT insert a Feature-Caps header 501 field with a 'sip.pns' feature-capability indicator in the response, 502 and the proxy MUST NOT request push notifications associated with the 503 registration. A registration expiration interval MUST be considered 504 too short if the interval is smaller than the time prior to 505 expiration that the proxy would request a push notification. The 506 proxy MAY consider the interval too small based on its own policy so 507 as to reduce load on the system. 509 Otherwise, if the pn-provider SIP URI parameter identifies a type of 510 PNS that the proxy does not support, or if the REGISTER request does 511 not contain all additional information required for the specific type 512 of PNS, the proxy MUST either forward the request (e.g., if the proxy 513 knows that a downstream proxy supports the type of PNS) or send a SIP 514 555 (Push Notification Service Not Supported) response to the 515 REGISTER request. If the proxy sends a SIP 555 (Push Notification 516 Service Not Supported) response Section 6.1, the proxy SHOULD insert 517 a Feature-Caps header field with a 'sip.pns' feature-capability 518 indicator in the response, identifying the type of each PNS that the 519 proxy supports. The decision whether to forward the request, or to 520 send a response, is done based on local policy. 522 If the proxy supports the type of PNS identified by the pn-provider 523 SIP URI parameter, the proxy MUST insert a Feature-Caps header field 524 with a 'sip.pns' feature-capability indicator, identifying the type 525 of PNS, in the REGISTER request before forwarding the REGISTER 526 request towards the registrar. This will inform downstream proxies 527 that the proxy supports, and will request (if the Contact header 528 field URI of the REGISTER request contains a pn-prid SIP URI 529 parameter), push notifications towards the UA. 531 If the proxy inserted a Feature-Caps header field with a 'sip.pns' 532 feature-capability indicator in the REGISTER request (see above), if 533 the proxy receives a 2xx response to the REGISTER request, the proxy 534 MUST insert a Feature-Caps header field with a 'sip.pns' feature- 535 capability indicator in the response, identifying the type of PNS. 536 This will inform the UA that the proxy supports, and will request (if 537 the Contact header field URI of the REGISTER request contained a pn- 538 prid SIP URI parameter), push notifications towards the UA. The 539 proxy MUST only indicate support of the same PNS that was identified 540 in the pn-provider SIP URI parameter in the REGISTER request. If the 541 proxy receives a receives a SIP 555 (Push Notification Service Not 542 Supported) response, the proxy SHOULD insert a Feature-Caps header 543 field with a 'sip.pns' feature-capability indicator in the response, 544 identifying the type of each PNS that the proxy supports. 546 In addition, if the proxy receives a 2xx response to the REGISTER 547 request: 549 o if the proxy supports, and will use, the VAPID mechanism, the 550 proxy MUST insert a Feature-Caps header field with a 'sip.vapid' 551 feature-capability indicator in the response. The header field 552 parameter contains the public key identifying the proxy [RFC8292]. 553 The proxy MUST be able to determine whether the PNS supports the 554 VAPID mechanism before it inserts the feature-capability 555 indicator. 556 o if the proxy received a 'sip.pnsreg' media feature tag in the 557 REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature- 558 capability indicator with an indicator value bigger than 120 in 559 the response, unless the proxy always want to request push 560 notifications to trigger the UA to send a REGISTER request. 562 5.3.2. Initial Request for Dialog or Stand-Alone Request 564 The procedures in this section apply when the SIP proxy has indicated 565 that it supports, and will request, push notifications towards the 566 SIP UA. 568 When the proxy receives a SIP request for a new dialog (e.g., a SIP 569 INVITE request) or a stand-alone SIP request (e.g., a SIP MESSAGE 570 request) addressed towards a SIP UA, if the Request-URI of the 571 request contains a pn-provider, a pn-prid and a pn-param (if required 572 for the specific PNS provider) SIP URI parameter, the proxy requests 573 a push notification towards the UA, using the PRID included in the 574 pn-prid SIP URI parameter and the PNS identified by the pn-provider 575 SIP URI parameter. 577 The push notification will trigger the UA to send a binding refresh 578 REGISTER request. The proxy will process the REGISTER request and 579 the associated response as described in Section 5.3.1. In case of a 580 2xx response to the REGISTER request, once the proxy has forwarded 581 the REGISTER response towards the UA, if the contact of the SIP 582 REGISTER request associated with the REGISTER response matches the 583 Request-URI of the SIP request to be forwarded, and the contact was 584 also present (and has not expired) in the REGISTER response, the 585 proxy can forward the SIP request towards the UA, using normal SIP 586 procedures. If the contact of the REGISTER request does not match 587 the Request-URI of the SIP request to be forwarded, or if the contact 588 was not present in the REGISTER response, the proxy MUST reject the 589 SIP request with a 404 (Not Found) response. This can happen if the 590 UA sends a binding refresh REGISTER request with a new contact at the 591 same time the registrar forwards a SIP request towards a UA using the 592 previously registered contact in the Request-URI. 594 When matching the Request-URI of the SIP request to be forwarded with 595 a contact of a REGISTER request, the proxy uses the URI comparison 596 rules in [RFC8292], with the following addition: the pn-prid SIP URI 597 parameter MUST also match. If the parameter is not present in the 598 Request-URI of the SIP request, or in the contact of the REGISTER, 599 there is no match. 601 The reason the proxy needs to wait for the REGISTER response before 602 forwarding the SIP request is to make sure that the REGISTER request 603 has been accepted by the registrar, and that the UA which initiated 604 the REGISTER request is authorized to receive messages for the 605 Request-URI. However, if the proxy is able to authorize the sender 606 of the REGISTER request, it does not need to wait for the associated 607 2xx response before it forwards the SIP request towards the UA. The 608 mechanism for authorizing the UA is outside the scope of this 609 document. 611 As both the SIP request to be forwarded towards the UA, and the 612 binding refresh REGISTER request triggered by the push notification 613 request, will convey pn- SIP URI parameters associated with the SIP 614 registration, those can be used to match the SIP request with the 615 binding refresh REGISTER request (even if the most recent contact and 616 the Request-URI of the SIP request do not match). 618 NOTE: The proxy needs to store (or be able to retrieve) the contact 619 of the most recent REGISTER 2xx response, to be able to compare it 620 with the Request-URI of the request to be forwarded towards the UA. 622 In case of non-2xx response to the REGISTER request, the proxy MUST 623 reject the SIP request with a 404 (Not Found) response. 625 If the push notification request fails (see PNS-specific 626 documentation for details), the proxy MUST reject the SIP request 627 with a 480 (Temporarily Unavailable) or a 556 (Push Notification 628 Failed) response. 630 NOTE; Before sending a 556 (Push Notification Failed) response, the 631 proxy operator needs to determine whether it could have privacy 632 implications. 634 If the proxy does not receive the REGISTER request from the UA within 635 a given time after the proxy has requested the push notification, the 636 proxy MUST reject the request with a 480 (Temporarily Unavailable) 637 response. The time value is set based on local policy. 639 As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must 640 complete immediately or risk losing race that results in stress on 641 intermediaries and state misalignment at the endpoints. The 642 mechanism defined in this document inherently delays the final 643 response to any non-INVITE request that requires a push notification. 644 In particular, while waiting for the push notification request to 645 succeed, and the associated REGISTER request to arrive from the SIP 646 UA, the proxy needs to take into consideration that the transaction 647 associated with the SIP request will eventually time out at the 648 sender of the request (UAC), and the sender will consider the 649 transaction a failure. If the proxy forwards the SIP request towards 650 the SIP UA, the SIP UA accepts the request and the transaction times 651 out at the sender before it receives the successful response, this 652 will cause state misalignment between the endpoints (the sender will 653 consider the transaction a failure, while the receiver will consider 654 the transaction a success). The SIP proxy needs to take this into 655 account when deciding for how long to wait before it considers the 656 transaction associated with the SIP request a failure, to make sure 657 that the error response reaches the sender before the transaction 658 times out. If the accumulated delay of this mechanism combined with 659 any other mechanisms in the path of processing the non-INVITE 660 transaction is not kept short, this mechanism should not be used. 661 For networks encountering such conditions, an alternative (left for 662 possible future work) would be for the proxy to immediately return an 663 new error code meaning "wait at least the number of seconds specified 664 in this response, and retry your request" before initiating the push 665 notification. 667 NOTE: While this work on this document was ongoing, implementation 668 test results showed that the time it takes for a proxy to receive the 669 REGISTER request, from when the proxy has requested a push 670 notification, is typically around 2 seconds. However, the time might 671 vary depending on the characteristics and load of the SIP network and 672 the PNS. 674 The proxy MUST NOT include the SIP request as payload in the 675 requested push message. 677 If the proxy has knowledge that the UA is wake, and that the UA is 678 able to receive the SIP request without first sending a REGISTER 679 request, the proxy MAY choose to not request a push notification 680 towards the UA (and wait for the associated REGISTER request and 2xx 681 response) before it tries to forward the SIP request towards the UA. 682 The mechanisms for getting such knowledge might be dependent on 683 implementation or deployment architecture, and are outside the scope 684 of this document. Similarly, if the Request-URI of the SIP request 685 only contains any pn-provider SIP URI parameter, but no other pn- SIP 686 URI parameters, e.g., because the SIP UA has not included them in a 687 REGISTER request (Section 4.2), the proxy is not able to request a 688 push notification towards the UA. If the proxy has knowledge that 689 the UA is wake, and that the UA is able to receive the SIP request, 690 the proxy MAY forwards the request towards the UA. Otherwise the 691 proxy MUST reject the SIP request with a 480 (Temporarily 692 Unavailable) or a 556 (Push Notification Failed) response. 694 6. Grammar 696 6.1. 555 (Push Notification Service Not Supported) Response Code 698 The 555 response code is added to the "Server-Error" Status-Code 699 definition. 555 (Push Notification Service Not Supported) is used to 700 indicate that the server did not support the push notification 701 service identified in a 'pn-provider' SIP URI parameter. 703 The use of the SIP 555 response code is defined for SIP REGISTER 704 responses. 706 6.2. 556 (Push Notification Failed) Response Code 708 The 556 response code is added to the "Server-Error" Status-Code 709 definition. 556 (Push Notification Failed) is used to indicate that 710 the server failed to request a push notification from the push 711 notification service identified in a 'pn-provider' SIP URI parameter. 713 The use of the SIP 556 response code is defined for responses to SIP 714 requests initiating dialogs, and responses to stand-alone SIP 715 requests. 717 6.3. sip.pns Feature-Capability Indicator 719 The sip.pns feature-capability indicator, when included in a Feature- 720 Caps header field of a SIP REGISTER request or a SIP 2xx response to 721 a REGISTER request, indicates that the entity associated with the 722 indicator supports, and will use, the SIP push mechanism and the push 723 notification service identified by the indicator value. When 724 included in a 555 (Push Notification Service Not Supported) response 725 to a REGISTER request, the the indicator indicates that the entity 726 associated with the indicator supports the SIP push mechanism, and 727 the push notification service(s) identified by the indicator value. 728 The values defined for the pn-provider SIP URI parameter are used as 729 indicator values. 731 pns-fc = "+sip.pns" EQUAL LDQUOT pns-list RDQUOT 732 pns-list = pns *(COMMA pns) 733 pns = tag-value 735 ; tag-value as defined in RFC 3840 737 6.4. sip.vapid Feature-Capability Indicator 739 The sip.vapid feature-capability indicator, when included in a SIP 740 2xx response to a SIP REGISTER request, indicates that the entity 741 associated with the indicator supports, and will use, the Voluntary 742 Application Server Identification (VAPID) [RFC8292] mechanism when 743 requesting push notifications towards the SIP UA associated with the 744 SIP registration. The indicator value is a public key identifying 745 the entity, that can be used by a SIP UA to restrict subscriptions to 746 that entity. 748 vapid-fc = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT 749 vapid = tag-value 751 ; tag-value as defined in RFC 3840 753 6.5. sip.pnsreg Feature-Capability Indicator 755 The sip.pnsreg feature-capability indicator, when included in a SIP 756 2xx response to a SIP REGISTER request, indicates that the entity 757 associated with the indicator expects to receive binding refresh 758 REGISTER requests from the SIP UA associated with the registration 759 before the registration expires, without the entity having to request 760 push notifications towards the SIP UA in order to trigger the 761 REGISTER requests. The indicator value is the minimum value (given 762 in seconds) before the registration expiration when the entity 763 expects to receive the REGISTER request. 765 pns-fc = "+sip.pnsreg" EQUAL LDQUOT reg RDQUOT 766 reg = 1*DIGIT 768 ; DIGIT as defined in RFC 3261 770 6.6. sip.pnsreg Media Feature Tag 772 The sip.pnsreg media feature tag, when included in the SIP Contact 773 header field of a SIP REGISTER request, indicates that the SIP UA 774 associated with the tag is able to send binding refresh REGISTER 775 requests associated with the registration without being awaken by 776 push notifications. The media feature tag has no values. 778 pnsreg-mt = "+sip.pnsreg" 780 6.7. SIP URI Parameters 782 The section defines new SIP URI parameters, by extending the grammar 783 for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: 785 uri-parameter =/ pn-provider / pn-param / pn-prid 786 pn-provider = "pn-provider" EQUAL pvalue 787 pn-param = "pn-param" EQUAL pvalue 788 pn-prid = "pn-prid" EQUAL pvalue 790 ; pvalue as defined in RFC 3261 791 ; EQUAL as defined in RFC 3261 792 ; COLON as defined in RFC 3261 794 The format and semantics of pn-prid and pn-param are 795 specific to the pn-provider value. 797 Parameter value characters that are not part of pvalue needs to be 798 escaped, as defined in RFC 3261. 800 7. PNS Registration Requirements 802 When a new value is registered to the PNS Sub-registry, a reference 803 to a specification which describes the PNS associated with the value 804 is provided. That specification MUST contain the following 805 information: 807 o The value of the pn-provider SIP URI parameter. 808 o How the pn-prid SIP URI parameter value is retrieved and set by 809 the SIP UA. 810 o How the pn-param SIP URI parameter (if required for the specific 811 PNS provider) value is retrieved and set by the SIP UA. 813 8. pn-provider, pn-param and pn-prid URI Parameters for Apple Push 814 Notification service 816 When the Apple Push Notification service (APNs) is used, the PNS- 817 related SIP URI parameters are set as described below. 819 The value of the pn-provider URI parameter is "apns". 821 Example: pn-provider = apns 823 The value of the pn-param URI parameter is the APNs App ID, which is 824 encoded by two values, separated by a period (.): Team ID and Bundle 825 ID. The Team ID is provided by Apple and is unique to a development 826 team. The Bundle ID is unique to a development team, and is a string 827 that will match a single application or a group of applications. 829 Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp 830 The value of the pn-prid URI parameter is the device token, which is 831 a unique identifier assigned by Apple to a specific app on a specific 832 device. 834 Example: pn-prid = 00fc13adff78512 836 For more information on the APNs App ID: 838 https://developer.apple.com/library/content/documentation/General/ 839 Conceptual/DevPedia-CocoaCore/AppID.html 841 For more information on the APNs device token: 843 https://developer.apple.com/library/content/documentation/NetworkingI 844 nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re 845 f/doc/uid/TP40008194-CH8-SW13 847 9. pn-provider, pn-param and pn-prid URI Parameters for Google Firebase 848 Cloud Messaging (FCM) push notification service 850 When Firebase Cloud Messaging (FCM) is used, the PNS related URI 851 parameters are set as described below. 853 The value of the pn-provider URI parameter is "fcm". 855 The value of the pn-param URI parameter is the Project ID. 857 The value of the pn-prid URI parameter is the Registration token, 858 which is generated by the FCM SDK for each client app instance. 860 For more information on the Project ID and Registration token: 862 https://firebase.google.com/docs/cloud-messaging/concept-options 864 10. pn-provider, pn-param and pn-prid URI Parameters for RFC 8030 865 (Generic Event Delivery Using HTTP Push) 867 When Generic Event Delivery Using HTTP Push is used, the PNS related 868 URI parameters are set as described below. 870 The value of the pn-provider URI parameter is "webpush". 872 The value of the pn-param URI parameter MUST NOT be used. 874 The value of the pn-prid URI parameter is the push subscription URI. 876 See RFC 8030 for more details: 878 Note that encryption for web push [RFC8291] is not used, therefore 879 parameters for message encryption are not defined in this 880 specification. Web push permits the sending of a push message 881 without a payload without encryption. 883 11. Security Considerations 885 Different mechanisms exist for authenticating and authorizing devices 886 and users registering with a PNS. The mechanisms for authorizing and 887 authenticating the users are PNS-specific, and are outside the scope 888 of this document. In addition to the information that needs to be 889 exchanged between a device and the PNS in order to establish a push 890 notification subscription, the mechanism defined in this document 891 does not require any additional information to be exchanged between 892 the device and the PNS. 894 Typically, the PNS also requires the SIP proxy requesting push 895 notifications to be authenticated and authorized by the PNS. In some 896 cases the PNS also require the SIP application (or the SIP 897 application developer) to be identified in order for the application 898 to request push notifications. 900 Operators MUST ensure that the SIP signalling is properly secured, 901 e.g., using encryption, from malicious middlemen, unless they are 902 sure that the signalling cannot be accessed and used maliciously 903 (e.g., to trigger push notifications towards a device) by a 904 middleman. 906 [RFC8292] defines a mechanism which allows a proxy to identity itself 907 to a PNS, by signing a JWT sent to the PNS using a key pair. The 908 public key serves as an identifier of the proxy, and can be used by 909 devices to restrict push notifications to the proxy associated with 910 the key. 912 The mechanism in this document does not require a proxy to include 913 any payload (in addition to possible payload used for the PNS itself) 914 when requesting push notifications. 916 12. IANA considerations 918 12.1. SIP URI Parameters 920 This section defines new SIP URI Parameters that extend the "SIP/SIPS 921 URI Parameters" sub-registry [RFC3969] under the sip-parameters 922 registry: http://www.iana.org/assignments/sip-parameters. 924 12.1.1. pn-provider 926 Parameter Name: pn-provider 928 Predefined Values: No 930 Reference: RFC XXXX 932 12.1.2. pn-param 934 Parameter Name: pn-param 936 Predefined Values: No 938 Reference: RFC XXXX 940 12.1.3. pn-prid 942 Parameter Name: pn-prid 944 Predefined Values: No 946 Reference: RFC XXXX 948 12.2. SIP Response Codes 950 12.2.1. 555 (Push Notification Service Not Supported) 952 This section defines a new SIP response code that extends the 953 "Response Codes" sub-registry [RFC3261] under the sip-parameters 954 registry: http://www.iana.org/assignments/sip-parameters. 956 Response Code Number: 555 958 Default Reason Phrase: Push Notification Service Not Supported 960 12.2.2. 556 (Push Notification Failed) 962 This section defines a new SIP response code that extends the 963 "Response Codes" sub-registry [RFC3261] under the sip-parameters 964 registry: http://www.iana.org/assignments/sip-parameters. 966 Response Code Number: 556 968 Default Reason Phrase: Push Notififcation Failed 970 12.3. SIP Global Feature-Capability Indicator 972 12.3.1. sip.pns 974 This section defines a new feature-capability indicator that extends 975 the "SIP Feature-Capability Indicator Registration Tree" sub-registry 976 [RFC6809] under the sip-parameters registry: 977 http://www.iana.org/assignments/sip-parameters. 979 Name: sip.pns 981 Description: This feature-capability indicator, when included in a 982 Feature-Caps header field of a SIP REGISTER request or a SIP 2xx 983 response to a REGISTER request, indicates that the entity 984 associated with the indicator supports, and will use, the SIP 985 push mechanism and the push notification service identified by 986 the indicator value. When included in a 555 (Push Notification 987 Service Not Supported) response to a REGISTER request, the the 988 indicator indicates that the entity associated with the 989 indicator supports the SIP push mechanism, and the push 990 notification service(s) identified by the indicator value. 992 Reference: [RFCXXXX] 994 Contact: IESG (iesg@ietf.org) 996 12.3.2. sip.vapid 998 This section defines a new feature-capability indicator that extends 999 the "SIP Feature-Capability Indicator Registration Tree" sub-registry 1000 [RFC6809] under the sip-parameters registry: 1001 http://www.iana.org/assignments/sip-parameters. 1003 Name: sip.vapid 1005 Description: This feature-capability indicator, when included in a 1006 SIP 2xx response to a SIP REGISTER request, indicates that the 1007 entity associated with the indicator supports, and will use, 1008 the Voluntary Application Server Identification (VAPID) 1009 mechanism when requesting push notifications towards the SIP UA 1010 associated with the SIP registration. The indicator value is a 1011 public key identifying the entity, that can be used by a SIP UA 1012 to restrict subscriptions to that entity. 1014 Reference: [RFCXXXX] 1016 Contact: IESG (iesg@ietf.org) 1018 12.3.3. sip.pnsreg 1020 This section defines a new feature-capability indicator that extends 1021 the "SIP Feature-Capability Indicator Registration Tree" sub-registry 1022 [RFC6809] under the sip-parameters registry: 1023 http://www.iana.org/assignments/sip-parameters. 1025 Name: sip.pnsreg 1027 Description: This feature-capability indicator, when included in a 1028 SIP 2xx response to a SIP REGISTER request, indicates that the 1029 entity associated with the indicator expects to receive 1030 binding refresh REGISTER requests from the SIP UA associated 1031 with the registration before the registration expires, without 1032 the entity having to request push notifications towards the SIP 1033 UA in order to trigger the REGISTER requests. The indicator 1034 value is the minimum value (given in seconds) before the 1035 registration expireation when the entity expects to receive the 1036 REGISTER request. 1038 Reference: [RFCXXXX] 1040 Contact: IESG (iesg@ietf.org) 1042 12.4. SIP Media Feature Tag 1043 12.4.1. sip.pnsreg 1045 This section defines a new media feature tag that extends the "SIP 1046 Media Feature Tag Registration Tree" sub-registry [RFC3840] under the 1047 Media Feature Tag registry: https://www.iana.org/assignments/media- 1048 feature-tags/media-feature-tags.xhtml. 1050 Media feature tag name: sip.pnsreg 1052 Summary of the media feature indicated by this feature tag: This 1053 media feature tag, when included in the SIP Contact header 1054 field of a SIP REGISTER request, indicates that the SIP UA 1055 associated with the tag is able to send binding refresh 1056 REGISTER requests associated with the registration without 1057 being awaken by push notifications. 1059 Values appropriate for use with this feature tag: none 1061 Related standards or documents: [RFCXXXX] 1063 Security considerations: This media feature tag does not introduce 1064 new security considerations, as it simply indicates support for 1065 a basic SIP feature. If an attacker manages to remove the media 1066 feature tag, push notifications towards the client will be 1067 requested. 1069 Contact: IESG (iesg@ietf.org) 1071 12.5. PNS Sub-registry Establishment 1073 This section creates a new sub-registry, "PNS", under the sip- 1074 parameters registry: http://www.iana.org/assignments/sip-parameters. 1076 The purpose of the sub-registry is to register SIP URI pn-provider 1077 values. 1079 When a SIP URI pn-provider value is registered in the sub-registry, 1080 it needs to meet the "Specification Required" policies defined in 1081 [RFC8126]. 1083 This sub-registry is defined as a table that contains the following 1084 three columns: 1086 Value: The token under registration 1088 Description: The name of the Push Notification Service (PNS) 1090 Document: A reference to the document defining the registration 1092 This specification registers the following values: 1094 Value Description Document 1095 ------- -------------------------------------- ---------- 1097 apns Apple Push Notification service [RFC XXXX] 1098 fcm Firebase Cloud Messaging [RFC XXXX] 1099 webpush Generic Event Delivery Using HTTP Push [RFC XXXX] 1101 13. Acknowledgements 1103 Thanks to Mickey Arnold, Paul Kyzivat, Dale Worley, Ranjit Avasarala, 1104 Martin Thomson, Mikael Klein, Susanna Sjoholm, Kari-Pekka Perttula, 1105 Liviu Chircu, Roman Shpount and Yehoshua Gev for reading the text, 1106 and providing useful feedback. 1108 14. References 1110 14.1. Normative References 1112 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1113 Requirement Levels", BCP 14, RFC 2119, 1114 DOI 10.17487/RFC2119, March 1997, . 1117 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1118 A., Peterson, J., Sparks, R., Handley, M., and E. 1119 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1120 DOI 10.17487/RFC3261, June 2002, . 1123 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1124 "Indicating User Agent Capabilities in the Session 1125 Initiation Protocol (SIP)", RFC 3840, 1126 DOI 10.17487/RFC3840, August 2004, . 1129 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1130 (IANA) Uniform Resource Identifier (URI) Parameter 1131 Registry for the Session Initiation Protocol (SIP)", 1132 BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, 1133 . 1135 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 1136 Indicate Support of Features and Capabilities in the 1137 Session Initiation Protocol (SIP)", RFC 6809, 1138 DOI 10.17487/RFC6809, November 2012, . 1141 [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic 1142 Event Delivery Using HTTP Push", RFC 8030, 1143 DOI 10.17487/RFC8030, December 2016, . 1146 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1147 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1148 May 2017, . 1150 [RFC8292] Thomson, M. and P. Beverloo, "Voluntary Application Server 1151 Identification (VAPID) for Web Push", RFC 8292, 1152 DOI 10.17487/RFC8292, November 2017, . 1155 14.2. Informative References 1157 [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the 1158 Session Initiation Protocol's (SIP) Non-INVITE 1159 Transaction", RFC 4320, DOI 10.17487/RFC4320, January 1160 2006, . 1162 [RFC4321] Sparks, R., "Problems Identified Associated with the 1163 Session Initiation Protocol's (SIP) Non-INVITE 1164 Transaction", RFC 4321, DOI 10.17487/RFC4321, January 1165 2006, . 1167 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1168 "Managing Client-Initiated Connections in the Session 1169 Initiation Protocol (SIP)", RFC 5626, 1170 DOI 10.17487/RFC5626, October 2009, . 1173 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1174 Writing an IANA Considerations Section in RFCs", BCP 26, 1175 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1176 . 1178 [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, 1179 DOI 10.17487/RFC8291, November 2017, . 1182 Authors' Addresses 1184 Christer Holmberg 1185 Ericsson 1186 Hirsalantie 11 1187 Jorvas 02420 1188 Finland 1190 Email: christer.holmberg@ericsson.com 1192 Michael Arnold 1193 Metaswitch Networks 1194 100 Church Street 1195 Enfield EN2 6BQ 1196 United Kingdom 1198 Email: Michael.Arnold@metaswitch.com