Background to the Invention IP Multimedia (IPMM) services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the numbers of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia"services which are considered in more detail below.

IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over 3G mobile communication networks (3GPP TS 23.228 and TS 24.229 Release 5 and Release 6). IMS provides key features to enrich the end-user person-to- person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network.

The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and web servers).

The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Others protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP), Message

Session Relay Protocol (MSRP), Hyper Text Transfer Protocol (HTTP). IMS requires an access network which would typically be a 2G/3G General Packet Radio Service (GPRS)/Packet Switched (PS) network, but which might be some other access network such as fixed broadband or WiFi. Figure 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network.

An example of a combinational IP Multimedia service is a multimedia service that includes and combines both a Circuit Switched media (such as voice) and a Packet Switched media over the IP Multimedia domain (such as pictures, video, presence, instant messages, etc. ). A service referred to here as"WeShare" combines the full IP Multimedia Subsystem (IMS) benefits of a multimedia service with CS voice. The service enables an end-user during a Circuit Switched (CS) voice conversation to immediately share content with another end-user. Such content may include (but is not limited to): zea picture taken during the conversation with the terminal's in-built camera, or a pre-stored picture (WeShare Image service feature); a one-way live video of, for example, the immediate physical surroundings, captured during the conversation with the terminal's in-built camera (WeShare Video service feature); . a video clip recorded during the conversation with the terminal's in-built camera, a pre-stored video clip with a sequence recorded previously or downloaded from the Web (WeShare Clip service feature).

Either party in the conversation may initiate transmission of content to the other party.

Figure 2 illustrates the WeShare combinational service and service features.

The introduction into the market of services such as WeShare puts a number of new requirements on the current IMS architecture and on the IMS/SIP-enabled terminal behaviour. Problems with current IMS technology mean that it is not capable of fulfilling all the above requirements. These problems are: 1.3GPP does not specify any specific service. Rather, 3GPP defines the

overall architecture for IP Multimedia services and its protocols (mainly SIP).

It is out of the scope of 3GPP as to how the protocols are used for each service, and what the service logic should be.

2.3GPP does not specify any architecture nor service solution that supports combinational IP Multimedia services, such as WeShare services.

Summary of the Invention The main characteristics resulting from the introduction of services such as WeShare and the impact on network and terminal behaviour are: WeShare services always include the combination of a CS call and an IMS (over PS) session. WeShare is a service that enriches an already established CS voice call. The end users shall perceive the enriched call as ONE multimedia call/service.

A WeShare service is able to indicate to the user whether or not the service has good chance of succeeding before the user actually tries to send content. Each party involved in the CS call shall discover if it is possible to send content to the other party. A user shall be able to use WeShare services when two conditions are met: 1 the sending user has a valid subscription to one or more WeShare services features; 2 both parties involved in the CS conversation have a WeShare capable terminal supporting the subscribed service feature.

. A user can subscribe to any of the WeShare service features in any combination. It is the task of the"service authorization discovery"procedure to find out which service features a user has subscribed to.

A UE may not support all WeShare service features. It is the task of the "service capability discovery"procedure to find out which service features are supported by the remote UE.

After IMS user registration, the UE (WeShare client) enters the"service authorization discovery"phase. If the UE learns that the user is not authorized to use the WeShare service (i. e. not subscribed to any of the WeShare service features), then the"service capability discovery"phase is skipped. If the user has authorization, then the UE enters the"service capability discovery"under the following conditions: 1 The first time is after service authorization discovery at initial registration.

The capability discovery is then initiated for all those E. 164 numbers in the phone book which are identified as mobile subscriber numbers.

2 Periodically for all those E. 164 numbers in the phone book which are identified as mobile subscriber numbers. Intervals could be as long as once every two weeks.

3 Whenever a single new E. 164 number identified as a mobile subscriber number is added to the phonebook. The capability discovery is invoked only on that number.

4 During a CS call which is made with an end user that does not exist in the phone book. The capability discovery is invoked only with the remote end user of the ongoing CS call.

According to conditions 1 to 3 above, the service capabilities of the remote UE are discovered regardless of whether or not a CS call is established, thus avoiding the need to launch the discovery procedure for each and every CS call. On the other hand, according to condition 4 the discovery procedure is launched during the established CS call.

Therefore, the purpose of the discovery process is to establish if these necessary conditions are met; when they are met the discovery is considered successful. As a result of a successful discovery process the terminal indicates to the human user the service features availability, e. g. by activating a"blinking icon"for each available service features. If the discovery fails, no service feature availability is indicated to the human user.

