WO2008082203A1 - Method for merging and splitting of sessions in session based applications like ims applications simple im and poc - Google Patents

Method for merging and splitting of sessions in session based applications like ims applications simple im and poc Download PDF

Info

Publication number
WO2008082203A1
WO2008082203A1 PCT/KR2007/006968 KR2007006968W WO2008082203A1 WO 2008082203 A1 WO2008082203 A1 WO 2008082203A1 KR 2007006968 W KR2007006968 W KR 2007006968W WO 2008082203 A1 WO2008082203 A1 WO 2008082203A1
Authority
WO
WIPO (PCT)
Prior art keywords
session
request
controlling function
sending
sessions
Prior art date
Application number
PCT/KR2007/006968
Other languages
French (fr)
Inventor
Sang-Kyung Sung
Venkateswar Jeedigunta
Mayuresh Madhukar Patil
Original Assignee
Samsung Electronics Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co., Ltd. filed Critical Samsung Electronics Co., Ltd.
Publication of WO2008082203A1 publication Critical patent/WO2008082203A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/4061Push-to services, e.g. push-to-talk or push-to-video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/148Migration or transfer of sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04Real-time or near real-time messaging, e.g. instant messaging [IM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10Push-to-Talk [PTT] or Push-On-Call services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/40Connection management for selective distribution or broadcast
    • H04W76/45Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services

Definitions

  • This invention in general relates to the field of session based applications like POC and SIMPLE IM.
  • This invention relates to group communication applications like POC and IM, where multiple group sessions are possible.
  • This invention relates to SIP technology protocol. More specifically this invention relates to system and method for merging and splitting of sessions in session based applications like IMS applications simple IM and POC.
  • IMS based application like POC and SIMPLE IM uses SIP session control procedure for establishing group communication sessions.
  • SIP does not support the merging of two or more group sessions.
  • splitting of group into two sessions is required.
  • SIP also does not support this procedure.
  • This invention proposes the SIP extensions to support this feature for merging the two or more sessions and splitting two sessions into two or more groups.
  • IMS based application like POC and SIMPLE IM uses SIP session control procedure of creation of a session.
  • SIP procedure allows initiating one to one session and group sessions.
  • Group session could be Pre-arranged sessions or Ad-Hoc sessions.
  • User can have simultaneous sessions. It is beneficial in some cases to allow user to merge a session or split a session in two or more groups.
  • One group session is poc groups, which is discussing on PoC related topics.
  • Second session is im group, which is discussing on SIMPLE IM related topics.
  • PoC group discussing on important issue which is common to SIMPLE IM group as well, in this case user wants to merge two groups into one group.
  • a SIP procedure does not allow mechanism to merge the ongoing sessions or split sessions into two sessions.
  • User needs to tear down the current on-going sessions and then create a new session for merged group. This required lots of signaling from the User side.
  • User need to send the terminate signal for current ongoing signal and then send the separate invite for the each split sessions. This requires lot of signaling from the client device which can waste lot of wireless resources.
  • the present invention proposes a method which allows user to send only one request for merging of sessions.
  • the proposed method simplifies the merging of sessions with single request.
  • the present invention provides the system and methods which allow user to send single request for splitting of the session into two or more sessions.
  • the present invention extends the SIP procedure and allow user to send the request for merging and for splitting of sessions.
  • the present invention further provides two methods for the merging and two methods for splitting of the sessions.
  • the invention explains a method to facilitate merging and splitting of user sessions wherein merging operation comprising the steps of : a user selecting groups to be merged; sending a merge initiator signal to a controlling function; sending invites to other users in the group by the controlling function; and merging the interested users together,
  • Splitting operation comprising the steps of: sending a splitting initiator signal to the controlling function; the controlling function inviting the concerned users regarding the split; and splitting the interested users.
  • the present invention aims to provide the system and methods for enabling the users to initiate the merging and splitting of sessions.
  • This invention initially discuss merging of session which provides two methods first method uses INVITE method and second method uses REFER method. These methods extend the INVITE and REFER methods for initiating the merging request. Similarly, invention extends the INVITE and REFER methods for initiating splitting request.
  • the present invention provide a user two sessions.
  • this inventions allows merging two groups into one group, and splitting of sessings into two or more groups in more groups.
  • the present invention extends the SIP procedure and allows a user to send the request for merging and for splitting of sessions. User does not need to tear down the current on-going sessions nor create a new session for merged group. So a lot of signaling from the user side does not waste lots of wireless resources.
  • Figure 1 illustrates System architecture for INVITE based method for merging of sessions
  • FIG. 2 illustrates Basic Flow diagrams
  • Figure 3 illustrates Terminating side Flow diagram: On demand session case
  • Figure 4 illustrates Terminating side Flow diagram: Pre-establish session case
  • Figure 5 illustrates Sending BYE to user who reject the REINVITE
  • Figure 6 illustrates Schema format for Merged Invite Body
  • Figure 7 illustrates System architecture for REFER based merging of merging of sessions
  • Figure 8 illustrates Logical flows for REFER based method for merging of sessions
  • FIG. 9 illustrates INVITE method for splitting of sessions
  • Figure 10 illustrates Flow diagram for session split with INVITE request
  • FIG 11 illustrates REFER method for splitting of sessions
  • Figure 12 illustrates Flow diagram for session splitting using REFER method
  • FIG. 13 illustrates Schema format for splitting of sessions
  • Figure 14 illustrates Including new user into a merged session
  • Figure 15 illustrates Excluding user from a merged session.
  • this section explains the detail solution for splitting and merging of session. Firstly, it discusses about merging of session then followed by splitting of sessions.
  • This part of invention deals with merging of sessions.
  • two methods are proposed. First method uses INVITE method and other method uses REFER method. These methods are discussed next. In this proposal assumption is that session ids are know to user who initiate the merging request.
  • This method uses INVITE method for sending of merging request.
  • Client A is initiator of merging request.
  • Session Ll User B, User C, User D, and User A
  • Session L2 User G, User F, User E, and User A
  • Controlling function is common to both sessions.
  • user sends ESTVITE request with session type URI parameter and merging indicator, e.g., set as "Ad- hoc+SessionMerge" Note a new tag is proposed to identify this request as merging request.
  • Client A wants to merge two sessions Ll, and L2.
  • Request URI of this INVITE request will be set to conference factory URI.
  • Controlling function receives the Merge INVITE request. Controlling function also extract the body to identify the sessions to be merged. Controlling function sends the RE-INVITE with new session parameters to all users of session Ll and session L2. Controlling function also add tag +SessionMerge in the session URI parameter. Controlling function also adds information about the other session information, so that user can decide on to join the session or not. Controlling function also can send the group advertisement before sending the RE-INVITE so that user knows merging of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 200OK response. All users are aware of the session merge situation by group advertisement and information in a RE-INVITE request. Controlling function also create the merged conference package for general notification about the merged session. This is a general proposed method using INVITE. Figure 2 explains the procedure in detail.
  • Client A wants to initiate the merge request, Sends a INVITE request a. Including SessionMerge parameter in session URI parameter in Request-URI header. b. Request-URI header field contains conference factory URI c. INVITE Body will include session ids of sessions to be merged d. INVITE body can also have optional information for including and excluding of users into merged sessions is Client A is authorized to do so. 2. Controlling function receives this invite request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URI header a. Controlling function creates new session parameter and new session ids for merged sessions b.Extract body of invite to identify the sessions to be merged
  • Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one
  • Controlling function then sends the RE-INVITE to all users a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b.
  • Merged session id and session parameters c.
  • REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
  • Client B device sends the 200 OK response to merged request.
  • Controlling function forwards a 200 OK response to Client A device.
  • Controlling function sends the notification about the merged session information.
  • Figure 3 explains the flow diagram case for terminating side in case of On-demand session: a. Controlling function sends the RE-INVITE to Participating function with all details about merging of session b. Participating server forwards the request to Client device c. Client device send the 200OK response to participating function d. Participating function forwards the request to controlling function Figure 4 explains Terminating side Flow diagram: Pre-establish session case:
  • Participating server send MBCP DISCONNECT message in RTCP protocol with reason of DISCONNECT as merging of session 3.
  • Client device sends MBCP Talk Burst Acknowledgement response to DISCONNECT message
  • Participating server send MBCP CONNECT message in RTCP protocol with information about the new session parameters
  • Client device sends MBCP Talk Burst Acknowledgement response to CONNECT message
  • INVITE based method is used for merging of the two sessions.
  • FIG. 6 shows, schema structure should be included in the Merged INVITE request.
  • Schema has root element called SessionMerge.
  • SessionMerge element has one element called Session. This element is used to include session ids of sessions to be merged. This element has two attributes one is SessionID and other is NoofUser.
  • SessionID is used to specify the ID of sessions. NoofUser is option attribute and generally it is added by controlling function to give information about other sessions to users of session. Session has child element called UserName, which is used by controlling function to indicate the users in the session. Session Merge also has two optional elements for excluding and including any users from the merged session.
  • This method uses REFER method for sending of merging request. As shown in the Figure 7. This method actually adds other sessions to one session to create a merged session.
  • Client A is initiator of merging request.
  • Session Ll User B, User C, User D, and User A
  • Session L2 User G, User F, User E, and User A
  • Controlling function is common to both sessions.
  • user sends REFER request with session URI parameter set as "Ad-hoc+SessionMerge"
  • Client A wants to merge two sessions Ll, and L2.
  • For this Client send REFER request and add the +SessionMerge tag in session URI parameter in Request URI header field e.g.
  • Request-URI:sip:sessonl@networkB.net;session Ad-Hoc+SessionMerge?.
  • Client A also adds the session information into the body of the session merge INVITE request.
  • Client A adds session ids of sessions to be merged.
  • Request URI of this INVITE request will be set to Ll session id.
  • Controlling function receives the Merge REFER request. Controlling function also extract the body to identify the sessions to be merged. Controlling function sends the RE-INVITE with new session parameters to all users of session L2. Controlling function also add tag +SessionMerge in the session URI parameter. Controlling function also adds information about the other session, so that user can decide on to join the session or not. Controlling function also can send group advertisement before sending the RE-INVITE so that user knows merging of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 200 OK response. All users are aware of the session merge situation by group advertisement and information in a RE-INVITE request. Controlling function also create the merged conference package for general notification about the merged session. This is a general proposed method using REFER. Figure 8 explains the procedure in detail.
  • Client A wants to initiate the merge request, Sends a REFER request a. +SessionMerge parameter in session URI parameter in Request-URI header. b. Request-URI header field contains Ll session Id c. REFER-TO field contains reference to REFER body d. REFER Body will include session ids of sessions to be merged e. REFER body can also have optional information for including and excluding of users into merged sessions is Client A is authorized to do so.
  • Controlling function receives this REFER request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URI header. a. Send 202 Accepted response to Client A b. Extract body of REFER to identify the sessions to be merged to current session
  • Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one
  • Controlling function then sends the RE-INVITE to all users of L2 session a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b.
  • REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not
  • Client B device sends the 200 OK response to merged request
  • Controlling function send the NOTIFY to Client A to indicate the status related to REFER request
  • This part of the invention deals with splitting of sessions.
  • two methods are proposed. First method uses INVITE method and other method uses RFER method. These methods are discussed next.
  • this proposal assumption is that hierarchical group definition is stored in controlling function or in controlling function XDMS.
  • This proposal also considers the situation for ad-hoc group splitting case, where user split the session in ad-hoc fashion.
  • This method uses INVITE method for sending of splitting request.
  • Client A is initiator of splitting request.
  • Session Ll (User B, User C, User D, User A, User G, User F, and User E).
  • user sends INVITE request with session URI parameter set as ⁇ d-hoc+SessionSplit?
  • session URI parameter set as ⁇ d-hoc+SessionSplit?
  • Client A wants to split current session. For this Client send INVITE request and add the +SessionSplit tag in session URI parameter in Request URI header field e.g.
  • Request- URI:sip:sessonl@networkB.net;session Ad-Hoc+SessionMerge?.
  • Client A also adds the group information into the body of the session split INVITE request.
  • Client A adds group URIs which identifies the groups into which session needs to be split.
  • Ad-hoc split client A also adds user names in each group so that two group sessions are created in Ad-Hoc fashion.
  • Request URI of this INVITE request will be set to session id of current session.
  • Controlling function receives the split INVITE request. Controlling function also extract the body to identify the groups into which session needs to be split. Controlling function sends the RE-INVITE with new session parameters to all users. Controlling function also add tag +SessionSplit in the session URI parameter. Controlling function also adds information about group, so that user can decide on to join the session or not. Controlling function also can send the group advertisement before sending the RE-INVITE so that user knows splitting of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 200OK response. All users are aware of the session split situation by group advertisement and information in a RE-INVITE request. Controlling function also create the conference package for each group; general notification about the session. This is a general proposed method using INVITE. Figure 10 explains the procedure in detail.
  • Client A wants to initiate the split request, Sends a INVITE request a. +SessionSplit parameter in session URI parameter in Request-URI header. b. Request-URI header field contains session id of current session c. INVITE Body will include groups URIs and also can have user names in each group for Ad-hoc splitting d. INVITE body can also have optional information for including and excluding of users into each group sessions if Client A is authorized to do so.
  • Controlling function receives this invite request and identifies it as a split request by seeing the +SessionSplit tag in Request-URI header. a. Controlling function creates new session parameter and new session ids for other sessions b. Extract body of invite to identify the groups
  • Controlling function sends the group advertisement to each user of sessions to indicate the splitting of session in to two
  • Controlling function then sends the RE-INVITE to all users a. +SessionSplit tag to identify it as splitting invite, so that client can retrieve session parameter from RE-INVITE request b. split session id and session parameters c.
  • REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
  • Client B device sends the 200 OK response to split request
  • Controlling function forwards a 200 OK response to Client A device.
  • split INVITE request will be used by the client device to initiate the split request.
  • This method uses REFER method for sending of splitting request.
  • Client A is initiator of splitting request.
  • Session Ll (User B, User C, User D, User A, User G, User F, and User E).
  • user sends REFER request with session URI parameter set as ⁇ ] d-hoc+SessionSplit?
  • session URI parameter set as ⁇ ] d-hoc+SessionSplit?
  • Client A also adds the group information into the body of the session split REFER request.
  • Client A adds group URIs which identifies the groups into which session needs to be split.
  • group URI which identifies the groups into which session needs to be split.
  • Request URI of this REFER request will be set to session id of current session.
  • REFER-TO is set to reference to body of REFER request.
  • Controlling function receives the split REFER request. Controlling function also extract the body to identify the groups into which session it needs to split. Controlling function sends the RE-INVITE with new session parameters to all users. Controlling function also add tag +SessionSplit in the session URI parameter. Controlling function also adds information about group, so that user can decide on to join the session or not. Controlling function also can send the group advertisement before sending the RE-INVITE so that user knows splitting of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 200OK response. All users are aware of the session split situation by group advertisement and information in a RE-INVITE request. Controlling function also create the conference package for each group; general notification about the session. This is a general proposed method using REFER. Figure 12 explains the Flow diagram for sessions splitting using REFER method.
  • Client A wants to initiate the split request, Sends a REFER request a. +SessionSplit parameter in session URI parameter in Request-URI header. b. Request-URI header field contains current session Id c. REFER-TO field contains reference to REFER body d. REFER Body will include Group ids of sessions
  • REFER body can also have optional information for including and excluding of users into Split sessions if Client A is authorized to do so.
  • Controlling function receives this REFER request and identify it as a Split request by seeing the +SessionSplit tag in Request-URI header a. Send 202 Accepted response to Client A b. Extract body of REFER to identify the sessions to be split from current session
  • Controlling function sends the group advertisement to each user of sessions to indicate the Split of session in to two
  • Controlling function then sends the RE-INVITE to all users of Gl session a. +SessionSplit tag to identify it as Splitting invite, so that client can retrieve session parameter from RE-INVITE request b.
  • REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the session or not
  • Client B device sends the 200 OK response to Split request
  • Controlling function send the NOTIFY to Client A to indicate the status related to REFER request
  • split REFER request will be used by the client device to initiate the split request.
  • Figure 13 shows, schema structure should be included in the Split INVITE request.
  • Schema has root element called SessionSplit.
  • SessionSplit element has one element called Group. This element is used to include group ids. This element has two attributes one is Group URL and other is NoofUser.
  • Group URL is used to specify the URL of group.
  • NoofUser is option attribute and generally, it is added by controlling function to give information about other sessions to users of session.
  • Group has child element called UserName, which is used by controlling function to indicate the users in the session.
  • Ad-hoc session split client will include the user names.
  • Session Split also has two optional elements for excluding and including any users from the Split sessions.
  • FIG. 14 shows flow diagram for merging scenario, in this example user A wants to add new user M into merged session.
  • the flows are as follows,
  • Client A wants to initiate the merge request, Sends a INVITE request a. Including SessionMerge parameter in session URI parameter in Request-URI header. b. Request-URI header field contains conference factory URI c. INVITE Body will include session ids of sessions to be merged d. INVITE body will have Include element with value set to User M address.
  • Controlling function receives this invite request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URI header a. Controlling function creates new session parameter and new session ids for merged sessions b. Extract body of invite to identify the sessions to be merged
  • Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one
  • Controlling function then sends the RE-INVITE to all users a. ⁇ SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b. Merged session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
  • Controlling function also send the INVITE to User M for inviting the user into a merged session a.
  • Other session information like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
  • Client M device sends the 200 OK response to INVITE request.
  • FIG. 14 shows flow diagram for merging scenario, in this example user A wants to exclude user C from a merged session.
  • the flows are as follows,
  • Client A wants to initiate the merge request with excluding user C, Sends a INVITE request a. Including SessionMerge parameter in session URI parameter in Request-URI header. b. Request-URI header field contains conference factory URI c. INVITE Body will include session ids of sessions to be merged d. INVITE body will have Exclude element with value set to User C address.
  • Controlling function receives this invite request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URI header a. Controlling function creates new session parameter and new session ids for merged sessions b. Extract body of invite to identify the sessions to be merged
  • Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one
  • Controlling function then sends the RE-INVITE to all users a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b.
  • Merged session id and session parameters c.
  • REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
  • Controlling function also send the BYE to User C for excluding him from merged session.
  • the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Abstract

