[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mohali-sipcore-originating-cdiv-parameter) 00 01 02 03 04 05 06 07 08

SIPCORE Working Group                                          M. Mohali
Internet-Draft                                                    Orange
Updates: 5502 (if approved)                                 May 15, 2017
Intended status: Informational
Expires: November 16, 2017


A P-Served-User Header Field Parameter for Originating CDIV session case
                  in Session Initiation Protocol (SIP)
            draft-ietf-sipcore-originating-cdiv-parameter-00

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 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 November 16, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Mohali                  Expires November 16, 2017               [Page 1]


Internet-Draft      P-Served-User parameter orig-cdiv           May 2017


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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 . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

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, his/her
   registration state 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 and if an
   originating service of the diverting user has to be triggered.



Mohali                  Expires November 16, 2017               [Page 2]


Internet-Draft      P-Served-User parameter orig-cdiv           May 2017


   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.  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 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 have to perform and on which user's behalf, it is
   necessary to know 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 the 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



Mohali                  Expires November 16, 2017               [Page 3]


Internet-Draft      P-Served-User parameter orig-cdiv           May 2017


   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.

   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




Mohali                  Expires November 16, 2017               [Page 4]


Internet-Draft      P-Served-User parameter orig-cdiv           May 2017


   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
      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.







Mohali                  Expires November 16, 2017               [Page 5]


Internet-Draft      P-Served-User parameter orig-cdiv           May 2017


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:

 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:









Mohali                  Expires November 16, 2017               [Page 6]


Internet-Draft      P-Served-User parameter orig-cdiv           May 2017


   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


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.


6.  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.








Mohali                  Expires November 16, 2017               [Page 7]


Internet-Draft      P-Served-User parameter orig-cdiv           May 2017


7.  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.

8.  References

8.1.  Normative References

   [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,
              <http://www.rfc-editor.org/info/rfc3261>.

   [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,
              <http://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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc7044>.

8.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, <http://www.rfc-editor.org/info/rfc5502>.

   [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.







Mohali                  Expires November 16, 2017               [Page 8]


Internet-Draft      P-Served-User parameter orig-cdiv           May 2017


   [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

   Marianne Mohali
   Orange
   Orange Gardens, 44 avenue de la Republique
   Chatillon  92326
   France

   Email: marianne.mohali@orange.com





































Mohali                  Expires November 16, 2017               [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/