draft-ietf-sipcore-originating-cdiv-parameter-01.txt   draft-ietf-sipcore-originating-cdiv-parameter-02.txt 
SIPCORE Working Group M. Mohali SIPCORE Working Group M. Mohali
Internet-Draft Orange Internet-Draft Orange
Updates: 5502 (if approved) September 27, 2017 Updates: 5502 (if approved) May 22, 2018
Intended status: Informational Intended status: Informational
Expires: March 31, 2018 Expires: November 23, 2018
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-01 draft-ietf-sipcore-originating-cdiv-parameter-02
Abstract Abstract
This specification defines a new parameter of the P-Served-User The P-Served-User header field RFC5502 is used to convey the identity
header field in the Session Initiation Protocol (SIP). This new of the served user and the session case that applies to this
"orig-cdiv" parameter defines the session case used by a proxy when particular communication session and application invocation. This
handling an originating session after Call Diversion (CDIV) services document updated RFC5502 by defining a new P-Served-User header field
has been invoked for the served user. The P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used
is defined in RFC5502 to convey the identity of the served user and by a proxy when handling an originating session after Call Diversion
the session case that applies to this particular communication (CDIV) services has been invoked for the served user. This document
session and application invocation. This document updates RFC5502 to also fixes the ABNF in RFC5502 and provides more guidance for using
add the "originating after CDIV" session case and to provide more the P-Served-User header field in IP networks.
guidance for using the P-Served-User header field in IP networks that
were missing in RFC5502.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2018. This Internet-Draft will expire on November 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3 1.2. Basic Use Case . . . . . . . . . . . . . . . . . . . . . 3
1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. Proxy behavior and parameter handling . . . . . . . . . . . . 4 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Proxy behavior and parameter handling . . . . . . . . . . . . 4
4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Clarification of RFC5502 procedures . . . . . . . . . . . . . 5
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8 7. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . 8
6.2. Call diversion and privacy . . . . . . . . . . . . . . . 9 7.1. Call diversion case . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7.2. Call diversion and privacy . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
1.1. General 1.1. General
The P-Served-User header field was defined in [RFC5502] to address an The P-Served-User header field [RFC5502] was defined based on a
issue that was found in the 3rd Generation Partnership Project (3GPP) requirement from 3rd Generation Partnership Project (3GPP) IMS (IP
IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Multimedia Subsystem) in order to convey the identity of the served
Control Function) and an AS (Application Server) on the ISC (IMS user, his/her registration state and the session case between an
Service Control) interface. For more information on the IMS, a S-CSCF (Serving Call Session Control Function) and an AS (Application
detailed description can be found in [TS.3GPP.24.229]. Server) on the ISC (IMS Service Control) interface. For more
information on the IMS, a detailed description can be found in
The P-Served-User header field conveys the identity of the served [TS.3GPP.24.229].
user, his/her registration state and the session case that applies to
this particular communication session and application invocation.
[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 2 specifies the proxy behavior P-Served-User header field, Section 2 discusses the applicability and
for handling the new header field parameter, and Section 3 discusses scope of this new header field parameter, and Section 3 specifies the
the applicability and scope of this new header field parameter. proxy behavior for handling the new header field parameter.
Section 4 describes the syntax and correct the syntax of [RFC5502], Section 4 clarifies some of the [RFC5502] procedures, Section 5
Section 5 registers the P-Served-User header field parameters with describes the extended syntax and correct the syntax of [RFC5502],
IANA, and Section 6 discusses the security properties of the Section 6 registers the P-Served-User header field parameters with
environment where this new header field parameter is intended to be IANA, Section 7 gives some examples and Section 8 discusses the
used. security properties of the environment where this new 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 allocated to it. This means terminating session states for users allocated to it. This means
that any call that is originated by a specific user or any call that that 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 allocated to that user. is allocated to that user.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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] poses some limitations as session cases defined in [RFC5502] poses some limitations as
described in the following section. described in the following section.
1.3. Problem Statement 1.3. Problem Statement
In case of a call diversion service, the received request is first In case of a call diversion service, the received request is first
considered as a terminating session case and the terminating filter considered as a terminating session case and the terminating filter
criteria configured in the S-CSCF are performed. Receiving the call criteria configured in the S-CSCF are performed. Receiving the call
initiation request, the Application Server is able to determine the initiation request, the AS is able to determine the served user and
served user and the session case (here "term") from the received P- the session case (here "term") from the received P-Served-User header
Served-User header field content and to execute terminating services. field content and to execute terminating services. When the call
When the call diversion service is executed (as a terminating diversion service is executed (as a terminating service), the AS
service), the Application Server changes the target (Request-URI) of changes the target (Request-URI) of the session and a new call leg is
the session and a new call leg is created. This new call leg could created. This new call leg could be considered as an originating
be considered as an originating call leg from the diverting user but call leg from the diverting user but this is not the case. Indeed,
this is not the case. Indeed, the originating user remains the same the originating user remains the same and some of the diverting
and some of the diverting user's originating services should not be user's originating services should not be triggered as if it was an
triggered as if it was an originating call. For instance, the originating call. For instance, the originating user identity should
originating user identity should not be restricted because the not be restricted because the diverting user has a privacy service
diverting user has a privacy service for his/her own identity. The for his/her own identity. The privacy of the diverting user should
privacy of the diverting user should apply to information related to apply to information related to this user (eg. in the History-Info
this user (eg. in the Histroy-Info header field). In the same header field). In the same manner, some specific services will need
manner, some specific services will need to be specifically triggered to be specifically triggered on the outgoing leg after a call
on the outgoing leg after a call diversion. Without a dedicated diversion. Without a dedicated session case for originating after
session case for originating after CDIV, there is no possiblity for a CDIV, there is no possiblity for a proxy to trigger an originating
proxy to trigger an originating service for the diverting user or for service for the diverting user or for an AS to execute the procedures
an Application Server to execute the procedures for this particular for this particular session case.
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. Proxy behavior and parameter handling 2. Applicability
The "orig-cdiv" header field parameter can be used inside a trust The use of the P-Served-User header field extensions is only
domain of the P-Served-User header field by proxies that are applicable inside a Trust Domain for P-Served-User header field.
processing call diversion services. The following section Nodes in such a Trust Domain explicitly trust each other to convey
illustrates how this header field parameter can be used in a 3GPP the served user and to be responsible for withholding that
network. information outside of the Trust Domain. The means by which the
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 terminating call, when receiving the initial INVITE request, 3. Proxy behavior and parameter handling
the S-CSCF will determine that the session case is for a terminating
user as described in [RFC5502], then it determines the served user by
looking at the Request-URI and saves this Request-URI. After that,
the S-CSCF starts the analysis of filter criteria and triggers the
served user Application Server for the terminating services to be
executed including in the INVITE request the P-Served-User header
field with the "sescase" parameter set to "term" and the regstate to
the corresponding value.
Based on some criteria, the Application Server concludes that the The following section illustrates how this header field parameter can
request has to be diverted to another target user or application. be used in a 3GPP network.
The received Request-URI is then replaced with the new diverted-to
address. The Application Server stores the successive Request-URI(s)
values by adding one or two History-Info header field entry(ies)
[RFC7044] in the outgoing INVITE. In the History-Info header field,
the served user address is tagged thanks to the mp-param header field
parameter added in entry associated to the diverted-to address
created.
In the next step, the Application Server forwards the INVITE request For a terminating call, the following steps will be followed:
back to the S-CSCF. When receiving back the INVITE request, the
S-CSCF can see that the topmost Route header field contains its own
hostname but the Request-URI does not match the saved Request-URI.
In this case, the S-CSCF updates the P-Served-User header field
content by replacing the "sescase" parameter by the "orig-cdiv"
parameter. The PServedUser-value remains unchanged.
Then the procedure continues by forwarding the INVITE request over to 1. The S-CSCF receives the initial INVITE request for a terminating
an AS that hosts the originating services of the served user call and determines that the session case is for a terminating
(diverting user) that specifically need to be executed on the user as described in [RFC5502];
forwarded leg after a call diversion service.
When the Application Server receives the INVITE request, it 2. The S-CSCF determines who is the served user by looking at the
determines that the session case is for "orig-cdiv" session case and Request-URI and saves the current Request-URI;
will perform the originating services to be executed after
retargeting for the diverting user (i.e. served user).
This document also provides the following guidance that reminds or 3. The S-CSCF starts the analysis of filter criteria and triggers
clarifies the P-Served-User handling that are missing in [RFC5502]: the served user AS for the terminating services to be executed by
including in the INVITE request the P-Served-User header field
with the "sescase" parameter set to "term" and the regstate to
the corresponding value;
o This header is forbidden to be repeated within a request for a 4. Based on some criteria, the AS concludes that the request has to
particular session at a particular time for the reason that be diverted to another target user or application. The received
session cases are mutually exclusive. This document updates Request-URI is then replaced with the new diverted-to address and
[RFC5502] to clearly state that P-Served-User header field MUST the AS stores the successive Request-URI(s) values by adding one
not contain different values either comma-separated or header- or two History-Info header field entry(ies) [RFC7044] in the
separated. This documents also updates the syntax of the header outgoing INVITE. In the History-Info header field, the served
as defined in [RFC5502] to reflect this uniqueness of parameters user address is tagged using the mp-param header field parameter
values. added in entry associated to the diverted-to address 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
the topmost Route header field contains its own hostname but the
Request-URI does not match the saved Request-URI. In this case,
the S-CSCF updates the P-Served-User header field content by
replacing the "sescase" parameter by the "orig-cdiv" parameter.
The P-Served-User header field value remains unchanged;
6. The S-CSCF forwards the INVITE request over to an AS that hosts
the originating services of the served user (diverting user) that
specifically need to be executed on the forwarded leg after a
call diversion service;
7. When the AS receives the INVITE request, it determines that the
session case is for "orig-cdiv" session case and will perform the
originating services to be executed after retargeting for the
diverting user (i.e. served user).
4. Clarification of RFC5502 procedures
This document provides the following guidance that reminds and
clarifies the P-Served-User header field handling that are missing in
[RFC5502]:
o This header MUST NOT be repeated within a request for a particular
session at a particular time for the reason that session cases are
mutually exclusive. This document updates [RFC5502] to clearly
state that P-Served-User header field MUST NOT contain different
values either comma-separated or header-separated. This documents
also updates the syntax of the header from [RFC5502] to reflect
this uniqueness of parameters values.
o Whether the "regstate" parameter is removed or not by the S-CSCF o Whether the "regstate" parameter is removed or not by the S-CSCF
when processing the orginating after CDIV session case is out of when processing the orginating after CDIV session case is out of
the scope of this document. In one hand, it can either be the scope of this document. In one hand, it can either be
considered that the S-CSCF is able to store the previous regstate considered that the S-CSCF is able to store the previous regstate
value and that the same value applies or that the "regstate" is value and that the same value applies or that the "regstate" is
not relevant after a diverting service. On the other hand, the not relevant after a diverting service. On the other hand, the
regstate can be combined to the orig-cdiv session case to provide regstate can be combined to the orig-cdiv session case to provide
different services if the served user is registered or different services if the served user is registered or
unregistered. These choices are implementation dependent. unregistered. These choices are implementation dependent.
3. Applicability 5. Syntax
The use of the P-Served-User header field extensions is only
applicable inside a Trust Domain for P-Served-User. Nodes in such a
Trust Domain explicitly trust each other to convey the served user
and to be responsible for withholding that information outside of the
Trust Domain. The means by which the network determines the served
user and the policies that are executed for a specific served user is
outside the scope of this document.
4. Syntax
4.1. General 5.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 in a special way and that it has been identified errors in parameter in a special way and that it has been identified errors in
the syntax of the P-Served-User header field as defined in [RFC5502], the syntax of the P-Served-User header field [RFC5502], this document
this document corrects and extends the header at the same time. corrects and extends the header at the same time.
The extension of the sessioncase-param parameter to add the "orig- The extension of the sessioncase-param parameter to add the "orig-
cdiv" session case is done in a way to fit the parameter format cdiv" session case is done in a way to fit the parameter format
introduced in release 11 of the 3GPP [TS.3GPP.24.229] and keep a introduced in release 11 of the 3GPP [TS.3GPP.24.229] and keep a
backward compatibility. backward compatibility.
"EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic- "EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and "generic-
param" are defined in [RFC3261]. param" are defined in [RFC3261].
4.2. ABNF 5.2. ABNF
The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P- The augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P-
Served-User header field is described in [RFC5502]. 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 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 = 1("sescase" EQUAL 1("orig" / "term")/ orig-cdiv) sessioncase-param = "sescase" EQUAL ("orig"/"term")/ orig-cdiv
registration-state-param = "regstate" EQUAL 1("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
5. IANA Considerations 6. IANA Considerations
The syntax of the P-Served-User header field is defined in [RFC5502] The syntax of the P-Served-User header field [RFC5502] is updated in
and updated in Section 4 of this document. Section 4 of this document.
This document requests IANA to update the existing row for the P- This document requests IANA to update the existing row for the P-
Served-User header field in the "Header Fields" sub-registry: Served-User header field in the "Header Fields" sub-registry:
Header Name Compact Form Reference Header Name Compact Form Reference
------------- ------------ ---------------- ------------- ------------ ----------------
P-Served-User none [RFC5502][RFCXXXX] P-Served-User none [RFC5502][RFCXXXX]
Note to RFC Editor: Please replace XXXX with the RFC number of this document. 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 This document requests IANA to add new rows for the P-Served-User
header field parameters in the "Header Field Parameters and Parameter header field parameters in the "Header Field Parameters and Parameter
Values" sub-registry as per the registry created by [RFC3968]: Values" sub-registry as per the registry created by [RFC3968]:
Header Field Parameter Name Predefined Values Reference Header Field Parameter Name Predefined Values Reference
P-Served-User sescase Yes [RFC5502][RFCXXXX] -------------- ---------------- ----------------- -----------------
P-Served-User regstate Yes [RFC5502][RFCXXXX] P-Served-User sescase Yes [RFC5502][RFCXXXX]
P-Served-User orig-cdiv No [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. Note to RFC Editor: Please replace XXXX with the RFC number of this
document.
6. Call Flow Examples 7. Call Flow Examples
6.1. Call diversion case 7.1. Call diversion case
The following call flow shows a session establishement for Alice The following call flow shows a session establishement for Alice
calls Bob which has a call diversion when busy towards Carol. calls Bob which has a call diversion when busy towards Carol.
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 | |
| |-------------------------------->| | | |-------------------------------->| |
| | 486 F5 | | | | 486 F5 | |
| |<--------------------------------| | | |<--------------------------------| |
| | 486 F6 | | | | | 486 F6 | | |
skipping to change at page 9, line 41 skipping to change at page 10, line 4
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 call diversion service
6.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 | | | |
|--------------->| INVITE F2 | | | |--------------->| INVITE F2 | | |
| |--------------->| | | | |--------------->| | |
| | INVITE F3 | | | | | INVITE F3 | | |
| |<---------------| | | | |<---------------| | |
| | INVITE F4 | | | | | INVITE F4 | | |
| |--------------->| | | | |--------------->| | |
| | INVITE F5 | | | | | INVITE F5 | | |
| |<---------------| INVITE F6 | | | |<---------------| INVITE F6 | |
skipping to change at page 11, line 28 skipping to change at page 11, line 37
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
7. Security Considerations 8. 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, it is important to ensure that the
parameter has not been added to the SIP message by an unauthorized parameter has not been added to the SIP message by an unauthorized
SIP entity. SIP entity.
8. Acknowledgments 9. 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 also to Dale Worley for input, and comments on the document. Thanks to Dale Worley for his
his careful review of the document. A special thanks to Christer careful review of the document and to Paul Kyzivat. A special thanks
Holmberg. to Christer Holmberg.
9. References 10. References
9.1. Normative References 10.1. Normative References
[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 E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, 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>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session (IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, Initiation Protocol (SIP)", BCP 98, RFC 3968,
skipping to change at page 12, line 28 skipping to change at page 12, line 34
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
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>.
9.2. Informative References 10.2. Informative References
[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>.
[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 v11.
 End of changes. 42 change blocks. 
168 lines changed or deleted 170 lines changed or added

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