draft-ietf-sipcore-originating-cdiv-parameter-04.txt   draft-ietf-sipcore-originating-cdiv-parameter-05.txt 
SIPCORE Working Group M. Mohali SIPCORE Working Group M. Mohali
Internet-Draft Orange Internet-Draft Orange
Updates: 5502 (if approved) September 24, 2018 Updates: 5502 (if approved) October 11, 2018
Intended status: Informational Intended status: Informational
Expires: March 28, 2019 Expires: April 14, 2019
A P-Served-User Header Field Parameter for Originating CDIV session case A P-Served-User Header Field Parameter for Originating CDIV session case
in Session Initiation Protocol (SIP) in Session Initiation Protocol (SIP)
draft-ietf-sipcore-originating-cdiv-parameter-04 draft-ietf-sipcore-originating-cdiv-parameter-05
Abstract Abstract
The P-Served-User header field is used to convey the identity of the The P-Served-User header field is used to convey the identity of the
served user and the session case that applies to this particular served user and the session case that applies to this particular
communication session and application invocation. This document communication session and application invocation. This document
updates RFC5502 by defining a new P-Served-User header field updates RFC5502 by defining a new P-Served-User header field
parameter, "orig-cdiv". The parameter conveys the session case used parameter, "orig-cdiv". The parameter conveys the session case used
by a proxy when handling an originating session after Call Diversion by a proxy when handling an originating session after Call Diversion
(CDIV) services have been invoked for the served user. This document (CDIV) services have been invoked for the served user. This document
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 28, 2019. This Internet-Draft will expire on April 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
1. Introduction 1. Introduction
1.1. General 1.1. General
The P-Served-User header field [RFC5502] was defined based on a The P-Served-User header field [RFC5502] was defined based on a
requirement from 3rd Generation Partnership Project (3GPP) IMS (IP requirement from 3rd Generation Partnership Project (3GPP) IMS (IP
Multimedia Subsystem) in order to convey the identity of the served Multimedia Subsystem) in order to convey the identity of the served
user, his/her registration state and the session case between an user, his/her registration state and the session case between an
Serving Call Session Control Function (S-CSCF) and an Application Serving Call Session Control Function (S-CSCF) and an Application
Server (AS) on the IMS Service Control (ISC) interface. A session Server (AS) on the IMS Service Control (ISC) interface. A session
case is an information indicating the status of the session in which case is metadata that captures the status of the session of a served
the served user is involved (originating, terminating..). For more 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 information on session cases and the IMS, a detailed description can
be found in [TS.3GPP.24.229]. be found in [TS.3GPP.24.229].
[RFC5502] defines the originating and terminating session cases for a [RFC5502] defines the originating and terminating session cases for a
registered or unregistered user. This document extends the P-Served- registered or unregistered user. This document extends the P-Served-
User header field to include the session case for a forwarded leg User header field to include the session case for a forwarded leg
when a call diversion service (CDIV) has been invoked and if an when a call diversion service (CDIV) has been invoked and if an
originating service of the diverting user has to be triggered. originating service of the diverting user has to be triggered.
The sessioncase-param parameter of the P-Served-User header field is The sessioncase-param parameter of the P-Served-User header field is
skipping to change at page 4, line 23 skipping to change at page 4, line 24
and AS to know which scenario needs to be realized, but in case of 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 call diversion services for which the session is re-targeted, the
session cases defined in [RFC5502] pose some limitations as described session cases defined in [RFC5502] pose some limitations as described
in the following section. in the following section.
1.3. Problem Statement 1.3. Problem Statement
In the case of a call diversion service, the received request is In the case of a call diversion service, the received request is
first treated as a terminating session case, and the terminating first treated as a terminating session case, and the terminating
filter criteria configured in the S-CSCF are performed. A filter filter criteria configured in the S-CSCF are performed. A filter
criteria is a user profile information that determines whether a criteria is information in the user profile that determines whether
particular initial request needs to be sent to a particular AS. When an initial request is sent to a particular AS. When the AS receives
the AS receives the call initiation request, the AS is able to the call initiation request, the AS is able to determine the served
determine the served user and the session case (here "term") from the user and the session case (here "term") from the received P-Served-
received P-Served-User header field content and to execute User header field content and to execute terminating services. When
terminating services. When the call diversion service is executed the call diversion service is executed (as a terminating service),
(as a terminating service), the AS changes the target (Request-URI) the AS changes the target (Request-URI) of the session and a new call
of the session and a new call leg is created. This new call leg leg is created. This new call leg could be considered as an
could be considered as an originating call leg from the diverting originating call leg from the diverting user but this is not the
user but this is not the case. Indeed, the originating user remains case. Indeed, the originating user remains the same, and some of the
the same, and some of the diverting user's originating services diverting user's originating services should not be triggered as if
should not be triggered as if it was an originating call. For it was an originating call. For instance, the originating user
instance, the originating user identity should not be restricted identity should not be restricted because the diverting user has a
because the diverting user has a privacy service for his/her own privacy service for his/her own identity. The privacy of the
identity. The privacy of the diverting user should apply to diverting user should apply to information related to this user (eg.
information related to this user (eg. in the History-Info header in the History-Info header field). In the same manner, some specific
field). In the same manner, some specific services will need to be services will need to be triggered on the outgoing leg after a call
triggered on the outgoing leg after a call diversion. Without a diversion. Without a dedicated session case for originating after
dedicated session case for originating after CDIV, the S-CSCF cannot CDIV, the S-CSCF cannot trigger an originating service for the
trigger an originating service for the diverting user, nor can an AS diverting user, nor can an AS execute the procedures for this
execute the procedures for this particular session case. particular session case.
For this use case, this document creates a new parameter for the For this use case, this document creates a new parameter for the
originating after CDIV session case to be embedded in the P-Served- originating after CDIV session case to be embedded in the P-Served-
User header field. User header field.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 6, line 36 skipping to change at page 6, line 36
o The P-Served-User header field MUST NOT be repeated within a o The P-Served-User header field MUST NOT be repeated within a
request for a particular session at a particular time for the request for a particular session at a particular time for the
reason that session cases are mutually exclusive. This document reason that session cases are mutually exclusive. This document
updates [RFC5502] to clearly state that the P-Served-User header updates [RFC5502] to clearly state that the P-Served-User header
field MUST NOT contain multiple values either comma-separated or field MUST NOT contain multiple values either comma-separated or
header-separated. This documents also updates the syntax of the header-separated. This documents also updates the syntax of the
header from [RFC5502] to reflect this uniqueness of parameters header from [RFC5502] to reflect this uniqueness of parameters
values. values.
o In [RFC5502], except for security reasons, it is not to clearly o [RFC5502] does not clearly state what to do with the received P-
stated what to do with the received P-Served-User header field Served-User header field when a call is diverted to another
when a call is diverted to another destination. This document destination. This document highlights that there are several ways
dealing with this specific use case, highlights that several of handling the P-Served-User header field: the S-CSCF could store
possibilities exist: the S-CSCF could store the previous the previous "regstate" value and decide that the same value
"regstate" value and decide that the same value applies, or the applies; or the "regstate" may no longer be relevant after a
"regstate" may not be relevant after a diverting service and diverting service so the S-CSCF removes it; or the regstate could
removed, or the regstate could be combined with the orig-cdiv be combined with the orig-cdiv session case to provide different
session case to provide different services if the served user is services depending on whether the served user is registered or
registered or unregistered. These choices are implementation unregistered. These choices are implementation dependent.
dependent.
6. Syntax 6. Syntax
6.1. General 6.1. General
[RFC5502] defines the P-Served-User header field with the [RFC5502] defines the P-Served-User header field with the
sessioncase-param parameter "sescase" which is specified as having sessioncase-param parameter "sescase" which is specified as having
"orig" and "term" predefined values. This document defines an "orig" and "term" predefined values. This document defines an
additional parameter for the sessioncase-param: "orig-cdiv". additional parameter for the sessioncase-param: "orig-cdiv".
Because this document extends the existing sessioncase-param Because this document extends the existing sessioncase-param
 End of changes. 7 change blocks. 
38 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/