draft-ietf-sipcore-originating-cdiv-parameter-08.txt   rfc8498.txt 
SIPCORE Working Group M. Mohali Internet Engineering Task Force (IETF) M. Mohali
Internet-Draft Orange Request for Comments: 8498 Orange
Updates: 5502 (if approved) December 10, 2018 Updates: 5502 February 2019
Intended status: Informational Category: Informational
Expires: June 13, 2019 ISSN: 2070-1721
A P-Served-User Header Field Parameter for Originating CDIV session case A P-Served-User Header Field Parameter for an
in Session Initiation Protocol (SIP) Originating Call Diversion (CDIV) Session Case in the
draft-ietf-sipcore-originating-cdiv-parameter-08 Session Initiation Protocol (SIP)
Abstract Abstract
The P-Served-User header field was defined based on a requirement The P-Served-User header field was defined based on a requirement
from 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia
Subsystem) in order to convey the identity of the served user, his/ Subsystem) in order to convey the identity of the served user, his/
her registration state and the session case that applies to this her registration state, and the session case that applies to that
particular communication session and application invocation. A particular communication session and application invocation. A
session case is metadata that captures the status of the session of 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 served user regardless of whether or not the served user is
whether the session originates or terminates with the served user. registered or the session originates or terminates with the served
This document updates RFC5502 by defining a new P-Served-User header user. This document updates RFC 5502 by defining a new P-Served-User
field parameter, "orig-cdiv". The parameter conveys the session case header field parameter, "orig-cdiv". The parameter conveys the
used by a proxy when handling an originating session after Call session case used by a proxy when handling an originating session
Diversion (CDIV) services have been invoked for the served user. after Call Diversion (CDIV) services have been invoked for the served
This document also fixes the ABNF in RFC 5502 and provides more user. This document also fixes the ABNF in RFC 5502 and provides
guidance for using the P-Served-User header field in IP networks. 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 document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on June 13, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8498.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 36 skipping to change at page 3, line 9
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 4
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Proxy behavior and parameter handling . . . . . . . . . . . . 5 4. Proxy Behavior and Parameter Handling . . . . . . . . . . . . 6
5. Clarification of RFC5502 procedures . . . . . . . . . . . . . 6 5. Clarification of RFC 5502 Procedures . . . . . . . . . . . . 7
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 9
7.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 7.1. Call Diversion Case . . . . . . . . . . . . . . . . . . . 9
7.2. Call diversion and privacy . . . . . . . . . . . . . . . 10 7.2. Call Diversion and Privacy . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
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 the 3rd Generation Partnership Project (3GPP) IMS
Multimedia Subsystem) in order to convey the identity of the served (IP Multimedia Subsystem) in order to convey the identity of the
user, his/her registration state and the session case between an served user, his/her registration state, and the session case between
Serving Call Session Control Function (S-CSCF) and an Application a 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 metadata that captures the status of the session of a served 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 user regardless of whether or not the served user is registered or
session originates or terminates with the served user. For more 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 both a CDIV service has been invoked and an originating service
originating service of the diverting user has to be triggered. 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 the P-Served-User header field, Section 3 discusses the applicability
scope of this new header field parameter, and Section 4 specifies the and scope of this new header field parameter, and Section 4 specifies
proxy behavior for handling the new header field parameter. the 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 7 gives some call flow examples, Section 8 registers the
IANA, Section 7 gives some examples, and Section 9 discusses the P-Served-User header field parameters with IANA, and Section 9
security properties of the environment where this new header field discusses the security properties of the environment where this new
parameter is intended to be used. header field parameter is intended to be used.
1.2. Basic Use Case 1.2. Basic Use Case
In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF) 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 is a SIP proxy that serves as a registrar and handles originating and
terminating session states for users assigned to it. This means that 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 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 terminated to that specific user will pass through the S-CSCF that is
assigned to that user. assigned to that user.
At the moment that an S-CSCF is assigned to a specific user, the user 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 profile is downloaded from the Home Subscriber Server (HSS) to that
S-CSCF, see [TS.3GPP.29.228]. The user profile contains the list of 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 actions to be taken by the S-CSCF for the served user depending on
the session direction (originating or terminating) and the user state the session direction (originating or terminating) and the user state
(registered or not) in the IMS network. With this user profile, the (registered or not) in the IMS network. With this user profile, the
S-CSCF determines the current case and applies the corresponding S-CSCF determines the current case and applies the corresponding
actions such as forwarding the request to an AS. The AS then goes actions such as forwarding the request to an AS. The AS then goes
through a similar process of determining who is the current served through a similar process of determining who is the current served
user, what is his/her "registration state", and what is the "session user, what is his/her "registration state", and what is the "session
case" of the session. [RFC5502] defines all those parameters and in case" of the session. [RFC5502] defines all those parameters and in
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 CDIV services for which the session is re-targeted, the session cases
session cases defined in [RFC5502] pose some limitations as described defined in [RFC5502] pose some limitations as described in the
in the following section. following section.
1.3. Problem Statement 1.3. Problem Statement
To illustrate the problem statement, let's imagine Alice trying to To illustrate the problem statement, let's imagine Alice trying to
call Bob and Bob having a call diversion service activated towards call Bob and Bob having a CDIV service activated towards Carol's
Carol's address. In the case of a call diversion service, the address. In the case of a CDIV service, the received request is
received request is first treated as a terminating session case (at first treated as a terminating session case (at Bob's side), and the
Bob side), and the terminating filter criteria configured in the terminating filter criteria configured in the S-CSCF is performed. A
S-CSCF are performed. A filter criteria is information in the user filter criteria is information in the user profile that determines
profile that determines whether an initial request is sent to a whether an initial request is sent to a particular AS. When the AS
particular AS. When the AS receives the call initiation request, the receives the call initiation request, the AS is able to determine the
AS is able to determine the served user (Bob) and the session case served user (Bob) and the session case (here "term") from the
(here "term") from the received P-Served-User header field content received P-Served-User header field content and is able to execute
and to execute terminating services. When the call diversion service terminating services. When the CDIV service is executed (as a
is executed (as a terminating service of Bob), the AS changes the terminating service of Bob), the AS changes the target (Request-URI)
target (Request-URI) of the session (toward Carol's address) and a of the session (toward Carol's address) and a new call leg is
new call leg is created. The served user becomes the diverting user. created. The served user becomes the diverting user. This new call
This new call leg could be considered as an originating call leg from leg could be considered as an originating call leg from the diverting
the diverting user (Bob) but this is not the case. Indeed, the user (Bob), but this is not the case. Indeed, the originating user
originating user remains the same (Alice), and some of the diverting remains the same (Alice), and some of the diverting user's
user's originating services should not be triggered as if it was an 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 (e.g., 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 CDIV.
diversion. Without a dedicated session case for originating-after- Without a dedicated session case for originating-after-CDIV, the
CDIV, the S-CSCF cannot trigger an originating service for the S-CSCF cannot trigger an originating service for the diverting user,
diverting user, nor can an AS execute the procedures for this nor can an AS execute the procedures for this particular session
particular session case. case.
For this use case, this document creates a new parameter ("orig- For this use case, this document creates a new parameter
cdiv") for the originating-after-CDIV session case to be embedded in ("orig-cdiv") for the originating-after-CDIV session case to be
the P-Served-User header field. embedded in 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.
3. Applicability 3. Applicability
The use of the P-Served-User header field extensions is only The use of the P-Served-User header field extensions is only
applicable inside a Trust Domain [RFC3324] for the P-Served-User applicable inside a Trust Domain [RFC3324] for the P-Served-User
header field. Nodes in such a Trust Domain explicitly trust each header field. Nodes in such a Trust Domain explicitly trust each
other to convey the served user and to be responsible for withholding other to convey the served user and to be responsible for withholding
that information outside of the Trust Domain. The means by which the that information outside of the Trust Domain. The means by which the
network determines the served user and the policies that are executed network determines the served user and the policies that are executed
for a specific served user is outside the scope of this document. for a specific served user is outside the scope of this document.
4. Proxy behavior and parameter handling 4. Proxy Behavior and Parameter Handling
The following section illustrates how this header field parameter can The following section illustrates how this header field parameter can
be used in a 3GPP network. be used in a 3GPP network.
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 as an INVITE that includes request to the AS of the served user as an INVITE that includes
the P-Served-User header field with the "sescase" parameter set the P-Served-User header field with the "sescase" parameter set
to "term" and the "regstate" set to the corresponding value in to "term" and the "regstate" set to the corresponding value in
order 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 stores the successive Request-URI(s) values by adding
adding one or two History-Info header field entry(ies) [RFC7044] one or two History-Info header field entry(ies) [RFC7044] in the
in the outgoing INVITE. In the History-Info header field, the outgoing INVITE. In the History-Info header field, the served
served user address is tagged using the mp-param header field user address is tagged by using the mp-param header field
parameter added in entry associated to the diverted-to address parameter added in the newly created entry that contains the
created. The AS forwards the INVITE request back to the S-CSCF; diverted-to address. The AS forwards the INVITE request back to
the S-CSCF.
5. When receiving back the INVITE request, the S-CSCF can see that 5. When receiving back the INVITE request, the S-CSCF can see that
the topmost Route header field contains its own hostname but the the topmost Route header field contains its own hostname, but the
Request-URI does not match the saved Request-URI. In this case, Request-URI does not match the saved Request-URI. In this case,
the S-CSCF updates the P-Served-User header field content by the S-CSCF updates the P-Served-User header field content by
replacing the "sescase" parameter with the "orig-cdiv" parameter. replacing the "sescase" parameter with the "orig-cdiv" parameter.
The P-Served-User header field value remains unchanged; The P-Served-User header field value remains unchanged.
6. The S-CSCF forwards the INVITE request to an AS that hosts the 6. The S-CSCF forwards the INVITE request to an AS that hosts the
originating services of the served user (diverting user) that served user's (diverting user's) originating services, which need
need to be executed on the forwarded leg after a call diversion to be executed on the forwarded leg after a CDIV service.
service;
7. When the AS receives the INVITE request, it determines that the 7. When the AS receives the INVITE request, it determines that the
session case is for "orig-cdiv" session case and performs the session case is for the "orig-cdiv" session case and performs the
originating services to be executed after retargeting for the originating services to be executed after retargeting for the
diverting user (i.e. served user). diverting user (i.e., served user).
5. Clarification of RFC5502 procedures 5. Clarification of RFC 5502 Procedures
This document provides the following guidance for the handling of the This document provides the following guidance for the handling of the
P-Served-User header field that are missing in [RFC5502]: P-Served-User header field that is missing in [RFC5502]:
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 document also updates the syntax of the
header from [RFC5502] to reflect this uniqueness of parameters header from [RFC5502] to reflect this uniqueness of parameter
values. values.
o [RFC5502] does not clearly state what to do with the received P- o [RFC5502] does not clearly state what to do with the received
Served-User header field when a call is diverted to another P-Served-User header field when a call is diverted to another
destination. This document highlights that there are several ways destination. This document highlights that there are several ways
of handling the P-Served-User header field: the S-CSCF could store of handling the P-Served-User header field: the S-CSCF could store
the previous "regstate" value and decide that the same value the previous "regstate" value and decide that the same value
applies; or the "regstate" may no longer be relevant after a applies, the "regstate" may no longer be relevant after a
diverting service so the S-CSCF removes it; or the regstate could diverting service so the S-CSCF removes it, or the "regstate"
be combined with the orig-cdiv session case to provide different could be combined with the "orig-cdiv" session case to provide
services depending on whether the served user is registered or different services depending on whether the served user is
unregistered. These choices are implementation dependent. registered or unregistered. These choices are implementation
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" as predefined values. This document defines an
additional parameter for the sessioncase-param: "orig-cdiv". additional parameter, "orig-cdiv", for the sessioncase-param.
Because this document extends the existing sessioncase-param Because this document extends the existing sessioncase-param
parameter, and because errors have been identified in the syntax, parameter, and because errors have been identified in the syntax,
this document corrects and extends the P-Served-User header field. this document corrects and extends the P-Served-User header field.
The extension of the sessioncase-param parameter to add the "orig- The extension of the sessioncase-param parameter to add the
cdiv" session case is done in a way to fit the parameter format "orig-cdiv" session case is done in a way that fits the parameter
introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and to maintain format introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and
a backward compatibility. maintains backward compatibility.
"EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and
param" are defined in [RFC3261]. "generic-param" are defined in [RFC3261].
If the "addr-spec" contains a comma, question mark, or semicolon, the
"name-addr" form MUST be used. The "name-addr" form requires the use
of angle brackets (< and >).
6.2. ABNF 6.2. ABNF
The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P- The Augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the
Served-User header field is described in [RFC5502]. P-Served-User header field is described in [RFC5502].
This document updates [RFC5502] to correct the P-Served-User header This document updates [RFC5502] to correct the P-Served-User header
field ABNF syntax and extend it as following: field ABNF syntax and extend it as the following:
P-Served-User = "P-Served-User" HCOLON PServedUser-value P-Served-User = "P-Served-User" HCOLON PServedUser-value
*(SEMI served-user-param) *(SEMI served-user-param)
served-user-param = sessioncase-param served-user-param = sessioncase-param
/ registration-state-param / registration-state-param
/ generic-param / generic-param
PServedUser-value = name-addr / addr-spec PServedUser-value = name-addr / addr-spec
sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv
registration-state-param = "regstate" EQUAL ("unreg" / "reg") registration-state-param = "regstate" EQUAL ("unreg" / "reg")
orig-cdiv = "orig-cdiv" orig-cdiv = "orig-cdiv"
Examples of possible P-Served-User header field: Examples of possible P-Served-User header fields:
P-Served-User: <sip:user@example.com>; orig-cdiv; regstate=reg P-Served-User: <sip:user@example.com>; orig-cdiv; regstate=reg
or or
P-Served-User: <sip:user@example.com>; orig-cdiv P-Served-User: <sip:user@example.com>; orig-cdiv
or or
P-Served-User: <sip:user@example.com>; sescase=term; regstate=unreg P-Served-User: <sip:user@example.com>; sescase=term; regstate=unreg
This document allows choosing between addr-spec and name-addr when
constructing the header field value. As specified in RFC 8217, the This document allows choosing between "addr-spec" and "name-addr"
"addr-spec" form MUST NOT be used if its value would contain a comma, when constructing the header field value. As specified in RFC 8217,
semicolon, or question mark [RFC8217]. 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. Call Flow Examples
7.1. Call diversion case 7.1. Call Diversion Case
The following call flow shows a session establishment when Alice The following call flow shows a session establishment when Alice
calls Bob, who has a call diversion service that diverts to Carol calls Bob, who has a CDIV service that diverts to Carol when Bob is
when Bob is busy. busy.
proxy server UA proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | | | | | | |
| INVITE F1 | | | | | INVITE F1 | | | |
|--------------->| INVITE F2 | | | |--------------->| INVITE F2 | | |
| |--------------->| | | | |--------------->| | |
| | INVITE F3 | | | | | INVITE F3 | | |
| |<---------------| INVITE F4 | | | |<---------------| INVITE F4 | |
| |-------------------------------->| | | |-------------------------------->| |
skipping to change at page 9, line 23 skipping to change at page 10, line 17
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg P-Served-User: <sip:bob@example.com>; term; regstate=reg
F4 INVITE S-CSCF-B -> Bob F4 INVITE S-CSCF-B -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0 INVITE sip:bob@192.0.2.4 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg P-Served-User: <sip:bob@example.com>; term; regstate=reg
[Bob is busy. His call diversion when busy is invoked towards Carol] [Bob is busy. His CDIV when busy is invoked towards Carol]
F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B F5-F6 486 BUSY Bob -> S-CSCF-B -> AS-B
486 BUSY 486 BUSY
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com>;tag=es43sd To: Bob <sip:bob@example.com>;tag=es43sd
[Alice's call is diverted to Carol] [Alice's call is diverted to Carol]
F7 INVITE AS-B -> S-CSCF-B F7 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0 INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg P-Served-User: <sip:bob@example.com>; term; regstate=reg
[Forwarded leg to Carol is identified as an originating call after [The forwarded leg to Carol is identified as an originating call after
diversion that should not trigger all Bob's originating services] CDIV, which should not trigger all of Bob's originating services]
F8 INVITE S-CSCF-B -> AS-B F8 INVITE S-CSCF-B -> AS-B
INVITE sip:carol@domainc.com SIP/2.0 INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F9 INVITE AS-B -> S-CSCF-B F9 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0 INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
F10 INVITE S-CSCF-B -> Carol F10 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0 INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Figure 1: P-Served-User during call diversion service Figure 1. P-Served-User During CDIV Service
7.2. Call diversion and privacy 7.2. Call Diversion and Privacy
The following call flow shows a call diversion use case for which The following call flow shows a CDIV use case for which Alice has no
Alice has no identity restriction service and Bob has an identity restriction service and Bob has an unconditional CDIV
unconditional call diversion service towards Carol and an identity service towards Carol and an identity presentation restriction
presentation restriction service. service.
proxy server UA proxy server UA
Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol Alice Bob's...S-CSCF-B..........AS-B.............Bob Carol
| | | | | | | | | |
| INVITE F1 | | | | | INVITE F1 | | | |
|--------------->| INVITE F2 | | | |--------------->| INVITE F2 | | |
| |--------------->| | | | |--------------->| | |
| | INVITE F3 | | | | | INVITE F3 | | |
| |<---------------| | | | |<---------------| | |
| | INVITE F4 | | | | | INVITE F4 | | |
skipping to change at page 11, line 6 skipping to change at page 12, line 5
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Supported: histinfo Supported: histinfo
F2 INVITE S-CSCF-B -> AS-B F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg P-Served-User: <sip:bob@example.com>; term; regstate=reg
[Bob's unconditional call diversion to Carol is triggered] [Bob's unconditional CDIV to Carol is triggered]
F3 INVITE AS-B -> S-CSCF-B F3 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0 INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com> To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; term; regstate=reg P-Served-User: <sip:bob@example.com>; term; regstate=reg
History-Info: History-Info:
<sip:bob@example.com>;index=1, <sip:bob@example.com>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1 <sip:carol@domainc.com;cause=302>;index=1.1;mp=1
skipping to change at page 11, line 38 skipping to change at page 12, line 37
F5 INVITE AS-B -> S-CSCF-B F5 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0 INVITE sip:carol@domainc.com SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com> To: Carol <sip:carol@domainc.com>
P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
History-Info: History-Info:
<sip:bob@example.com?privacy=history>;index=1, <sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=1 <sip:carol@domainc.com;cause=302>;index=1.1;mp=1
[Forwarded leg to Carol is identified as an originating call after [Forwarded leg to Carol is identified as an originating call after
diversion that allows to apply Bob's privacy request to his identity CDIV that allows Bob's privacy service to be applied to his
within the Histroy-Info header field] identity within the History-Info header field]
F6 INVITE S-CSCF-B -> Carol F6 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0 INVITE sip:carol@192.0.2.7 SIP/2.0
From: Alice <sip:alice@domaina.com>;tag=1928301774 From: Alice <sip:alice@domaina.com>;tag=1928301774
To: Carol <sip:carol@domainc.com> To: Carol <sip:carol@domainc.com>
History-Info: History-Info:
<sip:bob@example.com?privacy=history>;index=1, <sip:bob@example.com?privacy=history>;index=1,
<sip:carol@domainc.com;cause=302>;index=1.1;mp=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 <sip:carol@192.0.2.7>;index=1.1.1;rc=1.1
Figure 2: P-Served-User when privacy requested Figure 2. P-Served-User When Privacy Requested
8. IANA Considerations 8. IANA Considerations
The syntax of the P-Served-User header field [RFC5502] is updated in The syntax of the P-Served-User header field [RFC5502] is updated in
Section 4 of this document. Section 4 of this document.
This document requests IANA to update the existing row for the P- IANA has updated the existing row for the P-Served-User header field
Served-User header field in the "Header Fields" sub-registry within in the "Header Fields" subregistry within the "Session Initiation
the "Session Initiation Protocol (SIP) Parameters" registry: 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 Name Compact Form Reference
header field parameters in the "Header Field Parameters and Parameter ------------- ------------ ------------------
Values" sub-registry within the "Session Initiation Protocol (SIP) P-Served-User none [RFC5502][RFC8498]
Parameters" registry: as per the registry created by [RFC3968]:
Header Field Parameter Name Predefined Values Reference IANA has added new rows for the P-Served-User header field parameters
-------------- ---------------- ----------------- ----------------- in the "Header Field Parameters and Parameter Values" subregistry
P-Served-User sescase Yes [RFC5502] within the "Session Initiation Protocol (SIP) Parameters" registry
P-Served-User regstate Yes [RFC5502] (as per the registry created by [RFC3968]):
P-Served-User orig-cdiv No [RFCXXXX]
Note to RFC Editor: Please replace XXXX with the RFC number of this Header Field Parameter Name Predefined Values Reference
document. -------------- ---------------- ----------------- -------------
P-Served-User sescase Yes [RFC5502]
P-Served-User regstate Yes [RFC5502]
P-Served-User orig-cdiv No [RFC8498]
9. Security Considerations 9. Security Considerations
The security considerations in [RFC5502] apply. The security considerations in [RFC5502] apply.
As the "orig-cdiv" parameter of P-Served-User header field can be As the "orig-cdiv" parameter of the P-Served-User header field can be
used to trigger applications when a call is diverted , it is used to trigger applications when a call is diverted, it is important
important to ensure that the parameter has not been added to the SIP to ensure that the parameter has not been added to the SIP message by
message by an unauthorized SIP entity. Thus, the P-Served-User an unauthorized SIP entity. Thus, the P-Served-User header field is
header field is to be used in a trusted environment and proxies MUST to be used in a trusted environment, and proxies MUST NOT insert the
NOT insert the header unless they have sufficient knowledge that the header unless they have sufficient knowledge that the route set
route set includes another trusted proxy. includes another trusted proxy.
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 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted [RFC3324] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
<https://www.rfc-editor.org/info/rfc3324>. <https://www.rfc-editor.org/info/rfc3324>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and
Schooler, "SIP: Session Initiation Protocol", RFC 3261, E. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8217] Sparks, R., "Clarifications for When to Use the name-addr [RFC8217] Sparks, R., "Clarifications for When to Use the name-addr
Production in SIP Messages", RFC 8217, Production in SIP Messages", RFC 8217,
DOI 10.17487/RFC8217, August 2017, DOI 10.17487/RFC8217, August 2017,
skipping to change at page 14, line 16 skipping to change at page 15, line 10
C. Holmberg, "An Extension to the Session Initiation C. Holmberg, "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 7044, Protocol (SIP) for Request History Information", RFC 7044,
DOI 10.17487/RFC7044, February 2014, DOI 10.17487/RFC7044, February 2014,
<https://www.rfc-editor.org/info/rfc7044>. <https://www.rfc-editor.org/info/rfc7044>.
[RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header [RFC5502] van Elburg, J., "The SIP P-Served-User Private-Header
(P-Header) for the 3GPP IP Multimedia (IM) Core Network (P-Header) for the 3GPP IP Multimedia (IM) Core Network
(CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April
2009, <https://www.rfc-editor.org/info/rfc5502>. 2009, <https://www.rfc-editor.org/info/rfc5502>.
11.2. Informative References 10.2. Informative References
[TS.3GPP.24.229] [TS.3GPP.24.229]
3GPP, "IP multimedia call control protocol based on 3GPP, "IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description Session Initiation Protocol (SIP) and Session Description
Protocol (SDP);Stage 3", 3GPP TS 24.229 v11. Protocol (SDP);Stage 3", 3GPP TS 24.229 11.28.0, December
2018.
[TS.3GPP.29.228] [TS.3GPP.29.228]
3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces;
Signalling flows and message contents", 3GPP TS 29.228 Signalling flows and message contents", 3GPP TS 29.228
v11. 15.1.0, September 2018.
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.
Author's Address Author's Address
Marianne Mohali Marianne Mohali
Orange Orange
Orange Gardens, 44 avenue de la Republique Orange Gardens, 44 avenue de la Republique
Chatillon 92326 Chatillon 92326
France France
Email: marianne.mohali@orange.com Email: marianne.mohali@orange.com
 End of changes. 67 change blocks. 
199 lines changed or deleted 200 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/