Connect Network Configuration Guidelines

This article serves as a rough technical guideline for installing a Fonality Connect system.

NOTE: Although the installation guide provides networking information, Fonality cannot be held responsible for local network administration. A knowledgeable networking technician should be on site to provide the appropriate networking setup.

To provide the best possible experience when using the Fonality Connect system, a solid network setup is highly recommended. Each section below provides detailed information which will need to be considered in order to make an informed decision regarding network configuration.

 

 

Maximum concurrent calls per location

The Fonality Connect system utilizes two types of audio codecs:

  • G729 (default): bandwidth usage is ~33 kbps per call, per direction

  • G711(backup): bandwidth usage is ~90 kbps per call, per direction

When planning the local network setup and bandwidth provider, it is always recommended to keep the busiest scenario in mind, meaning the maximum number of phones and largest bandwidth utilization (G711).

EXAMPLE:

With a system that has 10 phones in total it would be best to expect up to 10 concurrent calls when planning the network infrastructure.

Using G711, the recommended bandwidth for phone calls alone would be:

  • 90 kbps x 10 = 900 kbps download 

  • 90 kbps x 10 = 900 kbps upload

Please note that the figures provided above only provide estimates for phone traffic. Please allow for additional bandwidth for computer traffic, as well. If additional bandwidth is not accounted for, call quality may suffer and internet navigation may slow to a crawl.

Number of phones per location

It is not recommended to utilize a residential-level router for an enterprise-level network deployment. Although there is not an exact technical cut-off between a residential-level vs. enterprise-level router, a rough estimate would be as follows:

  • Residential: 10 phones or fewer

  • Enterprise: 11 phones or more

NOTE: these figures also assume an equal number of computers on location in addition to phones, i.e.: 11 phones also assumes 11 computers at the same location.

Fonality several recommended routers, depending on the level of deployment:

  • Residential routers:

    • D-Link DIR 655 (up to 10 concurrent calls)

  • Enterprise routers:

    • Cisco SRP521W (up to 25 concurrent calls)

    • Cisco SRP541W (up to 50 concurrent calls)

 

Unsupported routers/firewalls

Certain models of routers or Internet connection types are not compatible with Connect.  In particular:

-- Most AT&T UVerse connections are unsuitable for more than one Connect phone.

-- Sonicwall firewalls are unsuitable for more than one Connect phone.

Network equipment per location

Although there are too many brands and models to keep track of all possible configurations, a few simple steps can help determine if the network equipment on site is capable of providing the best possible experience with a Fonality Connect system.

  1. Is the network set up with double NAT?

    1. If the phone connects as such:

IP Phone -> Router #1 -> Router #2 -> Internet

...this is called double NAT. This causes major issues with VoIP, and in nearly every case will not allow the phones to register properly.

b. To verify, log into the admin interface for Router #1 (as indicated in example above) and check the WAN address. If this address is an internal IP (such as 192.168.x.x or 10.10.x.x) then there is a double NAT scenario.

c. In a double NAT scenario, all redundant routers will need to be removed. If Router #2 (as seen in example above) is actually a modem/router combo, the router functionality will need to be disabled. To do so, contact the ISP and request that the modem be bridged. Once the modem is bridges, the double NAT scenario should no longer exist.

d. If multiple routers were used to allow for more devices to connect to the internet, it is recommended to simply utilize switches instead. Switches allow for more devices and do not interfere with the router's ability to pass packets appropriately.

  1. Verify the SIP ALG functions in the router.

    1. SIP ALG is a rule telling the router how to handle SIP traffic.

The settings in question are:

  • SIP Transformation

  • SIP Fixup

b. Different routers models, and even different firmware versions of the same router, implement SIP ALG differently. As each router handles these settings in its own way, it is recommended to switch the settings on and off and test after each change to find the best utilization of the settings.

  1. Verify the SPI Firewall settings.

a. Turn off SPI.

  • If call quality problems persist on the Fonality Connect phones, log into the router admin panel and verify that SPI is turned off. SPI adds additional delay as it inspects each incoming audio packet.

b. Verify the Quality of Service (QoS) settings

  • Fonality Connect IP phones send audio on ports UDP 10000-20000 and 5060.

  • Incoming audio packets from the Fonality Connect server need to be able to reach the Fonality Connect phones. When setting the QoS settings, configure the router to give priority to all inbound/outbound traffic between your network and this Fonality server.

-- To get the IP address of the Fonality server the phones are using, use the Fully Qualified Domain Name (FQDN) of the Fonality Connect server; the FQDN of the server is always s<serverID>.pbxtra.fonality.com.

c. If there is only one Fonality Connect phone at a location, port forwarding or DMZ mode on the router might have a positive effect on call quality.

  • To properly accomplish this, port forward UDP 5060 and UDP 10000-20000. A good reference on how to accomplish this can be found at

http://portforward.com/

Network latency

The most difficult part of troubleshooting VoIP call quality on a network is latency, jitter, and packet-loss. Please review the following information for an explanation of each topic, and methods to test for any issues.

  1. Latency

    1. Latency is the time it takes for an audio packet to travel from the Fonality Connect phone to the Fonality Connect server. As a rule of thumb, any measurement less than 150ms is tolerable. 

    2. To test latency:

  • On the same network as the phone, ping Fonality's server at s<sid>.pbxtra.fonality.com. If latency consistently measures over 250ms, attempt to ping another location such as http://google.com . If latency continues to measure over 250ms it is advisable to contact the ISP for that location for further troubleshooting.

  1. Jitter

    1. Jitter is the variation in delay between audio packets.

SIMPLIFIED EXAMPLE:

User #1 picks up the phone and say "Good morning!". "Good" is sent on Packet #1 and "morning" is sent on packet #2. In cases where jitter is extreme, the packets will be sent incorrectly and can be passed to the server as "morning good!" instead.

b. Unfortunately, not much can be done to fix jitter other than to make sure QoS is enabled on the local routers. By default, Fonality uses jitter buffers to compensate for this problem so this issue is encountered in only very rare occasions.

  1. Packet Loss

    1. Packet loss occurs when audio packets sent by either the Fonality Connect phone or Fonality Connect server get dropped.

    2. Packet loss is almost always a result of an ISP problem. If this issue occurs, contact the local ISP for advanced troubleshooting steps.

Return to Documentation Home I Return to Sangoma Support