Frequently Asked Questions

The overall bandwidth requirements can easily be configured. A variety of coding profiles allow precise control over bandwidth and voice quality in a distributed network environment. The parameters include the CODEC (industry standard G.722, G.711, G.723, G.726 and G.729), the jitter buffer and the amount of audio that is stuffed into packets. This provides the administrator the ability to control the IP payload over a range of 10 Kbps to 100 Kbps per active talking channel. Additionally, silence suppression can be used to further reduce IP payload by not sending out empty packets when audio falls below a prescribed threshold.

Download Coding Profiles

Voice over IP (VoIP) was designed to provide telephony facilities over IP, stemming from the initial desire to cut international and long distance call charges. Intercom over IP (IoIP) also uses IP networks but has been adapted to provide intercom-style functionality to provide immediate, multi-channel communications. The multi-channel aspects of the Mercury platform make highly dynamic and group communications much more efficient. Like VOIP, IoIP also provides the ability to significantly reduce the cost of global communications.

Realizing that VOIP is an important communications technology deployed in many organizations, Mercury is fully compatible with SIP-standard VOIP platforms via a software-only solution. H323 compatibility will be added in soon.

The Mercury system uses the following standards:

• IP, TCP & UDP for signaling, control and IP audio
• RTP (RFC3550 with the addition of a 6 byte header as a Protocol Descriptor Unit) for voice packets
• RLL (Reliable Link Layer) provides a reliable signaling message transfer using a sliding window protocol
• IGMPv3 for multicast conferences
• IEEE 802.1P prioritized packet switching is adjustable on a per host basis
• IEEE 802.1Q VLAN 12-bit identifier can be inserted on a per host basis
• RFC2474 Differentiated Services allows setting Standardized DSCP on a per host basis
• HTTP – Browser panel and web server; RS422 for Hardware Panels
• IPv6 will become available as a software upgrade.

This list contains all the TCP/IP functions that can be used by the Mercury system. The specified port numbers are the factory defaults (the port numbers can be changed by the administrator):

• UDP 2076 control & signaling
• UDP 2077 voice packets
• UDP 2078 signaling when using FXO, FXS or E&M telephone interfaces
• UDP 2079 voice packets when using FXO, FXS or E&M telephone interfaces
• TCP 12005 management database data port
• TCP 12006 management database control port
• TCP 13001 management database supervisor port
• TCP 6822 Virtual Panel to host connection
• TCP 80 Browser Panel to host connection

Basically, two ports that must be open for each Mercury device to operate: UDP 2076 & UDP 2077. The others ports are available to support application specific features that vary with customer requirements.

Yes. However, Mercury uses .xml files extensively. As most antivirus programs consume extensive CPU usage in scanning these files, we recommend that Mercury directories with .xml files be excluded from scanning by the antivirus software.

Windows
The Mercury application software relies on Windows as an OS. The Mercury Interface Unit (MIU) includes a licensed copy of Windows and is intended to be used as an appliance. The MIU is not intended to support users as a generic work station. The OS build has been locked down to support Mercury functionality and to provide security.

Nucleus
There is an embedded OS that runs on the Power PC of each Mercury host. Each Mercury host includes Nucleus and is licensed by Accelerated Technology, Inc. This provides the CPU processing for API-controlled multi-channel audio processing and mixing. This includes the network stack that supports IP audio.

The TBC (Talk Back Controller) is the host application that is the heart of the Mercury system. It can run as a service or as an application on the host Windows machine. The TBC performs the following functions:

1. Manages the peer-to-peer socket connections between Mercury hosts
2. Acts as the decision-making engine to set-up and tear-down IP audio routes and local audio crosspoints
3. Acts as the interface to the host Mercury hardware
4. Implements conditional routing rules. These allow the administrator to establish and enforce business rules appropriate to supporting the workflow requirements of operators and to control external devices (e.g. PTT and COR radio connections, PTT mic switches, etc.)
5. Communicates with the Mercury Hardware Panels that are connected to a Mercury system
6. Accepts the socket connection and communicates with Mercury Virtual Panels or 3rd-party control surfaces (API & SDK available upon request)
7. Sends status information to other TBCs and Mercury operator panels
8. Accepts the socket connection and communicates with the db supervisor for system management