The WeShare service shall be easy to use; e. g. a party with a WeShare

capable terminal performs the following actions: 1) uses the built-in camera to take a picture; 2) looks at the picture to see if it is OK to be sent; 3) pushes/clicks on the button/icon (that is activated) to send the picture to the other party in the ongoing CS conversation.

To invoke a WeShare multimedia service, the user does not need to enter any further address besides the E. 164 number used to establish the CS call.

When a party presses the WeShare button to send content (e. g. image, clip, video) to the other party for the first time during an ongoing CS call, an IMS session establishment shall be initiated between the sending party's UE and the receiving party's UE. The IMS session establishment signalling (SIP/SDP) carries information on the WeShare service feature being invoked and the media/content. The receiving party is prompted for its consent to receive such WeShare content. If the receiving party answers with a positive consent, then the IMS session is successfully established and the content transfer is started. No further request for consent will be needed during the ongoing CS call. If the receiving party refuses consent, the IMS session establishment is aborted, the content transmission does not start, and the sending party is informed accordingly. The sending party implicitly provides its consent/willingness to receive content when he/she presses the WeShare button/icon to start content sharing.

Upon successful transfer, the sending party shall be informed that the content has been rendered on the receiving party's UE.

The present invention aims to overcome the problems identified above by defining a simple and general sequence logic for WeShare services that can be used to standardize the IMS terminal behaviour in the context of such services.

A WeShare Client (application-specific logic in the UE) and a WeShare Application Server (service logic) are introduced into the IMS. The main functionalities of the WeShare Client are: authorization discovery, remote UE

capability discovery, user interaction, and send/receive content. The main functionalities of the WeShare Application Server are: service authorization, user-plane handling, policing (e. g. allowed content type/size), and charging.

The WeShare Application Server and the UE support IMS SIP and SDP in the control-plane, and a set of user-plane protocols for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP), Message Session Relay Protocol (MSRP), Hyper Text Transfer Protocol (HTTP), and possibly others. Also, the UE/WeShare Client provides the necessary coordination between the CS and IMS/PS components of the multimedia session (e. g. the UE releases the SIP session as soon as the associated CS call is released).

According to a first aspect of the present invention there is provided a method of establishing a combinational multimedia session between at least two end user terminals, the method comprising: discovering at each end user terminal the end user authorization to use the multimedia service; subsequently establishing a circuit switched connection between the end user terminals via one or more telecommunication networks; upon successful discovery of end user authorization to use the multimedia service and prior to or following the establishment of said circuit switched connection, discovering at each end user terminal the multimedia capabilities of the or each other terminal; and whilst the circuit switched connection is established, establishing an IP multimedia subsystem session between the end user terminals via one or more IP multimedia subsystem networks, and transferring IP multimedia information between the user terminals, said multimedia information relating to a service supported by both or all user terminals.

Preferably, said end user authorization to use the multimedia service is established at each end user terminal automatically (following IMS registration).

This may be initiated at the application layer within each user terminal. More preferably, the process of discovering user authorization at a terminal

comprises the steps of sending a request from the end user terminal to the server hosting the service. The server responds by returning the list of services authorized to the end user.

Preferably, said multimedia capabilities of the terminal are established at each user terminal automatically (following successful authorization discovery) prior to or following the establishment of a circuit switched connection. This may be initiated at the application layer within each user terminal. More preferably, the process of discovering capabilities at a terminal comprises the steps of sending a capability request from a first of the terminals, e. g. the call initiating terminal, to the or each other terminal. This request includes the capabilities of the first terminal. The or each receiving terminal responds by returning its capabilities in a capability response message to the first terminal. The capability discovery request and response messages may be SIP messages.

Preferably, the transfer of said multimedia information can be triggered by the pressing of a single button on a user terminal.

Preferably, the method comprises providing an indication, e. g. visual or audio, to a user that multimedia information transfer between terminals is possible and/or not possible.

Preferably, the steps of establishing service authorization (service subscription) and of transferring multimedia information comprise routing signalling and user data through an IMS server arranged to control the provision of said combinational multimedia service.

According to a second aspect of the present invention there is provided a method of discovering, at a user terminal, the end user's own service authorization in respect of a combinational multimedia service facilitated by an IP multimedia subsystem, the method comprising: sending a SIP OPTIONS request message from the user terminal to a Serving Call Session Control Function node of the IP multimedia subsystem,

