US20040085914A1 - Large-scale, fault-tolerant audio conferencing in a purely packet-switched network - Google Patents

Abstract

A method of large-scale fault-tolerant audio conferencing in an audio conferencing system using a purely packet-switched network. An endpoint places a call to a conference gatekeeper indicating an audio conference. The conference gatekeeper determines whether the call contains sufficient information to establish the audio conference. If there is insufficient information, the endpoint is connected to an IVR server that obtains sufficient information from the endpoint. Either way, a CACS selects an MCU hosting or that will host the audio conference. The CACS then responds to the endpoint with routing instructions indicating the selected MCU and the endpoint connects or transfers to the selected MCU. The MCU mixes input from all endpoints in the audio conference to form a voice stream, which is then returned to each endpoint in the audio conference. Audio conference participants can dial-out from the MCU to bring additional participants into the audio conference. Once established, the audio conference supports full service audio conferencing. In addition, dynamic routing permits an operator to service multiple MCUs, and an audio conference participant and/or an entire audio conference to be moved between MCUs. The audio conference can also be broadcast from a streaming protocol server to passive participants.

Description

BACKGROUND OF THE INVENTION
• 1. Related Application[0001]
• This application is related to co-owned U.S. Patent Application entitled LARGE-SCALE, FAULT-TOLERANT AUDIO CONFERENCING OVER A HYBRID NETWORK, filed on the same date as this application.[0002]
• 2. Field of the Invention[0003]
• The present invention relates generally to the field of packet-switched network audio conferencing. More specifically, the present invention discloses a method for large-scale, fault-tolerant audio conferencing in a purely packet-switched network.[0004]
• 3. Statement of the Problem[0005]
• The most common method to route calls for an audio conference is to control a local switch in a GSTN (globally switched telephony network). That is, a physical point-to-point connection is made between each piece of equipment in the network to create an overall point-to-point audio connection for the call. However, such a switch-controlled application can only route calls to devices connected to the switch, limiting the overall size of the system and limiting the geographic distribution of multipoint control units (MCUs) within the system. In addition, call transfer (e.g., from one MCU to another) requires that the connection from the switch to the new endpoint be established and the path to the transferring endpoint be torn down, thus limiting its use in a large-scale audio conferencing system.[0006]
• Another conventional method to route calls for an audio conference is to interface with the network signaling layer (SS7/C7) directly.[0007]
• Packet-switched call routing, on the other hand, facilitates dynamic call routing and call transfer during a call. That is, no dedicated point-to-point connection is required in a packet-switched network. Each packet, including the call data and associated control, is sent individually to a destination address and the physical route taken from one endpoint to another can vary from packet to packet, eliminating the need for a dedicated circuit for each call. Thus, a call can be routed or even transferred within the packet-switched network simply by renegotiating the end point address. A need exists to provide audio conferencing using packet-switched call routing.[0008]
• There is a need for audio conferencing implemented on a purely packet-switched network that provides both scalability and fault tolerance. Specifically, a need exists to monitor a pool of MCUs to determine which MCU can best handle the conference, and to dynamically route calls within the purely packet-switched network so that a conference participant in one conference call can be transferred to another conference call and further, entire conferences can be transferred to other MCUs in the MCU pool without interrupting the audio conference (i.e., without tearing down connections and reestablishing the connections within the packet-based network). A need also exists for audio conferencing for both receive-only or passive broadcast participants. Specifically, a need exists to provide a voice stream to the endpoints connected to the conference but that do not actively participate in the conference itself (i.e., do not contribute to the conference voice stream). Yet another need exists for full service audio conferencing using both high-touch (operator assisted) or reservation based audio conferencing and automated or “ad hoc” audio conferencing using the same platform. Specifically, a need exists to provide conferencing on a reservation basis and on an impromptu basis by monitoring a pool of MCUs to efficiently establish conferences in the packet-based network.[0009]
SUMMARY OF THE INVENTION
• 1. Solution to the Problem. None of the prior art references discussed above disclose large-scale, fault-tolerant audio conferencing implemented in a purely packet-switched network.[0010]
• This invention provides an audio conferencing method implemented on a purely packet-switched network that provides scalability and fault tolerance.[0011]
• A primary object of the present invention is to provide large-scale, fault tolerant audio conferencing using dynamically routed, call transfer in a purely packet-switched network. That is, the present invention monitors a pool of MCUs so that conferences can be efficiently established and routed to different MCUs when an MCU approaches capacity or when an MCU has to be taken out of service. As the audio conferencing method is implemented in a purely packet-switched network, the destination of each audio packet can be rerouted seamlessly without interrupting the audio conference.[0012]
• Another object of the present invention is to provide an audio conferencing method for receive-only or passive participants. That is, participants that do not actively contribute to the conference can be accommodated (i.e., receive the conference output or voice stream).[0013]
• Yet another object of the present invention is to provide full service audio conferencing using both high-touch or reservation-based audio conferencing and automated or “ad hoc” audio conferencing on the same platform. That is, a conference need not be reserved against a dedicated MCU and instead, the method of the present invention allows a pool of MCUs to be monitored, thus allowing for both advance conference reservations and ad-hoc conferences.[0014]
• 2. Summary. The present invention discloses a method of large-scale fault-tolerant audio conferencing in an audio conferencing system using a purely packet-switched network. According to the method of the present invention, an endpoint places a call to a conference gatekeeper indicating an audio conference (i.e., containing a location-request or LRQ signal). The conference gatekeeper determines whether the call contains sufficient information to establish the audio conference. If there is insufficient information, the endpoint is connected to an interactive voice response (IVR) server that obtains sufficient information (i.e., an account number) from the endpoint. Either way, a conference allocation and control system (CACS) linked to the conference gatekeeper selects an available multipoint control unit (MCU) to either host the audio conference if the audio conference has not been established yet, or the MCU that is already hosting the audio conference. The CACS then responds to the endpoint with routing instructions (i.e., a location-found or LCF signal) indicating the selected MCU. The endpoint then uses the routing instructions to connect to the selected MCU, or where the endpoint was initially connected to the IVR server to gather additional information, the endpoint is transferred from the IVR server to the selected MCU. Once connected, the MCU mixes input from all of the endpoints in the audio conference and forms a voice stream, which the MCU then returns to each endpoint in the audio conference.[0015]
• Once an audio conference is established according to the method of the present invention, the audio conference participants (i.e., endpoints connected to the MCU in the audio conference) can dial-out from the MCU to bring additional participants (i.e., another endpoint) into the audio conference. In addition, the established audio conference supports full service audio conferencing (i.e., both reservation-based, and ad hoc). Furthermore, the established audio conference supports dynamic routing which permits an operator to service multiple MCUs, for the MCUs to be geographically dispersed, and for an audio conference participant and/or an entire audio conference to be moved between MCUs.. The audio conference can also be broadcast from a streaming protocol server to passive participants. As such, the audio conference established according to the method of the present invention using a purely packet-switched network can be both large scale, and is fault-tolerant.[0016]
• These and other advantages, features, and objects of the present invention will be more readily understood in view of the following detailed description and the drawings.[0017]
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a high-level diagram of a packet-switched network for use with the method of the present invention.[0018]
• FIG. 2 is a flow chart illustrating an audio conferencing method of the present invention.[0019]
• FIG. 3 shows an example of the audio conferencing method of FIG. 2 in which an IVR server is not used.[0020]
• FIG. 4 shows an example of the audio conferencing method of FIG. 2 in which an IVR server is used.[0021]
• FIG. 5 is a flow chart illustrating a dial-out method of the present invention.[0022]
• FIG. 6 shows an example of the dial-out method of FIG. 5.[0023]
DETAILED DESCRIPTION OF THE INVENTION
• 1. Overview. FIG. 1 shows a high-level diagram of a purely packet-switched[0024]audio conferencing system100 using a packet network110 (e.g., Internet Protocol or IP, ATM, Frame Relay or any other packet-switched protocol) in which the method of the present invention can be implemented. The hardware is conventionally linked through packetized signals, as shown in FIG. 1. For purposes of illustration, control or routing signals are shown by dashed lines and audio (or voice stream) signals are shown by solid lines. An endpoint120 (E1, E2, . . . Ei) accesses112 theconventional packet network110 via agateway130 and is conventionally linked therein through a series of routers/hubs115 to a conference gatekeeper150 (e.g., via118).
• Optionally, each[0025]endpoint120 is also registered with agatekeeper140 through which routing signals are sent and received such as over links147. Registration is conventionally used under the H.323 protocol, however, registration is not required for the audio conferencing method of the present invention. Theendpoint120 can be connected to thesame gatekeeper140 or different gatekeepers within agatekeeper cloud145 having one ormore gatekeepers140. Thegatekeeper140 is then linked142 to theconference gatekeeper150. Theconference gatekeeper150 controls anMCU pool165 having one or more conferencing MCUs160 (MCU1,MCU2, . . . MCU n). Theconference gatekeeper150 is also linked156 to a conference allocation and control system (CACS)170. Optionally, theconference gatekeeper150 is also linked158 to a conventionally available interactive voice response (IVR)server180 that is capable of gathering additional routing information from theendpoint120 vialinks182,112
• In one embodiment, the[0026]conference system100 of the present invention also includes a conventional streaming protocol server185 (e.g., a real-time standard broadcast server or RTSP) linked152 to theCACS170 and thepacket network110, areservation system155 linked157 to theCACS170, and acall agent175 linked177 to the conference gatekeeper. Thestreaming protocol server185 is conventionally available and uses the conference sum (i.e., the mixed voice stream from allendpoints120 actively participating in the audio conference) as input for a broadcast signal to passive participants (i.e.,endpoints120 not actively participating in the audio conference). Thereservation system155 is also conventionally available and used to reserve planned audio conferences against an available MCU160 (i.e., an MCU having available ports190). Likewise, thecall agent175 is conventionally available and managesavailable ports190 in theMCU pool165 and assigns calls on an “ad hoc” basis toavailable MCUs160.
• The[0027]endpoint120 is a conventionally available client terminal that provides real-time, two-way communications using packetized audio signals. Packetized audio signals contain digitized and compressed speech or touch tones. Any protocol can be used under the teachings of the present invention and the specific protocol will be based on design considerations. That is, different ITU recommendations for digitizing and compressing signals reflect different tradeoffs between speech quality, bit rate, computer power, and signal delay (e.g., G.711, G.723, etc.). It is to be expressly understood that theendpoint120 can be either packet-based or circuit-switched, as thegateway130 hides the physical transport to theendpoint120.
• The[0028]gateway130 is optional under the teachings of the present invention, and when used can be a part of thepacket network110 itself. The purpose of thegateway130 is to provide, among other things, a translation function between conventional transmission formats (e.g., H.323, H.225.0, H.221, etc.). It is to be expressly understood that thegateway130 can supportendpoints120 that comply with other protocols and thegateway130 need only be equipped with the appropriate transcoders. However, thegateway130 is not required where connections to other networks are not needed, and theendpoint120 then communicates directly with anotherendpoint120 on the same network and a single translation function is used.
• Gatekeepers[0029]140 (and hence the gatekeeper cloud145) are also optional. Where thegatekeepers140 are used under the teachings of the present invention, the purpose ofgatekeepers140 is to perform two call control functions. Specifically, thegatekeeper140 performs address translation and manages bandwidth. Address translation is done conventionally (e.g., domain name to IP address or touch tones to IP address) within thepacket network110 itself. Bandwidth is also conventionally managed within thepacket network110 itself (e.g., as IP trunks reach capacity, the network moves audio, data, etc. signals to other lower volume IP trunks). When thegatekeeper140 is not used, endpoints are connected through the gateway130 (i.e., for H.323) or directly through thepacket network110.
• The[0030]conference gatekeeper150 in conjunction with theCACS170 controls the creation and execution of audio conferences. TheCACS170 determines an available MCU160 (i.e., having sufficient available ports190) to host the audio conference and provides routing instructions to theconference gatekeeper150 to direct the call from theendpoint120 to theappropriate MCU160. For instance, if a network administrator has specified a threshold (i.e., in the CACS) for the number of simultaneous audio conferences (i.e., number of active conferences, number of available ports, etc.), theCACS170 can refuse to make any more connections once the specified threshold is reached. In addition, theCACS170 also provides information concerning the audio conference parameters to theMCU160 and collects billing information.
• The[0031]MCU160 supports audio conferences between three ormore endpoints120. TheMCU160 is conventionally available and consists of a multipoint controller (not shown) and optionally one or more multipoint processors (not shown). For purposes of illustration, and not intended to limit the scope of the present invention, fourports190,195 are shown on eachMCU160, although atypical MCU160 can handle approximately 1,500 active conference participants.Available ports190 are shown “open” whileunavailable ports195 are shown “closed”. TheMCU160 handles negotiations between allendpoints120 to determine common capabilities for audio processing. TheMCU160 also controls audio conference resources by determining which, if any of the audio streams will be multicast.
• With respect to the[0032]audio conferencing system100 shown in FIG. 1, an audio conference is initiated when a call identifying a particular audio conference is placed by anendpoint120, as explained in more detail below. Routing signals are transmitted112 or147 either through the packet network110 (i.e., if thegatekeeper140 is not used) or through thegatekeeper140, respectively, to theconference gatekeeper150. AnMCU160 is selected by theconference gatekeeper150 and theCACS170 and the audio conference is established by connecting theendpoint120 through thepacket network110 overlinks112,114 to theMCU160.Additional endpoints120 can place a call identifying the audio conference and are similarly connected vialinks112,114 to the identified audio conference overlink112 through thepacket network110 to theMCU160 by theconference gatekeeper150 and theCACS170, as described in more detail below.
• It is to be expressly understood that each of the hardware components of the purely packet-switched[0033]conferencing system100 described above are conventionally available, and it is the arrangement and/or configuration of each component in the manner described above, and the method of using each component in this configuration as explained below that is new. Likewise, communication using packetized signals and various protocols is conventionally known. It is the combination of each of the above-identified hardware components to form theconferencing system100 for use with the method of the present invention that is new. It is also to be expressly understood that alternative hardware configurations are possible under the teachings of the present invention and that the method of the present invention is not to be limited by the configuration shown in FIG. 1 nor by any particular network protocol.
• 2. Establishing a Conference. An embodiment of the audio conferencing method of the present invention is illustrated in FIG. 2 and explained with reference to FIG. 1. At[0034]step200, anendpoint120 initiates a call to theaudio conferencing system100, for example, by entering a destination, account number, URL, or IP address. Optionally the call is routed147 through thegateway130 to an address serviced by thegatekeeper140 in thegatekeeper cloud145. If thegatekeeper140 is not used, the call is then routed112 directly to thepacket network110. Either way, the call is routed to theconference gatekeeper150 instep210. The initiating call contains conventional packetized control signals for routing the call including any audio conference identification information required to initiate the audio conference (i.e., a conventional location request or LRQ). For example, see co-owned U.S. patent application Ser. No. 09/366,355 and Ser. No. 08/825,477 (hereinafter, the on-demand teleconferencing methods), incorporated herein by reference. The LRQ is received via147,142 (or112,118 when thegatekeeper140 is not used) by theconference gatekeeper150 which in turn queries156 theCACS170 for audio conference routing instructions instep220. TheCACS170 determines whether the call (i.e., the LRQ) contains sufficient information to set up and route the audio conference instep230. If the call contains sufficient information232 (i.e., enough information to uniquely identify a subscriber, such as a subscriber identification, pass code, etc.), theCACS170 determines whether the indicated audio conference is active (i.e., whetherother endpoints120 are currently connected to the indicated audio conference) instep240. That is, theCACS170 starts all conferences with theMCU160 and thus stores all activity in memory. If aCACS170 is disconnected from anMCU160, a conventional process is used to resync theCACS170 and theMCU160, and thus theCACS170 is continuously updated with respect to activity in theMCU pool165. If theCACS170 determines that the indicated audio conference is not active242, theCACS170 selects anavailable MCU160 from theMCU pool165 to host the audio conference instep245. Instep260, theCACS170 then returns (e.g., via156) routing information to theconference gatekeeper150 and theconference gatekeeper150 responds142,147 (or118,112 whengatekeeper cloud145 is not used) to theendpoint120 with a conventional location found signal (LCF) indicating the selectedMCU160 to host the audio conference. Theendpoint120 then establishes112,114 a point-to-point call via thepacket network110 with the selectedMCU160 instep270, and an audio conference is established with one participant (i.e., the initiating endpoint). Instep280, theMCU160 mixes the input from allendpoints120 participating in the audio conference, and theMCU160 returns (e.g., via114,112) a voice stream to theendpoint120 instep290. The term “voice stream” as used herein, means the mixed sum of input from all actively participating endpoints in the conference. Further, the voice stream returned to an actively participating endpoint does not include input from thesame endpoint120.
• [0035]Additional endpoints120 can join an active audio conference in a manner similar to that outlined above. That is, anadditional endpoint120 initiates over link147 (or112 whengatekeeper cloud145 is not used) a call to an address identifying the audio conference instep200. A conventional LRQ is sent147,142 (or112,118 when thegatekeeper cloud145 is not used) to theconference gatekeeper150 as discussed above. Theconference gatekeeper150queries156 theCACS170 for routing instructions instep220. If there is sufficient information to set up and route the audio conference instep230, theCACS170 proceeds to determine whether the audio conference is active instep240, selects theactive MCU160 instep250 if the audio conference is active247, and responds156 with appropriate routing instructions to theconference gatekeeper150 instep260. Theconference gatekeeper150 responds142,147 (or118,112 where thegatekeeper140 is not used) to theendpoint120 with a conventional LCF signal indicating the selectedMCU160 hosting the active audio conference and theendpoint120 establishes a point-to-point call vialinks112,114 with the selectedMCU160 instep270, as discussed above. TheMCU160 mixes the input from eachendpoint120 participating in the audio conference instep280 and returns an appropriate voice stream overlinks114,112 to eachendpoint120 instep290. Additional endpoints can continue to join the audio conference in a similar manner to that just described.
• An example of the audio conferencing method of the present invention in which there is sufficient information associated with the call (i.e., an[0036]IVR server180 is not required to gather additional information such as an account number) is shown in FIG. 3. A new call identifying the audio conference (e.g., containing a URL, conference access number, etc.) is placed300 from the endpoint120 (e.g., E1, in this example and H.323 compliant endpoint) via link147 to agatekeeper140 in the gatekeeper cloud145 (step200). An LRQ is transmitted310 from thegatekeeper cloud145 to theconference gatekeeper150 via142 (step210), which in turn requests320 routing instructions (i.e., the details for the LCF) from theCACS170 via156 (step220). TheCACS170 selects anavailable MCU160 from the MCU pool165 (steps230,240,245) and returns325 routing instructions to theconference gatekeeper150 vialink156, which in turn forwards330 an LCF signal through thegatekeeper cloud145 and back335 to the endpoint120 (E1) vialinks142,147 (steps270,280, and290). The endpoint120 (E1) uses the LCF to setup340,345 a point-to-point connection with theMCU160 identified by the LCF signal and establish347 the requested audio conference (i.e., an audio conference having only the initiating endpoint E1) vialinks112,114. For example, see the on-demand teleconferencing methods, incorporated herein by reference. Additional endpoints120 (i.e., E2) join the establishedaudio conference347 as follows. A new call identifying the establishedaudio conference347 is placed350 to thegatekeeper cloud150 via link147 (step200). An LRQ is transmitted360 from thegatekeeper cloud145 to theconference gatekeeper150 via link142 (step210), which in turn requests370 routing instructions to the established audio conference from theCACS170 via link156 (step220). TheCACS170 selects theactive MCU160 identified as hosting the requested audio conference (steps230,240, and250) and returns375 routing instructions identifying theMCU160 hosting theaudio conference347 to theconference gatekeeper150 vialink156, which in turn forwards380,385 an LCF signal through thegatekeeper cloud145 to the endpoint120 (E2) vialinks142,147 (step260). The endpoint120 (E2) uses the routing information from the LCF to establish aconnection390,395 to the appropriate MCU160 (via112,114), and anactive audio conference397 is established (i.e., between E1 and E2) (steps270,280, and290). Additional endpoints120 (E3, E4, . . . Ei) can participate in theactive audio conference397 by accessing theappropriate MCU160 as just described with respect to the endpoint120 (E2) or through a dial out request, as described below. It is to be expressly understood that the above example is presented to be illustrative of the audio conferencing method of the present invention, and in no way should be interpreted to limit the scope of the present invention.
• In another embodiment, also shown in FIG. 2, where the call does not contain sufficient information[0037]237 (i.e., additional information such as an account number is required), theendpoint120 must first connect (vialinks112,182) to anIVR server180 capable of gathering the required information in step235 (e.g., by querying theendpoint120 for an account number). Routing proceeds as described above with respect tosteps240 through260 and instep270, theendpoint120 is then transferred from theIVR server180 to theMCU160 selected instep245 or250 before mixing the input and returning a voice stream insteps280 and290, respectively. Thus, there is no requirement to collocate the device gathering the information and theMCU160 which will be the final destination.
• An example of the audio conferencing method of the present invention in which an[0038]IVR server180 is used is shown in FIG. 4.Steps300,310 and320 in FIG. 4 correspond to those shown in FIG. 3. However, in FIG. 4, the CACS determines that the routing request contains insufficient information to establish an audio conference. Hence, a signal is returned325,330, and335 vialinks118,112 to the endpoint120 (E1) to route the endpoint120 (E1) to anIVR server180. The endpoint120 (E1) establishes a connection with the IVR server180 (400 and405), and theIVR server180 gathers410 additional information (e.g., an account number) from the endpoint120 (E1) to establish an audio conference (step235). Once theIVR server180 has gathered this information, theIVR server180 sends420 a routing request to theCACS170 vialinks158,156, which in turn returns425 routing information to the IVR server180 (steps240,245, and260). Based on the routing information, the call is then transferred430 from theIVR server180 and a point-to-point connection is established340,345 between the endpoint120 (E1) and theMCU160 and anaudio conference347 is established vialinks112,114 (steps270,280, and290). Additional endpoints120 (e.g., E2) join the audio conference again by placing350 a call through360 thegatekeeper cloud145 to the conference gatekeeper150 (step200). Again, theconference gatekeeper150requests370 routing information from theCACS170 and is provided375 with routing information to an IVR server for obtaining additional information from the endpoint120 (E2) (steps210,220,230,237). The LCF is transmitted380,385 to the endpoint120 (E2) and a call is established440,445 between the endpoint120 (E2) and theIVR server180. TheIVR server180 gathers450 the additional information (i.e., an account number, access code, etc.) from the endpoint120 (E2) and transmits460 a routing request to the CACS170 (step235). TheCACS170 responds465 with routing information identifying theMCU160 hosting the audio conference, and the call is then transferred from theIVR server180 to the identifiedMCU160, a point-to-point connection470 is established between the endpoint120 (E2) (steps240 to290 discussed above). It is to be expressly understood that the above example is presented to be illustrative of the audio conferencing method of the present invention, and in no way should be interpreted to limit the scope of the present invention.
• Communication with the[0039]gateway130 and thegatekeeper140, and address resolution is conventional. Furthermore, it is to be expressly understood that the use of thegateway130 and thegatekeeper140 is optional and need not be used under the teachings of the present invention. In an embodiment where thegateway130 and thegatekeeper140 are not used, the call is routed directly through the packet network110 (e.g., between routers/hubs115).3. Dial-out Method. An embodiment of the dial-out method of the present invention is illustrated in FIG. 5. The dial-out method is used to connect to anendpoint120 not currently connected to an active audio conference. For example, the dial-out method can be used when an active audio conference exists500 between conference participants (e.g., E1, E2, and E3) and the conference participants wish to bring in an additional participant (e.g., E4).
• In[0040]step510, a conference participant conventionally initiates the dial-out from an originating endpoint120 (e.g., E1, via touch tone or a web interface) and theCACS170 requests a dial-out from theMCU160 and supplies theMCU160 with the address of theendpoint120 to connect to (e.g., E4). TheMCU160 initiates (via154) a new call request to theconference gatekeeper150 instep520. Instep530, the gatekeeper140 (orpacket network110 whencloud145 is not used) receives an LRQ from theconference gatekeeper150 and instep540 the gatekeeper140 (or packet network110) returns the destination address (i.e., via an LCF message) which is forwarded154 to theMCU160 from theconference gatekeeper150. TheMCU160 then establishes a point-to-point call to the endpoint120 (E4) and mixes the input to form a voice stream for all conference participants (E1-E4) instep550, similar to that described above with respect to the audio conferencing method. Thus, the additional participant (E4) is brought into the active audio conference. If the additional participant (E4) does not answer the dial-out request, the line is disconnected by the originating endpoint120 (E1) and the originating endpoint120 (E1) is placed back in the audio conference.
• An example of the dial-out method of the present invention is shown in FIG. 6. In this example, an[0041]active audio conference397 has already been established (e.g., according to the method of establishing an audio conference discussed above), and the existing participants (e.g., E1-E3) wish to bring in an additional endpoint120 (E4) to participate in the active audio conference397 (step500). An initiating endpoint (i.e., E1) places a call identifying the additional endpoint (E4) and theCACS170 requests600 a dial-out from the MCU160 (step510). TheMCU160 transmits610 the new call to theconference gatekeeper150 via link154 (step520), which in turn requests620 the location of the desired endpoint120 (E4) from the gatekeeper cloud (via142). Thegatekeeper cloud145 responds630 via link142 (step530) to theconference gatekeeper150 with an LCF signal which is in turn transmitted635 to theMCU160 via link154 (step540). TheMCU160 then uses the information from the LCF to establish640,645 a point-to-point call between theMCU160 and the endpoint120 (E4) vialinks114,112. Hence, the endpoint120 (E4) is brought into theactive audio conference650 as an additional participant (step550). It is to be expressly understood that the above example is presented to be illustrative of the audio conferencing method of the present invention, and in no way should be interpreted to limit the scope of the present invention.
• 4. Full Service Audio Conferencing. Planned audio conferencing conventionally requires an advance reservation against a[0042]specific MCU160 orMCU pool165 and operator assistance (i.e., high-touch) to facilitate the audio conference. Ad-hoc audio conferencing conventionally is able to support an audio conference without a reservation and without operator assistance by creating a conference against asingle MCU160. On the other hand, once an audio conference is established according to the method of the present invention, theaudio conferencing system100 offers full service audio conferencing that supports both planned and ad-hoc audio conferencing.
• The method of the present invention implements full service audio conferencing by integrating the[0043]reservation system155 of the planned audio conferencing system and thecall agent175 of the ad-hoc system.Ports190,195 utilized for each audio conferencing type can be dynamically driven by current loads to achieve maximum port utilization.
• In one embodiment, the[0044]reservation system155 and thecall agent175 are loosely integrated. That is, themaster reservation system155 conventionally used to reserve planned audio conferences onspecific MCUs160 inpool165 keeps the ad-hoc call agent175 informed as to the number ofavailable ports190 on eachMCU160 and the ad hoccall agent175 conventionally manages theavailable ports190. The number ofavailable ports190 on a givenMCU160 are conventionally monitored to ensure that all reservations can be serviced. For example, anavailable port190 that will be required to support a reservation in the next five minutes is not considered available (i.e.,195). Likewise, statistically expected ad-hoc usage is also monitored and accounted for.
• In another embodiment, the[0045]reservation system155 and thecall agent175 are tightly integrated. That is, thereservation system155 is used to reserve planned audio conferences againstMCU pool165 but the reservation is not bound to aspecific MCU160. Instead, the audio conference is assigned to anMCU160 by thecall agent175 when it is created and thecall agent175 continuously monitors theport190,195 usage and anticipated near term usage (i.e., reserved ports) of eachMCU160 in thepool165 to determine the number and location ofavailable ports190. When an audio conference needs to be created (either a planned audio conference or an ad-hoc audio conference), thecall agent175 selects anappropriate MCU160 to host the audio conference and ensures that all calls for a given audio conference are routed to theappropriate MCU160. Thus, thecall agent175 determines the location of all audio conferences allowing forgreater port190,195 utilization as well as better fault tolerance (i.e., audio conference requests will seldom be denied becauseavailable ports190 are closely monitored).
• 5. Network Centric Call Transfer and Dynamic Call Routing. Once an audio conference is established according to the method of the present invention, the packet-switched[0046]audio conference system100 also facilitates dynamic call routing. A point-to-point connection is made using logical links (i.e., within the packet network110) and a dedicated physical connection is not required (i.e., as in a GSTN). That is, the call data and associated control are sent via packets through thepacket network110 and each packet is sent individually to a destination address so that the physical route taken from end-to-end may vary from packet to packet (i.e., a call can be routed or transferred by simply renegotiating the destination address).
• Thus, under the teachings of the present invention, calls can be routed to any[0047]MCU160 within theMCU pool165 allowingMCUs160 to be geographically distributed and theaudio conference network100 to be large-scale. In addition, the ability to transfer a call from oneMCU160 to another allows the operator voice path to be routed to anyMCU160 in theconference system100. This in turn allows an operator to service a large number ofMCUs160 and to quickly switch whichMCU160 their voice path terminates on.
• In addition, an audio conference established according to the method of the present invention allows an audio conference participant to be moved from one audio conference to another, even where the audio conferences are on[0048]separate MCUs160. The destination address of the packets are simply renegotiated to anotherMCU160 instead of establishing a connection between the twoMCUs160.
• An audio conference established according to the method of the present invention also allows a new audio conference to be created on a[0049]different MCU160 where anMCU160 is taken out of service or otherwise unavailable to take additional participants (e.g., due to overflow, etc.). By transferring calls, the audio conference can be serviced by anyMCU160 in thesystem100. All calls destined for a “moved” audio conference are still statically routed to theoriginal MCU160, but immediately transferred to thecorrect MCU160, thus service to the audio conference is not interrupted.
• 6. Receive Only Support. Audio conference participants can be either active or passive. Participants that can both contribute to and receive audio input from an audio conference are active participants. Those that can only receive a voice stream from an audio conference are passive participants. Once an audio conference is established according to the method of the present invention, the audio conference supports both active and passive participants.[0050]
• Support for passive participants can still be provided where there are only a limited number of participants by the[0051]MCU160 the same as it is in a conventional circuit-switched network. That is, a full duplex connection can be established and the receive path simply ignored. However, the method of the present invention can also use broadcasting to support passive participants. That is, the audio conference output is directed to a streaming protocol server185 (e.g., a real-time standard broadcast server RTSP). Thestreaming protocol server185 uses the audio conference sum as its input, and passive participants can connect to thestreaming protocol server185 using conventional standards of service. As such, a large number of broadcast protocols can be supported, and a virtually unlimited number of passive participants can be supported with little or no impact on theconferencing MCU160.
• The foregoing discussion of the invention has been presented for purposes of illustration and description. Further, the description is not intended to limit the invention to the form disclosed herein. Consequently, variation and modification commensurate with the above teachings, within the skill and knowledge of the relevant art, are within the scope of the present invention. The embodiment described herein and above is further intended to explain the best mode presently known of practicing the invention and to enable others skilled in the art to utilize the invention as such, or in other embodiments, and with the various modifications required by their particular application or uses of the invention. It is intended that the appended claims be construed to include alternate embodiments to the extent permitted by the prior art.[0052]

