RU2433558C2 - Calculating initial filter criterion - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: session initiation protocol containing a recipient uniform resource identifier is received. As a result of applying the initial filter criterion to the message, a message is sent to the application server and calculation of additional initial filter criteria is stopped. A return message is received from the application server, after which it is determined whether the uniform resource identifier has been changed by the application server. If the uniform resource identifier was changed by the application server, it is then determined whether or not to resume calculation of the initial filter criterion, and if the uniform resource identifier was not changed by the application server, calculation of the initial filter criterion is resumed.

EFFECT: enabling continuation of calculation of an initial filter criterion (IFC) during IFC calculation in the final call session control function, even when the recipient uniform resource identifier has been changed.

8 cl, 8 dwg

Description

FIELD OF THE INVENTION

The invention relates to a method and apparatus for calculating an initial filtering criterion in an IP network of a multimedia subsystem.

State of the art

IP Multimedia (IPMM) is an example of a service that provides a dynamic combination of voice, video, message, data, etc. in one session. Due to the increase in the number of core applications and multimedia tools that can be combined, the number of services provided to end users will increase, and interpersonal interaction will expand. This will lead to a new generation of customized, enhanced multimedia services, such as peer-to-peer multimedia, IPTV, etc.

These services can be based on the IP Multimedia Subsystem (IMS) architecture, which is a technology defined by the Third Generation Partnership Project (3GPP) to provide IP multimedia services over mobile networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Version 5-7).

IMS uses the Session Initiation Protocol (SIP) to establish and manage calls or sessions between user terminals (or between user terminals and application servers). Session Description Protocol (SDP), supported by SIP signaling, is used to describe and negotiate the multimedia session facilities. 1 schematically shows how an IMS is embedded in a mobile network architecture regarding a 3GPP PS access domain.

Services can be provided to the user over the IMS network using an application server (AS). The provision of services is initiated using one or more initial filtering criteria (IFC) stored in the user profile and loaded into the serving call session management (S-SCSF) function of the user when the user is registered in the IMS network. An IFC is composed of trip points and addresses of one or more ASs. The trigger point describes the conditions that should be checked to determine whether to contact the specified AS.

As shown in FIG. 2, when the S-CSCF receives the message, it checks the stored IFCs. If the incoming message satisfies the conditions of the trigger point in the IFC, then the S-CSCF transmits the message to the AS indicated by the IFC. After processing the AS message, the message is returned to the S-CSCF, after which the next IFC is checked. An IFC may be provided with a priority number, therefore, if several user-related IFCs are stored in the S-CSCF, then the IFCs are checked in priority order.

The interface between the S-CSCF and the AS is the IMS Service Management Interface (ISC), which uses SIP signaling to communicate between the AS and the S-CSCF.

The 3GPP IMS TS specification 24.229 version 7.5.1 describes a mechanism that allows an AS to perform a change in the purpose of a SIP request by changing the Request-URI (Request Unified Resource Identifier) contained in the message. When the message is returned from the AS to the S-CSCF, the S-CSCF detects a change in the Request-URI and aborts the initial filtering criterion (IFC) calculation check, as shown in FIG. 3. The message is sent directly to process the outgoing request, in addition, no IFCs with lower priorities are checked, which prevents the activation of other ASs.

The main motivation for the mechanism arises from the requirement in the call forwarding service, which allows the AS to change the destination address of the recipient of the SIP request. At that time, it was not envisaged that any other service would require the AS to change the SIP request Request-URI. However, cases are now being considered in which it may be necessary for the AS to change the Request-URI of the SIP request without interrupting the IFC calculation procedure to the S-CSCF. Examples of such cases include the following:

1. A user having an IMS Public Subscriber Identifier (IMPU) may use multiple instances of the UE. The AS accepts the request that is addressed to the user's IMPU and selects the SIP subscriber service (UA), typically the user terminal that is accessed using the globally routed UA (GRUU) URI or contact, as the endpoint. When an AS wishes to initiate a session termination with a user equipment (UE), a problem arises if the IMPUs allocated by the UE are shared with other UEs. In order to fully control which UE sends the request to end the session, the AS must change the request purpose from the IMPU to the address of the selected endpoint.

2. A similar problem occurs when the AS changes the user's IMPU. This may be required, for example, when an AS receives an IMPU with a TEL URI and sends another with a SIP URI, and vice versa.

3. An AS may be required to change the Request-URI of an incoming request from a SIP URI to a TEL URI. This change is necessary because devices connected to the network using the Public Switched Telephone Network (PSTN) can only be contacted using telephone numbers.

