WO2009062849A1

WO2009062849A1 - Method, apparatus and program product for merging communication sessions in an ims

Info

Publication number: WO2009062849A1
Application number: PCT/EP2008/064698
Authority: WO
Inventors: Jari Mutikainen; Miikka POIKSELKÄ
Original assignee: Nokia Siemens Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2007-11-13
Filing date: 2008-10-30
Publication date: 2009-05-22
Anticipated expiration: 2010-05-13
Also published as: ZA201002340B; BRPI0820525A8; US20100257273A1; CN101855890A; US9906565B2; AU2008323081A1; BRPI0820525A2; AU2008323081B2; EP2061212B1; CN101855890B; EP2061212A1; US9026663B2; US20150249691A1

Abstract

The present invention relates to a session merging entity in a communication system IMS. The merging entity is handling communication of the first user; the communication comprises a first session and a second session. The first session and the second session are merged into a single session towards the second user, if the same IMS communication service identifier has been indicated for the first session and the second session. The merging entity may also be located at the terminal device of the second user.

Description

METHOD, APPARATUS AND PROGRAM PRODUCT FOR MERGING COMMUNICATION SESSIONS IN AN IMS

5 Technical field of the invention

The invention relates to a network entity, user equip^¬ ment and a method for merging plurality of communication sessions from a first user into a single session towards 10 a second user.

Background of the invention

Within the IP (Internet Protocol) Multimedia Subsystem 15 (IMS) as defined by 3^rd Generation Partnership Project (3GPP) Session Initiation Protocol (SIP) defined by Internet Engineering Task Force (IETF) is used for controlling communication. SIP is an application-layer control protocol for creating, modifying, and terminat- 20 ing sessions with one or more participants. These ses^¬ sions may include Internet multimedia conferences, Internet telephone calls, and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of 25 these.

Different types network entities and functions exist in the IMS network. Call Session Control Functions (CSCF) implement a session control function in SIP layer. The 30 CSCF can act as Proxy CSCF (P-CSCF), Serving CSCF (S-

CSCF) or Interrogating CSCF (I-CSCF) . The P-CSCF is the first contact point for the User Equipment (UE) within the IMS; the S-CSCF actually handles the session states in the network; the I-CSCF is mainly the contact point within an operator's network for all IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area.

The functions performed by the I-CSCF are, for example, assigning an S-CSCF to a user performing SIP registration and routing SIP requests received from another net^¬ work towards the S-CSCF. The S-CSCF performs the ses- sion control services for the UE. It maintains a session state as needed by the network operator for support of the services and may be acting as Registrar, i.e. it ac^¬ cepts registration requests and makes its information available through the location server (e.g. HSS) . The S- CSCF is the central point to users that are hosted by this S-CSCF. The S-CSCF provides services to registered and unregistered users when it is assigned to these us^¬ ers. This assignment is stored in the Home Subscriber Server (HSS) .

An Application Server (AS) is offering value added IP multimedia (IM) services to users of the IMS network and resides either in the IMS user's home network or in a third party location. The third party could be a network or simply a stand-alone AS. The AS may host and execute various services and can influence and impact a SIP ses^¬ sion on behalf of the services. The IP multimedia Sub^¬ system Service Control Interface (ISC) interface is be^¬ tween the S-CSCF and the service platforms (i.e. Ass) . The ISC interface offers extended services to subscrib^¬ ers. ASs that are connected to the IMS are controlled via ISC interface. The protocol used on the ISC inter^¬ face is the SIP. A media gateway control function (MGCF) acts as an in- terworking point between a circuit switched (CS) network and an IP network in the control plane of the network. The MGCF controls the parts of the call state related to connection control for media channels in a media gateway (MGW) , communicates with call state control, and per^¬ forms protocol conversion between the call control pro^¬ tocols, such as SIP and ISUP.

