A P-Served-User Header Field
Parameter for Originating CDIV session case in Session Initiation Protocol
(SIP)OrangeOrange Gardens, 44 avenue de la RépubliqueChatillon92326Francemarianne.mohali@orange.com
Transport
RFC5502P-3GPPIMSServed-Userorig-cdiv
This specification defines a new parameter of the P-Served-User header
field in the Session Initiation Protocol (SIP). This new "orig-cdiv"
parameter defines the session case used by a proxy when handling an
originating session after Call Diversion (CDIV) services has been
invoked for the served user.
The P-Served-User header field is defined in RFC5502 to convey the
identity of the served user and the session case that applies to this
particular communication session and application invocation.
This document updates RFC5502 to add the "originating after CDIV"
session case and to provide more guidance for using the P-Served-User
header field in IP networks that were missing in RFC5502.
The P-Served-User header field was defined in
to address an issue that was found in the 3rd Generation Partnership
Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF
(Serving Call Session Control Function) and an AS (Application Server)
on the ISC (IMS Service Control) interface. For more information on
the IMS, a detailed description can be found in
.
This header field conveys the identity of the served user, his/her
registration state and the session case that applies to this
particular communication session and application invocation.
defines the originating and terminating
session cases for a registered or unregistered user.
This document extends the P-Served-User header field to include the
session case for a forwarded leg when a call diversion service (CDIV)
has been invoked and if an originating service of the diverting user
has to be triggered.
The sessioncase-param parameter of the P-Served-User header field is
extended with the "orig-cdiv" parameter for this "originating after
CDIV" session case.
The following section defines usage of the "orig-cdiv" parameter of
P-Served-User header field, Section 2 specifies the proxy behavior for
handling the new header field parameter, and Section 3 discusses the
applicability and scope of this new header field parameter. Section 4
describes the syntax and correct the syntax of , Section 5 registers the P-Served-User header field
parameters with IANA, and Section 6 discusses the security properties
of the environment where this new header field parameter is intended
to be used.
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 terminating session states for users allocated to it.
This means 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 allocated to that user.
At the moment that an S-CSCF is allocated for a specific user, the
user profile is downloaded to the S-CSCF from the HSS (Home Subscriber
Server), see .
To be able to determine which responsibilities the S-CSCF and the
Application Server have to perform and on which user's behalf, it is
necessary to know who is the current served user, what is his/her
"registration state" and on which "session case" is the session.
defines all those parameters and in
particular the originating and terminating session cases.
In the case of a call diversion service, the received request is first
considered as a terminating session case and the terminating filter
criteria configured in the S-CSCF are performed. Receiving the call
initiation request, the Application Server is able to determine the
served user and the session case (here "term") from the received
P-Served-User header field content and to execute terminating
services. When the call diversion service is executed (as a
terminating service), the Application Server changes the target
(Request-URI) of the session and a new call leg is created.
This new call leg could be considered as an originating call leg from
the diverting user but this is not the case. Indeed, the originating
user remains the same and some of the diverting user's originating
services should not be triggered as if it was an originating call. For
instance, the originating user identity should not be restricted
because the diverting user has a privacy service for his/her own
identity. The privacy of the diverting user should apply to
information related to this user (eg. in the Histroy-Info header
field). In the same manner, some specific services will need to be
specifically triggered on the outgoing leg after a call diversion.
Without a dedicated session case for originating after CDIV, there is
no possiblity for a proxy to trigger an originating service for the
diverting user or for an Application Server to execute the procedures
for this particular session case.
For this use case, this document creates a new parameter for the
originating after CDIV session case to be embedded in the
P-Served-User header field.
The "orig-cdiv" header field parameter can be used inside a trust
domain of the P-Served-User header field by proxies that are
processing call diversion services. The following section illustrates
how this header field parameter can be used in a 3GPP network.
For a terminating call, when receiving the initial INVITE request, the
S-CSCF will determine that the session case is for a terminating user
as described in , 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
request has to be diverted to another target user or application. 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)
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
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
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.
When the Application Server 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).
This document also provides the following guidance that reminds or
clarifies the P-Served-User handling that are missing in :
This header is forbidden to 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
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 as defined in
to reflect this uniqueness of parameters
values.
Whether the "regstate" parameter is removed or not by the S-CSCF
when processing the orginating after CDIV session case is out of
the scope of this document. In one hand, it can either be
considered that the S-CSCF is able to store the previous regstate
value and that the same value applies or that the "regstate" is
not relevant after a diverting service. On the other hand, the
regstate can be combined to the orig-cdiv session case to provide
different services if the served user is registered or
unregistered. These choices are implementation dependent.
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.
defines the P-Served-User header field with
the sessioncase-param parameter "sescase" which is specified as having
"orig" and "term" predefined values. This document defines an
additional parameter for the sessioncase-param: "orig-cdiv".
Because this document extends the existing sessioncase-param 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 ,
this document corrects and extends the header at the same time.
The extension of the sessioncase-param parameter to add the
"orig-cdiv" session case is done in a way to fit the parameter format
introduced in release 11 of the 3GPP
and keep a backward compatibility.
"EQUAL", "HCOLON", "SEMI", "name-addr", "addr-spec", and
"generic-param" are defined in .
The augmented Backus-Naur Form (ABNF)
syntax of the P-Served-User header field is described in .
This document updates to correct the
P-Served-User header field ABNF syntax and extend it as following:
Examples of possible P-Served-User header field:
The syntax of the P-Served-User header field is defined in and 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:
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 as per the registry created by :
The security considerations in apply.
As the "orig-cdiv" parameter of P-Served-User header field can be
used to trigger applications, it is important to ensure that the
parameter has not been added to the SIP message by an unauthorized SIP
entity.
The author wishes to thank the 3GPP community for providing guidance,
input, and comments on the document. Thanks also to Dale Worley for his
careful review of the document.
IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol
(SDP);Stage 33GPPIP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling
flows and message contents3GPP