Claims (31)

We claim:

1. A method of large-scale fault-tolerant audio conferencing in a purely packet-switched audio conferencing system, said method comprising the steps of:

placing a call from an endpoint to a conference gatekeeper, said call indicating an audio conference;

querying a CACS from said conference gatekeeper for routing instructions for said audio conference;

determining in said CACS whether said audio conference is active;

selecting in said CACS an MCU to host said audio conference when said audio conference is inactive;

selecting in said CACS an MCU hosting said audio conference when said audio conference is active;

responding from said CACS to said endpoint with said queried routing instructions, said queried routing instructions indicating said selected MCU;

connecting said endpoint to said selected MCU;

mixing input from all endpoints in said audio conference to form a voice stream; and

returning said voice stream to each endpoint in said audio conference.

2. The method ofclaim 1 wherein the step of placing a call links said endpoint to said conference gatekeeper through a gatekeeper cloud.

3. The method ofclaim 1 wherein the step of placing a call links said endpoint to said conference gatekeeper through said packet-switched network.

4. The method ofclaim 1 wherein the routing instructions include at least an LCF signal indicating the selected MCU.

5. The method ofclaim 1 wherein the call includes at least an LRQ signal.

6. The method ofclaim 1 further comprising the steps of:

determining in said CACS whether the call from said endpoint contains adequate information to establish said audio conference;

