SIPCORE Working GroupInternet Engineering Task Force (IETF) M. MohaliInternet-DraftRequest for Comments: 8498 Orange Updates: 5502(if approved) December 10, 2018 Intended status: Informational Expires: June 13,February 2019 Category: Informational ISSN: 2070-1721 A P-Served-User Header Field Parameter for an OriginatingCDIV session caseCall Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)draft-ietf-sipcore-originating-cdiv-parameter-08Abstract The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/ her registrationstatestate, and the session case that applies tothisthat particular communication session and application invocation. A session case is metadata that captures the status of the session of a serveduser:user regardless of whether or not the served user is registered ornot, and whetherthe session originates or terminates with the served user. This document updatesRFC5502RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks. Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draftthe IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documentsvalidapproved by the IESG are candidates fora maximumany level ofsix monthsInternet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 13, 2019.https://www.rfc-editor.org/info/rfc8498. Copyright Notice Copyright (c)20182019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 4. ProxybehaviorBehavior andparameter handlingParameter Handling . . . . . . . . . . . . 5 5. Clarification ofRFC5502 procedures .RFC 5502 Procedures . . . . . . . . . . . . 6 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 7.1. Calldiversion caseDiversion Case . . . . . . . . . . . . . . . . . . . 8 7.2. CalldiversionDiversion andprivacyPrivacy . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10.AcknowledgmentsReferences . . . . . . . . . . . . . . . . . . . . . . . . . 1311.10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . .13 11.1. Normative References. . . . . . . . . . 14 Acknowledgments . . . . . . . .13 11.2. Informative References. . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction 1.1. General The P-Served-User header field [RFC5502] was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/her registrationstatestate, and the session case betweenana Serving Call Session Control Function (S-CSCF) and an Application Server (AS) on the IMS Service Control (ISC) interface. A session case is metadata that captures the status of the session of a serveduser:user regardless of whether or not the served user is registered ornot, and whetherthe session originates or terminates with the served user. For more information on session cases and the IMS, a detailed description can be found in [TS.3GPP.24.229]. [RFC5502] defines the originating and terminating session cases for a registered or unregistered user. This document extends the P-Served- User header field to include the session case for a forwarded leg when both acall diversionCDIV service(CDIV)has been invoked andifan originating service of the diverting user has to be triggered. The sessioncase-param parameter of the P-Served-User header field is extended with the "orig-cdiv" parameter for this"originating-after- CDIV"originating-after- CDIV session case. The following section defines usage of the "orig-cdiv" parameter of the P-Served-User header field, Section 3 discusses the applicability and scope of this new header field parameter, and Section 4 specifies the proxy behavior for handling the new header field parameter. Section 5 clarifies some of the [RFC5502] procedures, Section 6 describes the extended syntax and corrects the syntax of [RFC5502], Section 7 gives some call flow examples, Section 8 registers the P-Served-User header field parameters with IANA,Section 7 gives some examples,and Section 9 discusses the security properties of the environment where this new header field parameter is intended to be used. 1.2. Basic Use Case In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) is a SIP proxy that serves as a registrar and handles originating and terminating session states for users assigned to it. This means that any call that is originated by a specific user or any call that is terminated to that specific user will pass through the S-CSCF that is assigned to that user. At the moment that an S-CSCF is assigned to a specific user, the user profile is downloaded from the Home Subscriber Server (HSS) tothis S-CSCF,that S-CSCF; see [TS.3GPP.29.228]. The user profile contains the list of actions to be taken by the S-CSCF for the served user depending on the session direction (originating or terminating) and the user state (registered or not) in the IMS network. With this user profile, the S-CSCF determines the current case and applies the corresponding actions such as forwarding the request to an AS. The AS then goes through a similar process of determining who is the current served user, what is his/her "registration state", and what is the "session case" of the session. [RFC5502] defines all those parameters and in particular the originating and terminating session cases. In basic call scenarios, there is no particular issue for the S-CSCF and AS to know which scenario needs to be realized, but in case ofcall diversionCDIV services for which the session is re-targeted, the session cases defined in [RFC5502] pose some limitations as described in the following section. 1.3. Problem Statement To illustrate the problem statement, let's imagine Alice trying to call Bob and Bob having acall diversionCDIV service activated towards Carol's address. In the case of acall diversionCDIV service, the received request is first treated as a terminating session case (atBobBob's side), and the terminating filter criteria configured in the S-CSCFareis performed. A filter criteria is information in the user profile that determines whether an initial request is sent to a particular AS. When the AS receives the call initiation request, the AS is able to determine the served user (Bob) and the session case (here "term") from the received P-Served-User header field content and is able to execute terminating services. When thecall diversionCDIV service is executed (as a terminating service of Bob), the AS changes the target (Request-URI) of the session (toward Carol's address) and a new call leg is created. The served user becomes the diverting user. This new call leg could be considered as an originating call leg from the diverting user(Bob)(Bob), but this is not the case. Indeed, the originating user remains the same (Alice), and some of the diverting user's originating services should not be triggered as if it was an originating call. For instance, the originating user identity (Alice) should not be restricted because the diverting user (Bob) has a privacy service for his own identity. The privacy of the diverting user should apply to information related to this user only(eg.(e.g., in the History-Info header field). In the same manner, some specific services will need to be triggered on the outgoing leg after acall diversion.CDIV. Without a dedicated session case fororiginating-after- CDIV,originating-after-CDIV, the S-CSCF cannot trigger an originating service for the diverting user, nor can an AS execute the procedures for this particular session case. For this use case, this document creates a new parameter ("orig- cdiv") for the originating-after-CDIV session case to be embedded in the P-Served-User header field. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Applicability The use of the P-Served-User header field extensions is only applicable inside a Trust Domain [RFC3324] for the P-Served-User header field. Nodes in such a Trust Domain explicitly trust each other to convey the served user and to be responsible for withholding that information outside of the Trust Domain. The means by which the network determines the served user and the policies that are executed for a specific served user is outside the scope of this document. 4. ProxybehaviorBehavior andparameter handlingParameter Handling The following section illustrates how this header field parameter can be used in a 3GPP network. For a terminating call, the following steps will be followed: 1. The S-CSCF receives the initial INVITE request for a terminating call and determines that the session case is for a terminating user as described in[RFC5502];[RFC5502]. 2. The S-CSCF determines who is the served user by looking at the Request-URI and saves the currentRequest-URI;Request-URI. 3. The S-CSCF analyzes the filter criteria. It then sends the request to the AS of the served user as an INVITE that includes the P-Served-User header field with the "sescase" parameter set to "term" and the "regstate" set to the corresponding value in order to trigger execution of terminatingservices;services. 4. Based on some criteria, the AS concludes that the request has to be diverted to another target user or application. The AS replaces the received Request-URI with the new diverted-to address andthe ASstores the successive Request-URI(s) values by adding one or two History-Info header field entry(ies) [RFC7044] in the outgoing INVITE. In the History-Info header field, the served user address is tagged by using the mp-param header field parameter added in the newly created entryassociated tothat contains the diverted-toaddress created.address. The AS forwards the INVITE request back to theS-CSCF;S-CSCF. 5. When receiving back the INVITE request, the S-CSCF can see that the topmost Route header field contains its ownhostnamehostname, but the Request-URI does not match the saved Request-URI. In this case, the S-CSCF updates the P-Served-User header field content by replacing the "sescase" parameter with the "orig-cdiv" parameter. The P-Served-User header field value remainsunchanged;unchanged. 6. The S-CSCF forwards the INVITE request to an AS that hosts theoriginating services of theserveduseruser's (divertinguser) thatuser's) originating services, which need to be executed on the forwarded leg after acall diversion service;CDIV service. 7. When the AS receives the INVITE request, it determines that the session case is for the "orig-cdiv" session case and performs the originating services to be executed after retargeting for the diverting user(i.e.(i.e., served user). 5. Clarification ofRFC5502 proceduresRFC 5502 Procedures This document provides the following guidance for the handling of the P-Served-User header field thatareis missing in [RFC5502]: o The P-Served-User header field MUST NOT be repeated within a request for a particular session at a particular time for the reason that session cases are mutually exclusive. This document updates [RFC5502] to clearly state that the P-Served-User header field MUST NOT contain multiple values either comma-separated or header-separated. Thisdocumentsdocument also updates the syntax of the header from [RFC5502] to reflect this uniqueness ofparametersparameter values. o [RFC5502] does not clearly state what to do with the received P- Served-User header field when a call is diverted to another destination. This document highlights that there are several ways of handling the P-Served-User header field: the S-CSCF could store the previous "regstate" value and decide that the same valueapplies; orapplies, the "regstate" may no longer be relevant after a diverting service so the S-CSCF removesit;it, or theregstate"regstate" could be combined with theorig-cdiv"orig-cdiv" session case to provide different services depending on whether the served user is registered or unregistered. These choices are implementation dependent. 6. Syntax 6.1. General [RFC5502] defines the P-Served-User header field with the sessioncase-param parameter"sescase""sescase", which is specified as having "orig" and "term" as predefined values. This document defines an additionalparameterparameter, "orig-cdiv", for thesessioncase-param: "orig-cdiv".sessioncase-param. Because this document extends the existing sessioncase-param parameter, and because errors have been identified in the syntax, this document corrects and extends the P-Served-User header field. The extension of the sessioncase-param parameter to add the "orig- cdiv" session case is done in a wayto fitthat fits the parameter format introduced in Release 11 of the 3GPP [TS.3GPP.24.229] andto maintain amaintains backward compatibility. "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- param" are defined in [RFC3261]. If the "addr-spec" contains a comma, question mark, or semicolon, the "name-addr" form MUST be used. The "name-addr" form requires the use of angle brackets (< and >). 6.2. ABNF TheaugmentedAugmented Backus-Naur Form (ABNF) [RFC5234] syntax of theP- Served-UserP-Served-User header field is described in [RFC5502]. This document updates [RFC5502] to correct the P-Served-User header field ABNF syntax and extend it as the following: P-Served-User = "P-Served-User" HCOLON PServedUser-value *(SEMI served-user-param) served-user-param = sessioncase-param / registration-state-param / generic-param PServedUser-value = name-addr / addr-spec sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv registration-state-param = "regstate" EQUAL ("unreg" / "reg") orig-cdiv = "orig-cdiv" Examples of possible P-Served-User headerfield:fields: P-Served-User: <sip:user@example.com>; orig-cdiv; regstate=reg or P-Served-User: <sip:user@example.com>; orig-cdiv or P-Served-User: <sip:user@example.com>; sescase=term; regstate=unreg This document allows choosing betweenaddr-spec"addr-spec" andname-addr"name-addr" when constructing the header field value. As specified in RFC 8217, the "addr-spec" form MUST NOT be used if its value would contain a comma, semicolon, or question mark [RFC8217]. 7. Call Flow Examples 7.1. Calldiversion caseDiversion Case The following call flow shows a session establishment when Alice calls Bob, who has acall diversionCDIV service that diverts to Carol when Bob is busy. proxy server UA Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol | | | | | | INVITE F1 | | | | |--------------->| INVITE F2 | | | | |--------------->| | | | | INVITE F3 | | | | |<---------------| INVITE F4 | | | |-------------------------------->| | | | 486 F5 | | | |<--------------------------------| | | | 486 F6 | | | | |--------------->| | | | | INVITE F7 | | | | |<---------------| | | | | INVITE F8 | | | | |--------------->| | | | | INVITE F9 | | | | |<---------------| INVITE F10 | | |------------------------------------------------->| | | | | | | | | | 180 F11 | | | | 180 F12 |<---------------| | | 180 F13 |<---------------| | | 180 F14 |<---------------| | | |<---------------| | | | | | | | | [Alice calls Bob] F1 INVITE Alice -> S-CSCF-B INVITE sip:bob@example.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> F2 INVITE S-CSCF-B -> AS-B INVITE sip:bob@example.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> P-Served-User: <sip:bob@example.com>; term; regstate=reg F3 INVITE AS-B -> S-CSCF-B INVITE sip:bob@example.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> P-Served-User: <sip:bob@example.com>; term; regstate=reg F4 INVITE S-CSCF-B -> Bob INVITE sip:bob@192.0.2.4 SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> P-Served-User: <sip:bob@example.com>; term; regstate=reg [Bob is busy. Hiscall diversionCDIV when busy is invoked towards Carol] F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B 486 BUSY From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com>;tag=es43sd [Alice's call is diverted to Carol] F7 INVITE AS-B -> S-CSCF-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> P-Served-User: <sip:bob@example.com>; term; regstate=reg[Forwarded[The forwarded leg to Carol is identified as an originating call afterdiversion thatCDIV, which should not trigger all of Bob's originating services] F8 INVITE S-CSCF-B -> AS-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg F9 INVITE AS-B -> S-CSCF-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg F10 INVITE S-CSCF-B -> Carol INVITE sip:carol@192.0.2.7 SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> Figure1:1. P-Served-Userduring call diversion serviceDuring CDIV Service 7.2. CalldiversionDiversion andprivacyPrivacy The following call flow shows acall diversionCDIV use case for which Alice has no identity restriction service and Bob has an unconditionalcall diversionCDIV service towards Carol and an identity presentation restriction service. proxy server UA Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol | | | | | | INVITE F1 | | | | |--------------->| INVITE F2 | | | | |--------------->| | | | | INVITE F3 | | | | |<---------------| | | | | INVITE F4 | | | | |--------------->| | | | | INVITE F5 | | | | |<---------------| INVITE F6 | | | |------------------------------------------------->| | | | | | | | | | 180 F7 | | | | 180 F8 |<---------------| | | 180 F9 |<---------------| | | 180 F10 |<---------------| | | |<---------------| | | | | | | | | [Alice calls Bob] F1 INVITE Alice -> S-CSCF-B INVITE sip:bob@example.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> Supported: histinfo F2 INVITE S-CSCF-B -> AS-B INVITE sip:bob@example.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Bob <sip:bob@example.com> P-Served-User: <sip:bob@example.com>; term; regstate=reg [Bob's unconditionalcall diversionCDIV to Carol is triggered] F3 INVITE AS-B -> S-CSCF-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Carol <sip:carol@domainc.com> P-Served-User: <sip:bob@example.com>; term; regstate=reg History-Info: <sip:bob@example.com>;index=1, <sip:carol@domainc.com;cause=302>;index=1.1;mp=1 [Alice's call is diverted to Carol] F4 INVITE S-CSCF-B -> AS-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Carol <sip:carol@domainc.com> P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg History-Info: <sip:bob@example.com>;index=1, <sip:carol@domainc.com;cause=302>;index=1.1;mp=1 F5 INVITE AS-B -> S-CSCF-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Carol <sip:carol@domainc.com> P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg History-Info: <sip:bob@example.com?privacy=history>;index=1, <sip:carol@domainc.com;cause=302>;index=1.1;mp=1 [Forwarded leg to Carol is identified as an originating call afterdiversionCDIV that allowsto applyBob's privacyrequestservice to be applied to his identity within theHistroy-InfoHistory-Info header field] F6 INVITE S-CSCF-B -> Carol INVITE sip:carol@192.0.2.7 SIP/2.0 From: Alice <sip:alice@domaina.com>;tag=1928301774 To: Carol <sip:carol@domainc.com> History-Info: <sip:bob@example.com?privacy=history>;index=1, <sip:carol@domainc.com;cause=302>;index=1.1;mp=1 <sip:carol@192.0.2.7>;index=1.1.1;rc=1.1 Figure2:2. P-Served-Userwhen privacy requestedWhen Privacy Requested 8. IANA Considerations The syntax of the P-Served-User header field [RFC5502] is updated in Section 4 of this document.This document requestsIANAto updatehas updated the existing row for theP- Served-UserP-Served-User header field in the "Header Fields"sub-registrysubregistry within the "Session Initiation Protocol (SIP) Parameters" registry: Header Name Compact Form Reference ------------- ---------------------------------------------- P-Served-User none[RFC5502][RFCXXXX] Note to RFC Editor: Please replace XXXX with the RFC number of this document. This document requests[RFC5502][RFC8498] IANAto addhas added new rows for the P-Served-User header field parameters in the "Header Field Parameters and Parameter Values"sub-registrysubregistry within the "Session Initiation Protocol (SIP) Parameters"registry: asregistry (as per the registry created by[RFC3968]:[RFC3968]): Header Field Parameter Name Predefined Values Reference -------------- ---------------- ----------------------------------------------- P-Served-User sescase Yes [RFC5502] P-Served-User regstate Yes [RFC5502] P-Served-User orig-cdiv No[RFCXXXX] Note to RFC Editor: Please replace XXXX with the RFC number of this document.[RFC8498] 9. Security Considerations The security considerations in [RFC5502] apply. As the "orig-cdiv" parameter of the P-Served-User header field can be used to trigger applications when a call isdiverted ,diverted, it is important to ensure that the parameter has not been added to the SIP message by an unauthorized SIP entity. Thus, the P-Served-User header field is to be used in a trustedenvironmentenvironment, and proxies MUST NOT insert the header unless they have sufficient knowledge that the route set includes another trusted proxy.11.10. References11.1.10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, <https://www.rfc-editor.org/info/rfc3324>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8217] Sparks, R., "Clarifications for When to Use the name-addr Production in SIP Messages", RFC 8217, DOI 10.17487/RFC8217, August 2017, <https://www.rfc-editor.org/info/rfc8217>. [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <https://www.rfc-editor.org/info/rfc3968>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, <https://www.rfc-editor.org/info/rfc7044>. [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April 2009, <https://www.rfc-editor.org/info/rfc5502>.11.2.10.2. Informative References [TS.3GPP.24.229] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);Stage 3", 3GPP TS 24.229v11.11.28.0, December 2018. [TS.3GPP.29.228] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", 3GPP TS 29.228v11. 10.15.1.0, September 2018. Acknowledgments The author wishes to thank the 3GPP community for providing guidance, input, and comments on the document. Thanks to Dale Worley, JeanMahoneyMahoney, and Ben Campbell for their careful review of the document. Thanks to Paul Kyzivat and Adam Roach. A special thanks to Christer Holmberg. Author's Address Marianne Mohali Orange Orange Gardens, 44 avenue de la Republique Chatillon 92326 France Email: marianne.mohali@orange.com