EP1692838A1

EP1692838A1 - System for providing services in response to a communications session message

Info

Publication number: EP1692838A1
Application number: EP03799472A
Authority: EP
Inventors: Dimitri Dekeyzer; Jogesh Patel
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2003-12-01
Filing date: 2003-12-01
Publication date: 2006-08-23
Also published as: AU2003299301A1; WO2005055549A1

Abstract

A system is provided for deploying at least one service in response to a communications session message. The system comprises a session initiation protocol (SIP) server responsive to the session message to identify one of a plurality of servlets, each of the servlets providing a predefined service to a user and a servlet container. The servlet container is operable to host and to invoke the plurality of servlets. The SIP server is operable to respond to the SIP 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 usemame part of the universal resource identifier, the servlet string identifying the servlet for providing the required service. The session message is also modified by introducing the servlet string identifier into a header of the session message, which header can be read by the servlet container. 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 session servlet.

Description

SYSTEM FOR PROVIDING SERVICES IN RESPONSE TO A COMMUNICATIONS SESSION MESSAGE

Field of the Invention The present invention relates to systems for providing services in response to a communications session message. 5 In some embodiments the session message is a Session Initiation Protocol (SEP) 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 10 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 15 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 multimedia 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 20 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. 25 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 30 network includes a SD? server and a service node. The SD? 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 SD? 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 usemame 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 SD? 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 usemame part of the top most route header address is empty, then the servlet does not have to remove any part of the SD? URI of the request-line. The usemame part of the top most route header address will be empty, if the SD? Server has an alternative mechanism for sending the session message to the right SD? 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 SD? server, the session message being a SD? message or request and the servlet container is a SD? servlet container. In other embodiments the SD? 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 SD? 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 (SD?

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 SD? server appearing in Figure i; 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 SD? initiation request; Figure 13 is an illustration of the SD? 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 SD? 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 SD? 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 SD? server 1 via a connecting channel 8, which may also form part of the packet switched network. Also connected to the SEP server 1 are first and second SD? servlet containers AS1, AS2. The SEP servlet containers may be part of a SEP application server or service node. The SD? servlet containers are operable to deploy SD? servlets. One of the SEP servlet containers AS1 shown in Figure 1 is also shown in Figure 2 in more detail. In Figure 2 the SD? 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 SD? 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 (SD? 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 SD? 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 SD? server

1. However, as will be appreciated by those acquainted with SEP, the deployment descriptor DD is only permitted to read certain parts of the SEP message. These parts include the addresses within the message header, which includes a SEP URI of a SEP message request line. The operation of the SEP server to introduced the servlet identifier string will now be described. Returning to Figure 1 a dashed line 29 represents the path of a SEP message as received at the SEP server. An example of the SEP message is shown in Figure 3. As shown in Figure 3 the SEP 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 SD? message is labelled "(1)" and shown correspondingly as being received at the SD? server 1 in Figure 1 at position "(1)". Upon receipt of the SEP message the SEP 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 SD? 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 SD? 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 SD? 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 SD? server then changes the SD? message to the effect of introducing the servlet identifier string into a header of the SEP message which can be read by the deployment descriptor DD within the SD? servlet container AS1. Since the deployment descriptor DD can only read the header request line, the "to" header and the "from" header, the SD? server arranges for the servlet identifier string to be introduced as a sub-domain name within the SD? URI provided as one of the headers. Figure 4 shows the effect of the SD? server operating in accordance with an embodiment of the present invention to adapt the SD? 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 SD? 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 SEP URI, the deployment descriptor can recover the servlet identifier string. The deployment descriptor DD can therefore launch the appropriate servlet. Before adapting the SD? initiation message to include the servlet string identifier of the servlet to be deployed, the SD? 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 SD? message can be routed to the SEP servlet container AS1. As explained above, the SD? server 1 also retrieves from the database 6 an indication of the SD? servlet container on which the identified servlet is contained. In order to route the adapted SIP message to the correct SD? servlet container, the SEP server introduces a route address which has a domain name which identifies the correct SD? servlet container AS1. Accordingly, a route address URI is introduced as the topmost address in the SIP message, into the route address line 40 of the SD? message 30. According to the rules for routing a SD? message by a SEP server, the SD? server first checks if there is a route header. If so the SEP server forwards the SD? 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 SD? 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 SD? message to the SIP servlet container AS 1. The SD? 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 SD? server therefore operates to introduce the route address header so that the SIP message can be forwarded to the correct SEP 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 SEP message "(2)" is forwarded to the SEP servlet container using the route address header. As illustrated in Figure 2 the SEP 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 SEP 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 SEP message to that servlet. However, to recover the original SEP message before processing its service logic, the servlet identifies the correct user name or SEP URI. The SEP URI was adapted by the SEP server in order to identify the appropriate servlet which was triggered by the SEP 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 SD? URI 32. This is done by matching the appropriate part of the servlet string identifier from the route header address and the usemame address in the request line. The correct address indicates the destination address of the session message. The servlet therefore forms a SEP message "(3)" shown in Figure 5 with the servlet identifier string removed from the header address. Accordingly, the SEP servlet can use the recovered address to execute the service logic. A flow diagram illustrating the operation of the SEP server in order to forward the SEP message to the appropriate servlet container which will deploy the corresponding servlet in response to the SEP message is provided in Figure 6. The flow diagram provided in Figure 6 is summarised as follows: SI: The SE? server receives a SD? message providing a SD? URI from a particular user having for example a user name "usernamel" . S2: The SD? server identifies the usemame from the SIP URI in the request header of the user to which the message is directed (usernamel). Using the user name "username2" the SD? server interrogates the database and recovers information associated with that usemame 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 aheady 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 SD? server may use "usernamel" to trigger a SD³ servlet. This may also depend on whether the SEP server is operating in association with a terminating user or an originating user of the communications session. S4: In order to route the SEP message to the correct servlet container the SD? server adds a route address to the top most route address header to route the SD? message to this SE? 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 SD? message to the SIP servlet container is inserted as the top most position. The address of the SEP servlet container is stored in the user profile. The usemame 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 SEP URI in the header request line. S6: The SD? server changes the routing address of the SD? URI in the request line of the SD? message to include the servlet string identifier as a sub-domain part of the host domain of the SD? URI. Thus, for example, if the servlet identifying string is "appln2" then the SEP URI in the header request becomes wserflame2@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 SEP URI. The SEP servlet can therefore remove the servlet identifier string before executing the service logic upon reception of the SEP message and when replying to the SEP message. S8: The SD? servlet container then receives the SEP URI as part of the SEP message adapted by the SEP 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 SEP servlet then identifies the identifier string in the request header address of the SEP message, which is received by it. The SEP 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 EP 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 EP multimedia sub-system. A diagram of a simplified version of D? multimedia sub-systems elements is shown in Figure 7. hi Figure 7 a Serving Call State Control Function (S-CSCF) 100 forms part of the D? multimedia sub-system and sends and receives SEP 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 SD? 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 EP 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 inline 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 SD? 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 SEP 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 3 GPP specifications and to the SEP servlet container specification, any SIP request within an EVIS network that will be forwarded to a service (SEP Servlet) that runs on top of a SD? Application Server (SD³ 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 SEP application server. As with the first embodiment, the embodiment shown in Figure 7 relating to an D? multimedia sub-system operates in order to adapt the SD? 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 SEP 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 SEP application server AS) the request is forwarded to the next SEP 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 SEP 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 SE? message forwarded to the SEP 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 SEP 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 SD? 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 SD? URI. The user name is inserted between the SEP URI user name and the host name (in this example SEP:usemame@servicename.homedomain.com). An example of the modified request is illustrated in Figure 13. In Figure 13 the modified SD? 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 SEP 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 SE? 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 SD? servlet corresponding to the "serviceName". A rule defining where to find the correct SD? servlet name is described within a deployment descriptor (XML based document) within the SP application server 106. The SEP application server then recovers the service name ("serviceName") and determines whether the service name corresponds to an application (SD? servlet). S44: If the service name corresponds to a SD? servlet then the SEP application server AS will invoke the corresponding SD? servlet and pass the SEP message to the servlet. The SEP URI should include a recognised address of an application in both the route address and the SEP URI. S45: If the address at the appropriate position in the SEP URI is not recognised, then the SEP 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 SEP message to the destination address. The operation of the application after receiving the SEP 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 SEP application server AS address and itself. Therefore, at S50, by removing the top most address (its own address), the SE? application server AS can return the STB 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 SEP servlet is triggered (S30). Otherwise, the S-CSCF routes the SEP message according to the SEP 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.icρ .org/en/j sr/detail?id= 116. [2]: E3FT RFC 3261 - SE? Session Initiation Protocol - http://www.ietf.org/rfc/rfc3261.txt [3]: 3GPP TS 23.218: E? Multimedia Session Handling - IP Multimedia Call Model - Stage 2 (Release 5). [4]: 3GPP TS 23.228: E? Multimedia Subsystem - stage 2 (Release 5). [5]: 3GPP TS.29.228: E? Multimedia Subsystem - Cx and Dx interface, signalling flow and message content (Release 5).

Claims

1. A system for providing at least one service in response to a communications session message, the system comprising a session protocol server responsive to the 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, and a servlet container operable to host the plurality of servlets, wherein 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 address including a servlet string identifier as a usemame part of the universal resource identifier, the servlet string identifying the servlet for providing the required service, and to introduce the servlet string identifier into a header of the session message which can be read by the servlet container, the servlet container being responsive to the modified session message to deploy the servlet identified by the servlet string identifier read from the session message.

2. A system as claimed in Claim 1, wherein the servlet container includes a deployment descriptor for deploying the servlets, the deployment descriptor being arranged to read the header fields of the session message, the session protocol server being operable to introduce the servlet string identifier into one of the headers which can be read by the deployment descriptor.

3. A system as claimed in Claim 1 or 2, wherein the deployed servlet is operable to parse the header fields and the route address of the session message for the servlet string identifier, and to identify the servlet string identifier from both a session initiation header and the route address, to reproduce an original form of the session message by removing the servlet string identifier, before executing service logic provided by the service.

4. A system as claimed in Claim 1, 2 or 3, wherein the session protocol server is provided with the servlet identifier string in association with a usemame of a user for which a request for the service provided by the servlet has been registered and an identifier of a servlet container where the servlet is contained.

5. A system as claimed in Claim 4, including a data store for storing user profile data in association with a usemame, the profile data including the servlet identifier string and the identifier of the servlet container where the servlet is contained, the profile data being provided to the session protocol server for depolying the servlet in response to the session message.

6. A system as claimed in any preceding Claim, wherein the session protocol server is provided with at least one filter criterion, the filter criterion providing a logical condition to be satisfied for triggering a servlet, and a servlet string identifier providing an identification of the servlet to be triggered with an identifier of the servlet container on which the servlet is hosted, the session protocol servlet being operable to modify the session message to include a route address for routing the session message to the servlet container indicated by the identifier for the servlet container and to introduce the servlet string identifier into a header of the session message, if the logical conditions provided by the filiter criterion are satisfied.

7. A system as claimed in Claim 6, including a data store for storing user profile data in association with a usemame, the profile data including the filter criterion.

8. A system as claimed in Claim 6 or 7, wherein the logical conditions provided by the filter criterion include a type of the session message, an address in the header of the session message or a usemame.

9. A system as claimed in Claim 6, 7 or 8, wherein the session protocol server is provided with a plurality of filter criteria, each filter criterion providing a logical condition to be satisfied, a servlet string identifier providing an identification of a servlet and an identifier of the servlet container, wherein the server is operable for each of the filter criterion to determine whether the logical conditions are satisfied by 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, to provide the servlet string identifier as a usemame part of the universal resource indicator, to identify the servlet to be deployed, to introduce the servlet string identifier into a header of the session message which can be read by the servlet container, and to modify the session message to provide a route address of the session protocol server for returning the session message to the session protocol server after execution of service logic by the servlet.

10. A system as claimed in any preceding Claim, wherein the session protocol server is a serving call state control function (S-SCSCF), the servlet container being an application server and the servlet includes an application according to a multi-media sub-system.

11. A system as claimed in Claim 10, wherein the multi-media sub-system is as specified by the 3GPP standard for mobile radio telecommunications.

12. A session protocol server for deploying at least one servlet in response to a communications session message, the server being responsive to the session message to identify one of a plurality of servlets, each of the servlets being arranged to provide a service to a user, to identify a servlet container on which the identified servlet is hosted, 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 address including a servlet string identifier as a usemame part of the universal resource identifier, the servlet string identifying the servlet for providing the service, and to introduce the servlet string identifier into a header of the session message which can be read by the servlet container.

13. A session protocol server as claimed in Claim 12, wherein the session protocol server is provided with the servlet identifier string in association with a usemame of a user for which a request for the service provided by the servlet has been registered and an identifier of a servlet container where the servlet is host.

14. A session protocol server as claimed in Claim 12, wherein the session protocol server is provided with at least one filter criterion, the filter criterion providing a logical condition to be satisfied for triggering a servlet, a servlet string identifier providing an identification of the servlet to be triggered and an identifier of the servlet container on which the servlet is hosted, the session protocol servlet being operable to modify the session message to include a route address for routing the session message to the servlet container provided by the identifier for the servlet container and to introduce the servlet string identifier into a header of the session message, if the logical conditions provided by the filiter criterion are satisfied.

15. A session protocol server as claimed in Claim 14, including a data store for storing user profile data in association with a usemame, the profile data including the filter criterion.

16. A session protocol server as claimed in Claim 14 or 15, wherein the logical conditions provided by the filter criterion include a type of the session message, and address in the header of the session message or a usemame.

17. A session protocol server as claimed in Claim 14, 15 or 16, wherein the session protocol server is provided with a plurality of filter criteria, each filter criterion providing a logical condition to be satisfied, a servlet string identifier providing an identification of a servlet and an identifier of a servlet container on which the servlet is hosted, wherein the server is operable for each of the filter criterion to determine whether the logical conditions are satisfied by 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 address including the servlet string identifier as a user name part of the universal resource identifier, to identify the servlet to be deployed, to introduce the servlet string identifier into a header of the session message which can be read by the servlet container, and to modify the session message to provide a route address of the session protocol server for returning the session message to the session protocol server after execution of service logic by the servlet.

18. A server according to any of Claims 12 to 17, wherein the server forms a serving call state control function (S-SCSCF) of a multi-media sub-system of the 3GPP standard.

19. A servlet for providing at least one service in response to a session communications message, the servlet being identified by a string, the servlet being operable to parse the header fields and the route address of the session message for the servlet string identifier, and if a servlet string identifier, identifying the servlet is present in both a session initiation header and the route address, to form an address for responding to the session message by removing the servlet string identifier from the session initiation header.

20. A servlet according to Claim 19, wherein the servlet forms an application of a multi-media sub-system according to the 3 GPP standard.

21. A method for providing at least one service in response to a communications session, the method comprising identifying one of a plurality of servlets, in response to the session message, each of the servlets providing a predefined service to a user, and hosting the plurality of servlets on a servlet container, modifying 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 address including a servlet string identifier as a usemame part of the universal resource identifier, the servlet string identifying the servlet for providing the session initiation service, introducing the servlet string identifier into a header of the session message which can be read by the servlet container, and deploying the servlet identifed by the servlet string identifier read from the modified session message, by the servlet container.

22. A method as claimed in Claim 21, the method comprising parsing the header fields and the route address of the session message for the servlet string identifier, identifying the servlet string identifier from both a session header which can be read by the servlet, and the route address, and forming an address for responding to the session message by removing the servlet string identifier from the session initiation header.

23. A computer software program providing a set of executable instructions for performing the method according to Claim 21 or 22.

24. A medium providing the computer software program claimed in Claim 23.

25. A medium as claimed in Claim 24, wherein the medium is a readable hardware medium.