In the two above cases, the S-CSCF may need to continue calculating the IFC after changing the Request-URI in the message by the application server. This does not change the target user, but only accesses the same user or a subset of user endpoints using an alternate address. This differs from the “call forwarding” scenario, in which the actual target user changes, and is the main reason why the existing mechanism for interrupting IFC calculations in the event of an address change is not suitable for these cases.

SUMMARY OF THE INVENTION

According to a first aspect of the invention, there is provided a method for calculating an initial filtering criterion in a final function of managing a call session in an IP network of a multimedia subsystem, including the steps of:

receiving a session initiation protocol message, wherein the session initiation protocol message comprises a unified identifier of the destination resources;

as a result of applying the initial filtering criterion to the message, a message is sent to the application server, and the calculation of the additional initial filtering criterion is suspended;

receive the message returned from the application server

determining whether the uniform resource identifier has been changed by the application server;

if the unified resource identifier has been changed by the application server, it is determined whether to resume the calculation of the initial filtering criterion, and if the unified resource identifier has not been changed by the application server, the calculation of the initial filtering criterion is resumed.

In this way, a decision is made to continue calculating IFC, even if the unified identifier of the destination resources has been changed.

The step of determining whether to resume the calculation of the initial filtering criterion may include determining whether the initial filtering criterion has an associated cancel indicator for changing the target, and if the result is positive, the calculation of the initial filtering criterion is resumed. In this case, the indicator of the cancellation of the change in the target, as a rule, is associated with the initial filtering criterion and is saved as part of the user profile.

Alternatively, the step of determining whether to resume the calculation of the initial filtering criterion may include the step of determining whether the message received from the application server contains an indication that the target change has been canceled, and if the result is positive, the calculation of the initial filtering criterion is resumed. This allows the application server to decide whether to turn on the undo indicator of the change in target.

In an alternative method, the step of determining whether to resume the calculation of the initial filtering criterion may include the step of determining whether the unified identifier of the destination resources contained in the message received from the application server relates to the public IP user identifier of the multimedia subsystem belonging to the same user that the user ID of the IP multimedia subsystem contained in the received message, and in the case of a positive result, continues with the resumption iem calculating initial filter criterion.

According to a second aspect of the invention, there is provided a terminating call session management function for use in an IP network of a multimedia subsystem, the call session management function including:

means for receiving a session initiation protocol message, the message comprising a unified identifier of destination resources;

means for calculating an initial filtering criterion for application to a message;

a transmitter for sending a message to the application server;

means for receiving a message returned from the application server;

means for determining whether the unified identifier of the destination resources has been changed by the application server; and

means for determining whether to continue or stop the calculation of the initial filtering criteria, if the unified identifier of the destination resources has been changed through the application server.

According to a third aspect of the invention, an application server is provided, including:

a receiver for receiving the message, and the message contains a unified resource identifier of the addressee:

means for correcting a uniform message resource identifier;

means for including a target address cancellation indicator in a message; and

a transmitter for sending a message to the call session management function.

According to a fourth aspect of the invention, there is provided a method for processing a session initiation protocol message in a final session management function of a call in an IP network of a multimedia subsystem, comprising the steps of:

receiving a session initiation protocol message, wherein the session initiation protocol message comprises a unified identifier of the destination resources;

at least one initial filtering criterion is applied to the message;

as a result of applying the initial filtering criterion, they send a message to the application server;

receive a message returned from the application server;

determining whether the returned message contains a unified resource identifier for the new target,

if the returned message contains the unified resource identifier of the new target, then replace the unified resource identifier of the destination with the unified resource identifier of the new target.

This method provides the ability to calculate all the initial filtering criteria before changing the unified identifier of the destination resources, even if the application server involved by the first initial filtering criterion from the set of initial filtering criteria wants to change the unified identifier of the destination resources.

According to a fifth aspect of the invention, a call session management function is provided for use on an IP network of a multimedia subsystem, including:

means for receiving a session initiation protocol message, the message comprising a unified identifier of destination resources;

means for applying initial filtering criteria to the message;

a transmitter for sending a message to the application server;

means for receiving a message returned from the application server;

means for determining whether the body of the returned message contains a unified resource identifier for the new target; and

means for replacing the unified resource identifier of the addressee in the message with the unified resource identifier of the new target.

Brief Description of the Drawings

Figure 1 schematically illustrates a method for embedding an IMS subsystem in a mobile network architecture, in the case of a 3GPP PS access domain;

2 schematically illustrates the initiation of application servers by an S-CSCF in response to a satisfying initial filtering criterion;

Figure 3 schematically illustrates the initiation of an application server by an S-CSCF in response to a satisfying initial filtering criterion, where the application server changes the target URI;

