Note: Descriptions are shown in the official language in which they were submitted.
CA 02630678 2008-05-22
WO 2007/060074 PCT/EP2006/067789
1
Message Handling in an IP Multimedia Subsystem
Field of the Invention
The present invention relates to Session Initiation Protocol message handling
in
an IP Multimedia Subsystem (IMS), and in particular, though not necessarily,
to
a method and apparatus for handling Session Initiation Protocol messages
related to call forwarding at a Serving Call/Session Control Function within
the
IMS.
Background to the Invention
IP Multimedia services provide a dynamic combination of voice, video,
messaging, data, etc. within the same session. By growing the number of basic
applications and the media which it is possible to combine, the number of
services offered to the end users will grow, and the inter-personal
communication experience will be enriched. This will lead to a new generation
of personalised, rich multimedia communication services, including so-called
"combinational IP Multimedia" services which are considered in more detail
below.
IP Multimedia Subsystem (IMS) is the technology defined by the Third
Generation Partnership Project (3GPP) to provide IP Multimedia services over
mobile communication networks (3GPP TS 22.228, TS 23.218, TS 23.228, TS
24.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases
5 to 7. IMS provides key features to enrich the end-user person-to-person
communication experience through the use of standardised IMS Service
Enablers, which facilitate new rich person-to-person (client-to-client)
communication services as well as person-to-content (client-to-server)
services
over IP-based networks. The IMS makes use of the Session Initiation Protocol
(SIP) to set up and control calls or sessions between user terminals (or user
CA 02630678 2008-05-22
WO 2007/060074 PCT/EP2006/067789
2
terminals and application servers). The Session Description Protocol (SDP),
carried by SIP signalling, is used to describe and negotiate the media
components of the session. Whilst SIP was created as a user-to-user protocol,
IMS allows operators and service providers to control user access to services
and to charge users accordingly.
Figure 1 illustrates schematically how the IMS fits into the mobile network
architecture in the case of a GPRS/PS access network. Call/Session Control
Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP
architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is
the first point of contact within the IMS for a SIP terminal; the Serving CSCF
(S-
CSCF) which provides services to the user that the user is subscribed to; and
the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF
and to forward to that S-CSCF a request received from a SIP terminal via a P-
CSCF.
A user registers with the IMS using the specified SIP REGISTER method. This
is a mechanism for attaching to the IMS and announcing to the IMS the address
at which a SIP user identity can be reached. The user receives a unique URI
from the S-CSCF that it shall use when it initiates a dialog. In 3GPP, when a
SIP terminal performs a registration, the IMS authenticates the user, and
allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the
criteria for allocating S-CSCFs is not specified by 3GPP, these may include
load
sharing and service requirements. It is noted that the allocation of an S-CSCF
is key to controlling (and charging for) user access to IMS-based services.
Operators may provide a mechanism for preventing direct user-to-user SIP
sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to
select an
S-CSCF if one is not already selected. The I-CSCF receives the required S-
CSCF capabilities from the home network's Home Subscriber Server (HSS),
CA 02630678 2008-05-22
WO 2007/060074 PCT/EP2006/067789
3
and selects an appropriate S-CSCF based on the received capabilities. [It is
noted that S-CSCF allocation is also carried out for a user by the I-CSCF in
the
case where the user is called by another party, and the user is not currently
allocated an S-CSCF.] When a registered user subsequently sends a session
request (e.g. SIP INVITE) to the IMS, the request will include the P-CSCF and
S-CSCF URIs so that the P-CSCF is able to forward the request to the selected
S-CSCF. This applies both on the originating and terminating sides (of the
IMS). [For the terminating call the request will include the P-CSCF address
and
the UE address.]
Within the IMS service network, Application Servers (ASs) are provided for
implementing IMS service functionality. Application Servers provide services
to
end-users in an IMS system, and may be connected either as end-points over
the 3GPP defined Mr interface, or "linked in" by an S-CSCF over the 3GPP
defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are
used by
an S-CSCF to determine which Applications Servers should be "linked in"
during a SIP Session establishment. Different IFCs may be applied to different
call cases. The IFCs are received by the S-CSCF from an HSS during the IMS
registration procedure as part of a user's User Profile. Certain Application
Servers will perform actions dependent upon subscriber identities (either the
called or calling subscriber, whichever is "owned" by the network controlling
the
Application Server). For example, in the case of call forwarding, the
appropriate
(terminating) application server will determine the new terminating party to
which a call to a given subscriber will be forwarded.
The working group known as ETSI TISPAN is developing the use of IMS for
fixed broadband accesses. One of their tasks is to develop supplementary
services based upon the IMS defined by 3GPP. These supplementary services
will be defined in separate specifications although they will impact upon core
specifications such as T524.229. Figure 2 illustrates schematically the
message flow within the IMS for a SIP INVITE, on the call originating side,
CA 02630678 2008-05-22
WO 2007/060074 PCT/EP2006/067789
4
according to TS24.229 (chapter 5.4.3.2). At step 1), the INVITE is sent from
the
originating User Equipment (UE) to the P-CSCF. This INVITE includes in its
header a so-called P-Preferred identity, as well as including the URI of the P-
CSCF at the topmost level of the SIP route header and the URI of the S-CSCF
as the second entry. The UE also includes the identity of the communicating
partner in the Request-URI. Upon receipt of the INVITE, the P-CSCF checks
that the originating UE is allowed to use the identity included as the P-
Preferred
identity, and if so includes it as the P-Asserted Identity in the outgoing
INVITE.
The P-Asserted Identity is an identity that is used among trusted SIP
entities,
typically intermediaries, to carry the identity of the user sending a SIP
message
as it was verified by authentication. The P-CSCF identifies the S-CSCF
allocated to the originating UE by looking in the Route Header, and at step 2)
forwards the amended INVITE to that S-CSCF.
The S-CSCF handles the call according to an originating call case procedure.
The S-CSCF uses the P-Asserted Identity to check whether any relevant
restrictions have been placed on the originating UE, e.g. is the UE barred
from
using the requested service. The S-CSCF also uses the P-Asserted Identity
and call case to determine the IFCs for the UE. In the example of Figure 2, it
is
assumed that the IFCs require that the S-CSCF forward (step 3)) the INVITE to
a particular AS. The S-CSCF includes at the topmost level of the SIP route
header the URI of the AS. It also includes in the subsequent level its own
URI,
together with an Original Dialog Identifier (ODI). The ODI is generated by the
S-CSCF and uniquely identifies the call to the S-CSCF. The AS will itself
perform authentication based upon the P-Asserted Identity contained in the
message (the originating case). The appropriate case is identified to the AS
by
the S-CSCF (e.g. by sending the message to an appropriate port of the AS).
When the AS returns the INVITE (step 4)) to the S-CSCF, the AS strips the URI
of the AS from the route header, leaving the URI of the S-CSCF together with
the ODI tag. The ODI tag allows the S-CSCF to determine that the INVITE
relates to an earlier dialogue.
CA 02630678 2008-05-22
WO 2007/060074 PCT/EP2006/067789
It is possible for the AS logic to require the setting up of a new session, in
which
case it would be necessary to provide a mechanism which allows the AS to
replace the original R-URI with the URI of the new terminating User (the
existing
5 TSs do not as yet provide for this re-routing scenario). In this case,
the identity
of the origin, i.e. the P-Asserted Identity of the INVITE at step 4), can be
either
the identity of the originating UE, the identity of the AS, or an identity of
a third
party on whose behalf the AS is setting up the new session. In this case, the
S-
CSCF will repeat the call restriction check and determine the IFCs based upon
the P-Asserted Identity contained in the "new" INVITE, assuming that the
originating case is used. However, it is possible that the AS may signal to
the
S-CSCF that the terminating case is to be used, in which case the checks are
carried out using the R-URI of the INVITE. Assuming that no further ASs are to
be linked-in based upon the IFCs, the S-CSCF forwards the INVITE to the
Request URI (R-URI) contained in the INVITE. This may be the R-URI
contained in the original INVITE, or a new R-URI contained in the new INVITE
if
that is different.
Figure 3 illustrates schematically the message flow within the IMS for a SIP
INVITE, on the call terminating side (T524.229: chapter 5.4.3.3). At step 1),
the
INVITE arrives from the I-SCSF (not shown) including the R-URI indicating the
called party. The S-CSCF uses this R-URI to check for restrictions placed on
the called party, and to obtain the IFCs. In this case, the IFCs do not
indicate
that an AS needs to be contacted. The S-CSCF will acquire the preloaded
Route Headers for the called party, based on the R-URI, and send the INVITE
forward to be UE based on these Route Header entries. The INVITE is
received by the P-CSCF in accordance with the preloaded route in the S-CSCF,
and the P-CSCF sends the INVITE to the UE in accordance with the contact
header.
CA 02630678 2013-01-08
6
SUMMARY OF THE INVENTION
It is an object of the present invention to overcome the problems identified
above, whilst avoiding the need to change the P-Asserted Identity contained
within a SIP message. This and other objects are achieved by introducing a
new header into SIP messages at the S-CSCF prior to forwarding to an
Application Server, the new header containing the URI of the User that is
served by the S-CSCF and to which the message relates.
According to a first aspect of the present invention there is provided a
method
of handling a Session Initiation Protocol communication within an IP
Multimedia Subsystem, the method comprising:
receiving a Session Initiation Protocol message at a Serving Call/State
Control Function serving a User identified by a R-URI of the message;
at the Serving Call/State Control Function, adding to the message a
further header, this header explicitly identifying the URI of the User served
by
the Serving Call/State Control Function;
forwarding the message to an Application Server; and
at the Application Server, handling the message on the basis of criteria
defined for the User identified in said further header
Said step of handling the message at the Application Server may includes
changing the R-URI in the message to a URI of a User to which the message
is to be re-routed, and returning the message to the Serving Call/State
Control
Function.
Said message may be forwarded directly to said Application Server by the S-
CSCF, or subsequent to exchanges of the message between the S-CSCF and
one or more other Application Servers. The earlier exchanges may introduce
modifications to the message headers.
Said step of handling the message on the basis of criteria defined for the
User
identified in said further header may comprise obtaining re-routing criteria
for
the User identified in said further header.
CA 02630678 2013-01-08
7
Preferably, the method further comprises receiving the message at the S-
CSCF and identifying the original R-URI on the basis of the Original Dialog
Identifier contained in the returned message, and determining IFCs for the
served User on the basis of that R-URI. Alternatively, in the event that the
returned message contains said further header, the S-CSCF may determine
the IFCs based upon the User identified in the further header.
Whilst the invention is applicable to any process (i.e. Application Server)
that
handles re-routing of a message, a particular application is that of SIP call
forwarding.
Said further header is identified by a header identifier which is understood
by
both the S-CSCF and the AS. Typically, this header is a prefix, e.g. "P-
Served-User-Identity".
Preferably, the P-Asserted Identity is the same in both the message initially
received at the S-CSCF and the message returned from the Application
server to the S-CSCF, this identity identifying the originating User.
Said step of handling the message received at the Application Server may
comprise handling the message according to one of an originating or
terminating case, the appropriate case being identified in the message
received at the Application Server from the S-CSCF, for example in said
further header.
Said step of authenticating the served User at the S-CSCF may comprise
handling the message according to one of an originating or terminating case,
the appropriate case being identified in the message received by the S-CSCF
from the Application Server.
According to a second aspect of the present invention there is provided a
Session Initiation Protocol Application Server of an IP Multimedia Subsystem
having processing means for handling a message received from a Serving
Call/State Control Function, the means being arranged to handle the message
CA 02630678 2013-01-08
8
based upon a header of the message containing the URI of the served user,
this header having been introduced by the Serving Call/State Control Function
and being other than the P-Asserted Identity and the R-URI.
According to a third aspect of the present invention there is provided a
Serving Call/State Control Function node of an IP Multimedia Subsystem, the
Serving Call/State Control Function node comprising means for receiving a
SIP message and for applying Initial Filter Criteria to the message, and, in
the
event that the Initial Filter Criteria require forwarding of the message to an
Application Server, for adding a header to the forwarded message containing
an identity of a served User to which the message relates.
According to a further aspect of the present invention there is provided
computer program code for carrying out the method of the first aspect of the
invention.
The invention is applicable in particular to Session Initiation Protocol
initial
request messages, e.g. INVITE, and to standalone Session Initiation Protocol
messages, e.g. messages relating to presence services.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates schematically the integration of an IP Multimedia Subsystem
into a 3G mobile communications system;
FIG. 2 illustrates the flow of a SIP INVITE on the originating call side of
the
IMS;
FIG. 3 illustrates the flow of a SIP INVITE on the terminating call side of
the
IMS; and
FIG. 4 illustrates the flow of a SIP INVITE in a call forwarding scenario
within
the IMS;
FIG. 5 shows the message header structure for a SIP INVITE message sent
from an S-CSCF to an Application Server;
FIG. 6 shows the message header structure for a SIP INVITE message sent
from an Application Server to an S-CSCF;
CA 02630678 2013-01-08
9
FIG. 7 shows the message header structure for a SIP INVITE message sent
from an S-CSCF to a second Application Server; and
FIG. 8 illustrates a signalling exchange between IMS entities involving the
message structure of FIG. 7.
DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS
FIG. 4 illustrates an alternative INVITE message flow scenario, where a call
from an originating terminal (UE-0) to a peer terminal (UE-F) is forwarded to
a
terminating terminal (UE-T). The call forwarding action is performed by an
Application Server (AS-F). The call flow is as follows:
1) The INVITE is sent from UE-Cr addressed to UE-F (R-URI). The S-CSCF
performs the originating side call procedure as described with reference to
FIG. 2.
2) After interaction with the AS-0 (no change is made to the R-URI at this
stage) the S-CSCF 0 sends the INVITE to the I-CSCF (not shown) of UE-F's
home network. The I-CSCF will acquire the address of the S-CSCF where the
UE-F is registered from the HSS. The INVITE is sent to that S-CSCF, i.e. to S-
CSCF F. The S-CSCF F will check the restriction requirement and obtain the
IFCs as described above (for the terminating side case) with reference to FIG.
3, i.e. based on the R-URI contained in the INVITE. In the scenario
illustrated
in FIG. 4, the INVITE will be sent to the AS-F where the call forwarding is
activated.
3) The AS-F will authorise the process based upon the R-URI (assuming the
terminating case),
4) The AS-F will then change the R-URI in the INVITE header from that of UE-
F to that of UE-T. The modified INVITE will be returned to the S-CSCF F.
5) The S-CSCF F will send the INVITE to the I-CSCF of the UE-T network,
and the I-CSCF (not shown) will interrogate the HSS to get the address of the
S-CSCF T of UE-T, and forward the INVITE to the S-CSCF T.
CA 02630678 2013-01-08
6) The S-CSCF T will perform the terminating procedure as described with
reference to FIG. 3, on the basis of the R-URI contained in the INVITE (that
is
the R-URI of UE-T).
5
Referring again to FIG. 4, at step 5), it will additionally be necessary for
the S-
CSCF F to check whether there are any restrictions on the forwarding User,
UE-F. To do this, the S-CSCF will typically use the originating side procedure
of FIG. 2. However, in the absence of any special procedures implemented by
10 the AS-F, the INVITE returned to the S-CSCF F by the AS-F will include
in the
P-Asserted Identity field the identity of the UE-0. If the S-CSCF F were to
perform an originating side check on the INVITE using the P-Asserted Identity,
the S-CSCF F will be unable to locate a record for this identity as it does
not
"belong" to the S-CSCF F (rather it belongs to the S-CSCF 0).
A solution to this problem might be for the AS-F to replace the P-Asserted
Identity of UE-0 with that of UE-F. However, this is unlikely to be accepted
by
operators who will prefer to leave the P-Asserted Identity unchanged from
end-to-end. From the operators' point of view, the P-Asserted Identity field
is
akin to the traditional (PSTN) calling line identity. Other solutions to this
problem must therefore be sought.
Whilst the forwarding user will typically be considered as an originating User
in the call forwarding scenario, this need not be the case, and may be
considered as a terminating User. In this case, when the S-CSCF F receives
the INVITE from the AS-F, the S-CSCF will want to perform a terminating side
check on the INVITE. (The message sent from the AS-F to the S-CSCF will
contain a parameter to indicate to the S-CSCF whether the message is to be
handled according to the terminating case or the originating case.) However,
this check will also fail as the R-URI contained in the INVITE identifies the
UE-
T, and that R-URI belongs to the S-CSCF T rather than to the S-CSCF F.
Changing the P-Asserted Identity will of course not address this problem.
These problems arise with messages other than INVITE, including, for
CA 02630678 2013-01-08
example, other initial request messages and standalone messages.
The problems involved in handling a "forwarding" scenario within the IP
Multimedia Subsystem have been described above. It is desirable to be able
to provide a mechanism for handling call forwarding which allows both the
Application Server (AS) and the S-CSCF to authorise, check restriction
requirements, and/or determine IFCs for the appropriate user, i.e. that user
which is served by the S-CSCF, and which deals both with the terminating
case and the originating case to ensure appropriate flexibility.
Consider now an INVITE arriving at the S-CSCF F from some originating user
(UE-0). The INVITE will include in its header a R-URI pointing to one of S-
CSCF F's registered users (UE-F), namely userf public1@home2.net. The
INVITE also includes the P-Asserted Identity of the originating user, namely
"John Doe" <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>. The S-
CSCF handles this message using the terminating case (identified by the
message being received at a particular port number in the absence of a
specific indication within the message), and hence will obtain the appropriate
IFCs based upon the R-URI of the message. One of these IFCs will indicate
that the message should be forwarded to an Application Server.
CA 02630678 2008-05-22
WO 2007/060074 PCT/EP2006/067789
12
Upon determining that the message is to be forwarded to an Application Server,
the S-CSCF will add an additional header to the INVITE. This header is
referred to here as the "P-Served-User-Identity", and contains the identity,
SIP-
S URI, or TEL URL of the user that is served by the S-CSCF and of which the
S-
CSCF has knowledge. The header also contains the call case which should be
applied by the Application Server. Example headers are as follows:
P-Served-User-ldentity: sip:alice@home1.net;orig
P-Served-User-ldentity: sip:bob@home2.net;termunreg
P-Served-User-ldentity: sip:bob@home2.net;termreg
Typically, in the case of call forwarding, the originating case will be
applied.
The P-Served-User-Identity header will always be added to the message,
regardless of the Application Server to which the message is to be forwarded.
The S-CSCF will also perform the standard operations of adding the SIP URI of
the AS as the topmost URI of the route header, i.e. sip:asl .homel .net;lr,
and
including its own SIP URI beneath the AS URI in the route header together with
the "original dialog identifier" (0D1). The resulting exemplary INVITE message
structure is shown in Figure 5, where the URI of the S-CSCF F added to the
route header is "scscfl .homel .net;Ir" and
the ODI is
"cb03a0s09a2sdfglkj490333". The message is then forwarded to the
Application Server over the ISC interface. The S-CSCF F maintains state
information for the session to which the INVITE relates. This information
includes the ODI and the identity of the served User F.
Upon receipt of the INVITE message from the S-CSCF, the Application Server
will always perform authorisation based upon the P-Served-User-Identity,
according to the case (originating or terminating) identified in the message.
In
the case that call forwarding is to be performed, based upon the R-URI
contained in the INVITE, the Application Server will replace the original R-
URI
with the URI of the User to which the call is to be forwarded (UE-T). In
addition,
CA 02630678 2008-05-22
WO 2007/060074 PCT/EP2006/067789
13
the Application Server will add the "orig" parameter in the route header to
indicate that the INVITE is to be dealt with using the originating call type
procedure. The topmost routing header, i.e. the URI of the Application Server,
is stripped from the message, and the message sent back to the S-CSCF. The
returned message retains the P-Served-User-Identity header.
The default operation of the S-CSCF when receiving a message containing a P-
Served-User-Identity header is to perform the IFC check based upon the served
User contained in the session state information corresponding to the ODI of
the
received message. (Whilst the User identity contained in the P-Served-User-
Identity header could be used for this purpose, it is preferable to avoid
changing
the existing procedures as much as possible). The S-CSCF will apply the
terminating or originating case in dependence upon the case identified in the
route header (or based upon the port number at which the INVITE is received
from the AS). Typically, a forwarded INVITE will be handled according to the
originating call type. (In this example, the case contained in the P-Served-
User-
Identity header is not used by the S-CSCF, although this is possible.)
In the absence of an ODI in a message received over the ISC, the S-CSCF will
perform the necessary checks based upon either the P-Asserted Identity or the
R-URI.
Following completion of the IFC check, the S-CSCF will process the INVITE
according to the identified IFCs. This may involve forwarding the message
directly to the terminating User UE-T, or possibly forwarding it to a further
Application Server.
In some cases, the IFC check carried out at the S-CSCF in response to receipt
of a SIP message (INVITE) over the ISC interface may require that the
message be forwarded to a further Application Server. An example message
forwarded to a second AS is illustrated in Figure 7. Again, the P-Served-User-
CA 02630678 2008-05-22
WO 2007/060074 PCT/EP2006/067789
14
Identity header contains the URI of User F, namely userf public1@home2.net,
whilst the P-Asserted Identity is that of the originating User and the R-URI
is
that of the new terminating User. Figure 8 illustrates the message exchange
between the S-CSCF F and two AS servers, AS-F 1 and AS-F 2.
It will be appreciated by the person of skill in the art that various
modifications
may be made to the embodiments described above without departing from the
scope of the present invention.