Telephony Application Server (TAS) is a SIP-AS providing the network support for multimedia telephony services. Such services may include call forwarding, call trans^¬ fer, conference call, call hold and other well known services from traditional circuit switched telephone networks .

The 3GPP is specifying multimedia session continuity (MMSC) which defines procedures for session continuity using SIP mechanisms. The MMSC is to include procedures where the UE moves from first access technology to sec^¬ ond access technology, e.g. from wireless local area network (WLAN) to universal terrestrial radio access network (UTRAN) , and the complete SIP session or part of the media components in the session continues seamlessly in the new access. Similar procedures should work also conjunction with voice call continuity (VCC), i.e. where the voice session is transferred from/to CS domain using VCC, but the SIP session is transferred using MMSC pro^¬ cedures. Also it should cover procedures where the ses- sions or media components in the session are transferred between multiple devices.

A session split/merge application server (AS) is a network entity responsible to represent a single SIP ses- sion towards the other end, even if the UE needs to use separate sessions in his end. The split/merge AS is also responsible to split and merge the session on fly in middle of the access transfer procedure. For example, if the UE is engaged in a SIP session in WLAN that includes voice over IP (VoIP) speech component and video sharing media, and the UE then moves from WLAN access to UTRAN access where VoIP is not possible or preferred, the UE should perform VCC procedure for the speech media, in order to transfer the speech to CS over UTRAN and transfer the video sharing SIP session to packet switched (PS) over UTRAN. The role of the split/merge AS in this scenario is to combine the speech and video sharing ses^¬ sions after the access transfer and hide the session split from the UE in the other end. In other words, the UE in the other end may receive media updates (e.g. SIP re-INVITE requests) due to the access transfer, but the other end should not realize that the session has been split into two due to access transfer.

The split/merge AS should merge together the speech ses^¬ sions it receives via MGCF, and SIP sessions it receives via P-CSCF, S-CSCF and present them as a single session towards the other end. The problem is that the split/merge AS should not merge the sessions that belong to different services. Otherwise the network is not able to route the sessions correctly to proper servers.

The object of the invention is to overcome the above problems . Summary of the invention

The present invention overcomes the above problem by providing session handling entity, a method and a com- puter program, comprising: handling communication of a first user, the communication comprising a first session and a second session, and handling the communication of the first session and the second session of the first user towards a second user and arranged to merge the first session and the second session into a single session towards the second user, if the same communication service identifier has been indicated for the first session and the second ses- sion. The communication may be handled using Session Initiation Protocol (SIP) .

Merging the first session and the second session may comprise re-negotiating an ongoing session to wards the second user.

During establishment of the second session, it may the determined that the session handling entity already maintains the ongoing session for the first user towards the second user, and the merging may comprise merging the second session into the ongoing session in response to the establishment of the second session. The ongoing session towards the second user may comprise media of the first session and the merging may add media of sec^¬ ond session into the ongoing session.

The re-negotiation of the ongoing session may comprise transmitting a re-INVITE or an UPDATE request of Session Initiation Protocol (SIP) . The communication service identifier may comprise an IMS Communication Service Identifier (ICSI) or an IMS Application Reference Identifier (IARI) or an Open Mobile Alliance feature tag. The IMS Communication Service Iden- tifier may is indicate IMS Multimedia Telephony service (MMt el) .

The session handling entity may be implemented in a mul^¬ timedia session continuity application server (MMSC AS) , a session split and merge function (SSMF) an IMS centralized services application server (ICS AS) or an ses^¬ sion initiation protocol application server.

The first session and the second session may carry dif- ferent media types. The media types may be either speech, video, instant messaging, push-to-talk, file transfer or image sharing or other media.

The merging multimedia sessions may comprise controlling communication of a first user, the communication comprising a first session and a second session; determining if communication service identifiers are indicated for the first session and for the second ses- sion, and if the communication service identifiers for the first session and the second session are the same, merging the first session and the second session into a single session towards a second user.

