draft-ietf-sipcore-originating-cdiv-parameter-05.txt   draft-ietf-sipcore-originating-cdiv-parameter-06.txt 
SIPCORE Working Group M. Mohali SIPCORE Working Group M. Mohali
Internet-Draft Orange Internet-Draft Orange
Updates: 5502 (if approved) October 11, 2018 Updates: 5502 (if approved) November 05, 2018
Intended status: Informational Intended status: Informational
Expires: April 14, 2019 Expires: May 9, 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-05 draft-ietf-sipcore-originating-cdiv-parameter-06
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 April 14, 2019. This Internet-Draft will expire on May 9, 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 33 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8
7.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 7.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8
7.2. Call diversion and privacy . . . . . . . . . . . . . . . 10 7.2. Call diversion and privacy . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
skipping to change at page 4, line 21 skipping to change at page 4, line 21
particular the originating and terminating session cases. particular the originating and terminating session cases.
In basic call scenarios, there is no particular issue for the S-CSCF 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 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 To illustrate the problem statement, let's imagine Alice trying to
first treated as a terminating session case, and the terminating call Bob and Bob having a call diversion service activated towards
filter criteria configured in the S-CSCF are performed. A filter Carol's address. In the case of a call diversion service, the
criteria is information in the user profile that determines whether received request is first treated as a terminating session case (at
an initial request is sent to a particular AS. When the AS receives Bob side), and the terminating filter criteria configured in the
the call initiation request, the AS is able to determine the served S-CSCF are performed. A filter criteria is information in the user
user and the session case (here "term") from the received P-Served- profile that determines whether an initial request is sent to a
User header field content and to execute terminating services. When particular AS. When the AS receives the call initiation request, the
the call diversion service is executed (as a terminating service), AS is able to determine the served user (Bob) and the session case
the AS changes the target (Request-URI) of the session and a new call (here "term") from the received P-Served-User header field content
leg is created. This new call leg could be considered as an and to execute terminating services. When the call diversion service
originating call leg from the diverting user but this is not the is executed (as a terminating service of Bob), the AS changes the
case. Indeed, the originating user remains the same, and some of the target (Request-URI) of the session (toward Carol's address) and a
diverting user's originating services should not be triggered as if new call leg is created. The served user becomes the diverting user.
it was an originating call. For instance, the originating user This new call leg could be considered as an originating call leg from
identity should not be restricted because the diverting user has a the diverting user (Bob) but this is not the case. Indeed, the
privacy service for his/her own identity. The privacy of the originating user remains the same (Alice), and some of the diverting
diverting user should apply to information related to this user (eg. user's originating services should not be triggered as if it was an
in the History-Info header field). In the same manner, some specific 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 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 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.
skipping to change at page 5, line 38 skipping to change at page 5, line 42
For a terminating call, the following steps will be followed: For a terminating call, the following steps will be followed:
1. The S-CSCF receives the initial INVITE request for a terminating 1. The S-CSCF receives the initial INVITE request for a terminating
call and determines that the session case is for a terminating call and determines that the session case is for a terminating
user as described in [RFC5502]; user as described in [RFC5502];
2. The S-CSCF determines who is the served user by looking at the 2. The S-CSCF determines who is the served user by looking at the
Request-URI and saves the current Request-URI; Request-URI and saves the current Request-URI;
3. The S-CSCF analyzes the filter criteria. It then sends the 3. The S-CSCF analyzes the filter criteria. It then sends the
request to the AS of the served user an INVITE that includes the request to the AS of the served user as an INVITE that includes
P-Served-User header field with the "sescase" parameter set to the P-Served-User header field with the "sescase" parameter set
"term" and the "regstate" set to the corresponding value in order to "term" and the "regstate" set to the corresponding value in
to trigger execution of terminating services; order to trigger execution of terminating services;
4. Based on some criteria, the AS concludes that the request has to 4. Based on some criteria, the AS concludes that the request has to
be diverted to another target user or application. The AS be diverted to another target user or application. The AS
replaces the received Request-URI with the new diverted-to replaces the received Request-URI with the new diverted-to
address and the AS stores the successive Request-URI(s) values by address and the AS stores the successive Request-URI(s) values by
adding one or two History-Info header field entry(ies) [RFC7044] adding one or two History-Info header field entry(ies) [RFC7044]
in the outgoing INVITE. In the History-Info header field, the in the outgoing INVITE. In the History-Info header field, the
served user address is tagged using the mp-param header field served user address is tagged using the mp-param header field
parameter added in entry associated to the diverted-to address parameter added in entry associated to the diverted-to address
created. The AS forwards the INVITE request back to the S-CSCF; created. The AS forwards the INVITE request back to the S-CSCF;
 End of changes. 7 change blocks. 
28 lines changed or deleted 32 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/