WO2007007902A1 - System and method for establishing multiparty conference by relays - Google Patents

System and method for establishing multiparty conference by relays Download PDF

Info

Publication number
WO2007007902A1
WO2007007902A1 PCT/JP2006/314200 JP2006314200W WO2007007902A1 WO 2007007902 A1 WO2007007902 A1 WO 2007007902A1 JP 2006314200 W JP2006314200 W JP 2006314200W WO 2007007902 A1 WO2007007902 A1 WO 2007007902A1
Authority
WO
WIPO (PCT)
Prior art keywords
invited
remote party
remote
party
parties
Prior art date
Application number
PCT/JP2006/314200
Other languages
French (fr)
Inventor
Yi-Wen Chang
Original Assignee
Matsushita Electric Industrial 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 Matsushita Electric Industrial Co., Ltd. filed Critical Matsushita Electric Industrial Co., Ltd.
Publication of WO2007007902A1 publication Critical patent/WO2007007902A1/en

Links

Classifications

    • 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/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1818—Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
    • 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/1854—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with non-centralised forwarding system, e.g. chaincast

Definitions

  • the invention relates to a system and method for establishing a multiparty conference, more particularly to a system and method for establishing a multiparty conference by relays.
  • a conventional centralized conference relies on a centralized server 75 and an underlying service network to establish the required point-to-point signal connection with each of the remote parties 71 -74 that join the conference.
  • one of the remote parties 71 -74 e.g., the remote party 71
  • acts as a conference initiator invites the other remote parties 72-74 through the underlying service network while holding the call connections, and sends a multiparty conference request to the centralized server 75 to combine the call connections on hold with the active call connection, thereby establishing an active multiparty conference call connection.
  • the centralized server 75 is responsible for receiving media data from all the remote parties 71 -74, proce.ssing the media data, and sending the processed media data back to the remote parties 71-74, respectively.
  • a conventional full mesh conference does not rely on a centralized server and an underlying service network thereof. Instead, each of the remote parties 91 -94 participating in the conference directly establishes a point-to-point signal connection with the other remote parties 91 -94, and sends media data of its own to the other remote parties 91 -94 in a one-to-one manner.
  • an object of the present invention is to provide a system for establishing a multiparty conference by relays.
  • the system can be employed to invite prescribed remote parties to participate in a multiparty conference by relays.
  • Another object of the present invention is to provide a method for establishing a multiparty conference by relays.
  • the method can be employed to invite prescribed remote parties to participate in a conference by relays and to return invitation results of establishing the multiparty conference.
  • the system for establishing a multiparty conference by relays of the present invention is adapted for use in establishing a multiparty conference among a plurality of remote parties installed with the system.
  • the system installed in each remote party includes a communications unit, a memory unit, a participating unit, an invitation unit, and a media data processing unit.
  • the communications unit is for transmitting data to the outside and for receiving data from the outside.
  • the memory unit is for storing a to-be-invited remote party list that records information of each to-be-invited remote party.
  • the participating unit is for receiving and responding to incoming invitation requests from other remote parties through the communications unit, and is for storing received allocation information in the memory unit as the to-be-invited remote party list.
  • the invitation unit is for inviting through the ⁇ communications unit at least one non-invited remote party by reference to the to-be-invited remote party list stored in the memory unit, receiving the response from the invited remote parties, allocating and distributing the information of non-invited remote parties to aforesaid successfully invited remote parties, thereby updating and distributing the invitation result to its remote inviting party based on the invitation results returned from aforesaid successfully invited remote parties.
  • the media data processing unit is for receiving respective media data from all the remote parties having a connection relationship through the communications unit, processing media data thereof and the received media data, and sending the processed media data to each of the remote parties having a connection relationship through the communications unit.
  • the method for establishing a multiparty conference by relays of this invention is adapted for use among a plurality of remote parties where a remote party initiating the multiparty conference is referred to as the conference initiator and also default initiating remote party.
  • the method comprises the following steps:
  • Figure 1 is a block diagram to illustrate the connection in a conventional centralized conference
  • Figure 2 is a block diagram to illustration the connection in a conventional full mesh conference
  • Figure 3 is a system block diagram to illustrate the preferred embodiment of a system and method for establishing a multiparty conference by relays according to the present invention
  • FIGS. 4A, 4B and 4C taken together show a flowchart of the preferred embodiment of the method according to the present invention
  • Figure 5 is a block diagram to illustrate the connection in the preferred embodiment
  • Figure 6 is a status diagram of the preferred embodiment, illustrating the condition of the to-be-invited remote party list prior to the start of the multiparty conference
  • Figure 7 is a status diagram of the preferred embodiment, illustrating the condition of the to-be-invited remote party list when a remote party A and a remote party B are successfully invited by a conference initiator S;
  • Figure 8 is a status diagram of the preferred embodiment, illustrating the condition of the to-be-invited remote party list when all the to-be-invited remote parties have been successfully invited and the multiparty conference is about to start.
  • a system for establishing a multiparty conference by relays of this invention is adapted for establishing a multiparty conference among a plurality of remote parties installed with the system.
  • Each remote party can be a mobile phone, a personal digital assistant (PDA), or any electronic device having networking functionality.
  • PDA personal digital assistant
  • the remote party which initiates the multiparty conference is referred to as the "conference initiator.”
  • the system installed within each remote party includes a communications unit 1 , a participating unit 2, an invitation unit 3, a memory unit 4, a list generating unit 5, and a media data processing unit 6.
  • the communications unit 1 is electrically connected to the participating unit 2, the invitation unit 3, and the media data processing unit 6, respectively, sends the data generated by the aforesaid units to the outside, and receives outside data for one of the units.
  • the communications unit 1 may conduct data transmission based on the Internet Protocol (IP).
  • IP Internet Protocol
  • the memory unit 4 is electrically connected to the participating unit 2, the invitation unit 3, and the list generating unit 5, respectively, and stores a to-be-invited remote party list.
  • the list records the name, contact information, and status of every to-be-invited remote party.
  • the contact information may be a Telephone Number Universal Resource Identifier (TEL URI), an Internet Protocol Address (IP address), a Session Initiation Protocol Universal Resource Identifier (SIP URI), or any addressable information.
  • the status includes a "non-invited” status and an "invited” status.
  • the list generating unit 5 is electrically connected to the invitation unit 3, generates contents-exclusive sub-lists whose number corresponds to that of the "invited” remote parties according to the to-be- invited remote party list stored in the memory unit 4, and allocates and records each of the "non-invited” remote parties on the to-be-invited remote party list stored in the memory unit 4 onto one of the sub-lists.
  • the principle of such allocation is to try to have the number of remote parties on each sub-list to be as equal as possible.
  • the list generating unit 5 sends the sub-list or sub-lists thus generated to the invitation unit 3.
  • the media data processing unit 6 receives respective media data, such as audio, video and text data, from all the remote parties that have a connection relationship through the communications unit 1 , processes the media data thereof and the aforesaid media data, and sends the processed media data to each of the remote parties having a connection relationship through the communications unit 1.
  • the media data sent to a remote party having a connection relationship are the results of processing the media data thereof and the media data from the other remote parties having a connection relationship.
  • the invitation unit 3 of the conference initiator selects at least one remote party whose status is "non-invited” according to the status of the to-be-invited remote parties stored in the memory unit 4, and sends an invitation request to the participating unit 2 of the selected remote party through the communications unit 1 according to the contact information of the selected remote party.
  • the number of remote parties that the conference initiator can invite can be set by the user, and can also be determined by the invitation unit 3 according to its available bandwidth.
  • the participating unit 2 of the remote party receiving the invitation request is electrically connected to the media data processing unit 6, sends a successful invitation signal to the invitation unit 3 of the conference initiator through the communications unit 1 , and instructs the media data processing unit 6 to start sending and receiving the media data.
  • the invitation unit 3 of the conference initiator is electrically connected to the media data processing unit 6.
  • the successfully invited remote party acts as a lower-level remote party to the conference initiator, whereas the conference initiator acts a higher-level remote party to the successfully invited remote party.
  • the invitation unit 3 of the conference initiator instructs the media data processing unit 6 to start processing the media data delivered to and fro between itself and the successfully invited remote party, updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote party is "invited,” instructs the list generating unit 5 to generate sub-lists, and sends the generated sub-lists to the participating units 2 of the remote parties at its lower level through the communications unit 1 , respectively.
  • the participating unit 2 of each remote party at every lower level stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation as a new initiating remote party.
  • Each initiating remote party at a lower level will repeat the invitation process of the conference initiator, and a new initiating remote party or new initiating parties are generated until there is no remote party that needs to be invited on the to-be-invited remote party list stored in the memory unit 4 of the latest initiating remote party, i.e., there is no "non-invited" remote party on the to-be-invited remote party list, or there are only those remote parties that cannot be smoothly invited and whose status is "non- invited,” e.g., the remote parties that rejected the invitation or that could not be successfully invited due to factors like busy lines, network problems, etc.
  • the invitation unit 3 of the latest initiating remote party sends the invitation result to the invitation unit 3 of its higher-level remote party through the communications unit 1.
  • the invitation unit 3 of the higher-level remote party receives the invitation results from the invitation units 3 of all the remote parties at its lower level, updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited,” and sends the invitation results through all the even higher levels for status updating at each level up to the invitation unit 3 of the conference initiator.
  • the invitation unit 3 of the conference initiator receives the invitation results from the invitation units 3 of all the remote parties at its lower levels, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited.” If there are still remote parties whose status is "non-invited” on the to-be-invited remote party list stored in the memory unit 4, the conference initiator will repeat the invitation process until there is no remote party that needs to be invited, thereby completing the establishment of the multiparty conference.
  • the method for establishing a multiparty conference by relays includes the following steps:
  • step 800 the user of the conference initiator stores a to-be- invited remote party list in the memory unit 4.
  • the list records the name, contact information and status of each to-be-invited remote party.
  • the status includes a "non-invited” status and an "invited” status.
  • the status of each to-be-invited remote party is set to be "non-invited.”
  • the invitation unit 3 of the conference initiator selects at least one remote party whose status is "non-invited” according to the status of the to-be-invited remote parties stored in the memory unit 4, and sends an invitation request to the participating unit 2 of the selected remote party through the communications unit 1 according to the contact information of the selected remote party.
  • step 802 the invitation unit 3 of the conference initiator inspects whether at least one successful invitation signal was received. In the affirmative, the flow goes to step 803. Otherwise, the flow returns to step 801. In step 803, the successfully invited remote party acts as a lower- level remote party to the conference initiator, whereas the conference initiator acts as a higher-level remote party to the successfully invited remote party.
  • the invitation unit 3 of the conference initiator instructs the media data processing unit 6 to start processing the media delivered to and fro between itself and all the remote parties that have a connection relationship, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited.”
  • the media data processing unit 6 receives the respective media data from all the remote parties at its lower level through the communications unit 1 , processes the media data thereof and the received media data, and sends the processed media data via the communications unit 1 to the remote parties at its lower level.
  • the media data sent by the conference initiator to a remote party at its lower level are the results of processing the media data of the conference initiator and the media data from the other remote parties at its lower level.
  • step 804 the invitation unit 3 of the conference initiator inspects whether there is still any remote party whose status is "non-invited” on the to-be-invited remote party list stored in the memory unit 4. In the affirmative, the flow goes to step 805. Otherwise, the establishment of the multiparty conference is deemed to have been completed.
  • step 805 the invitation unit 3 of the conference initiator instructs the list generating unit 5 to generate contents-exclusive sub-lists whose number corresponds to that of the remote parties with status being
  • step 806 the invitation unit 3 of the conference initiator sends the generated sub-lists to the participating units 2 of the remote parties at its lower level through the communications unit 1.
  • step 807 the participating unit 2 of each remote party at a lower level stores the received sub-list in the memory unit 4, causes the sub- list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote parties at a lower level act as new initiating remote parties.
  • step 808 the invitation unit 3 of the initiating remote party selects at least one remote party whose status is "non-invited” according to the status of the to-be-invited remote parties stored in the memory unit
  • step 809 the invitation unit 3 of the initiating remote party inspects whether at least one successful invitation signal was received. In the affirmative, the flow goes to step 810. Otherwise, the flow skips to step 814.
  • the remote party that has been successfully invited acts as a lower-level remote party to the initiating remote party, whereas the initiating remote party acts as a higher-level remote party to the successfully invited remote party.
  • the invitation unit 3 of the initiating remote party instructs the media data processing unit 6 to start processing the media data delivered to and fro between itself and the remote parties having a connection relationship, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited.”
  • the media data processing unit 6 receives the respective media data from the remote party at its higher level and all the remote parties at its lower level having a connection relationship through the communications unit 1 , processes the media data thereof and the received media data, and sends the processed media data to each of the remote parties that have a connection relationship through the communications unit 1.
  • the media data sent by the initiating remote party to a remote party having a connection relationship are the results of processing the media data of the initiating remote party and the media data from the other remote parties having a connection relationship.
  • the invitation unit 3 of the initiating remote party inspects whether there is still any non-invited remote party on the to-be- invited remote party list stored in the memory unit 4. In the affirmative, the flow goes to step 812. Otherwise, the flow goes to step 814.
  • the invitation unit 3 of the initiating remote party instructs the list generating unit 5 to generate contents-exclusive sub- lists whose number corresponds to that of the remote parties with status being "invited” according to the to-be-invited remote party list stored in the memory unit 4, to allocate and record each of the remote parties whose status is "non-invited” onto one of the sub-lists, and to send the sub-list or sub-lists thus generated to the invitation unit 3.
  • step 813 the invitation unit 3 of the initiating remote party sends the generated sub-list(s) to the participating units 2 of the remote parties at its lower level through the communications unit 1. After completion, the flow returns to step 807.
  • the invitation unit 3 of the initiating remote party sends the invitation results to the invitation unit 3 of the remote party at its higher level.
  • the invitation unit 3 of the remote party at the higher level receives the invitation results from the invitation units 3 of all the remote parties at its lower level, updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited,” and sends the invitation results upward through all the even higher levels for status updating at each level to the invitation unit 3 of the conference initiator.
  • the invitation unit 3 of the conference initiator receives the invitation results from the invitation units 3 of all the remote parties at its lower level, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited.”
  • step 816 the invitation unit 3 of the conference initiator inspects whether there is still any remote party whose status is "non-invited” on the to-be-invited remote party list stored in the memory unit 4. In the affirmative, the flow goes to step 817. Otherwise, it is determined that the establishment of the multiparty conference is completed.
  • the invitation unit 3 of the conference initiator selects at least one remote party whose status is "non-invited” according to the status of the to-be-invited remote parties stored in the memory unit 4, and sends an invitation request to the participating unit 2 of the selected remote party through the communications unit 1 according to the contact information of the selected remote party.
  • step 818 the invitation unit 3 of the conference initiator inspects whether at least one successful invitation signal was received. In the affirmative, the flow returns to step 803. Otherwise, it is determined that the establishment of the multiparty conference is completed.
  • the remote parties include one conference initiator S, a remote party A, a remote party B, a remote party C, a remote party D, a remote party E, a remote party F, a remote party G, a remote party H, a remote party I, and a remote party J.
  • the user of the conference initiator S stores a to-be- invited remote party list including the remote parties A ⁇ J in the memory unit 4, and sets the status of the remote parties A ⁇ J to "non-invited," as shown in Figure 6.
  • step 801 the invitation unit 3 of the conference initiator S sends an invitation request to the participating unit 2 of each of the remote parties A and B through the communications unit 1.
  • step 802 since the invitation unit 3 of the conference initiator S received a successful invitation signal from the participating unit 2 of each of the remote parties A and B, the flow goes to step 803.
  • step 803 the remote parties A and B act as lower-level remote parties to the conference initiator S, whereas the conference initiator S acts as a higher-level remote party to the remote parties A and B.
  • the invitation unit 3 of the conference initiator S instructs the media data processing unit 6 to start processing the media data delivered to and fro between /itself and the remote parties A and B, and updates the status of the remote parties A and B stored in the memory unit 4 so that the status of the remote parties A and B is "invited," as shown in Figure 7.
  • the media data processing unit 6 receives the respective media data from the remote parties A and B through the communications unit 1 , sends the media data thereof and the media data sent by the ⁇ remote party B to the remote party A through the communications unit 1 after processing, and sends the media data thereof and the media data sent by the remote party A to the remote party B through the communications unit 1 after processing.
  • step 804 since there are still remote parties whose status is "non-invited” on the to-be-invited remote party list stored in the memory unit 4 of the conference initiator S, the flow goes to step 805.
  • the invitation unit 3 of the conference initiator S instructs the list generating unit 5 to generate two sub-lists, one sub-list including the remote parties C, D, E and F, the other sub-list including the remote parties G, H, I, and J, and to send the two sub-lists to the invitation unit 3.
  • step 806 the invitation unit 3 of the conference initiator S sends the sub-list including the remote parties C, D, E, and F to the participating unit 2 of the remote party A through the communications unit 1 , and sends the sub-list including the remote parties G, H, I, and J to the participating unit 2 of the remote party B through the Communications unit 1.
  • the participating unit 2 of the remote party A stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote party A acts as a new initiating remote party.
  • the participating unit 2 of the remote party B also stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote party B acts as another new initiating remote party.
  • step 808 the invitation unit 3 of the remote party A sends an invitation request to the participating unit 2 of each of the remote parties C and D through the communications unit 1.
  • step 809 since the invitation unit 3 of the remote party A received a successful invitation signal from the participating unit 2 of each of the remote parties C and D, the flow goes to step 810.
  • the remote parties C and D act as lower-level remote parties to the remote party A, whereas the remote party A acts as a higher-level remote party to the remote parties C and D.
  • the invitation unit 3 of the remote party A instructs the media data processing unit 6 to start processing the media delivered to and fro between itself and the conference initiator S, and the remote parties C and D, and updates the status of the remote parties C and D stored in the memory unit.
  • the media data processing unit 6 receives the media data from the conference initiator S, and the remote parties C and D through the communications unit 1 , sends the media data thereof and the media data from the remote parties C and D to the conference initiator S through the communications unit 1 after processing, sends the media data thereof and the media data from the conference initiator S and the remote party D to the remote party C through the communications unit 1 after processing, and sends the media data thereof and the media data from the conference initiator S and the remote party C to the remote party D through the communications unit 1 after processing.
  • step 811 since there are still remote parties whose status is "non-invited" on the to-be-invited remote party list stored in the memory unit 4 of the remote party A, the flow goes to step 812.
  • the invitation unit 3 of the remote party A instructs the list generating unit 5 to generate two sub-lists, one sub-list including the remote party E, the other sub-list including the remote party F, and to send the two sub-lists to the invitation unit 3.
  • step 813 the invitation unit 3 of the remote party A sends the sub-list including the remote party E to the participating unit 2 of the remote party C through the communications unit 1 , and sends the sub- list including the remote party F to the participating unit 2 of the remote party D. Then, the flow returns to step 807.
  • the participating unit 2 of the remote party C stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote party C acts as a new initiating remote party.
  • the participating unit 2 of the remote party D also stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote party D acts a new initiating remote party. Since the operations of the remote parties C and D are alike, the branch of the remote party D will be omitted in the following description of the steps of the present invention, and only the branch of the remote party C will be exemplified.
  • step 808 the invitation unit 3 of the remote party C sends an invitation request to the participating unit 2 of the remote party E through the communications unit 1.
  • step 809 since the invitation unit 3 of the remote party C received a successful invitation signal from the participating unit 2 of the remote party E, the flow goes to step 810.
  • the remote party E acts as a lower-level remote party to the remote party C
  • the remote party C acts as a higher-level remote party to the remote party E.
  • the invitation unit 3 of the remote party C instructs the media data processing unit 6 to start processing the media data delivered to and fro between itself and the remote parties A and E, and updates the status of the remote party E stored in the memory unit 4 so that the status of the remote party E is "invited.”
  • the media data processing unit 6 receives the media data respectively from the remote parties A and E through the communications unit 1 , sends the media data thereof and the media data from the remote party E to the remote party A through the communications unit 1 after processing, and sends the media data thereof and the media data from the remote party A to the remote party E through the communications unit 1 after processing.
  • step 81 1 since there is no remote party whose status is "non- invited" on the to-be-invited remote party list stored in the memory unit 4 of the remote party C, the flow skips to step 814.
  • the invitation unit 3 of the remote party C sends the invitation result to the invitation unit 3 of the remote party A through the communications unit 1.
  • the other branches perform similar operations as well.
  • the invitation unit 3 of the remote party A receives the invitation results from the invitation unit 3 of each of the remote parties C and D, updates ,the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited," and sends the invitation results to the invitation unit 3 of the conference initiator S.
  • Other branches likewise perform similar operations.
  • the invitation unit 3 of the conference initiator S receives the invitation results from the invitation unit 3 of each of the remote parties A and B, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited.”
  • step 816 since there is no "non-invited" remote party on the to- be-invited remote party list stored in the memory unit 4 of the conference , initiator S, as shown in Figure 8, the establishment of the multiparty conference is deemed to have been completed.
  • the system and method for establishing a multiparty conference by relays does not rely on a centralized server and the underlying service network thereof in order to establish a multiparty conference, and is therefore not subject to constraints of the network provider.
  • a remote party does not have sufficient processing capabilities and sufficient bandwidth to maintain a large number of connections, the number of remote parties joining the multiparty conference will not be limited.
  • the present invention can be applied to system and method for establishing multiparty conference by relays.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

