Field of the Invention The present invention relates to systems for providing services in response to a communications session message.

In some embodiments the session message is a Session Initiation Protocol (SIP) message.

Background of the Invention The Session Initiation Protocol (SIP) is an application layer control protocol, which can establish, modify and terminate multi-media communications sessions or calls with one or more participants. These multimedia communications sessions can include internet telephony, multi-media distributions, multi-media conferences and similar applications.

Multi-media communications sessions can be established, controlled and terminated using SIP session messages of various types. A session message may form part of a stand-alone transaction such as a request/response to register a transaction or subscribe to a service, or may be part of a dialogue between two network entities.

Participants to a communications session may be users wishing to establish a multi- media call. However, as part of a communications session one or more services may be deployed in response to a particular session message. For many applications a communication session may require a specific function to be triggered to provide a particular feature or service to a user during a communications session. For example, if SIP is being used to set up an internet telephone call then a service provided as part of the session may be for example to provide call forwarding, or to provide a particular action depending upon the calling party, such as call blocking for particular numbers.

Therefore, it will be appreciated that there are various services, which may be required and may be provided as part of a communications session.

International patent application number WO/0079756 discloses a telecommunication network, which includes a packet switched network operable to establish a communications session in accordance with SIP. The telecommunications network includes a SIP server and a service node. The SIP server is responsive to a request message from a user to establish a call, to consult a user profile. Based on the

user profile, the SIP server is operable to formulate a request for a prescribed service, if a trigger condition is encountered in the user profile. The request includes at least one header field, which contains information specifying an operation, which the service node is to perform. Accordingly, a service is provide to a user as part of, for example, a session initiation, but may include other phases of a communication session, which can add value to a call between users.

Summary of the Present Invention According to the present invention a system is operable to provide at least one service in response to a communications session message. The system comprises a session protocol server responsive to a session message to identify one of a plurality of servlets, each of the servlets providing a predefined service to a user during a communications session. The system includes a servlet container operable to host the plurality of servlets. The session protocol server is operable in response to the session message to modify the session message to provide a route address for routing the session message to the servlet container, the address being a universal resource identifier. The route address includes a servlet string identifier as a username part of the universal resource identifier, the servlet string identifying the servlet for providing the required service. The session initiation protocol server is operable to introduce the servlet string identifier into a header of the session message, which can be read by the servlet container. The servlet container is responsive to the modified session message to deploy the servlet identified by the servlet string identifier read from the session message.

By providing the servlet string identifier in a header of the session message, which can be read by the servlet container, the servlet container can identify the servlet from the modified session message and deploy the corresponding servlet. The above mentioned known system disclosed in WO/0079756 does not provide a facility for hosting servlets on a servlet container which is remote from the session protocol server (e. g. a SIP server). Embodiments of the present invention provide a facility for deploying one of a plurality of servlets, which are hosted remote from the session protocol server on a servlet container. Accordingly a more flexible and more easily adaptable system is provided since further servlets can be added for deployment with relatively small adaptation to the session protocol server.

In one example embodiment the session message includes three headers which can be read by the servlet container. In one example the three headers include a request line, a"from"header and a"to"header.

In one embodiment the servlet container includes a deployment descriptor for deploying the servlets. The deployment descriptor is arranged to read the headers of the session message and to route the message to the relevant servlet by identifying the servlet string identifier in a header of the session message.

Embodiments of the present invention are arranged to deploy a service in accordance with a servlet efficiently by routing an adapted version of a received session message to a servlet container. A session protocol server is responsive to the session message to adapt a URI, which appears in the session message by adding a route header. The route header is arranged to identify the servlet container to which the adapted message can be thereby routed. The route header may contain many addresses. Accordingly, the server in response to the session message may add the URI to the route address header at the top most position.

