US20150055513A1 - Group Communication System and Method - Google Patents

Group Communication System and Method Download PDF

Info

Publication number
US20150055513A1
US20150055513A1 US14/531,948 US201414531948A US2015055513A1 US 20150055513 A1 US20150055513 A1 US 20150055513A1 US 201414531948 A US201414531948 A US 201414531948A US 2015055513 A1 US2015055513 A1 US 2015055513A1
Authority
US
United States
Prior art keywords
network entity
conference
new user
user
another network
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US14/531,948
Inventor
Dan Houghton
Antonio Varanda
Tiago Loureiro
Mike Bartlett
Mikael Suvi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Skype Ltd Ireland
Microsoft Corp
Original Assignee
Skype Ltd Ireland
Microsoft Corp
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
Priority to GB0608595.5 priority Critical
Priority to GB0608595A priority patent/GB2437785A/en
Priority to US11/799,451 priority patent/US8886719B2/en
Application filed by Skype Ltd Ireland, Microsoft Corp filed Critical Skype Ltd Ireland
Priority to US14/531,948 priority patent/US20150055513A1/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BARTLETT, MIKE, VARANDA, ANTONIO, HOUGHTON, DAN, LOUREIRO, TIAGO, SUVI, MIKAEL
Publication of US20150055513A1 publication Critical patent/US20150055513A1/en
Assigned to SKYPE LIMITED reassignment SKYPE LIMITED CORRECTIVE ASSIGNMENT TO CORRECT THE RECEIVING PARTY PREVIOUSLY RECORDED ON REEL 034167 FRAME 0802. ASSIGNOR(S) HEREBY CONFIRMS THE RECEIVING PARTY SHOULD BE SKYPE LIMITED. Assignors: BARTLETT, MIKE, VARANDA, ANTONIO, HOUGHTON, DAN, LOUREIRO, TIAGO, SUVI, MIKAEL
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/56Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00
    • H04L29/02Communication control; Communication processing
    • H04L29/06Communication control; Communication processing characterised by a protocol
    • H04L29/0602Protocols characterised by their application
    • H04L29/06027Protocols for multimedia communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1003Signalling or session protocols
    • H04L65/1006SIP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/40Services or applications
    • H04L65/403Arrangements for multiparty communication, e.g. conference
    • H04L65/4038Arrangements for multiparty communication, e.g. conference with central floor control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/80QoS aspects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/36Network-specific arrangements or communication protocols supporting networked applications involving the display of network or application conditions affecting the network application to the application user
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/22Supervisory, monitoring, management, i.e. operation, administration, maintenance or testing arrangements
    • H04M3/36Statistical metering, e.g. recording occasions when traffic exceeds capacity of trunks
    • H04M3/367Traffic or load control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/56Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/563User guidance or feature selection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/56Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/563User guidance or feature selection
    • H04M3/565User guidance or feature selection relating to time schedule aspects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Interconnection arrangements between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2203/00Aspects of automatic or semi-automatic exchanges
    • H04M2203/50Aspects of automatic or semi-automatic exchanges related to audio conference
    • H04M2203/5054Meet-me conference, i.e. participants dial-in

Abstract

A method is described for providing voice conferencing between a plurality of users over a communications network. A host user initiates a voice conference using a host user terminal, where pluralities of user terminals join the voice conference. On joining the voice conference, each participant user terminal displays a participant user interface, and the host user terminal displays a host user interface. At least one participant user activates a request control on the participant user interface which, in turn, transmits a request to the host user to speak in the voice conference. The host user can then activate a selection control to select from among participant users who transmitted the request, the speech of the at least one selected user being transmitted to all of the plurality of users.

