idnits 2.17.1 draft-ietf-sipcore-originating-cdiv-parameter-06.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 (November 05, 2018) is 1992 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 543, 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) November 05, 2018 5 Intended status: Informational 6 Expires: May 9, 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-06 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 May 9, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 To illustrate the problem statement, let's imagine Alice trying to 159 call Bob and Bob having a call diversion service activated towards 160 Carol's address. In the case of a call diversion service, the 161 received request is first treated as a terminating session case (at 162 Bob side), and the terminating filter criteria configured in the 163 S-CSCF are performed. A filter criteria is information in the user 164 profile that determines whether an initial request is sent to a 165 particular AS. When the AS receives the call initiation request, the 166 AS is able to determine the served user (Bob) and the session case 167 (here "term") from the received P-Served-User header field content 168 and to execute terminating services. When the call diversion service 169 is executed (as a terminating service of Bob), the AS changes the 170 target (Request-URI) of the session (toward Carol's address) and a 171 new call leg is created. The served user becomes the diverting user. 172 This new call leg could be considered as an originating call leg from 173 the diverting user (Bob) but this is not the case. Indeed, the 174 originating user remains the same (Alice), and some of the diverting 175 user's originating services should not be triggered as if it was an 176 originating call. For instance, the originating user identity 177 (Alice) should not be restricted because the diverting user (Bob) has 178 a privacy service for his own identity. The privacy of the diverting 179 user should apply to information related to this user only (eg. in 180 the History-Info header field). In the same manner, some specific 181 services will need to be triggered on the outgoing leg after a call 182 diversion. Without a dedicated session case for originating after 183 CDIV, the S-CSCF cannot trigger an originating service for the 184 diverting user, nor can an AS execute the procedures for this 185 particular session case. 187 For this use case, this document creates a new parameter for the 188 originating after CDIV session case to be embedded in the P-Served- 189 User header field. 191 2. Conventions and Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 3. Applicability 201 The use of the P-Served-User header field extensions is only 202 applicable inside a Trust Domain [RFC3324] for the P-Served-User 203 header field. Nodes in such a Trust Domain explicitly trust each 204 other to convey the served user and to be responsible for withholding 205 that information outside of the Trust Domain. The means by which the 206 network determines the served user and the policies that are executed 207 for a specific served user is outside the scope of this document. 209 4. Proxy behavior and parameter handling 211 The following section illustrates how this header field parameter can 212 be used in a 3GPP network. 214 For a terminating call, the following steps will be followed: 216 1. The S-CSCF receives the initial INVITE request for a terminating 217 call and determines that the session case is for a terminating 218 user as described in [RFC5502]; 220 2. The S-CSCF determines who is the served user by looking at the 221 Request-URI and saves the current Request-URI; 223 3. The S-CSCF analyzes the filter criteria. It then sends the 224 request to the AS of the served user as an INVITE that includes 225 the P-Served-User header field with the "sescase" parameter set 226 to "term" and the "regstate" set to the corresponding value in 227 order to trigger execution of terminating services; 229 4. Based on some criteria, the AS concludes that the request has to 230 be diverted to another target user or application. The AS 231 replaces the received Request-URI with the new diverted-to 232 address and the AS stores the successive Request-URI(s) values by 233 adding one or two History-Info header field entry(ies) [RFC7044] 234 in the outgoing INVITE. In the History-Info header field, the 235 served user address is tagged using the mp-param header field 236 parameter added in entry associated to the diverted-to address 237 created. The AS forwards the INVITE request back to the S-CSCF; 239 5. When receiving back the INVITE request, the S-CSCF can see that 240 the topmost Route header field contains its own hostname but the 241 Request-URI does not match the saved Request-URI. In this case, 242 the S-CSCF updates the P-Served-User header field content by 243 replacing the "sescase" parameter with the "orig-cdiv" parameter. 244 The P-Served-User header field value remains unchanged; 246 6. The S-CSCF forwards the INVITE request to an AS that hosts the 247 originating services of the served user (diverting user) that 248 need to be executed on the forwarded leg after a call diversion 249 service; 251 7. When the AS receives the INVITE request, it determines that the 252 session case is for "orig-cdiv" session case and performs the 253 originating services to be executed after retargeting for the 254 diverting user (i.e. served user). 256 5. Clarification of RFC5502 procedures 258 This document provides the following guidance for the handling of the 259 P-Served-User header field that are missing in [RFC5502]: 261 o The P-Served-User header field MUST NOT be repeated within a 262 request for a particular session at a particular time for the 263 reason that session cases are mutually exclusive. This document 264 updates [RFC5502] to clearly state that the P-Served-User header 265 field MUST NOT contain multiple values either comma-separated or 266 header-separated. This documents also updates the syntax of the 267 header from [RFC5502] to reflect this uniqueness of parameters 268 values. 270 o [RFC5502] does not clearly state what to do with the received P- 271 Served-User header field when a call is diverted to another 272 destination. This document highlights that there are several ways 273 of handling the P-Served-User header field: the S-CSCF could store 274 the previous "regstate" value and decide that the same value 275 applies; or the "regstate" may no longer be relevant after a 276 diverting service so the S-CSCF removes it; or the regstate could 277 be combined with the orig-cdiv session case to provide different 278 services depending on whether the served user is registered or 279 unregistered. These choices are implementation dependent. 281 6. Syntax 283 6.1. General 285 [RFC5502] defines the P-Served-User header field with the 286 sessioncase-param parameter "sescase" which is specified as having 287 "orig" and "term" predefined values. This document defines an 288 additional parameter for the sessioncase-param: "orig-cdiv". 290 Because this document extends the existing sessioncase-param 291 parameter, and because errors have been identified in the syntax, 292 this document corrects and extends the P-Served-User header field. 294 The extension of the sessioncase-param parameter to add the "orig- 295 cdiv" session case is done in a way to fit the parameter format 296 introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and to maintain 297 a backward compatibility. 299 "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- 300 param" are defined in [RFC3261]. 302 6.2. ABNF 304 The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P- 305 Served-User header field is described in [RFC5502]. 307 This document updates [RFC5502] to correct the P-Served-User header 308 field ABNF syntax and extend it as following: 310 P-Served-User = "P-Served-User" HCOLON PServedUser-value 311 *(SEMI served-user-param) 312 served-user-param = sessioncase-param 313 / registration-state-param 314 / generic-param 315 PServedUser-value = name-addr / addr-spec 316 sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv 317 registration-state-param = "regstate" EQUAL ("unreg" / "reg") 318 orig-cdiv = "orig-cdiv" 320 Examples of possible P-Served-User header field: 322 P-Served-User: ; orig-cdiv; regstate=reg 323 or 324 P-Served-User: ; orig-cdiv 325 or 326 P-Served-User: ; sescase=term; regstate=unreg 327 This document allows choosing between addr-spec and name-addr when 328 constructing the header field value. As specified in RFC 8217, the 329 "addr-spec" form MUST NOT be used if its value would contain a comma, 330 semicolon, or question mark [RFC8217]. 332 7. Call Flow Examples 334 7.1. Call diversion case 336 The following call flow shows a session establishment when Alice 337 calls Bob, who has a call diversion service that diverts to Carol 338 when Bob is busy. 340 proxy server UA 341 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 342 | | | | | 343 | INVITE F1 | | | | 344 |--------------->| INVITE F2 | | | 345 | |--------------->| | | 346 | | INVITE F3 | | | 347 | |<---------------| INVITE F4 | | 348 | |-------------------------------->| | 349 | | 486 F5 | | 350 | |<--------------------------------| | 351 | | 486 F6 | | | 352 | |--------------->| | | 353 | | INVITE F7 | | | 354 | |<---------------| | | 355 | | INVITE F8 | | | 356 | |--------------->| | | 357 | | INVITE F9 | | | 358 | |<---------------| INVITE F10 | 359 | |------------------------------------------------->| 360 | | | | | 361 | | | | 180 F11 | 362 | | | 180 F12 |<---------------| 363 | | 180 F13 |<---------------| | 364 | 180 F14 |<---------------| | | 365 |<---------------| | | | 366 | | | | | 368 [Alice calls Bob] 370 F1 INVITE Alice -> S-CSCF-B 371 INVITE sip:bob@example.com SIP/2.0 372 From: Alice ;tag=1928301774 373 To: Bob 375 F2 INVITE S-CSCF-B -> AS-B 376 INVITE sip:bob@example.com SIP/2.0 377 From: Alice ;tag=1928301774 378 To: Bob 379 P-Served-User: ; term; regstate=reg 381 F3 INVITE AS-B -> S-CSCF-B 382 INVITE sip:bob@example.com SIP/2.0 383 From: Alice ;tag=1928301774 384 To: Bob 385 P-Served-User: ; term; regstate=reg 387 F4 INVITE S-CSCF-B -> Bob 388 INVITE sip:bob@192.0.2.4 SIP/2.0 389 From: Alice ;tag=1928301774 390 To: Bob 391 P-Served-User: ; term; regstate=reg 393 [Bob is busy. His call diversion when busy is invoked towards Carol] 395 F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B 396 486 BUSY 397 From: Alice ;tag=1928301774 398 To: Bob ;tag=es43sd 400 [Alice's call is diverted to Carol] 402 F7 INVITE AS-B -> S-CSCF-B 403 INVITE sip:carol@domainc.com SIP/2.0 404 From: Alice ;tag=1928301774 405 To: Bob 406 P-Served-User: ; term; regstate=reg 408 [Forwarded leg to Carol is identified as an originating call after 409 diversion that should not trigger all Bob's originating services] 411 F8 INVITE S-CSCF-B -> AS-B 412 INVITE sip:carol@domainc.com SIP/2.0 413 From: Alice ;tag=1928301774 414 To: Bob 415 P-Served-User: ; orig-cdiv; regstate=reg 417 F9 INVITE AS-B -> S-CSCF-B 418 INVITE sip:carol@domainc.com SIP/2.0 419 From: Alice ;tag=1928301774 420 To: Bob 421 P-Served-User: ; orig-cdiv; regstate=reg 423 F10 INVITE S-CSCF-B -> Carol 424 INVITE sip:carol@192.0.2.7 SIP/2.0 425 From: Alice ;tag=1928301774 426 To: Bob 428 Figure 1: P-Served-User during call diversion service 430 7.2. Call diversion and privacy 432 The following call flow shows a call diversion use case for which 433 Alice has no identity restriction service and Bob has an 434 unconditional call diversion service towards Carol and an identity 435 presentation restriction service. 437 proxy server UA 438 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 439 | | | | | 440 | INVITE F1 | | | | 441 |--------------->| INVITE F2 | | | 442 | |--------------->| | | 443 | | INVITE F3 | | | 444 | |<---------------| | | 445 | | INVITE F4 | | | 446 | |--------------->| | | 447 | | INVITE F5 | | | 448 | |<---------------| INVITE F6 | | 449 | |------------------------------------------------->| 450 | | | | | 451 | | | | 180 F7 | 452 | | | 180 F8 |<---------------| 453 | | 180 F9 |<---------------| | 454 | 180 F10 |<---------------| | | 455 |<---------------| | | | 456 | | | | | 458 [Alice calls Bob] 460 F1 INVITE Alice -> S-CSCF-B 461 INVITE sip:bob@example.com SIP/2.0 462 From: Alice ;tag=1928301774 463 To: Bob 464 Supported: histinfo 466 F2 INVITE S-CSCF-B -> AS-B 467 INVITE sip:bob@example.com SIP/2.0 468 From: Alice ;tag=1928301774 469 To: Bob 470 P-Served-User: ; term; regstate=reg 472 [Bob's unconditional call diversion to Carol is triggered] 474 F3 INVITE AS-B -> S-CSCF-B 475 INVITE sip:carol@domainc.com SIP/2.0 476 From: Alice ;tag=1928301774 477 To: Carol 478 P-Served-User: ; term; regstate=reg 479 History-Info: 480 ;index=1, 481 ;index=1.1;mp=1 483 [Alice's call is diverted to Carol] 485 F4 INVITE S-CSCF-B -> AS-B 486 INVITE sip:carol@domainc.com SIP/2.0 487 From: Alice ;tag=1928301774 488 To: Carol 489 P-Served-User: ; orig-cdiv; regstate=reg 490 History-Info: 491 ;index=1, 492 ;index=1.1;mp=1 494 F5 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: ; orig-cdiv; regstate=reg 499 History-Info: 500 ;index=1, 501 ;index=1.1;mp=1 503 [Forwarded leg to Carol is identified as an originating call after 504 diversion that allows to apply Bob's privacy request to his identity 505 within the Histroy-Info header field] 507 F6 INVITE S-CSCF-B -> Carol 508 INVITE sip:carol@192.0.2.7 SIP/2.0 509 From: Alice ;tag=1928301774 510 To: Carol 511 History-Info: 512 ;index=1, 513 ;index=1.1;mp=1 514 ;index=1.1.1;rc=1.1 516 Figure 2: P-Served-User when privacy requested 518 8. IANA Considerations 520 The syntax of the P-Served-User header field [RFC5502] is updated in 521 Section 4 of this document. 523 This document requests IANA to update the existing row for the P- 524 Served-User header field in the "Header Fields" sub-registry within 525 the "Session Initiation Protocol (SIP) Parameters" registry: 527 Header Name Compact Form Reference 528 ------------- ------------ ---------------- 529 P-Served-User none [RFC5502][RFCXXXX] 531 Note to RFC Editor: Please replace XXXX with the RFC number of this 532 document. 534 This document requests IANA to add new rows for the P-Served-User 535 header field parameters in the "Header Field Parameters and Parameter 536 Values" sub-registry within the "Session Initiation Protocol (SIP) 537 Parameters" registry: as per the registry created by [RFC3968]: 539 Header Field Parameter Name Predefined Values Reference 540 -------------- ---------------- ----------------- ----------------- 541 P-Served-User sescase Yes [RFC5502] 542 P-Served-User regstate Yes [RFC5502] 543 P-Served-User orig-cdiv No [RFCXXXX] 545 Note to RFC Editor: Please replace XXXX with the RFC number of this 546 document. 548 9. Security Considerations 550 The security considerations in [RFC5502] apply. 552 As the "orig-cdiv" parameter of P-Served-User header field can be 553 used to trigger applications when a call is diverted , it is 554 important to ensure that the parameter has not been added to the SIP 555 message by an unauthorized SIP entity. Thus, the P-Served-User 556 header field is to be used in a trusted environment and proxies MUST 557 NOT insert the header unless they have sufficient knowledge that the 558 route set includes another trusted proxy. 560 10. Acknowledgments 562 The author wishes to thank the 3GPP community for providing guidance, 563 input, and comments on the document. Thanks to Dale Worley, Jean 564 Mahoney and Ben Campbell for their careful review of the document. 565 Thanks to Paul Kyzivat and Adam Roach. A special thanks to Christer 566 Holmberg. 568 11. References 570 11.1. Normative References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, 574 DOI 10.17487/RFC2119, March 1997, 575 . 577 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 578 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 579 . 581 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 582 A., Peterson, J., Sparks, R., Handley, M., and E. 583 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 584 DOI 10.17487/RFC3261, June 2002, 585 . 587 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 588 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 589 May 2017, . 591 [RFC8217] Sparks, R., "Clarifications for When to Use the name-addr 592 Production in SIP Messages", RFC 8217, 593 DOI 10.17487/RFC8217, August 2017, 594 . 596 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 597 (IANA) Header Field Parameter Registry for the Session 598 Initiation Protocol (SIP)", BCP 98, RFC 3968, 599 DOI 10.17487/RFC3968, December 2004, 600 . 602 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 603 Specifications: ABNF", STD 68, RFC 5234, 604 DOI 10.17487/RFC5234, January 2008, 605 . 607 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 608 C. Holmberg, "An Extension to the Session Initiation 609 Protocol (SIP) for Request History Information", RFC 7044, 610 DOI 10.17487/RFC7044, February 2014, 611 . 613 [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header 614 (P-Header) for the 3GPP IP Multimedia (IM) Core Network 615 (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 616 2009, . 618 11.2. Informative References 620 [TS.3GPP.24.229] 621 3GPP, "IP multimedia call control protocol based on 622 Session Initiation Protocol (SIP) and Session Description 623 Protocol (SDP);Stage 3", 3GPP TS 24.229 v11. 625 [TS.3GPP.29.228] 626 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 627 Signalling flows and message contents", 3GPP TS 29.228 628 v11. 630 Author's Address 632 Marianne Mohali 633 Orange 634 Orange Gardens, 44 avenue de la Republique 635 Chatillon 92326 636 France 638 Email: marianne.mohali@orange.com