Network Working Group M. Mohali Internet-Draft Orange Updates: 5502 (if approved) April 12, 2016 Intended status: Informational Expires: October 14, 2016 P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP) draft-mohali-dispatch-originating-cdiv-parameter-01 Abstract This specification defines a new Session Initiation Protocol (SIP) P- Served-User header field parameter, "orig-cdiv-param", which 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]. The P-Served-User header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. This document updates [RFC5502] in order to add the originating after CDIV session case. 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 http://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 October 14, 2016. Copyright Notice Copyright (c) 2016 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 Mohali Expires October 14, 2016 [Page 1]
Internet-Draft orig-cdiv session case April 2016 (http://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. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proxy behavior and parameter handling . . . . . . . . . . . . 4 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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]. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. [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. The generic-param of the P-Served-User is extended by the "orig-cdiv- param" created as a new parameter for this Originating_CDIV session case. Mohali Expires October 14, 2016 [Page 2]
Internet-Draft orig-cdiv session case April 2016 The following section defines the orig-cdiv-param P-Served-User header field parameter usage, Section 2 specifies the proxy behavior for the new header field parameter handling, and Section 3 discusses the applicability and scope of this new header field parameter. Section 4 descibes the Syntax, Section 5 registers the orig-cdiv header field parameter with the IANA, and Section 6 discusses the security properties of the environment where this new header field parameter is intended to be used. 1.2. 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, a user profile is downloaded to the S-CSCF from the HSS (Home Subscriber Server), see [TS.3GPP.29.228]. To be able to determine which responsibilities the S-CSCF and the Application Server haves to perform and on which user's behalf, it is necessary to know in which situation is the session and who is the current served user.[RFC5502] defines the originating and terminating session cases. In the case of a call diversion service, the received request is first considered as a terminating session case and the terminating iFC 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, 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 but this is not the case. Indeed, the originating user remains the same and the diverting user's originating services do not have to be triggered as if it was an originating call. For instance, the originating user identity should not be hidden because the diverting user has a privacy service for his/her own identity. In the same manner, some specific services may be triggered when performing a call diversion that would not be for a normal originating call. For this particular use case, this document created a new parameter to be embedded in the P-Served-User header field. Mohali Expires October 14, 2016 [Page 3]
Internet-Draft orig-cdiv session case April 2016 2. Proxy behavior and parameter handling The orig-cdiv-param header filed parameter can be used inside a trust domain 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 determines 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. Then, the S-CSCF starts the iFC processing and triggers the served user Application Server for the terminating services to be executed. Based on some criteria, the diversion service concludes that the request needs to be diverted to another user or application and the received Request-URI is replaced with the new diverted-to address. The Application Server stores the Request-URI(s) by adding one or two new History-Info header field entry(ies) [RFC7044]. The served user address is tagged thanks to the mp-param header field parameter added in the History-Info entry associated to the diverted-to address created. Then the AS forwards the INVITE request back to the S-CSCF. When the S-CSCF receives the INVITE, it can see that the topmost Route header contains its own hostname but the Request-URI does not match the saved Request-URI. In that case, the S-CSCF updates the P- Served-User header field content by removing both "sescase" and "regstate" header field parameters and inserting the "orig-cdiv" header field parameter. Then the procedure would continue forwarding the INVITE request over to an AS that hosts the originating services of the served user that specifically need to be executed on the forwarded leg after a call diversion service. When the AS 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 served user. 3. Applicability The use of the P-Served-User header field extensions is only applicable inside a Trust Domain for 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 Mohali Expires October 14, 2016 [Page 4]
Internet-Draft orig-cdiv session case April 2016 user and the policies that are executed for a specific served user is outside the scope of this document. 4. Syntax 4.1. General The orig-cdiv-param parameter is defined as an instance of generic- param from the current served-user-param component of P-Served-User header field. Following is a reminder of the P-Served-User syntax: 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" registration-state-param = "regstate" EQUAL "unreg" / "reg" EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are defined in [RFC3261]. 4.2. ABNF The augmented Backus-Naur Form (BNF) [RFC5234] syntax of the P- Served-User header field is described in [RFC5502]. The P-Served-User header syntax is extended as follows: served-user-param =/ orig-cdiv-param orig-cdiv-param = "orig-cdiv" The following is an example of a P-Served-User header field: P-Served-User: <sip:user@example.com>; orig-cdiv; regstate=reg 5. IANA Considerations This specification defines a new P-Served-User header field parameter called orig-cdiv-param in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by [RFC3968]. The syntax is defined in Section 4. Mohali Expires October 14, 2016 [Page 5]
Internet-Draft orig-cdiv session case April 2016 The required information is: Header Name References -------------- ----------------- P-Served-User [RFC5502][RFCxxxx] Note to RFC Editor: Please replace RFC XXXX with the RFC number of this specification. 6. Security Considerations The security considerations in [RFC5502] apply. As the orig-cdiv-param P-Served-User header field parameter 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. 7. Acknowledgments TBD 8. References 8.1. Normative References [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3968] "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", RFC 3968, December 2004. [RFC5234] "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [RFC7044] "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, February 2014. 8.2. Informative References [RFC5502] "The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem", RFC 5502, April 2009. Mohali Expires October 14, 2016 [Page 6]
Internet-Draft orig-cdiv session case April 2016 [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 x.x.x. [TS.3GPP.29.228] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", 3GPP TS 29.228 x.x.x. Author's Address Marianne Mohali Orange Orange Gardens, 44 avenue de la Republique Chatillon 92326 France Email: marianne.mohali@orange.com Mohali Expires October 14, 2016 [Page 7]