HK1134189B - Voip conferencing - Google Patents

Description

Field of the Invention

The present invention relates generally to the field of teleconferencing and more particularly to VOIP-based (Voice Over Internet Protocol) conferencing systems.

Background of the Invention

VOIP (Voice Over Internet Protocol) provides a significant cost advantage over standard PSTN (Public Switched Telephone Network). In addition, it is easier to add features to VOIP systems than PSTN systems. This trend is extending into teleconferencing systems. However, using the same techniques for VOIP conferencing as are presently used for PSTN conferencing would unnecessarily limit VOIP conferencing systems, particularly in regard to reliability-enhancing features such as load balancing amongst conferencing equipment and recovering from equipment failures.

Thus, there exist a need for VOIP conferencing system that takes advantage of the features that can be provided by using networking, including the internet.

Document US 2004/0062210 A1 discloses a system and method for providing conference calling over an IP network, wherein a conference calling platform interacts via a gateway connected to the Internet and conference call participants directly access the conference calling platform via an analog telephone call carried over the PSTN.

Document WO 01/86930 A2 includes a system, method and access gateway for minimizing the number of transcodings of a speech signal during a Voice-over-IP (VoIP) conference call in a packet-switched network in which Tandem Free Operation (TFO) is utilized, wherein the system includes a first gateway connecting the first mobile subscriber to the network, a second gateway connecting the second subscriber, and a third gateway connecting the third subscriber.

Document US 2003/0014488 A1 provides a system and method for enabling multimedia, real-time group communications on real-time communications platforms, wherein real-time communications platforms provide multimedia, real-time conferencing and communications services and wherein the system includes a service provider controller and a service provider media server.

Document US 2003/0023672 A1 illustrates and describes an Internet telephony conferencing system and an Internet video telephony conferencing system that includes a plurality of conferencing servers, each controlling a plurality of conferencing bridges, wherein each bridge is configured to host an Internet telephony conference call or Internet video conference call between two or more telephony clients and each client is configured to select a conferencing server for initiating the conference call based on a measurement of network quality of service between the client and the conferencing server.

Document US 2005/0094579 A1 illustrates and describes a system, including apparatus and architecture, and a method for providing scheduled and ad hoc voice over IP conference services having enhanced quality and reliability, wherein the system uses an overlay network of geographically distributed conference servers working simultaneously and collaboratively to host a given conference session and multiple conference servers simultaneously and collaboratively perform the necessary audio mixing.

Document US 2004/0037407 A1 includes a method and a system for selecting a Multimedia Resource Function Controller (MRFC) for allocating resources for a conference call based on a pre-defined condition, wherein the condition is associated with a status of an MRFC of a first network, such as an overload of resources, a failure, or an inexistence of the MRFC in the first network and when the condition is detected, an application server (AS) of the first network delegates the responsibility of allocating the resources for the conference call to an MRFC of a second network.

Document US 2003/0002481 A1 includes a method and a system for providing media services in Voice over IP telephony, wherein a switch is coupled between one or more audio sources and a network interface controller.

Summary of Invention

The present invention is a conferencing system according to claim 1 that is based on VoIP internally and can easily handle different protocols, load balance among multiple applications servers and media resources, and deal with failure situations. The conferencing system can include a gateway coupled to the PSTN (Public Switched Telephone Network), thereby maintaining a conventional service access method for traditional PSTN callers. The present implementation of the invention employs SIP as the internal call-control protocol, but other protocols could be employed, either instead of SIP or in addition to SIP.

All externally-originated calls, whether of PSTN origin or native VoIP, communicate over SIP to the conferencing system through one or more proxy server(s). The proxy identifies new call requests and initially forwards these to a Voice Services Director (VSD) application, with the proxy performing load-balancing among several available VSD instances. The VSD validates the caller and/or identifies the desired conference by using interactive voice response (IVR) mechanisms. The VSD uses a back-to-back user agent (B2BUA), employing SIP as the call-control protocol, to control a media server which plays voice prompts to the caller and performs DTMF detection functions. The use of a B2BUA decouples the caller from the specific media server resource used by the VSD, allowing the VSD to utilize any media server resource that is available. The caller's call-control terminates at the VSD, while the VSD independently manages the media server resource that is assigned to handle the caller's separate media stream(s).

