WO2002037803A2

WO2002037803A2 - Method and system for providing audio conferencing services using streaming audio

Info

Publication number: WO2002037803A2
Application number: PCT/US2001/049663
Authority: WO
Inventors: Chris Gindel; Jeffry Pickering; Eric Twietmeyer
Original assignee: Sonexis, Inc.
Priority date: 2000-10-30
Filing date: 2001-10-26
Publication date: 2002-05-10
Also published as: WO2002037803A9; WO2002037803A3; AU2002229119A1

Abstract

A method and system (fig.12) for providing audio conferencing services includes setting up a conference call with a conference bridge using voice over Internet Protocol (VOIP), receiving a request from at least one potential listener (1A or 1N) to listen to the audio content of the conference call at a web site address (3) and converting the VOIP audio content of the conference call to a streaming audio format (81A-81N). At least one potential listener (1A or 1N) having a streaming audio format is connected to a streaming audio format server (81A-81N) for the streaming audio format to effect receipt by the least one potential listener (1A or 1N) of the audio content in the streaming audio format.

Description

METHOD AND SYSTEM FOR PROVIDING AUDIO CONFERENCING SERVICES

USING STREAMING AUDIO

This application is a continuation-in-part of application serial no. 09/528,549, filed March 20, 2000 and now pending .

BACKGROUND OF THE INVENTION

The present invention relates to a method and system for providing audio conferencing services using streaming audio with a voice over IP teleconferencing bridge .

People communicate over their computers using text, chat and instant messaging services. These text, chat and instant messaging services are used over computer networks, global computer networks, and in particular, over the Internet, to allow people to communicate with each other instantaneously.

Often people who are communicating with each other, either over a chat line or an instant messaging connection, want to speak to each other. At present, it is difficult to do this on a spontaneous and informal basis without divulging personal information, for example, a telephone number. It is also difficult to carry out voice communication on a spontaneous and informal basis in groups greater than two persons .

It is therefore desirable to allow people to listen to telephone conference calls over the Internet without actually participating in the call. For example, a radio show or talk show broadcast would be accessible by multiple listeners who could hear the broadcast without actively participating.

One object of the present invention is to allow listeners to hear private telephone conference calls using the proper password, and the listeners and the participants in the calls can be anywhere in the world, as opposed to a radio which is limited to public broadcast and smaller geographical areas .

In accordance with the present invention, this object is carried out by an audio conferencing switch/bridge that sends an IP stream to encoders which then encode the IP stream to convert from PCM to, for example, Real Audio format, and send it to a Real Server. A potential listener goes to a URL and joins the conference by entering the conference ID and password. They are connected to the conference through an embedded Real Player which allows the listeners to listen in.

The method and system allows real time transport protocol (RTP) feeds to be sent to the streaming subsystem and converted from G711Ulaw to PCM and then converted to Real Audio format and then forwarded to the real servers for distribution. The system also has support for file based advertisements. The streaming subsystem has the capability to play a prerecorded Real Audio and/or video formatted file to the -Real Server such that the Real Server thinks it is still the live feed. This allows the streaming subsection to play advertisements at the start and at the end of conferences .

The Internet streaming players, for example the Real Player, will connect to an existing audio conference via a web page link. While the present invention is described using Real Player, Real Server and other Real Networks audio software, it is understood that other streaming audio and video formats can be utilized in accordance with the present invention. The present invention contemplates validation of the user by using a username, password and conference identification. After validation, the web callers are redirected to a new URL that the streaming subsystem creates based upon what conference the web caller wants to join. The set-up of the streaming services will be done dynamically, i.e., not when the conference is set up, but when the first web caller connects for a specific conference. A web caller will be allowed to join the conference regardless of whether the conference was already created by a host panel or whether there are PSTN callers, either hosts or participants already in the conference. In other words, a web caller can create a conference if there is no host panel or PSTN call is already in the conference. This will accommodate the fact that web callers may want to connect five minutes early, so that they don't miss the beginning of the conference. Advertisements can be played while listeners are waiting for the content of the conference to begin.

In a preferred embodiment of the present invention, a play message to the streaming players would be provided when the listeners first connect. This message would only be heard by the player that just connected and not any other listeners. After the message is played, the listener is then connected to the appropriate conference.

The method and system according to the present invention contemplates different scenarios of use. For example, a user can fill out a user name, password and conference I.D. for the conference that they want to connect to in a web page. The web caller is -then presented with a web page to select the advertisements they are interested in hearing, as well as viewing. The client web page connects to the real server, and the streaming player begins to stream audio and/or video to the web caller.

The web caller may decide to hang up at anytime and then reconnect at a later time. The caller would then have to be revalidated if they call in a second time, however, they don't need to use the user name, password or conference I.D. again, because it is still in their real player. If they shut down the Real Player, they will have to reconnect via the web page. The web caller will be played the advertisement and/or message and then finally be connected to the conference. SUMMARY OF THE INVENTION

These and other features of the present invention are achieved in accordance with the present invention by a system and method of providing audio conferencing services. In accordance with the invention, a conference bridge sets up the conference call using voice-over Internet protocol (VOIP) . A request is received from a potential listener at a website address. The listener is preferably requested to provide the conference identification number and an I.D. number or password for the user to allow the user to listen to the content of the conference call . Streaming audio service units convert the VOIP audio content to a streaming audio format, such as, preferably the real audio format. The listener is then connected to a streaming audio format server, preferably a real audio server. The listener, who has an embedded streaming audio format player, for example, a real audio player, is now able to receive the streaming audio format from the server, so as to be able to listen to the audio content of the conference call.