responding from said CACS to said endpoint with routing instructions to an IVR server when there is inadequate information to establish said audio conference;

connecting said endpoint to said IVR server when there is inadequate information to route said call;

gathering in said IVR server, after connecting said endpoint to said IVR server, adequate information to establish said audio conference; and

transferring said endpoint from said IVR server to said selected MCU after said IVR server gathers said adequate information.

7. The method ofclaim 1 further having a dial-out method comprising the steps of:

initiating a call request from said selected MCU to said conference gatekeeper, said call request indicating an additional endpoint;

transmitting an LRQ from the conference gatekeeper to the gatekeeper cloud;

returning a destination address to said conference gatekeeper from said gatekeeper cloud, said destination address corresponding to said additional endpoint;

forwarding said destination address from said conference gatekeeper to said selected MCU;

establishing a point-to-point call from said MCU to said additional endpoint based on said destination address, thereby bringing said additional endpoint into said audio conference.

8. The method ofclaim 1 further supporting full service audio conferencing using a reservation system and a call agent.

9. The method ofclaim 8 wherein the reservation system and the call agent are tightly integrated.

10. The method ofclaim 8 wherein the reservation system and the call agent are loosely integrated.

11. The method ofclaim 1 wherein said selected MCU is selected from an MCU pool.

12. The method ofclaim 1 further including the step of dynamically routing an operator voice path to service multiple MCUs.