The session handling entity may be implemented at a ter^¬ minal device of the second user and the handling the communication towards the second user may comprise rep^¬ resenting the merged sessions as a single application to the second user, if the first session and the second session are merged into the single session towards the second user.

The present invention has the advantage that it provides logic to merge sessions at the IMS network so as to con^¬ tinue the communication towards the other party in a single session, i.e. without the other party has to in^¬ volve a new session. The invention defines the condi^¬ tions when a session can be merged into an ongoing ses- sion and when this cannot be done. The merge logic should not merge the sessions that belong to different services, otherwise the problem would be that the net^¬ work cannot route the sessions correctly to proper serv^¬ ers .

Description of drawings :

Figure 1 illustrates an embodiment of the invention in which the split/merge AS decides to merge two sessions.

Figure 2 presents an aspect of the invention in which the split/merge AS decides to keep two session sepa^¬ rated.

Figure 3 illustrates the internal structure and func^¬ tions of the split/merge AS.

Detailed description of the invention

The 3GPP communication service identity framework de^¬ fines an IMS Communication Service Identifier (ICSI) that may be used to indicate the requested service in the initial request of the IMS session. The ICSI is pre- sented as Uniform Resource Name (URN) . URN is a Uniform Resource Identifier (URI) that uses so-called urn scheme, and does not imply availability of the identi^¬ fied resource.

IMS Multimedia Telephony service (MMtel) is an example service that is having ICSI value. URN used to define the ICSI for the IMS Mutimedia Telephony Communication Service :

urn : urn-xxx : 3gpp-service . ims . icsi .mintel .

MMtel URN may be used to indicate that the device sup^¬ ports the IMS Multimedia Telephony Communication Ser- vice .

The network part of the MMt el service is implemented in a Telephony Application Server (TAS) . An MMtel session may consist of multiple media components, for example audio, video, messaging (e.g. using messaging session relay protocol, MSRP) , file transfer, image sharing, etc. All IMS sessions that include the ICSI value for MMtel should be routed to the TAS in order to execute the MMtel service in proper manner. Also public switched telephone network (PSTN) or CS network originated ses^¬ sions shall be considered as an MMtel session which in^¬ cludes only audio as a media component, or both audio and video in case of a CS video telephony. For PSTN or CS network originated sessions an originating-MGCF in- eludes the ICSI value for MMtel for sessions it initi^¬ ates .

Open Mobile Alliance (OMA) has defined IMS services, for example instant messaging (IM), which consist of similar media than MMtel, except voice and video. OMA-IM does not use the ICSI framework, but has defined similar mechanism to identify the IM sessions. For this purpose OMA uses a dedicated feature tag. Also OMA-IM has a net- work server (IM AS) which implements the network part of the service and where the IM sessions need to be routed.

Multimedia session transfer is a transfer at the IMS- level of one or more of the session signalling paths and associated media paths of an ongoing multimedia session while maintaining session continuity. The multimedia session transfer incorporates both access network transfer and UE transfer. Multimedia session continuity is service of the IMS which supports the use of multimedia session transfer mechanisms in order to handle terminal mobility events and/or mobility between UEs for the case when such events are not hidden from the IMS session layer and thus session continuity could not otherwise be maintained. Access network transfer is a transfer at the IMS-level of both the signalling path and media path of an ongoing multimedia session on a UE from PS to CS domain or vice versa or between different IP connec^¬ tivity access networks (IP-CAN) .

In general, the continuity of multimedia services refers to the capability of continuing ongoing communication sessions with multiple media across different access networks or across different user equipments (UEs) . The main need for such continuity arises because (i) UEs with multimedia capabilities can move across a multi^¬ plicity of different access networks or because (ii) the users can move the media of their communication sessions across different UEs to best meet their communication preferences. Transfer of a multimedia session to a dif- ferent access network may lead to loss of synchroniza^¬ tion across various media components (e.g. across voice and video components) . The session continuity solution may take such synchronization issues into account for assuring the best user experience.