Introducing a servlet identifier string into any of the header fields of the session message, which can be read by the servlet container, provides the servlet container with an indication of the servlet to be deployed. In addition, including the servlet string identifier as the user name in the route address of the session message allows the deployed servlet to locate the servlet string identifier where it has been added to the header of the session message by the session protocol server. The servlet string identifier can be therefore removed at the SIP servlet to recover an original form of the session message. The servlet can therefore use the original session message to execute the service logic according to the service to be provided. If the username part of the top most route header address is empty, then the servlet does not have to remove any part of the SIP URI of the request-line. The username part of the top most route header address will be empty, if the SIP Server has an alternative mechanism for sending the session message to the right SIP servlet which does not need the request-line to be modified..

The adapted session message can be used to not only trigger a required servlet but also the servlet can be contained on a servlet container remote from the SIP server within the packet switched network. Furthermore, various conditions can be used to

filter a session message to the effect of introducing an appropriate servlet string identifier, to identify a particular servlet for deployment following receipt of a session message. Therefore, various servlets can be deployed for a particular session message following certain logical trigger conditions. Having identified a required servlet from a logical trigger condition being satisfied, a servlet string identifier for the servlet can be introduced into the session message. An efficient way of deploying a service to a user is thereby provided on a servlet container remote from the session protocol server.

According to example embodiments, the session protocol server is a SIP server, the session message being a SIP message or request and the servlet container is a SIP servlet container. In other embodiments the SIP server is a Serving-Call State Control Function (S-CSCF).

Various further aspects and features of the present invention are defined in the appended claims.

Brief Description of the Drawings Embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings, where like parts are provided with corresponding reference numerals, and in which: Figure 1 is a schematic block diagram of part of a system which includes packet switched network in which a session protocol is used to deploy a service; Figure 2 is a schematic block diagram of a SIP servlet container forming part of the system illustrated in Figure 1; Figure 3 provides an illustration of part of a header of a session message (SIP INVITE message); Figure 4 provides an illustration of part of a header of the session message shown in Figure 3 after adaptation of the message by a SIP server appearing in Figure 1 ; Figure 5 provides an illustration of part of a header of a session message shown in Figure 4, after adaptation of the message by a servlet appearing in Figure 1; Figure 6 is a flow diagram illustrating a process by which the system illustrated in Figure 1 deploys a servlet for providing a service during a session; Figure 7 is a schematic block diagram illustrating a simplified internet protocol multi-media sub-system represented in a simplified form Figure 8 provides an example XML structure illustrating an example user profile; Figure 9 is an illustrative block diagram of an in-line format of an example user profile; Figure 10 is an illustration of an initial filter criteria tree provided by a home subscriber system forming part of the sub-system shown in Figure 7; Figure 11 is a flow diagram illustrating the operation of a serving call state control function (S-CSCF) appearing in Figure 7; Figure 12 is an illustration of a SIP initiation request; Figure 13 is an illustration of the SIP initiation request of Figure 12, following modification by the serving call state control function (S-CSCF) appearing in Figure 7;

Figure 14a is a flow diagram illustrating the operation of a deployment descriptor forming part of applications server shown in Figure 7, and Figure 14b is a flow diagram illustrating the operation of an application deployed in response to the adapted session message and the applications server; and Figure 15 is an illustration of the SIP initiation request of Figure 12, following modification by an application, which has been deployed.

Description of Example Embodiments Figure 1 provides an example arrangement for deploying a service in response to a session message. In Figure 1 an SIP server 1 is connected into a communications path formed by communications channels 2,4. The communications channels 2,4 form part of a packet switched network.

As already explained a communications session may be established for various reasons. The communications session may involve only one party, which may be undertaking a particular function, such subscribing for a particular service or registering presence information. In other examples the communications session may be between two parties. The illustration shown in Figure 1 is applicable for a communications session involving a single party or between two parties exchanging data during a communications session. For the example of a communications session between two parties, the SIP server 1 could be on the side of an originator of the communications session, or could be on a terminating side of the communications session.

As shown in Figure 1, a database 6 is connected to the SIP server 1 via a connecting channel 8, which may also form part of the packet switched network. Also connected to the SIP server 1 are first and second SIP servlet containers AS1, AS2.

The SIP servlet containers may be part of a SIP application server or service node.

