idnits 2.17.1 draft-ietf-sipcore-originating-cdiv-parameter-04.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 (September 24, 2018) is 2012 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) September 24, 2018 5 Intended status: Informational 6 Expires: March 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-04 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 March 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 . . . . . . . . . . . . . . . . . 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 an information indicating the status of the session in which 102 the served user is involved (originating, terminating..). For more 103 information on session cases and the IMS, a detailed description can 104 be found in [TS.3GPP.24.229]. 106 [RFC5502] defines the originating and terminating session cases for a 107 registered or unregistered user. This document extends the P-Served- 108 User header field to include the session case for a forwarded leg 109 when a call diversion service (CDIV) has been invoked and if an 110 originating service of the diverting user has to be triggered. 112 The sessioncase-param parameter of the P-Served-User header field is 113 extended with the "orig-cdiv" parameter for this "originating after 114 CDIV" session case. 116 The following section defines usage of the "orig-cdiv" parameter of 117 P-Served-User header field, Section 3 discusses the applicability and 118 scope of this new header field parameter, and Section 4 specifies the 119 proxy behavior for handling the new header field parameter. 120 Section 5 clarifies some of the [RFC5502] procedures, Section 6 121 describes the extended syntax and corrects the syntax of [RFC5502], 122 Section 8 registers the P-Served-User header field parameters with 123 IANA, Section 7 gives some examples, and Section 9 discusses the 124 security properties of the environment where this new header field 125 parameter is intended to be used. 127 1.2. Basic Use Case 129 In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) 130 is a SIP proxy that serves as a registrar and handles originating and 131 terminating session states for users assigned to it. This means that 132 any call that is originated by a specific user or any call that is 133 terminated to that specific user will pass through the S-CSCF that is 134 assigned to that user. 136 At the moment that an S-CSCF is assigned to a specific user, the user 137 profile is downloaded from the Home Subscriber Server (HSS) to this 138 S-CSCF, see [TS.3GPP.29.228]. The user profile contains the list of 139 actions to be taken by the S-CSCF for the served user depending on 140 the session direction (originating or terminating) and the user state 141 (registered or not) in the IMS network. With this user profile, the 142 S-CSCF determines the current case and applies the corresponding 143 actions such as forwarding the request to an AS. The AS then goes 144 through a similar process of determining who is the current served 145 user, what is his/her "registration state", and what is the "session 146 case" of the session. [RFC5502] defines all those parameters and in 147 particular the originating and terminating session cases. 149 In basic call scenarios, there is no particular issue for the S-CSCF 150 and AS to know which scenario needs to be realized, but in case of 151 call diversion services for which the session is re-targeted, the 152 session cases defined in [RFC5502] pose some limitations as described 153 in the following section. 155 1.3. Problem Statement 157 In the case of a call diversion service, the received request is 158 first treated as a terminating session case, and the terminating 159 filter criteria configured in the S-CSCF are performed. A filter 160 criteria is a user profile information that determines whether a 161 particular initial request needs to be sent to a particular AS. When 162 the AS receives the call initiation request, the AS is able to 163 determine the served user and the session case (here "term") from the 164 received P-Served-User header field content and to execute 165 terminating services. When the call diversion service is executed 166 (as a terminating service), the AS changes the target (Request-URI) 167 of the session and a new call leg is created. This new call leg 168 could be considered as an originating call leg from the diverting 169 user but this is not the case. Indeed, the originating user remains 170 the same, and some of the diverting user's originating services 171 should not be triggered as if it was an originating call. For 172 instance, the originating user identity should not be restricted 173 because the diverting user has a privacy service for his/her own 174 identity. The privacy of the diverting user should apply to 175 information related to this user (eg. in the History-Info header 176 field). In the same manner, some specific services will need to be 177 triggered on the outgoing leg after a call diversion. Without a 178 dedicated session case for originating after CDIV, the S-CSCF cannot 179 trigger an originating service for the diverting user, nor can an AS 180 execute the procedures for this particular session case. 182 For this use case, this document creates a new parameter for the 183 originating after CDIV session case to be embedded in the P-Served- 184 User header field. 186 2. Conventions and Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 3. Applicability 196 The use of the P-Served-User header field extensions is only 197 applicable inside a Trust Domain [RFC3324] for the P-Served-User 198 header field. Nodes in such a Trust Domain explicitly trust each 199 other to convey the served user and to be responsible for withholding 200 that information outside of the Trust Domain. The means by which the 201 network determines the served user and the policies that are executed 202 for a specific served user is outside the scope of this document. 204 4. Proxy behavior and parameter handling 206 The following section illustrates how this header field parameter can 207 be used in a 3GPP network. 209 For a terminating call, the following steps will be followed: 211 1. The S-CSCF receives the initial INVITE request for a terminating 212 call and determines that the session case is for a terminating 213 user as described in [RFC5502]; 215 2. The S-CSCF determines who is the served user by looking at the 216 Request-URI and saves the current Request-URI; 218 3. The S-CSCF analyzes the filter criteria. It then sends the 219 request to the AS of the served user an INVITE that includes the 220 P-Served-User header field with the "sescase" parameter set to 221 "term" and the "regstate" set to the corresponding value in order 222 to trigger execution of terminating services; 224 4. Based on some criteria, the AS concludes that the request has to 225 be diverted to another target user or application. The AS 226 replaces the received Request-URI with the new diverted-to 227 address and the AS stores the successive Request-URI(s) values by 228 adding one or two History-Info header field entry(ies) [RFC7044] 229 in the outgoing INVITE. In the History-Info header field, the 230 served user address is tagged using the mp-param header field 231 parameter added in entry associated to the diverted-to address 232 created. The AS forwards the INVITE request back to the S-CSCF; 234 5. When receiving back the INVITE request, the S-CSCF can see that 235 the topmost Route header field contains its own hostname but the 236 Request-URI does not match the saved Request-URI. In this case, 237 the S-CSCF updates the P-Served-User header field content by 238 replacing the "sescase" parameter with the "orig-cdiv" parameter. 239 The P-Served-User header field value remains unchanged; 241 6. The S-CSCF forwards the INVITE request to an AS that hosts the 242 originating services of the served user (diverting user) that 243 need to be executed on the forwarded leg after a call diversion 244 service; 246 7. When the AS receives the INVITE request, it determines that the 247 session case is for "orig-cdiv" session case and performs the 248 originating services to be executed after retargeting for the 249 diverting user (i.e. served user). 251 5. Clarification of RFC5502 procedures 253 This document provides the following guidance for the handling of the 254 P-Served-User header field that are missing in [RFC5502]: 256 o The P-Served-User header field MUST NOT be repeated within a 257 request for a particular session at a particular time for the 258 reason that session cases are mutually exclusive. This document 259 updates [RFC5502] to clearly state that the P-Served-User header 260 field MUST NOT contain multiple values either comma-separated or 261 header-separated. This documents also updates the syntax of the 262 header from [RFC5502] to reflect this uniqueness of parameters 263 values. 265 o In [RFC5502], except for security reasons, it is not to clearly 266 stated what to do with the received P-Served-User header field 267 when a call is diverted to another destination. This document 268 dealing with this specific use case, highlights that several 269 possibilities exist: the S-CSCF could store the previous 270 "regstate" value and decide that the same value applies, or the 271 "regstate" may not be relevant after a diverting service and 272 removed, or the regstate could be combined with the orig-cdiv 273 session case to provide different services if the served user is 274 registered or unregistered. These choices are implementation 275 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