13. The method ofclaim 1 further including the step of renegotiating the destination of a voice path to move an audio conference participant from said selected MCU to a second MCU.

14. The method ofclaim 1 further including the step of moving said audio conference from said selected MCU to a second MCU.

15. The method ofclaim 1 further including the steps of:

providing said audio conference to a streaming protocol server from said selected MCU;

connecting a passive participant to said streaming protocol server; and

broadcasting said audio conference from said streaming protocol server to a passive participant.

16. A large-scale fault-tolerant purely packet-switched audio conferencing method, said method comprising the steps of:

establishing an audio conference by:

connecting an endpoint to a conference gatekeeper, said endpoint indicating an audio conference;

querying a CACS from said conference gatekeeper for routing instructions for said audio conference;

determining in said CACS the status of said audio conference;

selecting in said CACS an MCU to host said audio conference when said status of said audio conference is inactive;

selecting in said CACS an MCU hosting said audio conference when said status of said audio conference is active;

responding from said CACS to said endpoint with said queried routing instructions, said queried routing instructions indicating said selected MCU;

connecting said endpoint to said audio conference through said selected MCU;

mixing input from all endpoints in said audio conference to form a voice stream;

returning said voice stream to each endpoint in said audio conference; and

dialing out from the audio conference when said status of said audio conference is active to connect additional endpoints to the audio conference by:

