Network Parameters
UCX Server is a network device that will be connected to your local area network (LAN). You must select a fully qualified domain name (FQDN) for this device and an IP address that will be used by the device. You should also prepare network configuration parameters that will be used for the configuration of the UCX Server’s network adapter.
The WAN port (Ethernet 0) has the standard UCX software default address of 192.168.1.200, while the LAN port (Ethernet 1) has a default address of 192.168.10.200.
The following table provides a list of network configuration parameters that you should prepare:
| Parameter | Default Value | Selected Value |
|---|---|---|
| Host name | localhost.localdomain | ___________________________ (FQDN) |
| IP address type | Static | Static / DHCP |
| Static IP address | 192.168.1.200 | _____.____.____._____ |
| Subnet mask | 255.255.255.0 | _____.____.____._____ |
| Gateway IP address | 192.168.1.1 | _____.____.____._____ |
| Primary DNS Server | _____.____.____._____ | |
| Secondary DNS Server | _____.____.____._____ |
UCX Server can be configured to act as a DHCP client (thus obtaining the IP address and network configuration parameters from the DHCP server on your LAN). If you want to use the DHCP client configuration, you would have to ensure that all telephones will be able to locate the UCX system. This can be achieved in several ways (for example by using your DHCP server to provide the server address for telephones or by using the UCX system's domain name in the configuration of telephones). For certain types of telephones the IP address of the server is required (the server name is not accepted).
To simplify the configuration of telephones, we recommend either the use of a static IP address for your UCX Server or using an association of the MAC address of the UCX Server with a specific IP address from the IP address pool of your DHCP server. Both of these options ensure that the IP address of your UCX Server will not change and reconfiguration/reboots of telephones will not be required.
The remote access server assigns virtual IP addresses ranging from 10.80.0.0 to 10.95.255.255 for remote systems. To avoid IP address conflicts, do not use IP addresses in the same range for your UCX system.
If you have a Galaxy Pro or Galaxy 250, the Front Panel Display (FPD) will show the assigned IP address. If "No IP Address" is displayed, this is an indication that there is an IP address conflict or DHCP mode is selected and there is no DHCP server. See Front Panel Display for details on how to reset your UCX Server's network configuration back to factory default.
Network Considerations
The UCX software supports multiple ethernet network interfaces. Typically, for UCX-Virtualizion and UCX-Cloud deployments, only a single network interface is assigned to the instance, in which case all telepehony and management traffic will use that single interface, which will be designated as Ethernet 0 in the UCX Administration Network page.
Galaxy appliances are equipped with either two or three ethernet network interfaces that are identified as Ethernet 0, Ethernet 1, and Ethernet 2 (when available). Any of these interfaces can be used for telephony communication, including voice and signaling traffic for other Galaxy peripherals such as digital phone traffic via a DSM16, PRI, FXO or FXS ports on gateway hardware or IP Phones as well as management-related traffic. Therefore, even with multiple network interfaces ports available, just a single interface can be configured and connected tot he customer’s LAN infrastructure. In most cases the UCX documentation is based on using Ethernet 0 configured to connect to the customer LAN which in turn connects to the customers’ connection to the public internet.
In scenarios when there is a requirement to connect Ethernet 1 or Ethernet 2 to the customer LAN and public internet, then that interface should be configured prior to configuring Ethernet 0, pointing the Default Gateway, DNS servers, and IP address as appropriate for that connection. You can verify the connection by activating Remote Access (VPN) and downloading software updates from the E-MetroTel repository. Once configured, you may configure the Ethernet 0 interface to connect to your Telephony LAN. Note, however, that the distinction is merely the physical connection point to the network. All other functionality remains the same.
Typical Network Connection
For a typical Galaxy appliance deployment, ensure that the WAN interface is configured to be able to connect to the customer LAN. If the default address of 192.168.1.200 and subnet mask of 255.255.255.0 is not compatible with the customer network, change the IP address and subnet mask to be compatible, then connect a RJ-45 cable between the Galaxy appliance WAN port and the customer’s ethernet switch.
Care should be taken to ensure that the customer DHCP server avoids assigning the IP address of the Galaxy appliance to other devices. This can be avoided by making sure the IP address of the Galaxy appliance is outside the range of the DHCP server assigned addresses.
Separate Voice LAN
The following diagram shows how UCX can be deployed in a network with a separate LAN for voice traffic. In the following diagram the Galaxy Expand has been connected to the Management LAN (192.168.10.200) using the front Ethernet interface on the processor card itself. Ethernet 0 (192.168.1.200) on the backplane of the processor card is used for the connection to the Telephony LAN which includes any telephony cards in the Galaxy chassis. The actual physical connection to the rest of the Telephony LAN devices is via either of the ethernet switch ports on the SFS card.
The advantages of having a separate voice network is improved voice quality and reliability, better security and problem isolation. See Configure a Second Network Port for configuration instructions.
SIP Service Provider connections
In some instances, SIP Service Providers prefer to terminate their SIP trunks on a dedicated network interface in their control (say through a session border controller) that has a private addressing scheme that is separate from the customer LAN. In this case, the second or third ethernet interface can be configured to match the addressing scheme of the SIP Trunk service provider, and static routes can be configured within the UCX software on the Galaxy appliance to allow traffic to flow as needed.
The following diagram shows the Galaxy Mini with the second ethernet port connecting to the SIP Trunk provider.
Security
Adding Local Subnets to Do Not Block list
The UCX feature IP Block List is a security application that monitors the UCX system and temporarily blocks IP addresses that attempt to break into your system. If the UCX detects unauthorized attempts to connect to the system using the Web Server, Secure Shell, or Telephony interfaces, it will block all connections from the subnet of the source IP Address. For example, if a user on one of the local subnets attempts to log into the UCX Administration and reaches the threshold set for invalid connection attempts, then all users on that subnet will be blocked until the block timer has expired. Similarly, if a user or service provider SIP account is configured with the wrong password the subnet entire subnet will be blocked when the number of invalid connection attempts is reached. Therefore, it is advisable that you add either the specific IP addresses of local devices that you wish to communicate with the UCX or that you add the entire subnet(s) to the feature’s Do Not Block settings as part of your initial setup.
Network Connectivity Requirements
Bandwidth Requirements
Every leg of a call that made to or from the UCX uses bandwidth in both directions during the call while it is on the IP network. By default, the UCX uses G.711 encoding of the voice which requires approximately 100 kb/s of bandwidth per direction.
Examples:
- If you are calling from an IP phone on your LAN to an analog or digital trunk, the bandwidth consumption for that call is about 100 kb/s second in each direction, but only on the 100Mb/s LAN connection.
- A remote user connecting to a SIP trunk on the UCX uses 100 kb/s each way across the WAN for the connection to the UCX and then another 100 kb/s each way across the WAN for the SIP Trunk portion of the call for a total of 200 kb/s each way for the call.
- An office worker calling another office worker in a UCX Cloud deployment will use 100 kb/s each way across the WAN to connect to the UCX Cloud. The UCX will then connect to the called worker using 100 kb/s each way, for a total of 200 kb/s each way for the call.
- A remote worker calling on a SIP Trunk on a UCX Cloud will not use any of the office WAN bandwidth, but will use 100 kb/sec each way on the home internet connection.
So the total bandwidth required for UCX IP calls will vary based on your network topology and the number of simultaneous calls your business will require. But remember that there are other services such as web browsing, streaming services, email and other corporate data usages that require the bandwidth as well, so it is important to assess the overall bandwidth requirements. E-MetroTel recommends planning for an 80%
Latency Requirements
Latency is a measure of the time it takes for (voice) packets to reach the far end of a connection. For voice calls the higher the latency, the more difficult it is to communicate effectively over the connection, and may even cause calls to drop. E-MetroTel recommends that the end to end latency across a WAN connection to another site or to a UCX Cloud server less than 100 ms.
Jitter Requirements
Jitter is the amount of variation in the time it takes for packets to arrive at their destination, i.e. the inconsistency of the latency. Too much jitter can cause significant call quality issues. E-MetroTel recommends jitter be less than in the 20-30 ms range, and certainly never over 100 ms.
Packet Loss
While some degree of packet loss is tolerable in a Voice over IP call, packet loss over 3% can begin to significantly degrade the call quality.
Router Requirements
E-MetroTel does not recommend specific brands of routers. However, some of the router capabilities used to connect the office to the WAN need to be taken into consideration.
SIP ALG (Application Layer Gateway) and Stateful Packet Inspection (SPI)
Many brands of routers offer some level of firewall capabilities that are intended to make intelligent decisions on which packets can pass from the WAN to the customer LAN. These capabilities attempt to determine where certain packets really should go once they are passed (or if they pass) through the firewall, and they don’t necessarily make the correct choices. SIP ALGs will often result in one-way audio, no ringing, or dropped calls.
For more information refer to Unexpected call failures and registration problems.
E-MetroTel requires that SIP ALG be turned off. Most commercial routers have SIP ALG enabled by default. Please check the manufacturer's handbook for your device on how to disable SIP ALG.
Quality of Service
Many business class routers can be configured to prioritize certain packets over others as they pass from the high-bandwidth environment of the LAN to the narrower bandwidth WAN. In many cases this involves having the router look at a certain portion of the packets to determine if they have been marked with special Differentiated Services (DiffServ) codes. E-MetroTel marks VoIP related media packets with the Expedited Forwarding (EF) code by default, which is the industry standard. However, if your router requires some other value, refer to SIP Settings for an explanation of how this can be changed on the UCX.