A method for establishing a multiparty conference by relays is adapted for use among a plurality of remote parties participating in the multiparty conference where a conference initiator records a to-be-invited remote party list, and includes the following steps: inviting at least one remote party according to the to-be-invited remote party list; when the at least one remote party is successfully invited, allocating and distributing the information of non-invited remote parties to successfully invited remote parties; instructing the successfully invited remote parties to store received allocation information as the to-be-invited remote party list and act as new initiating remote parties and repeating the above steps until there is no remote party to be invited on the to-be-invited remote party list, thereby completing establishment of the multiparty conference.

Description

DESCRIPTION
SYSTEM AND METHOD FOR ESTABLISHING MULTIPARTY CONFERENCE BY RELAYS
Technical Field
The invention relates to a system and method for establishing a multiparty conference, more particularly to a system and method for establishing a multiparty conference by relays.
Background Art
According to existing methods of establishing connection, conventional multiparty conferences can be divided into two main types: centralized conferences and full mesh conferences.
Referring to Figure 1 , a conventional centralized conference relies on a centralized server 75 and an underlying service network to establish the required point-to-point signal connection with each of the remote parties 71 -74 that join the conference. Before a conference commences, one of the remote parties 71 -74, e.g., the remote party 71 , acts as a conference initiator, invites the other remote parties 72-74 through the underlying service network while holding the call connections, and sends a multiparty conference request to the centralized server 75 to combine the call connections on hold with the active call connection, thereby establishing an active multiparty conference call connection. The centralized server 75 is responsible for receiving media data from all the remote parties 71 -74, proce.ssing the media data, and sending the processed media data back to the remote parties 71-74, respectively.
Since the establishment of such conventional centralized conferences must rely on the centralized server 75 and the underlying service network thereof, it is limited by the network provider. Referring to Figure 2, a conventional full mesh conference does not rely on a centralized server and an underlying service network thereof. Instead, each of the remote parties 91 -94 participating in the conference directly establishes a point-to-point signal connection with the other remote parties 91 -94, and sends media data of its own to the other remote parties 91 -94 in a one-to-one manner.
Although conventional full mesh conferences can be established without relying on the centralized server 75 and the underlying service network thereof, unlike conventional centralized conferences, if the number of remote parties joining the conference is large, the number of connections that need to be established for each of the remote parties 91 -94 will increase with the number of the remote parties. Besides, not every remote party 91 -94 has sufficient processing capability and sufficient bandwidth to maintain so many connections. Therefore, the number of remote parties allowed to participate in a conventional full mesh conference will be limited.
Disclosure of Invention
Therefore, an object of the present invention is to provide a system for establishing a multiparty conference by relays. The system can be employed to invite prescribed remote parties to participate in a multiparty conference by relays.
Another object of the present invention is to provide a method for establishing a multiparty conference by relays. The method can be employed to invite prescribed remote parties to participate in a conference by relays and to return invitation results of establishing the multiparty conference.
Accordingly, the system for establishing a multiparty conference by relays of the present invention is adapted for use in establishing a multiparty conference among a plurality of remote parties installed with the system. The system installed in each remote party includes a communications unit, a memory unit, a participating unit, an invitation unit, and a media data processing unit. The communications unit is for transmitting data to the outside and for receiving data from the outside.
The memory unit is for storing a to-be-invited remote party list that records information of each to-be-invited remote party.
The participating unit is for receiving and responding to incoming invitation requests from other remote parties through the communications unit, and is for storing received allocation information in the memory unit as the to-be-invited remote party list.
The invitation unit is for inviting through the~communications unit at least one non-invited remote party by reference to the to-be-invited remote party list stored in the memory unit, receiving the response from the invited remote parties, allocating and distributing the information of non-invited remote parties to aforesaid successfully invited remote parties, thereby updating and distributing the invitation result to its remote inviting party based on the invitation results returned from aforesaid successfully invited remote parties.
The media data processing unit is for receiving respective media data from all the remote parties having a connection relationship through the communications unit, processing media data thereof and the received media data, and sending the processed media data to each of the remote parties having a connection relationship through the communications unit.
The method for establishing a multiparty conference by relays of this invention is adapted for use among a plurality of remote parties where a remote party initiating the multiparty conference is referred to as the conference initiator and also default initiating remote party. The method comprises the following steps:
(A) instructing the initiating remote party to invite at least one non-invited remote partyby reference to the to-be-invited remote party list;
(B)instructing the initiating remote party to determine whether the at least one remote party is successfully invited, the flow proceeding to step (C) in the affirmative and otherwise, proceeding to step (E); (C) instructing the initiating remote party to act as a higher-level remote party to the successfully invited remote party, where each successfully invited remote party acts as a lower-level remote party to the initiating remote party, and to allocate and distribute the information of non-invited remote parties to its lower-level remote parties; (D) instructing every lower-level remote party to store the received allocation information as the to-be-invited remote party list and act as a new initiating remote party, the flow proceeding to step (A); and
(E)instructing the initiating remote party to send its invitation result upward through all the even higher levels for update of invitation result at each level up to the conference initiator, thereby completing the establishment of the multiparty conference.
Brief Description of Drawings Other features and advantages of the present invention will become apparent in the following detailed description of the preferred embodiment with reference to the accompanying drawings, of which:
Figure 1 is a block diagram to illustrate the connection in a conventional centralized conference;
Figure 2 is a block diagram to illustration the connection in a conventional full mesh conference;
Figure 3 is a system block diagram to illustrate the preferred embodiment of a system and method for establishing a multiparty conference by relays according to the present invention;
Figures 4A, 4B and 4C taken together show a flowchart of the preferred embodiment of the method according to the present invention;
Figure 5 is a block diagram to illustrate the connection in the preferred embodiment; Figure 6 is a status diagram of the preferred embodiment, illustrating the condition of the to-be-invited remote party list prior to the start of the multiparty conference;
Figure 7 is a status diagram of the preferred embodiment, illustrating the condition of the to-be-invited remote party list when a remote party A and a remote party B are successfully invited by a conference initiator S; and
Figure 8 is a status diagram of the preferred embodiment, illustrating the condition of the to-be-invited remote party list when all the to-be-invited remote parties have been successfully invited and the multiparty conference is about to start.
Best Mode for Carrying Out the Invention
- Referring to Figure 3, a system for establishing a multiparty conference by relays of this invention is adapted for establishing a multiparty conference among a plurality of remote parties installed with the system. Each remote party can be a mobile phone, a personal digital assistant (PDA), or any electronic device having networking functionality. Herein below, for the sake of description, the remote party which initiates the multiparty conference is referred to as the "conference initiator."
The system installed within each remote party includes a communications unit 1 , a participating unit 2, an invitation unit 3, a memory unit 4, a list generating unit 5, and a media data processing unit 6.
The communications unit 1 is electrically connected to the participating unit 2, the invitation unit 3, and the media data processing unit 6, respectively, sends the data generated by the aforesaid units to the outside, and receives outside data for one of the units. The communications unit 1 may conduct data transmission based on the Internet Protocol (IP).
The memory unit 4 is electrically connected to the participating unit 2, the invitation unit 3, and the list generating unit 5, respectively, and stores a to-be-invited remote party list. The list records the name, contact information, and status of every to-be-invited remote party. The contact information may be a Telephone Number Universal Resource Identifier (TEL URI), an Internet Protocol Address (IP address), a Session Initiation Protocol Universal Resource Identifier (SIP URI), or any addressable information. The status includes a "non-invited" status and an "invited" status. Prior to establishing the multiparty conference, the user of the conference initiator must first store a to-be-invited remote party list in the memory unit 4, and set the status of every to-be-invited remote party to "non-invited". The list generating unit 5 is electrically connected to the invitation unit 3, generates contents-exclusive sub-lists whose number corresponds to that of the "invited" remote parties according to the to-be- invited remote party list stored in the memory unit 4, and allocates and records each of the "non-invited" remote parties on the to-be-invited remote party list stored in the memory unit 4 onto one of the sub-lists. The principle of such allocation is to try to have the number of remote parties on each sub-list to be as equal as possible. After the allocation, the list generating unit 5 sends the sub-list or sub-lists thus generated to the invitation unit 3.
The media data processing unit 6 receives respective media data, such as audio, video and text data, from all the remote parties that have a connection relationship through the communications unit 1 , processes the media data thereof and the aforesaid media data, and sends the processed media data to each of the remote parties having a connection relationship through the communications unit 1. The media data sent to a remote party having a connection relationship are the results of processing the media data thereof and the media data from the other remote parties having a connection relationship. The invitation unit 3 of the conference initiator selects at least one remote party whose status is "non-invited" according to the status of the to-be-invited remote parties stored in the memory unit 4, and sends an invitation request to the participating unit 2 of the selected remote party through the communications unit 1 according to the contact information of the selected remote party. The number of remote parties that the conference initiator can invite can be set by the user, and can also be determined by the invitation unit 3 according to its available bandwidth. The participating unit 2 of the remote party receiving the invitation request is electrically connected to the media data processing unit 6, sends a successful invitation signal to the invitation unit 3 of the conference initiator through the communications unit 1 , and instructs the media data processing unit 6 to start sending and receiving the media data.
The invitation unit 3 of the conference initiator is electrically connected to the media data processing unit 6. Upon the receipt of the successful invitation signal, the successfully invited remote party acts as a lower-level remote party to the conference initiator, whereas the conference initiator acts a higher-level remote party to the successfully invited remote party. The invitation unit 3 of the conference initiator instructs the media data processing unit 6 to start processing the media data delivered to and fro between itself and the successfully invited remote party, updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote party is "invited," instructs the list generating unit 5 to generate sub-lists, and sends the generated sub-lists to the participating units 2 of the remote parties at its lower level through the communications unit 1 , respectively. The participating unit 2 of each remote party at every lower level stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation as a new initiating remote party. Each initiating remote party at a lower level will repeat the invitation process of the conference initiator, and a new initiating remote party or new initiating parties are generated until there is no remote party that needs to be invited on the to-be-invited remote party list stored in the memory unit 4 of the latest initiating remote party, i.e., there is no "non-invited" remote party on the to-be-invited remote party list, or there are only those remote parties that cannot be smoothly invited and whose status is "non- invited," e.g., the remote parties that rejected the invitation or that could not be successfully invited due to factors like busy lines, network problems, etc.
At this time, the invitation unit 3 of the latest initiating remote party sends the invitation result to the invitation unit 3 of its higher-level remote party through the communications unit 1. The invitation unit 3 of the higher-level remote party receives the invitation results from the invitation units 3 of all the remote parties at its lower level, updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited," and sends the invitation results through all the even higher levels for status updating at each level up to the invitation unit 3 of the conference initiator.
The invitation unit 3 of the conference initiator receives the invitation results from the invitation units 3 of all the remote parties at its lower levels, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited." If there are still remote parties whose status is "non-invited" on the to-be-invited remote party list stored in the memory unit 4, the conference initiator will repeat the invitation process until there is no remote party that needs to be invited, thereby completing the establishment of the multiparty conference. Referring to Figures 4A, 4B and 4C, the method for establishing a multiparty conference by relays according to the present invention includes the following steps:
In step 800, the user of the conference initiator stores a to-be- invited remote party list in the memory unit 4. The list records the name, contact information and status of each to-be-invited remote party. The status includes a "non-invited" status and an "invited" status. The status of each to-be-invited remote party is set to be "non-invited." In step 801 , the invitation unit 3 of the conference initiator selects at least one remote party whose status is "non-invited" according to the status of the to-be-invited remote parties stored in the memory unit 4, and sends an invitation request to the participating unit 2 of the selected remote party through the communications unit 1 according to the contact information of the selected remote party.
In step 802, the invitation unit 3 of the conference initiator inspects whether at least one successful invitation signal was received. In the affirmative, the flow goes to step 803. Otherwise, the flow returns to step 801. In step 803, the successfully invited remote party acts as a lower- level remote party to the conference initiator, whereas the conference initiator acts as a higher-level remote party to the successfully invited remote party. The invitation unit 3 of the conference initiator instructs the media data processing unit 6 to start processing the media delivered to and fro between itself and all the remote parties that have a connection relationship, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited." Besides, the media data processing unit 6 receives the respective media data from all the remote parties at its lower level through the communications unit 1 , processes the media data thereof and the received media data, and sends the processed media data via the communications unit 1 to the remote parties at its lower level. The media data sent by the conference initiator to a remote party at its lower level are the results of processing the media data of the conference initiator and the media data from the other remote parties at its lower level.
In step 804, the invitation unit 3 of the conference initiator inspects whether there is still any remote party whose status is "non-invited" on the to-be-invited remote party list stored in the memory unit 4. In the affirmative, the flow goes to step 805. Otherwise, the establishment of the multiparty conference is deemed to have been completed.
In step 805, the invitation unit 3 of the conference initiator instructs the list generating unit 5 to generate contents-exclusive sub-lists whose number corresponds to that of the remote parties with status being
"invited" according to the to-be-invited remote party list stored in the memory unit 4, to allocate and record each of the remote parties whose status is "non-invited" onto one of the sub-lists, and to send the sub-list or sub-lists thus generated to the invitation unit 3.
In step 806, the invitation unit 3 of the conference initiator sends the generated sub-lists to the participating units 2 of the remote parties at its lower level through the communications unit 1.
In step 807, the participating unit 2 of each remote party at a lower level stores the received sub-list in the memory unit 4, causes the sub- list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote parties at a lower level act as new initiating remote parties.
In step 808, the invitation unit 3 of the initiating remote party selects at least one remote party whose status is "non-invited" according to the status of the to-be-invited remote parties stored in the memory unit
4, and sends an invitation request to the participating unit 2 of the selected remote party through the communications unit 1 according to the contact information of the selected remote party.
In step 809, the invitation unit 3 of the initiating remote party inspects whether at least one successful invitation signal was received. In the affirmative, the flow goes to step 810. Otherwise, the flow skips to step 814.
In step 810, the remote party that has been successfully invited acts as a lower-level remote party to the initiating remote party, whereas the initiating remote party acts as a higher-level remote party to the successfully invited remote party. The invitation unit 3 of the initiating remote party instructs the media data processing unit 6 to start processing the media data delivered to and fro between itself and the remote parties having a connection relationship, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited." Besides, the media data processing unit 6 receives the respective media data from the remote party at its higher level and all the remote parties at its lower level having a connection relationship through the communications unit 1 , processes the media data thereof and the received media data, and sends the processed media data to each of the remote parties that have a connection relationship through the communications unit 1. The media data sent by the initiating remote party to a remote party having a connection relationship are the results of processing the media data of the initiating remote party and the media data from the other remote parties having a connection relationship. In step 81 1 , the invitation unit 3 of the initiating remote party inspects whether there is still any non-invited remote party on the to-be- invited remote party list stored in the memory unit 4. In the affirmative, the flow goes to step 812. Otherwise, the flow goes to step 814. In step 812, the invitation unit 3 of the initiating remote party instructs the list generating unit 5 to generate contents-exclusive sub- lists whose number corresponds to that of the remote parties with status being "invited" according to the to-be-invited remote party list stored in the memory unit 4, to allocate and record each of the remote parties whose status is "non-invited" onto one of the sub-lists, and to send the sub-list or sub-lists thus generated to the invitation unit 3.
In step 813, the invitation unit 3 of the initiating remote party sends the generated sub-list(s) to the participating units 2 of the remote parties at its lower level through the communications unit 1. After completion, the flow returns to step 807.
In step 814, the invitation unit 3 of the initiating remote party sends the invitation results to the invitation unit 3 of the remote party at its higher level. The invitation unit 3 of the remote party at the higher level receives the invitation results from the invitation units 3 of all the remote parties at its lower level, updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited," and sends the invitation results upward through all the even higher levels for status updating at each level to the invitation unit 3 of the conference initiator.
In step 815, the invitation unit 3 of the conference initiator receives the invitation results from the invitation units 3 of all the remote parties at its lower level, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited."
In step 816, the invitation unit 3 of the conference initiator inspects whether there is still any remote party whose status is "non-invited" on the to-be-invited remote party list stored in the memory unit 4. In the affirmative, the flow goes to step 817. Otherwise, it is determined that the establishment of the multiparty conference is completed.
In step 817, the invitation unit 3 of the conference initiator selects at least one remote party whose status is "non-invited" according to the status of the to-be-invited remote parties stored in the memory unit 4, and sends an invitation request to the participating unit 2 of the selected remote party through the communications unit 1 according to the contact information of the selected remote party.
In step 818, the invitation unit 3 of the conference initiator inspects whether at least one successful invitation signal was received. In the affirmative, the flow returns to step 803. Otherwise, it is determined that the establishment of the multiparty conference is completed.
Referring to Figure 5, for purposes of better illustration, the present invention will be exemplified using an example in which a multiparty conference having eleven remote parties is to be established. The remote parties include one conference initiator S, a remote party A, a remote party B, a remote party C, a remote party D, a remote party E, a remote party F, a remote party G, a remote party H, a remote party I, and a remote party J. In step 800, the user of the conference initiator S stores a to-be- invited remote party list including the remote parties A~J in the memory unit 4, and sets the status of the remote parties A~J to "non-invited," as shown in Figure 6.
In step 801 , the invitation unit 3 of the conference initiator S sends an invitation request to the participating unit 2 of each of the remote parties A and B through the communications unit 1.
In step 802, since the invitation unit 3 of the conference initiator S received a successful invitation signal from the participating unit 2 of each of the remote parties A and B, the flow goes to step 803.
In step 803, the remote parties A and B act as lower-level remote parties to the conference initiator S, whereas the conference initiator S acts as a higher-level remote party to the remote parties A and B. The invitation unit 3 of the conference initiator S instructs the media data processing unit 6 to start processing the media data delivered to and fro between /itself and the remote parties A and B, and updates the status of the remote parties A and B stored in the memory unit 4 so that the status of the remote parties A and B is "invited," as shown in Figure 7. Moreover, the media data processing unit 6 receives the respective media data from the remote parties A and B through the communications unit 1 , sends the media data thereof and the media data sent by the ■remote party B to the remote party A through the communications unit 1 after processing, and sends the media data thereof and the media data sent by the remote party A to the remote party B through the communications unit 1 after processing.
In step 804, since there are still remote parties whose status is "non-invited" on the to-be-invited remote party list stored in the memory unit 4 of the conference initiator S, the flow goes to step 805. In step 805, the invitation unit 3 of the conference initiator S instructs the list generating unit 5 to generate two sub-lists, one sub-list including the remote parties C, D, E and F, the other sub-list including the remote parties G, H, I, and J, and to send the two sub-lists to the invitation unit 3. In step 806, the invitation unit 3 of the conference initiator S sends the sub-list including the remote parties C, D, E, and F to the participating unit 2 of the remote party A through the communications unit 1 , and sends the sub-list including the remote parties G, H, I, and J to the participating unit 2 of the remote party B through the Communications unit 1.
In step 807, the participating unit 2 of the remote party A stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote party A acts as a new initiating remote party. The participating unit 2 of the remote party B also stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote party B acts as another new initiating remote party. Since the operations of the remote parties A and B are alike, the branch of the remote party B will be omitted in the following description of the steps of the present invention, and only the branch of the remote party A will be exemplified. In step 808, the invitation unit 3 of the remote party A sends an invitation request to the participating unit 2 of each of the remote parties C and D through the communications unit 1.
In step 809, since the invitation unit 3 of the remote party A received a successful invitation signal from the participating unit 2 of each of the remote parties C and D, the flow goes to step 810.
In step 810, the remote parties C and D act as lower-level remote parties to the remote party A, whereas the remote party A acts as a higher-level remote party to the remote parties C and D. The invitation unit 3 of the remote party A instructs the media data processing unit 6 to start processing the media delivered to and fro between itself and the conference initiator S, and the remote parties C and D, and updates the status of the remote parties C and D stored in the memory unit. 4 so that the status of the remote parties C and D is "invited." Moreover, the media data processing unit 6 receives the media data from the conference initiator S, and the remote parties C and D through the communications unit 1 , sends the media data thereof and the media data from the remote parties C and D to the conference initiator S through the communications unit 1 after processing, sends the media data thereof and the media data from the conference initiator S and the remote party D to the remote party C through the communications unit 1 after processing, and sends the media data thereof and the media data from the conference initiator S and the remote party C to the remote party D through the communications unit 1 after processing.
In step 811 , since there are still remote parties whose status is "non-invited" on the to-be-invited remote party list stored in the memory unit 4 of the remote party A, ,the flow goes to step 812.
In step 812, the invitation unit 3 of the remote party A instructs the list generating unit 5 to generate two sub-lists, one sub-list including the remote party E, the other sub-list including the remote party F, and to send the two sub-lists to the invitation unit 3.
In step 813, the invitation unit 3 of the remote party A sends the sub-list including the remote party E to the participating unit 2 of the remote party C through the communications unit 1 , and sends the sub- list including the remote party F to the participating unit 2 of the remote party D. Then, the flow returns to step 807.
In step 807, the participating unit 2 of the remote party C stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote party C acts as a new initiating remote party. The participating unit 2 of the remote party D also stores the received sub-list in the memory unit 4, causes the sub-list to become the to-be-invited remote party list, and instructs the invitation unit 3 to start operation, i.e., the remote party D acts a new initiating remote party. Since the operations of the remote parties C and D are alike, the branch of the remote party D will be omitted in the following description of the steps of the present invention, and only the branch of the remote party C will be exemplified.
In ,step 808, the invitation unit 3 of the remote party C sends an invitation request to the participating unit 2 of the remote party E through the communications unit 1. In step 809, since the invitation unit 3 of the remote party C received a successful invitation signal from the participating unit 2 of the remote party E, the flow goes to step 810.
In step 810, the remote party E acts as a lower-level remote party to the remote party C, whereas the remote party C acts as a higher-level remote party to the remote party E. The invitation unit 3 of the remote party C instructs the media data processing unit 6 to start processing the media data delivered to and fro between itself and the remote parties A and E, and updates the status of the remote party E stored in the memory unit 4 so that the status of the remote party E is "invited." Moreover, the media data processing unit 6 receives the media data respectively from the remote parties A and E through the communications unit 1 , sends the media data thereof and the media data from the remote party E to the remote party A through the communications unit 1 after processing, and sends the media data thereof and the media data from the remote party A to the remote party E through the communications unit 1 after processing.
In step 81 1 , since there is no remote party whose status is "non- invited" on the to-be-invited remote party list stored in the memory unit 4 of the remote party C, the flow skips to step 814.
In step 814, the invitation unit 3 of the remote party C sends the invitation result to the invitation unit 3 of the remote party A through the communications unit 1. The other branches perform similar operations as well. The invitation unit 3 of the remote party A receives the invitation results from the invitation unit 3 of each of the remote parties C and D, updates ,the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited," and sends the invitation results to the invitation unit 3 of the conference initiator S. Other branches likewise perform similar operations.
In step 815, the invitation unit 3 of the conference initiator S receives the invitation results from the invitation unit 3 of each of the remote parties A and B, and updates the status of the to-be-invited remote parties stored in the memory unit 4 so that the status of the successfully invited remote parties is "invited."
In step 816, since there is no "non-invited" remote party on the to- be-invited remote party list stored in the memory unit 4 of the conference , initiator S, as shown in Figure 8, the establishment of the multiparty conference is deemed to have been completed.
In sum, the system and method for establishing a multiparty conference by relays according to the present invention does not rely on a centralized server and the underlying service network thereof in order to establish a multiparty conference, and is therefore not subject to constraints of the network provider. Besides, by establishing connections by relays, there is no need to establish a point-to-point signal connection for every remote party with all the other remote parties participating in the multiparty conference. Therefore, even if a remote party does not have sufficient processing capabilities and sufficient bandwidth to maintain a large number of connections, the number of remote parties joining the multiparty conference will not be limited.
While the present invention has been described in connection with what is considered the most practical and preferred embodiment, it is understood that this invention is not limited to the disclosed embodiment but is intended to cover various arrangements included within the spirit and scope of the broadest interpretation so as to encompass all such modifications and equivalent arrangements.
Industrial Applicability
The present invention can be applied to system and method for establishing multiparty conference by relays.

