draft-ietf-sipcore-originating-cdiv-parameter-03.txt   draft-ietf-sipcore-originating-cdiv-parameter-04.txt 
SIPCORE Working Group M. Mohali SIPCORE Working Group M. Mohali
Internet-Draft Orange Internet-Draft Orange
Updates: 5502 (if approved) August 27, 2018 Updates: 5502 (if approved) September 24, 2018
Intended status: Informational Intended status: Informational
Expires: February 28, 2019 Expires: March 28, 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-03 draft-ietf-sipcore-originating-cdiv-parameter-04
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 February 28, 2019. This Internet-Draft will expire on March 28, 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8
8. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 7.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8
8.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 7.2. Call diversion and privacy . . . . . . . . . . . . . . . 10
8.2. Call diversion and privacy . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
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
S-CSCF (Serving Call Session Control Function) and an AS (Application Serving Call Session Control Function (S-CSCF) and an Application
Server) on the ISC (IMS Service Control) interface. For more Server (AS) on the IMS Service Control (ISC) interface. A session
case is an information indicating the status of the session in which
the served user is involved (originating, terminating..). 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
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 7 registers the P-Served-User header field parameters with Section 8 registers the P-Served-User header field parameters with
IANA, Section 8 gives some examples, and Section 9 discusses the IANA, Section 7 gives some examples, and Section 9 discusses the
security properties of the environment where this new header field security properties of the environment where this new header field
parameter is intended to be used. 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 allocated to it. This means terminating session states for users assigned to it. This means that
that any call that is originated by a specific user or any call that any call that is originated by a specific user or any call that is
is terminated to that specific user will pass through the S-CSCF that terminated to that specific user will pass through the S-CSCF that is
is allocated to that user. assigned to that user.
At the moment that an S-CSCF is allocated for a specific user, the At the moment that an S-CSCF is assigned to a specific user, the user
user profile is downloaded from the HSS (Home Subscriber Server) to profile is downloaded from the Home Subscriber Server (HSS) to this
this S-CSCF, see [TS.3GPP.29.228]. The user profile contains the S-CSCF, see [TS.3GPP.29.228]. The user profile contains the list of
list of actions to be taken by the S-CSCF for the served user actions to be taken by the S-CSCF for the served user depending on
depending on the session direction (originating or terminating) and the session direction (originating or terminating) and the user state
the user state (registered or not) in the IMS network. With this (registered or not) in the IMS network. With this user profile, the
user profile, the S-CSCF determines the current case and applies the S-CSCF determines the current case and applies the corresponding
corresponding actions such as forwarding the request to an AS. The actions such as forwarding the request to an AS. The AS then goes
AS then goes through a similar process of determining who is the through a similar process of determining who is the current served
current served user, what is his/her "registration state", and what user, what is his/her "registration state", and what is the "session
is the "session case" of the session. [RFC5502] defines all those case" of the session. [RFC5502] defines all those parameters and in
parameters and in particular the originating and terminating session particular the originating and terminating session cases.
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 In the case of a call diversion service, the received request is
first considered 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. When the AS filter criteria configured in the S-CSCF are performed. A filter
receives the call initiation request, the AS is able to determine the criteria is a user profile information that determines whether a
served user and the session case (here "term") from the received P- particular initial request needs to be sent to a particular AS. When
Served-User header field content and to execute terminating services. the AS receives the call initiation request, the AS is able to
When the call diversion service is executed (as a terminating determine the served user and the session case (here "term") from the
service), the AS changes the target (Request-URI) of the session and received P-Served-User header field content and to execute
a new call leg is created. This new call leg could be considered as terminating services. When the call diversion service is executed
an originating call leg from the diverting user but this is not the (as a terminating service), the AS changes the target (Request-URI)
case. Indeed, the originating user remains the same, and some of the of the session and a new call leg is created. This new call leg
diverting user's originating services should not be triggered as if could be considered as an originating call leg from the diverting
it was an originating call. For instance, the originating user user but this is not the case. Indeed, the originating user remains
identity should not be restricted because the diverting user has a the same, and some of the diverting user's originating services
privacy service for his/her own identity. The privacy of the should not be triggered as if it was an originating call. For
diverting user should apply to information related to this user (eg. instance, the originating user identity should not be restricted
in the History-Info header field). In the same manner, some specific because the diverting user has a privacy service for his/her own
services will need to be specifically triggered on the outgoing leg identity. The privacy of the diverting user should apply to
after a call diversion. Without a dedicated session case for information related to this user (eg. in the History-Info header
originating after CDIV, the S-CSCF cannot trigger an originating field). In the same manner, some specific services will need to be
service for the diverting user, nor can an AS execute the procedures triggered on the outgoing leg after a call diversion. Without a
for this particular session case. dedicated session case for originating after CDIV, the S-CSCF cannot
trigger an originating service for the diverting user, nor can an AS
execute the procedures for this 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
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 P-Served-User header applicable inside a Trust Domain [RFC3324] for the P-Served-User
field. Nodes in such a Trust Domain explicitly trust each other to header field. Nodes in such a Trust Domain explicitly trust each
convey the served user and to be responsible for withholding that other to convey the served user and to be responsible for withholding
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 to the AS 3. The S-CSCF analyzes the filter criteria. It then sends the
of the served user an INVITE that includes the P-Served-User request to the AS of the served user an INVITE that includes the
header field with the "sescase" parameter set to "term" and the P-Served-User header field with the "sescase" parameter set to
"regstate" set to the corresponding value in order to trigger "term" and the "regstate" set to the corresponding value in order
execution of terminating services; 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;
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 originating services of the served user (diverting user) that
specifically need to be executed on the forwarded leg after a need to be executed on the forwarded leg after a call diversion
call diversion 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 "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 RFC5502 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 are 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 different 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 Whether the S-CSCF removes the "regstate" parameter when it o In [RFC5502], except for security reasons, it is not to clearly
processes the orig-cdiv session case is out of the scope of this stated what to do with the received P-Served-User header field
document. The S-CSCF could store the previous regstate value and when a call is diverted to another destination. This document
that the same value applies, or the "regstate" may not be relevant dealing with this specific use case, highlights that several
after a diverting service, or the regstate could be combined with possibilities exist: the S-CSCF could store the previous
the orig-cdiv session case to provide different services if the "regstate" value and decide that the same value applies, or the
served user is registered or unregistered. These choices are "regstate" may not be relevant after a diverting service and
implementation dependent. removed, or the regstate could be combined with the orig-cdiv
session case to provide different services if the served user is
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" 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
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.
skipping to change at page 7, line 38 skipping to change at page 8, line 4
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 field:
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 This document allows choosing between addr-spec and name-addr when
constructing the header field value. As specified in RFC 8217, the 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, "addr-spec" form MUST NOT be used if its value would contain a comma,
semicolon, or question mark [RFC8217]. semicolon, or question mark [RFC8217].
7. IANA Considerations 7. Call Flow Examples
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][RFCXXXX]
P-Served-User regstate Yes [RFC5502][RFCXXXX]
P-Served-User orig-cdiv No [RFCXXXX]
Note to RFC Editor: Please replace XXXX with the RFC number of this
document.
8. Call Flow Examples
8.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 call diversion service that diverts to Carol
when Bob is busy. when Bob is 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 | | |
skipping to change at page 10, line 32 skipping to change at page 10, line 12
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 call diversion service
8.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 call diversion use case for which
Alice has no identity restriction service and Bob has an Alice has no identity restriction service and Bob has an
unconditional call diversion service towards Carol and an identity unconditional call diversion service towards Carol and an identity
presentation restriction service. presentation restriction 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 | | | |
skipping to change at page 12, line 25 skipping to change at page 12, line 5
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
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 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 P-Served-User header field can be
used to trigger applications, it is important to ensure that the used to trigger applications when a call is diverted , it is
parameter has not been added to the SIP message by an unauthorized important to ensure that the parameter has not been added to the SIP
SIP entity. 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.
10. Acknowledgments 10. Acknowledgments
The author wishes to thank the 3GPP community for providing guidance, The author wishes to thank the 3GPP community for providing guidance,
input, and comments on the document. Thanks to Dale Worley and Jean input, and comments on the document. Thanks to Dale Worley, Jean
Mahoney for their careful review of the document. Thanks to Paul Mahoney and Ben Campbell for their careful review of the document.
Kyzivat and Adam Roach. A special thanks to Christer Holmberg. Thanks to Paul Kyzivat and Adam Roach. A special thanks to Christer
Holmberg.
11. References 11. References
11.1. Normative References 11.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>.
 End of changes. 26 change blocks. 
117 lines changed or deleted 125 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/