After the VSD, in conjunction with a media server resource, has collected necessary information from the caller, the VSD checks with the back-office servers to find out if the passcode is valid, and if so, where to send the caller next. If this is the first caller for the conference, the back-office will use a load-balancing algorithm to determine on which bridge to start the conference. If, on the other hand, the conference has already started, the back-office will identify which bridge the conference is running on. This bridge-selection information is passed back to the VSD, which then transfers the caller to the desired bridge.

Bridge software, which also employs a B2BUA, acts as the conference 'bridge', controlling the conference and the individual callers at a high level, while the low-level media operations (such as audio mixing, prompt playing, and DTMF detection) are performed on a media server resource that is being controlled by the bridge software application. A given bridge software application may control multiple media server resources, and a given media resource may be utilized by one or more VSD or bridge software applications. When the VSD transfers the caller, information about the caller and their desired action (i.e. join a specific conference) is included in the transfer request itself. Specifically, the phone number and/or IP address of the caller, the conference passcode, the dialed number and other information is passed in 'cookie' parameters of the SIP REFER command. The use of this mechanism eliminates the need for passing this necessary information between the VSD and the bridge software application through an 'out-of-band' mechanism, while clearly linking the information to that specific caller.

The system may be distributed so that the proxy, media server, conference control ('conference bridge') application, back-office servers and voice services director may be in different locations. This provides a mechanism for switching to alternate resources if a specific resource fails or becomes full or overloaded. If a given media server resource becomes full, a VSD or 'bridge' may make use of additional media servers. For 'bridges', it may also become necessary to link the media of multiple media servers together to expand existing conferences or to allow larger conferences than could normally be handled on a single media server resource. It is also advantageous to link multiple 'bridge' applications together for handling a single conference, with each bridge controlling their own media resource, rather than controlling many media server resources from a single 'bridge' application as this may overload a single instance. In this case, the bridge applications interact at a higher, more abstracted level than the detailed level required to manage a media server resource directly.

The system can also originate calls, referred to as dial-outs, to either PSTN or VoIP endpoints. If the call is being made through a gateway, the SIP INVITE message will contain the destination phone number or contact information.

Brief Description of the Drawings

• FIG. 1 is a block diagram of a VOIP conferencing system in accordance with one embodiment of the invention;
• FIG. 2 is a block diagram of a distributed VOIP conferencing system in accordance with one embodiment of the invention;
• FIG. 3 is a block diagram of a distributed conference using a distributed VOIP conferencing system in accordance with one embodiment of the invention; and
• FIG. 4 is a call flow diagram for a typical PSTN conference participant in accordance with one embodiment of the invention.
• FIG. 5 is a call flow diagram for a typical native VOIP conference participant in accordance with one embodiment of the invention.

Detailed Description of the Drawings

The present invention is a VOIP conferencing system that can readily handle different protocols, load balance resources and deal with fail-over situations. A number of terms are used in the present application that may be unfamiliar. As a result, a list of some of the terms used in the application and a representative definition are provided to help clarify these terms. The definitions should be considered representative but not limiting. Gateway - a device that converts one incoming protocol to a different outgoing protocol. SIP - Session Initiation Protocol defined in IETF RFC 3261: Internet Engineering Task Force - Request For Comment 3261. Proxy Server - A device or application running on a computer that acts a consolidation point of contact. VSD - Voice Services Director. An application running on a computer that interacts with a caller and provides a greeting and authentication. UA - User Agent, which is defined in the IETF RFC 3261: Internet Engineering Task Force - Request For Comment 3261. The User Agent acts as an end or origination point for SIP messages. Media Server - An application running on a computer that mixes various audio signals and other data related messages. Bridge - An application running on a computer that manages media servers and conferences. APS - Advanced Protocol Server. A message router for inter-application messages. DDS - Dialog Database Server. An application server managing conference reservations. ACS - Active Conference Server. An application that maintains the real time conference state, selects media servers, bridges and provides load balancing of available resources.