the OPTIONS request message including in a URI field a Public Service Identity identifying a SIP application server; routing the OPTIONS request message to the SIP application server on the basis of the Public Service Identity ; and in response to receipt of the OPTIONS request message at the application server, returning a SIP OPTIONS response message to the user terminal containing the list of services the end user is authorized to use.

Preferably, the SIP OPTIONS response is a SIP 200 OK message.

According to a third aspect of the present invention there is provided a method of routing a SIP message from a Serving Call Session Control Function to a SIP Application Server, the message including in a Request URI field thereof, a Public Service Identity which uniquely identifies the IMS service to which the message relates, the method comprising: at the Serving Call Session Control Function, inspecting the Request URI field to identify the Public Service Identity ; and mapping the Public Service Identity to an IP address of a SIP application server, and forwarding the message to that SIP application server using the IP address.

According to a fourth aspect of the present invention there is provided a method of discovering, at a user terminal, the supported capabilities of a remote terminal in respect of a combinational multimedia service facilitated by an IP multimedia subsystem, the method comprising: sending a SIP OPTIONS request message from the user terminal to a Serving Call Session Control Function node of the IP multimedia subsystem, the OPTIONS request message including in a URI field a Public User Identity identifying the remote end user; routing the OPTIONS request message to the remote terminal on the basis of the Public User Identity ; and in response to receipt of the OPTIONS request message at the remote terminal, returning a SIP OPTIONS response message to the enquiring terminal

containing the supported capabilities of the remote terminal.

According to a fifth aspect of the present invention there is provided a method of providing in a user terminal, information to an end user identifying the service availability in respect of a combinational multimedia service, the method comprising: at the user terminal, determining service availability from discovered service authorization information for the end user, local terminal capability information, and capability information obtained for a remote terminal; and providing a visual indication to the end user of the service availability in respect of the combinational multimedia service.

According to a sixth aspect of the present invention there is provided a method of setting up a multimedia session during an established circuit switched call, facilitated by an IP multimedia subsystem, the method comprising: sending a SIP INVITE request message from an initiating user terminal to a Serving Call Session Control Function node of the IP multimedia subsystem, the INVITE request message including in a URI field a Public Service Identity identifying the service, and including the identity of a remote user in the body of the message; at the Serving Call Session Control Function, inspecting the Request URI field to identify the Public Service Identity ; mapping the Public Service Identity to an IP address of a SIP application server, and forwarding the message to that SIP application server using the IP address; at said SIP application server, authorizing the sender and, if authorized, routing the INVITE request message to the remote user's terminal on the basis of the Public User Identity found in the body of the message; and in response to receipt of the INVITE request message at the remote user's terminal, returning a SIP INVITE response message to the originating user terminal indicating whether the invitation to establish a multimedia session is accepted.

Brief Description of the Drawings Figure 1 illustrates schematically the IMS architecture within a 3G network; Figure 2 illustrates schematically the WeShare service and service feature; Figure 3 shows signalling associated with the WeShare service ; and Figure 4 illustrates schematically the WeShare service architecture.

Detailed Description of Certain Embodiments There is illustrated in Figure 3 the signalling exchanged between two user terminals (A and B) and network nodes, associated with a WeShare service, where: Solid arrows represent SIP protocol messages, . Dashed arrows represent MSRP (Message Session Relay Protocol) messages or similar, and Arrows between"User"and"UA"boxes represent user interaction.

In particular, Figure 3 refers to: An intra-operator (i. e. one network) scenario, where : IMS Core A is serving User A ; IMS Core B is serving User B; the same WeShare Server is serving both User A and User B.

. A WeShare Image service feature scenario (although the same scenario applies to other WeShare service features including the WeShare Clip service feature, and most of the signalling applies to any WeShare XX service feature).

Four main signalling phases can be identified as follows : Phase 1-CS session set-up and discovery phase (signalling steps 1 to 9 in Figure 3) Steps 1. & 2. UE-A and UE-B register to their-own serving IMS Core; this is typically done when the UE is turned on.

Steps 3. & 4. After IMS registration, UE-A discovers User-A's WeShare service authorization (i. e. service subscription) at the serving WeShare server. UE-B discovers User-B's WeShare service authorization (i. e. service subscription) at the serving WeShare server.

Step 5. User-A establishes a voice call with User-B using the Circuit Switched domain.