In accordance with a preferred embodiment of the present invention, the connecting of the listener to the real audio server is carried out by redirecting the listener to the server by using a synchronized multimedia integration language (SMIL) file. The file is preferably dynamically generated.

The system also uses load balancing to preserve resources. Thus, a plurality of streaming audio format servers are provided, along with a streaming manager which controls the resources to make sure that the usage of the various servers are balanced. The same is true for the servers which carry out the encoding into the audio format, the service units. A plurality of those are provided, and under the control of the streaming manager, the usage is balanced.

In accordance with another preferred embodiment of the present invention, the requests over the web are controlled by a plurality of web servers which are also controlled to balance usage among those servers.

In accordance with another aspect of the present invention, the system allows for the inclusion of messages and advertisements at the beginning and the end of the audio content, in addition to the content of the conference itself . These and other features of the present invention will become apparent from the following detailed description of invention taken with the drawings, wherein:

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a schematic view of an audio conferencing system in accordance with the present invention for carrying out the method of the present invention;

Figures 2-10 are flow charts of methods for providing audio conferencing services in accordance with the present invention;

Figure 11 is a screen for controlling a conference from a computer;

Figure 12 is a schematic view of an audio conferencing system in accordance with the present invention for carrying out the method of providing audio conferencing services using streaming audio in accordance with the present invention;

Figure 13 is an interaction diagram for web URL redirection for validation and load balancing; Figure 14 is a system flow diagram for the interaction of Fig. 13;

Figure 15 is an interaction diagram for incoming calls;

Figure 16 is an interaction diagram for call hangups ;

Figure 17 is an interaction diagram for a teardown; and

Figure 18 is an interaction diagram for advertisement playing.

DETAILED DESCRIPTION OF THE INVENTION

Figure 1 illustrates the teleconferencing bridge 100 as it is connected to carry out a system and method for providing audio conferencing services. As shown, the bridge 100 is connected to the Internet 3 and to a gateway 5 which provides IP packets of call set up information and IP packets of call content information received from callers 1A-1N over telephone network 4 or directly into the gateway as shown. The gateway is preferably a Sonus Networks GSX 9000 The bridge 100 also receives information from the Internet from computers 2A-2N which are preferably associated with various callers.

The bridge 100 includes as the hub component, an IP switch 10 which is preferably a Cisco Systems 6509 switch. Connected to the IP switch 10 is a switchboard 20 which enables the IP switch to receive calls via the gateway 5 from the telephone network 4 and from callers IAIN and to call out to callers. Also connected to the IP switch 10 is the media service unit manager 30 which controls a plurality of media service units 35A-35N. The call flow manager 50 is also connected to the IP switch 10 and controls call flow units 55A-55N. An SQL database 60 is connected to the IP switch as are servers 70 which in turn are connected to the Internet 3. The database and servers are preferably Dell 6350 or 8350 servers.

The call flow manager 50 receives the call signaling information packets from the IP switch and controls the call flow units to carry out Visual Basic (or other language) scripts which prompt a caller to lead the caller through a series of menus to enable the caller to obtain the desired function in accordance with the method of the present invention. The call flow manager and call flow units are preferably implemented by a multiprocessor having a plurality of Pentium III processors such as a Dell 6350 or 8350 server capable of carrying out the functions with a high degree of redundancy or cluster processing so that the failure of one processor will not prevent the functions of the call flow manager and call flow units from being carried out .

The media service unit manager 30 controls media service units 35A-35N in order to process the call content IP packets so that the packets are assembled for each conference at the appropriate destination of the conference. The media service manager and media service units also handle information received from computers 2A-2N over the Internet 3 via the servers 70 so that information shown on the monitor of one computer can be conferenced and thereby shown on the monitors of other computers of callers in the same conference. The IP switch is also able to receive control information from the computers 2A-2N for controlling the call flow via the call flow manager 50, as will be discussed hereinafter. The media service unit (MSU) manager as well as the IP switch and switchboard have the same multiprocessor or cluster processing configuration as described above. The MSU manager and switchboard are preferably Dell 6350 or 8350 servers. In a preferred embodiment, the media service units each comprise 10 central processing units which are Pentium III microprocessors such as Dell 4350 servers which are each able to handle 200 lines. Thus a single media service unit can handle 2,000 lines and these units can be connected as shown. Thus in order to scale up the system to handle more conference lines, one need only add media service units under the control of the media service unit manager .

The media service unit manager determines which media service unit has free space for controlling the content of the conference.

The switchboard 20 communicates with the gateway 5 through the IP switch 10 to receive the call set up information. The call flow manager 50 decides how a call is to be processed and instructs the switchboard and the media service unit manager to configure the system and allocate resources of the system necessary to process the call. The scripts for carrying out the calls are stored in the SQL database 60.