For the scenario of PS-PS multimedia session continuity:

All or some ongoing media components in the source access network are transferred to the target access net- work. If it is not possible or not desired (e.g. due to operator policies) to transfer all media, then part of the media components are transferred and the remaining component (s) are either released or kept. . For example it may not be possible to transfer some media components to the target access network due to limited target ac^¬ cess network capabilities. The selection of media to be transferred may depend on the solution used to realize the session transfer

If possible and if allowed (e.g. by user prefer- ences and/or operator policies) some media components may remain in the source access network.

The source and the target access network can in^¬ clude both 3GPP IP access systems and non-3GPP IP access systems (e.g. WiMAX) . - After the UE hands over to the target access net^¬ work the same or a different P-CSCF may be used. The so^¬ lution for PS-PS multimedia session continuity should cope with both cases.

The PS-PS session continuity in conjunction with PS-CS continuity refers to a particular case of multimedia session continuity in which a session with media on both the CS domain and the PS domain is transferred to an ac^¬ cess network supporting only packet switched (PS) commu- nications, or vice versa. The transfer of the session is required due to user' s movement from one access network (source) to another access network (target) . The typical characteristic of this case is that one access network supports real-time media (usually voice) only on the CS domain (e.g. GERAN or UTRAN) whereas the other access network supports both real-time media and non-real-time media on PS bearers (e.g. E-UTRAN, WiMAX, or WLAN) . To maintain a high-quality of user experience, the session is transferred to and continued on the target access network as seamlessly as possible.

For the scenario of PS-PS session continuity in conjunc^¬ tion with PS-CS continuity the following behavior may be relevant :

One access network (either the source or the tar^¬ get) supports voice on the CS domain only (such as UTRAN or GERAN) , while the other access network supports voice and non-voice components on IP transport bearers (such as WLAN, WiMAX or E-UTRAN) .

If the target access network supports voice on the CS domain only, then a voice component may be trans^¬ ferred to the CS domain and drop the remaining non-voice component (s) . - If possible and if allowed (e.g. by user prefer^¬ ences and/or operator policies) some non-voice media components may remain in the source access network.

If the target access network supports video on the CS domain, then voice and video components may be trans- ferred to the CS domain and all other components can be transferred to the PS domain.

If the target access network supports all media on IP transport bearers, then all media components active in the CS and PS domain of the source network may be transferred to IP transport bearers.

The invention proposes the split/merge AS to use ICSI for making a decision whether sessions are to be merged or not .

Therefore logic in the split/merge AS is introduced to determine an ICSI value in a received session, and if the ICSI matches to the ICSI in the existing session be^¬ tween the same users, then the decision is made to merge the sessions, otherwise the sessions are not merged.

Example scenarios are presented in following figures.

Figure 1 presents a scenario where a UE 1 initiates, in signal 11, a circuit switched (CS) call towards the other end (e.g. UE 2) through a CS network 3..An S-CSCF 6 executes initial filter criteria (iFC) and a session split and merge application server (SM-AS 9) is allo^¬ cated to the session path. The session path traverses the CS network 3 and an MGCF 4 to the split/merge AS 9 over ISC interface. However, it is to be noted that other ways exist to route a session setup from the UE 1 to the split/merge AS 9. For example, the session setup may pass through the MGCF 4 and an I-CSCF (not shown in the figure), instead of the S-CSCF 6. In step 12, the split/merge AS 9 determines that the session includes ICSI with value MMTeI. In signal 13 the split/merge AS 9 passes the session further back to S-CSCF 6. The S-CSCF 6 continues iFC execution and the session is routed to TAS 7, which executes the actual service logic for mul^¬ timedia telephony service. Later on during the voice call, in signal 14, the UE 1 initiates a video sharing session with the same other end (UE 2) . UE 1 includes ICSI with value MMTeI for the session. The session is routed through a P-CSCF 5 to the S-CSCF 6. The S-CSCF 6 executes the iFC and the session is routed to the split/merge AS 9. In step 15 the split/merge AS 9 deter^¬ mines that it maintains an existing session with the same participants (UE 1 and UE 2), and that the ICSI values of the existing session and the new (video shar^¬ ing) session are equal. Thus split/merge AS 9 considers that the sessions belong together, and in signal 16, the split/merge AS 9 sends a re-INVITE towards the other end (UE 2) . The re-INVITE is routed to S-CSCF 6 which then follows the existing path for the session, and routes the re-INVITE to the TAS 7. The TAS 7 executes the ac- tual service for MMTeI.

