idnits 2.17.1 draft-ietf-sipcore-originating-cdiv-parameter-05.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 (October 11, 2018) is 1996 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 538, 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) October 11, 2018 5 Intended status: Informational 6 Expires: April 14, 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-05 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 April 14, 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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 82 7.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 83 7.2. Call diversion and privacy . . . . . . . . . . . . . . . 10 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 89 11.2. Informative References . . . . . . . . . . . . . . . . . 14 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 Serving Call Session Control Function (S-CSCF) and an Application 100 Server (AS) on the IMS Service Control (ISC) interface. A session 101 case is metadata that captures the status of the session of a served 102 user: whether the served user is registered or not, and whether the 103 session originates or terminates with the served user. For more 104 information on session cases and the IMS, a detailed description can 105 be found in [TS.3GPP.24.229]. 107 [RFC5502] defines the originating and terminating session cases for a 108 registered or unregistered user. This document extends the P-Served- 109 User header field to include the session case for a forwarded leg 110 when a call diversion service (CDIV) has been invoked and if an 111 originating service of the diverting user has to be triggered. 113 The sessioncase-param parameter of the P-Served-User header field is 114 extended with the "orig-cdiv" parameter for this "originating after 115 CDIV" session case. 117 The following section defines usage of the "orig-cdiv" parameter of 118 P-Served-User header field, Section 3 discusses the applicability and 119 scope of this new header field parameter, and Section 4 specifies the 120 proxy behavior for handling the new header field parameter. 121 Section 5 clarifies some of the [RFC5502] procedures, Section 6 122 describes the extended syntax and corrects the syntax of [RFC5502], 123 Section 8 registers the P-Served-User header field parameters with 124 IANA, Section 7 gives some examples, and Section 9 discusses the 125 security properties of the environment where this new header field 126 parameter is intended to be used. 128 1.2. Basic Use Case 130 In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) 131 is a SIP proxy that serves as a registrar and handles originating and 132 terminating session states for users assigned to it. This means that 133 any call that is originated by a specific user or any call that is 134 terminated to that specific user will pass through the S-CSCF that is 135 assigned to that user. 137 At the moment that an S-CSCF is assigned to a specific user, the user 138 profile is downloaded from the Home Subscriber Server (HSS) to this 139 S-CSCF, see [TS.3GPP.29.228]. The user profile contains the list of 140 actions to be taken by the S-CSCF for the served user depending on 141 the session direction (originating or terminating) and the user state 142 (registered or not) in the IMS network. With this user profile, the 143 S-CSCF determines the current case and applies the corresponding 144 actions such as forwarding the request to an AS. The AS then goes 145 through a similar process of determining who is the current served 146 user, what is his/her "registration state", and what is the "session 147 case" of the session. [RFC5502] defines all those parameters and in 148 particular the originating and terminating session cases. 150 In basic call scenarios, there is no particular issue for the S-CSCF 151 and AS to know which scenario needs to be realized, but in case of 152 call diversion services for which the session is re-targeted, the 153 session cases defined in [RFC5502] pose some limitations as described 154 in the following section. 156 1.3. Problem Statement 158 In the case of a call diversion service, the received request is 159 first treated as a terminating session case, and the terminating 160 filter criteria configured in the S-CSCF are performed. A filter 161 criteria is information in the user profile that determines whether 162 an initial request is sent to a particular AS. When the AS receives 163 the call initiation request, the AS is able to determine the served 164 user and the session case (here "term") from the received P-Served- 165 User header field content and to execute terminating services. When 166 the call diversion service is executed (as a terminating service), 167 the AS changes the target (Request-URI) of the session and a new call 168 leg is created. This new call leg could be considered as an 169 originating call leg from the diverting user but this is not the 170 case. Indeed, the originating user remains the same, and some of the 171 diverting user's originating services should not be triggered as if 172 it was an originating call. For instance, the originating user 173 identity should not be restricted because the diverting user has a 174 privacy service for his/her own identity. The privacy of the 175 diverting user should apply to information related to this user (eg. 176 in the History-Info header field). In the same manner, some specific 177 services will need to be triggered on the outgoing leg after a call 178 diversion. Without a dedicated session case for originating after 179 CDIV, the S-CSCF cannot trigger an originating service for the 180 diverting user, nor can an AS execute the procedures for this 181 particular session case. 183 For this use case, this document creates a new parameter for the 184 originating after CDIV session case to be embedded in the P-Served- 185 User header field. 187 2. Conventions and Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in BCP 192 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 3. Applicability 197 The use of the P-Served-User header field extensions is only 198 applicable inside a Trust Domain [RFC3324] for the P-Served-User 199 header field. Nodes in such a Trust Domain explicitly trust each 200 other to convey the served user and to be responsible for withholding 201 that information outside of the Trust Domain. The means by which the 202 network determines the served user and the policies that are executed 203 for a specific served user is outside the scope of this document. 205 4. Proxy behavior and parameter handling 207 The following section illustrates how this header field parameter can 208 be used in a 3GPP network. 210 For a terminating call, the following steps will be followed: 212 1. The S-CSCF receives the initial INVITE request for a terminating 213 call and determines that the session case is for a terminating 214 user as described in [RFC5502]; 216 2. The S-CSCF determines who is the served user by looking at the 217 Request-URI and saves the current Request-URI; 219 3. The S-CSCF analyzes the filter criteria. It then sends the 220 request to the AS of the served user an INVITE that includes the 221 P-Served-User header field with the "sescase" parameter set to 222 "term" and the "regstate" set to the corresponding value in order 223 to trigger execution of terminating services; 225 4. Based on some criteria, the AS concludes that the request has to 226 be diverted to another target user or application. The AS 227 replaces the received Request-URI with the new diverted-to 228 address and the AS stores the successive Request-URI(s) values by 229 adding one or two History-Info header field entry(ies) [RFC7044] 230 in the outgoing INVITE. In the History-Info header field, the 231 served user address is tagged using the mp-param header field 232 parameter added in entry associated to the diverted-to address 233 created. The AS forwards the INVITE request back to the S-CSCF; 235 5. When receiving back the INVITE request, the S-CSCF can see that 236 the topmost Route header field contains its own hostname but the 237 Request-URI does not match the saved Request-URI. In this case, 238 the S-CSCF updates the P-Served-User header field content by 239 replacing the "sescase" parameter with the "orig-cdiv" parameter. 240 The P-Served-User header field value remains unchanged; 242 6. The S-CSCF forwards the INVITE request to an AS that hosts the 243 originating services of the served user (diverting user) that 244 need to be executed on the forwarded leg after a call diversion 245 service; 247 7. When the AS receives the INVITE request, it determines that the 248 session case is for "orig-cdiv" session case and performs the 249 originating services to be executed after retargeting for the 250 diverting user (i.e. served user). 252 5. Clarification of RFC5502 procedures 254 This document provides the following guidance for the handling of the 255 P-Served-User header field that are missing in [RFC5502]: 257 o The P-Served-User header field MUST NOT be repeated within a 258 request for a particular session at a particular time for the 259 reason that session cases are mutually exclusive. This document 260 updates [RFC5502] to clearly state that the P-Served-User header 261 field MUST NOT contain multiple values either comma-separated or 262 header-separated. This documents also updates the syntax of the 263 header from [RFC5502] to reflect this uniqueness of parameters 264 values. 266 o [RFC5502] does not clearly state what to do with the received P- 267 Served-User header field when a call is diverted to another 268 destination. This document highlights that there are several ways 269 of handling the P-Served-User header field: the S-CSCF could store 270 the previous "regstate" value and decide that the same value 271 applies; or the "regstate" may no longer be relevant after a 272 diverting service so the S-CSCF removes it; or the regstate could 273 be combined with the orig-cdiv session case to provide different 274 services depending on whether the served user is registered or 275 unregistered. These choices are implementation dependent. 277 6. Syntax 278 6.1. General 280 [RFC5502] defines the P-Served-User header field with the 281 sessioncase-param parameter "sescase" which is specified as having 282 "orig" and "term" predefined values. This document defines an 283 additional parameter for the sessioncase-param: "orig-cdiv". 285 Because this document extends the existing sessioncase-param 286 parameter, and because errors have been identified in the syntax, 287 this document corrects and extends the P-Served-User header field. 289 The extension of the sessioncase-param parameter to add the "orig- 290 cdiv" session case is done in a way to fit the parameter format 291 introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and to maintain 292 a backward compatibility. 294 "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- 295 param" are defined in [RFC3261]. 297 6.2. ABNF 299 The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P- 300 Served-User header field is described in [RFC5502]. 302 This document updates [RFC5502] to correct the P-Served-User header 303 field ABNF syntax and extend it as following: 305 P-Served-User = "P-Served-User" HCOLON PServedUser-value 306 *(SEMI served-user-param) 307 served-user-param = sessioncase-param 308 / registration-state-param 309 / generic-param 310 PServedUser-value = name-addr / addr-spec 311 sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv 312 registration-state-param = "regstate" EQUAL ("unreg" / "reg") 313 orig-cdiv = "orig-cdiv" 315 Examples of possible P-Served-User header field: 317 P-Served-User: ; orig-cdiv; regstate=reg 318 or 319 P-Served-User: ; orig-cdiv 320 or 321 P-Served-User: ; sescase=term; regstate=unreg 322 This document allows choosing between addr-spec and name-addr when 323 constructing the header field value. As specified in RFC 8217, the 324 "addr-spec" form MUST NOT be used if its value would contain a comma, 325 semicolon, or question mark [RFC8217]. 327 7. Call Flow Examples 329 7.1. Call diversion case 331 The following call flow shows a session establishment when Alice 332 calls Bob, who has a call diversion service that diverts to Carol 333 when Bob is busy. 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 [Alice calls Bob] 365 F1 INVITE Alice -> S-CSCF-B 366 INVITE sip:bob@example.com SIP/2.0 367 From: Alice ;tag=1928301774 368 To: Bob 370 F2 INVITE S-CSCF-B -> AS-B 371 INVITE sip:bob@example.com SIP/2.0 372 From: Alice ;tag=1928301774 373 To: Bob 374 P-Served-User: ; term; regstate=reg 376 F3 INVITE AS-B -> S-CSCF-B 377 INVITE sip:bob@example.com SIP/2.0 378 From: Alice ;tag=1928301774 379 To: Bob 380 P-Served-User: ; term; regstate=reg 382 F4 INVITE S-CSCF-B -> Bob 383 INVITE sip:bob@192.0.2.4 SIP/2.0 384 From: Alice ;tag=1928301774 385 To: Bob 386 P-Served-User: ; term; regstate=reg 388 [Bob is busy. His call diversion when busy is invoked towards Carol] 390 F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B 391 486 BUSY 392 From: Alice ;tag=1928301774 393 To: Bob ;tag=es43sd 395 [Alice's call is diverted to Carol] 397 F7 INVITE AS-B -> S-CSCF-B 398 INVITE sip:carol@domainc.com SIP/2.0 399 From: Alice ;tag=1928301774 400 To: Bob 401 P-Served-User: ; term; regstate=reg 403 [Forwarded leg to Carol is identified as an originating call after 404 diversion that should not trigger all Bob's originating services] 406 F8 INVITE S-CSCF-B -> AS-B 407 INVITE sip:carol@domainc.com SIP/2.0 408 From: Alice ;tag=1928301774 409 To: Bob 410 P-Served-User: ; orig-cdiv; regstate=reg 412 F9 INVITE AS-B -> S-CSCF-B 413 INVITE sip:carol@domainc.com SIP/2.0 414 From: Alice ;tag=1928301774 415 To: Bob 416 P-Served-User: ; orig-cdiv; regstate=reg 418 F10 INVITE S-CSCF-B -> Carol 419 INVITE sip:carol@192.0.2.7 SIP/2.0 420 From: Alice ;tag=1928301774 421 To: Bob 423 Figure 1: P-Served-User during call diversion service 425 7.2. Call diversion and privacy 427 The following call flow shows a call diversion use case for which 428 Alice has no identity restriction service and Bob has an 429 unconditional call diversion service towards Carol and an identity 430 presentation restriction service. 432 proxy server UA 433 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 434 | | | | | 435 | INVITE F1 | | | | 436 |--------------->| INVITE F2 | | | 437 | |--------------->| | | 438 | | INVITE F3 | | | 439 | |<---------------| | | 440 | | INVITE F4 | | | 441 | |--------------->| | | 442 | | INVITE F5 | | | 443 | |<---------------| INVITE F6 | | 444 | |------------------------------------------------->| 445 | | | | | 446 | | | | 180 F7 | 447 | | | 180 F8 |<---------------| 448 | | 180 F9 |<---------------| | 449 | 180 F10 |<---------------| | | 450 |<---------------| | | | 451 | | | | | 453 [Alice calls Bob] 455 F1 INVITE Alice -> S-CSCF-B 456 INVITE sip:bob@example.com SIP/2.0 457 From: Alice ;tag=1928301774 458 To: Bob 459 Supported: histinfo 461 F2 INVITE S-CSCF-B -> AS-B 462 INVITE sip:bob@example.com SIP/2.0 463 From: Alice ;tag=1928301774 464 To: Bob 465 P-Served-User: ; term; regstate=reg 467 [Bob's unconditional call diversion to Carol is triggered] 469 F3 INVITE AS-B -> S-CSCF-B 470 INVITE sip:carol@domainc.com SIP/2.0 471 From: Alice ;tag=1928301774 472 To: Carol 473 P-Served-User: ; term; regstate=reg 474 History-Info: 475 ;index=1, 476 ;index=1.1;mp=1 478 [Alice's call is diverted to Carol] 480 F4 INVITE S-CSCF-B -> AS-B 481 INVITE sip:carol@domainc.com SIP/2.0 482 From: Alice ;tag=1928301774 483 To: Carol 484 P-Served-User: ; orig-cdiv; regstate=reg 485 History-Info: 486 ;index=1, 487 ;index=1.1;mp=1 489 F5 INVITE AS-B -> S-CSCF-B 490 INVITE sip:carol@domainc.com SIP/2.0 491 From: Alice ;tag=1928301774 492 To: Carol 493 P-Served-User: ; orig-cdiv; regstate=reg 494 History-Info: 495 ;index=1, 496 ;index=1.1;mp=1 498 [Forwarded leg to Carol is identified as an originating call after 499 diversion that allows to apply Bob's privacy request to his identity 500 within the Histroy-Info header field] 502 F6 INVITE S-CSCF-B -> Carol 503 INVITE sip:carol@192.0.2.7 SIP/2.0 504 From: Alice ;tag=1928301774 505 To: Carol 506 History-Info: 507 ;index=1, 508 ;index=1.1;mp=1 509 ;index=1.1.1;rc=1.1 511 Figure 2: P-Served-User when privacy requested 513 8. IANA Considerations 515 The syntax of the P-Served-User header field [RFC5502] is updated in 516 Section 4 of this document. 518 This document requests IANA to update the existing row for the P- 519 Served-User header field in the "Header Fields" sub-registry within 520 the "Session Initiation Protocol (SIP) Parameters" registry: 522 Header Name Compact Form Reference 523 ------------- ------------ ---------------- 524 P-Served-User none [RFC5502][RFCXXXX] 526 Note to RFC Editor: Please replace XXXX with the RFC number of this 527 document. 529 This document requests IANA to add new rows for the P-Served-User 530 header field parameters in the "Header Field Parameters and Parameter 531 Values" sub-registry within the "Session Initiation Protocol (SIP) 532 Parameters" registry: as per the registry created by [RFC3968]: 534 Header Field Parameter Name Predefined Values Reference 535 -------------- ---------------- ----------------- ----------------- 536 P-Served-User sescase Yes [RFC5502] 537 P-Served-User regstate Yes [RFC5502] 538 P-Served-User orig-cdiv No [RFCXXXX] 540 Note to RFC Editor: Please replace XXXX with the RFC number of this 541 document. 543 9. Security Considerations 545 The security considerations in [RFC5502] apply. 547 As the "orig-cdiv" parameter of P-Served-User header field can be 548 used to trigger applications when a call is diverted , it is 549 important to ensure that the parameter has not been added to the SIP 550 message by an unauthorized SIP entity. Thus, the P-Served-User 551 header field is to be used in a trusted environment and proxies MUST 552 NOT insert the header unless they have sufficient knowledge that the 553 route set includes another trusted proxy. 555 10. Acknowledgments 557 The author wishes to thank the 3GPP community for providing guidance, 558 input, and comments on the document. Thanks to Dale Worley, Jean 559 Mahoney and Ben Campbell for their careful review of the document. 560 Thanks to Paul Kyzivat and Adam Roach. A special thanks to Christer 561 Holmberg. 563 11. References 565 11.1. Normative References 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 573 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 574 . 576 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 577 A., Peterson, J., Sparks, R., Handley, M., and E. 578 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 579 DOI 10.17487/RFC3261, June 2002, 580 . 582 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 583 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 584 May 2017, . 586 [RFC8217] Sparks, R., "Clarifications for When to Use the name-addr 587 Production in SIP Messages", RFC 8217, 588 DOI 10.17487/RFC8217, August 2017, 589 . 591 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 592 (IANA) Header Field Parameter Registry for the Session 593 Initiation Protocol (SIP)", BCP 98, RFC 3968, 594 DOI 10.17487/RFC3968, December 2004, 595 . 597 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 598 Specifications: ABNF", STD 68, RFC 5234, 599 DOI 10.17487/RFC5234, January 2008, 600 . 602 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 603 C. Holmberg, "An Extension to the Session Initiation 604 Protocol (SIP) for Request History Information", RFC 7044, 605 DOI 10.17487/RFC7044, February 2014, 606 . 608 [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header 609 (P-Header) for the 3GPP IP Multimedia (IM) Core Network 610 (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 611 2009, . 613 11.2. Informative References 615 [TS.3GPP.24.229] 616 3GPP, "IP multimedia call control protocol based on 617 Session Initiation Protocol (SIP) and Session Description 618 Protocol (SDP);Stage 3", 3GPP TS 24.229 v11. 620 [TS.3GPP.29.228] 621 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 622 Signalling flows and message contents", 3GPP TS 29.228 623 v11. 625 Author's Address 627 Marianne Mohali 628 Orange 629 Orange Gardens, 44 avenue de la Republique 630 Chatillon 92326 631 France 633 Email: marianne.mohali@orange.com