idnits 2.17.1 draft-ietf-sipcore-originating-cdiv-parameter-08.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 (December 10, 2018) is 1963 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 549, 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) December 10, 2018 5 Intended status: Informational 6 Expires: June 13, 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-08 12 Abstract 14 The P-Served-User header field was defined based on a requirement 15 from 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia 16 Subsystem) in order to convey the identity of the served user, his/ 17 her registration state and the session case that applies to this 18 particular communication session and application invocation. A 19 session case is metadata that captures the status of the session of a 20 served user: whether the served user is registered or not, and 21 whether the session originates or terminates with the served user. 22 This document updates RFC5502 by defining a new P-Served-User header 23 field parameter, "orig-cdiv". The parameter conveys the session case 24 used by a proxy when handling an originating session after Call 25 Diversion (CDIV) services have been invoked for the served user. 26 This document also fixes the ABNF in RFC 5502 and provides more 27 guidance for using the P-Served-User header field in IP networks. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 13, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3 78 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 79 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 80 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4. Proxy behavior and parameter handling . . . . . . . . . . . . 5 82 5. Clarification of RFC5502 procedures . . . . . . . . . . . . . 6 83 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 87 7.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 88 7.2. Call diversion and privacy . . . . . . . . . . . . . . . 10 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 91 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 94 11.2. Informative References . . . . . . . . . . . . . . . . . 14 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 1.1. General 101 The P-Served-User header field [RFC5502] was defined based on a 102 requirement from 3rd Generation Partnership Project (3GPP) IMS (IP 103 Multimedia Subsystem) in order to convey the identity of the served 104 user, his/her registration state and the session case between an 105 Serving Call Session Control Function (S-CSCF) and an Application 106 Server (AS) on the IMS Service Control (ISC) interface. A session 107 case is metadata that captures the status of the session of a served 108 user: whether the served user is registered or not, and whether the 109 session originates or terminates with the served user. For more 110 information on session cases and the IMS, a detailed description can 111 be found in [TS.3GPP.24.229]. 113 [RFC5502] defines the originating and terminating session cases for a 114 registered or unregistered user. This document extends the P-Served- 115 User header field to include the session case for a forwarded leg 116 when a call diversion service (CDIV) has been invoked and if an 117 originating service of the diverting user has to be triggered. 119 The sessioncase-param parameter of the P-Served-User header field is 120 extended with the "orig-cdiv" parameter for this "originating-after- 121 CDIV" session case. 123 The following section defines usage of the "orig-cdiv" parameter of 124 P-Served-User header field, Section 3 discusses the applicability and 125 scope of this new header field parameter, and Section 4 specifies the 126 proxy behavior for handling the new header field parameter. 127 Section 5 clarifies some of the [RFC5502] procedures, Section 6 128 describes the extended syntax and corrects the syntax of [RFC5502], 129 Section 8 registers the P-Served-User header field parameters with 130 IANA, Section 7 gives some examples, and Section 9 discusses the 131 security properties of the environment where this new header field 132 parameter is intended to be used. 134 1.2. Basic Use Case 136 In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) 137 is a SIP proxy that serves as a registrar and handles originating and 138 terminating session states for users assigned to it. This means that 139 any call that is originated by a specific user or any call that is 140 terminated to that specific user will pass through the S-CSCF that is 141 assigned to that user. 143 At the moment that an S-CSCF is assigned to a specific user, the user 144 profile is downloaded from the Home Subscriber Server (HSS) to this 145 S-CSCF, see [TS.3GPP.29.228]. The user profile contains the list of 146 actions to be taken by the S-CSCF for the served user depending on 147 the session direction (originating or terminating) and the user state 148 (registered or not) in the IMS network. With this user profile, the 149 S-CSCF determines the current case and applies the corresponding 150 actions such as forwarding the request to an AS. The AS then goes 151 through a similar process of determining who is the current served 152 user, what is his/her "registration state", and what is the "session 153 case" of the session. [RFC5502] defines all those parameters and in 154 particular the originating and terminating session cases. 156 In basic call scenarios, there is no particular issue for the S-CSCF 157 and AS to know which scenario needs to be realized, but in case of 158 call diversion services for which the session is re-targeted, the 159 session cases defined in [RFC5502] pose some limitations as described 160 in the following section. 162 1.3. Problem Statement 164 To illustrate the problem statement, let's imagine Alice trying to 165 call Bob and Bob having a call diversion service activated towards 166 Carol's address. In the case of a call diversion service, the 167 received request is first treated as a terminating session case (at 168 Bob side), and the terminating filter criteria configured in the 169 S-CSCF are performed. A filter criteria is information in the user 170 profile that determines whether an initial request is sent to a 171 particular AS. When the AS receives the call initiation request, the 172 AS is able to determine the served user (Bob) and the session case 173 (here "term") from the received P-Served-User header field content 174 and to execute terminating services. When the call diversion service 175 is executed (as a terminating service of Bob), the AS changes the 176 target (Request-URI) of the session (toward Carol's address) and a 177 new call leg is created. The served user becomes the diverting user. 178 This new call leg could be considered as an originating call leg from 179 the diverting user (Bob) but this is not the case. Indeed, the 180 originating user remains the same (Alice), and some of the diverting 181 user's originating services should not be triggered as if it was an 182 originating call. For instance, the originating user identity 183 (Alice) should not be restricted because the diverting user (Bob) has 184 a privacy service for his own identity. The privacy of the diverting 185 user should apply to information related to this user only (eg. in 186 the History-Info header field). In the same manner, some specific 187 services will need to be triggered on the outgoing leg after a call 188 diversion. Without a dedicated session case for originating-after- 189 CDIV, the S-CSCF cannot trigger an originating service for the 190 diverting user, nor can an AS execute the procedures for this 191 particular session case. 193 For this use case, this document creates a new parameter ("orig- 194 cdiv") for the originating-after-CDIV session case to be embedded in 195 the P-Served-User header field. 197 2. Conventions and Terminology 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described in BCP 202 14 [RFC2119] [RFC8174] when, and only when, they appear in all 203 capitals, as shown here. 205 3. Applicability 207 The use of the P-Served-User header field extensions is only 208 applicable inside a Trust Domain [RFC3324] for the P-Served-User 209 header field. Nodes in such a Trust Domain explicitly trust each 210 other to convey the served user and to be responsible for withholding 211 that information outside of the Trust Domain. The means by which the 212 network determines the served user and the policies that are executed 213 for a specific served user is outside the scope of this document. 215 4. Proxy behavior and parameter handling 217 The following section illustrates how this header field parameter can 218 be used in a 3GPP network. 220 For a terminating call, the following steps will be followed: 222 1. The S-CSCF receives the initial INVITE request for a terminating 223 call and determines that the session case is for a terminating 224 user as described in [RFC5502]; 226 2. The S-CSCF determines who is the served user by looking at the 227 Request-URI and saves the current Request-URI; 229 3. The S-CSCF analyzes the filter criteria. It then sends the 230 request to the AS of the served user as an INVITE that includes 231 the P-Served-User header field with the "sescase" parameter set 232 to "term" and the "regstate" set to the corresponding value in 233 order to trigger execution of terminating services; 235 4. Based on some criteria, the AS concludes that the request has to 236 be diverted to another target user or application. The AS 237 replaces the received Request-URI with the new diverted-to 238 address and the AS stores the successive Request-URI(s) values by 239 adding one or two History-Info header field entry(ies) [RFC7044] 240 in the outgoing INVITE. In the History-Info header field, the 241 served user address is tagged using the mp-param header field 242 parameter added in entry associated to the diverted-to address 243 created. The AS forwards the INVITE request back to the S-CSCF; 245 5. When receiving back the INVITE request, the S-CSCF can see that 246 the topmost Route header field contains its own hostname but the 247 Request-URI does not match the saved Request-URI. In this case, 248 the S-CSCF updates the P-Served-User header field content by 249 replacing the "sescase" parameter with the "orig-cdiv" parameter. 250 The P-Served-User header field value remains unchanged; 252 6. The S-CSCF forwards the INVITE request to an AS that hosts the 253 originating services of the served user (diverting user) that 254 need to be executed on the forwarded leg after a call diversion 255 service; 257 7. When the AS receives the INVITE request, it determines that the 258 session case is for "orig-cdiv" session case and performs the 259 originating services to be executed after retargeting for the 260 diverting user (i.e. served user). 262 5. Clarification of RFC5502 procedures 264 This document provides the following guidance for the handling of the 265 P-Served-User header field that are missing in [RFC5502]: 267 o The P-Served-User header field MUST NOT be repeated within a 268 request for a particular session at a particular time for the 269 reason that session cases are mutually exclusive. This document 270 updates [RFC5502] to clearly state that the P-Served-User header 271 field MUST NOT contain multiple values either comma-separated or 272 header-separated. This documents also updates the syntax of the 273 header from [RFC5502] to reflect this uniqueness of parameters 274 values. 276 o [RFC5502] does not clearly state what to do with the received P- 277 Served-User header field when a call is diverted to another 278 destination. This document highlights that there are several ways 279 of handling the P-Served-User header field: the S-CSCF could store 280 the previous "regstate" value and decide that the same value 281 applies; or the "regstate" may no longer be relevant after a 282 diverting service so the S-CSCF removes it; or the regstate could 283 be combined with the orig-cdiv session case to provide different 284 services depending on whether the served user is registered or 285 unregistered. These choices are implementation dependent. 287 6. Syntax 289 6.1. General 291 [RFC5502] defines the P-Served-User header field with the 292 sessioncase-param parameter "sescase" which is specified as having 293 "orig" and "term" predefined values. This document defines an 294 additional parameter for the sessioncase-param: "orig-cdiv". 296 Because this document extends the existing sessioncase-param 297 parameter, and because errors have been identified in the syntax, 298 this document corrects and extends the P-Served-User header field. 300 The extension of the sessioncase-param parameter to add the "orig- 301 cdiv" session case is done in a way to fit the parameter format 302 introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and to maintain 303 a backward compatibility. 305 "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- 306 param" are defined in [RFC3261]. 308 6.2. ABNF 310 The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P- 311 Served-User header field is described in [RFC5502]. 313 This document updates [RFC5502] to correct the P-Served-User header 314 field ABNF syntax and extend it as following: 316 P-Served-User = "P-Served-User" HCOLON PServedUser-value 317 *(SEMI served-user-param) 318 served-user-param = sessioncase-param 319 / registration-state-param 320 / generic-param 321 PServedUser-value = name-addr / addr-spec 322 sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv 323 registration-state-param = "regstate" EQUAL ("unreg" / "reg") 324 orig-cdiv = "orig-cdiv" 326 Examples of possible P-Served-User header field: 328 P-Served-User: ; orig-cdiv; regstate=reg 329 or 330 P-Served-User: ; orig-cdiv 331 or 332 P-Served-User: ; sescase=term; regstate=unreg 333 This document allows choosing between addr-spec and name-addr when 334 constructing the header field value. As specified in RFC 8217, the 335 "addr-spec" form MUST NOT be used if its value would contain a comma, 336 semicolon, or question mark [RFC8217]. 338 7. Call Flow Examples 340 7.1. Call diversion case 342 The following call flow shows a session establishment when Alice 343 calls Bob, who has a call diversion service that diverts to Carol 344 when Bob is busy. 346 proxy server UA 347 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 348 | | | | | 349 | INVITE F1 | | | | 350 |--------------->| INVITE F2 | | | 351 | |--------------->| | | 352 | | INVITE F3 | | | 353 | |<---------------| INVITE F4 | | 354 | |-------------------------------->| | 355 | | 486 F5 | | 356 | |<--------------------------------| | 357 | | 486 F6 | | | 358 | |--------------->| | | 359 | | INVITE F7 | | | 360 | |<---------------| | | 361 | | INVITE F8 | | | 362 | |--------------->| | | 363 | | INVITE F9 | | | 364 | |<---------------| INVITE F10 | 365 | |------------------------------------------------->| 366 | | | | | 367 | | | | 180 F11 | 368 | | | 180 F12 |<---------------| 369 | | 180 F13 |<---------------| | 370 | 180 F14 |<---------------| | | 371 |<---------------| | | | 372 | | | | | 374 [Alice calls Bob] 376 F1 INVITE Alice -> S-CSCF-B 377 INVITE sip:bob@example.com SIP/2.0 378 From: Alice ;tag=1928301774 379 To: Bob 381 F2 INVITE S-CSCF-B -> AS-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 F3 INVITE AS-B -> S-CSCF-B 388 INVITE sip:bob@example.com SIP/2.0 389 From: Alice ;tag=1928301774 390 To: Bob 391 P-Served-User: ; term; regstate=reg 393 F4 INVITE S-CSCF-B -> Bob 394 INVITE sip:bob@192.0.2.4 SIP/2.0 395 From: Alice ;tag=1928301774 396 To: Bob 397 P-Served-User: ; term; regstate=reg 399 [Bob is busy. His call diversion when busy is invoked towards Carol] 401 F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B 402 486 BUSY 403 From: Alice ;tag=1928301774 404 To: Bob ;tag=es43sd 406 [Alice's call is diverted to Carol] 408 F7 INVITE AS-B -> S-CSCF-B 409 INVITE sip:carol@domainc.com SIP/2.0 410 From: Alice ;tag=1928301774 411 To: Bob 412 P-Served-User: ; term; regstate=reg 414 [Forwarded leg to Carol is identified as an originating call after 415 diversion that should not trigger all Bob's originating services] 417 F8 INVITE S-CSCF-B -> AS-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 F9 INVITE AS-B -> S-CSCF-B 424 INVITE sip:carol@domainc.com SIP/2.0 425 From: Alice ;tag=1928301774 426 To: Bob 427 P-Served-User: ; orig-cdiv; regstate=reg 429 F10 INVITE S-CSCF-B -> Carol 430 INVITE sip:carol@192.0.2.7 SIP/2.0 431 From: Alice ;tag=1928301774 432 To: Bob 434 Figure 1: P-Served-User during call diversion service 436 7.2. Call diversion and privacy 438 The following call flow shows a call diversion use case for which 439 Alice has no identity restriction service and Bob has an 440 unconditional call diversion service towards Carol and an identity 441 presentation restriction service. 443 proxy server UA 444 Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol 445 | | | | | 446 | INVITE F1 | | | | 447 |--------------->| INVITE F2 | | | 448 | |--------------->| | | 449 | | INVITE F3 | | | 450 | |<---------------| | | 451 | | INVITE F4 | | | 452 | |--------------->| | | 453 | | INVITE F5 | | | 454 | |<---------------| INVITE F6 | | 455 | |------------------------------------------------->| 456 | | | | | 457 | | | | 180 F7 | 458 | | | 180 F8 |<---------------| 459 | | 180 F9 |<---------------| | 460 | 180 F10 |<---------------| | | 461 |<---------------| | | | 462 | | | | | 464 [Alice calls Bob] 466 F1 INVITE Alice -> S-CSCF-B 467 INVITE sip:bob@example.com SIP/2.0 468 From: Alice ;tag=1928301774 469 To: Bob 470 Supported: histinfo 472 F2 INVITE S-CSCF-B -> AS-B 473 INVITE sip:bob@example.com SIP/2.0 474 From: Alice ;tag=1928301774 475 To: Bob 476 P-Served-User: ; term; regstate=reg 478 [Bob's unconditional call diversion to Carol is triggered] 480 F3 INVITE AS-B -> S-CSCF-B 481 INVITE sip:carol@domainc.com SIP/2.0 482 From: Alice ;tag=1928301774 483 To: Carol 484 P-Served-User: ; term; regstate=reg 485 History-Info: 486 ;index=1, 487 ;index=1.1;mp=1 489 [Alice's call is diverted to Carol] 491 F4 INVITE S-CSCF-B -> AS-B 492 INVITE sip:carol@domainc.com SIP/2.0 493 From: Alice ;tag=1928301774 494 To: Carol 495 P-Served-User: ; orig-cdiv; regstate=reg 496 History-Info: 497 ;index=1, 498 ;index=1.1;mp=1 500 F5 INVITE AS-B -> S-CSCF-B 501 INVITE sip:carol@domainc.com SIP/2.0 502 From: Alice ;tag=1928301774 503 To: Carol 504 P-Served-User: ; orig-cdiv; regstate=reg 505 History-Info: 506 ;index=1, 507 ;index=1.1;mp=1 509 [Forwarded leg to Carol is identified as an originating call after 510 diversion that allows to apply Bob's privacy request to his identity 511 within the Histroy-Info header field] 513 F6 INVITE S-CSCF-B -> Carol 514 INVITE sip:carol@192.0.2.7 SIP/2.0 515 From: Alice ;tag=1928301774 516 To: Carol 517 History-Info: 518 ;index=1, 519 ;index=1.1;mp=1 520 ;index=1.1.1;rc=1.1 522 Figure 2: P-Served-User when privacy requested 524 8. IANA Considerations 526 The syntax of the P-Served-User header field [RFC5502] is updated in 527 Section 4 of this document. 529 This document requests IANA to update the existing row for the P- 530 Served-User header field in the "Header Fields" sub-registry within 531 the "Session Initiation Protocol (SIP) Parameters" registry: 533 Header Name Compact Form Reference 534 ------------- ------------ ---------------- 535 P-Served-User none [RFC5502][RFCXXXX] 537 Note to RFC Editor: Please replace XXXX with the RFC number of this 538 document. 540 This document requests IANA to add new rows for the P-Served-User 541 header field parameters in the "Header Field Parameters and Parameter 542 Values" sub-registry within the "Session Initiation Protocol (SIP) 543 Parameters" registry: as per the registry created by [RFC3968]: 545 Header Field Parameter Name Predefined Values Reference 546 -------------- ---------------- ----------------- ----------------- 547 P-Served-User sescase Yes [RFC5502] 548 P-Served-User regstate Yes [RFC5502] 549 P-Served-User orig-cdiv No [RFCXXXX] 551 Note to RFC Editor: Please replace XXXX with the RFC number of this 552 document. 554 9. Security Considerations 556 The security considerations in [RFC5502] apply. 558 As the "orig-cdiv" parameter of P-Served-User header field can be 559 used to trigger applications when a call is diverted , it is 560 important to ensure that the parameter has not been added to the SIP 561 message by an unauthorized SIP entity. Thus, the P-Served-User 562 header field is to be used in a trusted environment and proxies MUST 563 NOT insert the header unless they have sufficient knowledge that the 564 route set includes another trusted proxy. 566 10. Acknowledgments 568 The author wishes to thank the 3GPP community for providing guidance, 569 input, and comments on the document. Thanks to Dale Worley, Jean 570 Mahoney and Ben Campbell for their careful review of the document. 571 Thanks to Paul Kyzivat and Adam Roach. A special thanks to Christer 572 Holmberg. 574 11. References 576 11.1. Normative References 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, 580 DOI 10.17487/RFC2119, March 1997, 581 . 583 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 584 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 585 . 587 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 588 A., Peterson, J., Sparks, R., Handley, M., and E. 589 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 590 DOI 10.17487/RFC3261, June 2002, 591 . 593 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 594 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 595 May 2017, . 597 [RFC8217] Sparks, R., "Clarifications for When to Use the name-addr 598 Production in SIP Messages", RFC 8217, 599 DOI 10.17487/RFC8217, August 2017, 600 . 602 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 603 (IANA) Header Field Parameter Registry for the Session 604 Initiation Protocol (SIP)", BCP 98, RFC 3968, 605 DOI 10.17487/RFC3968, December 2004, 606 . 608 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 609 Specifications: ABNF", STD 68, RFC 5234, 610 DOI 10.17487/RFC5234, January 2008, 611 . 613 [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and 614 C. Holmberg, "An Extension to the Session Initiation 615 Protocol (SIP) for Request History Information", RFC 7044, 616 DOI 10.17487/RFC7044, February 2014, 617 . 619 [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header 620 (P-Header) for the 3GPP IP Multimedia (IM) Core Network 621 (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 622 2009, . 624 11.2. Informative References 626 [TS.3GPP.24.229] 627 3GPP, "IP multimedia call control protocol based on 628 Session Initiation Protocol (SIP) and Session Description 629 Protocol (SDP);Stage 3", 3GPP TS 24.229 v11. 631 [TS.3GPP.29.228] 632 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 633 Signalling flows and message contents", 3GPP TS 29.228 634 v11. 636 Author's Address 638 Marianne Mohali 639 Orange 640 Orange Gardens, 44 avenue de la Republique 641 Chatillon 92326 642 France 644 Email: marianne.mohali@orange.com