Figure 2 presents a scenario where the UE 1 initiates, in signal 21, a CS call towards the other end (UE 2) . An S-CSCF 6 executes the iFC and an split/merge AS 9 is al- located to the session path. In step 22, the split/merge AS 9 determines that the session includes ICSI with value MMTeI. In signal 23 the split/merge AS 9 passes the session further back to S-CSCF 6. The S-CSCF 6 continues iFC execution and the session is routed to a TAS 7, which executes the actual service logic for multime^¬ dia telephony service. Until this point the description of Fig 2 corresponds to the description of Fig 1. Later on during the voice call, in signal 24, the UE 1 initi^¬ ates a file transfer session (difference to Fig 1) with the same other end (UE 2) . The UE 1 does not include

ICSI value, but includes OMA IM indicator instead. The session is routed to the S-CSCF 6. The S-CSCF 6 executes the iFC and the session is routed to the split/merge AS 9. In step 25, the split/merge AS 9 determines that it maintains an existing session with the same participants (UE 1, UE 2), but that the ICSI values are different. In other words, the new request 24 does not include ICSI with value MMTeI, but OMA IM indicator instead. The OMA IM indicator may replace ICSI in the same field. Thus the split/merge AS 9 considers the sessions do not be^¬ long together, and in signal 26 generates a new INVITE towards the other end (UE 2) . The INVITE is routed to S- CSCF 6 which then executes the iFC for the new session and routes the INVITE to an OMA-IM AS 8. The IM-AS exe^¬ cutes the actual service for OMA-IM service.

Thus, by determining the same ICSI for both sessions be^¬ tween the same endpoints the split/merge AS decides that the sessions can be merged towards the other end. If the ICSI values do not match, or one of the sessions does not have ICSI value (but instead may include e.g. OMA feature tag for identifying the service) , the sessions are not merged. In one aspect of the invention the sessions of a first user are to be merged towards a second user based on matching OMA feature tags indicating the same service.

In one aspect of the invention, a split/merge AS merges the sessions only if ICSI with value MMTeI has been in^¬ dicated for both sessions of the first user, i.e. for other matching ICSI (or OMA feature tag) values the ses^¬ sions are not merged.

In one aspect of the invention and IMS Application Ref^¬ erence Identifier (IARI) values of the sessions of a first user are compared in a similar way as ICSI values above. The IARI is coded as a URN. The IARI URN may be included as a quoted string as a value of the g. ims . app_ref media feature tag. An example of a g. ims . app_ref media feature tag containing an IARI is: g. ims . app_ref="<urn :urn-xxx : telephony .3gpp . mmt el- application-vl>"

In this aspect of the invention sessions of a first user are to be merged towards a second user based on matching IARI values.

