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

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

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

Abstract

   The P-Served-User header field RFC5502 is used to convey the identity
   of the served user and the session case that applies to this
   particular communication session and application invocation.  This
   document updated RFC5502 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 has been invoked for the served user.  This document
   also fixes the ABNF in RFC5502 and provides more guidance for using
   the P-Served-User header field in IP networks.

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 November 23, 2018.

Copyright Notice

   Copyright (c) 2018 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

Mohali                  Expires November 23, 2018               [Page 1]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

   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.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Proxy behavior and parameter handling . . . . . . . . . . . .   4
   4.  Clarification of RFC5502 procedures . . . . . . . . . . . . .   5
   5.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Call Flow Examples  . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Call diversion case . . . . . . . . . . . . . . . . . . .   8
     7.2.  Call diversion and privacy  . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

1.1.  General

   The P-Served-User header field [RFC5502] was defined based on a
   requirement from 3rd Generation Partnership Project (3GPP) IMS (IP
   Multimedia Subsystem) in order to convey the identity of the served
   user, his/her registration state and the session case 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].

   [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 23, 2018               [Page 2]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

   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 discusses the applicability and
   scope of this new header field parameter, and Section 3 specifies the
   proxy behavior for handling the new header field parameter.
   Section 4 clarifies some of the [RFC5502] procedures, Section 5
   describes the extended syntax and correct the syntax of [RFC5502],
   Section 6 registers the P-Served-User header field parameters with
   IANA, Section 7 gives some examples and Section 8 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 November 23, 2018               [Page 3]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

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 AS 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 AS
   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 History-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 AS 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.  Applicability

   The use of the P-Served-User header field extensions is only
   applicable inside a Trust Domain for 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.

3.  Proxy behavior and parameter 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:

Mohali                  Expires November 23, 2018               [Page 4]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

   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];

   2.  The S-CSCF determines who is the served user by looking at the
       Request-URI and saves the current Request-URI;

   3.  The S-CSCF starts the analysis of filter criteria and triggers
       the served user AS for the terminating services to be executed by
       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;

   4.  Based on some criteria, the AS 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 and
       the AS 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 using the mp-param header field parameter
       added in entry associated to the diverted-to address created.
       The AS forwards the INVITE request back to the S-CSCF;

   5.  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 P-Served-User header field value remains unchanged;

   6.  The S-CSCF forwards 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;

   7.  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
       diverting user (i.e. served user).

4.  Clarification of RFC5502 procedures

   This document provides the following guidance that reminds and
   clarifies the P-Served-User header field handling that are missing in
   [RFC5502]:

   o  This header MUST NOT be repeated within a request for a particular
      session at a particular time for the reason that session cases are

Mohali                  Expires November 23, 2018               [Page 5]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

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

5.  Syntax

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

5.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 November 23, 2018               [Page 6]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

   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 header field:

   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

6.  IANA Considerations

   The syntax of the P-Served-User header field [RFC5502] is 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]:

Mohali                  Expires November 23, 2018               [Page 7]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

  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.

7.  Call Flow Examples

7.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 <sip:alice@domaina.com>;tag=1928301774

Mohali                  Expires November 23, 2018               [Page 8]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

        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

   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

   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

   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>

Mohali                  Expires November 23, 2018               [Page 9]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

             Figure 1: P-Served-User during call diversion service

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

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

   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

Mohali                  Expires November 23, 2018              [Page 10]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

        History-Info:
                <sip:bob@example.com>;index=1,
                <sip:carol@domainc.com;cause=302>;index=1.1;mp=1

   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

   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

            Figure 2: P-Served-User when privacy requested

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

9.  Acknowledgments

   The author wishes to thank the 3GPP community for providing guidance,
   input, and comments on the document.  Thanks to Dale Worley for his

Mohali                  Expires November 23, 2018              [Page 11]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

   careful review of the document and to Paul Kyzivat.  A special thanks
   to Christer Holmberg.

10.  References

10.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,
              <https://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,
              <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>.

10.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, <https://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.

   [TS.3GPP.29.228]
              3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces;
              Signalling flows and message contents", 3GPP TS 29.228
              v11.

Mohali                  Expires November 23, 2018              [Page 12]
Internet-Draft      P-Served-User parameter orig-cdiv           May 2018

Author's Address

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

   Email: marianne.mohali@orange.com

Mohali                  Expires November 23, 2018              [Page 13]