The switchboard receives the call set up information packets which include, when available, information relating to the number dialed (DNI) , caller ID (the caller's telephone number or ANI) as well as any other information as to the type of connection or the network the caller is calling from. The switchboard provides this information to the call flow manager which uses the information to select and process a script as well as make the information available to the scripts for processing the call . In addition, a caller already participating in an audio conference, such as a host, can initiate a script to place a call to a new participant of the audio conference. In this mode, the script gets the number from the host and instructs the switchboard to initiate a call to that number.

The call flow manager also determines how the system responds to various system events and uses the scripts to execute predefined responses to system events. The call flow manager receives the information from the switchboard relating to the system event and uses the information to select and execute the appropriate switch.

The media service unit (MSU) manager 30 manages the media service unit resources of units 35A-35N that provide auto conferencing services to the individual caller. The MSU manager communicated with the call flow manager and assigns the MSU system resources to each call that is processed. The MSU manager assigns the MSU system resources as a function of the MSU resource that is available. The web server 70 also provides a web-based interface to allow a participant to join an audio conference or allow the host of a conference to add or drop a participant from an audio conference. This interface is carried out by the server 70 which interfaces with the Internet 3 and provides information via the IP switch to the call flow manager 50 and the MSU manager 30.

The MSU manager also provides audio conferencing services such as enabling a plurality of audio conferences, real time conference recording and playback, and interactive voice response based services. In one embodiment, each media service unit 35A-35N is a 500 megahertz Intel Pentium III CPU with 512 megabytes of RAM. Each runs a Microsoft Windows NT server operating system, Microsoft Internet Information Server and Microsoft Transaction Server. In this configuration, the switchboard, call flow manager, and MSU manager, can be software modules compliant with the Microsoft Component Object Model and Distributed Component Object Model specifications. The scripts can be written in Microsoft Visual Basic.

The media service units receive call content information packets and either combine them with other packets to be sent to other participants in the audio conference, are sent to other participants of the audio conference or are discarded, depending upon the configuration of the audio conference. In one embodiment, where there are two or more participants in an audio conference and participant 1 and participant 2 are the loudest speakers, the audio conferencing bridge can be configured to send the following signals to the following participants: participant 1, the signal received from participant 2; participant 2, the signal received from participant 1; and to participant 3 and all other participants, the combined signal from participant 1 and participant 2.

The call flow manager can be adapted to utilize a plurality of scripts that determine how incoming calls, based upon information received in the call signaling packets, can be processed. The choice of scripts can be determined by ANI/DNI, or by conference number or member number input by the caller. The call flow manager can process each incoming call by having the MSU manager assign the call to a media service unit which can play a prompt to the caller asking the caller to identify a conference to be connected to as well as a password or other authenticating identification. The caller can input information via a telephone key pad (DTMF) or by voice. Based upon the input information, the incoming call can be connected to the media service unit responsible for that audio conference. Alternatively, the call flow manager can execute a script which notifies the host of a conference that a participant is waiting to be connected to the conference and await the host authorization to let the participant join the conference . When a local telephone network notifies the bridge that a call has been placed to the audio conferencing switch, the switchboard notifies the call flow manager of the incoming call and provides any information that was included in the call signaling message received from the local exchange carrier. The call flow manager, using that information (such as the ANI/DNI) , selects and executes the script to process the incoming call. During the course of executing the script, the call flow manager can instruct the MSU manager to assign the media service unit to service the incoming call. If the call flow manager is unable to determine which audio conference the incoming call is to be connected to, the system must query the caller to ascertain the identifier of the appropriate conference. Thus a first media service unit can be used to query the caller to ascertain the appropriate conference and then the call may be assigned to a second media service unit that hosts the conference.

The switchboard and call flow manager also work together to provide services to participants of a conference, such as to allow a participant to exit from a conference or to switch conferences. The system according to the present invention processes a call as follows. The incoming call from the local telephone network has the information therein converted into VOIP packets which are supplied via the gateway 5 to the bridge 100. The incoming packets are transmitted to the switchboard and when the switchboard answers the call, it notifies the call flow manager. The call flow manager notifies the MSU manager that a particular MSU service is needed and, in one embodiment, the MSU manager notifies the switchboard of the IP address of the MSU service that will service the incoming call . The switchboard then notifies the gateway of the port or the destination IP address from the media service unit that will process the call. The IP switch directs the IP packets to the appropriate port which was assigned by the MSU manager to process the call . Once a call has been assigned to a media service unit, the media service unit processes all call content IP packets received from or sent to a caller. Thus the media service unit can add the caller to a conference, drop the caller from a conference or respond to an interactive voice response request. In one embodiment, the MSU manager is a DCOM object that spawns instances of the MSU 35A-35N to handle each call.

Alternatively, the IP switch can receive inputs from a web site maintained by servers 70 that allows management of an audio conference . The MSU manager receives instructions from the servers via the IP switch and acts on those instructions to add a caller to a conference, delete a caller from a conference, mute a caller or provide additional services. The inputs are generated by the host and optionally by the other participants by activating "buttons" on a monitor of computer 2A. An example of a screen with these controls is shown in Fig. 11.

The method can further comprise providing a web site relating to the audio conferencing services, allowing participants to access the web site and display images thereon as shown in Fig. 11 including a display of at least one of the participants on a display of at least one of the other participants of a conference call. The screen also provides conference call service options on a display of at least one participant and permits the at least one participant to select a conference call service option from the display. The options as shown include dialing out to additional participants, muting at least one of the participants and determining the number of participants in the conference call .

Each media service unit 35A-35N provides audio conferencing services to an assigned caller. Each caller is assigned an IP address of a media service unit that receives audio data IP packets and each media service unit is responsible for transmitting IP packets of call content information to the caller. In accordance with the invention, the media service units determine what audio information is output to the caller. In one embodiment, where there are more than two participants to an audio conference, the conference can be configured to send the signals from one participant to the other and vice-versa and the combined signals from the two participants to a third participant. In an embodiment where there are only two participants, the conference is configured so that each hears what the other is saying.

Figures 2-10 show the flow of various methods of providing conferencing services in accordance with the present invention.

Figure 2 illustrates the method according to the present invention using the bridge shown in Figure 1 for the host calling in to set up in a conference.

In step 200, a caller dials a local number such as 1-617-yes-eYak, an 800 number or the like to reach the IP switch 10. Upon connection to the IP switch, there is an eYak chime in step 201 and a welcoming message in step 202. The call flow manager then initiates a script in step 203 where the caller is asked whether the caller wants to join a conference, host a conference, or sign up with the system. If the caller wishes to sign up, the caller is sent to step 204 which transfers out to a caller sign in routine. If the caller presses no button or presses an incorrect button, an error message will be obtained in step 220. If the caller indicates a desire to join a conference, the caller is sent to a participant entry process in step 205. On the other hand if the caller chooses to host a conference, the caller will be asked for a conference identification in step 207. A host conference identification entry can also be achieved from another path at step 206 (step 407 in Fig. 4) according to the present invention. If the caller in step 207 enters an unrecognized identification, an error message will be given in step 208. If the caller does not have an identification but wishes to sign up for one, then the caller is sent to step 204. If the caller enters an identification, the caller is asked in step 209 to enter a pin number. If the pin number is incorrect, there will be an error message at step 210. If the pin number is correct, the system will next determine if the conference is underway in step 211. If the conference is underway, then the caller is sent to the host reentry step 212. If the conference is not underway, a message is given to the caller in step 213 to set up the conference to see if a password is required. Step 213 can also be accessed via the host conference routine from step 214 (see step 407 in Fig. 4) . If no password is required, then the caller hears the eYak chime in step 216. If the caller enters a password, a scripted response is given in step 215 and then the chime is received in step 216. After the chime, the caller is prompted with a starting message in step 217 and the conference is started with the host as the initial member in step 218.

Figure 3 illustrates the participant entry process for the method according to the present invention.

The participant entry process starts in step 300 whereupon the caller is prompted to enter the identification of the conference in step 301. If an improper identification is entered, an error message will be received in step 302. If a correct identification is received, then a determination must be made if the conference has started already in step 303. If the conference has not started, the caller is informed of this fact in step 304 and a message is played or promotional material is heard by the caller for a given amount of time, preferably 10 minutes in step 305. If the conference does not start after ten minutes, the caller is informed that the conference host has not arrived and that the caller should try for the conference at another time in step 306, whereupon the caller is disconnected in step 307. If on the other hand the conference starts before the end of 10 minutes, a determination is made as to whether the conference requires a password in step 309. A host reentry as a participant can also occur at this point in the process from step 308. If no password is required, the eYak chime is received in step 311 and a scripted message is delivered to the caller indicating that the conference is being joined in step 312 and the participant is added to the conference in step 313 and the other participants are informed of this fact by the use of an entry tone. If the conference requires a password, the user is prompted to enter the conference password in step 310. If the password is improper, an error message will be received in step 320. If the proper password is entered, the caller will be directed to step 311 as previously described.

If the conference has started, a determination is made in step 314 whether the conference is full. If the conference is full a scripted message is returned to the caller in step 315 informing the caller of this fact and the caller is disconnected in step 316. If the conference is not full, the next determination to be made is whether the conference is locked in step 317. If the conference is locked, a scripted message is delivered to the caller in step 318 informing the caller of this fact and the caller is disconnected in step 319. If the conference is not locked, the caller is directed to the step 309 as previously described.

Figure 4 illustrates the host reentry method starting at step 400. When the host seeks to reenter, the first determination to be made by the system is whether the existing conference still has a host connected and this is done in step 401. If there is no host connected, the caller is prompted with the message in step 402 and the menu of items therein. If the caller wishes to rejoin the conference as the host, the caller is added to the conference as a host in step 403. If the caller wishes to end the existing conference and start a new one, the caller is directed to the menu items in step 404. If the caller inadvertently had asked to end the conference, the caller is directed back to the choices given in step 402. On the other hand, if the caller seeks to end the existing conference, this is carried out in step 405 and the caller is directed to the host conference setup in step 406. If the caller sought to reenter the conference identification, then the host is directed to step 407 wherein the host identification entry routine is carried out .

Returning back to step 401, if the existing conference still has a host connected, the system then determines if the conference is full. If the conference is full, the caller is prompted with a message in step 412 informing the caller of that fact and giving the caller the option to host a different conference. If the caller seeks to host a different conference, the caller is directed to the host conference identification entry step 407. If the conference is not full, then a determination is made in step 409 if the conference is locked. If the conference is locked, the script informs the caller of this fact in step 413 and gives the caller the option to host a different conference whereupon the caller will be directed to step 407. If the conference is not locked, the caller is given the menu choices in step 410 to either join the conference as a participant or host a new conference. If the caller decides to join the conference as a participant, the caller is added as a participant in step 411 and the current participants are informed by means of an entry tone. If the caller seeks to form a different conference, the caller is directed to step 407.

Figure 5 illustrates some of the teleconferencing services that may be performed in accordance with the method and system of the present invention. During the conference, a caller presses certain numbers in step 500 to access these functions. As noted, the caller can get to any of the sub-functions by pressing the appropriate numbers directly. If the caller is a host, the caller is prompted with a menu in step 501 giving the caller a number of options. If the caller is a participant, the caller is prompted with a menu in step 502. The options for the participant in step 502 is to mute or unmute the line whereupon the lines is muted in step 505, to speak with a customer service representative, whereupon the user is transferred out in step 515, to hear the menu again, or to return to the conference whereupon the user is returned to the conference in step 503. If a button is hit which is incorrect, the error message will be received in step 504 and the caller will be returned to the conference. Similarly, if the caller does not react to any of the menu items, the caller will be returned to the conference in step 503.

The host has a number of other options available. One option is to dial out to a new participant which is carried out in step 506. The second option is to allow the participants to continue talking after the host disconnects and this is carried out in step 507. Another option is to carry out call recording which is initiated in step 508. The host can also lock or unlock a conference and this is carried out in step 509. The host may initiate a roll call in step 510 or the host can mute a particular caller in step 511. The host can initiate a lecture mode, wherein all of the participants, with the exception of the host are muted and this is carried out in step 512. The host can record a conference greeting in step 513 or the host can change the pin number for the conference in step 514. Alternatively, the host can return to the conference at any time in step 503 or the host can go to a customer representative and transfer out in step 515.

Figure 6-10 show how the various functions shown in Figure 5 are carried out by the system. In Figure 6, the dial out routine is shown starting at step 600 whereupon the specific number entries from the caller. The system determines in step 601 if the conference is full, and if not, the caller is prompted in step 602 to enter the area code and phone number of the person to be added and whether or not the host wants to rejoin with the new participant or disconnect the new participant and rejoin without the new participant. The host dials the number and gives the information regarding the joiner which is received in step 603. If the host seeks to rejoin without the new participant, a chime is received in step 604, the user is prompted in step 605 that the caller is rejoining the conference and the new participant is abandoned and the host is returned to the conference in step 606 and the conference hears the appropriate entry tone. If on the other hand the host seeks to join with the new participant, an eYak chime is received in step 607, the announcement message is given in step 608 that they are rejoining and the host and new participant are added to the conference in step 609 and a suitable entry tone is sounded. If the conference is full as determined in step 601, the caller is prompted in step 610 of this fact and informed that before one can dial out to more participants, some of the participants must hang up. If the host is a paying subscriber as determined in step 611, the host is allowed to rejoin the conference as indicated by the prompt in step 613 and returned to the conference in step 614. If the host is not a paying subscriber, the host is prompted in step 612 to increase the maximum size of the conference by signing up for a more expensive service.

The steps for carrying out conference continuation are shown starting at step 620 which leads to a determination by the system in step 621 if the conference is already set to continue after the host disconnects. If not, the host is prompted in step 622 with a message that the conference may now continue until the last participant hangs up even if the host is disconnected. The host is then returned to the conference in step 624. If the conference is already set up to continue after the host connects, the host is prompted in step 623 that the conference will be ended and that all participants will be disconnected when the host is disconnected. The host is then returned to the conference in step 624. Figure 7 illustrates the steps for call recording, conference lock and roll call. If call recording is selected in step 700, a determination is made by the system in step 701 if the conference is already being recorded. If not, the user is prompted in step 702 that conference recording will begin and the host is returned to the conference in step 703 with the message that conference recording has begun. If the conference is already being recorded, the host is prompted with the message that conference recording has been paused and to resume recording the user must initiate recording again. The host is then returned to the conference in step 705 and the message that the recording has stopped is played to the conference .

When the conference lock feature is selected in step 710, the system first determines in step 711 if the conference is already locked, and if not, the host is prompted with the message in step 712 that the conference is now locked and the host will be paged when new participants try to join the conference. The host is then returned to the conference in step 713. If the conference is already locked, the host will be prompted with the message in step 714 that the conference is now unlocked and to relock the host must go through the conference lock routine again. The host is thereafter returned to the conference in step 713.

If the host selects the roll call function in step 720, the system first determines the number of people in the conference in step 721. If only one, the host is prompted with the message in step 722 that the host is the only person in the conference and the host is then returned to the conference in step 725. If there is more than one person in the conference, the host is prompted with the message in step 723 that there are N people in the conference, where N is the number of people in the conference. The host is then returned to the conference in step 725. In a preferred embodiment of the present invention, name recording is made available so that not only will the number of people in the conference be told to the host, but the roll call will include the names thereof.

Figure 8 shows the routines for mute calling and lecture mode. When the host selects to mute a caller in step 800, the system determined in step 801 is the caller is already muted. If not, the host is prompted with the message in step 802 that the line is now muted and to unmute it the host must go through the process again. If the line is already muted, the host is prompted in step 803 that the line is now unmuted and to remute the line the user must go through the same process again. The caller is then returned to the conference in step 804. It will be apparent that this mute caller routine can also be used by the caller who is a participant.

When lecture mode is selected at step 810, the system first determines in step 811 if the participants are already muted. If not, the host is prompted with the message that all participants are now muted in step 812 and to unmute the host must go through the routine again. The host is then returned to the conference in step 814. If the participants are already muted, the host is prompted in step 813 that the participant lines have been unmuted and to re- mute them the host must be go through the process again. The host is then returned to the conference in step 814. Figure 9 shows the steps for recording a greeting when such is selected at step 900. The host is prompted in step 901 to record a personal conference greeting and the caller can select the standard greeting or record a personal greeting. If the caller elects to use a standard greeting, the caller is prompt in step 907 that a standard greeting will be used and the host is returned to the conference in step 908. If the host elects to record a personal greeting, the host is prompted in step 902 to record the greeting at the tone. If the message exceeds 3 minutes, the host will be prompted in step 904 that the greeting went beyond the time limit. If the host does not enter any greeting, an error message at step 903 will be given to the host. If on the other hand the host records the message properly, the host is then prompted in step 905 with a menu to keep the greeting, erase the greeting, review the greeting or switch to a standard greeting and finally to return to the conference with the greeting unchanged. If no choice is made or an improper choice is made an error message is given in step 906. If the host seeks to use a standard greeting, the host is prompted in step 907 that the standard greeting will be received as hereinbefore described. If the host seeks to keep the greeting, the host will be prompted in step 909 that the greeting will be kept and the host is returned to the conference. If the host decides to use the old greeting, the host will be prompted in step 910 that the old greeting will be kept and the host is returned to the conference. If the host wants to review the greeting, the host plays the greeting for review in step 911 and returns to the menu again as in step 905.

Figure 10 illustrates the steps for carrying out a change in the pin number for the conference. If change pin number is selected at step 1000, the system prompts the host in step 1001 to enter a new pin followed by the pound sign. If the host changes his or her mind, the host is returned to the conference in step 1002. If an improper pin number is entered, the host will receive an error message in step 1006. If a new pin number is entered, the host will be prompted to reenter the pin number in step 1003 and if it is incorrectly done the host will receive an error message in step 1004. If the second entry of the pin number has been made, the host will be prompted in step 1005 that the new pin number has been recorded and the host will be returned to the conference in step 1007.

In accordance with a further aspect of the present invention, the operator of the conference bridge can bill for the audio conferencing services in a number of ways .

For example, the operator of the bridge can bill the host for each participant minute. That is the standard way that audio conferencing has always been billed. Alternatively, the operator of the bridge can bill each participant per minute of connection to a conference. Additionally, the conference bridge can play advertisements at selective times during the conference call or show advertisements on the computer screen of the user, as is shown in Figure 11.

In an alternative embodiment of the present invention, the operator of the bridge can make money as a result of the way in which the telephone industry is regulated. If a person makes a long distance call, the long distance company has to pay the local telephone company that terminates the call. The bridge according to the present invention will have a local telephone company associated therewith. Thus each person calling the conference number will not have to pay for the conference, since the bridge will be receiving the payment from the long distance companies for terminating each of the long distance calls.

Referring now to Fig. 12, the conference bridge 100 has been shown as a single block with the IP switch 10 therein for the sake of simplicity, however, the bridge 100 contains all of the elements set forth in Fig. 1. Connected to the bridge is a streaming subsystem 80 which includes streaming audio servers 81A-81N, streaming service units 82A-82Ν, a streaming manager 84 and a redirector 83. The elements 81-84 are interconnected to the IP switch 10 in the conference bridge 100, and the servers 81A-81N are connected to the Internet 3. Each of the units 81-84 can be implemented using conventional servers and can be constitute a single server for one or all of the functions are one or more servers for each of the functions, depending upon the scale of the system.

The streaming subsystem 80, along with the conferencing bridge 100, maintains the call state and the telephony rules and mixes the audio such that all participants can hear and talk to one another. The conference bridge 100 includes the switchboard which manipulates the H.323 protocol or other VOIP protocol to perform the telephone functionality. The MSU manager and MSU service units control and mix audio conferences and play announcements to the incoming callers. The call flow manager invokes the visual basic scripts to control the calls in the system.

In the streaming subsystem, the redirector redirects content from the gateway to the appropriate media service unit via the IP switch. The redirector receives audio RTP packets from the gateway and forwards it to the appropriate MSU. The outgoing audio stream is sent directly from the MSU to the gateway 5. The MSU will source an RTP stream per conference to the streaming service units for encoding, which is then sent to the streaming audio server and then on to the listener.

The streaming audio servers 81A-81N, in accordance with one example of the present invention, are Real Audio servers. The streaming service units 82A-82N, under the control of the streaming manager 84, have the same architecture structure as the MSU manager and MSU's, whereby one manager manages a set of streaming converters which take incoming live streams from the MSU and converts them into the real audio streaming format . In the example of using Real Audio, the streaming service units will be set up after getting the Allowance plug-in that runs in the Real Servers. The Allowance plug-in is invoked whenever a player connects to a Real Server.

The streaming manager also controls the streaming audio servers 81A-81N in the same way that the MSU manager controls the MSU's. By routing data to the servers or the service units, the streaming manager can balance the usage of the various units and servers.

The Real Servers 81 will also validate each user as they connect in addition to validation done by the web server 70 when the browser first tries to connect to the system. It must provide fan out of 1 stream to N streams. It should also have the ability to connect any player that is already connected, to any existing stream...

The streaming service units will be architected similarly to the MSU Manager/MSUs where by there is one manager (the streaming manager) managing a farm of streaming service units which will take incoming live streams from the MSU and convert them into the Real Audio streaming format. The streaming service units will be set up after getting an indication from the Allowance plug-in that runs in the Real Server. The Allowance plug-in is invoked whenever a player connects to a Real Server.

Referring below to Table I, the following is the interface from the real server 81A-81N to the streaming manager 84 for an incoming call.

Table 1 Web URL Redirection

players/encoders . This algorithm will be improved for our next release.

Redirect Web Server Redirects the user to a page with an embedded Real Player control . The control is passed a SMIL file that is generated on the fly by our system. The SMIL file contains any messages that should be played to the user before or after the conference and the conference URL itself. The conference URL is in the form: rtsp : //Hostname : 554/A llConf?ConfID=www&-use rname=xxx&password=yy y&P1aye ID=zzzArchive =TRUEFi1ename=xxx

Where hostname is in the form

"RealServer1. eyak. com " . PlayerlD, which is a unique ID for this user, is generated by the Stream Manager. Archive and Filename are used to archive the conference .

Each Real Server will [in] BSTR register with STRM hostname ,

Registers Mgr when Real Server treamServ comes up. [in] RSControl

Figure 13 is a Web URL redirection for validation and load balancing interaction diagram.

• User fills out Conference ID and Password (if necessary) and hits enter. The URL will look something like this http : //stream. eya . com/j oin . asp

• The web browser connects to a Layer 4 load balancer which picks one of the Web Servers. The Web server loads the ASP code, validates the user, then checks with the streaming manager to find out what Real Server to redirect to.

• Next, the ASP code performs a database hit and retrieves the ad URLs that are to be played before and after the conference . Then the ASP code performs a second database hit to get archiving information. The archive information, the ad URLs, and the Real Server URL are then used to generate a SMIL file on the web server.

• The browser is redirected to the SMIL file which causes the Real Player to contact the Real Server and play the first ad'. When the ad is finished the SMIL file passes the conference URL to the Real Server. The Conference URL is a generic URL with conference and user specific information that the Real Server Allowance plugin will use. The conference URL, which is embedded inside the SMIL file, will now be in the form rtsp : //Hostname : 554AllConf?ConfID-xxx&username=---xx &password=xxx&PlayerID=xxx&Archive=TRUE&filename=xxx. Hostname is either an IP address or DNS name that the Streaming Manager returns to the Web Server. • The streaming manager will need to parse the ConflD to use to check if the conference exists. If it exists, it will pick the Real Server where the conference is already set up, otherwise if will check it in memory database to see what Real Server and streaming servers combination is free. The Streaming manager will then return to the real server the final URL that the player should be redirected to. It will be in the form: rtsp : //hostname : 554/encoder/livel2_12345678. rm

Figure 14 is a system flow diagram for the redirection and balancing.

• The user first logs into the web server with their Conference ID and Password (if necessary) . • The web server then validates the user. If the user is valid the web sever performs a couple of tasks. It gets the correct name of a Real Server to use, gets some archiving information, figures out which ads to play, and creates a SMIL file. The user is then redirected to another web page.

• This web page contains an embedded Real Control that is passed the SMIL file. The control reads the SMIL file and plays the first URL which will be an advertisement/message. When the Advertisement is finished the Real Control will load the RTSP URL in order to start the conference and connect to the Real Server.

• The Real Server uses the Allowance plug-in to direct the user to the correct conference as an encoder starts streaming audio from the conference to the server. The Real Control is eventually passed the conferences RTSP stream and the user can begin listening.

The following Table 2 and Figure 15 describe the incoming call interface. Table 2 - Incoming Call Indication/Response

of Streaming Service OwnerMemID for MSU to send its output to. If [in] PlayerlD conference exists Stream Mgr will just [in] Archive hand back the URL Flag without creating a new conference . The [in] Archvie URL already has the Filename correct Real Server hostname so no need [out] to find this out, URL/Filename just redirect to the preexisting URL [out] rej ect/reason

Stream Tell MSU manager and [in] Stream ID Conferenc Call Flow to create a e Created streaming connection Event and add it to the conference specified.

Redirect/ The streaming player [out] URL Reject is redirected to a new URL by the [out] Reason ? allowance plugin that runs in the Real Server, which represents the conference that the user wishes to connect to. OR Reject the connect

Connect After the Real Player [in] DWORD cmd connects, send Player ID connect cmd to STRM Mgr and make internal [in] DWORD record of player OwnerMemID ID/Conf ID

[in] BSTR hostname Referring to Figure 15, the call flow is as follows:

• Browser is redirected to Username, Password, and Conference ID, PlayerlD for which they wish to connect.

• The client web page logic connects to a URL of the form rtsp : //Hostname : 554AllConf?ConfID=x&username=y&password= z&PlayerID=nnn which causes the Real player to contact the Real Server.

• The Real Server using an Allowance Plug-in or Similar type of Plug-in, validates the user by passing control ^■ over to streaming manager blocking on the return.

• Streaming manager creates the URL/Filename if the stream doesn't already exist for other web callers, creates a StreamingConf and informs MSU of RTP info for this stream conference .

• Streaming manager returns to the Real Server the URL/Filename for the player to connect to.

• The Streaming Player connects to the new redirected URL and begins hearing the conference.

• Real Server gets indication that player connected and sends event to streaming manager. Table 3 and Figure 16 describe the call hangup flow.

Table 3

Referring to Figure 16, User disconnects player.

Real Server sends streaming manager disconnect cmd. Streaming manager sends disconnect events to MSU manager and call flow manager.

If this is last web caller in conference, streaming manager cleans up resources in streaming service unit and sends Conf Finished event to to call flow manager and MSU.

Table 4 and Figure 17 describe the teardown interaction of the system. Table 4

Referring to Figure 17,

• Call Flow disconnects player (s) or Conf.

• Real Server disconnects player (s). • If this is last web caller in conference, streaming manager cleans up resources in streaming server unit and send Conf Finished event to call flow manager and MSU.

Table 5 and Figure 18 describe the advertisement play interaction of the system.

Table 5

Referring to Figure 1. • Call flow manager instructs streaming service units to play file based ad.

• Streaming service units send event back when done playing ad.

• Call flow manager instructs MSU to pause conference/Stream ID while ad is playing.

The method and system allows real time transport protocol (RTP) feeds to be sent from the streaming subsystem and converted from G711ULAW to PCM and then converted to Real Audio format and then forwarded to the Real Servers for distribution. The system also has support for file based advertisements. The streaming subsystem has the capability to play a prerecorded real audio and/or video formatted file to the real server such that the real server thinks it is still the live feed. This allows the streaming subsection to play advertisements at the start and in the end of conferences .

The Internet streaming players, the Real Player, will connect to an existing audio conference via a web page link. While the present invention is described using Real Player, Real Server and other Real Networks audio and video software, it is understood that other streaming audio and video formats can be utilized in accordance with the present invention.

The present invention contemplates validation of the user by using a user name, password and conference identification. After validation, the web callers are redirected to a new URL that the streaming subsystem creates based upon what conference the web caller wants to join. The setup of the streaming services will be done dynamically, i.e., not when the conference is set up, but when the first web caller connects for a specific conference. A web caller will be allowed to join the conference regardless of whether the conference was already created by a host panel or whether there are PSTN callers, either hosts or participants already in the conference. In other words, a web caller can create a conference if there is no host panel or PSTN call is already in the conference. This will accommodate the fact that web callers may want to connect five minutes early, so that they don't miss the beginning of the conference. Advertisements can be played while listeners are waiting for the content of the conference to begin. In a preferred embodiment of the present invention, a play message to the streaming players would be provided when the listeners first connect. This message would only be heard by the player that just connected and not any other listeners. After the message is played, the listener is then connected to the appropriate conference.

The method and system according to the present invention contemplates different scenarios of use. For example, a user can fill out a user name, password and conference I.D. for the conference that they want to connect to in a web page. The web caller is then presented with a web page to select the advertisements they are interested in hearing, as well as viewing. The client web page connects to the real server, and the streaming player begins to stream audio and/or video to the web caller.

The web caller may decide to hang up at anytime and then reconnect at a later time. The caller would then have to be revalidated if they call in a second time, however, they don't need to use the user name, password or conference I.D. again, because it is still in their Real Player. If they shut down the real player, they will have to reconnect via the web page. The web caller will be played the advertisement and/or message and then finally be connected to the conference.

It is understood that the embodiments described hereinabove are merely illustrative and are not intended to limit the scope of the invention. It is realized that various changes, alterations, rearrangements and modifications can be made by those of skill in the art without substantially departing from the spirit and the scope of the present invention.

Claims

What is claimed is:

1. A method of providing audio conferencing services, the method comprising the steps of: setting up a conference call with a conference bridge using voice over Internet Protocol (VOIP) ; receiving a request from at least one potential listener to listen to the audio content of the conference call at a web site address; converting the VOIP audio content of the conference call to a streaming audio format; and connecting at least one potential listener having a streaming audio format player for the streaming audio format to a streaming audio format server for the streaming audio format to effect receipt by the at least one potential listener of the audio content in the streaming audio format .

2. The method according to claim 1, wherein the step of receiving comprises receiving at least one request over the Internet .

3. The method according to claim 1, wherein the step of receiving comprises validating the at least one potential listener by prompting for a conference identification and password.

4. The method according to claim 1, wherein the streaming audio format is RealAudio.

5. The method according to claim 1, wherein the step of connecting comprises redirecting at least one potential listener using at least one Synchronized Multimedia Integration Language (SMIL) file.

6. The method according to claim 5, wherein the at least one SMIL file is dynamically generated.

7. The method according to claim 1, wherein the step of connecting comprises providing a plurality of streaming audio format servers and connecting a potential listener to one of the servers to balance the use of the plurality of servers.

8. The method according to claim 1, wherein the step of converting comprises providing a plurality of streaming audio format service units and applying the audio content to one of the service units to balance the use of the plurality of service units.

9. The method according to claim 1, further comprising feeding additional audio content into the streaming audio received by the at least one potential listener.

10. The method according to claim 9, wherein the additional content is an advertisement.

11. The method according to claim 10, wherein the additional audio content is fed prior to the onset of the conference call audio content .

12. A system for providing audio conferencing services comprising: a conference bridge for setting up a conference call using voice over Internet Protocol (VOIP) ; at least one web server for receiving a request from at least one potential listener to listen to the audio content of the conference call at a web site address; at least one streaming service units for converting the VOIP audio content of the conference call to a streaming audio format ; and at least one streaming audio server for connecting to at least one potential listener having a streaming audio format player for the streaming audio format .

13. The system according to claim 12, wherein the web server receives at least one request over the Internet.

14. The system according to claim 12, wherein the at least one web server validates the at least one potential listener by prompting for a conference identification and password.

15. The system according to claim 12, wherein the streaming audio format is RealAudio.

16. The system according to claim 12, wherein the at least one streaming audio server redirects the at least one potential listener using at least one Synchronized Multimedia Integration Language (SMIL) file.

17. The system according to claim 16, wherein the at least one SMIL file is dynamically generated.

18. The system according to claim 12, comprising a plurality of streaming audio servers and a streaming manager for connecting a potential listener to one of the servers to balance the use of the plurality of servers .

19. The system according to claim 12, comprising a plurality of streaming audio service units and and a streaming manager for applying the audio content to one of the service units to balance the use of the plurality of service units.

20. The system according to claim 12, further comprising a streaming manager for effecting the feeding of additional audio content into the streaming audio received by the at least one potential listener.

21. The system according to claim 20, wherein the additional content is an advertisement.

22. The system according to claim 21, wherein the additional audio content is fed prior to the onset of the conference call audio content.