Claims

1. A method for establishing a multiparty conference by relays, which is adapted for use among a plurality of remote parties, one remote parties which initiates the multiparty conference acting as a conference initiator and also default initiating remote party, and storing a to-be- invited remote party list about each to-be-invited remote party, said method comprising the following steps:
(A) instructing the initiating remote party to invite at least one non-invited remote partyby reference to the to-be-invited remote party list;
(B) instructing the initiating remote party to determine whether the at least one remote party is successfully invited, the flow proceeding to step (C) in the affirmative and otherwise, proceeding to step (E); (C) instructing the initiating remote party to act as a higher-level remote party to the successfully invited remote party, where each successfully invited remote party acts as a lower-level remote party to the initiating remote party, and to allocate and distribute the information of non-invited remote parties to its lower-level remote parties; (D) instructing every lower-level remote party to store the received allocation information as the to-be-invited remote party list and act as a new initiating remote party, the flow proceeding to step (A); and
(E) instructing the initiating remote party to send its invitation result upward through all the even higher levels for update of invitation result at each level up to the conference initiator, thereby completing the establishment of the multiparty conference.
2. The method according to Claim 1 , wherein step (C)includes the following steps: (C-1 ) instructing the initiating remote party to act as a higher-level remote party to the successfully invited remote party, where each successfully invited remote party acts as a lower-level remote party to the initiating remote party; (C-2) instructing the initiating remote party to determine whether there is any remote party whose status is non-invited on the to-be-invited remote party list, the flow proceeding to step (C-3) in the affirmative, the flow skipping to (E) if otherwise; and
(C-3) instructing the initiating remote party to allocate and distribute the information of non-invited remote parties to its lower-level remote parties.
3. The method according to Claim 1 , wherein, every to-be-invited remote party list records the name, contact information and status of each to-be-invited remote party, the status including a non-invited status and an invited status, the status of each to-be-invited remote party, being pre-set to be non-invited.
4. The method according to Claim 3, wherein, in step (C), the initiating remote party further updates the status of the to-be-invited remote parties so that the status of the successfully invited remote party is invited.
5. The method according to Claim 4, wherein, in step (C), the initiating remote party generates content-exclusive sub-lists whose number corresponds to that of the remote parties whose status is invited according to the to-be-invited remote party list and allocates and records each of the remote parties whose status is non-invited onto one of the sub-lists.
6. The method according to Claim 4, wherein, in step (E), every higher-level remote party receives the invitation results from all the remote parties at its lower level, and updates the stored status of the to- be-invited remote parties so that the status of the successfully invited remote parties is invited.
7. The method according to Claim 6, wherein, in step (E), the conference initiator further determines whether there remains any remote party to be further invited after complete update of the to-be-invited remote party list and in the affirmative, the conference initiator acts as a new initiating remote party, the flow returning to step (A), and otherwise, it is determined that the establishment of the multiparty conference is completed.
8. The method according to Claim 1 , wherein, in step (B), the initiating remote party further receives the respective media data from all the remote parties which have a connection relationship, processes the media data thereof and the received media data, and sends the processed media data to each of the remote parties having a connection relationship, the media data sent by the initiating remote party to a remote party having a connection relationship being the results of processing the media data of the initiating remote party and the media data from the other remote parties having a connection relationship.
9. The method according to Claim 8, wherein the media data include any or combination of audio, video and text data.
10. The method according to Claim 3, wherein data transmission is conducted using an Internet communications protocol.
11. The method according to Claim 10, wherein the contact information is an Internet protocol address.
12. The method according to Claim 10, wherein the contact information is a Session Initiation Protocol Universal Resource. Identifier.
13. The method according to Claim 10, wherein the contact information is a telephone number.
14. The method according to Claim 1 , wherein the number of remote parties that can be invited by each remote party is set by the user.
15. The method according to Claim 1 , wherein the number of remote parties that can be invited by each remote party is determined according to bandwidth.
16. The method according to Claim 5, wherein the principle of allocating the remote parties whose status is non-invited to the sub-lists is to try to have the number of remote parties on the sub-lists to be substantially the same.
17. A system for establishing a multiparty conference by relays, which is adapted for establishing a multiparty conference among a plurality of remote parties installed with said system, said system which is installed in each of the remote parties comprising: a communications unit for transmitting data to the outside and receiving data from the outside; a memory unit for storing a to-be-invited remote party list that records information of each to-be-invited remote party; a participating unit for receiving and responding to incoming invitation requests from other remote parties through the communications unit, and for storing received allocation information in the memory unit as the to-be-invited remote party list; an invitation unit for inviting through the communications unit at least one non-invited remote party by reference to the to-be-invited remote party list stored in the memory unit, for receiving the response from the invited remote parties, and for allocating and distributing the information of non-invited remote parties to aforesaid successfully invited remote parties, thereby updating and distributing the invitation result to its remote inviting party based on the invitation results returned from aforesaid successfully invited remote parties; and a media data processing unit for receiving respective media data from all the remote parties having a connection relationship through the communications unit, processing media data thereof and the received media data, and sending the processed media data to each of the remote parties having a connection relationship through the communications unit.
18. The system according to Claim 17, wherein said memory unit stores a to-be-invited remote party list, said list recording the name, contact information and status of each to-be-invited remote party, said status including a non-invited status and an invited status, said status of each to-be-invited remote party being pre-set to be non-invited.
19. The system according to Claim 18, wherein said invitation unit updates the status of the to-be-invited remote parties stored in said memory unit after receiving response from the invited remote parties, so that the status of the successfully invited remote parties is invited.
20. The system according to Claim 19, further comprising a list generating unit, wherein said list generating unit generates content- exclusive sub-lists whose number corresponds to that of the remote parties whose status is invited according to the to-be-invited remote party list stored in said memory unit and allocates and records each of the remote parties whose status is non-invited onto one of the sub-lists, said sub-lists utilized by said invitation unit as the information of non- invited remote parties.
21. The system according to Claim 19, wherein when said invitation unit has updated the status of the to-be-invited remote parties stored in said memory unit according to the invitation results thus received, and finds out there still remains any remote party whose status is non-invited on the to-be-invited remote party list stored in said memory unit, said invitation unit repeats the invitation process until there is no remote party that needs to be invited, thereby completing the establishment of the multiparty conference.
22. The system according to Claim 19, wherein a remote party initiating said multiparty conference is referred to as the conference initiator and also default initiating remote party, after the invitation unit of said initiating remote party has received the successful invitation signal, the successfully invited remote party acting as a lower-level remote party to said initiating remote party, and said initiating remote party acting as a higher-level remote party to the successfully invited remote party, each lower-level remote party starting operation as lower-level remote party and repeating the same invitation process until there is no remote party that needs to be invited on the to-be-invited remote party list stored in said memory unit of the latest initiating remote party, then the invitation unit of said latest initiating remote party sending the invitation result upward through the invitation unit of all even-higher higher-levels to said conference initiator causing status update at each level where the status of the to-be-invited remote parties is updated so that the status of the successfully invited remote party is invited, thereby completing the establishment of the multiparty conference.
23. The system according to Claim 20, wherein a remote party initiating said multiparty conference is referred to as the conference initiator and also default initiating remote party, after the invitation unit of said initiating remote party has received the successful invitation signal, the successfully invited remote party acting as a lower-level remote party to said initiating remote party, and said initiating remote party acting as a higher-level remote party to the successfully invited remote party, each lower-level remote party starting operation as lower-level remote party and repeating the same invitation process until there is no remote party that needs to be invited on the to-be-invited remote party list stored in said memory unit of the latest initiating remote party, then the invitation unit of said latest initiating remote party sending the invitation result upward through the invitation unit of all even-higher higher-levels to said conference initiator causing status update at each level where the status of the to-be-invited remote parties is updated so that the status of the successfully invited remote party is invited, thereby completing the establishment of the multiparty conference.
24. The system according to Claim 21 , wherein a remote party initiating said multiparty conference is referred to as the conference initiator and also default initiating remote party, after the invitation unit of said initiating remote party has received the successful invitation signal, the successfully invited remote party acting as a lower-level remote party to said initiating remote party, and said initiating remote party acting as a higher-level remote party to the successfully invited remote party, each lower-level remote party starting operation as lower-level remote party and repeating the same invitation process until there is no remote party that needs to be invited on the to-be-invited remote party list stored in said memory unit of the latest initiating remote party, then the invitation unit of said latest initiating remote party sending the invitation result upward through the invitation unit of all even-higher higher-levels to said conference initiator causing status update at each level where the status of the to-be-invited remote parties is updated so that the status of the successfully invited remote party is invited, thereby completing the establishment of the multiparty conference.
25. The system according to Claim 17, wherein said media data include any or combination of audio, video and text data.
26. The system according to Claim 18, wherein data transmission is conducted using an Internet communications protocoi.
27. The system according to Claim 26, wherein the contact information is an Internet protocol address.
28. The system according to Claim 26, wherein the contact information is a Session Initiation Protocol Universal Resource Identifier.
29. The system according to Claim 26, wherein the contact information is a telephone number.
30. The system according to Claim 17, wherein the number of remote parties that can be invited by said invitation unit is set by the user.
31. The system according to Claim 17, wherein the number of remote parties that can be invited by said invitation unit is determined according to bandwidth.
32. The system according to Claim 20, wherein the principle of allocation employed by said list generating unit is to try to have the number of remote parties on the sub-lists to be substantially the same.
PCT/JP2006/314200 2005-07-12 2006-07-12 System and method for establishing multiparty conference by relays WO2007007902A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNA2005100836315A CN1897535A (en) 2005-07-12 2005-07-12 Method and apparatus for relay multiple-party conference
CN200510083631.5 2005-07-12

