idnits 2.17.1 draft-ietf-sipcore-originating-cdiv-parameter-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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 226: '... [RFC5502] to clearly state that P-Served-User header field MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o This header is forbidden to be repeated within a request for a particular session at a particular time for the reason that session cases are mutually exclusive. This document updates [RFC5502] to clearly state that P-Served-User header field MUST not contain different values either comma-separated or header-separated. This documents also updates the syntax of the header as defined in [RFC5502] to reflect this uniqueness of parameters values. (Using the creation date from RFC5502, updated by this document, for RFC5378 checks: 2007-04-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 27, 2017) is 2375 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 322, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group M. Mohali 3 Internet-Draft Orange 4 Updates: 5502 (if approved) September 27, 2017 5 Intended status: Informational 6 Expires: March 31, 2018 8 A P-Served-User Header Field Parameter for Originating CDIV session case 9 in Session Initiation Protocol (SIP) 10 draft-ietf-sipcore-originating-cdiv-parameter-01 12 Abstract 14 This specification defines a new parameter of the P-Served-User 15 header field in the Session Initiation Protocol (SIP). This new 16 "orig-cdiv" parameter defines the session case used by a proxy when 17 handling an originating session after Call Diversion (CDIV) services 18 has been invoked for the served user. The P-Served-User header field 19 is defined in RFC5502 to convey the identity of the served user and 20 the session case that applies to this particular communication 21 session and application invocation. This document updates RFC5502 to 22 add the "originating after CDIV" session case and to provide more 23 guidance for using the P-Served-User header field in IP networks that 24 were missing in RFC5502. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 31, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3 63 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 64 2. Proxy behavior and parameter handling . . . . . . . . . . . . 4 65 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 71 6.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 72 6.2. Call diversion and privacy . . . . . . . . . . . . . . . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 1.1. General 84 The P-Served-User header field was defined in [RFC5502] to address an 85 issue that was found in the 3rd Generation Partnership Project (3GPP) 86 IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session 87 Control Function) and an AS (Application Server) on the ISC (IMS 88 Service Control) interface. For more information on the IMS, a 89 detailed description can be found in [TS.3GPP.24.229]. 91 The P-Served-User header field conveys the identity of the served 92 user, his/her registration state and the session case that applies to 93 this particular communication session and application invocation. 95 [RFC5502] defines the originating and terminating session cases for a 96 registered or unregistered user. This document extends the P-Served- 97 User header field to include the session case for a forwarded leg 98 when a call diversion service (CDIV) has been invoked and if an 99 originating service of the diverting user has to be triggered. 101 The sessioncase-param parameter of the P-Served-User header field is 102 extended with the "orig-cdiv" parameter for this "originating after 103 CDIV" session case. 105 The following section defines usage of the "orig-cdiv" parameter of 106 P-Served-User header field, Section 2 specifies the proxy behavior 107 for handling the new header field parameter, and Section 3 discusses 108 the applicability and scope of this new header field parameter. 109 Section 4 describes the syntax and correct the syntax of [RFC5502], 110 Section 5 registers the P-Served-User header field parameters with 111 IANA, and Section 6 discusses the security properties of the 112 environment where this new header field parameter is intended to be 113 used. 115 1.2. Basic Use Case 117 In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) 118 is a SIP proxy that serves as a registrar and handles originating and 119 terminating session states for users allocated to it. This means 120 that any call that is originated by a specific user or any call that 121 is terminated to that specific user will pass through the S-CSCF that 122 is allocated to that user. 124 At the moment that an S-CSCF is allocated for a specific user, the 125 user profile is downloaded from the HSS (Home Subscriber Server) to 126 this S-CSCF, see [TS.3GPP.29.228]. The user profile contains the 127 list of actions to be taken by the S-CSCF for the served user 128 depending on the session direction (originating or terminating) and 129 the user state (registered or not) in the IMS network. With this 130 user profile, the S-CSCF determines the current case and apply the 131 corresponding actions such as forward the request to an AS. At its 132 turn, the AS has to go through a similar process of determining who 133 is the current served user, what is his/her "registration state" and 134 on which "session case" is the session. [RFC5502] defines all those 135 parameters and in particular the originating and terminating session 136 cases. 138 In basic call scenarios, the is no particular issue for the S-CSCF 139 and AS to know which scenario needs to be realized but in case of 140 call diversion services for which the session is re-targeted, the 141 session cases defined in [RFC5502] poses some limitations as 142 described in the following section. 144 1.3. Problem Statement 146 In case of a call diversion service, the received request is first 147 considered as a terminating session case and the terminating filter 148 criteria configured in the S-CSCF are performed. Receiving the call 149 initiation request, the Application Server is able to determine the 150 served user and the session case (here "term") from the received P- 151 Served-User header field content and to execute terminating services. 152 When the call diversion service is executed (as a terminating 153 service), the Application Server changes the target (Request-URI) of 154 the session and a new call leg is created. This new call leg could 155 be considered as an originating call leg from the diverting user but 156 this is not the case. Indeed, the originating user remains the same 157 and some of the diverting user's originating services should not be 158 triggered as if it was an originating call. For instance, the 159 originating user identity should not be restricted because the 160 diverting user has a privacy service for his/her own identity. The 161 privacy of the diverting user should apply to information related to 162 this user (eg. in the Histroy-Info header field). In the same 163 manner, some specific services will need to be specifically triggered 164 on the outgoing leg after a call diversion. Without a dedicated 165 session case for originating after CDIV, there is no possiblity for a 166 proxy to trigger an originating service for the diverting user or for 167 an Application Server to execute the procedures for this particular 168 session case. 170 For this use case, this document creates a new parameter for the 171 originating after CDIV session case to be embedded in the P-Served- 172 User header field. 174 2. Proxy behavior and parameter handling 176 The "orig-cdiv" header field parameter can be used inside a trust 177 domain of the P-Served-User header field by proxies that are 178 processing call diversion services. The following section 179 illustrates how this header field parameter can be used in a 3GPP 180 network. 182 For a terminating call, when receiving the initial INVITE request, 183 the S-CSCF will determine that the session case is for a terminating 184 user as described in [RFC5502], then it determines the served user by 185 looking at the Request-URI and saves this Request-URI. After that, 186 the S-CSCF starts the analysis of filter criteria and triggers the 187 served user Application Server for the terminating services to be 188 executed including in the INVITE request the P-Served-User header 189 field with the "sescase" parameter set to "term" and the regstate to 190 the corresponding value. 192 Based on some criteria, the Application Server concludes that the 193 request has to be diverted to another target user or application. 194 The received Request-URI is then replaced with the new diverted-to 195 address. The Application Server stores the successive Request-URI(s) 196 values by adding one or two History-Info header field entry(ies) 197 [RFC7044] in the outgoing INVITE. In the History-Info header field, 198 the served user address is tagged thanks to the mp-param header field 199 parameter added in entry associated to the diverted-to address 200 created. 202 In the next step, the Application Server forwards the INVITE request 203 back to the S-CSCF. When receiving back the INVITE request, the 204 S-CSCF can see that the topmost Route header field contains its own 205 hostname but the Request-URI does not match the saved Request-URI. 206 In this case, the S-CSCF updates the P-Served-User header field 207 content by replacing the "sescase" parameter by the "orig-cdiv" 208 parameter. The PServedUser-value remains unchanged. 210 Then the procedure continues by forwarding the INVITE request over to 211 an AS that hosts the originating services of the served user 212 (diverting user) that specifically need to be executed on the 213 forwarded leg after a call diversion service. 215 When the Application Server receives the INVITE request, it 216 determines that the session case is for "orig-cdiv" session case and 217 will perform the originating services to be executed after 218 retargeting for the diverting user (i.e. served user). 220 This document also provides the following guidance that reminds or 221 clarifies the P-Served-User handling that are missing in [RFC5502]: 223 o This header is forbidden to be repeated within a request for a 224 particular session at a particular time for the reason that 225 session cases are mutually exclusive. This document updates 226 [RFC5502] to clearly state that P-Served-User header field MUST 227 not contain different values either comma-separated or header- 228 separated. This documents also updates the syntax of the header 229 as defined in [RFC5502] to reflect this uniqueness of parameters 230 values. 232 o Whether the "regstate" parameter is removed or not by the S-CSCF 233 when processing the orginating after CDIV session case is out of 234 the scope of this document. In one hand, it can either be 235 considered that the S-CSCF is able to store the previous regstate 236 value and that the same value applies or that the "regstate" is 237 not relevant after a diverting service. On the other hand, the 238 regstate can be combined to the orig-cdiv session case to provide 239 different services if the served user is registered or 240 unregistered. These choices are implementation dependent. 242 3. Applicability 244 The use of the P-Served-User header field extensions is only 245 applicable inside a Trust Domain for P-Served-User. Nodes in such a 246 Trust Domain explicitly trust each other to convey the served user 247 and to be responsible for withholding that information outside of the 248 Trust Domain. The means by which the network determines the served 249 user and the policies that are executed for a specific served user is 250 outside the scope of this document. 252 4. Syntax 254 4.1. General 256 [RFC5502] defines the P-Served-User header field with the 257 sessioncase-param parameter "sescase" which is specified as having 258 "orig" and "term" predefined values. This document defines an 259 additional parameter for the sessioncase-param: "orig-cdiv". 261 Because this document extends the existing sessioncase-param 262 parameter in a special way and that it has been identified errors in 263 the syntax of the P-Served-User header field as defined in [RFC5502], 264 this document corrects and extends the header at the same time. 266 The extension of the sessioncase-param parameter to add the "orig- 267 cdiv" session case is done in a way to fit the parameter format 268 introduced in release 11 of the 3GPP [TS.3GPP.24.229] and keep a 269 backward compatibility. 271 "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- 272 param" are defined in [RFC3261]. 274 4.2. ABNF 276 The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P- 277 Served-User header field is described in [RFC5502]. 279 This document updates [RFC5502] to correct the P-Served-User header 280 field ABNF syntax and extend it as following: 282 P-Served-User = "P-Served-User" HCOLON PServedUser-value 283 *(SEMI served-user-param) 284 served-user-param = sessioncase-param 285 / registration-state-param 286 / generic-param 287 PServedUser-value = name-addr / addr-spec 288 sessioncase-param = 1("sescase" EQUAL 1("orig" / "term")/ orig-cdiv) 289 registration-state-param = "regstate" EQUAL 1("unreg" / "reg") 290 orig-cdiv = "orig-cdiv" 292 Examples of possible P-Served-User header field: 294 P-Served-User: ; orig-cdiv; regstate=reg 295 or 296 P-Served-User: ; orig-cdiv 297 or 298 P-Served-User: ; sescase=term; regstate=unreg 300 5. IANA Considerations 302 The syntax of the P-Served-User header field is defined in [RFC5502] 303 and updated in Section 4 of this document. 305 This document requests IANA to update the existing row for the P- 306 Served-User header field in the "Header Fields" sub-registry: 308 Header Name Compact Form Reference 309 ------------- ------------ ---------------- 310 P-Served-User none [RFC5502][RFCXXXX] 312 Note to RFC Editor: Please replace XXXX with the RFC number of this document. 314 This document requests IANA to add new rows for the P-Served-User 315 header field parameters in the "Header Field Parameters and Parameter 316 Values" sub-registry as per the registry created by [RFC3968]: 318 Header Field Parameter Name Predefined Values Reference 319 -------------- ---------------- ----------------- ----------------- 320 P-Served-User sescase Yes [RFC5502][RFCXXXX] 321 P-Served-User regstate Yes [RFC5502][RFCXXXX] 322 P-Served-User orig-cdiv No [RFCXXXX] 324 Note to RFC Editor: Please replace XXXX with the RFC number of this document. 326 6. Call Flow Examples 328 6.1. Call diversion case 330 The following call flow shows a session establishement for Alice 331 calls Bob which has a call diversion when busy towards Carol. 333 proxy server UA 334 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 335 | | | | | 336 | INVITE F1 | | | | 337 |--------------->| INVITE F2 | | | 338 | |--------------->| | | 339 | | INVITE F3 | | | 340 | |<---------------| INVITE F4 | | 341 | |-------------------------------->| | 342 | | 486 F5 | | 343 | |<--------------------------------| | 344 | | 486 F6 | | | 345 | |--------------->| | | 346 | | INVITE F7 | | | 347 | |<---------------| | | 348 | | INVITE F8 | | | 349 | |--------------->| | | 350 | | INVITE F9 | | | 351 | |<---------------| INVITE F10 | 352 | |------------------------------------------------->| 353 | | | | | 354 | | | | 180 F11 | 355 | | | 180 F12 |<---------------| 356 | | 180 F13 |<---------------| | 357 | 180 F14 |<---------------| | | 358 |<---------------| | | | 359 | | | | | 361 F1 INVITE Alice -> S-CSCF-B 362 INVITE sip:bob@example.com SIP/2.0 363 From: Alice ;tag=1928301774 364 To: Bob 366 F2 INVITE S-CSCF-B -> AS-B 367 INVITE sip:bob@example.com SIP/2.0 368 From: Alice ;tag=1928301774 369 To: Bob 370 P-Served-User: ; term; regstate=reg 372 F3 INVITE AS-B -> S-CSCF-B 373 INVITE sip:bob@example.com SIP/2.0 374 From: Alice ;tag=1928301774 375 To: Bob 376 P-Served-User: ; term; regstate=reg 378 F4 INVITE S-CSCF-B -> Bob 379 INVITE sip:bob@192.0.2.4 SIP/2.0 380 From: Alice ;tag=1928301774 381 To: Bob 382 P-Served-User: ; term; regstate=reg 384 F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B 385 486 BUSY 386 From: Alice ;tag=1928301774 387 To: Bob ;tag=es43sd 389 F7 INVITE AS-B -> S-CSCF-B 390 INVITE sip:Carol@domainc.com SIP/2.0 391 From: Alice ;tag=1928301774 392 To: Bob 393 P-Served-User: ; term; regstate=reg 395 F8 INVITE S-CSCF-B -> AS-B 396 INVITE sip:Carol@domainc.com SIP/2.0 397 From: Alice ;tag=1928301774 398 To: Bob 399 P-Served-User: ; orig-cdiv; regstate=reg 401 F9 INVITE AS-B -> S-CSCF-B 402 INVITE sip:carol@domainc.com SIP/2.0 403 From: Alice ;tag=1928301774 404 To: Bob 405 P-Served-User: ; orig-cdiv; regstate=reg 407 F10 INVITE S-CSCF-B -> Carol 408 INVITE sip:carol@192.0.2.7 SIP/2.0 409 From: Alice ;tag=1928301774 410 To: Bob 412 Figure 1: P-Served-User during call diversion service 414 6.2. Call diversion and privacy 416 The following call flow shows a call diversion use case for which 417 Alice has no identity restriction service and Bob has an 418 unconditional call diversion service towards Carol and an identity 419 presentation restriction service. 421 proxy server UA 422 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 423 | | | | | 424 | INVITE F1 | | | | 425 |--------------->| INVITE F2 | | | 426 | |--------------->| | | 427 | | INVITE F3 | | | 428 | |<---------------| | | 429 | | INVITE F4 | | | 430 | |--------------->| | | 431 | | INVITE F5 | | | 432 | |<---------------| INVITE F6 | | 433 | |------------------------------------------------->| 434 | | | | | 435 | | | | 180 F7 | 436 | | | 180 F8 |<---------------| 437 | | 180 F9 |<---------------| | 438 | 180 F10 |<---------------| | | 439 |<---------------| | | | 440 | | | | | 442 F1 INVITE Alice -> S-CSCF-B 443 INVITE sip:bob@example.com SIP/2.0 444 From: Alice ;tag=1928301774 445 To: Bob 446 Supported: histinfo 448 F2 INVITE S-CSCF-B -> AS-B 449 INVITE sip:bob@example.com SIP/2.0 450 From: Alice ;tag=1928301774 451 To: Bob 452 P-Served-User: ; term; regstate=reg 454 F3 INVITE AS-B -> S-CSCF-B 455 INVITE sip:carol@domainc.com SIP/2.0 456 From: Alice ;tag=1928301774 457 To: Carol 458 P-Served-User: ; term; regstate=reg 459 History-Info: 460 ;index=1, 461 ;index=1.1;mp=1 463 F4 INVITE S-CSCF-B -> AS-B 464 INVITE sip:carol@domainc.com SIP/2.0 465 From: Alice ;tag=1928301774 466 To: Carol 467 P-Served-User: ; orig-cdiv; regstate=reg 468 History-Info: 470 ;index=1, 471 ;index=1.1;mp=1 473 F5 INVITE AS-B -> S-CSCF-B 474 INVITE sip:carol@domainc.com SIP/2.0 475 From: Alice ;tag=1928301774 476 To: Carol 477 P-Served-User: ; orig-cdiv; regstate=reg 478 History-Info: 479 ;index=1, 480 ;index=1.1;mp=1 482 F6 INVITE S-CSCF-B -> Carol 483 INVITE sip:carol@192.0.2.7 SIP/2.0 484 From: Alice ;tag=1928301774 485 To: Carol 486 History-Info: 487 ;index=1, 488 ;index=1.1;mp=1 489 ;index=1.1.1;rc=1.1 491 Figure 2: P-Served-User when privacy requested 493 7. Security Considerations 495 The security considerations in [RFC5502] apply. 497 As the "orig-cdiv" parameter of P-Served-User header field can be 498 used to trigger applications, it is important to ensure that the 499 parameter has not been added to the SIP message by an unauthorized 500 SIP entity. 502 8. Acknowledgments 504 The author wishes to thank the 3GPP community for providing guidance, 505 input, and comments on the document. Thanks also to Dale Worley for 506 his careful review of the document. A special thanks to Christer 507 Holmberg. 509 9. References 511 9.1. Normative References 513 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 514 A., Peterson, J., Sparks, R., Handley, M., and E. 515 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 516 DOI 10.17487/RFC3261, June 2002, 517 . 519 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 520 (IANA) Header Field Parameter Registry for the Session 521 Initiation Protocol (SIP)", BCP 98, RFC 3968, 522 DOI 10.17487/RFC3968, December 2004, 523 . 525 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 526 Specifications: ABNF", STD 68, RFC 5234, 527 DOI 10.17487/RFC5234, January 2008, 528 . 530 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 531 C. Holmberg, "An Extension to the Session Initiation 532 Protocol (SIP) for Request History Information", RFC 7044, 533 DOI 10.17487/RFC7044, February 2014, 534 . 536 9.2. Informative References 538 [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header 539 (P-Header) for the 3GPP IP Multimedia (IM) Core Network 540 (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 541 2009, . 543 [TS.3GPP.24.229] 544 3GPP, "IP multimedia call control protocol based on 545 Session Initiation Protocol (SIP) and Session Description 546 Protocol (SDP);Stage 3", 3GPP TS 24.229 v11. 548 [TS.3GPP.29.228] 549 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 550 Signalling flows and message contents", 3GPP TS 29.228 551 v11. 553 Author's Address 554 Marianne Mohali 555 Orange 556 Orange Gardens, 44 avenue de la Republique 557 Chatillon 92326 558 France 560 Email: marianne.mohali@orange.com