Description

    RELATED APPLICATIONS
  • This application is a divisional of, and claims priority to, under 35 U.S.C. §120, U.S. patent application Ser. No. 11/799,451, filed on May 1, 2007 entitled “Group Communication System and Method”, which in turn claims priority to United Kingdom Application Serial No. 0608595.5, filed on May 2, 2006 entitled “Voice Over Internet Protocol (VOIP) Group Conference Communication” the disclosures of which are incorporated by reference herein in their entirety.
  • BACKGROUND
  • At least some embodiments relate to a group communication system and method, particularly but not exclusively for use in a peer-to-peer telecommunications system.
  • Telephone conferencing systems enable telephone calls in which three or more people are connected and can participate in the same conversation. Telephone conferencing systems are a useful way of allowing a group of people to discuss a subject in an interactive manner, without the requirement for the people to be in the same physical location.
  • Telephone conferencing using the traditional public switched telephone network (“PSTN”) is achieved by each participant in the conference dialing a pre-determined telephone number that connects the participant to a conference server (also called a conference bridge). The conference server answers the telephone calls from the multiple participants to the conference, and performs the function of mixing the voice signals from each participant together and distributing the mixed signals to all of the participants. In this way, each participant is able to hear what every other participant in the conference is saying.
  • In addition to using the traditional PSTN system, telephone conferencing can also be achieved using Internet telephony systems. Internet telecommunications systems allow the user of a device, such as a personal computer, to make telephone calls across a computer network such as the Internet. These systems are beneficial to the user as they are often of significantly lower cost than traditional telephony networks, such as fixed line or mobile networks. This may particularly be the case for long distance calls. These systems may utilize voice over internet protocol (“VoIP”) over an existing network (e.g. the Internet) to provide these services, although alternative protocols can also be used. To use an Internet telephony service, the user must install and execute client software on their device. The client software provides the VoIP connections as well as other functions such as registration and authentication. A telephone call may be made using VoIP in accordance with methods known in the art, such as disclosed in WO 2005/009019.
  • Telephone conferencing using VoIP is performed in a similar manner to telephone conferencing using the PSTN. However, rather than using the PSTN to connect to the conference server, the terminals of the user connect to a conference server using the Internet. The VoIP conference server performs the decoding of VoIP audio streams from each of the participants in the conference, mixes the audio streams from the participants, encodes the mixed audio streams to VoIP, and distributes the mixed audio streams to all the participants via the Internet.
  • The use of peer-to-peer technology (and its associated low cost) and the ubiquitous nature of the Internet enables large numbers of users to come together from all over the world to discuss various subjects. However, the presence of a large number of participants in a telephone conference can give rise to significant problems. When the number of participants in a telephone conference are small, then a single conference server may be capable of handling all the connections from the participants. However, as the number of participants increases, the load on the conference server also increases. In particular, the CPU load increase as the number of participants increases. Therefore, for a conference server to support a large number of users, it must have a large amount of processing power. When the load on the conference server reaches a certain limit, then the conferencing server must either refuse the addition of more participants or risk becoming unstable due to overloading.
  • In addition to the above-mentioned issues regarding the handling of large numbers of users at the conference server, there are also other issues regarding the control and management of large conferences to consider. From a usability perspective, it becomes very difficult to manage a discussion over a telephone conference when the number of participants is large. This is because several people will tend to try and talk at any instance in time, leading to overlapping voices and confusion, which interrupts the flow of the discussion. This can particularly be the case if there is any delay present on the voice signals, as this can cause people to repeatedly talk over each other, leading to a stop-start type of conversation. In addition, there is also a problem with identifying a particular participant who is talking from a large group of people. When a person begins talking in a telephone conference containing a large group of people, the identity of the person talking may not be clear. This may require the person to be interrupted in order to establish their identity, and may in turn lead to the problems above of several people talking at once. These problems limit the usefulness of telephone conferences for discussions between large groups of people.
  • SUMMARY
  • Therefore, as traditional telephone conferences are not able to handle large numbers of people, there is a need for a system for allowing large groups of people to communicate in a controlled manner.
  • According to one or more embodiments, there is provided a method of providing voice conferencing between a plurality of users over a communications network, the plurality of users comprising a host user and a plurality of participant users, the method comprising:
  • the host user initiating a voice conference using a host user terminal connected to said communications network;
  • the plurality of users joining the voice conference, each of the plurality of users joining the conference by using a client executed at their respective user terminals, wherein on joining the voice conference the user terminal of each of the plurality of participant users displays a participant user interface and the user terminal of the host displays a host user interface;
  • at least one of the plurality of participant users activating a request control on the participant user interface, said client transmitting via said communication network a request to the host user to speak in the voice conference in response to the activation of the request control; and
  • the host user receiving an indication on the host user interface of the request from the at least one of the plurality of participant users, and activating a selection control on the host interface to select from among the at least one of the plurality of users who transmitted the request, the speech of the at least one selected user being transmitted to all of the plurality of users over the communications network.
  • In one embodiment the method further comprises the step of blocking the speech from other users that have not been selected by the host user.
  • In another embodiment the method further comprises the step of displaying at the participant user interface and the host interface a list of the plurality of users in the voice conference. In another embodiment the list of the plurality of users in the voice conference indicates which of the plurality of users has been selected by the host user to speak in the voice conference.
  • In another embodiment the method further comprises the step of the host user activating a muting control associated with a participant user displayed on the host user interface, the speech of the associated participant user being blocked in response to the activation of said muting control.
  • In another embodiment the method further comprises the step of the host user activating a muting control associated with the plurality of participant users displayed on the host user interface, the speech of all the plurality of participant users being blocked in response to the activation of said muting control. In another embodiment the speech from the user blocked by the host user is blocked at a server in the communications network. In another embodiment the speech from the user blocked by the host user is blocked at the client of the user blocked by the host user.
  • In another embodiment the method further comprises the step of the host user activating a removal control associated a participant user displayed on the host user interface, the associated participant user being removed from the voice conference in response to the activation of the removal control.
  • In another embodiment the step of initiating a voice conference further comprises displaying details of the voice conference to the plurality of users.
  • According to at least one other embodiment, there is provided a system for providing voice conferencing between a plurality of user terminals over a communications network, the plurality of user terminals comprising a host user terminal and a plurality of participant user terminals, the system comprising:
  • a client executed at each of the plurality of user terminals for joining a user of each of the plurality of user terminals to a voice conference;
  • a participant user interface displayed on each of the plurality of participant user terminals comprising a request control for requesting to speak in the voice conference, the client being arranged to transmit a request message to the host user terminal in response to the activation of the request control;
  • a host user interface displayed on the host user terminal comprising an indication that at least one of the users of the participant user terminals is requesting to speak in the voice conference, the host user interface further comprising at least one selection control for selecting at least one of the users of the participant user terminals requesting to speak in the voice conference, the speech of the at least one selected users being transmitted to the plurality of user terminals over the communications network in response to the activation of said selection control.
  • In one embodiment the speech from other users that have not been selected by the user of the host use terminal are blocked from being transmitted to the plurality of user terminals over the communications network.
  • In another embodiment the participant user interface and the host interface is arranged to display a list of the users of the plurality of user terminals in the voice conference. In another embodiment the list of the plurality of users in the voice conference indicates which of the plurality of users has been selected by the user of the host user terminal to speak in the voice conference.
  • In another embodiment the host user interface further comprises a muting control associated with a user of a participant user terminal, the speech of the associated user being blocked in response to the activation of said muting control. In another embodiment the host user interface further comprises a muting control associated with the plurality of participant users, the speech of all the plurality of participant users being blocked in response to the activation of said muting control. In another embodiment the speech from the user blocked by the host user is blocked at a server in the communications network. In another embodiment the speech from the user blocked by the host user is blocked at the client of the user blocked by the host user.
  • In another embodiment the host user interface further comprises a removal control associated with a user of a participant user terminal, the associated user being removed from the voice conference in response to the activation of the removal control.
  • According to at least one other embodiment, there is provided a user terminal for providing voice conferencing over a communications network, comprising:
  • a client executed at the user terminal for joining a user of the user terminal to a voice conference;
  • a user interface displayed on the user terminal comprising a request control for requesting to speak in the phone conference, the client being arranged to transmit a request message to the user terminal of a host user in response to the activation of the request control.
  • According to at least one other embodiment, there is provided a user terminal for providing voice conferencing over a communications network, comprising:
  • a client executed at the user terminal for joining a user of the user terminal to a voice conference;
  • a user interface displayed on the user terminal comprising an indication that at least one user in the voice conference is requesting to speak in the voice conference, the user interface further comprising at least one selection control for selecting at least one of the users requesting to speak in the voice conference, the speech of the at least one selected user being transmitted to all of the users in the voice conference over the communications network in response to the activation of said selection control.
  • According to at least one other embodiment, there is provided a computer program product comprising program code means which when loaded into a computer controls the computer to carry out the method above.
  • According to at least one other embodiment, there is provided a method of managing a voice conference in which a plurality of users are connected to a first network entity, the method comprising the steps of:
  • receiving a request to add a new user to a voice conference at a control node;
  • the control node analyzing a conference load on the first network entity and if the conference load exceeds a threshold, selecting another network entity and transmitting the request to said another network entity;
  • receiving the request from the control node at the another network entity, and determining whether the another network entity is currently included in the voice conference; and
  • if the another network entity is not currently included in the voice conference, creating a bridging connection between the another network entity and the first network entity, connecting the new user to the another network entity, and adding the new user to the voice conference via said bridging connection.
  • In one embodiment the step of analyzing the conference load further comprises the steps of: determining whether the first network entity can support the new user; if the first network entity cannot support the new user, checking whether a further network entity is currently included in the voice conference; if a further network entity is currently included in the voice conference, determining whether the further network entity can support the new user; if the further network entity is not currently included in the voice conference or cannot support the new user, selecting the another network entity.
  • In another embodiment the step of selecting the another network entity comprises selecting the least loaded available network entity.
  • In another embodiment the step of analyzing the conference load comprises determining the CPU load. In another embodiment the step of analyzing the conference load comprises determining the number of users connected to the first network entity.
  • In another embodiment the step of connecting the new user to the another network entity further comprises authenticating the new user prior to adding the new user to the voice conference.
  • In another embodiment the method further comprises the step of the control node accessing a database and determining whether a queried network entity has contacted the database within a predetermined time period, whereby, if the queried network entity has not contacted the database within the predetermined time period, the control node ceases to transmit requests to said queried network entity.
  • In another embodiment the step of creating a bridging connection further comprises the steps of determining whether the creation of the bridging connection has failed, and if so substituting the another network entity for the first network entity.
  • In another embodiment the method further comprises the steps of: monitoring the bridging connection between the another network entity and the first network entity; if the step of monitoring observes that the connection has failed, determining whether the first network entity has been substituted; and if the first network entity has not been substituted, substituting the another network entity for the first network entity.
  • According to at least one other embodiment, there is provided a system for managing a voice conference in which a plurality of users are connected to a first network entity, the system comprising:
  • a control node comprising means for receiving a request to add a new user to a voice conference, means for analyzing a conference load on the first network entity, means for selecting another network entity if the conference load exceeds a threshold, and means for transmitting the request to said another network entity, and
  • another network entity comprising means for receiving the request from the control node, means for determining whether the another network entity is currently included in the voice conference, means for creating a bridging connection between the another network entity and the first network entity, if the another network entity is not currently included in the voice conference, means for connecting the new user to the another network entity, and means for adding the new user to the voice conference via said bridging connection.
  • In one embodiment the means for analyzing the conference load further comprises: means for determining whether the first network entity can support the new user; means for checking whether a further network entity is currently included in the voice conference if the first network entity cannot support the new user; means for determining whether the further network entity can support the new user if a further network entity is currently included in the voice conference; and means for selecting the another network entity if the further network entity is not currently included in the voice conference or cannot support the new user.
  • In another embodiment the means for selecting another network entity comprises means for selecting the least loaded available network entity.
  • In another embodiment the means for analyzing the conference load comprises means for determining the CPU load. In another embodiment the means for analyzing the conference load comprises means for determining the number of users connected to the first network entity.
  • In another embodiment the means for connecting the new user to the another network entity further comprises means for authenticating the new user prior to adding the new user to the voice conference.
  • In another embodiment the control node further comprises means for accessing a database and means for determining whether a queried network entity has contacted the database within a predetermined time period, whereby, if the queried network entity has not contacted the database within the predetermined time period, the control node ceases to transmit requests to said queried network entity.
  • In another embodiment the means for creating a bridging connection further comprises means for determining whether the creation of the bridging connection has failed, and if so substituting the another network entity for the first network entity.
  • In another embodiment the another network entity further comprises means for monitoring the bridging connection between the another network entity and the first network entity, means for determining whether the first network entity has been substituted if the means for monitoring observes that the connection has failed and means for substituting the another network entity for the first network entity if the first network entity has not been substituted.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • For a better understanding of the various embodiments, and to show how the same may be put into effect, reference will now be made, by way of example, to the following drawings in which:
  • FIG. 1 shows a first embodiment for establishing a voice conference using VoIP;
  • FIG. 2 shows a second embodiment for establishing a voice conference using VoIP;
  • FIG. 3 shows a system for managing the load on conference servers;
  • FIG. 4 shows a flowchart of a process for handling call requests at a SIP proxy;
  • FIG. 5 shows a flowchart of a process for handling a call request at a conference server;
  • FIGS. 6A-C show flowcharts of the processes performed in the case of a failure in the conference servers;
  • FIG. 7 shows a webpage for creating, viewing and joining conferences;
  • FIG. 8A-B shows a webpage for entering conference creation details;
  • FIG. 9 shows a guide webpage displaying scheduled conferences;
  • FIG. 10 shows an announcement box displaying a scheduled conference;
  • FIGS. 11A-C show a control window presented to the host of an ongoing conference;
  • FIGS. 12A-B show a control window presented to the participant of an ongoing conference;
  • FIG. 13 shows the network elements used to control a conference; and
  • FIGS. 14A-B shows two embodiments for muting participants of a conference.
  • DETAILED DESCRIPTION
  • Described herein is a system and method for allowing groups of people to interact in a controlled manner using voice communication. In one or more embodiments, a number of users can participate in a voice conference discussion using VoIP (or another packet-based voice communication protocol). The system for providing the voice conferencing service is reliable and scalable for large groups of people. In addition, the system provides a technique for ensuring that the problems associated with large groups of people communicating on a shared medium are avoided, as will be discussed hereinafter.
  • Reference will first be made to FIG. 1, in which is shown a first embodiment for establishing a voice conference using VoIP. The first embodiment illustrates the case where only a small number of users are participating in the conference. This embodiment may be limited to, for example, only five users or less, although the skilled person will appreciate that this is an arbitrary number and the number of users can be limited to any suitable amount.
  • FIG. 1 shows a host user 102, who is operating a user terminal 104. The host 102 is the user that is establishing the voice conference. In other words, the host user 102 is setting up a new voice conference, as opposed to joining a pre-existing one. The procedure for setting up the voice conference from the perspective of the user is discussed later herein. The user terminal 104 may be a personal computer (“PC”), personal digital assistant (“PDA”), mobile phone, cordless telephone or other type of electronic device capable of connecting to a network.
  • Client software 106 is installed and executed on the user terminal 104. The client software 106 is provided by the operator of a telephony system, and allows the user of the terminal 104 to make VoIP calls to other users of the telephony system (or to other telephony systems). The user terminal 104 is connected to a network (not shown) via a network port, and may be connected via a cable (wired) connection or a wireless connection. The network may be the Internet.
  • The host user 102 has scheduled a voice conference to occur at a specific time and this has been advertised in advance (in accordance with methods described hereinafter). Other users are also present that have requested to join the conference, and are denoted participants 108 in FIG. 1. The participants 108 are operating user terminals 110 that may be similar to those of the host 102, and the terminals of the participants 108 are executing client software 112 similar to that of the host 102.
  • When the conference starts, each of the participants 108 are connected via VoIP to the user terminal 104 of the host 102. The VoIP audio stream from the users (both host and participants) is sent to the user terminal 104 of the host 102. The client software 106 executed on the user terminal 104 of the host 102 decodes the VoIP audio streams from all the users. The decoded audio streams are mixed, such that each user is provided with a mixed audio stream that includes the audio streams of each of the other users (but does not include the audio stream of the user for which the mixed stream is intended). Each of the mixed streams are then encoded and sent to the appropriate user. The reason that a different stream needs to be mixed and encoded for each user is that it is not desirable for a user's voice to be heard returning to the same user. This is particularly the case since there is a delay incurred in the transmission of the audio stream and the decoding/encoding process, and the user would therefore hear their voice delayed by a short period of time, which would be disconcerting to the user.
  • The voice conference can be set up in this manner due to the peer-to-peer (“P2P”) nature of addressable network packet protocols, such as VoIP. This permits the decentralized connection of the participants to the user terminal 104 of the host 102.
  • However, this technique is only suitable for a limited number of users participating in the conference, due to the requirement to decode, mix and encode the audio streams at the client 106 of the host 102. The ability of the client 106 to achieve this may depend on the processing power of the user terminal 104, which is difficult to determine from the perspective of the operator of the telephony system. In addition, the data rate of the connection to the network of the user terminal 104 may not be sufficient to support a large number of participants.
  • If a conference is required for a larger number of users, then the system shown in FIG. 2 can be utilized. FIG. 2 shows a second embodiment for establishing a voice conference using VoIP. FIG. 2 illustrates a host user 102, using a terminal 104 which is executing client software 106 in the same manner as outlined above with reference to FIG. 1. The user terminal 104 is connected to a network via a network port as described above. The network may again be the Internet.
  • In the embodiment shown in FIG. 2, the host 102 has scheduled a conference for a large number of participants (using a method as will be described hereinafter). As a result of this, the system is not based on a P2P structure. Rather, the host 102 is connected to a centralized conference server 202, which may be remotely located in the network and operated by the operator of the telephony system.
  • Participants 108 (using user terminals 110 executing client software 112, as described with reference to FIG. 1) can join the conference at the scheduled time. However, rather than connecting directly to the user terminal 104 of the host 102, the participants 108 connect to the conference server 202. The conference server 202 is arranged to perform the function of decoding the VoIP audio streams from each of the users, and mixing and encoding audio streams to be sent to each of the users. Therefore, the same functionality as performed at the client software 106 of the host 102 described above with reference to FIG. 1 is now performed at the conference server 202.
  • As the conference server 202 is a dedicated server performing the tasks of decoding, mixing and encoding the audio streams, it is able to handle a significantly larger number of users participating in the voice conference. Furthermore, the conference server 202 can be connected to a fast data-rate network connection, to ensure that sufficient bandwidth is present to support the connections to all the users. Therefore, using the system shown in FIG. 2, a voice conference can be established for a relatively large number of participants.
  • In summary, if the voice conference has been scheduled for a small number of participants then the system shown in FIG. 1 can be used to operate the voice conference. In this case, there may be a strict limit set for the number of users that can join the conference (for example five users). If more users above this limit attempt to join the conference, then they may be blocked from joining However, if the conference has been scheduled as a large conference, then the system shown in FIG. 2 is used, and a larger number of users are able to join the conference. Nevertheless, although the system shown in FIG. 2 can support a larger number of users, the conference server is still limited by its processing power and hence limited in the number of users it can support. Therefore, as the number of users in the conference increases, then the load on the conference server must be appropriately managed.
  • The management of the conference servers is described with reference to FIGS. 3, 4 and 5. Reference is first made to FIG. 3, which shows the system for managing the load on the conference servers. FIG. 3 illustrates a number of clients (302-306) participating in a voice conference. In FIG. 3, there are p participants illustrated. The clients 302-306 are the same as those shown running on the user terminals in FIGS. 1 and 2.
  • The VoIP conference uses the known Internet session initiation protocol (“SIP”) to initiate, control and terminate the voice sessions to the conference server. Each of the p clients 302-306 connects to a SIP proxy server 308. The SIP proxy server 308 is connected to all the available conference servers (310-314) that can be used to support VoIP conferences, and also a conferences database 316. FIG. 3 illustrates n conference servers. Each of the n conference servers can create a connection to any of the other conference servers. Each of the n conference servers are connected to the conferences database 316, which stores information about the ongoing conferences and servers. In particular, the conference servers 310-314 frequently update the conferences database 316 with information regarding their CPU load and the number of users supported by the server. This information can be used to determine how loaded the server is.
  • The operation of the load management system shown in FIG. 3 will now be described with reference to the flowcharts in FIGS. 4 and 5. FIG. 4 illustrates the process that occurs at the SIP proxy server 308 when a SIP request message arrives from a client 302-306.
  • In step S402, a SIP request message arrives at the SIP proxy server 308 from a client 302-306. Then, in step S404, the SIP proxy 308 interrogates the conferences database 316 to determine if the original conference server where the conference was booked can accept another user. This is determined by obtaining the CPU load and number of users from the conferences database 316, and comparing this to a threshold value. If the conference server where the conference was originally booked can accept another user, then in step S406 the message is forwarded to the original conference server. If, however, the original conference server cannot accept any new requests because it is too loaded, then at step S408 the SIP proxy 308 determines whether one or more other conference servers are also being used to support users for this conference. The process of spanning a conference over multiple servers is called “bridging”, and is described in more detail hereinafter. The connection between the original conference server and the other server used to support users is called a “bridge connection” and the other server used to support users is called a “bridged conference server”.
  • If the conference has been spanned over multiple servers and one or more bridged conference servers already exist for this conference, then at step S409 the SIP proxy checks with the conferences database 316 whether these bridged servers are already excessively loaded. If at step S410 the bridged servers are not excessively loaded, then in step S412 the SIP proxy forwards the SIP message to the least loaded bridged conference server.
  • If, however, it is determined in step S408 that no bridged conference servers already exist, or it is found in step S410 that all the bridged conference servers are excessively loaded, then at step S414 the SIP proxy 308 uses information from the conferences database 316 to determine which of the available conference servers is the least loaded. It is then determined in step S416 whether the least loaded server available is over its load limit. If the least loaded server is not over its load limit then the SIP proxy 308 forwards the SIP message to the least loaded server in step S418. Alternatively, in step S420, if the least loaded server is already over the load limit, then the SIP proxy 308 informs the user that they cannot join the conference with the message “temporarily not available” (SIP status code 480).
  • The above description with reference to FIG. 4 outlined the operation of the process that occurs at the SIP proxy server 308 when a SIP request message arrives from a client 302-306. Reference is now made to FIG. 5, which outlines the process that is performed at a conference server (310-314) when a request is made for a user to join a conference. This can be either the first user to join the conference, or a new user joining an already established conference. The request to the conference server can be sent from the SIP proxy following steps S406, S412 or S418 as outlined above with reference to FIG. 4. In addition, the request can also be another conference server being added as a participant, as part of the process of creating a bridged server.
  • In step S502, the conference server receives the request to join a conference.
  • In step S504, the conference server determines the type of channel that is being used to connect to the server. In particular, it is determined in step S506 whether the client 302-306 is connecting directly to the conference server (via the SIP proxy 308), or whether the request is from another conference server (for example a bridged server) attempting to connect.
  • If a SIP request is received directly from the client, then, in step S508, the conference server checks with the conferences database 316 whether the conference specified in the request message is booked. If the conference is not booked in the database 316, the conference server sends a message back to the user stating that the conference number was invalid in step S510.
  • If the conference is booked in the database 316, the conference server checks in step S512 whether the conference was booked for this particular server. This is achieved by comparing the server prefix in the request message with the server prefix of the conference server that is performing the steps in FIG. 5.
  • If the conference server is the original server for which the conference was booked, then in step S514 the user is validated using the database 316, and then joins the conference at step S516.
  • Returning again to step S512, if the conference was not originally booked for this server, then in step S518 the server determines if this conference is already running on this server. If the conference is already running on this server (i.e. it is a bridged server for this conference) then at step S514 the user is validated using the database 316, and then joins the conference at step S516. If, however, the conference is not already running on this server then at step S520 the server creates a bridge connection to the server on which the conference was originally booked.
  • As mentioned, a bridged conference server is used to handle the load of further users when the original conference server is excessively loaded. Bridging operates by creating a direct connection between the two servers, and creating two new participants, one in the original server and one in the bridged server. The connection between the servers is used to transmit the voice signals from all the users in the bridged conference server to the original server as a single voice stream, and vice versa. Therefore, to the original server, the single voice stream from the bridged server (which comprises all the voice signals from the users of the bridged server) appears as if it was from a single participant (the new participant added as part of the bridging). Similarly, the bridged server receives all the voice signals from the original server through the new single participant added to the bridged server.
  • Following the creation of the bridge connection, the user is validated at step S514 using the database 316, and then joins the conference at step S516.
  • Returning again to step S506, if the request is from another conference server, then the step of validation can be skipped, as another conference server from the available servers under the control of the operator does not need to be validated, and the server can be added to the conference at step S522.
  • In summary, using the system shown in FIG. 3 and the processes shown in FIGS. 4 and 5, the load on the conference servers is managed. The processes shown operate to create a scalable structure of multiple conference servers as the load increases. Furthermore, this method of managing the load on the servers is also resilient in the case of failure, as will be described presently.
  • Reference is now made to FIG. 6A-C, in which are shown flowcharts illustrating the procedure in the case of a failure in the conference servers. The system is designed to manage failures in a controlled manner, and to substitute failed servers whenever possible to minimize disruption to conferences. This is known as the failover process.
  • Reference is first made to FIG. 6A, which shows the process performed by the SIP proxy server 308 (as illustrated in FIG. 3) in order to detect a failed conference server. In step S602 a client attempts to connect to a conference server via the SIP proxy 308. In step S604, the SIP proxy 308 checks when the last update to the conferences database 316 was made by the conference server. As mentioned previously, the conference servers 310-314 update the database 316 with information regarding their CPU load and number of users. If, however, there is a software or hardware failure of the conference server, these updates will cease. The SIP proxy server determines at step S606 whether the last update was longer than, for example, 15 seconds ago.
  • If the database 316 was updated within the last 15 seconds, then the request to the conference server can proceed as normal in step S608, as outlined previously in FIGS. 4 and 5. If, however, the database 316 was not updated in the last 15 seconds, then the SIP proxy server 308 determines that the conference server has failed. If this is the case, then in step S610 the SIP proxy server directs the call to an alternative unloaded server. The procedure for selecting the server to use can be the same as that outlined in FIG. 4 with regards to load management. Obviously, the timeout between updates can be any value and is not limited to the example of 15 seconds.
  • Reference is now made to FIG. 6B, which illustrates the process performed by a conference server 310-314 (as illustrated in FIG. 3) in the case of a new conference server attempting to set up a bridge connection to a failed server. This procedure only applies to servers that are not the original server on which the conference was established and on which a bridge connection does not already exist (i.e. the procedure shown in FIG. 5 has been performed up to step S522). The server is also assumed to be sufficiently unloaded to allow it to support the new user.
  • In step S612 a call arrives to the conference server (which is not the original server). This call could be directed to the server by the process shown in FIG. 6A, if the original server has been detected as failed. Alternatively the call could be directed to the server by the load management processes shown in FIG. 4. As this is not the original server and does not currently have a bridge connection to the original server, at step S614 this server will attempt to set up a bridge connection to the original server. The conference server determines if the attempt to set up the bridge connection has failed in step S616.
  • If the attempt to set up the bridge connection succeeds, then the original server has clearly not failed, and the procedure can continue as normal in step S618 (see FIG. 5). However, if the original server has failed, then the attempt to set up the bridge connection will fail, and the original server will not respond to the connection request. In this case, in step S620, the new conference server will attempt to substitute the original server, as will be described in more detail below.
  • Reference is now made to FIG. 6C, which illustrates the process performed by a conference server 310-314 (as illustrated in FIG. 3) in the case of a bridged conference server detecting a failure in the original server. The process shown in FIG. 6C only applies in the case of a conference server which is not the original server, which has an existing bridge connection to the original server.
  • In step S622 the bridged server detects the loss of the connection to the original server. Then, in step S624, the bridged server attempts to reconnect to the original server, and in step S626 it is determined whether the reconnection attempt failed. If the reconnection attempt succeeded, then the original server has not failed, and the bridge connection can continue as before in step S628. If the reconnection attempt failed, however, the bridged server will attempt to substitute the failed original server in step S630.
  • First, the bridged server will check whether a substitution has already occurred in step S632. The substitution may already have been made to another server, since the original failed server may have had several bridged servers connected to it, which may have previously detected the failure and performed the substitution. All of the bridged servers connected to the original failed server may attempt to substitute the original server, but only one of them will be able to update a table in the conferences database 316 and become the substitute.
  • If it is determined in step S632 that a substitute has already been made, then in step S634 the bridged server is reconnected to the substitute server. Alternatively, if it is determined that a substitute has not already been made, then in step S636 the server performs the process of substituting for the failed original server. Therefore, the process outlined in FIG. 6C allows a single bridged server to substitute the original server, and all the other bridged servers that may have been connected to the original server will reconnect to the substitute. In this way, only the calls on the original failed server will be dropped from the conference, and the calls on the other bridged servers can continue to speak to each other.
  • The process of substitution of a server is not only used in the case of the failover processes outlined above with reference to FIGS. 6B and 6C. The substitution process is also used whenever a conference server needs to be deactivated for the purposes of bug fixing or updating/upgrading. In these instances a method is required of deactivating the server whilst maintaining ongoing conferences and providing a way for conferences booked to occur on a server to be held even if the server is taken down.
  • To perform the substitution process a type of software tool is used to trigger an event. The server to be deactivated is put in an inactive state and the least loaded of the available conference servers is chosen to substitute the inactive server. From this moment on, no more conferences will be booked for the inactive server until it is reactivated.
  • When a new client attempts to join a conference booked for the inactive server, the client is redirected to the substitute server. The substitute server checks if this conference is already running on it. If the conference is already running on the substitute server, the new client is added to the conference. If the conference is not already running on the substitute server, then the substitute server checks the conferences database 316 to determine whether there are still clients connected to the inactive server in this conference. If there are still existing clients connected to this conference on the inactive server, then the substitute server creates a bridge connection to the inactive server so that the new client on the substitute server can talk to the pre-existing clients in the conference. If there aren't any pre-existing clients in the conference connected to the inactive server, then the substitute server can create the conference and add the new client to it.
  • The inactive server can only be totally deactivated when there are no more bridge connections or clients connected thereto. Furthermore, once the server has been deactivated, it can only be reactivated again once there are no users in any of the conferences originally booked for the deactivated server. This is because the participants in the conference on the substitute server cannot be moved from the substitute server to the reactivated server, and any new users would attempt to join the reactivated server, and not the substitute where the conference was actually ongoing. When the server is reactivated, it updates the database 316 to activate itself in the server list and removes the substitute server. The above procedure therefore provides a method of substituting a server without interrupting ongoing conferences.
  • When users leave a conference, the resources must be released as appropriate. In particular, when a user leaves a conference and the user was connected to a bridged conference server, the bridged server checks if the user was the last user connected to it. If the user was the last user connected to the bridged server, the server removes bridge connection to the original server, and updates the database to remove the record of the conference being held on the bridged server.
  • The above description details the structure of the conferencing system and outlines the procedures performed in the network to manage the conference. Described hereinafter is the operation of the conferencing system from the perspective of the user. This outlines the techniques used to manage the issues associated with large groups of people communicating on a shared medium, as mentioned previously.
  • The users can create, view and join conferences using a webpage provided by the operator of the conferencing system and client software installed and executed on the user terminals of the users. An example of a webpage 700 provided by the operator of the conferencing system can be seen illustrated in FIG. 7. The user views the webpage 700 by executing a web browser program on the user terminal and navigating to the address of the webpage 700.
  • A conference is created and scheduled by a user using the webpage 700 such as that illustrated in FIG. 7. The webpage 700 contains a hyperlink 702 labelled “Create a Skypecast”. The user can use a pointing device to click on this link 702 to begin the process of creating and scheduling a conference.
  • Upon clicking the link, the user's web browser navigates to a conference creation webpage 800 such as that shown in FIG. 8A. The conference creation webpage 800 comprises a form for the user to enter information regarding the conference that user wishes to create. The form comprises a first field 802 for the user to enter a title to be displayed for the conference, and an optional second field 804 for the user to enter a short description of the subject matter of the conference.
  • The user makes a selection using buttons 806 regarding the size of the conference to be set up. In the example webpage 800 shown in FIG. 8A, the user has two options for the size of the conference, either up to 100 people or up to 5 people. The selection by the user determines the maximum number of users that can connect to the conference. In particular, this selection determines whether the conference will be established using the peer-to-peer structure as described above with reference to FIG. 1, or using the centralized server structure as described above with reference to FIG. 2.
  • The form on the webpage 800 continues in FIG. 8B, which illustrates the lower portion of the form to which the user has scrolled. In the next section of the form the user selects from the buttons 808 to determine whether the conference starts immediately, or whether it starts at a specified time. If user has selected to start the conference at a specified time, the user enters the time using the options for time and date from the drop-down lists 810. The user also defines the duration of the conference using the drop-down list 812.
  • The user can optionally enter a keyword (known as a “tag”) in field 814. The tags can be used to define the subject matter of the conference. In particular, the tags can provide information on the subject of the conference that may not be clear from the title defined in field 802. For example, the tag may be a general keyword such as “music” or “football”, which may not be explicitly referred to in the title of the conference. The tags are used when a user is searching for a conference on a particular subject. For example referring again to FIG. 7, a search field 704 is shown on the webpage 700, into which the user may enter a search term and in response to which scheduled or ongoing conferences related to the search term will be displayed to the user. The searching functionality can utilize the information contained in the tags to return results that are relevant to a particular subject.
  • The user can optionally choose a picture to be associated with the conference from a selection such as those shown in 816. When the above information has been entered in to webpage 800 the user can create the conference by clicking on the button 818 labelled “Create”. By entering the information in the webpage 800 and creating the conference the user becomes the host of the conference. The host of the conference has specific control over the operation of the conference as will be discussed hereinafter. If the conference was set up as a large conference, it will be allocated a conference server which acts as the original server as referred to with regards to FIGS. 4 and 5. The allocation of the conference server may be based on a random allocation, although other methods of allocating a server may also be used.
  • Once a conference has been created by a user it is listed on a “guide” webpage, such as that shown in FIG. 9. The guide webpage 900 displays the conferences that are currently ongoing or are scheduled to occur. This can be structured in a similar manner to a “TV guide”, in that the conferences are listed in the order in which they are to start. For example the webpage 900 shows an example conference 902 entitled “Learn about Skypecasts” which is listed along with the name of the host user and the scheduled start time of the conference. The user can also select different tabs to change which conferences are listed in the guide. For example, the user can choose to see all current and scheduled conferences by selecting tab 904, only ongoing conferences by selecting tab 906, only conferences starting soon by selecting tab 908, featured conferences selected by the operator by clicking on tab 910, or only those conferences for which the current user is the host by clicking on tab 912. Featured conferences may also be listed on the main conference webpage 700 shown in FIG. 7, such as the conference 706 entitled “Learn about Skypecasts”.
  • In addition to the guide webpage 900 shown in FIG. 9 and the webpage 700 shown in FIG. 7, conferences can also be listed on other webpages which are not operated by the operator of the conference system. For example, conferences can be listed on third party webpages using an announcement box such as that illustrated in FIG. 10. The announcement box 1000 provides information regarding the title of the conference 1002, the host of the conference 1004 and the time at which the conference is scheduled/started 1006. The announcement box can be included in third party webpages to publicize a conference discussion related to the subject matter of the third party webpage. An announcement box may be included in the third party webpage in the form of a hypertext markup language (“HTML”) snippet or as an RSS feed in accordance with techniques known in the art.
  • A user can join a conference (either one that is about to start, or one that is currently ongoing) by clicking on a link marked “Join the Skypecast” which is shown against the conference listed on the guide webpage 900, on the main webpage 700, or on a third party webpage in an announcement box 1000. When the “join” link is clicked by the user, the client software executed on the user terminal dials a number associated with the conference that is to be joined. The number to dial is stored along with the conference details, but may not be directly visible to the user. The dialing of the number causes the client software to connect to the conference server in accordance with techniques described hereinabove.
  • A user cannot join a conference that has not yet started. However, the user is able to select a link labelled “Remind me” associated with a conference that the user wishes to join. When the desired conference is about to start, the user is sent a prompt to remind him to join the conference.
  • When a conference is in operation, the host user has control over the way in which the conference is run. FIGS. 11A-C show the control window presented to the host of an ongoing conference. The control window 1100 displays the title of the conference 1102, the elapsed time of the conference 1104 and the number of participants in the conference 1106. The participants in the conference are shown in a list 1108 within the control window 1100. The control window may not be large enough to view all the participants in the conference, and if so scroll bar is provided to allow the user to scroll through the full list of participants.
  • Unlike traditional telephone conferences, the host user has control over which participants are able to speak at any one time. This is because a large number of participants are able to take part in the conferences, and if many of them are speaking simultaneously the discussion becomes unintelligible. The host user can select which of the participants are able to speak in the conference. In other words, the host can select which of the participants will be muted (i.e. not heard by any of the other participants in the conference) or unmuted (i.e. can be heard by all of the other participants in the conference). The host has buttons 1110 next to each participant to mute them. In addition, the host has a “Mute Everyone” button 1112, which will mute every participant in the conference (apart from the host). The effect of activating the “Mute Everyone” button 1112 can be seen in FIG. 11B, where all participants are muted. The buttons 1114 next to the participants are now labelled “Unmute”, as all the participants are currently muted. In addition, the button 1116 is now labelled “Unmute Everyone”, and can be activated to unmute all the participants. FIG. 11C shows the case where one participant 1118 is muted, and two participants 1120, 1122 are unmuted.
  • If a participant is muted and wishes to speak in the conference he must first request to be unmuted (or “request the microphone”) from the host. The conference window displayed to a participant in the conference (not the host) is shown illustrated in FIG. 12A. This window 1200 shows similar information to the host's control window in FIG. 11A-C, but also includes a button 1202 for requesting the microphone from the host.
  • When the participant requests the microphone from the host, this is indicated to the host by the icon 1124 flashing (or alternatively animating or changing color) in the control window 1100 in FIG. 11A (the same icon is also shown in the participants window 1200 to indicate who is requesting the microphone). The host can choose to let the user speak in the conference by using the mute/unmute button 1110 shown next to the participant. The host may choose to only give the microphone to a single user at a time, or the host may give it to several users or to all participants. This allows the conference to be controlled in an effective way if there are many participants present. For example, the host may give the microphone to a small group of people, such as a “panel”, who can talk freely on a subject, and then may request questions from the remainder of the participants. The participants can request the microphone to ask their question of the “panel”, who can respond accordingly.
  • The participants that are currently speaking and those requesting the microphone are brought to the top of the list of participants shown in both the host's control window 1100 and the window 1200 of the participants, so that they may be easily viewed by the users. Icons 1204 are shown next to the names of the participants in the window 1200 to indicate if the user is currently muted or not. This allows all the participants to easily identify who is speaking in the conference, which is useful when a large number of participants are present. FIG. 12B shows the case where the participant is not currently muted, and can be heard by all the participants of the conference. The button to request the microphone from the host is not present in this case, as the user is unmuted, and hence already “has the microphone”.
  • In addition to muting a participant or allocating a participant the microphone, the host can also eject a participant from the conference. This may be useful if, for example, the user is being disruptive to the conference discussion. The host may do this by using the buttons 1126 shown in FIG. 11A.
  • The network elements used to control the conference are shown illustrated in FIG. 13. The elements shown in FIG. 13 control the booking, updating and deleting of conferences as well as the muting, unmuting and removal of users from the conference. A web or client interface 1302 (such as the client of the host or a web page for booking a conference) can connect to a manager proxy 1304. The web or client interface 1302 may connect to the manager proxy 1304 via other elements, but these are beyond the scope of this application. The manager proxy 1304 acts as a single point of contact for managing the conference. This is required since the users participating in the conference may be spread over several different servers, and the manager proxy 1304 allows the client to contact a single centralized entity, which can then manage the requests to the different servers as appropriate. The manager proxy is connected to the conference database 316 and conference servers 310-314 (discussed previously with reference to FIG. 3). The manager proxy 1304 receives a request from the web or client interface (e.g. to remove a user) and determines the particular server to which this request should be directed.
  • Reference is now made to FIGS. 14A and 14B, which illustrate two embodiments for implementing the muting of participants in the conference. FIGS. 14A and 14B show a host user 102 with a user terminal 104 running a client 106. The host user is controlling an ongoing conference, which is being run on the conference server 202. Connected to the conference server 202 is a participant 108 with a user terminal 110 executing a client 112. This is the same scenario as illustrated previously in FIG. 2. The host 102 wishes to mute the audio stream coming from the participant 108.
  • FIG. 14A illustrates an embodiment in which the muting is performed at the conference server. The client 112 on the participant's user terminal 110 is receiving the mixed audio stream from the conference server, as indicated by the arrow 1402. Speech from the participant 108 is encoded by the client 112 into an audio stream and transmitted to the conference server 202, as represented by arrow 1404. However, since the host 102 has muted the participant 108, the conference server does not distribute the speech from the participant 108 to all the other participants. Instead, the conference server discards the audio stream from the participant 108. This is represented in FIG. 14A by the “muting point” 1406 being located at the conference server 202. This embodiment has the advantage of providing a simple centralized way of muting the users. However, it does have the disadvantage of wasting bandwidth, as the audio stream 1404 is sent from the participant to the conference server, only to be discarded.
  • FIG. 14B illustrates the second embodiment in which the muting is performed at the client. As before, the client 112 on the participant's user terminal 110 is receiving the mixed audio stream from the conference server, as indicated by the arrow 1402. However, as well as sending the mixed audio stream to the participant 108, the conference server 202 is also transmitting muting information to the client 112. The client 112 is informed that the host 102 has muted the participant 108, and therefore does not encode any speech from the participant 108, and does not transmit the audio stream 1404 to the conference server 202. This is represented in FIG. 14B by the “muting point” 1408 being located at the client 112.
  • The embodiment in FIG. 14B has the advantage of saving bandwidth between the participant and the conference server, as the audio stream is not transmitted to the conference server unless it is needed. However, this embodiment does require more information to be sent to the client from the conference server.
  • The above-described system and method provides an effective way of delivering voice-based group communication to a large group of people. The use of the Internet allows the conferences be scheduled in advance and can be open for anyone to join and discuss a subject. This allows large groups of people to discuss issues in a controlled way, with a scalable and reliable server architecture to ensure that the large numbers of participants can be supported.
  • A known alternative method used for discussion between large groups of people is through online forums and chat rooms. An online forum is usually run over the World Wide Web, and allows a large number of users to discuss a subject through the posting of messages in the form of text, which are then visible to all users of the forum in a chronological order. Subjects that are being discussed are often advertised on a webpage, and a user can join the discussion by reading the messages posted to date and then adding their own message to the discussion. A user can also create a new discussion (known as a thread) by posting a first message under a new subject, which can then be responded to by other users. The problem with an online forum is that it is limited in its interactivity. A user of the forum can post a message, but then must wait until another user has read the message and written and posted a response before getting a reply. This causes a considerable delay between the posting of a message and the response. However, an online forum does avoid the problems described hereinabove with reference to telephone conferences comprising large numbers of participants.
  • A variation of an online forum that allows a greater degree of interactivity is known as a chat room. A chat room operates in a similar manner to the forum described above, but the text typed by the user is transmitted in real time. Therefore, participants in the chat room can engage in a form of conversation in which a message is typed and transmitted instantly to all participants in the chat room, and can be immediately responded to by another user. An example of a known protocol used in chat rooms is Internet relay chat (“IRC”). Despite chat rooms providing a greater degree of interactivity than message-based online forums, they are still significantly less interactive than speech. The act of typing invariably delays the response from a user to a larger degree than is present with speech. In addition, many users may be much more comfortable interacting with others through speech rather than text. The system and method described herein overcomes these problems by providing a technique for voice communication between large numbers of users, therefore providing the necessary degree of interactivity.
  • While various embodiments have been described, it will be understood to those skilled in the art that various changes in form and detail may be made without departing from the scope of the claimed subject matter.