The present invention is related to communication systems over mobile or the Internet. More specifically, the invention is related to the group communication systems like POC or IMS on the Internet or mobile systems. The POC or IMS use SIP technology to accomplish communication between users. The current invention provides method to facilitate the management of user sessions. A user can initiate merge operation for two distinct groups. The user has to just select the groups to be merged. Then, merge initiator signal is sent to controlling function. The controlling function then sends invites to other users in the group. All the interested users are then merged together. Similarly, the user can initiate division of group. In this case, division initiator signal is sent to the controlling function. The controlling function invites the concerned users regarding the division. The interested users are divided into two groups.

Description

[DESCRIPTION] [Invention Title]
METHOD FOR MERGING AND SPLITTING OF SESSIONS IN SESSION BASED APPLICATIONS LIKE IMS APPLICATIONS SIMPLE IM AND POC
[Technical Field]
This invention in general relates to the field of session based applications like POC and SIMPLE IM. This invention relates to group communication applications like POC and IM, where multiple group sessions are possible. This invention relates to SIP technology protocol. More specifically this invention relates to system and method for merging and splitting of sessions in session based applications like IMS applications simple IM and POC.
[Background Art]
IMS based application like POC and SIMPLE IM uses SIP session control procedure for establishing group communication sessions. There can be multiple group sessions simultaneously running for a particular user. There is a need for merging the two separate group sessions into one session for some use cases. Currently SIP does not support the merging of two or more group sessions. There are various use cases where splitting of group into two sessions is required. SIP also does not support this procedure. This invention proposes the SIP extensions to support this feature for merging the two or more sessions and splitting two sessions into two or more groups.
[Disclosure]
[Technical Problem]
IMS based application like POC and SIMPLE IM uses SIP session control procedure of creation of a session. There can be one to one session or group sessions. SIP procedure allows initiating one to one session and group sessions. Group session could be Pre-arranged sessions or Ad-Hoc sessions. User can have simultaneous sessions. It is beneficial in some cases to allow user to merge a session or split a session in two or more groups. Consider User A is having two sessions. One group session is poc groups, which is discussing on PoC related topics. Second session is im group, which is discussing on SIMPLE IM related topics. In some situation where PoC group discussing on important issue which is common to SIMPLE IM group as well, in this case user wants to merge two groups into one group. User can initiate a merge request and server should be able to merge these two sessions into one session. Similarly, there is possibility of splitting of sessions into two or more groups in case of hierarchical group scenarios or in Ad-Hoc fashion. This will allow user to split one session into two sessions.
Currently, a SIP procedure does not allow mechanism to merge the ongoing sessions or split sessions into two sessions. Currently for merging of sessions, User needs to tear down the current on-going sessions and then create a new session for merged group. This required lots of signaling from the User side. Similarly for splitting of sessions, User need to send the terminate signal for current ongoing signal and then send the separate invite for the each split sessions. This requires lot of signaling from the client device which can waste lot of wireless resources.
[Technical Solution]
The present invention proposes a method which allows user to send only one request for merging of sessions. The proposed method simplifies the merging of sessions with single request.
Besides, the present invention provides the system and methods which allow user to send single request for splitting of the session into two or more sessions.
The present invention extends the SIP procedure and allow user to send the request for merging and for splitting of sessions. The present invention further provides two methods for the merging and two methods for splitting of the sessions.
Accordingly the invention explains a method to facilitate merging and splitting of user sessions wherein merging operation comprising the steps of : a user selecting groups to be merged; sending a merge initiator signal to a controlling function; sending invites to other users in the group by the controlling function; and merging the interested users together,
Splitting operation comprising the steps of: sending a splitting initiator signal to the controlling function; the controlling function inviting the concerned users regarding the split; and splitting the interested users.
The present invention aims to provide the system and methods for enabling the users to initiate the merging and splitting of sessions. This invention initially discuss merging of session which provides two methods first method uses INVITE method and second method uses REFER method. These methods extend the INVITE and REFER methods for initiating the merging request. Similarly, invention extends the INVITE and REFER methods for initiating splitting request.
These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings.
[Advantageous Effects]
The present invention provide a user two sessions. In other words, this inventions allows merging two groups into one group, and splitting of sessings into two or more groups in more groups.
Namely, the present invention extends the SIP procedure and allows a user to send the request for merging and for splitting of sessions. User does not need to tear down the current on-going sessions nor create a new session for merged group. So a lot of signaling from the user side does not waste lots of wireless resources.
[Description of Drawings]
Figure 1 illustrates System architecture for INVITE based method for merging of sessions;
Figure 2 illustrates Basic Flow diagrams;
Figure 3 illustrates Terminating side Flow diagram: On demand session case;
Figure 4 illustrates Terminating side Flow diagram: Pre-establish session case;
Figure 5 illustrates Sending BYE to user who reject the REINVITE;
Figure 6 illustrates Schema format for Merged Invite Body;
Figure 7 illustrates System architecture for REFER based merging of merging of sessions;
Figure 8 illustrates Logical flows for REFER based method for merging of sessions;
Figure 9 illustrates INVITE method for splitting of sessions;
Figure 10 illustrates Flow diagram for session split with INVITE request;
Figure 11 illustrates REFER method for splitting of sessions;
Figure 12 illustrates Flow diagram for session splitting using REFER method;
Figure 13 illustrates Schema format for splitting of sessions;
Figure 14 illustrates Including new user into a merged session;
Figure 15 illustrates Excluding user from a merged session.
[Best Mode]
The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well- known or conventional details are not described in order not to unnecessarily obscure the present invention in detail.
As discuss in the previous section basic use cases and motivation for merging and splitting of session, this section explains the detail solution for splitting and merging of session. Firstly, it discusses about merging of session then followed by splitting of sessions.
Merging of sessions:
This part of invention deals with merging of sessions. In this invention, two methods are proposed. First method uses INVITE method and other method uses REFER method. These methods are discussed next. In this proposal assumption is that session ids are know to user who initiate the merging request.
INVITE method for merging of sessions
This method uses INVITE method for sending of merging request. As shown in the Figure 1, Client A is initiator of merging request. There are two ongoing sessions, Session Ll (User B, User C, User D, and User A) and Session L2 (User G, User F, User E, and User A). Controlling function is common to both sessions. According to this method user sends ESTVITE request with session type URI parameter and merging indicator, e.g., set as "Ad- hoc+SessionMerge" Note a new tag is proposed to identify this request as merging request. Client A wants to merge two sessions Ll, and L2. For this Client send INVITE request and add the +SessionMerge tag in session URI parameter in Request URI header field e.g. Request- URI:sip:PoCConferenceFactoryURI;session="Ad-Hoc+SessionMerge" Client A also adds the session information into the body of the session merge INVITE request. Client A adds session ids of sessions to be merged. Request URI of this INVITE request will be set to conference factory URI.
Controlling function receives the Merge INVITE request. Controlling function also extract the body to identify the sessions to be merged. Controlling function sends the RE-INVITE with new session parameters to all users of session Ll and session L2. Controlling function also add tag +SessionMerge in the session URI parameter. Controlling function also adds information about the other session information, so that user can decide on to join the session or not. Controlling function also can send the group advertisement before sending the RE-INVITE so that user knows merging of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 200OK response. All users are aware of the session merge situation by group advertisement and information in a RE-INVITE request. Controlling function also create the merged conference package for general notification about the merged session. This is a general proposed method using INVITE. Figure 2 explains the procedure in detail.
In this scenario, there are two sessions, one session is Ll session, and other session is L2 session. Flows according to proposed solutions are follows:
1. Client A wants to initiate the merge request, Sends a INVITE request a. Including SessionMerge parameter in session URI parameter in Request-URI header. b. Request-URI header field contains conference factory URI c. INVITE Body will include session ids of sessions to be merged d. INVITE body can also have optional information for including and excluding of users into merged sessions is Client A is authorized to do so. 2. Controlling function receives this invite request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URI header a. Controlling function creates new session parameter and new session ids for merged sessions b.Extract body of invite to identify the sessions to be merged
3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one
4. Controlling function then sends the RE-INVITE to all users a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b. Merged session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
5. Client B device sends the 200 OK response to merged request.
6. Controlling function forwards a 200 OK response to Client A device.
7. Create a merged conference package and Controlling function sends the notification about the merged session information.
This ways Merge INVITE request will be used by the client device to initiate the merge request.
Figure 3 explains the flow diagram case for terminating side in case of On-demand session: a. Controlling function sends the RE-INVITE to Participating function with all details about merging of session b. Participating server forwards the request to Client device c. Client device send the 200OK response to participating function d. Participating function forwards the request to controlling function Figure 4 explains Terminating side Flow diagram: Pre-establish session case:
1. Controlling function sends the RE-INVITE to Participating function with all details about merging of session
2. Participating server send MBCP DISCONNECT message in RTCP protocol with reason of DISCONNECT as merging of session 3. Client device sends MBCP Talk Burst Acknowledgement response to DISCONNECT message
4. Participating server send MBCP CONNECT message in RTCP protocol with information about the new session parameters
5. Client device sends MBCP Talk Burst Acknowledgement response to CONNECT message
6. Participating function then send the 200OK response to controlling function
This way INVITE based method is used for merging of the two sessions. When any user reject the REINVITE then controlling server send the BYE to him to tear down the session. This scenario is shown in the figure 5.
Figure 6 shows, schema structure should be included in the Merged INVITE request. Schema has root element called SessionMerge. SessionMerge element has one element called Session. This element is used to include session ids of sessions to be merged. This element has two attributes one is SessionID and other is NoofUser.
SessionID is used to specify the ID of sessions. NoofUser is option attribute and generally it is added by controlling function to give information about other sessions to users of session. Session has child element called UserName, which is used by controlling function to indicate the users in the session. Session Merge also has two optional elements for excluding and including any users from the merged session.
REFER method for merging of sessions
This method uses REFER method for sending of merging request. As shown in the Figure 7. This method actually adds other sessions to one session to create a merged session. Client A is initiator of merging request. There are two ongoing session, Session Ll (User B, User C, User D, and User A) and Session L2 (User G, User F, User E, and User A). Controlling function is common to both sessions. According to this method user sends REFER request with session URI parameter set as "Ad-hoc+SessionMerge" Client A wants to merge two sessions Ll, and L2. For this Client send REFER request and add the +SessionMerge tag in session URI parameter in Request URI header field e.g. Request-URI:sip:sessonl@networkB.net;session=Ad-Hoc+SessionMerge?. Client A also adds the session information into the body of the session merge INVITE request. Client A adds session ids of sessions to be merged. Request URI of this INVITE request will be set to Ll session id.
Controlling function receives the Merge REFER request. Controlling function also extract the body to identify the sessions to be merged. Controlling function sends the RE-INVITE with new session parameters to all users of session L2. Controlling function also add tag +SessionMerge in the session URI parameter. Controlling function also adds information about the other session, so that user can decide on to join the session or not. Controlling function also can send group advertisement before sending the RE-INVITE so that user knows merging of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 200 OK response. All users are aware of the session merge situation by group advertisement and information in a RE-INVITE request. Controlling function also create the merged conference package for general notification about the merged session. This is a general proposed method using REFER. Figure 8 explains the procedure in detail.
In this scenario, there are two sessions, one session is Ll session, and other session is L2 session. Flows according to proposed solutions are follows:
1. Client A wants to initiate the merge request, Sends a REFER request a. +SessionMerge parameter in session URI parameter in Request-URI header. b. Request-URI header field contains Ll session Id c. REFER-TO field contains reference to REFER body d. REFER Body will include session ids of sessions to be merged e. REFER body can also have optional information for including and excluding of users into merged sessions is Client A is authorized to do so.
2. Controlling function receives this REFER request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URI header. a. Send 202 Accepted response to Client A b. Extract body of REFER to identify the sessions to be merged to current session
3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one
4. Controlling function then sends the RE-INVITE to all users of L2 session a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b. Merged session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not
5. Client B device sends the 200 OK response to merged request
6. Controlling function send the NOTIFY to Client A to indicate the status related to REFER request
7. Client A sends a 200 OK response
8. Create a merged conference package and Controlling function sends the notification about the merged session information
This way Merge REFER request will be used by the client device to initiate the merge request. The schema defined in previous section is valid for this method as well. The procedures at terminating side will remain same as given in the previous section.
Splitting of sessions:
This part of the invention deals with splitting of sessions. In this invention, two methods are proposed. First method uses INVITE method and other method uses RFER method. These methods are discussed next. In this proposal assumption is that hierarchical group definition is stored in controlling function or in controlling function XDMS. This proposal also considers the situation for ad-hoc group splitting case, where user split the session in ad-hoc fashion.
INVITE Method for splitting of sessions
This method uses INVITE method for sending of splitting request. As shown in the Figure 9, Client A is initiator of splitting request. There is one ongoing session, Session Ll (User B, User C, User D, User A, User G, User F, and User E). According to this method user sends INVITE request with session URI parameter set as ^ d-hoc+SessionSplit? Note a new tag is proposed to identify this request as splitting request. Client A wants to split current session. For this Client send INVITE request and add the +SessionSplit tag in session URI parameter in Request URI header field e.g. * Request- URI:sip:sessonl@networkB.net;session=Ad-Hoc+SessionMerge?. Client A also adds the group information into the body of the session split INVITE request. Client A adds group URIs which identifies the groups into which session needs to be split. In case of Ad-hoc split client A also adds user names in each group so that two group sessions are created in Ad-Hoc fashion. Request URI of this INVITE request will be set to session id of current session.
Controlling function receives the split INVITE request. Controlling function also extract the body to identify the groups into which session needs to be split. Controlling function sends the RE-INVITE with new session parameters to all users. Controlling function also add tag +SessionSplit in the session URI parameter. Controlling function also adds information about group, so that user can decide on to join the session or not. Controlling function also can send the group advertisement before sending the RE-INVITE so that user knows splitting of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 200OK response. All users are aware of the session split situation by group advertisement and information in a RE-INVITE request. Controlling function also create the conference package for each group; general notification about the session. This is a general proposed method using INVITE. Figure 10 explains the procedure in detail.
In this scenario, there is one session and client A wants to split the session into two sessions with Gl and G2. Flows according to proposed solutions are follows:
1. Client A wants to initiate the split request, Sends a INVITE request a. +SessionSplit parameter in session URI parameter in Request-URI header. b. Request-URI header field contains session id of current session c. INVITE Body will include groups URIs and also can have user names in each group for Ad-hoc splitting d. INVITE body can also have optional information for including and excluding of users into each group sessions if Client A is authorized to do so.
2. Controlling function receives this invite request and identifies it as a split request by seeing the +SessionSplit tag in Request-URI header. a. Controlling function creates new session parameter and new session ids for other sessions b. Extract body of invite to identify the groups
3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the splitting of session in to two
4. Controlling function then sends the RE-INVITE to all users a. +SessionSplit tag to identify it as splitting invite, so that client can retrieve session parameter from RE-INVITE request b. split session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
5. Client B device sends the 200 OK response to split request
6. Controlling function forwards a 200 OK response to Client A device.
7. Create a conference package and Controlling function sends the notification about each session information
This way split INVITE request will be used by the client device to initiate the split request.
REFER Method for splitting of sessions
This method uses REFER method for sending of splitting request. As shown in the Figure 11, Client A is initiator of splitting request. There is one ongoing session, Session Ll (User B, User C, User D, User A, User G, User F, and User E). According to this method user sends REFER request with session URI parameter set as ϋ] d-hoc+SessionSplit? Note a new tag is proposed to identify this request as splitting request. Client A wants to split current session. For this Client send REFER request and add the ++SessionSplit tag in session URI parameter in Request URI header field e.g. Request- URI:sip:sessonl@networkB.net;session=Ad-Hoc+SessionMerge? Client A also adds the group information into the body of the session split REFER request. Client A adds group URIs which identifies the groups into which session needs to be split. In case of Ad-hoc split client A also adds user names in each group so that two group sessions are created in Ad-Hoc fashion. Request URI of this REFER request will be set to session id of current session. REFER-TO is set to reference to body of REFER request.
Controlling function receives the split REFER request. Controlling function also extract the body to identify the groups into which session it needs to split. Controlling function sends the RE-INVITE with new session parameters to all users. Controlling function also add tag +SessionSplit in the session URI parameter. Controlling function also adds information about group, so that user can decide on to join the session or not. Controlling function also can send the group advertisement before sending the RE-INVITE so that user knows splitting of session is going to happen. Upon receiving of RE-INVITE from the controlling function, user sends the 200OK response. All users are aware of the session split situation by group advertisement and information in a RE-INVITE request. Controlling function also create the conference package for each group; general notification about the session. This is a general proposed method using REFER. Figure 12 explains the Flow diagram for sessions splitting using REFER method.
In this scenario, there is one session and client A wants to split the session into two sessions with Gl and G2. Flows according to proposed solutions are follows,
1. Client A wants to initiate the split request, Sends a REFER request a. +SessionSplit parameter in session URI parameter in Request-URI header. b. Request-URI header field contains current session Id c. REFER-TO field contains reference to REFER body d. REFER Body will include Group ids of sessions
REFER body can also have optional information for including and excluding of users into Split sessions if Client A is authorized to do so.
2. Controlling function receives this REFER request and identify it as a Split request by seeing the +SessionSplit tag in Request-URI header a. Send 202 Accepted response to Client A b. Extract body of REFER to identify the sessions to be split from current session
3. Controlling function sends the group advertisement to each user of sessions to indicate the Split of session in to two
4. Controlling function then sends the RE-INVITE to all users of Gl session a. +SessionSplit tag to identify it as Splitting invite, so that client can retrieve session parameter from RE-INVITE request b. Split session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the session or not
5. Client B device sends the 200 OK response to Split request
6. Controlling function send the NOTIFY to Client A to indicate the status related to REFER request
7. Client A sends a 200 OK response
8. Create a Split conference package and Controlling function for each session, and sends the notification about the Split session information
This way split REFER request will be used by the client device to initiate the split request.
Schema for Splitting of sessions
Figure 13 shows, schema structure should be included in the Split INVITE request. Schema has root element called SessionSplit. SessionSplit element has one element called Group. This element is used to include group ids. This element has two attributes one is Group URL and other is NoofUser.
Group URL is used to specify the URL of group. NoofUser is option attribute and generally, it is added by controlling function to give information about other sessions to users of session. Group has child element called UserName, which is used by controlling function to indicate the users in the session. In case of Ad-hoc session split client will include the user names. Session Split also has two optional elements for excluding and including any users from the Split sessions.
Excluding and including users from sessions:
This section gives example for case where user can exclude or include the any member from the merged session or split sessions.
Including user while merging the session
In this example its shows, how user can use the INCLUDE element so that he can invite new user into a merged session. Figure 14 shows flow diagram for merging scenario, in this example user A wants to add new user M into merged session. The flows are as follows,
1. Client A wants to initiate the merge request, Sends a INVITE request a. Including SessionMerge parameter in session URI parameter in Request-URI header. b. Request-URI header field contains conference factory URI c. INVITE Body will include session ids of sessions to be merged d. INVITE body will have Include element with value set to User M address.
2. Controlling function receives this invite request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URI header a. Controlling function creates new session parameter and new session ids for merged sessions b. Extract body of invite to identify the sessions to be merged
3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one
4. Controlling function then sends the RE-INVITE to all users a. ÷SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b. Merged session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
5. Controlling function also send the INVITE to User M for inviting the user into a merged session a. Merged session id and session parameters b. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
6. Client M device sends the 200 OK response to INVITE request.
After this session will commence normally, so this way Include element is used for including new user into a merged session.
Excluding user while merging the session
In this example its shows, how user can use the EXCLUDE element so that he can exclude any user from a merged session. Figure 14 shows flow diagram for merging scenario, in this example user A wants to exclude user C from a merged session. The flows are as follows,
1. Client A wants to initiate the merge request with excluding user C, Sends a INVITE request a. Including SessionMerge parameter in session URI parameter in Request-URI header. b. Request-URI header field contains conference factory URI c. INVITE Body will include session ids of sessions to be merged d. INVITE body will have Exclude element with value set to User C address.
2. Controlling function receives this invite request and identify it as a Merge request by seeing the +SessionMerge tag in Request-URI header a. Controlling function creates new session parameter and new session ids for merged sessions b. Extract body of invite to identify the sessions to be merged
3. Optionally, Controlling function sends the group advertisement to each user of sessions to indicate the merging of session in to one
4. Controlling function then sends the RE-INVITE to all users a. +SessionMerge tag to identify it as merging invite, so that client can retrieve session parameter from RE-INVITE request b. Merged session id and session parameters c. REPLACES header will have the session information about session to be changed d. Other session information, like users of other session. This will be beneficial to users so that they can decide to join the merged session or not to join the merged session
5. Controlling function also send the BYE to User C for excluding him from merged session.
After this session will commence normally, so this way Exclude element is used for excluding any user from a merged session.
Note this inclusion and exclusion is also applicable while splitting a session as well.
It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device.
Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from.