FIG. 1 is a block diagram of a VOIP conferencing system 10 in accordance with one embodiment of the invention. Any or all of the applications and/or servers in the following description can be single, clustered or load balanced to allow scaling up the system capacity and/or improving system reliability and/or improving system response times. The system has a gateway (GW) 12; this is coupled to a telephone 14, 16 through the PSTN (Public Switched Telephone network) 18. The telephones 14, 16 use a public switched telephone network format. The gateway 12 converts the PSTN format of the call into a control portion, usually SIP (Session Initiation Protocol) or control portion, and a media portion, usually RTP (Real Time Protocol). The gateway connects to a proxy 20 through a network such as the internet, a LAN or a WAN. The proxy 20 passes the SIP information to the VSD (Voice Services Director) 22. The VSD 22 has a back-to-back user agent (UA) 24, 26. One user agent 24 acts as the termination point for the original call, while the other user agent 26 communicates with and controls media server resources 28. The VSD also communicates with back office servers 32 using some back-office communication protocol (BOC), either through the B2BUA (back-to-back user agent) or through another mechanism and/or protocol. The back office 32 has a number of control services including the Advanced Protocol Server (APS) 34, which routes back-office messages, the Dialog Database Server (DDS) 36, which holds conference information and validates user passcodes, and the Active Conference Server (ACS) 38, which tracks information about active conferences. Note that the ACS 38 assigns conferences to various bridges and also load balances between the bridges. Once a media server 28 is designated for a particular conference, the RTP media 40 is routed from the gateway 12 to the media server 28. The media server 28 does the voice (audio, video or real-time data) mixing. Note that each media server may have a number of blades, each further having a number of ports. As a result, a given media server may perform audio mixing for a number of conferences. The media servers 28 are connected to the bridge application (conferencing bridges, or just 'bridges') 44. A bridge 44 performs the control functions for an active conference, including functions like routing, recording and conference creation and destruction. If a user is using a computer 50 or a VoIP hard phone as their telephone they can connect directly to the proxy 20 that then routes the SIP and the RTP portions of the call to the appropriate places. The telephone 50 employs a VoIP connectivity rather than PSTN.

The bridge 44 is SIP-protocol 30 enabled. The SIPShim (a control layer) 52 is an implementation of a B2BUA, allowing the bridge application 44 to interact with the caller and the media server resources through generic higher-level commands rather than dealing directly with SIP protocol and SIP signaling events.

When a PSTN user calls into a conference, the call is routed through a gateway 12, through the proxy 20 and to the VSD 22. The VSD 22 plays a greeting and asks the user for a passcode. Different passcodes may be used to differentiate the conference leader for a given conference, as well as to select a particular conference. These passcodes are validated by the DDS 36 at the request of the VSD 22. Based on the DNIS, ANI, passcode, or any combination of these (customer defining code), a specific greeting may be selected by the VSD, rather than playing a generic greeting. Next, the VSD asks the ACS 38 which bridge 44 the conference is assigned to. The VSD 22 then transfers the caller to the appropriate conferencing bridge, where the caller's media is joined to a conference.

The back-to-back user agents 24, 26 allow the system to handle failures in conferencing resources. The call from the telephone 14 is terminated at the first user agent 24. If a media server 28 stops functioning or gives indication of a pending failure (failure mode), the second user agent 26 is instructed to reroute the call to another media server resource. The back-to-back user agents 24, 26 also allow the system to handle different protocols. The first user agent 24 generally receives SIP protocol information, but the second user agent 26 can use a different protocol if that is convenient. This allows the system 10 to interoperate between resources that use differing protocols.

Note that those systems connected to the SIP/BOC channels can be considered part of the conference control system while those systems connected to the RTP or media data streams can be considered to be part of the data portion of the conference system.

