Skip to main content

A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)
draft-ietf-sipcore-originating-cdiv-parameter-08

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8498.
Author Marianne Mohali
Last updated 2019-02-14 (Latest revision 2018-12-09)
Replaces draft-mohali-sipcore-originating-cdiv-parameter
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Jean Mahoney
Shepherd write-up Show Last changed 2018-08-29
IESG IESG state Became RFC 8498 (Informational)
Action Holders
(None)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Ben Campbell
Send notices to Jean Mahoney <mahoney@nostrum.com>
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
draft-ietf-sipcore-originating-cdiv-parameter-08
SIPCORE Working Group                                          M. Mohali
Internet-Draft                                                    Orange
Updates: 5502 (if approved)                            December 10, 2018
Intended status: Informational
Expires: June 13, 2019

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

Abstract

   The P-Served-User header field 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 that applies to this
   particular communication session and application invocation.  A
   session case is metadata that captures the status of the session of a
   served user: whether the served user is registered or not, and
   whether the session originates or terminates with the served user.
   This document updates 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 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

   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 June 13, 2019.

Mohali                    Expires June 13, 2019                 [Page 1]
Internet-Draft      P-Served-User parameter orig-cdiv      December 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
   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.  Proxy behavior and parameter handling . . . . . . . . . . . .   5
   5.  Clarification of RFC5502 procedures . . . . . . . . . . . . .   6
   6.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Call Flow Examples  . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Call diversion case . . . . . . . . . . . . . . . . . . .   8
     7.2.  Call diversion and privacy  . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  13

Mohali                    Expires June 13, 2019                 [Page 2]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

     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 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
   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 served
   user: whether the served user is registered or not, and whether the
   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 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 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 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.

Mohali                    Expires June 13, 2019                 [Page 3]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

   At the moment that an S-CSCF is assigned to a specific user, the user
   profile is downloaded from the Home Subscriber Server (HSS) 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 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 of
   call diversion 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 a call diversion service activated towards
   Carol's address.  In the case of a call diversion service, the
   received request is first treated as a terminating session case (at
   Bob side), and the terminating filter criteria configured in the
   S-CSCF are 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 to execute terminating services.  When the call diversion 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) 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. in
   the History-Info header field).  In the same manner, some specific
   services will need to be triggered on the outgoing leg after a call
   diversion.  Without a dedicated session case for originating-after-
   CDIV, the S-CSCF cannot trigger an originating service for the

Mohali                    Expires June 13, 2019                 [Page 4]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

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

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

Mohali                    Expires June 13, 2019                 [Page 5]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

       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 with the "orig-cdiv" parameter.
       The P-Served-User header field value remains unchanged;

   6.  The S-CSCF forwards the INVITE request to an AS that hosts the
       originating services of the served user (diverting user) that
       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 performs the
       originating services to be executed after retargeting for the
       diverting user (i.e. served user).

5.  Clarification of RFC5502 procedures

   This document provides the following guidance for the handling of the
   P-Served-User header field that are 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.  This documents also updates the syntax of the
      header from [RFC5502] to reflect this uniqueness of parameters
      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 value
      applies; or the "regstate" may no longer be relevant after a
      diverting service so the S-CSCF removes it; or the regstate could
      be combined with the orig-cdiv session case to provide different
      services depending on whether the served user is registered or
      unregistered.  These choices are implementation dependent.

Mohali                    Expires June 13, 2019                 [Page 6]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

6.  Syntax

6.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, 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 way to fit the parameter format
   introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and to maintain
   a backward compatibility.

   "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic-
   param" are defined in [RFC3261].

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

Mohali                    Expires June 13, 2019                 [Page 7]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

   This document allows choosing between addr-spec and 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.  Call diversion case

   The following call flow shows a session establishment when Alice
   calls Bob, who has a call diversion 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>

Mohali                    Expires June 13, 2019                 [Page 8]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

   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. His call diversion 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 leg to Carol is identified as an originating call after
diversion that should not trigger all 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

Mohali                    Expires June 13, 2019                 [Page 9]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

   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>

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

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

Mohali                    Expires June 13, 2019                [Page 10]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

        P-Served-User: <sip:bob@example.com>; term; regstate=reg

[Bob's unconditional call diversion 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 after
diversion that allows to apply Bob's privacy request to his identity
within the Histroy-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

            Figure 2: P-Served-User when privacy requested

Mohali                    Expires June 13, 2019                [Page 11]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

8.  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 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 IANA to add new rows for the P-Served-User
   header field parameters in the "Header Field Parameters and Parameter
   Values" sub-registry within the "Session Initiation Protocol (SIP)
   Parameters" registry: as per the registry created by [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.

9.  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 when a call is 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 trusted environment and proxies MUST
   NOT insert the header unless they have sufficient knowledge that the
   route set includes another trusted proxy.

Mohali                    Expires June 13, 2019                [Page 12]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

10.  Acknowledgments

   The author wishes to thank the 3GPP community for providing guidance,
   input, and comments on the document.  Thanks to Dale Worley, Jean
   Mahoney and Ben Campbell for their careful review of the document.
   Thanks to Paul Kyzivat and Adam Roach.  A special thanks to Christer
   Holmberg.

11.  References

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

Mohali                    Expires June 13, 2019                [Page 13]
Internet-Draft      P-Served-User parameter orig-cdiv      December 2018

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

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

   Email: marianne.mohali@orange.com

Mohali                    Expires June 13, 2019                [Page 14]