In fast paced communications environments, many parties to a conference, for example, a teleconference may need to be connected. The origination or type of each participant's connection may be dissimilar to other participants' calls and thus the audio signal quality for each party may differ. Some solutions include using a software-based audio mixer to process the different audio streams. In some teleconferencing environments, the number and size of teleconferences happening simultaneously may present a challenge in determining which audio mixers may be best suited to process any given teleconference.
As may be seen, there is a need for a system that selects the optimal mixer for a conference.
In one aspect of the present invention, a system comprises a plurality of terminals adapted for conferencing; and a controller coupled with at least one of the plurality of terminals, the controller configured to: send a query to a plurality of data stream signal mixers in the system to obtain information corresponding to signal mixing capacity for a conference, receive the information from the plurality of signal mixers, and select, based on a current signal mixing capacity of a respective signal mixer of the plurality of signal mixers, an optimal one of the plurality of signal mixers for use in mixing data streamed in the conference.
In another aspect of the present invention, a computer program product for selecting an audio signal mixer for a voice conference between terminals, the computer program product comprising a non-transitory computer readable storage medium having program code embodied therewith, the program code readable/executable by a processing device to: identify available signal mixers in a network; identify resource requirements of the conference; query the available signal mixers for signal mixing capacity; determine from responses provided by the signal mixers, which of the available signal mixers has an optimal capacity for providing signal mixing of the conference under the identified resource requirements; and select the signal mixer of the available signal mixers with the optimal capacity to provide signal mixing of the conference.
These and other features, aspects and advantages of the present invention will become better understood with reference to the following drawings, description and claims.
The following detailed description is of the best currently contemplated modes of carrying out exemplary embodiments of the invention. The description is not to be taken in a limiting sense, but is made merely for the purpose of illustrating the general principles of the invention, since the scope of the invention is best defined by the appended claims.
Broadly, an embodiment of the present invention generally provides a mechanism for dynamically selecting optimal conferencing data stream component(s). Conference related data streams may include, for example, audio, video, text, or file related data that may be transmitted in communication between endpoints of a meeting conference. Embodiments of the invention may be beneficial to applications such as a commodity trading room or a command and control environment. In exemplary embodiments, conferencing units or data stream mixers (referred to in general as mixers) may be selected to maximize, for example, voice quality, video quality, availability and up-time of teleconferences. The mixers may be part of a standalone conferencing system, part of a more specific Voice over IP (VoIP) solution such as an Adaptive Trading Platform (ATP), or part of a similar trading room or command and control voice platform. Some exemplary embodiments may use or take the form of computer readable media. The computer readable media may be stored on non-transitory media and may be read and/or executed by a processing device.
An optimal mixer(s) selection process may happen when, for example, a call or video meeting is first initiated, is restored, or during an existing call or meeting when an additional (or replacement) mixer is required for the conference. Call restoration may happen when one or more participants in a conference are temporarily disconnected and subsequently re-established. The need for an additional mixer may happen when a mixer fails or the capacity of an existing mixer is approaching a limit.
According to some exemplary embodiments, the mixers may be used in environments including a voice recording server, a voice gateway, a hardware based phone or turret (sometimes called a terminal), a software based phone or turret, an audio mixing component, and phone or turret download profiles, for example. Voice streams may originate from internal sources such as turrets (physical and virtual), phone handsets, mobile devices, automated systems such as interactive voice response (IVR) technology or sound sources music on hold (MOH), tone generators etc., gateways connected to external public switched telephone network (PSTN) gateways (using such protocols as T1, E1, PRI, BRI or analog), or to session boundary controllers (SBCs) connecting to remote voice networks. Mixers under some embodiments may use a proprietary protocol, SIP protocol, or Industry Standard H.323 protocol to setup calls, though other similar VoIP (Spell out) protocols such as IAX2 may be used.
Referring now to
In an exemplary embodiment, one or more conference mixers 125a-125f and 125x (referred to in general as mixer(s) 125) may provide data stream mixing (for example of audio signals or other multimedia type signal) to participants of a conference meeting communicating through electronic means (for example, via a teleconference or videoconference). Participants in the meeting may communicate via terminals 120 (shown as terminals 120a-120d) (sometimes referred to as “turrets” for example, as may be used in a trading room environment) connected to one or more of the mixers 125. In some embodiments, the terminals 120 may be connected together in a peer-to-peer fashion. Thus, control signals may be sent directly from and received directly by each of the terminals 120 participating in the meeting.
When bringing a terminal 120 into the system 100, the terminal 120 may be connected to a configuration server 130. The configuration server 130 may store computer readable programs and data, and computer executable instructions which may be loaded into the terminal 120 allowing it to communicate with other terminals 120. In some embodiments, the system 100 may include a morning call server 135, for example, in applications where the system 100 is used for large scale conferencing for trading. The morning call server 135 may employ both a two-way transmission and a one-way broadcast or multi-cast transmission of audio data to the terminals 120.
In some embodiments, the system 100 may include virtualized terminals 140. The virtualized terminals 140 may be software applications run on an electronic platform that is not a dedicated terminal 120. For example, the virtualized terminals 140 may be programs run on a PC, a mobile phone, a tablet or other computing device with a user interface. The terminals 120 may be configured to communicate with the virtualized terminals 140 as though the virtualized terminals 140 were terminals 120.
The selection of which of the mixer(s) 125 to use for a teleconference is described in further detail in the following.
In
Referring to
During initiation of the teleconference or to bring a party into an existing call, one of the terminals 120, for example, 120c may send out a query to one or more mixers 125 to determine which mixer 125 may be optimal for providing audio mixing of the teleconference. For example, queries may be sent to mixers 125c, 125b, 125f, and 125x. As shown, the query to mixer 125x may involve more than one query to the mixers in the mixer farm.
Referring to
Referring in general to
Available ones of mixers 125 may be identified by maintaining a map of mixers 125 that are running and are available for use. This may be stored either centrally or in a distributed architecture where each endpoint (for example, the terminals 120, servers 150, etc.) that uses mixers 125 may store the map after periodic updating of the full mixer topology and capacity availability from either or both of distributed and centralized sources.
In some embodiments, the one of mixer(s) 125 may conference or mix anywhere from two to many hundreds of voice streams simultaneously. In addition, the one of mixers 125 may need to stream extra RTP streams to IP voice loggers. One of the mixers 125 may run acoustic echo cancellation and deal with other audio processing work such as wide bandwidth CODEC's, compression, volume control, and muting, for example.
In some embodiments, multiple mixers 125 may be used for a teleconference to provide a failsafe mechanism to one of the mixer(s) 125 failing during a call. In embodiments with redundant mixers 125 being used, the selection of mixers 125 for a call may be based on which mixers 125 provide the most redundant combination when paired together for the teleconference.
The determination of mixing capacity on one of the mixers 125 may be calculated by checking current available resource capacity (particularly, but not exclusively compute capacity) on one of the mixers 125 and comparing the mixer capacity to the resource requirements of the teleconference. The resource requirement may be determined by evaluating the expected size and complexity of the audio signal mix for the teleconference (for example, evaluating the number of voice streams in and out of the teleconference, Codecs used, compression used, security, encryption and any other resource intensive function to be performed). The choice of which of mixers 125 to be used may be made based on which mixers 125 are best able to perform under the requirements with less signal latency and bandwidth consumed. In some embodiments, one of the mixers 125 may be selected based on being able to provide the best network connectivity for the media flows that will be used during the teleconference.
The mixer(s) 125 may use two or more redundant network connections, which may also use different Ethernet (or other network architecture) devices for interfacing to the VoIP network to further improve reliability, and there may be enough DSP power to support conferencing, echo cancellation, compression, and wideband CODEC's.
The mixers 125 may also run concurrently (i.e. on the same hardware or virtual platform) with gateway, turret, phone, voice recording or other functions.
Referring now to
One or more mixers 125 may be in communication with the terminal 120. The mixer 125 may be entirely software operating as a set of mixer instructions 128 in and/or between terminals 120 in the system 100. The set of mixer instructions 128 are shown as part of the mixer 125 however it will be understood that the set of instructions 128 may be resident within the controller 121 of respective terminals 120 in communication with each other. In an exemplary embodiment, the system 100 may include multiple mixers 125 available for any given teleconference convening within the system 100.
It should be understood, of course, that the foregoing relates to exemplary embodiments of the invention and that modifications may be made without departing from the spirit and scope of the invention as set forth in the following claims.
This application claims benefit under 35 U.S.C. §119(e) of U.S. Provisional Application having No. 61/656,897 filed Jun. 7, 2012, which is hereby incorporated by reference herein in its entirety.
Number | Date | Country | |
---|---|---|---|
61656897 | Jun 2012 | US |