Steps 6. & 7. Each UE discovers the WeShare terminal capability of the remote UE. Since either of the two parties can send images, each of the UEs needs to perform its own capability discovery process. For each UE to enter the terminal capability discovery step, the following conditions must be met: The UE is registered with the IMS network, . The authorization discovery step has detected a subscription to the WeShare service, The UE is involved in an established CS call, and The WeShare capabilities of the remote UE (e. g. UE-B) are not known to the local UE (e. g. UE-A) from an earlier capability discovery procedure (see below for further details).

Steps 8. & 9. A user shall be informed (e. g. via a blinking icon) when it is possible to transmit images to the other party. The WeShare service availability indication is given to the users when two conditions are met: The sending user has a valid WeShare subscription to one or more features (i. e. has authorization to use the service), and Both users have a WeShare capable terminal that supports the subscribed features.

During phase 1 the end users are not allowed to send or receive images.

The procedure for IMS registration uses the SIP REGISTER message. The procedure for service authorization discovery and remote terminal capability discovery uses the SIP OPTIONS message.

Phase 2-WeShare session set-up phase (signalling steps 10 to 15 in Figure 3) Step 10. User-A takes a picture and pushes the WeShare button to send the image to User-B. A user, who has been given an indication of WeShare service availability, shall be able to prepare the image (e. g. by pressing a button to take a photograph with an in-built camera) and transmit it to the other party by pressing a WeShare button. The transmitting party's terminal may generate a query, e. g. confirm image, after presenting the image to its user, requesting that the user presses once again the button to initiate transmission. A user, who has been given an indication of WeShare service availability, may also be able to select pre-stored content in his/her terminal's memory and transmit this content to the other party in the conversation.

Step 11. A WeShare IMS session set-up request towards the B-party is initiated.

Step 12 to 15. Upon receiving a WeShare IMS session set-up request, the receiving UE will prompt the receiving user to ask whether he/she would like to enrich the CS call to a WeShare multimedia session (i. e. whether he/she would like to accept the content/image). If the receiving UE accepts, network resources will be reserved, and the WeShare IMS session will be successfully established. If the receiver refuses then the sender is informed accordingly, and the PtS session is aborted.

The procedure for setting up the WeShare session and reserving resources for the session uses the SIP INVITE, SIP 200 OK for SIP INVITE, and SIP ACK messages, along with the SDP Offer/Answer model. The negotiation of type and size of the image is accomplished via the SDP Offer/Answer model within the SIP INVITE, SIP 200 OK for SIP INVITE, and SIP ACK messages.

Phase 3-Image transfer phase (signalling steps 16 to 26 in Figure 3)

Steps 16. to 26. The transmission of the image may be initiated when two conditions are met: a) The sending UE has received confirmation that it can send images, and b) The sending user has confirmed which image to send.

Condition (a) is verified when the sending UE receives confirmation of a successful WeShare session set-up; condition (b) is verified when the sender has pressed the confirm image button to push a specific image. Hence the image transmission begins when user-A presses the confirmation button and lasts until the content reception response (successful or not) has been received by the sending terminal. A transfer state indication is given to the user.

Either of the parties in a CS voice conversation may receive and send images to the other party.

Steps 20. & 26. Upon successful image transmission, the network produces charging reports for billing of the users.

The procedure for the sending UE to send an image uses the MSRP SEND message over a TCP connection.

Phase 4-WeShare session tear down (signalling steps 27 to 29 in Figure 3) Steps 27. to 29. As soon as the CS voice call is terminated, the IMS WeShare session is released, and all resources allocated to the IMS session shall be released.

The procedure for tearing down the WeShare session uses the SIP BYE message. The procedure used for releasing the MSRP resources is to close the TCP connection.

The WeShare service architecture is further illustrated in Figure 4 and is based

on the IMS as defined in 3GPP R5/R6, 23.228 and 24.229, with the addition of a WeShare client and WeShare server functional entities. The UE is the terminal equipment containing the WeShare XX client (application software).

Every WeShare XX service will use a Type A terminal [3GPP TS 23.060].

The IMS core includes the Proxy-, Interrogating-and Serving-Call Session Control Functions (P-, I-, and S-CSCF) and the Home Subscriber Server (HSS), as defined in 3GPP R5/R6 TS 23.228 and TS 24. 229. The IMS Core performs the following functions: -Routes the SIP signalling between the UE and the WeShare server; - Terminates the SIP compression from the terminal; - Performs IMS authentication and authorisation; - Maintains the registration state and the SIP session state; and -Reports to the charging system.