Claims

[CLAIMS]
[Claim 1 ]
A method to facilitate merging and splitting of user sessions wherein merging operation comprising the steps of : a user selecting groups to be merged; sending a merge initiator signal to a controlling function; sending invites to other users in the group by the controlling function; and merging the interested users together, Splitting operation comprising the steps of: sending a splitting initiator signal to the controlling function; the controlling function inviting the concerned users regarding the split; and splitting the interested users.
[Claim 2]
A method as claimed in claim 1 wherein an INVITE method for merging of sessions comprising the steps of: sending a INVITE request by a first client who wants to initiate the merge request; controlling function receiving the invite request and identifying it as a Merge request; controlling function optionally sending a group advertisement to each user of sessions to indicate the merging of session in to one; controlling function then sending the RE-INVITE to all users; a second client sending response to merge request; controlling function forwarding a response to the first client; and
Creating a merged conference package and the controlling function sending the notification about the merged session information.
[Claim 3]
The method as claimed in claim 1 wherein a REFER method for merging of sessions comprising the steps of: a first client who wants to initiate the merge request, sending a REFER request ; controlling function receiving the REFER request and identify it as a Merge request ; controlling function optionally sending the group advertisement to each user of sessions to indicate the merging of session in to one; controlling function sending the RE-I-WITE to all users of the session; a second client sending a response to merge request; controlling function sending the NOTIFY to the first client to indicate the status related to REFER request; first client sending a response; and creating a merged conference package and the controlling function sending the notification about the merged session information.
[Claim 4]
The method as claimed in claim 1 wherein a INVITE method for splitting of sessions comprising the steps of: a first client wanting to initiate the split request, sending a INVITE request ; controlling function receiving the invite request and identifying it as a split request ;
Controlling function creating new session parameter and new session ids for other sessions; controlling function optionally sending the group advertisement to each user of sessions to indicate the splitting of session in to two; controlling function sending the RE-INVITE to all users; a second client device sending a response to split request; controlling function forwarding response to first Client; and creating a conference package and the Controlling function sending the notification about each session information.
[Claim 5]
The method as claimed in claim 1 wherein a REFER Method for splitting of sessions comprising the steps of: a first Client wanting to initiate the split request, Sending a REFER request ; controlling function receiving the REFER request and identifying it as a Split request; controlling function sending the group advertisement to each user of sessions to indicate the split of session in to two; controlling function sending the RE-INVITE to all users of the session; a second client sending response to split request; controlling function sending the NOTIFY to first client to indicate the status related to REFER request; first client sending a response; and creating a split conference package and controlling function for each session, and sending the notification about the Split session information.
[Claim 6]
A method to facilitate merging and splitting of user sessions substantially described particularly with reference to the accompanying drawings.
PCT/KR2007/006968 2006-12-29 2007-12-28 Method for merging and splitting of sessions in session based applications like ims applications simple im and poc WO2008082203A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN2475CH2006 2006-12-29
IN2475/CHE/2006 2006-12-29

