Network & Connectivity Requirements

This article provides a detailed overview of the network and connectivity requirements essential for the RingDNA Communication Hub. It includes information about the servers, port ranges, and IP addresses that users must have access to.

Connectivity Overview

The RingDNA Communication hub offers two options for call connectivity.

Please note that if your network is not properly configured to support cloud-based calling over WebRTC, you may encounter issues such as:

• Robotic audio
• One-way audio
• Dropped Calls
• Audio Delays

Hardware Requirements

Minimum System Requirements

• Desktop or Portable Laptop with:
  • A minimum of 8GB of RAM
  • An Octane 2.0 score of 30,000 or greater
• USB Wired or Wireless Headset
  • For best results, connect wired headsets directly to the computer and not a USB hub.
  • For Wireless headsets, use the included USB dongle if it comes with one.

Headset Requirements

We recommend using a quality headset for your calls. A laptop's built-in microphone can pick up background noise and isn't suitable for use with RingDNA. The best choice is a USB headset, as it connects reliably to your computer and provides good sound quality.

While wireless headsets using Bluetooth can work, their connectivity can sometimes be unreliable resulting in audio that skips, cuts out, or has static. If you experience issues with a wireless headset, it's best to switch to a wired one.

For the best results, plug the USB headset directly into your computer rather than using USB hubs or docking stations, which can sometimes cause audio issues.

Bandwidth Requirements

Fast internet isn’t the same as consistent, reliable internet. Even if your connection has very high-bandwidth or speed, there could still be issues with jitter, packet loss, bufferbloat, or latency resulting in call quality issues.

The following table lists the network requirements to deliver acceptable audio quality through WebRTC with the OPUS codec:

For more information see: Running Network Tests and Interpreting Results.

Network Configuration Requirements

Domain Connectivity Requirements

Firewalls are used by network administrators to protect a private network by blocking or allowing traffic to and from internet destinations based on certain rules, such as traffic direction, protocol, and IP address.

In order to use the RingDNA Communication hub, traffic must be allowed to and from the following domains.

*.revenue.io, *.ringdna.net, *.ringdna.com, *.pubnub.com, *.pndsn.com, *.pubnub.net and *.pubnubapi.com, *.launchdarkly.com

If access is not allowed for all domains listed above, the RingDNA Communication hub may not work as expected.

Carrier Connectivity Requirements

Your firewall should also allow outgoing TCP and UDP traffic to our carrier partner's media servers and signaling gateways, and allow return traffic in response.

† The client will select any available port from the ephemeral range. On most machines, this means the port range 1,024 to 65,535

VPN

If your company uses a VPN, please configure a split-tunnel to allow a call's signaling and media traffic to connect outside of the VPN.

Our dialer performs optimally when allowed to connect directly to our Carrier Partner network. Additional network hops introduced by your company VPN may introduce additional network latency and degrade the quality of the call.

Virtual Desktops and Remote Desktop Clients

We do not support using our services through Virtual Desktop Infrastructure (VDI) or Remote Desktop Clients (RDP).

Global Low Latency (GLL) Requirements

By default, the ringDNA Communication Hub will resolve a hostname to the edge location with the least latency. In order for GLL to give accurate results, the intermediate DNS must:

• Support RFC 7871 - Client Subnet in DNS Queries.
• Reside in the same edge as the endpoint. For example, a user in the US configured with a VPN to Europe or configured with a DNS server that resides in Europe will result in connecting that user to an edge in Europe.

Routers, Switches, and Firewalls

Our services do not require specific network hardware. To achieve the best possible service quality, your network should be configured to:

• Enable Quality of Service (QoS) rules which prioritizes the voice media and signaling traffic
• Disable SIP-ALG
• Disable Deep Packet Inspection (DPI)
• Disable Stateful Packet Inspection (SPI)

Salesforce Authentication & API Access

If your Salesforce Org restricts login access to a range of IPs, you will need to whitelist our application IPs in Salesforce. More information can be found in this troubleshooting article: Salesforce OAuth Failed: Ip Restricted

Jitter, Packet Loss and Latency Recommendations

Jitter, latency and packet loss are the biggest contributors to voice quality issues in any
voice network.

• Jitter: When packets arrive in a different order compared to when they were sent. The main symptom is choppy audio quality.
• Packet Loss: Certain network connections such as WiFi are prone to packet loss, which leads to “robotic sounding” audio.

We recommends the following to avoid jitter and packet loss:

• Users should connect to the network using an ethernet cable whenever possible.
• Move closer to your Wifi access point. Multiple walls could affect the signal strength and introduce packet loss.
• If your Wifi access point is dual channel, and if you have a lot of smart home devices, connect to the 5G network instead of 2.4G.
• Reduce packet conflicts on Wifi by reducing the number of devices operating on the same channel or Wifi access points.
• Avoid large data transfers or streams over the same WiFi environment concurrently with voice and schedule backups during off-hours.
• Implement QoS rule to prioritize the traffic based on the IP ranges and internet addresses in the section above titled Firewall Configuration.
• Some users may opt for using a bluetooth headset for comfort. While it's a great option in most cases, it can also sometimes introduce latency or jitter if the connection is poor or the battery is running low. In general, we recommend using a wired headset for quality and reliability.

A typical symptom of latency is audio delay or people talking over each other. Callers
typically start to notice the effects of latency once it breaches 250ms “mouth-to-ear” or roundtrip, and above ~600ms the experience is very poor.

Note that there will always be some latency – It takes time to encode the
audio and traverse the carrier’s networks. The goal is to minimize the total trip time below 300-400ms for voice calls.