4 schematically illustrates the initiation of application servers by means of an S-CSCF according to the present invention;

5 depicts a signaling sequence when a target change cancel indicator is associated with an IFC in a user profile;

6 depicts a signaling sequence when a target change cancel indicator is transmitted by an application server;

7 depicts a signaling sequence when a new target is transmitted by an application server, and

Fig. 8 depicts a signaling sequence where the target change cancel logic is used in the S-CSCF.

Detailed description

The S-CSCF is able to determine if the Request-URI has been changed by the AS. If it is determined that the Request-URI has been changed, then the S-CSCF decides whether to continue the calculation of the initial filtering criterion (IFC). This is shown in FIG. 4. The first IFC-1 initial filtering criterion applies to an incoming message on the S-CSCF. The message is sent to the AS-1 application server specified in IFC1. The message then returns from AS-1 to the S-CSCF. The S-CSCF determines whether the Request-URI has been changed. If not, the following IFC-2 initial filtering criteria is applied to the message. If the S-CSCF decides that the Request-URI has been changed, then the S-CSCF decides whether to resume IFC calculation. If the result is negative, the message is sent directly to process the outgoing request to the S-CSCF. Alternatively, if the S-CSCF decides that IFC calculation should be resumed, then the message with the corrected Request-URI is transmitted for calculation on IFC-2. This process is repeated for each IFC.

It should be noted that in FIG. 4, a check to see if the Request-URI has been changed is shown as taking place before checking whether to resume calculating the IFC criterion or to send a message directly to process the outgoing request to the S-CSCF. The order of these two checks may be reversed.

There are several different ways in which the S-CSCF can determine whether to resume IFC calculation after changing the Request-URI of a message. Three possible methods are described below:

1. The undo target change indicator is included as part of the user profile stored on the HSS and uploaded to the S-CSCF during user registration on the network. A Goal Cancellation Indicator is associated with a specific IFC. When the S-CSCF receives the SIP returned with the changed target by the AS initiated by the IFC using the target change cancel indicator, the S-CSCF will not interrupt the IFC calculation, but will resume the procedure despite the change in the target.

2. The target change cancel indicator is entered as part of the ISC signaling between the S-CSCF and AS. An AS that changes the purpose of the request may also include an indication that the target has been canceled in the SIP request sent to the S-CSCF. The target change cancel indicator may be located in any suitable part of the SIP message, including the header or body of the message. The S-CSCF reads the target change cancel indicator in the SIP message and resumes the IFC calculation. There are additional alternative ways in which the AS can transmit the change of purpose, as well as transmit the cancel indicator to the S-CSCF via ISC as follows:

a. The AS changes the Request-URI and includes a clear indication of the cancellation of the change in the destination address in the SIP request;

b. AS keeps the Request-URI unchanged, but a new destination address is sent in the SIP request (for example, in the SIP header);

3. A new logic is introduced in the S-CSCF to analyze the address of the changed request target to determine whether to continue or stop the IFC calculation. This logic determines whether the changed target is another IMPU owned by the user, or the target is obtained from the IMPU owned by the user, or whether it is the SIP user agent (UA) currently registered with the user. If any of these conditions is met, then the S-CSCF resumes the IFC calculation; otherwise, the SIP message is transmitted to process the outgoing request.

Three of the above examples will now be described in more detail.

1. Goal change cancel indicator associated with the IFC in the user profile.

The signaling sequence for this embodiment is shown in FIG. 5.

1.1. The undo target change indicator is included as part of the user profile on the HSS. The undo target change indicator is associated with an IFC that indicates a specific AS. The undo target change indicator is uploaded to the S-CSCF as part of the user profile when the S-CSCF is allocated to the user (as a rule, during user registration or upon completion of a request to an unregistered user to receive final services). The undo target change indicator is in addition to the existing user profile stored on the HSS and cached by the S-CSCF.

1.2. When the S-CSCF receives the request to complete the initial SIP for the served user, it performs IFC calculation by comparing the received request with the stored IFCs in their predefined priority order. If the request matches IFC, the calculation is aborted, and the request is forwarded to the AS indicated by the IFC comparison result.

1.3. When the AS accepts the SIP request and decides to change the request target, it includes the new target in the SIP request Request-URI and returns the SIP request back to the S-CSCF.

1.4. When the S-CSCF receives the SIP request returned by the AS, it checks to see if the request target has been changed, and whether the target change cancel indicator is associated with the IFC that initiated the message sent to the AS. The S-CSCF checks whether the request target has been changed by comparing the Request-URI of the SIP message sent to the AS with the Request-URI of the SIP message received from the AS. The following actions may result in:

1.4.a. If the purpose of the request has not been changed, then IFC calculation is resumed according to step 1.5 below;

1.4.b. If the target change cancel indicator is set for the AS indicated by the IFC that initiated this request, then IFC calculation resumes according to step 1.5;

1.4.c. If the request target has been changed, and the target change cancel indicator for the AS indicated by the IFC that initiated this request is not set, then IFC calculation does not resume, and the message is sent to process the outgoing request;

1.5. In cases where the S-CSCF must resume IFC calculation as required by steps 4a and 4b above, the S-CSCF resumes the IFC calculation by comparing the SIP request received with the AS with the stored IFCs from the next IFC in a predefined priority order. If the request matches IFC, the calculation is aborted, and the request is forwarded to the AS indicated by IFC comparison. The procedure continues from step 3.

2a. Target change cancel indicator transmitted by AS

The signaling sequence for this embodiment is shown in FIG. 6 and described as follows:

2a.1. When the S-CSCF receives the request to complete the initial SIP for the served user, it performs the existing IFC calculation procedure by comparing the received request with the stored IFCs in a predefined user priority order. If the SIP request matches IFC, the calculation is aborted, and the request is forwarded to the AS indicated by the IFC comparison result.

2a.2. When the AS accepts the SIP request and decides to change the purpose of the request, it forwards the SIP request back to the S-CSCF with a new target in the SIP request Request-URI, and also includes a new target change cancel indicator in the SIP request to inform the S-CSCF about the continued IFC calculation .

2a.3. When the S-CSCF receives the SIP request returned by the AS, it determines whether the request target has changed and whether the cancel indicator of the change in purpose is included in the received request. The S-CSCF removes from the request any received indicator of the cancellation of the target change before further processing in step 2.4 or before processing the outgoing request. As a result of step 2.3, the following actions may occur:

2a.3.a. If the request target has not been changed, then IFC calculation resumes according to step 2a.4;

2a.3.b. If the request target has been changed and the request from the AS has accepted the cancel target change indicator indicating “cancel”, then the IFC calculation is resumed according to step 2a.4;

2a.3.c. If the request target has been changed, but the SIP message received from the AS does not contain an indicator that the target has been canceled, then IFC calculation does not resume, and the message is sent to process the outgoing request.

2a.4. If IFC calculation is resumed, then the S-CSCF resumes the existing IFC calculation procedure by comparing the received request with the stored IFC criteria from the next IFC in a predefined priority order. If the request matches IFC, the calculation is aborted, and the request is forwarded to the AS indicated by the IFC comparison result. The procedure continues from step 2.2.

2b. New target transmitted by AS

The signaling sequence for this embodiment is illustrated in FIG. 7 and described as follows:

2b.1. When the S-CSCF receives the initial SIP termination request for the served user, it performs the existing IFC calculation procedure by comparing the received request with the stored IFCs in their predefined priority order. If the request matches IFC, the calculation is aborted, and the request is forwarded to the AS indicated by the IFC comparison result.

2b.2. When the AS accepts the SIP request and decides to change the purpose of the request, it forwards the SIP request back to the S-CSCF without changing the Request-URI of the request. Instead, it adds a new target to the SIP request. The new target may be included in the new header or, alternatively, in the body of the message.

2b.3. The SIP request is returned to the S-CSCF through the AS with the same Request-URI. Therefore, the S-CSCF resumes the IFC calculation according to the existing procedure by comparing the received request with the stored IFCs from the following IFC criterion in a predetermined priority order. If the request matches IFC, the calculation is aborted, and the request is forwarded to the AS indicated by the IFC comparison result. The procedure continues from step 3.2.

2b.4. At the end of the IFC calculation procedure, before performing outbound processing, the S-CSCF checks for a new target in the SIP request. If there is a new target, the S-CSCF places it in the Request-URI of the request, and also removes it from the request. Then it resumes the usual outbound processing based on the new target.

3. The logic of canceling changes to a new target in the S-CSCF

The signaling sequence for this embodiment is illustrated in FIG. 8 and described as follows:

3.1. When the S-CSCF receives the request to complete the initial SIP for the served user, it performs the existing IFC calculation procedure by comparing the received request with the stored IFCs in a predetermined order of their priorities. If the request matches IFC, the calculation is aborted, and the request is forwarded to the AS indicated by the IFC comparison result.

3.2. The AS accepts the SIP request and decides to change the purpose of the request. The request message is sent back to the S-CSCF with a new purpose in the Request-URI of the SIP request.