The SIP servlet containers are operable to deploy SIP servlets. One of the SIP servlet containers AS 1 shown in Figure 1 is also shown in Figure 2 in more detail.

In Figure 2 the SIP servlet container AS1 is arranged to support a plurality of applications or servlets 20,22, 24,26. Each of the servlets 20,22, 24,26 provides an application program which when executed provides a service. The servlet is deployed in response to a communications session message. The communications sesion message may be of various type. One example of a communications session message is an INVITE message. The session message will be referred to in the example embodiments as a SIP message.

Also included as part of the SIP servlet container is a deployment descriptor DD. A deployment descriptor DD is operable in response to receipt of a session message (SIP message) to deploy one of the servlets 20,22, 24,26 which, according to

one example explained shortly, is identified to the deployment descriptor DD by information provided in the SIP message. In other examples, the deployment descriptor DD may deploy servlets based on a type of session message received and/or an address in a header of the message or a logical combination of conditions.

For the example implementation, the address information which identifies one of the servlets is provided in the form of a servlet string identifier, which is introduced into a header of the session message, which can be read by the deployment descriptor DD. The deployment descriptor DD can therefore deploy the correct servlet to provide the service to a user during session initiation. As will be explained in the following paragraphs the servlet identifier string is introduced into the header by the SIP server 1. However, as will be appreciated by those acquainted with SIP, the deployment descriptor DD is only permitted to read certain parts of the SIP message. These parts include the addresses within the message header, which includes a SIP URI of a SIP message request line. The operation of the SIP server to introduced the servlet identifier string will now be described.

Returning to Figure 1 a dashed line 29 represents the path of a SIP message as received at the SIP server. An example of the SIP message is shown in Figure 3. As shown in Figure 3 the SIP message 30 includes a request line 32 a"to"header 34 and a "from"header 36. As shown in Figure 3 the request line includes a SIP URI providing an indication of the location of the server or client which is requesting a communications session. The SIP message is labelled" (1)" and shown correspondingly as being received at the SIP server 1 in Figure 1 at position" (1)".

Upon receipt of the SIP message the SIP server 1 is operable to interrogate the database 6 and retrieve a name of a servlet (an applications program) which is to be triggered in response to the SIP message for that user. In addition, the database 6 provides an identifier for the servlet container on which the servlet is hosted.

Alternatively, information from the database providing the name of the servlet to be deployed and the appropriate servlet container may have been down-loaded already from the data base and stored locally in the SIP server 1.

The database 6 contains a profile for the user, the user having pre-registered a particular service or set of services, which are to be triggered in response to a session message. The identification of the servlet, which is to be triggered, can be done in

several ways using different logical combinations of conditions. However, in one example embodiment, which will be described shortly, an initial filter criteria tree is provided in order to determine whether specific conditions have been satisfied and from which the appropriate servlet to be triggered can be identified. Accordingly, the SIP server 1 identifies the servlet to be triggered and from the information pre-stored in the database 6 retrieves a servlet identifier string which identifies that servlet. The SIP server then changes the SIP message to the effect of introducing the servlet identifier string into a header of the SIP message which can be read by the deployment descriptor DD within the SIP servlet container AS1. Since the deployment descriptor DD can only read the header request line, the"to"header and the"from"header, the SIP server arranges for the servlet identifier string to be introduced as a sub-domain name within the SIP URI provided as one of the headers.

Figure 4 shows the effect of the SIP server operating in accordance with an embodiment of the present invention to adapt the SIP initiation message shown in Figure 3 to introduce the servlet string identifier into the header request line 32. As shown within the header request line 32 a servlet identifier string appln2 is introduced as a sub-domain within the host name of the SIP URI. The deployment descriptor DD can read the host name in the header and because the deployment descriptor DD has a predetermined knowledge of where to retrieve the servlet string identifier from the host name of the adapted SIP URI, the deployment descriptor can recover the servlet identifier string. The deployment descriptor DD can therefore launch the appropriate servlet.