Publications (1)

Publication Number Publication Date
WO2008082203A1 true WO2008082203A1 (en) 2008-07-10

Family

ID=39588789

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2007/006968 WO2008082203A1 (en) 2006-12-29 2007-12-28 Method for merging and splitting of sessions in session based applications like ims applications simple im and poc

Country Status (1)

Country Link
WO (1) WO2008082203A1 (en)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011035601A1 (en) * 2009-09-23 2011-03-31 中兴通讯股份有限公司 Method and system for media modification
US20150249691A1 (en) * 2007-11-13 2015-09-03 Cellular Communications Equipment Llc Method, Apparatus and Program Product for Merging Communication Sessions in an IMS
US9510166B1 (en) 2015-06-29 2016-11-29 Blackberry Limited Merging active group calls
WO2017004062A1 (en) * 2015-06-29 2017-01-05 Blackberry Limited Merging active group calls
WO2017142345A1 (en) * 2016-02-18 2017-08-24 Samsung Electronics Co., Ltd. Method and terminal for providing mcptt(mission critical push to talk) service
US11128962B2 (en) 2019-03-28 2021-09-21 Sonova Ag Grouping of hearing device users based on spatial sensor input
US11184484B2 (en) 2019-04-09 2021-11-23 Sonova Ag Prioritization of speakers in a hearing device system
CN113992614A (en) * 2021-10-26 2022-01-28 广州博冠信息科技有限公司 Session group processing method and device, computer storage medium and electronic equipment
US11973808B2 (en) 2022-07-11 2024-04-30 Samsung Electronics Co., Ltd. Electronic device for providing conference service and method of the same

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1427141A1 (en) * 2002-12-04 2004-06-09 Deutsche Thomson-Brandt Gmbh Method for creating a peer-to-peer home network using common group label
EP1480415A1 (en) * 2003-05-23 2004-11-24 Deutsche Thomson-Brandt Gmbh Method for assigning an identifier to a peer-group in a peer-to-peer network
US20060114846A1 (en) * 2004-12-01 2006-06-01 Rachida Dssouli Methods for cluster-based multi-party conferencing in ad-hoc networks
US20060114843A1 (en) * 2004-12-01 2006-06-01 Rachida Dssouli Cluster of terminals and ad-hoc network for cluster-based multi-party conferencing

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1427141A1 (en) * 2002-12-04 2004-06-09 Deutsche Thomson-Brandt Gmbh Method for creating a peer-to-peer home network using common group label
EP1480415A1 (en) * 2003-05-23 2004-11-24 Deutsche Thomson-Brandt Gmbh Method for assigning an identifier to a peer-group in a peer-to-peer network
US20060114846A1 (en) * 2004-12-01 2006-06-01 Rachida Dssouli Methods for cluster-based multi-party conferencing in ad-hoc networks
US20060114843A1 (en) * 2004-12-01 2006-06-01 Rachida Dssouli Cluster of terminals and ad-hoc network for cluster-based multi-party conferencing

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9906565B2 (en) * 2007-11-13 2018-02-27 Cellular Communications Equipment Llc Method, apparatus and program product for merging communication sessions in an IMS
US20150249691A1 (en) * 2007-11-13 2015-09-03 Cellular Communications Equipment Llc Method, Apparatus and Program Product for Merging Communication Sessions in an IMS
US8428627B2 (en) 2009-09-23 2013-04-23 Zte Corporation Method and system for media modification
WO2011035601A1 (en) * 2009-09-23 2011-03-31 中兴通讯股份有限公司 Method and system for media modification
KR20180021846A (en) * 2015-06-29 2018-03-05 블랙베리 리미티드 Merge Active Groups
US10123182B2 (en) 2015-06-29 2018-11-06 Blackberry Limited Merging active group calls
US9628965B2 (en) 2015-06-29 2017-04-18 Blackberry Limited Merging active group calls
KR102406374B1 (en) 2015-06-29 2022-06-07 블랙베리 리미티드 Merge activation group calls
CN107925666B (en) * 2015-06-29 2021-04-13 黑莓有限公司 Merging active group calls
WO2017004060A1 (en) * 2015-06-29 2017-01-05 Blackberry Limited Merging active group calls
US9510166B1 (en) 2015-06-29 2016-11-29 Blackberry Limited Merging active group calls
CN107925666A (en) * 2015-06-29 2018-04-17 黑莓有限公司 Merger activity group calls
CN107950010A (en) * 2015-06-29 2018-04-20 黑莓有限公司 Merger activity group calls
WO2017004062A1 (en) * 2015-06-29 2017-01-05 Blackberry Limited Merging active group calls
CN107950010B (en) * 2015-06-29 2020-11-20 黑莓有限公司 Merging active group calls
US9894496B2 (en) 2016-02-18 2018-02-13 Samsung Electronics Co., Ltd. Method and terminal for providing MCPTT service
WO2017142345A1 (en) * 2016-02-18 2017-08-24 Samsung Electronics Co., Ltd. Method and terminal for providing mcptt(mission critical push to talk) service
US11128962B2 (en) 2019-03-28 2021-09-21 Sonova Ag Grouping of hearing device users based on spatial sensor input
US11184484B2 (en) 2019-04-09 2021-11-23 Sonova Ag Prioritization of speakers in a hearing device system
CN113992614A (en) * 2021-10-26 2022-01-28 广州博冠信息科技有限公司 Session group processing method and device, computer storage medium and electronic equipment
US11973808B2 (en) 2022-07-11 2024-04-30 Samsung Electronics Co., Ltd. Electronic device for providing conference service and method of the same