3.3. When the S-CSCF receives the SIP request returned by the AS, it determines whether the request target has been changed by the AS, and if the result is positive, the S-CSCF applies logic to decide whether to correct the change in the target. The logic is based on the S-CSCF being informed of all identifiers belonging to the user, including user GRUU identifiers, in addition to the currently registered contact addresses of the served user. This new logic determines whether the changed target belongs to the served user.

3.3.a. If the request target has not been changed, then IFC calculation resumes according to step 3.4;

3.3.b. If the request target has been changed and the S-CSCF decides that the new target belongs to the served user, then IFC calculation is resumed according to step 3.4;

3.3.c. If the request target has been changed and the S-CSCF decides that the new target does not belong to the served user, then IFC calculation does not resume, and the message is sent to process the outgoing request;

3.4. When the S-CSCF decides that IFC calculation should be resumed, the S-CSCF resumes the existing IFC calculation procedure by comparing the received request with the stored IFCs from the next IFC in a predefined priority order. If the request matches IFC, the calculation is aborted, and the request is forwarded to the AS indicated by the IFC comparison result. The procedure continues from step 3.2.

Those skilled in the art will appreciate that various modifications can be made to the above described embodiments without departing from the scope of the present invention.

Claims (8)

1. A method for calculating the initial filtering criterion in the final function of managing a call session in an IP network of a multimedia subsystem, which includes: receiving a session initiation protocol message, the session initiation protocol message containing the requested unified resource identifier; send a message to the application server, and also suspend the calculation of an additional initial filtering criterion, as a result of applying the initial filtering criterion to the message; receiving a message returned from the application server, determining whether the requested uniform resource identifier has been changed by the application server; if the requested unified resource identifier has been changed by the application server, then it is determined whether to resume the calculation of the initial filtering criterion, and if the requested unified resource identifier has not been changed by the application server, the calculation of the initial filtering criterion is resumed. 2. The method according to claim 1, wherein the step of determining whether to resume the calculation of the initial filtering criterion includes determining whether the initial filtering criterion has an associated cancel indicator for changing the target, and if so, then the calculation of the initial filtering. 3. The method according to claim 1, in which the step of determining whether to resume the calculation of the initial filtering criterion includes determining whether the goal change cancel indicator received from the application server contains, and if so, the calculation of the criterion is resumed initial filtration. 4. The method according to claim 1, wherein the step of determining whether to resume the calculation of the initial filtering criterion includes determining whether the requested uniform resource identifier contained in the message received from the application server relates to the IP user identifier a multimedia subsystem belonging to the same user as the user ID of the IP multimedia subsystem contained in the received message, and if so, then continue the process with the resumption of the calculation of the criterion initial filtration. 5. The final function of the management of the call session for use in the IP network of the multimedia subsystem, including: means for receiving a session initiation protocol message, the message containing the requested uniform resource identifier; means for calculating an initial filtering criterion for application to a message; a transmitter for sending a message to the application server; means for receiving a message returned from the application server; means for determining whether the requested uniform resource identifier has been changed by the application server; and means for determining whether to continue calculating an initial filtering criterion or to stop calculating an initial filtering criterion if the requested unified resource identifier has been changed by the application server. 6. An application server, including: a receiver for receiving a message, the message containing the requested uniform resource identifier; means for correcting the requested uniform message resource identifier; means for including a target address cancellation indicator in the message, the target address cancellation indicator can be used by the call session management function to determine that the calculation of the initial filtering criterion should be continued; and a transmitter for sending the message to the call session management function. 7. A method for processing a session initiation protocol message in an IP multimedia subsystem call session management function, comprising the steps of: receiving a session initiation protocol message, wherein the session initiation protocol message contains a requested uniform resource identifier; apply to the message at least one initial filtering criterion as a result of applying the initial filtering criterion, send the message to the application server; receive a message returned from the application server; determining whether the returned message contains a unified resource identifier for the new target, the calculation of the initial filtering criterion is continued; and at the end of the calculation of the initial filtering criterion, it is determined whether the returned message contains the unified resource identifier of the new target, and if so, then replace the requested unified resource identifier with the unified resource identifier of the new target. 8. A call session management function for use on an IP network of a multimedia subsystem, including: means for receiving a session initiation protocol message, the message comprising a requested uniform resource identifier; means for applying initial filtering criteria to the message; a transmitter for sending a message to the application server; means for receiving a message returned from the application server; means for continuing to calculate an initial filtering criterion (IFC); means for determining whether the returned message contains a unified resource identifier for the new target; and means for replacing the requested unified resource identifier in the message with the unified resource identifier of the new target.

Images