Claims (20)

What is claimed is:
1. A method of managing a voice conference in which a plurality of users are connected to a first network entity, the method comprising:
receiving a request to add a new user to a voice conference at a control node;
the control node analyzing a conference load on the first network entity and if the conference load exceeds a threshold, selecting another network entity and transmitting the request to said another network entity;
receiving the request from the control node at the another network entity, and determining whether the another network entity is currently included in the voice conference; and
if the another network entity is not currently included in the voice conference, creating a bridging connection between the another network entity and the first network entity, connecting the new user to the another network entity, and adding the new user to the voice conference via said bridging connection.
2. The method according to claim 1, wherein the analyzing the conference load further comprises:
determining whether the first network entity can support the new user;
responsive to determining the first network entity cannot support the new user, checking whether a further network entity is currently included in the voice conference;
responsive to determining the further network entity is currently included in the voice conference, determining whether the further network entity can support the new user; and
responsive to determining that the further network entity is not currently included in the voice conference or cannot support the new user, selecting the another network entity.
3. The method according to claim 2, wherein the selecting the another network entity further comprises selecting the least loaded available network entity.
4. The method according to claim 1, wherein the analyzing the conference load further comprises determining the CPU load.
5. The method according to claim 1, wherein the analyzing the conference load further comprises determining the number of users connected to the first network entity.
6. The method according to claim 1, wherein the step of connecting the new user to the another network entity further comprises authenticating the new user prior to adding the new user to the voice conference.
7. The method according to claim 1, further comprising:
the control node accessing a database; and
determining whether a queried network entity has contacted the database within a predetermined time period, whereby, if the queried network entity has not contacted the database within the predetermined time period, the control node ceases to transmit requests to said queried network entity.
8. The method according to claim 1, wherein the creating a bridging connection further comprises:
determining whether the creation of the bridging connection has failed; and
responsive to determining the creation of the bridging connection has failed, substituting the another network entity for the first network entity.
9. The method according to claim 1, further comprising:
monitoring the bridging connection between the another network entity and the first network entity;
responsive to the monitoring the bridging connection observing that the connection has failed, determining whether the first network entity has been substituted; and
responsive to determining the first network entity has not been substituted, substituting the another network entity for the first network entity.
10. A system for managing a voice conference in which a plurality of users are connected to a first network entity, the system comprising:
a control node configured to:
receive a request to add a new user to a voice conference;
analyze a conference load on the first network entity;
select another network entity if the conference load exceeds a threshold; and
transmit the request to said another network entity; and
another network entity configured to:
receive the request from the control node;
determine whether the another network entity is currently included in the voice conference;
create a bridging connection between the another network entity and the first network entity, if the another network entity is not currently included in the voice conference;
connect the new user to the another network entity; and
add the new user to the voice conference via said bridging connection.
11. The system according to claim 10, wherein to analyze the conference load, the control node is further configured to:
determine whether the first network entity can support the new user;
check whether a further network entity is currently included in the voice conference if the first network entity cannot support the new user;
determine whether the further network entity can support the new user if a further network entity is currently included in the voice conference; and
select the another network entity if the further network entity is not currently included in the voice conference or cannot support the new user.
12. The system according to claim 10, wherein to select another network entity, the control node is further configured to select the least loaded available network entity.
13. The system according to claim 10, wherein to analyze the conference load, the control node is further configured to determine the CPU load.
14. The system according to claim 10, wherein to analyze the conference load, the control node is further configured to determine the number of users connected to the first network entity.
15. The system according to claim 10, wherein to connect the new user to the another network entity, the another node is further configured to authenticate the new user prior to adding the new user to the voice conference.
16. The system according to claim 10, wherein the control node is further configured to:
access a database; and
determine whether a queried network entity has contacted the database within a predetermined time period, wherein, if the queried network entity has not contacted the database within the predetermined time period, the control node ceases to transmit requests to said queried network entity.
17. The system according to claim 10, wherein to create a bridging connection, the another network entity is further configured to determine whether the creation of the bridging connection has failed, and if so, substitute the another network entity for the first network entity.
18. The system according to claim 10, wherein the another network entity is further configured to:
monitor the bridging connection between the another network entity and the first network entity;
determine whether the first network entity has been substituted if the monitoring observes that the connection has failed; and
substitute the another network entity for the first network entity if the first network entity has not been substituted.
19. One or more computer-readable storage memory devices embodying one or more processor-executable instructions which, responsive to execution by at least one processor, perform a method of managing a voice conference in which a plurality of users are connected to a first network entity, the method comprising:
receiving a request to add a new user to a voice conference at a control node;
the control node analyzing a conference load on the first network entity and if the conference load exceeds a threshold, selecting another network entity and transmitting the request to said another network entity;
receiving the request from the control node at the another network entity, and determining whether the another network entity is currently included in the voice conference; and
if the another network entity is not currently included in the voice conference, creating a bridging connection between the another network entity and the first network entity, connecting the new user to the another network entity, and adding the new user to the voice conference via said bridging connection.
20. The one or more computer-readable storage memory devices according to claim 19, wherein the analyzing the conference load further comprises:
determining whether the first network entity can support the new user;
responsive to determining the first network entity cannot support the new user, checking whether a further network entity is currently included in the voice conference;
responsive to determining the further network entity is currently included in the voice conference, determining whether the further network entity can support the new user; and
responsive to determining that the further network entity is not currently included in the voice conference or cannot support the new user, selecting the another network entity.
US14/531,948 2006-05-02 2014-11-03 Group Communication System and Method Abandoned US20150055513A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
GB0608595.5 2006-05-02
GB0608595A GB2437785A (en) 2006-05-02 2006-05-02 Voice over internet protocol (VOIP) group conference communication
US11/799,451 US8886719B2 (en) 2006-05-02 2007-05-01 Group communication system and method
US14/531,948 US20150055513A1 (en) 2006-05-02 2014-11-03 Group Communication System and Method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US14/531,948 US20150055513A1 (en) 2006-05-02 2014-11-03 Group Communication System and Method

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/799,451 Division US8886719B2 (en) 2006-05-02 2007-05-01 Group communication system and method