Publications (1)

Publication Number Publication Date
WO2007007902A1 true WO2007007902A1 (en) 2007-01-18

Family

ID=36952846

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/314200 WO2007007902A1 (en) 2005-07-12 2006-07-12 System and method for establishing multiparty conference by relays

Country Status (2)

Country Link
CN (1) CN1897535A (en)
WO (1) WO2007007902A1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108134915B (en) * 2014-03-31 2020-07-28 宝利通公司 Method and system for a hybrid topology media conferencing system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020065886A1 (en) * 2000-11-28 2002-05-30 Sang-Gil Kim Method for selecting RTP element in dynamic multicast tree for multimedia conference
US20020078150A1 (en) * 2000-12-18 2002-06-20 Nortel Networks Limited And Bell Canada Method of team member profile selection within a virtual team environment
US6697365B1 (en) * 1999-06-10 2004-02-24 Charles Hayes Messenger Method of listener transmitted broadcasting

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6697365B1 (en) * 1999-06-10 2004-02-24 Charles Hayes Messenger Method of listener transmitted broadcasting
US20020065886A1 (en) * 2000-11-28 2002-05-30 Sang-Gil Kim Method for selecting RTP element in dynamic multicast tree for multimedia conference
US20020078150A1 (en) * 2000-12-18 2002-06-20 Nortel Networks Limited And Bell Canada Method of team member profile selection within a virtual team environment