initiating in the endpoint connected to said audio conference a call request from said selected MCU to said conference gatekeeper, said call request indicating said additional endpoint;

transmitting an LRQ from the conference gatekeeper to the gatekeeper cloud;

returning a destination address to said conference gatekeeper from said gatekeeper cloud, said destination address corresponding to said additional endpoint;

forwarding said destination address from said conference gatekeeper to said selected MCU;

establishing a point-to-point call from said MCU to said additional endpoint based on said destination address, thereby bringing said additional endpoint into said audio conference.

17. The method ofclaim 16 further comprising the steps of:

determining in said CACS whether the call from said endpoint contains adequate information to establish said audio conference;

responding from said CACS to said endpoint with routing instructions to an IVR server when there is inadequate information to establish said audio conference;

connecting said endpoint to said IVR server when there is inadequate information to route said call;

gathering in said IVR server, after connecting said endpoint to said IVR server, adequate information to establish said audio conference; and

transferring said endpoint from said IVR server to said selected MCU after said IVR server gathers said adequate information.

18. The method ofclaim 16 further supporting full service audio conferencing using a reservation system and a call agent.

19. The method ofclaim 16 wherein said selected MCU is selected from an MCU pool.

20. The method ofclaim 16 further including the step of dynamically routing an operator voice path to service multiple MCUs.