The UE shall send all SIP messages to the IP address of the P-GSCF (outbound proxy) after resolving the SIP URI of the P-CSCF to an IP address.

The WeShare Server handles the WeShare XX service. The WeShare server performs the following functions: - Handles SIP signalling ; - Authorises access to the WeShare XX service; - Handles user-plane for the WeShare XX service; - Reports to the charging system; - Applies policy by enforcing the rule that the content transferred in the user plane conforms to the WeShare XX service contract (e. g. maximum image/clip size, image/clip/video encoding types); - Monitors the WeShare XX content transmission and notifies of transmission failure.

The CS Core contains MSC/VLR, GMSC, HLR and possibly other logical elements according to 3GPP R5/R6 TS 23.002.

The signalling illustrated in Figure 3 will now be considered in more detail.

The user terminals of A and B register with the IMS using SIP. Each terminal sends a SIP REGISTER message according to 3GPP R5/R6 TS 23. 228 and TS 24.229, including in the message the supported terminal's capabilities (e. g. media feature tags). Such terminal capabilities will be used for routing a SIP request towards the right terminal. This is typically carried out immediately following power-up of the user terminals.

Immediately following IMS registration, both users (A and B) discover their subscription information (authorisation to use the WeShare services) by contacting their respective WeShare Application Servers. This procedure makes use of the SIP OPTIONS message. The SIP OPTIONS request is addressed to the Public Service Identity (PSI) of the WeShare Service (e. g.

WeShare@operator. com), and this identity is included in the Request URI of the OPTIONS message. The S-CSCF routes the OPTIONS messages to the WeShare Application Server on the basis of the PSI. Upon receipt of an OPTIONS request message, the WeShare Application Server responds by returning to the enquiring UE an OPTIONS response (i. e. SIP 200 OK) message containing the authorised service information of the user (i. e. a list of media feature tags).

After a successful service authorization discovery process, the terminal capability discovery process is initiated.

The terminal capability discovery at the remote UE may occur prior to a CS call being established between user A and user B (e. g. the terminal capability discovery is initiated for all those E. 164 numbers in the phone book that are marked up as"mobile"numbers). This procedure is discussed further below.

The case which will be considered now is that where the terminal capability discovery occurs once a CS call has been established (possibly because user B's E. 164 number is not in user A's address book).

Once a CS call has been set up by user A to user B (i. e. by user A dialling the

E. 164 number of user B and user B answering the call), user A's terminal sends a SIP OPTIONS request message to user B's terminal. The sending of the SIP OPTIONS request message may be initiated automatically, with the whole capability exchange process being invisible to the users.

The SIP OPTIONS request includes user B's E. 164 number (used to establish the CS call) in the Request-URI header. The IMS Core serving user A translates user B's E. 164 number to a SIP Universal Resource Identity (URI), such as"userb@ericsson. com", by contacting an ENUM/DNS or via some other means, and routes the message to user B's terminal, through the IMS Core serving B. In response to receipt of the SIP OPTIONS request message, user B's terminal generates a SIP 200 OK response message (for the OPTIONS request) including the multimedia capabilities of the terminal (e. g. including a list a media feature tags). The SIP 200 OK response message is routed via the IMS Core serving user B and the IMS Core serving user A, to user A's terminal.

The same OPTIONS request and OPTIONS response exchange is repeated when user B sends an OPTIONS request message to A. Thereafter each terminal knows the capabilities supported for use during the ongoing CS call.

When the following three conditions are met for one or more WeShare service features: Subscription authorization of the local user has been obtained, The capability of the local user's terminal (part of the terminal local settings) has been determined, and The capability of the remote user's terminal determined (via the capability discovery) then a message is displayed at each user terminal to show that the WeShare service features are active. Icons may be displayed to indicate the available WeShare service features, e. g. a still camera to indicate WeShare image, a video camera to indicate WeShare video.

Using the procedure described above, the network/service operators can ensure that the capabilities available on the terminals are used only if the users

of those terminals have a subscription to the service. This discovery procedure can be generalized to all services identified by media feature tags.

An important requirement for the WeShare service to be successful is user friendliness and ease of use. In particular, once user A has dialled the E. 164 number to establish the CS speech call to the B user, no other identities (i. e. <BR> <BR> numbers, URIs, etc. ) should need to be entered by the users in order to use the WeShare service. The users should merely have to push a button (soft or hard key) on their terminals to, for example, take a picture and then push one further button to send the picture.