Also Published As

Publication number Publication date
CN1897535A (en) 2007-01-17

Similar Documents

Publication Publication Date Title
CN100574316C (en) The Multimedia session controller
US20170019436A1 (en) Assigning resources for conference call
EP2452487B1 (en) Controlling multi-party communications
US9313081B2 (en) System and method for data transfer between terminals in voice communication under voice over internet protocol (VOIP)
US7975073B2 (en) Middleware server for interfacing communications, multimedia, and management systems
US8068866B2 (en) Group communication server
CN101453524B (en) Multimedia service implementing method
US20100199320A1 (en) Multimodal escalation to endpoints in enhanced communication systems
JP2007534266A (en) System and method for including participants in a conference call
EP1131935B1 (en) Announced session control
US10187529B2 (en) Systems and methods for conducting conference calls
JP2007110631A (en) Group call server, group call system, terminal and method for controlling group calls
CN102893573A (en) Conference reservation method and system
US8798037B2 (en) Apparatus and method for providing recording service in IP multimedia subsystem
US6522645B1 (en) Computer telephony integration system and operation method therein
CN101674305A (en) Method and system for realizing multimedia conference
CN101938498A (en) Method, device and system for instant communication between digital TV terminals
CN1984373B (en) System and method for providing multimedia contents in a communication system
US20090310601A1 (en) Communication control device, communication terminal device, communication system, and communication control method
CN101444070B (en) Telecommunications system and method of initiating file transfers from voice endpoints
US20080080692A1 (en) System and method for joining a conference call or multimedia conference
KR100693038B1 (en) apparatus and method of providing Caller Identification in VoIP service system
CN101815138B (en) Method and device for leaving meeting message
AU2003200825B2 (en) Apparatus and method for compulsively receiving multi-calls over internet protocol phones in internet protocol telephony system
CN103081437B (en) For communication system and the method for high-end communication session

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06781207

Country of ref document: EP

Kind code of ref document: A1