Figure 3 presents the internal structure and functions of the network entity 30 implementing the session merge function, such as split/merge AS 9. The network entity 30 comprises a first session handling unit 31 configured to handle SIP sessions of a first user participating the communication. A second session unit 32 is configured to handle SIP sessions towards a second user participating the communication. The second session unit 32 is arranged to merge a session (s) handled by the first ses^¬ sion unit 31 into a single session towards the second user. A determination unit 33 is configured to determine if an ICSI is indicated for a session handled by the first session handling unit 31. The ICSI may be present in a received SIP request. If the ICSI is detected the determination unit 33 is also configured to recognize the ICSI value. The network entity 30 comprises a main^¬ taining unit 34 configured to maintain information about ongoing sessions in the network entity 30, participants of the sessions and possible ICSI values determined for the sessions. During establishing a new session, the determination unit 33 determines a possible ICSI value for the new session. If such is found, the maintaining unit 34 checks if there already exists an ongoing ses^¬ sion with the same participants (i.e. users) and with the same ICSI value. If such a session is found, the second session unit 32 is merging the new session into the ongoing session towards the second user, i.e. to^¬ wards the party from whose side the new request did not arrive. The second session unit 32 may merge the session by transmitting a SIP re-INVITE or a SIP UPDATE request which modifies the ongoing session by adding media components of the new session to the ongoing session. The determination unit 33 and maintaining unit 34 may detect, recognize and compare also OMA feature tags iden- tifying OMA services or IARI values and order a session merge based on matching OMA feature tags or IARI values . The units described above may be implemented e.g using microprocessors and/or other electrical components and/or by software.

In one aspect of the invention, similar split/merge logic is implemented at user equipment (UE) . The UE is having more than one ongoing SIP sessions towards the network, but based on matching ICSI, IARI or OMA feature tag values the UE may merge two or more of the session into a single session towards the user. The (end) user sees the merged session as a single application. This aspect has the benefit that even if the terminal device of the second user (e.g. UE 2 in Fig 1) receives two sessions in signaling level, only one application is visible to the end user of the device (UE 2) . The termi^¬ nal device (UE 2) may merge the sessions internally even if the network does not support merge/split logic.

The invention is not limited to IMS networks, but may also be applied in other networks having similar session splitting and merging entity role as split/merge AS and in which networks various medias are used for communica^¬ tion. Therefore, the split/merge AS is only used here as an example of an entity responsible for handling session merging. A Session Split and Merge Function (SSMF), a Multimedia Session Continuity Application Server (MMSC AS) and an IMS Centralized Services Application Server (ICS AS) are further examples of network nodes which may implement session splitting and merging operations ac^¬ cording to this invention. Functions of the split/merge AS described above may be implemented by code means, as software, and loaded into memory of a computer.

Claims

1. A session handling entity (9, 30) in a communica^¬ tion system, comprising: first session means (31) for handling communication of a first user (UE 1), the communication comprising a first session (11, 21) and a second session (14, 24); second session means (32, 33) for handling the communication of the first session (11, 21) and the second session (14, 24) of the first user (UE 1) towards a sec^¬ ond user (UE 2) and arranged to merge the first session (11) and the second session (14) into a single session (13, 16) towards the second user (UE 2), if the same communication service identifier has been indicated for the first session (11, 21) and the second session (14, 24) .

2. The session handling entity (9, 30) of claim 1, wherein the first session means (31) is configured to handle the communication of the first user using Session Initiation Protocol (SIP) .

3. The session handling entity (9, 30) of claim 1 or 2, wherein the second session means (32, 33) is config- ured to handle the communication towards the second user using Session Initiation Protocol (SIP) .

4. The session handling entity (9, 30) of any of claim 1 to 3, wherein the single session (13, 16) comprises an ongoing session (13) towards the second user (UE 2) and the merging the first session (11) and the second ses^¬ sion (14) comprises re-negotiating the ongoing session (13) .

5. The session handling entity (9, 30) of claim 4, further comprising means for determining (34), during establishment of the second session (14,24), that the session handling entity (9, 30) already maintains the ongoing session (13) for the first user (UE 1) towards the second user (UE 2), and wherein the merging comprises merging the second session (14) into the ongoing session (13, 16) in response to the establishment of the second session (14) .

6. The session handling entity (9, 30) of claim 4 or 5, wherein the ongoing session (13) towards the second user comprises media of the first session (11) and the merging adds (16) media of second session (14) into the ongoing session (13, 16) .

