idnits 2.17.1 draft-ietf-sipcore-originating-cdiv-parameter-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 (Using the creation date from RFC5502, updated by this document, for RFC5378 checks: 2007-04-18) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 27, 2018) is 2068 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 348, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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) August 27, 2018 5 Intended status: Informational 6 Expires: February 28, 2019 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-03 12 Abstract 14 The P-Served-User header field is used to convey the identity of the 15 served user and the session case that applies to this particular 16 communication session and application invocation. This document 17 updates 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 have been invoked for the served user. This document 21 also fixes the ABNF in RFC 5502 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 February 28, 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 (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 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3 73 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 74 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 75 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4. Proxy behavior and parameter handling . . . . . . . . . . . . 5 77 5. Clarification of RFC5502 procedures . . . . . . . . . . . . . 6 78 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 82 8. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 83 8.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 84 8.2. Call diversion and privacy . . . . . . . . . . . . . . . 10 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 89 11.2. Informative References . . . . . . . . . . . . . . . . . 13 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 93 1.1. General 95 The P-Served-User header field [RFC5502] was defined based on a 96 requirement from 3rd Generation Partnership Project (3GPP) IMS (IP 97 Multimedia Subsystem) in order to convey the identity of the served 98 user, his/her registration state and the session case between an 99 S-CSCF (Serving Call Session Control Function) and an AS (Application 100 Server) on the ISC (IMS Service Control) interface. For more 101 information on session cases and the IMS, a detailed description can 102 be found in [TS.3GPP.24.229]. 104 [RFC5502] defines the originating and terminating session cases for a 105 registered or unregistered user. This document extends the P-Served- 106 User header field to include the session case for a forwarded leg 107 when a call diversion service (CDIV) has been invoked and if an 108 originating service of the diverting user has to be triggered. 110 The sessioncase-param parameter of the P-Served-User header field is 111 extended with the "orig-cdiv" parameter for this "originating after 112 CDIV" session case. 114 The following section defines usage of the "orig-cdiv" parameter of 115 P-Served-User header field, Section 3 discusses the applicability and 116 scope of this new header field parameter, and Section 4 specifies the 117 proxy behavior for handling the new header field parameter. 118 Section 5 clarifies some of the [RFC5502] procedures, Section 6 119 describes the extended syntax and corrects the syntax of [RFC5502], 120 Section 7 registers the P-Served-User header field parameters with 121 IANA, Section 8 gives some examples, and Section 9 discusses the 122 security properties of the environment where this new header field 123 parameter is intended to be used. 125 1.2. Basic Use Case 127 In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) 128 is a SIP proxy that serves as a registrar and handles originating and 129 terminating session states for users allocated to it. This means 130 that any call that is originated by a specific user or any call that 131 is terminated to that specific user will pass through the S-CSCF that 132 is allocated to that user. 134 At the moment that an S-CSCF is allocated for a specific user, the 135 user profile is downloaded from the HSS (Home Subscriber Server) to 136 this S-CSCF, see [TS.3GPP.29.228]. The user profile contains the 137 list of actions to be taken by the S-CSCF for the served user 138 depending on the session direction (originating or terminating) and 139 the user state (registered or not) in the IMS network. With this 140 user profile, the S-CSCF determines the current case and applies the 141 corresponding actions such as forwarding the request to an AS. The 142 AS then goes through a similar process of determining who is the 143 current served user, what is his/her "registration state", and what 144 is the "session case" of the session. [RFC5502] defines all those 145 parameters and in particular the originating and terminating session 146 cases. 148 In basic call scenarios, there is no particular issue for the S-CSCF 149 and AS to know which scenario needs to be realized, but in case of 150 call diversion services for which the session is re-targeted, the 151 session cases defined in [RFC5502] pose some limitations as described 152 in the following section. 154 1.3. Problem Statement 156 In the case of a call diversion service, the received request is 157 first considered as a terminating session case, and the terminating 158 filter criteria configured in the S-CSCF are performed. When the AS 159 receives the call initiation request, the AS is able to determine the 160 served user and the session case (here "term") from the received P- 161 Served-User header field content and to execute terminating services. 162 When the call diversion service is executed (as a terminating 163 service), the AS changes the target (Request-URI) of the session and 164 a new call leg is created. This new call leg could be considered as 165 an originating call leg from the diverting user but this is not the 166 case. Indeed, the originating user remains the same, and some of the 167 diverting user's originating services should not be triggered as if 168 it was an originating call. For instance, the originating user 169 identity should not be restricted because the diverting user has a 170 privacy service for his/her own identity. The privacy of the 171 diverting user should apply to information related to this user (eg. 172 in the History-Info header field). In the same manner, some specific 173 services will need to be specifically triggered on the outgoing leg 174 after a call diversion. Without a dedicated session case for 175 originating after CDIV, the S-CSCF cannot trigger an originating 176 service for the diverting user, nor can an AS execute the procedures 177 for this particular session case. 179 For this use case, this document creates a new parameter for the 180 originating after CDIV session case to be embedded in the P-Served- 181 User header field. 183 2. Conventions and Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 187 "OPTIONAL" in this document are to be interpreted as described in BCP 188 14 [RFC2119] [RFC8174] when, and only when, they appear in all 189 capitals, as shown here. 191 3. Applicability 193 The use of the P-Served-User header field extensions is only 194 applicable inside a Trust Domain [RFC3324] for P-Served-User header 195 field. Nodes in such a Trust Domain explicitly trust each other to 196 convey the served user and to be responsible for withholding that 197 information outside of the Trust Domain. The means by which the 198 network determines the served user and the policies that are executed 199 for a specific served user is outside the scope of this document. 201 4. Proxy behavior and parameter handling 203 The following section illustrates how this header field parameter can 204 be used in a 3GPP network. 206 For a terminating call, the following steps will be followed: 208 1. The S-CSCF receives the initial INVITE request for a terminating 209 call and determines that the session case is for a terminating 210 user as described in [RFC5502]; 212 2. The S-CSCF determines who is the served user by looking at the 213 Request-URI and saves the current Request-URI; 215 3. The S-CSCF analyzes the filter criteria. It then sends to the AS 216 of the served user an INVITE that includes the P-Served-User 217 header field with the "sescase" parameter set to "term" and the 218 "regstate" set to the corresponding value in order to trigger 219 execution of terminating services; 221 4. Based on some criteria, the AS concludes that the request has to 222 be diverted to another target user or application. The AS 223 replaces the received Request-URI with the new diverted-to 224 address and the AS stores the successive Request-URI(s) values by 225 adding one or two History-Info header field entry(ies) [RFC7044] 226 in the outgoing INVITE. In the History-Info header field, the 227 served user address is tagged using the mp-param header field 228 parameter added in entry associated to the diverted-to address 229 created. The AS forwards the INVITE request back to the S-CSCF; 231 5. When receiving back the INVITE request, the S-CSCF can see that 232 the topmost Route header field contains its own hostname but the 233 Request-URI does not match the saved Request-URI. In this case, 234 the S-CSCF updates the P-Served-User header field content by 235 replacing the "sescase" parameter with the "orig-cdiv" parameter. 236 The P-Served-User header field value remains unchanged; 238 6. The S-CSCF forwards the INVITE request to an AS that hosts the 239 originating services of the served user (diverting user) that 240 specifically need to be executed on the forwarded leg after a 241 call diversion service; 243 7. When the AS receives the INVITE request, it determines that the 244 session case is for "orig-cdiv" session case and performs the 245 originating services to be executed after retargeting for the 246 diverting user (i.e. served user). 248 5. Clarification of RFC5502 procedures 250 This document provides the following guidance for the handling of the 251 P-Served-User header field that are missing in [RFC5502]: 253 o The P-Served-User header field MUST NOT be repeated within a 254 request for a particular session at a particular time for the 255 reason that session cases are mutually exclusive. This document 256 updates [RFC5502] to clearly state that the P-Served-User header 257 field MUST NOT contain different values either comma-separated or 258 header-separated. This documents also updates the syntax of the 259 header from [RFC5502] to reflect this uniqueness of parameters 260 values. 262 o Whether the S-CSCF removes the "regstate" parameter when it 263 processes the orig-cdiv session case is out of the scope of this 264 document. The S-CSCF could store the previous regstate value and 265 that the same value applies, or the "regstate" may not be relevant 266 after a diverting service, or the regstate could be combined with 267 the orig-cdiv session case to provide different services if the 268 served user is registered or unregistered. These choices are 269 implementation dependent. 271 6. Syntax 273 6.1. General 275 [RFC5502] defines the P-Served-User header field with the 276 sessioncase-param parameter "sescase" which is specified as having 277 "orig" and "term" predefined values. This document defines an 278 additional parameter for the sessioncase-param: "orig-cdiv". 280 Because this document extends the existing sessioncase-param 281 parameter, and because errors have been identified in the syntax, 282 this document corrects and extends the P-Served-User header field. 284 The extension of the sessioncase-param parameter to add the "orig- 285 cdiv" session case is done in a way to fit the parameter format 286 introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and to maintain 287 a backward compatibility. 289 "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- 290 param" are defined in [RFC3261]. 292 6.2. ABNF 294 The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P- 295 Served-User header field is described in [RFC5502]. 297 This document updates [RFC5502] to correct the P-Served-User header 298 field ABNF syntax and extend it as following: 300 P-Served-User = "P-Served-User" HCOLON PServedUser-value 301 *(SEMI served-user-param) 302 served-user-param = sessioncase-param 303 / registration-state-param 304 / generic-param 305 PServedUser-value = name-addr / addr-spec 306 sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv 307 registration-state-param = "regstate" EQUAL ("unreg" / "reg") 308 orig-cdiv = "orig-cdiv" 310 Examples of possible P-Served-User header field: 312 P-Served-User: ; orig-cdiv; regstate=reg 313 or 314 P-Served-User: ; orig-cdiv 315 or 316 P-Served-User: ; sescase=term; regstate=unreg 318 This document allows choosing between addr-spec and name-addr when 319 constructing the header field value. As specified in RFC 8217, the 320 "addr-spec" form MUST NOT be used if its value would contain a comma, 321 semicolon, or question mark [RFC8217]. 323 7. IANA Considerations 325 The syntax of the P-Served-User header field [RFC5502] is updated in 326 Section 4 of this document. 328 This document requests IANA to update the existing row for the P- 329 Served-User header field in the "Header Fields" sub-registry within 330 the "Session Initiation Protocol (SIP) Parameters" registry: 332 Header Name Compact Form Reference 333 ------------- ------------ ---------------- 334 P-Served-User none [RFC5502][RFCXXXX] 336 Note to RFC Editor: Please replace XXXX with the RFC number of this 337 document. 339 This document requests IANA to add new rows for the P-Served-User 340 header field parameters in the "Header Field Parameters and Parameter 341 Values" sub-registry within the "Session Initiation Protocol (SIP) 342 Parameters" registry: as per the registry created by [RFC3968]: 344 Header Field Parameter Name Predefined Values Reference 345 -------------- ---------------- ----------------- ----------------- 346 P-Served-User sescase Yes [RFC5502][RFCXXXX] 347 P-Served-User regstate Yes [RFC5502][RFCXXXX] 348 P-Served-User orig-cdiv No [RFCXXXX] 350 Note to RFC Editor: Please replace XXXX with the RFC number of this 351 document. 353 8. Call Flow Examples 355 8.1. Call diversion case 357 The following call flow shows a session establishment when Alice 358 calls Bob, who has a call diversion service that diverts to Carol 359 when Bob is busy. 361 proxy server UA 362 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 363 | | | | | 364 | INVITE F1 | | | | 365 |--------------->| INVITE F2 | | | 366 | |--------------->| | | 367 | | INVITE F3 | | | 368 | |<---------------| INVITE F4 | | 369 | |-------------------------------->| | 370 | | 486 F5 | | 371 | |<--------------------------------| | 372 | | 486 F6 | | | 373 | |--------------->| | | 374 | | INVITE F7 | | | 375 | |<---------------| | | 376 | | INVITE F8 | | | 377 | |--------------->| | | 378 | | INVITE F9 | | | 379 | |<---------------| INVITE F10 | 380 | |------------------------------------------------->| 381 | | | | | 382 | | | | 180 F11 | 383 | | | 180 F12 |<---------------| 384 | | 180 F13 |<---------------| | 385 | 180 F14 |<---------------| | | 386 |<---------------| | | | 387 | | | | | 389 [Alice calls Bob] 391 F1 INVITE Alice -> S-CSCF-B 392 INVITE sip:bob@example.com SIP/2.0 393 From: Alice ;tag=1928301774 394 To: Bob 396 F2 INVITE S-CSCF-B -> AS-B 397 INVITE sip:bob@example.com SIP/2.0 398 From: Alice ;tag=1928301774 399 To: Bob 400 P-Served-User: ; term; regstate=reg 402 F3 INVITE AS-B -> S-CSCF-B 403 INVITE sip:bob@example.com SIP/2.0 404 From: Alice ;tag=1928301774 405 To: Bob 406 P-Served-User: ; term; regstate=reg 408 F4 INVITE S-CSCF-B -> Bob 409 INVITE sip:bob@192.0.2.4 SIP/2.0 410 From: Alice ;tag=1928301774 411 To: Bob 412 P-Served-User: ; term; regstate=reg 414 [Bob is busy. His call diversion when busy is invoked towards Carol] 416 F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B 417 486 BUSY 418 From: Alice ;tag=1928301774 419 To: Bob ;tag=es43sd 421 [Alice's call is diverted to Carol] 422 F7 INVITE AS-B -> S-CSCF-B 423 INVITE sip:carol@domainc.com SIP/2.0 424 From: Alice ;tag=1928301774 425 To: Bob 426 P-Served-User: ; term; regstate=reg 428 [Forwarded leg to Carol is identified as an originating call after 429 diversion that should not trigger all Bob's originating services] 431 F8 INVITE S-CSCF-B -> AS-B 432 INVITE sip:carol@domainc.com SIP/2.0 433 From: Alice ;tag=1928301774 434 To: Bob 435 P-Served-User: ; orig-cdiv; regstate=reg 437 F9 INVITE AS-B -> S-CSCF-B 438 INVITE sip:carol@domainc.com SIP/2.0 439 From: Alice ;tag=1928301774 440 To: Bob 441 P-Served-User: ; orig-cdiv; regstate=reg 443 F10 INVITE S-CSCF-B -> Carol 444 INVITE sip:carol@192.0.2.7 SIP/2.0 445 From: Alice ;tag=1928301774 446 To: Bob 448 Figure 1: P-Served-User during call diversion service 450 8.2. Call diversion and privacy 452 The following call flow shows a call diversion use case for which 453 Alice has no identity restriction service and Bob has an 454 unconditional call diversion service towards Carol and an identity 455 presentation restriction service. 457 proxy server UA 458 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 459 | | | | | 460 | INVITE F1 | | | | 461 |--------------->| INVITE F2 | | | 462 | |--------------->| | | 463 | | INVITE F3 | | | 464 | |<---------------| | | 465 | | INVITE F4 | | | 466 | |--------------->| | | 467 | | INVITE F5 | | | 468 | |<---------------| INVITE F6 | | 469 | |------------------------------------------------->| 470 | | | | | 471 | | | | 180 F7 | 472 | | | 180 F8 |<---------------| 473 | | 180 F9 |<---------------| | 474 | 180 F10 |<---------------| | | 475 |<---------------| | | | 476 | | | | | 478 [Alice calls Bob] 480 F1 INVITE Alice -> S-CSCF-B 481 INVITE sip:bob@example.com SIP/2.0 482 From: Alice ;tag=1928301774 483 To: Bob 484 Supported: histinfo 486 F2 INVITE S-CSCF-B -> AS-B 487 INVITE sip:bob@example.com SIP/2.0 488 From: Alice ;tag=1928301774 489 To: Bob 490 P-Served-User: ; term; regstate=reg 492 [Bob's unconditional call diversion to Carol is triggered] 494 F3 INVITE AS-B -> S-CSCF-B 495 INVITE sip:carol@domainc.com SIP/2.0 496 From: Alice ;tag=1928301774 497 To: Carol 498 P-Served-User: ; term; regstate=reg 499 History-Info: 500 ;index=1, 501 ;index=1.1;mp=1 503 [Alice's call is diverted to Carol] 505 F4 INVITE S-CSCF-B -> AS-B 506 INVITE sip:carol@domainc.com SIP/2.0 507 From: Alice ;tag=1928301774 508 To: Carol 509 P-Served-User: ; orig-cdiv; regstate=reg 510 History-Info: 511 ;index=1, 512 ;index=1.1;mp=1 514 F5 INVITE AS-B -> S-CSCF-B 515 INVITE sip:carol@domainc.com SIP/2.0 516 From: Alice ;tag=1928301774 517 To: Carol 518 P-Served-User: ; orig-cdiv; regstate=reg 519 History-Info: 520 ;index=1, 521 ;index=1.1;mp=1 523 [Forwarded leg to Carol is identified as an originating call after 524 diversion that allows to apply Bob's privacy request to his identity 525 within the Histroy-Info header field] 527 F6 INVITE S-CSCF-B -> Carol 528 INVITE sip:carol@192.0.2.7 SIP/2.0 529 From: Alice ;tag=1928301774 530 To: Carol 531 History-Info: 532 ;index=1, 533 ;index=1.1;mp=1 534 ;index=1.1.1;rc=1.1 536 Figure 2: P-Served-User when privacy requested 538 9. Security Considerations 540 The security considerations in [RFC5502] apply. 542 As the "orig-cdiv" parameter of P-Served-User header field can be 543 used to trigger applications, it is important to ensure that the 544 parameter has not been added to the SIP message by an unauthorized 545 SIP entity. 547 10. Acknowledgments 549 The author wishes to thank the 3GPP community for providing guidance, 550 input, and comments on the document. Thanks to Dale Worley and Jean 551 Mahoney for their careful review of the document. Thanks to Paul 552 Kyzivat and Adam Roach. A special thanks to Christer Holmberg. 554 11. References 556 11.1. Normative References 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, 560 DOI 10.17487/RFC2119, March 1997, 561 . 563 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 564 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 565 . 567 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 568 A., Peterson, J., Sparks, R., Handley, M., and E. 569 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 570 DOI 10.17487/RFC3261, June 2002, 571 . 573 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 574 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 575 May 2017, . 577 [RFC8217] Sparks, R., "Clarifications for When to Use the name-addr 578 Production in SIP Messages", RFC 8217, 579 DOI 10.17487/RFC8217, August 2017, 580 . 582 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 583 (IANA) Header Field Parameter Registry for the Session 584 Initiation Protocol (SIP)", BCP 98, RFC 3968, 585 DOI 10.17487/RFC3968, December 2004, 586 . 588 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 589 Specifications: ABNF", STD 68, RFC 5234, 590 DOI 10.17487/RFC5234, January 2008, 591 . 593 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 594 C. Holmberg, "An Extension to the Session Initiation 595 Protocol (SIP) for Request History Information", RFC 7044, 596 DOI 10.17487/RFC7044, February 2014, 597 . 599 [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header 600 (P-Header) for the 3GPP IP Multimedia (IM) Core Network 601 (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 602 2009, . 604 11.2. Informative References 606 [TS.3GPP.24.229] 607 3GPP, "IP multimedia call control protocol based on 608 Session Initiation Protocol (SIP) and Session Description 609 Protocol (SDP);Stage 3", 3GPP TS 24.229 v11. 611 [TS.3GPP.29.228] 612 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 613 Signalling flows and message contents", 3GPP TS 29.228 614 v11. 616 Author's Address 618 Marianne Mohali 619 Orange 620 Orange Gardens, 44 avenue de la Republique 621 Chatillon 92326 622 France 624 Email: marianne.mohali@orange.com