Similar Documents

Publication Publication Date Title
WO2008082203A1 (en) Method for merging and splitting of sessions in session based applications like ims applications simple im and poc
US8725802B2 (en) Method for transferring file in conference system, file transfer system and conference server
US9210196B2 (en) Method and apparatus for identifying an IMS service
EP2014013B1 (en) Method and devices for third-party session modification
EP2093933A1 (en) A method, system and device for performing a storing process and inquiring on sessions history records
US8185094B2 (en) Message handling in an IP multimedia subsystem
KR101581674B1 (en) Method for storing conversation according to user request in cpm service system and the system thereof
WO2006129206A1 (en) Providing a second service to a group of users using a first service
EP3047651B1 (en) A method and system for integrating content viewing and communication in immersive social centre session
CN101043431B (en) Method and system for shortening built-up time of multi-party communication service
CN101026614B (en) Media type parameter negotiation method
US20080212523A1 (en) Session based communication
US20070049315A1 (en) Computer-aided conference session having priority indication
US20150074284A1 (en) Providing push to all (pta) service
US8462669B2 (en) Method and apparatus for determining PT server having controlling function
US20110264813A1 (en) Method and system for managing communication session establishment
WO2014026316A1 (en) Media data transmission method and device
KR101071980B1 (en) Apparatus and method controlling session connection for ims multiparty conference applications
CN100571149C (en) A kind of dialogue-based initiation protocol upgrades the implementation method of conference media type
WO2008041831A1 (en) System and method for ordered invite for session based group communication
WO2012025802A2 (en) Method for session modifying in the session description protocol
Saint-Andre et al. Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
Arunprasath et al. Enriched conference

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07851827

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07851827

Country of ref document: EP

Kind code of ref document: A1