idnits 2.17.1 draft-holmberg-sipcore-sip-push-03.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 (November 23, 2017) is 2343 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: 'RFC XXXX' is mentioned on line 454, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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 November 23, 2017 5 Expires: May 27, 2018 7 Push Notification with the Session Initiation Protocol (SIP) 8 draft-holmberg-sipcore-sip-push-03 10 Abstract 12 This document describes how push notification mechanisms can be used 13 to wake up suspended Session Initiation Protocol (SIP) User Agents 14 (UAs), in order to be able to receive and generate SIP requests. The 15 document defines new SIP URI parameters, that can be used in a SIP 16 REGISTER request to provide push notification information from the 17 SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in 18 this document) that will send a push request to the push server in 19 order to trigger a push notification towards the SIP UA. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 27, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Push Resource ID (PRID) . . . . . . . . . . . . . . . . . . . 5 58 4. SIP User Agent (UA) Behavior . . . . . . . . . . . . . . . . 5 59 5. SIP Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Push Notification Provider Information . . . . . . . . . 6 61 5.2. Trigger Periodic Re-registration . . . . . . . . . . . . 6 62 5.3. SIP Request . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Network Address Translator (NAT) Considerations . . . . . . . 7 64 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. PNS Registration Requirements . . . . . . . . . . . . . . . . 8 66 9. pn-prid and pn-type URI parameters for Apple Push 67 Notification service . . . . . . . . . . . . . . . . . . . . 8 68 10. pn-prid and pn-type URI parameters for Google Firebase Cloud 69 Messaging (FCM) push notification service . . . . . . . . . . 9 70 11. Security considerations . . . . . . . . . . . . . . . . . . . 9 71 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 72 12.1. pn-prid . . . . . . . . . . . . . . . . . . . . . . . . 10 73 12.2. pn-type . . . . . . . . . . . . . . . . . . . . . . . . 10 74 12.3. pn-enckey . . . . . . . . . . . . . . . . . . . . . . . 10 75 12.4. pn-enccode . . . . . . . . . . . . . . . . . . . . . . . 10 76 12.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 11 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 13.1. Normative references . . . . . . . . . . . . . . . . . . 11 79 13.2. Informative references . . . . . . . . . . . . . . . . . 12 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 In order to save resources (e.g, battery life) some devices and 85 operating systems require suspended Session Initiation Protocol (SIP) 86 User Agents (UAs) [RFC3261] to be woken up using a push notification 87 service. Typically each operating system uses a dedicated push 88 notification service. For example, Apple iOS devices use the Apple 89 Push Notification service (APNs). 91 Due to the restriction above, applications can not be woken up by 92 non-push notification traffic. This means that a suspended SIP UA 93 will not be able to receive an incoming SIP request (e.g., a SIP 94 INVITE request), or to send periodic re-registration requests. 96 This document describes how push notification mechanisms can be used 97 to wake up suspended SIP UAs, in order to be able to receive and 98 generate SIP requests. The document defines new SIP URI parameters, 99 that can be used in a SIP REGISTER request to provide push 100 notification information from the SIP UA to the SIP entity (realized 101 as a SIP proxy in this document) that will send a push request to the 102 push server in order to trigger a push notification towards the SIP 103 UA. 105 When a SIP UA registers to a push service, it will receive a unique 106 Push Resource ID (PRID) associated to that registration. The SIP UA 107 will provide the PRID to the SIP network in a SIP REGISTER request. 108 A SIP proxy (e.g., the SIP registrar) will store a mapping between 109 the registered contact and the PRID. 111 When the SIP proxy receives a SIP request for a new session, or a 112 stand-alone SIP request, addressed towards a SIP UA, or when the SIP 113 proxy determines that the SIP UA needs to perform a re-registration, 114 the SIP proxy will send a push request to the push notification 115 service used by the SIP UA, using the push resource ID associated 116 with the registered contact of the SIP UA, in order to trigger a push 117 notification towards the SIP UA. The SIP proxy will then forward the 118 SIP request towards the SIP UA using normal SIP routing procedures. 119 Once the SIP UA receives the push notification, it will be to receive 120 the SIP request, and to generate a SIP request (e.g., a SIP REGISTER) 121 itself. 123 Different push notification mechanisms exist today. Some are based 124 on there standardized mechanism defined in [RFC8030], while others 125 are proprietary (e.g., the Apple Push Notification service). 126 Figure 1 shows the generic push notification architecture supported 127 by the mechanism in this document. 129 +--------+ +--------------+ +-----------------+ 130 | SIP UA | | Push Service | | SIP Proxy | 131 +--------+ +--------------+ +-----------------+ 132 | | | 133 | Subscribe | | 134 |--------------------->| | 135 | | | 136 | Push Resource ID | | 137 |<---------------------| | 138 | | | 139 | SIP REGISTER (Push Resource ID) | 140 |===============================================>| 141 | | | 142 | | Push Message | 143 | | (Push Resource ID) | 144 | Push Message |<------------------------| 145 | (Push Resource ID) | | 146 |<---------------------| | 147 | | | 149 ------- Push Notification API 151 ======= SIP 153 REGISTER sip:alice@example.com SIP/2.0 154 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 155 Max-Forwards: 70 156 To: Alice 157 From: Alice ;tag=456248 158 Call-ID: 843817637684230@998sdasdh09 159 CSeq: 1826 REGISTER 160 Contact: 163 Expires: 7200 164 Content-Length: 0 166 Figure 1: SIP Push Notification Architecture 168 2. Conventions 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 3. Push Resource ID (PRID) 176 When an entity registers with a Push Notification Server (PNS) is 177 receives a unique Push Resource ID (PRID), which is a value 178 associated with the registration. 180 The format of the PRID may vary depending on the PNS provider. The 181 PRID may be part of a URI that can be used to retrieve the address 182 and port of the PNS when sending push requests to the PNS. The PRID 183 may also be a token value, in which case the address and port of the 184 PNS needs to be provided using other means. 186 The details regarding discovery of the PNS, and the procedures for 187 the push notification registration and maintenance are outside the 188 scope of this document. The information needed to contact the PNS is 189 typically pre-configured in the operating system (OS) of the device. 191 4. SIP User Agent (UA) Behavior 193 Once the SIP UA has registered with the PNS and received the PRID, 194 and when the UA wants to receive push notifications triggered by the 195 SIP proxy, the UA MUST send a SIP REGISTER using normal SIP 196 registration procedures. The UA MUST add a pn-prid URI parameter and 197 a pn-type URI parameter to the SIP Contact header field URI of the 198 request. The pn-prid URI parameter contains the PRID value. The pn- 199 type contains additional, PNS-specific, information. 201 When the SIP UA receives a push notification, it MUST perform a SIP 202 re-registration [RFC3261] by sending a SIP REGISTER request. If 203 there are Network Address Translators (NATs) between the SIP UA and 204 the SIP proxy, the SIP REGISTER request will create NAT bindings 205 allowing incoming SIP requests to reach the SIP UA. If the SIP proxy 206 triggered the push notification because it wants to forward a SIP 207 request towards the SIP UA, the receival of the SIP REGISTER request 208 can be used by the SIP proxy as a trigger to forward the SIP request. 210 As long as the UA wants the SIP proxy to continue sending push 211 requests, the UA MUST include the pn-prid and pn-type URI parameters 212 in every re-registration SIP REGISTER request sent towards the SIP 213 proxy. Note that, in some cases, the PNS might update the PRID 214 value, in which case the re-registration SIP REGISTER request will 215 contain the new value. 217 If the SIP UA at some point wants to stop the SIP proxy from sending 218 push requests, the SIP UA MUST send a SIP REGISTER request without 219 the pn-prid and pn-type URI parameters. 221 If the SIP UA expects to receive payload in the push notification, 222 the SIP UA MAY add a pn-enckey and a pn-encsec Contact header field 223 URI parameter, in order to allow encryption of the data using the 224 mechanism in [I-D.ietf-webpush-encryption]. The pn-enckey URI 225 parameter contains the public key, and the pn-encsec URI parameter 226 contains the authentication secret [I-D.ietf-webpush-encryption]. 228 NOTE: End-to-end encryption of the payload between the SIP proxy and 229 the SIP UA cannot be used if the push notification request payload 230 contains information that needs to be accessible by the push 231 notification server. 233 5. SIP Proxy Behavior 235 5.1. Push Notification Provider Information 237 In some cases the push notification provider can be retrieved from 238 the pn-prid URI parameter. In other cases the pn-type URI parameter 239 is used to identity the push notification provider. 241 The protocol and format used for the push request depends on the push 242 notification provider, and the details for constructing and sending 243 the messages are outside the scope of this specification. 245 5.2. Trigger Periodic Re-registration 247 If the SIP UA needs to perform periodic re-registrations, the SIP 248 proxy needs to have information about when those re-registrations are 249 to be performed. The SIP proxy either needs to contain the SIP 250 registrar functionality, or the SIP proxy needs to retreive the 251 information from the registrar using some other mechanism. 253 When the SIP proxy receives an indication that the SIP UA needs to 254 perform a re-registration, the SIP proxy triggers a push request 255 towards the push notification server associated with the PRID. 257 5.3. SIP Request 259 When the SIP proxy receives a SIP request for a new dialog (e.g., a 260 SIP INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE 261 request) aimed for a SIP UA, if the Request-URI of the request 262 contains a pn-prid URI parameter, the SIP proxy triggers a push 263 request towards the push notification server associated with the 264 PRID. After that, the SIP proxy forwards the SIP request towards the 265 SIP UA using normal SIP procedures. 267 As the push notification will trigger the SIP UA to perform a re- 268 registration, the SIP proxy can use the receival of the SIP REGISTER 269 request as a trigger to forward SIP request towards the SIP UA. 271 The SIP proxy MUST NOT transport the SIP request as push request 272 payload, instead of forwarding the request using normal SIP 273 procedures. 275 If the proxy is not able to contact the push notification provider, 276 or even determine which push notification provider to contact, it 277 SHOULD reject the SIP request. 279 If the SIP proxy is able to assume that the SIP UA is awake, and that 280 the SIP UA is able to receive the SIP request, the SIP proxy MAY 281 choose to not trigger a push notification request before trying to 282 forward the SIP request towards the SIP UA. The SIP proxy can make 283 such assumption e.g., if a TLS connection previously established by 284 the SIP UA is still open. 286 6. Network Address Translator (NAT) Considerations 288 Whenever the UA receives a push notification, if the SIP UA is 289 located behind a Network Address Translator (NAT), the UA might need 290 to take actions in order to establish a binding in the NAT, in order 291 for an incoming SIP request to reach the UA. By performing the re- 292 registration the SIP UA will establish such NAT binding. 294 7. Grammar 296 The section defines new SIP URI parameters, by extending the grammar 297 for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: 299 uri-parameter =/ pn-prid / pn-type / pn-enccode / pn-enckey 300 pn-prid = "pn-prid" EQUAL pvalue 301 pn-type = "pn-type" EQUAL pns-provider COLON pns-param 302 pn-enccode = "pn-enccode" EQUAL pvalue 303 pn-enckey = "pn-enckey" EQUAL pvalue 305 pns-provider = pvalue ; Colon (":") characters MUST be escaped 306 pns-param = pvalue ; Colon (":") characters MUST be escaped 308 ; pvalue as defined in RFC 3261 309 ; EQUAL as defined in RFC 3261 310 ; COLON as defined in RFC 3261 312 The format and semantics of pns-param is specific to a given 313 pns-provider value. 315 8. PNS Registration Requirements 317 When a new value is registered to the PNS Sub-registry, a reference 318 to a specification which describes the push notification service 319 associated with the value is provided. That specification MUST 320 contain the following information: 322 o How the values for the pn-prid parameter is retrieved and set by 323 the SIP UA. 324 o The format of the pns-param part of the pns-type parameter, and 325 how the value of the pns-param part is retrieved and set by the 326 SIP UA. 327 o Whether there are any restrictions regarding usage of payload 328 encryption [I-D.ietf-webpush-encryption] with the associated push 329 notification service. 331 9. pn-prid and pn-type URI parameters for Apple Push Notification 332 service 334 When the Apple Push Notification service (APNs) is used, the value of 335 the pn-type URI parameter pns-provider parameter part is "apns". The 336 pns-param part contains the APNs App ID, which is encoded by two 337 values, separated by a period (.): Team ID and Bundle ID. The Team 338 ID is provided by Apple and is unique to a development team. The 339 Bundle ID is unique to a development team, and is a string that will 340 can match a single application or a group of applications. 342 Example: pn-type = apns:DEF123GHIJ.com.yourcompany.yourexampleapp 344 When the Apple Push Notification service (APNs) is used, pn-type URI 345 parameter pns-prid parameter part contains the device token, which is 346 a unique identifier assigned by Apple to a specific app on a specific 347 device. 349 Example: pn-prid = 00fc13adff78512 351 For more information on the APNs App ID: 353 https://developer.apple.com/library/content/documentation/General/ 354 Conceptual/DevPedia-CocoaCore/AppID.html 356 For more information on the APNs device token: 358 https://developer.apple.com/library/content/documentation/NetworkingI 359 nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re 360 f/doc/uid/TP40008194-CH8-SW13 362 10. pn-prid and pn-type URI parameters for Google Firebase Cloud 363 Messaging (FCM) push notification service 365 When Firebase Cloud Messaging (FCM) is used, the value of the pn-type 366 URI parameter pns-provider parameter part is "fcm". The pns-param 367 part contains the Sender ID. 369 When Firebase Cloud Messaging (FCM) is used, pn-type URI parameter 370 pns-prid parameter part contains the Registration token, which 371 generated by the FCM SDK for each client app instance. 373 For more information on the Sender ID and Registration token: 375 https://firebase.google.com/docs/cloud-messaging/concept-options 377 11. Security considerations 379 In addition to the information exchanged between a device and its PNS 380 in order to establish a push notification subscription, the mechanism 381 in this document does not require entities to provide any additional 382 information to the PNS. 384 Push notification mechanisms provide different methods to ensure that 385 malicious user cannot trigger push notifications to a device. Users 386 of the mechanism in this document MUST take measures to prevent push 387 notifications from being sent to a device from a malicious user. 389 In case entities do want to include payload in the push 390 notifications, this document defines the means for using end-to-end 391 payload encryption between the entity sending the push request and 392 the entity receiving the associated push notification. 394 12. IANA considerations 396 This specification defines new SIP URI parameters that extend the 397 registry created by [RFC3969]: 399 12.1. pn-prid 401 Parameter Name: pn-prid 403 Predefined Values: No 405 Reference: RFC XXXX 407 12.2. pn-type 409 Parameter Name: pn-type 411 Predefined Values: No 413 Reference: RFC XXXX 415 12.3. pn-enckey 417 Parameter Name: pn-enckey 419 Predefined Values: No 421 Reference: RFC XXXX 423 12.4. pn-enccode 425 Parameter Name: pn-enccode 427 Predefined Values: No 429 Reference: RFC XXXX 431 12.5. PNS Sub-registry Establishment 433 This section creates a new sub-registry, "PNS", under the sip- 434 parameters registry: http://www.iana.org/assignments/sip-parameters. 436 The purpose of the sub-registry is to register SIP URI pn-type 437 values. 439 This sub-registry is defined as a table that contains the following 440 three columns: 442 Value: The token under registration 444 Description: The name of the push notification service 446 Document: A reference to the document defining the registration 448 This specification registers the following values: 450 Value Description Document 451 ------- ---------------------------------- ---------- 453 apns Apple Push Notification service [RFC XXXX] 454 fcm Firebase Cloud Messaging [RFC XXXX] 456 13. References 458 13.1. Normative references 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, . 465 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 466 A., Peterson, J., Sparks, R., Handley, M., and E. 467 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 468 DOI 10.17487/RFC3261, June 2002, . 471 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 472 (IANA) Uniform Resource Identifier (URI) Parameter 473 Registry for the Session Initiation Protocol (SIP)", 474 BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, 475 . 477 [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic 478 Event Delivery Using HTTP Push", RFC 8030, 479 DOI 10.17487/RFC8030, December 2016, . 482 13.2. Informative references 484 [I-D.ietf-webpush-encryption] 485 Thomson, M., "Message Encryption for Web Push", draft- 486 ietf-webpush-encryption-09 (work in progress), September 487 2017. 489 Author's Address 491 Christer Holmberg 492 Ericsson 493 Hirsalantie 11 494 Jorvas 02420 495 Finland 497 Email: christer.holmberg@ericsson.com