The fMS network accepts E. 164 identities. Once the calling user's S-CSCF is reached, the identity must be translated to a SIP URI. Such translation is done by querying for example a DNS ENUM server. This could be done for each SIP message sent during a given CS call. Nevertheless, the SIP OPTIONS exchange may be used to provide the Public User Identity SIP URI (or"address of record") of each user to its peer. Each user gets the SIP URI of the other user from the OPTIONS request FROM field.

Subsequent SIP transactions and/or SIP dialogues relating to the same WeShare service call could use the SIP URI saved from the SIP OPTIONS exchange, and would thus not require a further DNS ENUM translation to be performed.

This solution of using the OPTIONS exchange may be applied to any service, not just WeShare (or other CS+PS services) that use the OPTIONS exchange before invoking the service.

In the procedure described above, capability discovery for the remote user terminal is performed following establishment of a CS call. In an alternative procedure, this discovery may be carried out prior to initiation of a CS call under the following conditions: 'The first time following service authorization of a user, after initial IMS

registration, capability discovery is initiated for all those E. 164 numbers in the phone book of the user's terminal which are identified as mobile subscriber numbers.

Periodically for all those E. 164 numbers in the phone book which are identified as mobile subscriber numbers. Intervals could be as long as once every two weeks.

Whenever a single new E. 164 number identified as a mobile subscriber number is added to the phone book, capability discovery is invoked only on that number.

As will be apparent from the above discussion, the provision of WeShare services requires, for authorization, charging and control purposes, that SIP sessions related to a WeShare service pass through the WeShare Application Server (within the IMS) hosting this service. For instance, the S-CSCF node which receives SIP messages must be able to distinguish SIP sessions that are set up for WeShare, from other session setups, in order to route the message to the correct WeShare Application Server. Using the standard IMS initial filter criteria (which relies upon message headers or Session Description Protocol), it may not always be possible to identify the service for which a SIP message (e. g. INVITE) has been issued. It is unlikely that there will be a"media feature tag"specified for each and every IMS service.

Differentiating between session setup messages related to various kind of session requires looking into the Session Description Protocol (SDP) field for the presence (or absence) of a particular protocol in a so-called"m-line" (i. e. media line) For instance, differentiating between a WeShare Image/Clip related setup message and an instant messaging-based Chat service related setup message, both using"a messaging session as media type", requires something more, either in the SDP or in the SIP headers (e. g. Accept-Contact with a specific feature tag).

A preferred mechanism for identifying the service that a particular SIP message (e. g. a SIP INVITE or OPTIONS message) might have been issued for, requires

the inclusion of a Public Service Identity (PSI) in the Request-URt fieid. An example of a PSI identifying a particular WeShare service might be "WeShare@operator. com". This mechanism has the significant advantage that it does not require standardisation as the PS) s are only required to be unique within a given operator's network. The filter criteria based on the contents of the Request-URI field is relatively simple to define.

The use of a mechanism which triggers the forwarding of a SIP INVITE from the S-CSCF towards an Application Server based on the Request-URI provides a simple way for the S-CSCF to route the SIP message. No extra filter criterion is needed in the Home Subscription Server (HSS) to identify services which a user does not have. Filter criteria are only stored for services that a user has.

Initial filter criteria processing in the S-CSCF is simplified when the initial filter criteria is the PSI to be matched to the Request-URI.

Table 1 below defines certain terms used in this document.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention. es*criiition lms 3GPP name for IP Multimedia Subsystem. IMS 3GPP name for IP Multimedla Subsystem. IP Multimedia A Multimedia Service, based on IMS. In this document it also refers to the System. Combinational Refers to the combination of real-time service component over CS with a non real-time service component over PS/IMS. Conversational Refers to the real-time media component of a multimedia service. WeShare Stands for"Instant Share". A family of combinational services. WeShare XX A specific WeShare service, e. g."WeShare Image". Client Application software in the UE ; e. g. WeShare client. Application Server Server hosting and executing service logic for one or more services ; e. g. WeShare Application Server. CS Circuit Switched PS Packet Switched PtS Push to Show S-CSCF Serving Call Session Control Function HSS Home Subscriber Server URI Universal Resource Information UE User Equipment. 3GPP name for user terminal.

Table 1