Supported Network Configurations, Best Practices, and Things You Should Know

What is required for a flawless Network?

In most cases, our platform is meant to be plug-and-play with local Networks. Once the phone is configured; it should just work! However, there are best practices and some uncommon configurations which will prevent phones from working as they should, and these best practices are detailed below. 

Internet Service Providers

Your Internet Service provider can make or break your service. ISPs are known to interfere with voice services from 3rd party providers; this could be anything from queueing to blocking traffic. While not extremely common, you can usually get around this interference with TLS or a VPN.

Business-class internet is not a requirement, and rarely needed for our services, but you will find getting the required support is easier with Business class internet when working with most ISPs.

If you are using a router provided by the ISP, and not a simple modem, it is highly recommended to do the following: 

1. Disable WiFi
2. Disable the firewall
3. Activate 'Bridge Mode' with your router/firewall handling traffic.

SIP-ALG

SIP ALG is not supported, with the exception of certain SBCs. You can check call traces to see if SIP ALG is turned on. SIP ALG will cause a variety of strange issues, as described in the linked article.

SIP ALG may be referred to by other names, such as SIP Helper. SIP ALG can be enabled by an ISP on Routers or Firewalls. In most cases, we will require ALG to be turned off before doing other troubleshooting.

Customer Internal Network Considerations

NAT

Phones have a local SIP Port and local RTP Ports. They will send traffic towards our Network, opening up NAT pinholes. Most Networks use some type of dynamic cone NAT. Our PBX reverse-engineers the NAT ports by waiting to receive traffic from the Registered device, or at the specified SDP Port. The PBX will then send back to the port where it received the traffic from.

In a normal Network environment, your phone's NAT ports on the WAN side of their Network should not change. If they are changing frequently, this is a common sign that the UDP timeout is too short.

Double-NAT

Our PBX can generally handle and tolerate Double-NAT, but you should avoid Double-NAT when possible. In Double NAT, your router or Firewall will have a private IP address on the WAN port and use another private IP address on the LAN port. You typically want the router that is handling NAT to have a public IP address on its WAN side.

UDP Timeouts

UDP timeouts can result in all sorts of VoIP Problems, as described in our article explaining UDP Timeouts. You will need to have a minimum of 30 seconds for UDP Timeouts. Keep in mind that higher values equate to less secure Networks and lower values equate to SIP problems.

Traffic Shaping/QoS

Traffic shaping is considered a requirement before troubleshooting quality-based issues. Traffic shaping allows you to prioritize SIP and RTP packets above other packets. Most commercial-grade routers and firewalls have the ability to do traffic shaping or QoS of some type.

You won't necessarily have quality problems without traffic shaping, but it's your best defense against running across quality problems in the first place.

VLANs

Segregation of VoIP traffic from the rest of the Network is another best-case scenario. It may take extra effort, but VLANS prevent further interference from devices on the LAN. You can also tag your traffic so switches on the customer Network respect and prioritize the VoIP packets accordingly.

DSCP

DSCP is a layer 3 QoS Method that is not carried over the WAN, but you can set DSCP values on your phones and on some Network equipment. DSCP helps to prioritize the traffic on the local Network and typically goes hand-in-hand with setting up VLANs.

• 46 for RTP
• 26 for SIP

Packet Fundamentals

P-time

P-time is packet timing. Most codecs support a 20ms P-time by default, and we do not recommend changing P-time values because other values will simply break communications if you are unfamiliar with how to configure P-time. Each packet is 20 milliseconds in length, there are 50 packets per second (PPS) sent, and 50 PPS received during a normal phone call.

Packet Loss

You will typically want less than 1% overall packet loss to maintain good call quality. 1% is a general statement, and different codecs have different methods of Packet Loss Concealment (PLC), which can make a difference in what is tolerated. 

For the 1% statement to be considered tolerable, the packet loss must be spread evenly throughout the call.

• Example of acceptable 1% packet loss: 10,000 packets, 1 in every 100 packets (20ms each) are lost.
• Example of unacceptable 1% packet loss: 10,000 packets, 100 packets are lost in a row resulting in 2 seconds of a complete loss.

Jitter

Jitter occurs when packets arrive out of order. Most phones have the tolerance to handle some jitter with a Jitter Buffer. We typically set 70-150ms of adaptive Jitter Buffer by default, and these values can be increased to suit your customer's Network. It is important to remember that Jitter Buffer impacts the delay on a phone call.

Packet Delay Variation

In a perfect environment, each 20ms packet would be delivered 20ms after the last packet.

Packet Delay Variation (PDV) may be referred to as Jitter or 'Delta' in many Networking fields. However, PDV can more specifically describe multiple packets being received at one time, after an interval of not receiving packets. Therefore, packets can arrive in order but delayed. If the packets are in order, they are technically not 'jittered.'

PDV is generally caused by faulty Network equipment, cable modem 'static,' or 'signal strength.' Jitter Buffer does help with PDV to an extent, but only up to the Jitter Buffer value of the device receiving the packets.

Often the best way to resolve PDV issues is to reset all Network equipment (especially the cable modem).

Latency/Delay

Contrary to popular belief, Latency alone is not usually an issue. A Network with a steady 300ms of latency is usually undetectable (if there is no jitter and PDV). Latency is the same thing as delay, meaning too much latency results in too much delay. Delay is most notably people talking over one another. Less than 150ms is ideal, but typically the smaller the number, the better!

Bandwidth

Bandwidth has minimal requirements for VoIP, typically if you can remember ~70kb/s per voice call, that's enough. Please don't confuse having a large amount of bandwidth, with having high-quality bandwidth!

RTCP-XR

RTP-Sight collects and displays RTCP-XR, which shows information about the received RTP Stream. RTCP-XR must be turned on at the endpoint (it is enabled on our Supported devices). The benefit to RTCP-XR is two-way packet troubleshooting (you can see information about packets sent To and From your customer's Network).

Other Information/Troubleshooting/Workarounds

Dynamic local SIP Ports

If your customer's Network is having NAT issues, it is possible to deploy an override to change the local SIP Ports. 

SIP over TLS

SIP over TLS can be set to bypass SIP ALG, ISP blocking, or other Network interference issues. 

Static SIP Trunk considerations

Most of this article relates to Registered devices, but static SIP Trunks don't send outbound packets on a regular interval and therefore don't usually maintain a single NAT Port. Static SIP trunks require the devices SIP and RTP Ports to be opened towards our servers.