21. The method ofclaim 16 further including the step of renegotiating the destination of a voice path to move an audio conference participant from said selected MCU to a second MCU.

22. The method ofclaim 16 further including the step of moving said audio conference from said selected MCU to a second MCU.

23. The method ofclaim 16 further including the steps of:

providing said audio conference to a streaming protocol server from said selected MCU;

connecting a passive participant to said streaming protocol server; and

broadcasting said audio conference from said streaming protocol server to a passive participant.

24. A large-scale fault-tolerant audio conferencing method over a purely packet-switched network, said method comprising the steps of:

initiating a call from an endpoint to a conference gatekeeper;

querying a CACS from said conference gatekeeper for routing instructions for an audio conference;

determining in said CACS whether the call from said endpoint contains adequate information to establish said audio conference;

responding from said CACS to said endpoint with routing instructions to an IVR server when there is inadequate information to establish said audio conference;

connecting said endpoint to said IVR server when there is inadequate information to route said call and:

gathering in said IVR server adequate information to establish said audio conference; and

transferring said adequate information to the CACS;

determining in said CACS the status of said audio conference;

selecting in said CACS an MCU to host said audio conference when said status of said audio conference is inactive;

selecting in said CACS an MCU hosting said audio conference when said status of said audio conference is active;

responding from said CACS to said endpoint with said queried routing instructions, said queried routing instructions indicating said selected MCU;

