U.S. patent application number 14/286516 was filed with the patent office on 2014-09-11 for message handling in an ip multimedia subsystem.
This patent application is currently assigned to Telefonaktiebolaget L M Ericsson (pubI). The applicant listed for this patent is Telefonaktiebolaget L M Ericsson (pubI). Invention is credited to Johannes Van Elburg.
Application Number | 20140254599 14/286516 |
Document ID | / |
Family ID | 40568258 |
Filed Date | 2014-09-11 |
United States Patent
Application |
20140254599 |
Kind Code |
A1 |
Van Elburg; Johannes |
September 11, 2014 |
Message Handling in an IP Multimedia Subsystem
Abstract
A method and apparatus for handling a Session initiation
Protocol communication in an IP Multimedia Subsystem (IMS) network.
A Proxy Call Session Control Function receives a Session Initiation
Protocol message sent from a trusted remote network. The P-CSCF
adds to the message a further header, which identifies a Public
User Identity of a trusted entity located in the remote network
served by a Serving Call Session Control Function in the IMS
network. The message is then sent to the S-CSCF. The S-CSCF, and
any other node that the message is sent to, knows from the presence
of the further header to use the Public User Identity of the
trusted entity to determine the served user rather than the
P-Asserted Identity contained in the SIP message.
Inventors: |
Van Elburg; Johannes;
(Oosterhout, NL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Telefonaktiebolaget L M Ericsson (pubI) |
Stockholm |
|
SE |
|
|
Assignee: |
Telefonaktiebolaget L M Ericsson
(pubI)
Stockholm
SE
|
Family ID: |
40568258 |
Appl. No.: |
14/286516 |
Filed: |
May 23, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12812266 |
Aug 2, 2010 |
8762553 |
|
|
PCT/EP2008/050305 |
Jan 11, 2008 |
|
|
|
14286516 |
|
|
|
|
Current U.S.
Class: |
370/392 |
Current CPC
Class: |
H04L 69/22 20130101;
H04L 65/1016 20130101; H04L 67/14 20130101; H04L 67/147 20130101;
H04L 65/1006 20130101; H04W 84/042 20130101; H04L 63/08 20130101;
H04L 49/25 20130101 |
Class at
Publication: |
370/392 |
International
Class: |
H04L 12/947 20060101
H04L012/947; H04L 29/06 20060101 H04L029/06 |
Claims
1. A method of handling a Session Initiation Protocol communication
within an IP Multimedia Subsystem network, the method comprising:
at a Proxy Call Session Control Function, receiving a Session
Initiation Protocol message sent from a remote network; at the
Proxy Call Session Control Function, adding to the message a
further header, the further header identifying a Public User
Identity of a trusted entity in the remote network served by a
Serving Call Session Control Function; and sending the message to
the Serving Call Session Control Function.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation application of U.S.
application Ser. No. 12/812,266, which is the National Stage of
International Application No. PCT/EP2008/050305, filed Jan. 11,
2008. Each of the '266 and '305 applications are expressly
incorporated herein by reference in their entirety.
TECHNICAL FIELD
[0002] The present invention relates to Session Initiation Protocol
message handling in a communications network.
BACKGROUND
[0003] 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). IMS provides key features to enrich the end-user
person-to-person communication experience through the integration
and interaction of services. IMS allows new rich person-to-person
(client-to-client) as well as person-to-content (client-to-server)
communications over an IP-based network.
[0004] The IMS makes use of the Session Initiation Protocol (SIP)
to set up and control calls or sessions between user terminals
(UEs) or between UEs and application servers (ASs). 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.
[0005] Within an IMS network, Call/Session Control Functions
(CSCFs) operate as SIP entities 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.
[0006] IMS service functionality is implemented using application
servers (ASs). For any given UE, one or more ASs may be associated
with that terminal. ASs communicate with an S-CSCF via the IMS
Service Control (ISC) interface and are linked into a SIP messaging
route as required (e.g. as a result of the triggering of iFCs
downloaded into the S-CSCF for a given UE).
[0007] A user registers in the IMS using the specified SIP REGISTER
method. This is a mechanism for attaching to the IMS and announcing
to the IMS the address giving the location at which a SIP user
identity can be reached. In 3GPP, when a SIP terminal performs a
registration, the IMS authenticates the user using subscription
information stored in a Home Subscriber Server (HSS), and allocates
an S-CSCF to that user from the set of available S-CSCFs. Whilst
the criteria for allocating S-CSCFs are 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
that would otherwise bypass the S-CSCF.
[0008] During the registration process, it is the responsibility of
the I-CSCF to select an S-CSCF, if an S-CSCF is not already
selected. The I-CSCF receives the required S-CSCF capabilities from
the HSS, and selects an appropriate S-CSCF based on the received
capabilities. It is noted that S-CSCF allocation is also carried
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 to the
IMS, the P-CSCF is able to forward the request to the selected
S-CSCF based on information received from the S-CSCF during the
registration process.
[0009] Every IMS user possesses one or more Private User
Identities. A Private User Identity is assigned by the home network
operator and is used by the IMS, for example for registration,
authorisation, administration, and accounting purposes. This
identity takes the form of a Network Access Identifier (NAI) as
defined in IETF RFC 2486. It is possible for a representation of
the International Mobile Subscriber identity (IMSI) to be contained
within the NAI for the private identity. 3GPP TS 23.228 specifies
the following properties of the Private User identity: [0010] The
Private User Identity is not used for routing of SIP messages.
[0011] The Private User Identity is contained in all Registration
requests, (including Re-registration and De-registration requests)
passed from the UE to the home network. [0012] An IP multimedia
Services Identity Module (ISIM) application securely stores one
Private User Identity. It is not possible for the UE to modify the
Private User Identity information stored on the ISIM application.
[0013] The Private User Identity is a unique global identity
defined by the Home Network Operator, which may be used within the
home network to identify the user's subscription (e.g. IM service
capability) from a network perspective. The Private User Identity
identifies the subscription, not the user. [0014] The Private User
Identity is permanently allocated to a user's subscription (it is
not a dynamic identity), and is valid for the duration of the
user's subscription with the home network. [0015] The Private User
Identity is used to identify the user's information (for example
authentication information) stored within the HSS (for use for
example during Registration). [0016] The Private User Identity may
be present in charging records based on operator policies. [0017]
The Private User Identity is authenticated only during registration
of the user, (including re-registration and de-registration).
[0018] The S-CSCF needs to obtain and store the Private User
Identity upon registration and unregistered termination.
[0019] In addition to a Private User Identity, every IMS user has
one or more IMS Public User Identities (PUIs). The PUIs are used by
any user to request communications to other users. A user might for
example include a PUI (but not a Private User Identity) on a
business card. 3GPP TS 23.228 specifies the following properties of
the PUI: [0020] Both telecom numbering and Internet naming schemes
can be used to address users depending on the PUIs that the users
have. [0021] The PUI(s) take the form of a SIP URI (as defined in
RFC 3261 and RFC 2396 or the "tel:"-URI format defined in RFC 3966.
[0022] An ISIM application securely stores at least one PUI (it
shall not be possible for the UE to modify the PUI), but it is not
required that all additional PUIs be stored on the ISIM
application. [0023] A PUI is registered either explicitly or
implicitly before the identity can be used to originate IMS
sessions and IMS session unrelated procedures. [0024] A PUI is
registered either explicitly or implicitly before terminating IMS
sessions and terminating IMS session unrelated procedures can be
delivered to the UE of the user that the PUI belongs to. [0025] It
is possible to register globally (i.e. through one single UE
request) a user that has more than one PUI via a mechanism within
the IMS (e.g. by using an Implicit Registration Set). This does not
preclude the user from registering individually some of his/her
PUIs if needed. [0026] PUIs are not authenticated by the network
during registration. [0027] PUIs may be used to identify the user's
information within the HSS (for example during mobile terminated
session set-up). [0028] PUIs may be used by ASs within the IMS to
identify service configuration data to be applied to a user.
[0029] FIG. 1 illustrates schematically example relationships
between a user (IMS) subscription and the Public and Private User
Identities. In the example shown, a subscriber has two Private User
Identities, with both being associated with two Public User
Identities (one of the Public User Identities, Public User
Identities-2, being associated with both Private User Identities).
A Service Profile is associated with each Public User Identity,
this profile specifying service data for the associated Public User
Identities. A Service Profile is created or modified when an
application server is provisioned for a user at the Home Subscriber
Server. Each Service Profile comprises one or more initial Filter
Criteria (iFCs), which are used to trigger the provision, or
restriction, of IMS services. The differences between services
offered by Service Profile-1 and Service Profile-2 are operator
specific, but may involve different application servers (ASs), and
even different charging/rating schemes.
[0030] In the example shown in FIG. 1, Public User Identity-1 is
associated with a Service Profile-1, whilst Public User Identity-2
and Public User Identity-3 are associated with Service Profile-2.
In a typical scenario, the Public User Identity-1 might be an
identity that the user gives to friends and family, e.g.
"Big_Joe@priv.operator.com", whilst Public User Identity-2 and
Public User Identity-3 might be identities that the user gives to
business contacts, e.g. "+46111222333@operatorcom" and
"joe.black@operator.com".
[0031] 3GPP defines a so-called "Implicit Registration Set" concept
to identify a set of PUIs that work as a group, and which are
registered and deregistered together when any one of the PUIs of
the set is registered or deregistered. 3GPP requires that the HSS
sends the implicit Registration Set to the S-CSCF upon registration
of a user or upon terminating a call. It has been understood that,
at registration, the HSS identifies all PUIs within the Implicit
Registration Set, and then identifies all of the Service Profiles
associated with these PUIs. The Service Profiles (or selected data
from the Service Profiles) containing the PUIs with which they are
associated are then sent to the S-CSCF. As a result of this
operation, the S-CSCF knows all of the PUIs that belong to the same
Implicit Registration Set, as well as their Service Profiles.
[0032] A possible use case of the IMS involves a collection of
users having a group level subscription to the IMS, but where the
individual users themselves have no subscription and of which the
IMS is unaware. It is desirable to allow direct inward and outward
dialling to the users. This might arise, for example, in the case
of a company having a subscription to the IMS and having individual
employee stations or terminals attached to an IP private branch
exchange (IP-PBX). The employee terminals may or may not be
provided with SIP clients. In the latter case, the IP-PBX performs
a translation between SIP and non-SIP signalling. Whilst it might
of course be possible for the IMS to record an individual PUI for
each terminal (within the same Implicit Registration Set), this
becomes inefficient as the group size becomes large. ETSI TISPAN
defines such a corporate network as a Next Generation Corporate
Network (NGCN).
[0033] It is possible to include within the Implicit Registration
Set associated with a subscription, a wildcarded Public User
Identity. "Wildcarded" or "wildcard" is understood here to mean a
Public User Identity that contains a symbol or symbol that stands
for one or more unspecified characters. The wildcarded Public User
Identity has a service profile associated with it. Any node within
the IP Multimedia Subsystem which performs checks or processing
based upon the Implicit Registration Set, acts upon a received
Public User Identity matching a wildcarded Public User Identity in
the same way as if the received Public User Identity matched any
standard Public User Identity within the Implicit Registration Set.
Rather than representing a range of Public User identities using a
wildcarded Public User Identity, such a range may instead be
represented by a sub-domain. For example, a range of Tel URIs may
be represented by a dialing prefix, whilst a range of SIP URIs may
be represented by a corporate domain. This allows routing to and
from corporate network users when the corporate network is
connected to an IMS network over the Gm reference point.
[0034] However, there is a requirement in the TISPAN published
specification for Business Communication Requirements (ETSI TS 181
019 (V2.0.0). Telecommunications and Internet converged Services
and Protocols for Advanced Networking (TISPAN); Business
Communication Requirements)] that expresses that the operator's
trust domain should be able to be extended into the corporate
network domain where a business trunk between an IMS network and a
trusted corporate network is in place. An implication of this is
that the P-CSCF in the IMS network must accept a
P-Asserted-Identity header sent from the corporate network over the
Gm reference point. The P-Asserted-Identity header is a header in a
SIP message that contains a SIP URI and an optional display-name.
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-Asserted-Identity is inserted into the header
field of a SIP message by a SIP entity once the node has
authenticated the originating user in some way. A consequence of
this is that the P-Asserted-Identity may not represent the
originating served user of the IMS network, as the
P-Asserted-Identity contains an identity that is authenticated by
the remote/corporate/private network.
[0035] The S-CSCF normally 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 Initial Filter Criteria (IFCs) for the UE.
Assuming, for example, that the IFCs require that the S-CSCF
forward 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. It can be concluded from this that the
P-Asserted-Identity is used in an originating IMS network to
determine the served user, for the network to be able to execute
the right policies/services for this user.
[0036] As described above, when the trust domain is extended from a
public IMS network into another network connected over a Gm
reference point, the P-Asserted-Identity can contain a user
identity not known in the IMS network. However, a problem arises
because the P-Asserted-Identity is also used by originating IMS
core systems to determine the served user. When forwarding a
message containing a P-Asserted-Identity of a user that does not
represent the user currently served by a P-CSCF, and in some cases
a P-Asserted-Identity that is not the identity of a known IMS user,
the current procedures would either fail, procedures would be
executed for the wrong user, or the P-CSCF would drop the
P-Asserted-Identity belonging to a different user.
SUMMARY
[0037] The inventor has devised a method to allow an IMS network to
extend its trust domain to another network. A P-CSCF in the IMS
network, after receiving a SIP message from the trusted company
domain, inserts a new header, termed a P-Served-User header, in the
SIP message before sending the SIP message to an S-CSCF. Optionally
the P-CSCF only inserts the new header when the P-Asserted-Identity
in the SIP message does not match an identity of an implicit
Registration set belonging to the trusted entity. The P-Served-User
header includes the identity of the served user. The identity of
the served user is a default identity belonging to the trusted
network site through which the SIP message entered the IMS network.
An S-CSCF that subsequently receives the SIP message is then aware
that it must use the P-Served-User header field to determine the
served user and it can ignore a P-Asserted-Identity header field
for the purpose of determining the served user.
[0038] According to a first aspect of the invention, there is
provided a method of handling a Session Initiation Protocol (SIP)
communication within an IP Multimedia Subsystem (IMS) network. A
Proxy Call Session Control Function (P-CSCF) receives a SIP message
sent from a remote network. The P-CSCF adds to the message a
further header, which identifies a Public User Identity of a
trusted entity in the remote network served by a Serving Call
Session Control Function in the IMS network. Optionally the P-CSCF
only inserts the new header when the P-Asserted-Identity in the SIP
message does not match the identity of the trusted entity. The
Public User Identity of the trusted entity is optionally obtained
by determining the identity of a secure channel on which message
was received. The message is then sent to the S-CSCF. The S-CSCF,
and any other node that the message is sent to, knows from the
presence of the further header to ignore the contents of a
P-Asserted-Identity header, which may not include the identity of
the user Public User Identity served by the S-CSCF, and instead to
use the Public User Identity of the trusted entity contained in the
further header.
[0039] The SIP message is optionally sent via a business trunk
between the remote network and the IMS network, and the remote
network is trusted by the IMS network. Because the IMS network's
P-CSCF trusts the remote network (this can be termed being in the
same trustdomain, see IETF RFC 3324 and RFC 3325) it will trust the
P-Asserted-Identity received from that network, and nodes within
the IMS network which trust the P-CSCF will trust the
P-Asserted-Identity received from it and so on. This is termed
transitive trust. Nodes in the IMS network will therefore be aware
that the trusted entity can be trusted.
[0040] Optionally, the further header identifying the private
network node is obtained from subscription information relating to
the Public User Identity of the trusted entity stored at either a
Home Subscriber Server or, in the case of a NGN network, a User
Profile Server Function located in the IP Multimedia Subsystem
network.
[0041] The subscription information relating to the Public User
Identity of the trusted entity optionally includes an Implicit
Registration Set. Optionally an Implicit Registration Set includes
a wildcarded Public User Identity or Public User Identity
sub-domain representative of a range of Public User Identities. As
a further option, the SIP message is a SIP INVITE message sent from
the trusted entity on behalf of a user of the remote network.
[0042] According to a second aspect of the invention, there is
provided a P-CSCF node for use in an IMS network. The P-CSCF
Function node comprises a receiver for receiving a SIP message sent
from a remote network. A processor is provided for adding to the
message a further header, the further header identifying a Public
User Identity of a trusted entity in the remote network that is
served by a S-CSCF. The P-CSCF also includes a transmitter for
sending the message to the S-CSCF. The further header can be used
by other nodes in the IMS network to inform them to use information
in the further header to identify the served node, rather than
information contained in the P-Asserted-Identity header.
[0043] The P-CSCF optionally comprises means for receiving
subscription information relating to the Public User Identity of
the trusted entity from one of a Home Subscriber Server and a User
Profile Server Function located in the IMS network.
[0044] The subscription information optionally includes an Implicit
Registration Set, the Implicit Registration Set comprising a
wildcarded Public User Identity or Public User Identity sub-domain
representative of a range of Public User Identities.
[0045] According to a third aspect of the invention, there is
provided a S-CSCF node for use in an IMS network. The S-CSCF node
comprises a receiver for receiving a Session Initiation Protocol
message from a P-CSCF node, and a processor for identifying the
presence of a further header in the Session Initiation Protocol
message, the further header identifying a Public User Identity of a
trusted entity in a remote network served by the Serving Call
Session Control Function. The S-CSCF also includes means for, in
the event that the further header is identified, using the Public
User Identity of the trusted entity in that header to determine the
served user instead of the P-Asserted-Identity header contained in
the SIP message. In this way, messages received by the S-CSCF in
which the served user is not identified by the P-Asserted-Identity
header can be dealt with properly.
[0046] According to a fourth aspect of the invention, there is
provided an Application Server (AS) for use in an IMS network. The
AS comprises a receiver for receiving a SIP message, and a
processor for identifying the presence of a further header in the
Session Initiation Protocol message. The further header identifies
a Public User Identity of a trusted entity in a remote network
served by a S-CSCF in the IMS network. The AS further includes
means for, in the event that the further header is identified,
using the Public User Identity of the trusted entity contained in
that header to determine the served user instead of the
P-Asserted-Identity.
BRIEF DESCRIPTION OF THE DRAWINGS
[0047] FIG. 1 illustrates schematically example relationships
between a user IMS subscription and Public and Private User
Identities;
[0048] FIG. 2 illustrates schematically in a block diagram a
signalling flow between a corporate network and an IMS network
according to an embodiment of the invention;
[0049] FIG. 3 is a flow diagram showing the basic steps of an
embodiment of the invention;
[0050] FIG. 4 illustrates schematically in a block diagram a P-CSCF
according to an embodiment of the invention;
[0051] FIG. 5 illustrates schematically in a block diagram an
S-CSCF according to an embodiment of the invention;
[0052] FIG. 6 illustrates schematically in a block diagram an
Application Server according to an embodiment of the invention.
DETAILED DESCRIPTION
[0053] Referring to FIG. 2, there is illustrated schematically an
IMS network 1 and a trusted corporate network 2. The corporate
network 2 contains a Private Branch Exchange (PBX), denoted IP-PBX.
The IP-PBX registers with the IMS network 1 on behalf of a group of
user terminals. IP-PBX learns the address of the outbound P-CSCF 3
located in the IMS network 1 by way of a DHCP lookup (as specified
in IETF RFC 3263). IP-PBX registers with the IMS network using its
own PUI (in this example, "pbx1@operator.com"). An HSS 4 in the IMS
network 1 stores subscription information for IP-PBX, which
includes an Implicit Registration Set that includes all users able
to access the IMS network 1 via IP-PBX. In addition to IP-PBX's PUI
and a tel URI allocated to IP-PBX, the Implicit Registration Set
contains a "wildcard" PUI which represents a range of PUIs
associated with the PBX. In this example, the wildcard PUI is
"!x!@enterprise2.com". The "!x!" component of the wildcard PUI
indicates that a PUI having the specified suffix and any prefix
will match the wildcard PUI.
[0054] The HSS 4 sends the Implicit Registration Set to an S-CSCF 7
in a Server Assignment Answer together with the associated service
profile(s). The S-CSCF 7 then sends a 200 OK message to IP-PBX via
the I-CSCF (not shown) and the P-CSCF 3, with the 200 OK message
including a P-Associated-URI field identifying the PUIs within the
Implicit Registration Set associated with the PUI of the PBX.
[0055] Considering the case where a terminal in the trusted
corporate network wishes to forward a call to another terminal, a
first terminal 5 having the identity Cassandra@enterprise3.com
calls a second terminal 6 having the identity Bob@enterprise2.com.
A message sent from the first terminal 5 contains in its header the
URI Cassandra@enterprise3.com in the "From" field and
Bob@enterprise2.com in the "To" field. The message also includes
the P-Asserted-Identity of Cassandra@enterprise3.com. However,
messages sent to Bob@enterprise2.com are to be forwarded to
Alice@enterprise1.com.
[0056] The message is returned to IP-PBX for forwarding to
Alice@enterprise1.com, and IP-PBX determines that this must be sent
to the P-CSCF 3 in the IMS network 1. IP-PBX sends an INVITE
message to the P-CSCF 3, the invite message containing the URI for
Alice, the URI for Cassandra in the "From" field, and the URI for
Bob in the "To" field. The INVITE also contains Cassandra's
P-Asserted-Identity.
[0057] Note that a trust relationship exists between the IP-PBX in
the corporate network 2 and the IMS network 1. Because the P-CSCF 3
receives the SIP INVITE on the security association that was
created during registration, the P-CSCF is aware that the INVITE is
to be treated on behalf of pbx1@operator1.com. The P-CSCF 3 is also
aware that the trust domain of the IMS network 1 extends to IP-PBX
in the corporate network 2. The P-CSCF 3 passes the
P-Asserted-Identity unmodified and inserts a new header to the
INVITE, the new header referred to as the "P-Served-User". The
P-Served-User header contains the URI of IP-PBX, that is
pbx1@operator1.com. Note that in one embodiment, the P-CSCF 3 will
only insert a P-Served-User header in the event that the
P-Asserted-Identity does not match the identity from which the
message was received. In this example, the P-CSCF will only insert
a P-Served-User header if the P-Asserted-Identity is not an element
of the Implicit Registration Set belonging to the trusted
entity.
[0058] The P-CSCF 3 forwards the SIP INVITE containing the
P-Served-User header to the S-CSCF 7. The IFCs associated with
pbx1@operator.com subscription may indicate that the INVITE is to
be processed by a call forwarding Application Server (AS) 8. In
this case, the S-CSCF 7 performs standard operations of adding the
SIP URI of the AS 8 as the topmost URI of the route header, and
including its own SIP URI beneath the AS URI in the route header
together with the "original dialog identifier" (ODI). The message
is then forwarded to the AS 8 over the ISC interface. The S-CSCF 7
maintains state information for the session to which the INVITE
relates. This information includes the ODI and the identity of the
served User.
[0059] The S-CSCF 7 also determines the served user based upon the
P-Served-User, rather than the P-Asserted-Identity. This allows
authentication to be based on the IP-PBX identity associated with
IP-PBX, rather than the P-Asserted-Identity contained in the SIP
INVITE.
[0060] If the P-Served-User header were not included in the SIP
INVITE, nodes in the IMS network would attempt to perform
authorisation on the P-Asserted-Identity (in this case,
Cassandra@enterprise3.com). As Cassandra@enterprise3.com does not
belong to the IMS network or the attached corporate network,
authentication using the P-Asserted-Identity would fail.
[0061] The invention allows the P-CSCF 3 to communicate the served
user (Bob@enterprise2.com) in a separate information element in the
SIP INVITE from the identity of the network asserted originating
user (Cassandra@enterprise3.com). The S-CSCF 7 uses this to
determine the served user. This allows corporate networks to be
treated as trusted networks.
[0062] FIG. 3 is a flow diagram illustrating the basic steps of an
embodiment of the invention. The following numbering refers to the
numbering in FIG. 3: [0063] S1. The P-CSCF receives a SIP message
from IP-PBX on the security association created during
registration; [0064] S2. By receiving the SIP message on the
existing security association and recognising this is coming from a
trusted entity, and determining that the P-Asserted-Identity does
not belong to the set of implicitly registered identities, the
P-CSCF adds the URL of IP-PBX to the SIP message in the form of a
P-Served-User header and leaves an optionally existing
P-Asserted-Identity header intact, as the IP-PBX has a subscription
with the IMS network and the network asserted originating user may
not have such a subscription; [0065] S3. The SIP message resulting
from step 2 is sent to the S-CSCF; [0066] S4. The S-CSCF, being
aware of the presence of the P-Served-User header, ignores the
P-Asserted-Identity and uses the P-Served-User header to determine
the served user for processing of its procedures. If IFCs are
activated for the served user, the SIP message may be forwarded to
an AS; [0067] S5. If the message is subsequently received by an AS,
the AS, being aware of the presence of the P-Served-User header,
uses the P-Served-User header to determine the served user for
processing relevant procedures.
[0068] FIG. 4 illustrates schematically a P-CSCF 3 according to an
embodiment of the invention. The P-CSCF 3 comprises a receiver 9
for receiving from IP-PBX a SIP message. A memory 10 is provided
for storing subscription information relating to IP-PBX, and a
processor 11 is provided for adding a P-Served-User header to the
SIP message, the P-Served-User header identifying the subscription
relating to IP-PBX. A transmitter 12 is also provided for sending
the SIP message to a further node such as an S-CSCF.
[0069] FIG. 5 illustrates schematically a S-CSCF 5 according to an
embodiment of the invention. The S-CSCF 7 comprises a receiver 13
for receiving a SIP message from the P-CSCF 3, and a processor 14
for determining if the SIP message contains a P-Served-User header.
If a P-Served-User header is present in the SIP message, then the
P-Served-User header will be used to determine the served user
instead of the P-Asserted-Identity. A transmitter 15 is also
provided for sending the message to other nodes in the IMS network
for further processing.
[0070] FIG. 6 illustrates schematically an AS 8 according to an
embodiment of the invention. The AS 8 comprises a receiver 16 for
receiving a SIP message, and a processor 17 for determining if the
SIP message contains a P-Served-User header. If a P-Served-User
header is present in the SIP message, then the P-Served-User header
will be used to determine the served user instead of the
P-Asserted-Identity header. The AS also has a transmitter 18 for
sending messages to other nodes in the IMS network.
[0071] 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.
For example, the above description refers to an IP_PBX node in a
corporate network. However, the invention also applies to a
connected SIP proxy node or SIP B2BUA disposed in corporate
networks or other types of network.
* * * * *