7. The session handling entity (9, 30) of any of claims 4 to 6, wherein the re-negotiation of the ongoing session (16) comprises transmitting a re-INVITE or an UPDATE request of Session Initiation Protocol (SIP) .

8. The session handling entity (9, 30) of any of pre^¬ ceding claims, wherein the communication service identifier comprises one of an IMS Communication Service Iden- tifier (ICSI) and an IMS Application Reference Identi^¬ fier (IARI) .

9. The session handling entity (9, 30) of claim 8, wherein the IMS Communication Service Identifier is in- dicating IMS Multimedia Telephony service (MMt el) .

10. The session handling entity (9, 30) of any of pre^¬ ceding claims, wherein the session handling entity comprises one of a multimedia session continuity applica- tion server (MMSC AS) , a session split and merge func^¬ tion (SSMF) an IMS centralized services application server (ICS AS) or a session initiation protocol application server.

11. The session handling entity (9, 30) of any of pre^¬ ceding claims, wherein the first session (11, 21) and the second session (14, 24) are carrying different media types .

12. The session handling entity (9, 30) of claim 11, wherein the said media types are selected from speech, video, instant messaging, push-to-talk, file transfer and image sharing.

13. A method of merging multimedia sessions in a communication system, comprising: controlling communication of a first user (12, 15), the communication comprising a first session (11, 21) and a second session (14, 24); determining (12, 15) if communication service identifiers are indicated for the first session (11, 21) and for the second session (14, 24) . wherein, if the communication service identifiers for the first session (11) and the second session (14) are the same, merging the first session (11) and the second session (14) into a single session (13, 16) to^¬ wards a second user.

14. The method of claim 13, wherein controlling the communication of the first user (12, 15) comprises using Session Initiation Protocol (SIP) .

15. The method of claim 13 or 14, wherein the single session (13, 16) towards the second user is controlled using Session Initiation Protocol (SIP) .

16. The method of any of claims 13 to 15, wherein the single session 13, 16) comprises an ongoing session (13) towards the second user and the merging the first ses^¬ sion (11) and the second session (14) comprises re^¬ negotiating the ongoing session (16) .

17. The method of claim 16, further comprising determining (15), during establishment of the second session

(14), existence of the ongoing session of the first user towards the second user (13), and wherein the merging comprises merging the second session (14) into the ongo^¬ ing session (16) in response to the establishment of the second session (14) .

18. The method of claim 16 or 17, wherein the ongoing session (13) towards the second user (UE 2) comprises media of the first session (11) and the merging adds (16) media of second session (14) into the ongoing ses^¬ sion (16) .

19. The method of any of claims 16 to 18, wherein the re-negotiation of the ongoing session (16) comprises transmitting a re-INVITE or an UPDATE request of Session Initiation Protocol (SIP) .

20. The method of any of claim 13 to 19, wherein the communication service identifier comprises one of an IMS Communication Service Identifier (ICSI) and an IMS Application Reference Identifier (IARI) .

21. The method of any of claim 13 to 19, wherein the communication service identifier comprises an Open Mo^¬ bile Alliance feature tag.

22. The method of claim 20, further comprising deter^¬ mining that the IMS Communication Service Identifier is indicating IMS Multimedia Telephony service (MMtel) .

23. The method of any of claims 13 to 22, wherein the first session (11, 21) and the second session (14, 24) are carrying different media types.

24. The method of claim 23, wherein the said media types are selected from speech, video, instant messag- ing, push-to-talk, file transfer and image sharing.

25. A computer program product comprising code means adapted to produce the steps of any one of claims 13-23 when loaded into the memory of a computer.

26. The session handling entity (9, 30) of claim 1, wherein the session handling entity (9, 30) comprises a terminal device of the second user (UE 2) and wherein the merging the first session (11) and the second ses- sion (14) into the single session towards the second user by the second session means comprises representing the merged sessions (11, 14) as a single application to the second user.