FIG. 2 is a block diagram of a distributed VOIP conferencing system 60 in accordance with one embodiment of the invention. The conferencing system 60 is similar to that shown in FIG. 1 except that this system is distributed and has multiple instances of a system like that of Figure 1. A number of conference centers 62, 64, 66, 68 are located around the country or the world. Each conference center 62, 64, 66, 68 is coupled to a network such as the internet. One or more gateways 70a, b can also be coupled to this network, and VoIP phones or VoIP-based enterprises 80 can tie in to the system. Each conference center would typically have one or more of a proxy 72a-d, a VSD 74a-d, a bridge 76a-d and a media server 78a-d. A software based distributed cache 79a-d or other information-sharing mechanism (such as Back Office 80) is made available to all VSDs(a-d) and provides shared information about the ongoing conferences and the resources that are available. The caches 79a-d shares this information through the network 82. A call may arrive at the proxy 72b in LA 64 and be routed to the VSD 74a in New York 62. The VSD 74a may select the media server 78d in Tokyo 68 and a bridge 76c in Atlanta 66. This allows the proxy 72, VSD 74 and bridge 76c to load balance all available resources across the network 60. In addition, in a fail-over situation the VSD 74a in New York can detect that the bridge 76d in Tokyo is not responding. Under these circumstance, the VSD can redirect the conference to bridge 76c in Atlanta.

FIG. 3 is a block diagram of a distributed conference using a distributed VOIP conferencing system 90 in accordance with one embodiment of the invention. This figure shows how distributed resources may be shared. The system 90 has three media servers 92, 94, 96 that each provide many, perhaps 1000 or more, conferencing port resources. In an open conference the number of participants can be any number up to a maximum number. Assume that a conference 100 starts on media server 92. Five minutes into that conference, only 10 ports are left unused on media server 92 but 20 new people want to join that conference. These people can be allocated to other media servers. For instance, 11 ports 102 can be used in media server 94 and 11 ports 104 can be used in media server 96. Two additional conference ports will be required from the original conference and media server 92 to link the RTP or media to the other two media servers, which each use one media (RTP) linking port in addition to their 10 callers. A single bridge 98 may control all three media servers 92, 94, 96 and the three conferences 100, 102, 104 through SIP 106 or another protocol, even if one or more media servers are located in a remote location relative to the bridge's location. Conference bridge applications may also be linked at a high level, where each bridge 98, 99 controls its own media server resources, and are linked through some form of back-office communications (BOC) which could include SIP. Conference media (RTP) linking is typically initiated from one bridge that acts as a parent, with multiple subordinate or child conferences being instantiated on the other media servers and possibly also on other bridges.

This approach minimizes audio latency by having a common focal point for all child conferences to converge. However, this approach requires more 'linking' ports on the parent conference. Hence, the initial conference may be deprecated to be a child conference, while the second conference is assigned to be the parent (or step-parent), and thus the media for all conferences is linked to the second conference as the focal point. When instantiating the second conference, sufficient ports may be reserved to allow linking further child conferences in the future.

This approach of linking conferences also applies where large numbers of callers are located in different geographical regions, such as Asia and Europe, or possibly on different types of networks such as a combination of standard VoIP network and a proprietary network such as Skype, but these need to be linked together. Rather than having all callers connect to a single location, each region or network could connect to a regional bridge, then the bridges and the media are linked together. This minimizes audio latency for callers in the same region, and may also reduce media transport and/or conversion costs. Each region or network could also use parent and child conferences as needed, and only the two parent (or step-parent) conferences in different regions or networks would have their media linked together.