transferring said endpoint from said IVR server to said audio conference at said selected MCU when there is inadequate information to route the call; and

connecting said endpoint to said audio conference at said MCU when there is adequate information to route the call.

25. The method ofclaim 24 further supporting full service audio conferencing using a reservation system and a call agent.

26. The method ofclaim 24 wherein said selected MCU is selected from an MCU pool.

27. The method ofclaim 24 further including the step of dynamically routing an operator voice path to service multiple MCUs.

28. The method ofclaim 24 further including the step of renegotiating the destination of a voice path to move an audio conference participant from said selected MCU to a second MCU.

29. The method ofclaim 24 further including the step of moving said audio conference from said selected MCU to a second MCU.

30. The method ofclaim 24 further including the steps of:

providing said audio conference to a streaming protocol server from said selected MCU;

connecting a passive participant to said streaming protocol server; and

broadcasting said audio conference from said streaming protocol server to a passive participant.

31. A large-scale fault-tolerant audio conferencing method in a purely packet-switched network, said method comprising the steps of:

initiating a call from an endpoint to a conference gatekeeper in a gatekeeper cloud;

querying a CACS from said conference gatekeeper for routing instructions for an audio conference;

determining in said CACS whether the call from said endpoint contains adequate information to establish said audio conference;

responding from said CACS to said endpoint with routing instructions to an IVR server when there is inadequate information to establish said audio conference;

connecting said endpoint to said IVR server when there is inadequate information to route said call and:

gathering in said IVR server adequate information to establish said audio conference; and

transferring said adequate information to the CACS;

determining in said CACS the status of said audio conference;

selecting in said CACS a conference MCU from an MCU pool, said conference MCU hosting said audio conference when said status of said audio conference is inactive;

selecting in said CACS a conference MCU from an MCU pool, said conference MCU hosting said audio conference when said status of said audio conference is active;

responding from said CACS to said endpoint with said queried routing instructions, said queried routing instructions indicating said selected MCU;

transferring said endpoint from said IVR server to said audio conference at said selected conference MCU when there is inadequate information to route the call;

connecting said endpoint to said audio conference at said conference MCU when there is adequate information to route the call, once said endpoint is connected to said audio conference, said audio conference:

supporting full service conferencing in said audio conference to said endpoint with a reservation system and a call agent;

supporting dynamically routed audio signals within said packet-switched network;

supporting passive participants in said packet-switched network

supporting dial out from said audio conference to an additional endpoint.

Images