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 PDFInfo
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/148—Migration or transfer of sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
- H04W4/10—Push-to-Talk [PTT] or Push-On-Call services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/40—Connection management for selective distribution or broadcast
- H04W76/45—Connection 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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IN2475/CHE/2006 | 2006-12-29 | ||
IN2475CH2006 | 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)
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)
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 |
-
2007
- 2007-12-28 WO PCT/KR2007/006968 patent/WO2008082203A1/en active Application Filing
Patent Citations (4)
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)
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 |
WO2017004062A1 (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 |
WO2017004060A1 (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 | |
EP2082552B1 (en) | Session based communication | |
CN101026614B (en) | Media type parameter negotiation method | |
CN101527641A (en) | Realization method, control method and device for sub-conference in multimedia sub-system | |
US9282152B2 (en) | Providing push to all (PTA) service | |
US20070049315A1 (en) | Computer-aided conference session having priority indication | |
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 | |
RU2389148C2 (en) | Method and device for identifying ims service | |
WO2012025802A2 (en) | Method for session modifying in the session description protocol | |
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 |