idnits 2.17.1 draft-holmberg-sipcore-sip-push-01.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 (October 27, 2017) is 2373 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 392, 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 October 27, 2017 5 Expires: April 30, 2018 7 Push Notification with the Session Initiation Protocol (SIP) 8 draft-holmberg-sipcore-sip-push-01 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 April 30, 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 6. Network Address Translator (NAT) Considerations . . . . . . . 6 61 7. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. pn-prid and pn-type URI parameters for Apple Push 63 Notification service . . . . . . . . . . . . . . . . . . . . 7 64 9. pn-prid and pn-type URI parameters for Google Firebase Cloud 65 Messaging (FCM) push notification service . . . . . . . . . . 8 66 10. Security considerations . . . . . . . . . . . . . . . . . . . 8 67 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 68 11.1. pn-prid . . . . . . . . . . . . . . . . . . . . . . . . 8 69 11.2. pn-type . . . . . . . . . . . . . . . . . . . . . . . . 9 70 11.3. pn-enckey . . . . . . . . . . . . . . . . . . . . . . . 9 71 11.4. pn-enccode . . . . . . . . . . . . . . . . . . . . . . . 9 72 11.5. PNS Sub-registry Establishment . . . . . . . . . . . . . 9 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 12.1. Normative references . . . . . . . . . . . . . . . . . . 10 75 12.2. Informative references . . . . . . . . . . . . . . . . . 11 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 In order to save resources (e.g, battery life) some devices and 81 operating systems require suspended Session Initiation Protocol (SIP) 82 User Agents (UAs) [RFC3261] to be woken up using a push notification 83 service. Typically each operating system uses a dedicated push 84 notification service. For example, Apple iOS devices use the Apple 85 Push Notification service (APNs). 87 Due to the restriction above, applications can not be woken up by 88 non-push notification traffic. This means that a suspended SIP UA 89 will not be able to receive an incoming SIP request (e.g., a SIP 90 INVITE request). 92 This document describes how push notification mechanisms can be used 93 to wake up suspended SIP UAs, in order to be able to receive and 94 generate SIP requests. The document defines new SIP URI parameters, 95 that can be used in a SIP REGISTER request to provide push 96 notification information from the SIP UA to the SIP entity (realized 97 as a SIP proxy in this document) that will send a push request to the 98 push server in order to trigger a push notification towards the SIP 99 UA. 101 When a SIP UA registers to a push service, it will receive a unique 102 Push Resource ID (PRID) associated to that registration. The SIP UA 103 will provide the PRID to the SIP network in a SIP REGISTER request. 104 A SIP proxy (e.g., the SIP registrar) will store a mapping between 105 the registered contact and the PRID. 107 When the SIP proxy receives a SIP request for a new session, or a 108 stand-alone SIP request, addressed towards a SIP UA, the SIP proxy 109 will send a push request to the push notification service used by the 110 SIP UA, using the push resource ID associated with the registered 111 contact of the SIP UA, in order to trigger a push notification 112 towards the SIP UA. The SIP proxy will then forward the SIP request 113 towards the SIP UA using normal SIP routing procedures. Once the SIP 114 UA receives the push notification, it will be able to receive the SIP 115 request (and generate a SIP request itself, if needed). 117 Different push notification mechanisms exist today. Some are based 118 on there standardized mechanism defined in [RFC8030], while others 119 are proprietary (e.g., the Apple Push Notification service). 120 Figure 1 shows the generic push notification architecture supported 121 by the mechanism in this document. 123 +--------+ +--------------+ +-----------------+ 124 | SIP UA | | Push Service | | SIP Proxy | 125 +--------+ +--------------+ +-----------------+ 126 | | | 127 | Subscribe | | 128 |--------------------->| | 129 | | | 130 | Push Resource ID | | 131 |<---------------------| | 132 | | | 133 | SIP REGISTER (Push Resource ID) | 134 |===============================================>| 135 | | | 136 | | Push Message | 137 | | (Push Resource ID) | 138 | Push Message |<------------------------| 139 | (Push Resource ID) | | 140 |<---------------------| | 141 | | | 143 ------- Push Notification API 145 ======= SIP 147 REGISTER sip:alice@example.com SIP/2.0 148 Via: SIP/2.0/TCP alicemobile.example.com:5060;branch=z9hG4bKnashds7 149 Max-Forwards: 70 150 To: Alice 151 From: Alice ;tag=456248 152 Call-ID: 843817637684230@998sdasdh09 153 CSeq: 1826 REGISTER 154 Contact: 157 Expires: 7200 158 Content-Length: 0 160 Figure 1: SIP Push Notification Architecture 162 2. Conventions 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 3. Push Resource ID (PRID) 170 When an entity registers with a Push Notification Server (PNS) is 171 receives a unique Push Resource ID (PRID), which is a value 172 associated with the registration. 174 The format of the PRID may vary depending on the PNS provider. The 175 PRID may be part of a URI that can be used to retrieve the address 176 and port of the PNS when sending push requests to the PNS. The PRID 177 may also be a token value, in which case the address and port of the 178 PNS needs to be provided using other means. 180 The details regarding discovery of the PNS, and the procedures for 181 the push notification registration and maintenance are outside the 182 scope of this document. The information needed to contact the PNS is 183 typically pre-configured in the operating system (OS) of the device. 185 4. SIP User Agent (UA) Behavior 187 Once the SIP UA has registered with the PNS and received the PRID, 188 and when the UA wants to receive push notifications triggered by the 189 SIP proxy, the UA MUST send a SIP REGISTER using normal SIP 190 registration procedures. The UA MUST add a pn-prid URI parameter and 191 a pn-type URI parameter to the SIP Contact header field URI of the 192 request. The pn-prid URI parameter contains the PRID value. The pn- 193 type contains additional, PNS-specific, information. 195 As long as the UA wants the SIP proxy to continue sending push 196 requests, the UA MUST include the pn-prid and pn-type URI parameters 197 in every re-registration SIP REGISTER request sent towards the SIP 198 proxy. Note that, in some cases, the PNS might update the PRID 199 value, in which case the re-registration SIP REGISTER request will 200 contain the new value. 202 If the UA at some point wants to stop the SIP proxy from sending push 203 requests, the UA MUST send a SIP REGISTER request without the pn-prid 204 and pn-type URI parameters. 206 If the UA expects to receive payload in the push notification, the UA 207 MAY add a pn-enckey and a pn-encsec Contact header field URI 208 parameter, in order to allow encryption of the data using the 209 mechanism in [I-D.ietf-webpush-encryption]. The pn-enckey URI 210 parameter contains the public key, and the pn-encsec URI parameter 211 contains the authentication secret [I-D.ietf-webpush-encryption]. 213 5. SIP Proxy Behavior 215 When the SIP proxy receives a SIP request for a new dialog (e.g., a 216 SIP INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE 217 request) aimed for a SIP UA, if the Request-URI of the request 218 contains a pn-prid URI parameter, the SIP proxy triggers a push 219 request towards the push notification server associated with the 220 PRID. After that, the SIP proxy forwards the SIP request towards the 221 SIP UA using normal SIP procedures. 223 The SIP proxy MUST NOT transport the SIP request as push request 224 payload, instead of forwarding the request using normal SIP 225 procedures. 227 In some cases the push notification provider can be retrieved from 228 the pn-prid URI parameter. In other cases the pn-type URI parameter 229 is used to identity the push notification provider. 231 If the proxy is not able to contact the push notification provider, 232 or even determine which push notification provider to contact, it 233 SHOULD reject the SIP request. 235 The protocol and format used for the push request depends on the push 236 notification provider, and the details for constructing and sending 237 the messages are outside the scope of this specification. 239 6. Network Address Translator (NAT) Considerations 241 Whenever the UA receives a push notification, if the SIP UA is 242 located behind a Network Address Translator (NAT), the UA might need 243 to take actions in order to establish a binding in the NAT, in order 244 for an incoming SIP request to reach the UA. [RFC5626] and [RFC6223] 245 define such mechanisms. This document does not require usage of a 246 specific mechanism. 248 7. Grammar 250 The section defines new SIP URI parameters, by extending the grammar 251 for "uri-parameter" as defined in [RFC3261]. The ABNF is as follows: 253 uri-parameter =/ pn-prid / pn-type / pn-enccode / pn-enckey 254 pn-prid = "pn-prid" EQUAL pvalue 255 pn-type = "pn-type" EQUAL pns-provider COLON pns-param 256 pn-enccode = "pn-enccode" EQUAL pvalue 257 pn-enckey = "pn-enckey" EQUAL pvalue 259 pns-provider = pvalue ; Colon (":") characters MUST be escaped 260 pns-param = pvalue ; Colon (":") characters MUST be escaped 262 ; pvalue as defined in RFC 3261 263 ; EQUAL as defined in RFC 3261 264 ; COLON as defined in RFC 3261 266 The format and semantics of pns-param is specific to a given 267 pns-provider value. 269 8. pn-prid and pn-type URI parameters for Apple Push Notification 270 service 272 When the Apple Push Notification service (APNs) is used, the value of 273 the pn-type URI parameter pns-provider parameter part is "apns". The 274 pns-param part contains the APNs App ID, which is encoded by two 275 values, separated by a period (.): Team ID and Bundle ID. The Team 276 ID is provided by Apple and is unique to a development team. The 277 Bundle ID is unique to a development team, and is a string that will 278 can match a single application or a group of applications. 280 Example: pn-type = apns:DEF123GHIJ.com.yourcompany.yourexampleapp 282 When the Apple Push Notification service (APNs) is used, pn-type URI 283 parameter pns-prid parameter part contains the device token, which is 284 a unique identifier assigned by Apple to a specific app on a specific 285 device. 287 Example: pn-prid = 00fc13adff78512 289 For more information on the APNs App ID: 291 https://developer.apple.com/library/content/documentation/General/ 292 Conceptual/DevPedia-CocoaCore/AppID.html 294 For more information on the APNs device token: 296 https://developer.apple.com/library/content/documentation/NetworkingI 297 nternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_re 298 f/doc/uid/TP40008194-CH8-SW13 300 9. pn-prid and pn-type URI parameters for Google Firebase Cloud 301 Messaging (FCM) push notification service 303 When Firebase Cloud Messaging (FCM) is used, the value of the pn-type 304 URI parameter pns-provider parameter part is "fcm". The pns-param 305 part contains the Sender ID. 307 When Firebase Cloud Messaging (FCM) is used, pn-type URI parameter 308 pns-prid parameter part contains the Registration token, which 309 generated by the FCM SDK for each client app instance. 311 For more information on the Sender ID and Registration token: 313 https://firebase.google.com/docs/cloud-messaging/concept-options 315 10. Security considerations 317 In addition to the information exchanged between a device and its PNS 318 in order to esatblish a push notification subscription, the mechanism 319 in this document does not require entities to provide any additional 320 information to the PNS. 322 Push notification mechanisms provide different methods to ensure that 323 malicious user cannot trigger push notifications to a device. Users 324 of the mechanism in this document MUST take measures to prevent push 325 notifications from being sent to a device from a malicious user. 327 In case entities do want to include payload in the push 328 notifications, this document defines the means for using end-to-end 329 payload encryption between the entity sending the push request and 330 the entity receiving the associated push notification. 332 11. IANA considerations 334 This specification defines new SIP URI parameters that extend the 335 registry created by [RFC3969]: 337 11.1. pn-prid 339 Parameter Name: pn-prid 341 Predefined Values: No 343 Reference: RFC XXXX 345 11.2. pn-type 347 Parameter Name: pn-type 349 Predefined Values: No 351 Reference: RFC XXXX 353 11.3. pn-enckey 355 Parameter Name: pn-enckey 357 Predefined Values: No 359 Reference: RFC XXXX 361 11.4. pn-enccode 363 Parameter Name: pn-enccode 365 Predefined Values: No 367 Reference: RFC XXXX 369 11.5. PNS Sub-registry Establishment 371 This section creates a new sub-registry, "PNS", under the sip- 372 parameters registry: http://www.iana.org/assignments/sip-parameters. 374 The purpose of the sub-registry is to register SIP URI pn-type 375 values. 377 This sub-registry is defined as a table that contains the following 378 three columns: 380 Value: The token under registration 382 Description: The name of the push notification service 384 Document: A reference to the document defining the registration 386 This specification registers the following values: 388 Value Description Document 389 ------- ---------------------------------- ---------- 391 apns Apple Push Notification service [RFC XXXX] 392 fcm Firebase Cloud Messaging [RFC XXXX] 394 12. References 396 12.1. Normative references 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, . 403 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 404 A., Peterson, J., Sparks, R., Handley, M., and E. 405 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 406 DOI 10.17487/RFC3261, June 2002, . 409 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 410 (IANA) Uniform Resource Identifier (URI) Parameter 411 Registry for the Session Initiation Protocol (SIP)", 412 BCP 99, RFC 3969, DOI 10.17487/RFC3969, December 2004, 413 . 415 [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic 416 Event Delivery Using HTTP Push", RFC 8030, 417 DOI 10.17487/RFC8030, December 2016, . 420 12.2. Informative references 422 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 423 "Managing Client-Initiated Connections in the Session 424 Initiation Protocol (SIP)", RFC 5626, 425 DOI 10.17487/RFC5626, October 2009, . 428 [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 429 RFC 6223, DOI 10.17487/RFC6223, April 2011, 430 . 432 [I-D.ietf-webpush-encryption] 433 Thomson, M., "Message Encryption for Web Push", draft- 434 ietf-webpush-encryption-09 (work in progress), September 435 2017. 437 Author's Address 439 Christer Holmberg 440 Ericsson 441 Hirsalantie 11 442 Jorvas 02420 443 Finland 445 Email: christer.holmberg@ericsson.com