idnits 2.17.1 draft-ietf-sipcore-originating-cdiv-parameter-02.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 : ---------------------------------------------------------------------------- ** 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 234: '... o This header MUST NOT be repeated ...' RFC 2119 keyword, line 237: '...ser header field MUST NOT contain diff...' -- The draft header indicates that this document updates RFC5502, but the abstract doesn't seem to directly say this. It does mention RFC5502 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (May 22, 2018) is 2159 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 323, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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) May 22, 2018 5 Intended status: Informational 6 Expires: November 23, 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-02 12 Abstract 14 The P-Served-User header field RFC5502 is used to convey the identity 15 of the served user and the session case that applies to this 16 particular communication session and application invocation. This 17 document updated RFC5502 by defining a new P-Served-User header field 18 parameter, "orig-cdiv". The parameter conveys the session case used 19 by a proxy when handling an originating session after Call Diversion 20 (CDIV) services has been invoked for the served user. This document 21 also fixes the ABNF in RFC5502 and provides more guidance for using 22 the P-Served-User header field in IP networks. 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 https://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 November 23, 2018. 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3 61 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 62 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Proxy behavior and parameter handling . . . . . . . . . . . . 4 64 4. Clarification of RFC5502 procedures . . . . . . . . . . . . . 5 65 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 71 7.2. Call diversion and privacy . . . . . . . . . . . . . . . 10 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 10.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 1.1. General 83 The P-Served-User header field [RFC5502] was defined based on a 84 requirement from 3rd Generation Partnership Project (3GPP) IMS (IP 85 Multimedia Subsystem) in order to convey the identity of the served 86 user, his/her registration state and the session case between an 87 S-CSCF (Serving Call Session Control Function) and an AS (Application 88 Server) on the ISC (IMS Service Control) interface. For more 89 information on the IMS, a detailed description can be found in 90 [TS.3GPP.24.229]. 92 [RFC5502] defines the originating and terminating session cases for a 93 registered or unregistered user. This document extends the P-Served- 94 User header field to include the session case for a forwarded leg 95 when a call diversion service (CDIV) has been invoked and if an 96 originating service of the diverting user has to be triggered. 98 The sessioncase-param parameter of the P-Served-User header field is 99 extended with the "orig-cdiv" parameter for this "originating after 100 CDIV" session case. 102 The following section defines usage of the "orig-cdiv" parameter of 103 P-Served-User header field, Section 2 discusses the applicability and 104 scope of this new header field parameter, and Section 3 specifies the 105 proxy behavior for handling the new header field parameter. 106 Section 4 clarifies some of the [RFC5502] procedures, Section 5 107 describes the extended syntax and correct the syntax of [RFC5502], 108 Section 6 registers the P-Served-User header field parameters with 109 IANA, Section 7 gives some examples and Section 8 discusses the 110 security properties of the environment where this new header field 111 parameter is intended to be used. 113 1.2. Basic Use Case 115 In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) 116 is a SIP proxy that serves as a registrar and handles originating and 117 terminating session states for users allocated to it. This means 118 that any call that is originated by a specific user or any call that 119 is terminated to that specific user will pass through the S-CSCF that 120 is allocated to that user. 122 At the moment that an S-CSCF is allocated for a specific user, the 123 user profile is downloaded from the HSS (Home Subscriber Server) to 124 this S-CSCF, see [TS.3GPP.29.228]. The user profile contains the 125 list of actions to be taken by the S-CSCF for the served user 126 depending on the session direction (originating or terminating) and 127 the user state (registered or not) in the IMS network. With this 128 user profile, the S-CSCF determines the current case and apply the 129 corresponding actions such as forward the request to an AS. At its 130 turn, the AS has to go through a similar process of determining who 131 is the current served user, what is his/her "registration state" and 132 on which "session case" is the session. [RFC5502] defines all those 133 parameters and in particular the originating and terminating session 134 cases. 136 In basic call scenarios, the is no particular issue for the S-CSCF 137 and AS to know which scenario needs to be realized but in case of 138 call diversion services for which the session is re-targeted, the 139 session cases defined in [RFC5502] poses some limitations as 140 described in the following section. 142 1.3. Problem Statement 144 In case of a call diversion service, the received request is first 145 considered as a terminating session case and the terminating filter 146 criteria configured in the S-CSCF are performed. Receiving the call 147 initiation request, the AS is able to determine the served user and 148 the session case (here "term") from the received P-Served-User header 149 field content and to execute terminating services. When the call 150 diversion service is executed (as a terminating service), the AS 151 changes the target (Request-URI) of the session and a new call leg is 152 created. This new call leg could be considered as an originating 153 call leg from the diverting user but this is not the case. Indeed, 154 the originating user remains the same and some of the diverting 155 user's originating services should not be triggered as if it was an 156 originating call. For instance, the originating user identity should 157 not be restricted because the diverting user has a privacy service 158 for his/her own identity. The privacy of the diverting user should 159 apply to information related to this user (eg. in the History-Info 160 header field). In the same manner, some specific services will need 161 to be specifically triggered on the outgoing leg after a call 162 diversion. Without a dedicated session case for originating after 163 CDIV, there is no possiblity for a proxy to trigger an originating 164 service for the diverting user or for an AS to execute the procedures 165 for this particular session case. 167 For this use case, this document creates a new parameter for the 168 originating after CDIV session case to be embedded in the P-Served- 169 User header field. 171 2. Applicability 173 The use of the P-Served-User header field extensions is only 174 applicable inside a Trust Domain for P-Served-User header field. 175 Nodes in such a Trust Domain explicitly trust each other to convey 176 the served user and to be responsible for withholding that 177 information outside of the Trust Domain. The means by which the 178 network determines the served user and the policies that are executed 179 for a specific served user is outside the scope of this document. 181 3. Proxy behavior and parameter handling 183 The following section illustrates how this header field parameter can 184 be used in a 3GPP network. 186 For a terminating call, the following steps will be followed: 188 1. The S-CSCF receives the initial INVITE request for a terminating 189 call and determines that the session case is for a terminating 190 user as described in [RFC5502]; 192 2. The S-CSCF determines who is the served user by looking at the 193 Request-URI and saves the current Request-URI; 195 3. The S-CSCF starts the analysis of filter criteria and triggers 196 the served user AS for the terminating services to be executed by 197 including in the INVITE request the P-Served-User header field 198 with the "sescase" parameter set to "term" and the regstate to 199 the corresponding value; 201 4. Based on some criteria, the AS concludes that the request has to 202 be diverted to another target user or application. The received 203 Request-URI is then replaced with the new diverted-to address and 204 the AS stores the successive Request-URI(s) values by adding one 205 or two History-Info header field entry(ies) [RFC7044] in the 206 outgoing INVITE. In the History-Info header field, the served 207 user address is tagged using the mp-param header field parameter 208 added in entry associated to the diverted-to address created. 209 The AS forwards the INVITE request back to the S-CSCF; 211 5. When receiving back the INVITE request, the S-CSCF can see that 212 the topmost Route header field contains its own hostname but the 213 Request-URI does not match the saved Request-URI. In this case, 214 the S-CSCF updates the P-Served-User header field content by 215 replacing the "sescase" parameter by the "orig-cdiv" parameter. 216 The P-Served-User header field value remains unchanged; 218 6. The S-CSCF forwards the INVITE request over to an AS that hosts 219 the originating services of the served user (diverting user) that 220 specifically need to be executed on the forwarded leg after a 221 call diversion service; 223 7. When the AS receives the INVITE request, it determines that the 224 session case is for "orig-cdiv" session case and will perform the 225 originating services to be executed after retargeting for the 226 diverting user (i.e. served user). 228 4. Clarification of RFC5502 procedures 230 This document provides the following guidance that reminds and 231 clarifies the P-Served-User header field handling that are missing in 232 [RFC5502]: 234 o This header MUST NOT be repeated within a request for a particular 235 session at a particular time for the reason that session cases are 236 mutually exclusive. This document updates [RFC5502] to clearly 237 state that P-Served-User header field MUST NOT contain different 238 values either comma-separated or header-separated. This documents 239 also updates the syntax of the header from [RFC5502] to reflect 240 this uniqueness of parameters values. 242 o Whether the "regstate" parameter is removed or not by the S-CSCF 243 when processing the orginating after CDIV session case is out of 244 the scope of this document. In one hand, it can either be 245 considered that the S-CSCF is able to store the previous regstate 246 value and that the same value applies or that the "regstate" is 247 not relevant after a diverting service. On the other hand, the 248 regstate can be combined to the orig-cdiv session case to provide 249 different services if the served user is registered or 250 unregistered. These choices are implementation dependent. 252 5. Syntax 254 5.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 [RFC5502], this document 264 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 5.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 = "sescase" EQUAL ("orig"/"term")/ orig-cdiv 289 registration-state-param = "regstate" EQUAL ("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 6. IANA Considerations 302 The syntax of the P-Served-User header field [RFC5502] is updated in 303 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 313 document. 315 This document requests IANA to add new rows for the P-Served-User 316 header field parameters in the "Header Field Parameters and Parameter 317 Values" sub-registry as per the registry created by [RFC3968]: 319 Header Field Parameter Name Predefined Values Reference 320 -------------- ---------------- ----------------- ----------------- 321 P-Served-User sescase Yes [RFC5502][RFCXXXX] 322 P-Served-User regstate Yes [RFC5502][RFCXXXX] 323 P-Served-User orig-cdiv No [RFCXXXX] 325 Note to RFC Editor: Please replace XXXX with the RFC number of this 326 document. 328 7. Call Flow Examples 330 7.1. Call diversion case 332 The following call flow shows a session establishement for Alice 333 calls Bob which has a call diversion when busy towards Carol. 335 proxy server UA 336 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 337 | | | | | 338 | INVITE F1 | | | | 339 |--------------->| INVITE F2 | | | 340 | |--------------->| | | 341 | | INVITE F3 | | | 342 | |<---------------| INVITE F4 | | 343 | |-------------------------------->| | 344 | | 486 F5 | | 345 | |<--------------------------------| | 346 | | 486 F6 | | | 347 | |--------------->| | | 348 | | INVITE F7 | | | 349 | |<---------------| | | 350 | | INVITE F8 | | | 351 | |--------------->| | | 352 | | INVITE F9 | | | 353 | |<---------------| INVITE F10 | 354 | |------------------------------------------------->| 355 | | | | | 356 | | | | 180 F11 | 357 | | | 180 F12 |<---------------| 358 | | 180 F13 |<---------------| | 359 | 180 F14 |<---------------| | | 360 |<---------------| | | | 361 | | | | | 363 F1 INVITE Alice -> S-CSCF-B 364 INVITE sip:bob@example.com SIP/2.0 365 From: Alice ;tag=1928301774 366 To: Bob 368 F2 INVITE S-CSCF-B -> AS-B 369 INVITE sip:bob@example.com SIP/2.0 370 From: Alice ;tag=1928301774 371 To: Bob 372 P-Served-User: ; term; regstate=reg 374 F3 INVITE AS-B -> S-CSCF-B 375 INVITE sip:bob@example.com SIP/2.0 376 From: Alice ;tag=1928301774 377 To: Bob 378 P-Served-User: ; term; regstate=reg 380 F4 INVITE S-CSCF-B -> Bob 381 INVITE sip:bob@192.0.2.4 SIP/2.0 382 From: Alice ;tag=1928301774 383 To: Bob 384 P-Served-User: ; term; regstate=reg 386 F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B 387 486 BUSY 388 From: Alice ;tag=1928301774 389 To: Bob ;tag=es43sd 391 F7 INVITE AS-B -> S-CSCF-B 392 INVITE sip:Carol@domainc.com SIP/2.0 393 From: Alice ;tag=1928301774 394 To: Bob 395 P-Served-User: ; term; regstate=reg 397 F8 INVITE S-CSCF-B -> AS-B 398 INVITE sip:Carol@domainc.com SIP/2.0 399 From: Alice ;tag=1928301774 400 To: Bob 401 P-Served-User: ; orig-cdiv; regstate=reg 403 F9 INVITE AS-B -> S-CSCF-B 404 INVITE sip:carol@domainc.com SIP/2.0 405 From: Alice ;tag=1928301774 406 To: Bob 407 P-Served-User: ; orig-cdiv; regstate=reg 409 F10 INVITE S-CSCF-B -> Carol 410 INVITE sip:carol@192.0.2.7 SIP/2.0 411 From: Alice ;tag=1928301774 412 To: Bob 413 Figure 1: P-Served-User during call diversion service 415 7.2. Call diversion and privacy 417 The following call flow shows a call diversion use case for which 418 Alice has no identity restriction service and Bob has an 419 unconditional call diversion service towards Carol and an identity 420 presentation restriction service. 422 proxy server UA 423 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 424 | | | | | 425 | INVITE F1 | | | | 426 |--------------->| INVITE F2 | | | 427 | |--------------->| | | 428 | | INVITE F3 | | | 429 | |<---------------| | | 430 | | INVITE F4 | | | 431 | |--------------->| | | 432 | | INVITE F5 | | | 433 | |<---------------| INVITE F6 | | 434 | |------------------------------------------------->| 435 | | | | | 436 | | | | 180 F7 | 437 | | | 180 F8 |<---------------| 438 | | 180 F9 |<---------------| | 439 | 180 F10 |<---------------| | | 440 |<---------------| | | | 441 | | | | | 443 F1 INVITE Alice -> S-CSCF-B 444 INVITE sip:bob@example.com SIP/2.0 445 From: Alice ;tag=1928301774 446 To: Bob 447 Supported: histinfo 449 F2 INVITE S-CSCF-B -> AS-B 450 INVITE sip:bob@example.com SIP/2.0 451 From: Alice ;tag=1928301774 452 To: Bob 453 P-Served-User: ; term; regstate=reg 455 F3 INVITE AS-B -> S-CSCF-B 456 INVITE sip:carol@domainc.com SIP/2.0 457 From: Alice ;tag=1928301774 458 To: Carol 459 P-Served-User: ; term; regstate=reg 460 History-Info: 461 ;index=1, 462 ;index=1.1;mp=1 464 F4 INVITE S-CSCF-B -> AS-B 465 INVITE sip:carol@domainc.com SIP/2.0 466 From: Alice ;tag=1928301774 467 To: Carol 468 P-Served-User: ; orig-cdiv; regstate=reg 469 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 8. 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 9. Acknowledgments 504 The author wishes to thank the 3GPP community for providing guidance, 505 input, and comments on the document. Thanks to Dale Worley for his 506 careful review of the document and to Paul Kyzivat. A special thanks 507 to Christer Holmberg. 509 10. References 511 10.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 10.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 555 Marianne Mohali 556 Orange 557 Orange Gardens, 44 avenue de la Republique 558 Chatillon 92326 559 France 561 Email: marianne.mohali@orange.com