FIG. 4 is a call flow diagram for a typical PSTN conference participant in accordance with one embodiment of the invention. A gateway (GW) receives an incoming call 300 from the PSTN. The gateway converts the PSTN call into a control (SIP) portion and media (RTP) portion. Figure 4 only shows the SIP portion of the call that is coupled to the gateway; the SIP for the media server is not shown. The RTP is also not shown in Figure 4, as this diagram details the control messaging (SIP) and not the media. The proxy forwards the control portion of the incoming call 302 to a VSD. The VSD answers the call 304, then plays one or more prompts to the caller requesting them to enter a passcode. After the caller enters the necessary information by DTMF, by speaker-independent voice recognition, or by other means, the media for the original call is put on hold 306. Next, the VSD checks with the back-office system to see if the passcode is valid, and if so, the caller is transferred 308 to a bridge as specified by the back-office system. When the caller hangs up 310, the gateway informs the bridge of this event 312 and the call is thereby terminated at both ends.

During the call, the state of the conference and of individual users can be controlled through DTMF by the caller, or from any other mechanism that allows a user to access the bridge directly or indirectly, such as a web-based interface that ties to the bridge through the back office. The bridge will subsequently control the media server(s) in use.

For both the VSD and the conferencing bridge, when the caller presses a digit on his phone the digit press may be passed on as in-band tones within the RTP audio media stream, or may optionally be converted by the gateway to a telephony event signaling protocol that is carried inside the RTP. In either case, the digit press is detected by the media server and reported to the VSD or bridge application. The above describes the basic call flow of typical conference user.

FIGURE 5 shows the identical call flow from Figure 4, but with a native VoIP call origination rather than PSTN. The main difference is that a gateway is not required. Variations of these flows are also needed to handle error conditions that may occur, such as a bridge failing to answer when a caller is transferred to it. These have been omitted for clarity.

Below is a list of SIP commands shown in FIGs. 4 & 5. SIP: Session Initiation Protocol, as defined primarily by IETF Standard RFC3261. SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions such as Internet telephony calls. INVITE: a SIP Request method used to set up (initiate) or modify a SIP-based communication session (referred to as a SIP 'dialog'). SDP: Session Description Protocol. An IETF protocol that defines a text-based message format for describing a multimedia session. Data such as version number, contact information, broadcast times and audio and video encoding types are included in the message. ACK: Acknowledgement. A SIP Request used within the SIP INVITE transaction to finalize the establishment or renegotiation of a SIP session or 'dialog'. 100, 200, 202: SIP Response codes that are sent back to the originator of a SIP request. A response code indicates a specific result for a given request. NOTIFY: a SIP Request method that is used to convey information to one SIP session about the state of another SIP session or 'dialog'. REFER: a SIP Request method that is used to transfer one end of a SIP session to a different SIP destination. Sipfrag: SIP fragment. A fragment of a SIP message (such as a Response code) from another SIP session, that is sent as part of the body of a SIP NOTIFY message. BYE: a SIP Request method that is used to terminate an existing SIP session or 'dialog'.

Thus there has been described a VOIP conferencing system that can easily handle different protocols, load balance media resources and deal with a fail-over situation.

The methods described herein can be implemented as computer-readable instructions stored on a computer-readable storage medium that when executed by a computer will perform the methods described herein.

While the invention has been described in conjunction with specific embodiments thereof, it is evident that many alterations, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description. Accordingly, it is intended to embrace all such alterations, modifications, and variations in the appended claims.

Claims (14)

1. A conferencing system (60), comprising:

   a network;

   a gateway (70a) that is coupled to the public switched telephone network and the network, the gateway (70a) arranged to convert a public switch telephone format into a control data format and a media data format; and

   a plurality of VoIP conferencing centers (62, 64, 68, 66) including respective proxy servers (20, 72a-72d) and bridges (44, 76a-76d) coupled to the network each of the VoIP conferencing centers (62, 64, 68, 66) having a voice services director (22, 74a-74d) for interacting with a caller by providing a greeting and authentication of the caller, the voice services director (22, 74a-74d) having a back-to-back user agent configuration including a first user agent (24) in communication with the respective proxy server (20, 72a-72d) and a second user agent (26) in communication with a media server (28, 78a-78d) the media server (28, 78a-78d) mixing a plurality of media data streams in the media data format,

   wherein a first bridge at a first VoIP conferencing center of the plurality of VoIP conferencing centers (62, 64, 68, 66) is linked with a second bridge from a second VoIP conferencing center of the plurality of VoIP conferencing centers (62, 64, 68, 66), each of the first bridge and the second bridge controlling at least one respective media server.