Publications (1)

Publication Number Publication Date
US20150055513A1 true US20150055513A1 (en) 2015-02-26

Family

ID=36603729

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/799,451 Active 2030-10-25 US8886719B2 (en) 2006-05-02 2007-05-01 Group communication system and method
US14/531,948 Abandoned US20150055513A1 (en) 2006-05-02 2014-11-03 Group Communication System and Method

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/799,451 Active 2030-10-25 US8886719B2 (en) 2006-05-02 2007-05-01 Group communication system and method

Country Status (5)

Country Link
US (2) US8886719B2 (en)
EP (1) EP2014051A2 (en)
CN (1) CN101438559A (en)
GB (1) GB2437785A (en)
WO (1) WO2007132149A2 (en)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2437785A (en) 2006-05-02 2007-11-07 Skype Ltd Voice over internet protocol (VOIP) group conference communication
US8270586B2 (en) * 2007-06-26 2012-09-18 Microsoft Corporation Determining conditions of conferences
JP4479761B2 (en) * 2007-08-07 2010-06-09 セイコーエプソン株式会社 Conference system, connection method
US20090316870A1 (en) * 2008-06-19 2009-12-24 Motorola, Inc. Devices and Methods for Performing N-Way Mute for N-Way Voice Over Internet Protocol (VOIP) Calls
US8005895B2 (en) 2009-02-27 2011-08-23 Microsoft Corporation Distributed routing of conferences using conference identifier
US20100287251A1 (en) * 2009-05-06 2010-11-11 Futurewei Technologies, Inc. System and Method for IMS Based Collaborative Services Enabling Multimedia Application Sharing
US8266314B2 (en) * 2009-12-16 2012-09-11 International Business Machines Corporation Automated audio or video subset network load reduction
US9432372B2 (en) * 2010-01-28 2016-08-30 Adobe Systems Incorporated Access policy based on collaboration participation
WO2012166811A2 (en) 2011-05-31 2012-12-06 Google Inc. Muting participants in a communication session
US9443518B1 (en) 2011-08-31 2016-09-13 Google Inc. Text transcript generation from a communication session
JP5953939B2 (en) * 2012-05-28 2016-07-20 富士通株式会社 End estimation method terminates estimation program, and an information processing apparatus
US8612211B1 (en) * 2012-09-10 2013-12-17 Google Inc. Speech recognition and summarization
KR101467248B1 (en) 2012-10-26 2014-12-02 (주)카카오 Method of operating an application for providing group call service using mobile voice over internet protocol
US20150092615A1 (en) * 2013-10-02 2015-04-02 David Paul Frankel Teleconference system with overlay aufio method associate thereto
US20150109968A1 (en) * 2013-10-21 2015-04-23 Vonage Network Llc Method and system for automating conferencing in a communication session
US9270937B2 (en) * 2013-12-26 2016-02-23 OnCam Inc. Real time stream provisioning infrastructure
US20150200980A1 (en) * 2014-01-13 2015-07-16 Cisco Technology, Inc. Hybrid Client/Server Online Conference Session Management
US9197701B1 (en) * 2014-08-14 2015-11-24 Ringcentral, Inc. Consolidated peer-to-peer media sessions for audio and/or video communications
EP3035674A1 (en) * 2014-12-19 2016-06-22 Unify GmbH & Co. KG Distributed audio control method, device, system, and software product
US20160283912A1 (en) * 2015-03-26 2016-09-29 Microsoft Technology Licensing, Llc Changing Meeting Type Depending on Audience Size
GB2542327A (en) * 2015-05-18 2017-03-22 Nowhere Digital Ltd A method and system for controlling communications for video/audio-conferencing
US10324587B2 (en) * 2015-08-13 2019-06-18 Vyu Labs, Inc. Participant selection and abuse prevention for interactive video sessions
US9697198B2 (en) * 2015-10-05 2017-07-04 International Business Machines Corporation Guiding a conversation based on cognitive analytics
CN105530257A (en) * 2015-12-17 2016-04-27 合肥寰景信息技术有限公司 Voice communication system with channel monitoring and early warning device
CN105515801A (en) * 2015-12-17 2016-04-20 合肥寰景信息技术有限公司 Speech communication method for network community group
CN105553988A (en) * 2015-12-17 2016-05-04 合肥寰景信息技术有限公司 Voice communication method with channel monitoring and early warning device
CN105515954A (en) * 2015-12-22 2016-04-20 合肥寰景信息技术有限公司 Network community group voice communication system
EP3203701A1 (en) * 2016-02-04 2017-08-09 Unify Patente GmbH & Co. KG Method of controlling a real-time conference session, a computer program product causing a computer to execute the method, and a communication system for controlling the real-time conference session
CN107800993A (en) * 2016-09-06 2018-03-13 中兴通讯股份有限公司 Multimedia conference connection method, device and system
CN108737480A (en) * 2017-04-24 2018-11-02 中兴通讯股份有限公司 Conference cascading method based on software media server, server and storage medium

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030167302A1 (en) * 2000-12-29 2003-09-04 Min Zhu Scalable distributed network system for collaborative computing
US20040205219A1 (en) * 2003-02-19 2004-10-14 Wen-Syan Li Virtual active network for live streaming media
US20050108328A1 (en) * 2003-10-30 2005-05-19 Berkeland Mark S. Distributed multipoint conferencing with automatic endpoint address detection and dynamic endpoint-server allocation
US20080207167A1 (en) * 2007-02-28 2008-08-28 Embarq Holdings Company, Llc System and method for remotely managing wireless devices

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08298653A (en) * 1995-04-25 1996-11-12 Canon Inc Video conference system and its terminal equipment
US6175822B1 (en) * 1998-06-05 2001-01-16 Sprint Communications Company, L.P. Method and system for providing network based transcription services
US6304648B1 (en) * 1998-12-21 2001-10-16 Lucent Technologies Inc. Multimedia conference call participant identification system and method
US6807563B1 (en) * 1999-05-21 2004-10-19 Terayon Communications Systems, Inc. Automatic teleconferencing control system
JP3546941B2 (en) * 1999-05-24 2004-07-28 日本電気株式会社 Large-scale multicast data transmission system
AU2785601A (en) * 2000-01-14 2001-07-24 Multitude Inc Apparatus and method for creating moderated forums
KR100752038B1 (en) * 2000-11-28 2007-08-23 주식회사 케이티 A Method of RTP Element Selection for Multimedia Conference in Dynamic Multicast Tree
JP2003032753A (en) 2001-07-19 2003-01-31 Nec Corp System and method of public communication
US6915331B2 (en) * 2002-05-16 2005-07-05 Cisco Managed Solutions, Inc. End user control of a teleconferencing network through a data network
US20040006595A1 (en) * 2002-07-03 2004-01-08 Chiang Yeh Extended features to conferencing system using a web-based management interface
US7266188B2 (en) * 2002-08-08 2007-09-04 International Business Machines Corporation Apparatus and method for securing a conference call via personal user ID and passcode
US7027577B2 (en) * 2002-08-26 2006-04-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for multi-party call conferencing
AU2004301258B2 (en) 2003-07-16 2007-04-26 Skype Peer-to-peer telephone system and method
GB0324289D0 (en) * 2003-10-17 2003-11-19 Ibm Method and system for integration of instant messaging and teleconferencing via a telephone network
US20050278424A1 (en) * 2004-05-26 2005-12-15 Wesley White Network conferencing using method for concurrent real time broadcast and distributed computing and/or distributed objects
US7711384B1 (en) * 2005-06-10 2010-05-04 Nextel Communications Inc. Method and computer-readable medium for in-call status for dispatch group calls
US8392836B1 (en) * 2005-07-11 2013-03-05 Google Inc. Presenting quick list of contacts to communication application user
US20070067387A1 (en) * 2005-09-19 2007-03-22 Cisco Technology, Inc. Conferencing system and method for temporary blocking / restoring of individual participants
US8023932B2 (en) * 2006-02-10 2011-09-20 Microsoft Corporation Managing subscribers on a cellular network
US20070263824A1 (en) * 2006-04-18 2007-11-15 Cisco Technology, Inc. Network resource optimization in a video conference
GB2437785A (en) 2006-05-02 2007-11-07 Skype Ltd Voice over internet protocol (VOIP) group conference communication
US20070260686A1 (en) * 2006-05-04 2007-11-08 Encounter Collaborative Inc. Method and system for conferencing control

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030167302A1 (en) * 2000-12-29 2003-09-04 Min Zhu Scalable distributed network system for collaborative computing
US20040205219A1 (en) * 2003-02-19 2004-10-14 Wen-Syan Li Virtual active network for live streaming media
US20050108328A1 (en) * 2003-10-30 2005-05-19 Berkeland Mark S. Distributed multipoint conferencing with automatic endpoint address detection and dynamic endpoint-server allocation
US20080207167A1 (en) * 2007-02-28 2008-08-28 Embarq Holdings Company, Llc System and method for remotely managing wireless devices