Before adapting the SIP initiation message to include the servlet string identifier of the servlet to be deployed, the SIP message is adapted to include an address of the servlet container on which the servlet is hosted. By adding the address of the servlet container, the adapted SIP message can be routed to the SIP servlet container AS1. As explained above, the SIP server 1 also retrieves from the database 6 an indication of the SIP servlet container on which the identified servlet is contained.

In order to route the adapted SIP message to the correct SIP servlet container, the SIP server introduces a route address which has a domain name which identifies the correct SIP servlet container AS1. Accordingly, a route address URI is introduced as the top- most address in the SIP message, into the route address line 40 of the SIP message 30.

According to the rules for routing a SIP message by a SIP server, the SIP server first checks if there is a route header. If so the SIP server forwards the SIP message to the address contained in the top most route header. If not the request is sent to the address contained in the request-line (address in the first line of the SIP request). Since the route address is the top-most address which is read by a server within the packet switched network then this address will be used to forward the SIP message to the SIP servlet container AS 1.

The SIP message is constructed and established in accordance with an IETF specification, and includes a body part 42 for supporting data such as SDP data.

The SIP server therefore operates to introduce the route address header so that the SIP message can be forwarded to the correct SIP servlet container. As shown in Figure 4 the route address header 40 includes in the user name part 44 the servlet identifier string"appln2". Thus, within the header request line the servlet string identifier appln2 is introduced and in the user name part of the route address header 44 the same servlet identifier string is introduced as illustrated by a double headed arrow 44.

As shown in Figure 1 the adapted SIP message" (2)" is forwarded to the SIP servlet container using the route address header. As illustrated in Figure 2 the SIP message is then forwarded to the deployment descriptor DD, which is, provided with a predetermined knowledge of the location of the servlet identifier string within the header request SIP URI. Accordingly, the deployment descriptor can recover the servlet identifier string, and identify the appropriate servlet in order to trigger the appropriate service by forwarding the SIP message to that servlet. However, to recover the original SIP message before processing its service logic, the servlet identifies the correct user name or SIP URI. The SIP URI was adapted by the SIP server in order to identify the appropriate servlet which was triggered by the SIP server container.

To identify the correct address, the servlet, once it has received the session message, recovers the correct address of the session message by removing the servlet identifier string from the SIP URI 32. This is done by matching the appropriate part of the servlet string identifier from the route header address and the username address in the request line. The correct address indicates the destination address of the session

message. The servlet therefore forms a SIP message" (3)" shown in Figure 5 with the servlet identifier string removed from the header address. Accordingly, the SIP servlet can use the recovered address to execute the service logic.

A flow diagram illustrating the operation of the SIP server in order to forward the SIP message to the appropriate servlet container which will deploy the corresponding servlet in response to the SIP message is provided in Figure 6. The flow diagram provided in Figure 6 is summarised as follows: Sl : The SIP server receives a SIP message providing a SIP URI from a particular user having for example a user name"usernamel".

S2: The SIP server identifies the username from the SIP URI in the request header of the user to which the message is directed (username2). Using the user name "username2"the SIP server interrogates the database and recovers information associated with that username for defining services to be deployed when a session communication is undertaken. Alternatively, as mentioned above the information associated with the user (user profile) may have already been downloaded from the database. The information provides the SIP server with a servlet string identifier, identifying a servlet to be deployed. For multiple servlets, deployment is done one at a time. In one embodiment, the servlet string identifiers are provided from an initial filter criteria tree, which provides a set of logical conditions or trigger points, which if satisfied provides a servlet and therefore a servlet string identifier of the servlet to be deployed. In other example embodiments the SIP server may use"usernamel"to trigger a SIP servlet. This may also depend on whether the SIP server is operating in association with a terminating user or an originating user of the communications session.

S4: In order to route the SIP message to the correct servlet container the SIP server adds a route address to the top most route address header to route the SIP message to this SIP servlet container. Thus, the host domain name of the route address header identifies the specific servlet container where the servlet to be triggered is hosted. The route header address provided to route the SIP message to the SIP servlet container is inserted as the top most position. The address of the SIP servlet container is stored in the user profile. The username part of the address includes the servlet

identifier string ("appln2"), which is also introduced in step S6 as a sub-domain in the host domain of the SIP URI in the header request line.

S6: The SIP server changes the routing address of the SIP URI in the request line of the SIP message to include the servlet string identifier as a sub-domain part of the host domain of the SIP URI. Thus, for example, if the servlet identifying string is "appln2"then the SIP URI in the header request becomes username2@appln2. orange. com. The route header address also includes the servlet string identifier to provide the servlet with an indication that the servlet identifier string has been added to the header in the SIP URI. The SIP servlet can therefore remove the servlet identifier string before executing the service logic upon reception of the SIP message and when replying to the SIP message.

S8: The SIP servlet container then receives the SIP URI as part of the SIP message adapted by the SIP server and deploys the appropriate servlet by identifying the servlet identifier string which is in a known part of the SIP URI provided as part of the header.

S10 : The SIP servlet then identifies the identifier string in the request header address of the SIP message, which is received by it. The SIP server then removes the identifier string from the address to form an address for use in responding to the session destination, as part of the service logic of the servlet.

IP Multimedia Sub-System A mobile multimedia sub-system as defined in [3], [4], and [5] includes a call control service architecture which has been defined by the 3GPP standards body to work with an underlying real-time capable UMTS packet data network. The IP multimedia sub-system provides a basis for providing services and for developing new services. This is utilised to provide real-time multimedia services which are integrated with non real-time services and person to machine communications.

One example application of an embodiment of the present invention will now be described in accordance with an IP multimedia sub-system. A diagram of a simplified version of IP multimedia sub-systems elements is shown in Figure 7.

In Figure 7 a Serving Call State Control Function (S-CSCF) 100 forms part of the IP multimedia sub-system and sends and receives SIP messages via connecting channels 102, 104. Connected to the S-CSCF is an application server 106 via a

connecting channel 108. Also included as part of the sub-system is a Home Subscriber Server HSS 110.

The embodiments of the present invention illustrated in Figure 7 correspond substantially to the embodiment illustrated in Figure 1. The S-CSCF is an example of a SIP server whereas the application server contains a servlet container.

Correspondingly, the HSS 110 is an example of a database, which provides user related information to the S-CSCF.

The operation of the IP multimedia sub-system shown in Figure 7 will now be explained in more detail. As explained with reference to the first embodiment, the HSS contains information from each user in the form of a user profile. The user profile may be in the form of an XML document conforming to the XML schema defined in [5]. The user profile is stored in the HSS 110 and is downloaded to the S- CSCF upon user registration or if the S-CSCF receives an initial request which is destined for an unregistered user.

An example of a user profile in the form of an XML schema is provided in Figure 8.

An example of an in-line format of a user profile is shown in Figure 9. The in- line format shown in Figure 9 comprises several fields including a private identification data field 120 as well as a service profile 122 comprising public identification 124, call network server authorisation 126 and an application and a server filter 128. The application and server filters provide information, which is related to service logic. Included within the application and server filters is data representing an initial filter criteria tree which provides a list of applications or servlets which are to be deployed in accordance with specific conditions with which a user may have subscribed.

The initial filter criteria tree for a particular user is relatively static in nature because the filer criteria will not change on a frequent basis. The filter criteria are valid throughout the registration lifetime of a user or until a user profile is changed.

Figure 10 provides a representation of an initial filter criteria tree. As shown in Figure 10 the initial filter criteria is represented in the form of an object orientated language in which several classes are defined. One class 140 is an application server class, which defines an application server, which is to be contacted if certain trigger points are

satisfied. The application server name has a SIP URI forming part of the class, the application server class may contain an instant of a service information class. The service information class is provided to allow the S-CSCF to download information, which is to be transferred transparently to an application server when a trigger point of a filter criteria is satisfied. The service information is a string conveying information to the SIP server such as for example an international mobile subscriber identity number. On the left hand. side of Figure 10 two classes 144,146 which provide trigger points. The trigger point class 144 provides conditions for triggering a service from a particular application server. Correspondingly, the service point trigger class provides conditions for the service to be provided in accordance with the trigger points.

The S-CSCF is operable to parse the initial filter criteria to determine whether any trigger points have been satisfied. For example, if a user has selected that call- forwarding should be used, then parsing the filter will determine that the user has set a requirement for the call-forwarding to be"on"and so a servlet should be triggered to provide the call-forwarding function. In response to the S-CSCF applying the initial filter criteria, the S-CSCF recovers the servlet identifier string identifying the servlet to provide the call-forwarding service and the address of the application server, which is to execute the servlet to provide the call-forwarding service. Both the servlet identifier string and the address of the applications server are stored as part of a user profile in the HSS 110. These may be down-loaded to the S-CSCF upon user registration.

According to the IMS-related 3GPP specifications and to the SIP servlet container specification, any SIP request within an IMS network that will be forwarded to a service (SIP Servlet) that runs on top of a SIP Application Server (SIP Servlet Container) will have: 'first to match an initial filter criteria at the S-CSCF; 'then to match a rule within the deployment descriptor at the SIP application server.

As with the first embodiment, the embodiment shown in Figure 7 relating to an IP multimedia sub-system operates in order to adapt the SIP request message to include a servlet identifier string from which the servlet or application can be identified within the application server and deployed. The operation of the S-CSCF in

order to deploy the correct application is described in the flow diagram shown in Figure 11, which is summarised as follows: S20 : The S-CSCF receives a request relating to a communications session and removes its own URI from the top most route header position, if present. An example of the request is illustrated in Figure 12.

S22 : The S-CSCF then checks the initial filter criteria, which have been downloaded from the HSS 110 at registration time. The initial filter criteria correspond to the public user identity of the user as illustrated in the inline format in Figure 9.

S24 : For each of the initial filter criteria (iFC) downloaded as part of the user profile, the S-CSCF determines whether each filter criterion is met for the identified user. An iFC is a service to which the user has subscribed. As illustrated in Fig. 10 the class iFC includes an attribute called"priority". This class is to allow the S-CSCF to order the iFCs (where there is more than one) and to process them one by one. The logical expression described by all the trigger points of an iFC has to be met in order to forward the request to the SIP application server AS. An example of the logical trigger points are: Trigger Point 1 is"This is an INVITE Message" Trigger Point 2 is"From header containing"userl"". The iFC for the trigger point provides that"If the received request is an INVITE and the"From"header contains the string"userl", then forward to the SIP applications server AS".

S26 : The check of the iFCs is done until there are no more iFCs to be evaluated (steps S34).

S28 : When there are no more iFCs to be evaluated (independent of the fact that some iFCs may have been triggered by the SIP application server AS) the request is forwarded to the next SIP server towards the end-user.

S30 : If an initial filter criterion is satisfied in that if a trigger point in the filter criteria is met then the S-CSCF recovers the address of the application server AS which is hosting the application. This address is contained in the ServiceName attribute of the application server class in the iFC.

S32 : The S-CSCF adds the SIP application server address in the route header at the top most position.

S34 : The S-CSCF then adds a route header containing its own address and a dialogue identifier in order for the application server 106 to send a message back to the S-CSCF. Adding the route header with the S-CSCF address will allow the SIP message forwarded to the SIP application server AS to come back to the S-CSCF after having been processed by an application (service). Upon reception of this request from the SIP application server AS, the S-CSCF will check if there is still an iFC to be evaluated. If so, then steps S22 to S26 are repeated. If not, the S-CSCF forwards the request to the next SIP server towards the destination address.

S36 : The S-CSCF then parses the application server address within the filter criteria and extracts the user name which is in the form of a service name ("serviceName"). The S-CSCF then modifies the request URI in the received request in order to include the user name ("serviceName") into the SIP URI. The user name is inserted between the SIP URI user name and the host name (in this example SIP: usemame@servicename. homedomain. com). An example of the modified request is illustrated in Figure 13. In Figure 13 the modified SIP URI 160 is shown with a service name"serviceName"introduced into the host name. As illustrated in line 162 the S-CSCF has introduced its own address in order for the application server to return the request.

