AEQ PHOENIX MERCURY USER’S MANUAL ED. 07/14 V. 1.0 - 21/07/2014 Firmware Versions: Software Version: CPU 4.10 / DSP 3.11 or higher AEQ ControlPHOENIX 2.1.0.
CONTENTS 1. INTRODUCTION....................................................................................................................... 4 1.1. General description............................................................................................................ 4 1.2. Functional specifications.................................................................................................... 4 1.3. Available encoding modes. ...................................................................
5. CONTROL TERMINAL OVER WEB BROWSER. ................................................................. 35 5.1. Upgrading the equipment firmware.................................................................................. 35 5.2. Configuring the MAC address associated with the Ethernet interface. ........................... 36 5.3. Technical Assistance Service and On-line manuals........................................................ 37 5.4. Saving and loading configurations...........................
1. INTRODUCTION. 1.1. General description. El AEQ PHOENIX MERCURY STUDIO is a multiformat, multi-algorithm audiocodec designed for stationary rack-mounted applications, like links between MERCURYs for STL or mobile equipment connections. It´s a stereo device, so the unit houses a stereo codec with a stereo analog input and output, features digital AES/EBU input and output as an option.
1.3. Available encoding modes. We recommend consulting ANNEXE A to see a detailed description, as well as additional information on these encoding modes. • • • • • • • * ** G.711 A-Law or µ-Law mono G.
2. PHYSICAL DESCRIPTION OF THE UNIT. To understand how the PHOENIX MERCURY unit is wired and installed, you will first need to familiarize yourself with the connectors and other configurable elements that are present on the front and rear panels of the device. 2.1. Description of the front panel. There are five indications concerning the communication status. From right to left: - SYNC LED: indicates the status of the audio connection. • Off: no connection is established.
2.2. Description of the rear panel and connections. A B C D 2.2.1. Analog line stereo input. E F G A XLR - 3p female connector. Balanced connection. Two connectors for L+R or independent mono channels (the left connector corresponds to L input and the right one corresponds to R input). XLR 3p Female-panel Pinout Pin 1 Æ Ground Pin 2 Æ + Input Pin 3 Æ - Input 2.2.2. Analog line stereo output. B XLR - 3p male connector. Balanced connection.
DB15 connector pinout identification - Pin 1: AES_IN+ - Pin 2: N/A - Pin 3: N/A - Pin 4: AES_OUT- Pin 5: N/A - Pin 6: N/A - Pin 7: N/A - Pin 8: GND - Pin 9: AES_IN- Pin 10: N/A - Pin 11: AES_OUT+ - Pin 12: N/A - Pin 13: N/A - Pin 14: N/A - Pin 15: N/A Considerations: - The inputs and outputs are compliant with the AES-3 standard, both for audio and for synchronization / signalling. 2.2.4. AUX DATA connector (+ IP Reset).
Physically, the connector is RJ45 10/100 BT, with the following pinout. RJ45 connector pinout 2.2.6. USB Port. F The USB port can be configured as Master or Slave. By default, it leaves the factory configured as Slave. This port can be connected to a USB port in a PC, permitting a data transmission speed of up to 480Mbps (USB 2.0), just for equipment maintenance purposes. IMPORTANT NOTE: Do not use this connector for any reason without the supervision of AEQ technical service personnel. 2.2.7.
3. CONFIGURATION AND OPERATION OPTIONS DESCRIPTION. Configuration and operation of Phoenix MERCURY is carried out by means of the application “AEQ ControlPHOENIX“ (AEQ Phoenix STUDIO, MERCURY and VENUS Audiocodecs Configuration and Control Software). The version that is provided together with the equipment can control only one unit per software instance.
We can find “CALL” and ”ON AIR” buttons/indicators at the right, as well as the “SYNC” indicator and audio presence indicators for both directions: transmission (“Tx”) and reception (“Rx”). At the right side, “CONFIG” button gives access to a menu with the following options: “General“, “Contacts“, “Ethernet“, “Miscellaneous“ and “Network“. Just click on “CONFIG“ button again in order to close this menu.
3.2. IP interface connection modes. In order to establish an IP communication, first we need to choose one among three available connection modes within the “INTERFACE” drop-down menu: “PROXY SIP”, “DIRECT SIP” and “RTP Point to Point (RAW)”. We can access the IP configuration submenu by clicking on “I/F Setup”. This menu is described in sections 6.1.4.2 and 6.1.4.3 of “AEQ ControlPHOENIX” user’s manual. It is important to know the details of each type of connection, so they are explained below. 3.2.1.
- Proxy Provider: enables you to select the external SIP server with which the unit will work from a previously stored list. By default, AEQ server will be selected. Authentication: enables you to edit the password and security information for the user profile associated with the unit in the previously selected SIP server. By default, the data configured in this field in order to use AEQ server are the following: o User: the “User Name” configured in Factory, “phxme_231” for instance.
When you create a Call Book, these fields describing a contact can be modified in the Call Book that can be accessed from a codec individual control window through the “Contacts” option in “Configuration”(see section 5.1.7 of “AEQ ControlPHOENIX” user’s manual). In order to call a same contact using different IP modes (as defined in “INTERFACE“ drop-down menu), different contact entries must be created.
3.2.3. RTP Point to Point (RAW). This type of connection is selected when the connection over IP will be an RTP type link with calling of the IP address to IP address type. Obviously there is no advanced signaling protocol in this scenario and you will need to established, set parameters and disconnect communication from both ends. Audio encoding must be the same (and explicitly specified) in both ends of the communication.
b) Multicast: it is also possible to send the audio stream to a special “multicast” address, for example, 239.255.20.8. If the receiving equipments call to that same IP, they will receive the audio that is being sent provided that their “local media port” matches the one the transmitter is sending the packets to. Similarly to broadcast, multicast traffic is usually blocked by switches and routers, so its use is restricted to local area networks too.
3.3. NAT TRAVERSAL. NAT Traversal is a set of tools used by the equipment in order to surpass the NAT (Network Address Translation) performed by some routers. We can select among several modes depending on the kind of network the unit is connected to. Phoenix MERCURY offers a total of six different operating modes when traversing devices with NAT (routers, firewalls…). Each one of those modes is suitable for a different scenario.
1. SIP LOCAL IP: read-only parameter that tells you the IP of the IP interface of the unit as regards SIP, so that the latter can, in turn, convey this to the router or firewall administrator when it is configured. For instance 172.26.33.35. It can be set in order to adapt it to network necessities in menu: “Configuration” Æ ”Ethernet”. 2.
7. RTP PUBLIC IP: parameter that will tell the unit which public IP will correspond to the RTP of its IP interface, so that it can send the said IP in its SIP messages. The router or firewall administrator must tell you the value of this parameter. Usually the administrator will take out SIP traffic and RTP using the same public IP configure in point number 3. For instance 212.170.180.177 8.
• • • • LOWEST: generates a 40% higher binary rate and produces a 575ms additional delay. LOW: generates a 50% higher binary rate and produces a 375ms additional delay. MIDDLE: generates a 66% higher binary rate and produces 225ms additional delay. HIGH: doubles the binary rate producing 125 ms additional delay. - Adaptive/Fixed: you can set up the reception buffer as adaptive or fixed. In the first case, its size will vary according to the network transmission quality.
However, when the interface is set up to work in any of the SIP modes, particular coding algorithms won’t be selected and connection “profiles” will be defined instead, containing one or more modes. This is like that because SIP allows the participants in a communication to negotiate the coding algorithm, so the one to be finally used will be limited to the list the caller presents.
The parameters to be configured are: - - Enable DHCP: enables the activation or deactivation of the automatic configuration of IP addresses, masks and gateways. There must be a DHCP server in the network the unit is connected to in order to make this option work. When “Enable DHCP” is validated, the following parameters will be filled automatically; when “Enable DHCP” is not validated you will be able to change them manually. IP Address: valid IP address associated with that interface.
3.8. SNMP configuration. This unit can be remotely managed using SNMP (Simple Network Management Protocol) using one of the many client pieces of software available in the market, even for free. SNMP allows monitoring of the status of several pieces of equipment from very diverse manufacturers and natures, as well as elaborating reports, generate e-mail alerts, etc. You can access the configuration menu in “Configuration“ Æ “Network”.
- phxCh1TxAudioThreshold (Audio threshold for channel 1's input) phxCh1TxAudioInterval (Audio interval for channel 1's input) phxCh1RxAudioThreshold (Audio threshold for channel 1's output) phxCh1RxAudioInterval (Audio interval for channel 1's output) 3.
4. QUICKSTART USER’S GUIDE. To gain a complete grasp of the PHOENIX MERCURY, we recommend reading the previous chapters and “AEQ ControlPHOENIX” user’s manual carefully. The paragraphs below describe the basic actions you will need to take to operate the equipment. If you need more detail, review the information given in the previous sections of this manual. 4.1. Equipment connections. 4.1.1. Power supply. The external 12V power supply connector is located at the back panel of the unit. 4.1.2.
4.4. Audio. Section 2.2 of this manual describes in detail the physical connections at the back panel of the unit, but the procedure would be, in a nutshell, as follows: • • • • Connect the audio line inputs in analog or digital format according to the description of the connectors at the back panel of Phoenix MERCURY. XLR connectors for analog inputs and optional DB15 connector for digital inputs.
The same screen allows you to configure the type and size of the receiving buffer and FEC parameters as a function of the IP network quality so we have the shortest delay while audio cuts are minimized or eliminated in poor quality networks (see paragraph 3.4 of this manual in order to select the optimal buffer configuration depending on your application).
• • • • • You can monitor the status of the call on the screen: o CALLING. o CONNECTING (depending on the communication interface and the network status, this may be a status of extremely brief duration). o SYNCHRONIZING (depending on the communication interface and the network status, this may be a status of extremely brief duration). o CONNECTED. Verify that the “SYNC“ LED beneath the “CALL“ button is lighted in green to indicate that the communication has been successfully established.
Check the SIP server configuration (“Proxy Provider”). Select one that is already configured from the list, for example the default “AEQ”, or otherwise go to ”Manage Providers”, create a “New provider” and fill in the following fields: name, port, address of the server (either its IP or URL) and, if necessary, check the “Register” field.
• Enter the IP address of the remote unit, either manually or getting it from the buttons: By clicking here, the last URI “Calls”, the URIs in the “Equipment Contacts” book or the available “IP” addresses are shown respectively, but only those with formats compatible with channel and communication type.
4.5.2.2. Receiving and accepting an IP communication in PROXY SIP mode. If the IP interface is correctly configured and automatic answer mode is OFF, when you receive a call: • • • • • • • • • The unit and the application will provide acoustic warning. This can be disabled (for the unit) at “Configuration“ Æ “Miscellaneous“ Æ “Buzzer and test“.
• Enter “I/F Setup“ and click on “SIP Parameters”. Check that the “User Name” and “Display name” are configured. User name and IP address constitute the equipment’s required connection information. • Select the working mode to traverse NAT devices (“NAT Traversal”) that is more adequate for the network the unit is connected to. NOTE: It is recommended that you follow Application Notes 0-A or 0-C, according to the type of equipment’s connection.
Enter the IP address of the remote unit, either manually or getting it from the buttons: By clicking here, the last URI “Calls”, the URIs in the “Equipment Contacts” book or the available “IP” addresses are shown respectively, but only those with formats compatible with channel and communication type. • It is mandatory that the called unit URI is specified in any of the following formats, adequate for Direct SIP communications: “@” (for example: “phxme_231@172.26.
4.5.3.2. Receiving and accepting an IP communication in DIRECT SIP mode. If the IP interface is correctly configured and automatic answer mode is OFF, when you receive a call: • • • • • • • • • The unit and the application will provide acoustic warning. This can be disabled (for the unit) at “Configuration“ Æ “Miscellaneous“ Æ “Buzzer and test“.
5. CONTROL TERMINAL OVER WEB BROWSER. The Phoenix MERCURY includes a WebServer that enables you to execute numerous functions remotely over the Ethernet interface included in the back panel of the unit; with the aid of a standard web browser (compatibility is guaranteed with Internet Explorer running on Microsoft Windows operating system). 5.1. Upgrading the equipment firmware. The unit PHOENIX MERCURY is supplied from the factory with the latest firmware versions available.
4. To upgrade the codec, click on the UPGRADE option. 5. A user ID and password are requested (by default, both are aeq). After you have correctly entered these two items, the firmware upgrading screen will be displayed. 6. Check to see whether the versions displayed are the same as the firmware that is currently in effect. If they do not match, upgrade the firmware as indicated below. 7. Select the module you want to upgrade in “Upgrade” column.
5. 6. 7. 8. Modify the value in the MAC field associated with the Ethernet interface. Press the “Apply” button. Wait for on-screen confirmation that the operation has been successfully completed. In the Internet browser, go to the MAINTENANCE section and ensure that the MAC address is now the correct one. 9. Power the unit down. 5.3. Technical Assistance Service and On-line manuals.
5.5. Status menu. By means of IP Status menu you can monitor some statistical parameters regarding the connection status of IP channels. Some of this parameters are: transmission and reception buffers status, Jitter, lost packets… 5.6. SNMP. This unit can be remotely managed using SNMP (Simple Network Management Protocol) using one of the many client pieces of software available in the market, even for free.
6. TECHNICAL SPECIFICATIONS* Audio Inputs and Outputs Analog line input 2 x XLR female. 9Kohm. Electronic balancing. Line level. DB15 connector. AES/EBU interface (accepts any sampling rate between 24 and 192KHz). 2 x XLR male. Output impedance < 100 ohm. Electronic balancing. Line level. AES/EBU audio output through DB15 connector. Output sampling frecuency of 48KHz.
7. A.E.Q. WARRANTY. AEQ warrants that this product has been designed and manufactured under a certified Quality Assurance System. AEQ therefore warrants that the necessary test protocols to assure the proper operation and the specified technical characteristics of the product have been followed and accomplished. This includes that the general protocols for design and production and the particular ones for this product are conveniently documented. 1.
ANNEXE A: General characteristics of encoding modes. G.711: ITU encoding standard for processing audio signals in the human voice frequency band, through the compression of digital audio samples obtained at 8KHz, and typically used in telephone systems. Bandwidth: 3.5 KHz For further information on this subject, consult: http://www.itu.int/rec/T-REC-G.711/e G.
ANNEXE B: List of available coding algorithms in Phoenix MERCURY. CODEC G.711 Ley A G.711 Ley µ G.722 AEQ-LD MPEG-1 Layer II MPEG-2 Layer II RATE (Kbps) 64 64 64 64 128 128 192 256 384 64 128 192 256 384 64 128 32 64 AAC-LC 96 128 192 AAC-LD PCM 256 32 64 96 128 192 256 <768 <1152 <1024 <1536 <1280 <2M <1536 <2.
ANNEXE C: Protocols associated with communications over IP networks. Communication over IP networks differs notably from the communications traditionally used to date in broadcast environments, whether they are POTS or ISDN, in that IP networks do not have dedicated resources or qualities of service implemented in most systems, with the associated problems this involves in terms of communication signaling, establishment, maintenance and cleardown.
• • The circuit is fixed. Because a physical circuit is specifically dedicated to the communication session in question, once the circuit is established there are no losses of time for calculation and decision-making regarding routing through the intermediate nodes. Each intermediate node has a single route for the incoming and outgoing packets that belong to a specific session, which means it is impossible for the packets to be disordered. Simplicity in the management of intermediate nodes.
C1.2.3. Disadvantages: • • • • Greater complexity of the intermediate switching devices, which need to have higher speed and greater calculating capacity to determine the appropriate route for each packet. Packet duplication. If a packet takes too long to reach its destination, the receiving device may conclude that it has been lost, in which case it will send a packet retransmission request to the sender, which gives rise to the arrival of duplicate packets.
C2.1. IP addresses. An IP address is a number that logically and hierarchically identifies an interface of a device in a network that uses the IP protocol. The format used is X.X.X.X, where each X represents a group of eight bits translated into decimal form—that is, whose minimum value is 0.0.0.0 and whose maximum value is 255.255.255.255. IP addresses are classified in two major groups: static and dynamic. • It is typical for a user to connect to the Internet from his or her home using an IP address.
C3. RTP Protocol. RTP are the initials of Real-time Transport Protocol. It is a transport level protocol used for the transmission of information in real time, as occurs with audio and video. Normally it is paired with RTCP (RTP Control Protocol) and is located on UDP. The IP ports defined for its use are 5004 (RTP) and 5005 (RTCP). The functions of the RTP/RTCP protocol are: • • • Management of the reception buffer in order to minimize the jitter effect introduced by the network.
One of the objectives of SIP was to contribute a set of processing functions to apply to calls and capacities present in the public switched telephone network. Thus, it implemented typical functions that a common telephone terminal offers, such as: calling a number, making a telephone ring when called, hearing a dial tone or busy tone. The implementation and terminology in SIP are different. SIP requires proxy servers and register elements to give a practical service.
SIP protocol operation diagram. Phase 1: Registration. Phase 2: Search for the called device in the SIP server database. Phase 3: Establishment of the connection This working method, supported by external SIP servers, enables the physical position of a device to be made independent from its logic identifier and, through the use of the SIP protocol, makes it unnecessary to know more data regarding the called device than its URI.
• • • Static public IP addresses offer the ideal situation, since they guarantee that the IP interface of the codec will always be assigned to a fixed address (regardless of whether it is turned off and then powered up again) and directly accessible to the rest of the network users.
PHOENIX MERCURY includes a STUN client that sends a request to a STUN server. The STUN server then informs the client of its public IP and which port has been opened by NAT to permit incoming traffic to enter the client’s network. This information enables the PHOENIX MERCURY to identify its position within the SIP server. This protocol is used in “AUTO3” and “AUTO4” NAT TRAVERSAL modes (see section 3.1.5.2.4).
The response further enables the STUN client to determine the type of NAT being used, since different NAT types handle incoming UDP packets in different ways. STUN supports three of the four main existing types of NAT: Full Cone, Restricted Cone and Port Restricted Cone. It does not, however, support Symmetric NAT, also known as bidirectional NAT, although PHOENIX MERCURY allows it to be detected and reports its presence to the user.
ANNEXE D: Ports used by PHOENIX equipment. When Phoenix unit is installed in a private IP network and you want to establish communication with other units through that network router+firewall (gateway), three indications related to the ports used by the unit must be taken into account: 1 - Output permissions in router+firewall: Phoenix unit will send packets to different servers and/or other units (each one will use a different port).
ANNEXE E: Application notes guide. This index tries to give users guidance on selecting the most advisable application note in order to connect two audiocodecs of Phoenix family, depending on its requirements and working environment. Each application note describes the way to configure each of the audiocodecs. When both ends are different (for instance, at one end there’s a Phoenix Mobile and at the other end a Phoenix MERCURY), different application notes should be followed in order to configure each one.
ANNEXE F: Additional information. NOTE: This equipment complies with the limits for a Class A digital device, pursuant to part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications.