SIPCORE Working Group M. Mohali Internet-Draft Orange Updates: 5502 (if approved) September 27, 2017 Intended status: Informational Expires: March 31, 2018 A P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP) draft-ietf-sipcore-originating-cdiv-parameter-01 Abstract This specification defines a new parameter of the P-Served-User header field in the Session Initiation Protocol (SIP). This new "orig-cdiv" parameter defines the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services has been invoked for the served user. The P-Served-User header field is defined in RFC5502 to convey the identity of the served user and the session case that applies to this particular communication session and application invocation. This document updates RFC5502 to add the "originating after CDIV" session case and to provide more guidance for using the P-Served-User header field in IP networks that were missing in RFC5502. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 March 31, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Mohali Expires March 31, 2018 [Page 1] Internet-Draft P-Served-User parameter orig-cdiv September 2017 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 2. Proxy behavior and parameter handling . . . . . . . . . . . . 4 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 6.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 6.2. Call diversion and privacy . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 1.1. General The P-Served-User header field was defined in [RFC5502] to address an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface. For more information on the IMS, a detailed description can be found in [TS.3GPP.24.229]. The P-Served-User header field conveys the identity of the served user, his/her registration state and the session case that applies to this particular communication session and application invocation. Mohali Expires March 31, 2018 [Page 2] Internet-Draft P-Served-User parameter orig-cdiv September 2017 [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 a call diversion service (CDIV) has been invoked and if an 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" session case. The following section defines usage of the "orig-cdiv" parameter of P-Served-User header field, Section 2 specifies the proxy behavior for handling the new header field parameter, and Section 3 discusses the applicability and scope of this new header field parameter. Section 4 describes the syntax and correct the syntax of [RFC5502], Section 5 registers the P-Served-User header field parameters with IANA, and Section 6 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 allocated 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 allocated to that user. At the moment that an S-CSCF is allocated for a specific user, the user profile is downloaded from the HSS (Home Subscriber Server) to this 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 apply the corresponding actions such as forward the request to an AS. At its turn, the AS has to go through a similar process of determining who is the current served user, what is his/her "registration state" and on which "session case" is the session. [RFC5502] defines all those parameters and in particular the originating and terminating session cases. In basic call scenarios, the is no particular issue for the S-CSCF and AS to know which scenario needs to be realized but in case of call diversion services for which the session is re-targeted, the session cases defined in [RFC5502] poses some limitations as described in the following section. Mohali Expires March 31, 2018 [Page 3] Internet-Draft P-Served-User parameter orig-cdiv September 2017 1.3. Problem Statement In case of a call diversion service, the received request is first considered as a terminating session case and the terminating filter criteria configured in the S-CSCF are performed. Receiving the call initiation request, the Application Server is able to determine the served user and the session case (here "term") from the received P- Served-User header field content and to execute terminating services. When the call diversion service is executed (as a terminating service), the Application Server changes the target (Request-URI) of the session and a new call leg is created. This new call leg could be considered as an originating call leg from the diverting user but this is not the case. Indeed, the originating user remains the same 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 should not be restricted because the diverting user has a privacy service for his/her own identity. The privacy of the diverting user should apply to information related to this user (eg. in the Histroy-Info header field). In the same manner, some specific services will need to be specifically triggered on the outgoing leg after a call diversion. Without a dedicated session case for originating after CDIV, there is no possiblity for a proxy to trigger an originating service for the diverting user or for an Application Server to execute the procedures for this particular session case. For this use case, this document creates a new parameter for the originating after CDIV session case to be embedded in the P-Served- User header field. 2. Proxy behavior and parameter handling The "orig-cdiv" header field parameter can be used inside a trust domain of the P-Served-User header field by proxies that are processing call diversion services. The following section illustrates how this header field parameter can be used in a 3GPP network. For a terminating call, when receiving the initial INVITE request, the S-CSCF will determine that the session case is for a terminating user as described in [RFC5502], then it determines the served user by looking at the Request-URI and saves this Request-URI. After that, the S-CSCF starts the analysis of filter criteria and triggers the served user Application Server for the terminating services to be executed including in the INVITE request the P-Served-User header field with the "sescase" parameter set to "term" and the regstate to the corresponding value. Mohali Expires March 31, 2018 [Page 4] Internet-Draft P-Served-User parameter orig-cdiv September 2017 Based on some criteria, the Application Server concludes that the request has to be diverted to another target user or application. The received Request-URI is then replaced with the new diverted-to address. The Application Server stores 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 thanks to the mp-param header field parameter added in entry associated to the diverted-to address created. In the next step, the Application Server forwards the INVITE request back to the S-CSCF. When receiving back the INVITE request, the S-CSCF can see that the topmost Route header field contains its own hostname 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 by the "orig-cdiv" parameter. The PServedUser-value remains unchanged. Then the procedure continues by forwarding the INVITE request over to an AS that hosts the originating services of the served user (diverting user) that specifically need to be executed on the forwarded leg after a call diversion service. When the Application Server receives the INVITE request, it determines that the session case is for "orig-cdiv" session case and will perform the originating services to be executed after retargeting for the diverting user (i.e. served user). This document also provides the following guidance that reminds or clarifies the P-Served-User handling that are missing in [RFC5502]: o This header is forbidden to 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 P-Served-User header field MUST not contain different values either comma-separated or header- separated. This documents also updates the syntax of the header as defined in [RFC5502] to reflect this uniqueness of parameters values. o Whether the "regstate" parameter is removed or not by the S-CSCF when processing the orginating after CDIV session case is out of the scope of this document. In one hand, it can either be considered that the S-CSCF is able to store the previous regstate value and that the same value applies or that the "regstate" is not relevant after a diverting service. On the other hand, the regstate can be combined to the orig-cdiv session case to provide Mohali Expires March 31, 2018 [Page 5] Internet-Draft P-Served-User parameter orig-cdiv September 2017 different services if the served user is registered or unregistered. These choices are implementation dependent. 3. Applicability The use of the P-Served-User header field extensions is only applicable inside a Trust Domain for P-Served-User. 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. Syntax 4.1. General [RFC5502] defines the P-Served-User header field with the sessioncase-param parameter "sescase" which is specified as having "orig" and "term" predefined values. This document defines an additional parameter for the sessioncase-param: "orig-cdiv". Because this document extends the existing sessioncase-param parameter in a special way and that it has been identified errors in the syntax of the P-Served-User header field as defined in [RFC5502], this document corrects and extends the header at the same time. The extension of the sessioncase-param parameter to add the "orig- cdiv" session case is done in a way to fit the parameter format introduced in release 11 of the 3GPP [TS.3GPP.24.229] and keep a backward compatibility. "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- param" are defined in [RFC3261]. 4.2. ABNF The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P- 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 following: Mohali Expires March 31, 2018 [Page 6] Internet-Draft P-Served-User parameter orig-cdiv September 2017 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 = 1("sescase" EQUAL 1("orig" / "term")/ orig-cdiv) registration-state-param = "regstate" EQUAL 1("unreg" / "reg") orig-cdiv = "orig-cdiv" Examples of possible P-Served-User header field: P-Served-User: ; orig-cdiv; regstate=reg or P-Served-User: ; orig-cdiv or P-Served-User: ; sescase=term; regstate=unreg 5. IANA Considerations The syntax of the P-Served-User header field is defined in [RFC5502] and updated in Section 4 of this document. This document requests IANA to update the existing row for the P- Served-User header field in the "Header Fields" sub-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 IANA to add new rows for the P-Served-User header field parameters in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by [RFC3968]: Header Field Parameter Name Predefined Values Reference -------------- ---------------- ----------------- ----------------- P-Served-User sescase Yes [RFC5502][RFCXXXX] P-Served-User regstate Yes [RFC5502][RFCXXXX] P-Served-User orig-cdiv No [RFCXXXX] Note to RFC Editor: Please replace XXXX with the RFC number of this document. Mohali Expires March 31, 2018 [Page 7] Internet-Draft P-Served-User parameter orig-cdiv September 2017 6. Call Flow Examples 6.1. Call diversion case The following call flow shows a session establishement for Alice calls Bob which has a call diversion when busy towards Carol. 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 |<---------------| | | |<---------------| | | | | | | | | F1 INVITE Alice -> S-CSCF-B INVITE sip:bob@example.com SIP/2.0 From: Alice ;tag=1928301774 To: Bob F2 INVITE S-CSCF-B -> AS-B INVITE sip:bob@example.com SIP/2.0 From: Alice ;tag=1928301774 To: Bob P-Served-User: ; term; regstate=reg F3 INVITE AS-B -> S-CSCF-B INVITE sip:bob@example.com SIP/2.0 Mohali Expires March 31, 2018 [Page 8] Internet-Draft P-Served-User parameter orig-cdiv September 2017 From: Alice ;tag=1928301774 To: Bob P-Served-User: ; term; regstate=reg F4 INVITE S-CSCF-B -> Bob INVITE sip:bob@192.0.2.4 SIP/2.0 From: Alice ;tag=1928301774 To: Bob P-Served-User: ; term; regstate=reg F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B 486 BUSY From: Alice ;tag=1928301774 To: Bob ;tag=es43sd F7 INVITE AS-B -> S-CSCF-B INVITE sip:Carol@domainc.com SIP/2.0 From: Alice ;tag=1928301774 To: Bob P-Served-User: ; term; regstate=reg F8 INVITE S-CSCF-B -> AS-B INVITE sip:Carol@domainc.com SIP/2.0 From: Alice ;tag=1928301774 To: Bob P-Served-User: ; orig-cdiv; regstate=reg F9 INVITE AS-B -> S-CSCF-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice ;tag=1928301774 To: Bob P-Served-User: ; orig-cdiv; regstate=reg F10 INVITE S-CSCF-B -> Carol INVITE sip:carol@192.0.2.7 SIP/2.0 From: Alice ;tag=1928301774 To: Bob Figure 1: P-Served-User during call diversion service 6.2. Call diversion and privacy The following call flow shows a call diversion use case for which Alice has no identity restriction service and Bob has an unconditional call diversion service towards Carol and an identity presentation restriction service. Mohali Expires March 31, 2018 [Page 9] Internet-Draft P-Served-User parameter orig-cdiv September 2017 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 |<---------------| | | |<---------------| | | | | | | | | F1 INVITE Alice -> S-CSCF-B INVITE sip:bob@example.com SIP/2.0 From: Alice ;tag=1928301774 To: Bob Supported: histinfo F2 INVITE S-CSCF-B -> AS-B INVITE sip:bob@example.com SIP/2.0 From: Alice ;tag=1928301774 To: Bob P-Served-User: ; term; regstate=reg F3 INVITE AS-B -> S-CSCF-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice ;tag=1928301774 To: Carol P-Served-User: ; term; regstate=reg History-Info: ;index=1, ;index=1.1;mp=1 F4 INVITE S-CSCF-B -> AS-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice ;tag=1928301774 To: Carol P-Served-User: ; orig-cdiv; regstate=reg History-Info: Mohali Expires March 31, 2018 [Page 10] Internet-Draft P-Served-User parameter orig-cdiv September 2017 ;index=1, ;index=1.1;mp=1 F5 INVITE AS-B -> S-CSCF-B INVITE sip:carol@domainc.com SIP/2.0 From: Alice ;tag=1928301774 To: Carol P-Served-User: ; orig-cdiv; regstate=reg History-Info: ;index=1, ;index=1.1;mp=1 F6 INVITE S-CSCF-B -> Carol INVITE sip:carol@192.0.2.7 SIP/2.0 From: Alice ;tag=1928301774 To: Carol History-Info: ;index=1, ;index=1.1;mp=1 ;index=1.1.1;rc=1.1 Figure 2: P-Served-User when privacy requested 7. Security Considerations The security considerations in [RFC5502] apply. As the "orig-cdiv" parameter of P-Served-User header field can be used to trigger applications, it is important to ensure that the parameter has not been added to the SIP message by an unauthorized SIP entity. 8. Acknowledgments The author wishes to thank the 3GPP community for providing guidance, input, and comments on the document. Thanks also to Dale Worley for his careful review of the document. A special thanks to Christer Holmberg. 9. References 9.1. Normative References Mohali Expires March 31, 2018 [Page 11] Internet-Draft P-Served-User parameter orig-cdiv September 2017 [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, . [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, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [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, . 9.2. Informative References [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, . [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.229 v11. [TS.3GPP.29.228] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", 3GPP TS 29.228 v11. Author's Address Mohali Expires March 31, 2018 [Page 12] Internet-Draft P-Served-User parameter orig-cdiv September 2017 Marianne Mohali Orange Orange Gardens, 44 avenue de la Republique Chatillon 92326 France Email: marianne.mohali@orange.com Mohali Expires March 31, 2018 [Page 13]