If the S-CSCF does not find a trigger point within the initial filter criteria, if there is no iFC to be evaluated then the SIP message is routed to the next server, specified by the top-most route address header.

The operation of the application server upon receipt of the modified request is explained by the flow diagram provided in Figure 14a and 14b. Figure 14a illustrates the operation of the deployment descriptor, which is summarised as follows: S40 : The application server receives a modified SIP message.

S42 : The application server receiving the request will use the request URI in order to map the request to the correct servlet. This is the SIP servlet corresponding to the"serviceName". A rule defining where to find the correct SIP servlet name is described within a deployment descriptor (XML based document) within the SIP application server 106. The SIP application server then recovers the service name ("serviceName'^) and determines whether the service name corresponds to an application (SIP servlet).

S44 : If the service name corresponds to a SIP servlet then the SIP application server AS will invoke the corresponding SIP servlet and pass the SIP message to the servlet. The SIP URI should include a recognised address of an application in both the route address and the SIP URI.

S45 : If the address at the appropriate position in the SIP URI is not recognised, then the SIP message is returned to the S-CSCF by removing the top most address (address of the applications server), so that the address of the S-CSCF is the top-most address. The S-CSCF may generate an error message before forwarding the SIP message to the destination address.

The operation of the application after receiving the SIP message from the deployment descriptor and being deployed and the applications server is illustrated in Figure 14b. Figure 14b is summarised as follows: S46 : Before executing the service logic, the application will remove the "serviceName"within the request line and then execute the service. The application will extract the"serviceName"string from the user name part of the SIP URI of the route header and then remove this same user name from the request URI of the request line.

S48 : The application then executes to provide the service in accordance with its service logic.

S50 : The applications server then removes the address of the applications server from the route header at the top most position, so that the address of the S- CSCF becomes the top-most address. The Figure 15 provides an example of a message formed in accordance with the operation of the servlet to reform the address of the terminating user. As can be seen in the invite address line 180, the user name is present but the service name has been removed from the address. The route header now includes the address of the S-CSCF in order to return the request to the S-CSCF.

S52 : The applications server then uses the modified request to return the request to the S-CSCF. The S-CSCF has included two route header addresses, namely the SIP application server AS address and itself. Therefore, at S50, by removing the top most address (its own address), the SIP application server AS can return the SIP message according to the routing rule described by the RFC 3261 to the S-CSCF. The

request will be sent to the address contained in the top most route header, which is the address of the S-CSCF.

S54 : The S-CSCF then remove its own address from the top most route header and (S20) checks whether there are anymore initial filter criteria to be evaluated. If so then as illustrated by the flow diagram in Figure 11, the iFC are evaluated and if appropriate a SIP servlet is triggered (S30). Otherwise, the S-CSCF routes the SIP message according to the SIP routeing procedures (specified in RFC3261) towards the terminating user (S28).

Various modifications may be made to the embodiments of the invention herein before described without departing from the scope of the present invention. It will be appreciated that the Session Initiation Protocol is one example of a communications signalling protocol which can be used to establish an internet protocol communications session and that the present invention finds application with other such protocols.

Various further aspects and features of the present invention are defined in the appended claims.

References [1]: Sip Servlets API version 1.0 (JSR 116)- http ://www. icp. org/en/jsr/detail ? id=116.

[2]: IEFT RFC 3261-SIP Session Initiation Protocol- . llttp ://www. ietf. orglric/rfc3261. txt [3]: 3GPP TS 23.218 : IP Multimedia Session Handling-IP Multimedia Call Model-Stage 2 (Release 5).

[4]: 3GPP TS 23. 228 : IP Multimedia Subsystem-stage 2 (Release 5).

[5]: 3GPP TS. 29. 228: IP Multimedia Subsystem-Cx and Dx interface, signalling flow and message content (Release 5).