Administration of the Mercury system is performed by an Administrator or group of Administrators using the Configuration and Editing software. The application can be securely installed and run on a Windows PC or multiple PCs. The PCs can be operated on or off line from the network. The application is a comprehensive tool kit that provides the Administrator with tools to manage Mercury system parameters and IP settings. It allows the creation and management of files that can be used to update and configure the Mercury devices on the network. These files can be synchronized with a network database server or servers to transmit any changes to the Mercury system devices.

Each Mercury host, once notified that there is new data available, connects to the database and sends queries through the encrypted socket connection to get the required data. This data is then written out to a local cache. By this method, audio applications always have a local copy of the database available whether the supervisor/database server is present or not.

The database server provides a networked resource to allow administration and management of all the Mercury devices on the network. This server is only needed at times when it is desirable to perform system wide configuration changes. Typically, this occurs at deployment and periodically when configuration changes are called for. It is not required to have this server available all the time.

The database application is DBISAM and is licensed by Elevate Software. Database connections and transactions are secured by password and user name. These are hard coded as part of the connection string. The served db protocol is encrypted. The DBISAM database encryption uses the Blowfish symmetric block cipher encryption algorithm along with the RSA Data Security, Inc. MD5 message-digest algorithm for encrypting tables and remote session requests and responses to and from a database server.

There is a middle tier application (Database Supervisor) that runs on the database server that communicates directly with the database and serves data to connected clients. Peer-to-peer Mercury devices connect to this application on a single socket connection to exchange encrypted data.

If slave databases are used, the Master Database Supervisor will take all the database files and add them to a standard ZIP file. This file is transferred over the supervisor socket connection. This data can be encrypted if required. Once the slave database has the data it then unzips it and serves it to it's locally connected mercury hosts as if it was a master database.

Normal run time communications between Mercury devices use peer-to-peer socket IP connections. Communicating securely between separate network enclaves may not be permissable using IP. A secure alternative is to use two MIUs as analog gateways between IP networks. The two units can be configured to have analog audio tie lines between them as a method of exchanging voice communications between the two networks.

General Purpose Interface (GPI) can be used to send on/off logic statements between the networks by means of contact closures (TTL, opto-isolators and open collectors). These on/off logic statements can be used to support call negotiation and status. This enables users on each network to establish calls and accept calls between networks without any IP connectivity.

Because of the sensitive nature of this topic not all details are included in this response. Please inquire for additional information.

• Mercury Panels of All Types (Virtual and Hardware)
• Many legacy intercom platforms
• Radios
• PSTN and Analog Phones
• Cellular Phones
• Call Center Hybrid PBXs
• IP Voice Logger and Playback Systems
• VOIP Servers, Phones (SIP) and SIP-Standard Technologies
• Wireless Base Stations
• TV, Multimedia and PA Feeds
• Headset Junction Boxes

Download Interoperability Diagram

Customers have connected dozens of radio types to the Mercury system over the years including those designed for consumers, public safety and military use. In fact, we have not encountered a radio that could not be interconnected to the Mercury Interface Unit via a Radio Interface Board!

The default location for Mercury files is C:\Program Files\Trilogy\Mercury. However, Windows 2003 Server when securely locked down will set permissions to not allow users full access to files in C:\Program Files directory. The Mercury applications uses ini and XML files within this folder to which they need to read and write. If using a server locked down in this fashion we recommend changing the installation location to C:\Trilogy\Mercury. After installation is complete, change the security settings of C:\Trilogy to allow users of Mercury full control of this folder.

Yes. Mercury applications do not work with hardware Data Execution Prevention (DEP) in both Windows XP and Windows Server 2003 (and 2003 R2). We have also observed that in some cases software DEP on Server 2003 (and 2003 R2) prevents Mercury applications from running.

If you have turned on DEP for more than essential Windows programs and services, add Mercury applications to the exceptions list in the Advanced System Properties settings.

Jumper J14, located on the power board just outside of the power supply metal frame, enables or disables the automatic power on feature of the Mercury Interface Unit. All Mercury Interface Units are shipped from the factory with the automatic power-on feature enabled.