2. The conferencing system (60) of claim 1, wherein the voice services directors (22, 74a-74d) are adapted to decouple one or more conference handsets (14, 16, 50) from the at least one respective media server (28, 78a-78d).
3. The conferencing system (60) of claim 1, wherein the control data format is coupled to the voice services directors (22, 74a-74d).
4. The conferencing system (60) of claim 1, wherein the bridges (44, 76a-76d) or the voice services directors (22, 74a-74d) are adapted to perform a load balancing routine among the plurality of media servers (28, 78a-78d).
5. The conferencing system (60) of claim 1, wherein the conferencing system (60) further includes a server (80) coupled to the network and/or wherein each of the plurality of VoIP conferencing centers (62, 64, 68, 66) has a software distributed cache (79).
6. The conferencing system (60) of claim 1, wherein each of the plurality of VoIP conferencing centers (62, 64, 68, 66) has a plurality of bridges (76) or wherein each of the plurality of VoIP conferencing centers (62, 64, 68, 66) has a plurality of bridges (76) and each of the plurality of bridges (76) has a back-to-back user agent configuration.
7. The conferencing system (60) of claim 1, herein each of the plurality of VoIP conferencing centers (62, 64, 68, 66) has a plurality of voice service directors (74) or wherein each of the plurality of VoIP conferencing centers (62, 64, 68, 66) has a plurality of voice service directors (74) and each of the plurality of voice service directors (74) has a back-to-back user agent configuration.
8. A method of operating a conferencing system (10, 60), comprising the steps of:

   in a gateway (12, 70a), dividing an incoming channel of a conference call into a first control data stream and a media data stream;

   terminating the first control data stream at a first user agent (24) of a voice services director (22, 74a-74d);

   in the voice services director (22, 74a-74d), originating a second control data stream at a second user agent (26) of the voice services director (22, 74a-74d), wherein the first user agent (24) communicates with a proxy server (20, 72a-72d) coupled to the gateway (12, 70a) and the second user agent (26) communicates with a first media server (28, 78a-78d), the first media server (28, 78a-78d) mixing a plurality of media data streams;

   in the proxy server (20), providing a bridge data stream (30);

   terminating the bridge data stream (30) at a first user agent of a first bridge application (44);

   originating a second bridge data stream at a second user agent of the first bridge application (44) to communicate with the first media server (28, 78a-78d);

   repeating the providing, terminating and originating to integrate a second bridge application; and

   in response to an active conference server (38), linking the first bridge application to the second bridge application with each bridge application controlling at least one respective media server.
9. The method of claim 8, further including the steps of:

   using the gateway (12, 70a) to direct the media stream to the at least one respective media server (28);

   using the voice services director (22, 74a-74d) to direct the second control data stream to the at least one respective media server (28).
10. The method of claim 9, further including the steps of:

    receiving a passcode from the incoming conference call at the voice services director (22);

    checking if the passcode is valid with a dialog database server (36).
11. The method of claim 10, further including the steps of:

    when the passcode is valid, using the voice services director (22, 74a-74d) to redirect the first control data stream to the first user agent of the first bridge application (44); and

    using an active conference server (38) to connect a second user agent of the first bridge application (44) to the first media server (28).
12. The method of claim 11, further comprising the step of:

    using the first user agent and the second user agent to communicate between bridge applications at a more abstracted level than the detailed level required to manage a media server directly.
13. The method of claim 9, further comprising the step of:

    in an active conference server (38), determining if one of the media servers (28) is in a failure mode; and

    when one of the media servers (28) is in the failure mode, rerouting the second control data stream to another media server.
14. The method of claim 8, further comprising the step of:

    in the voice services director (22, 74a-74d), playing a specific greeting, based on a customer defined code.