Also Published As

Publication number Publication date
WO2007132149A2 (en) 2007-11-22
EP2014051A2 (en) 2009-01-14
CN101438559A (en) 2009-05-20
WO2007132149A3 (en) 2008-01-24
US8886719B2 (en) 2014-11-11
GB0608595D0 (en) 2006-06-14
WO2007132149B1 (en) 2008-03-13
US20080010347A1 (en) 2008-01-10
GB2437785A (en) 2007-11-07

Similar Documents

Publication Publication Date Title
CN100375078C (en) method and device for voice and text group chat of wireless mobile terminals
US7996463B2 (en) Handling an audio conference related to a text-based message
US6628767B1 (en) Active talker display for web-based control of conference calls
US6434599B1 (en) Method and apparatus for on-line chatting
CN1117450C (en) Multimedia conferencing system using parallel networks
CN102904733B (en) Distributed, scalable, pluggable architecture conference
US9654572B2 (en) Identity management and service access for local user group based on network-resident user profiles
US7376129B2 (en) Enabling collaborative applications using Session Initiation Protocol (SIP) based Voice over Internet protocol Networks (VoIP)
CN101047744B (en) Presence and preference-enabled push to talk telephone system
US9742830B2 (en) Systems and methods for asynchronously joining and leaving video conferences and merging multiple video conferences
US20030055897A1 (en) Specifying monitored user participation in messaging sessions
US7496639B2 (en) Individually specifying message output attributes in a messaging system
US6501740B1 (en) System and method for teleconferencing on an internetwork comprising connection-oriented and connectionless networks
CN100344102C (en) Method and system for sharing presence information
US20060088152A1 (en) Conference-call initiation
CN101273616B (en) Method and apparatus for multiparty collaboration enhancement
CN101867487B (en) System and method for graphically call connection symbol of contact center management
CN1868164B (en) Method and system for integration of instant messaging and PSTN based teleconferencing
US20030021400A1 (en) Audio conferencing system and method
US8028073B2 (en) Mobile meeting and collaboration
KR101521332B1 (en) Method of provicing a lot of services extended from a instant messaging service and the instant messaging service
US20070050448A1 (en) Method and system for information collaboration over an IP network via handheld wireless communication devices
CN101223730B (en) Method for instant scheduling of conference calls
US20050149876A1 (en) System and method for collaborative call management
CN100409208C (en) End user control method and device of a teleconferencing network through a data network

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HOUGHTON, DAN;VARANDA, ANTONIO;LOUREIRO, TIAGO;AND OTHERS;SIGNING DATES FROM 20070801 TO 20070829;REEL/FRAME:034167/0802

AS Assignment

Owner name: SKYPE LIMITED, IRELAND

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE RECEIVING PARTY PREVIOUSLY RECORDED ON REEL 034167 FRAME 0802. ASSIGNOR(S) HEREBY CONFIRMS THE RECEIVING PARTY SHOULD BE SKYPE LIMITED;ASSIGNORS:HOUGHTON, DAN;VARANDA, ANTONIO;LOUREIRO, TIAGO;AND OTHERS;SIGNING DATES FROM 20070801 TO 20070829;REEL/FRAME:041731/0123

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION