draft-ietf-sipcore-originating-cdiv-parameter-07.txt   draft-ietf-sipcore-originating-cdiv-parameter-08.txt 
SIPCORE Working Group M. Mohali SIPCORE Working Group M. Mohali
Internet-Draft Orange Internet-Draft Orange
Updates: 5502 (if approved) November 05, 2018 Updates: 5502 (if approved) December 10, 2018
Intended status: Informational Intended status: Informational
Expires: May 9, 2019 Expires: June 13, 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-07 draft-ietf-sipcore-originating-cdiv-parameter-08
Abstract Abstract
The P-Served-User header field is used to convey the identity of the The P-Served-User header field was defined based on a requirement
served user and the session case that applies to this particular from 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia
communication session and application invocation. This document Subsystem) in order to convey the identity of the served user, his/
updates RFC5502 by defining a new P-Served-User header field her registration state and the session case that applies to this
parameter, "orig-cdiv". The parameter conveys the session case used particular communication session and application invocation. A
by a proxy when handling an originating session after Call Diversion session case is metadata that captures the status of the session of a
(CDIV) services have been invoked for the served user. This document served user: whether the served user is registered or not, and
also fixes the ABNF in RFC 5502 and provides more guidance for using whether the session originates or terminates with the served user.
the P-Served-User header field in IP networks. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 9, 2019. This Internet-Draft will expire on June 13, 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 2, line 25 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Proxy behavior and parameter handling . . . . . . . . . . . . 5 4. Proxy behavior and parameter handling . . . . . . . . . . . . 5
5. Clarification of RFC5502 procedures . . . . . . . . . . . . . 6 5. Clarification of RFC5502 procedures . . . . . . . . . . . . . 6
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 25 skipping to change at page 3, line 30
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
extended with the "orig-cdiv" parameter for this "originating after extended with the "orig-cdiv" parameter for this "originating-after-
CDIV" session case. CDIV" session case.
The following section defines usage of the "orig-cdiv" parameter of The following section defines usage of the "orig-cdiv" parameter of
P-Served-User header field, Section 3 discusses the applicability and P-Served-User header field, Section 3 discusses the applicability and
scope of this new header field parameter, and Section 4 specifies the scope of this new header field parameter, and Section 4 specifies the
proxy behavior for handling the new header field parameter. proxy behavior for handling the new header field parameter.
Section 5 clarifies some of the [RFC5502] procedures, Section 6 Section 5 clarifies some of the [RFC5502] procedures, Section 6
describes the extended syntax and corrects the syntax of [RFC5502], describes the extended syntax and corrects the syntax of [RFC5502],
Section 8 registers the P-Served-User header field parameters with Section 8 registers the P-Served-User header field parameters with
IANA, Section 7 gives some examples, and Section 9 discusses the IANA, Section 7 gives some examples, and Section 9 discusses the
skipping to change at page 4, line 45 skipping to change at page 4, line 50
This new call leg could be considered as an originating call leg from 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 the diverting user (Bob) but this is not the case. Indeed, the
originating user remains the same (Alice), and some of the diverting originating user remains the same (Alice), and some of the diverting
user's originating services should not be triggered as if it was an user's originating services should not be triggered as if it was an
originating call. For instance, the originating user identity originating call. For instance, the originating user identity
(Alice) should not be restricted because the diverting user (Bob) has (Alice) should not be restricted because the diverting user (Bob) has
a privacy service for his own identity. The privacy of the diverting a privacy service for his own identity. The privacy of the diverting
user should apply to information related to this user only (eg. in user should apply to information related to this user only (eg. in
the History-Info header field). In the same manner, some specific the History-Info header field). In the same manner, some specific
services will need to be triggered on the outgoing leg after a call services will need to be triggered on the outgoing leg after a call
diversion. Without a dedicated session case for originating after diversion. Without a dedicated session case for originating-after-
CDIV, the S-CSCF cannot trigger an originating service for the CDIV, the S-CSCF cannot trigger an originating service for the
diverting user, nor can an AS execute the procedures for this diverting user, nor can an AS execute the procedures for this
particular session case. particular session case.
For this use case, this document creates a new parameter ("orig- For this use case, this document creates a new parameter ("orig-
cdiv") for the originating after CDIV session case to be embedded in cdiv") for the originating-after-CDIV session case to be embedded in
the P-Served-User header field. the P-Served-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
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
 End of changes. 9 change blocks. 
17 lines changed or deleted 22 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/