Objective
To ensure the highest quality calls possible using Outreach Voice, there are several factors to consider, including the performance of your computer, what type of headset is being used, and network configuration.
Notice Regarding Voice Network Updates |
|---|
|
As of September 26, 2023, our voice provider, Twilio, began migrating the media IPs and port ranges for calls in all regions to a new IP and expand their UDP port range. As of October 10, 2023, your network infrastructure needs to be updated to ensure that you have whitelisted the below full IP and UDP port ranges:
Failure to do so will result in one-way audio and dropped calls. Old IP and port ranges will no longer accept or send traffic after but will need to be kept open in your infrastructure until that time. Signaling addresses are not changing. |
Please note that if you do not ensure your setup is configured properly you may run into issues including, but not limited to:
- Dropped calls
- Calls with high delay
- Robotic sounding audio
- One-way audio
There are several configurations we do not recommend which are detailed in the Unsupported Configurations section of this article.
Applies To
- Outreach Voice
Voice Network Requirements
Minimum Requirements
- Computer Hardware
- A minimum of 8GB of RAM
- An i5 CPU or better is recommended to ensure a consistently high performance
- Minimum requirements to run the Outreach Platform include the use of the Chrome browser (the most recent version running on Windows or Mac OS X).
If you are experiencing audio quality issues, CPU spikes from other apps will cause call quality issues. Please be sure to check your activity monitor (Mac) or task manager (windows) for any applications that are taking up CPU.
Headset
As the default microphone in most computers can pick up a lot of background noise, we strongly recommend that you use a high-quality headset for your calls. A USB headset is preferable as it ensures you have a solid connection to your computer. Bluetooth or other wireless headsets can work but are significantly more susceptible to attenuation and can cause poor audio quality so we recommend they are used with caution. Symptoms of a poor wireless connection can include audio that skips, stutters, cuts off, or has static or buzzing. You may also notice that your headset doesn't connect or stay connected. If you experience any of these issues we recommend changing to a wired headset.
Outreach recommends connecting the USB device directly to the system instead of a USB hub or computer dock. Devices not connected directly to computers may experience audio issues.
Browser
Ensure you are on the latest version of Google Chrome. To help maintain the highest voice quality, our voice app tags packets with a DSCP of 46. DSCP, or Differentiated Services Code Point, allows packets to be tagged to prioritize them on the network. Browsers that support DSCP, like Chrome, are capable of tagging call media packets. This can then be used in coordination with your network equipment to ensure these packets are prioritized properly as they progress through your local network.
Network Equipment
Any firewalls, switches, and wireless access points used should allow you to mark and prioritize traffic as this helps to ensure optimal voice quality. If you are using a shared workspace that provides network infrastructure, please be sure to forward this document, specifically the network configuration section, to their IT team. If they are unwilling to make these changes, call quality may be poor so we suggest avoiding VoIP and using a personal phone instead.
Connection Type and Quality
We strongly recommend that your computer is connected via Ethernet instead of WiFi as this helps to ensure the best possible connection to your network. While calling is possible over WiFi, additional setup is recommended. If you wish to use WiFi, please be sure to follow the requirements in our WiFi section below.
To make high-quality voice calls, there are several network qualities that must be considered:
- Latency: How long a packet takes to make it from your computer to our media servers.
- Packet Loss: When a packet does not make it from point A to point B.
- Jitter: The variation in delivery time between packets.
- Bandwidth: The data transfer rate.
| Network Metric | Threshold |
|---|---|
| Latency | Less than 150 ms |
| Packet Loss | Less than 1% |
| Jitter | Less than 30 ms |
| Bandwidth |
At least 100 kbps per concurrent call. |
Bandwidth Calculations
As the number of calls occurring at any given time may vary, we suggest adding at least a 20% overhead to calculations to ensure that you have enough bandwidth during a high calling period. For instance, if you have 15 reps and estimate that during a busy period, and 10 of them would be on the phone, we recommend ensuring at least 1000 kbps is available although it is good to err on the side of caution and reserve even more if possible.
Please note that if your team is growing, we recommend including any additional new users that may be added later into calculations even if they are not yet active.
Network Configuration
Below you will find the complete list of ports, IPs, and fully qualified domain names (FQDNS) used by Outreach. Please ensure these are explicitly added in your configuration and note that ANY-ANY configurations may cause problems. We also recommend these are prioritized across your local network.
IP Addresses
Please note the IP addresses below are used solely by our media servers to process the audio of calls.
| Location | Media Server IP Address Range | CIDR Notation | Protocol | Ports |
|---|---|---|---|---|
|
ALL* |
168.86.128.0 - 168.86.191.255 |
168.86.128.0/18 |
UDP |
10,000-60,000 |
* As of 10/10/2023, this range is required and all others have been deprecated.
Deprecated IPs: The following IP addresses are now deprecated, but provided below for historical reference.
| Location | Media Server IP Address Range | CIDR Notation | Protocol | Ports |
|---|---|---|---|---|
|
Australia |
54.252.254.64 - 54.252.254.127 3.104.90.0 - 3.104.90.255 |
54.252.254.64/26 3.104.90.0/24 |
UDP |
10,000 - 20,000 |
|
Brazil |
177.71.206.192 - 177.71.206.255 18.228.249.0 - 18.228.249.255 |
177.71.206.192/26 18.228.249.0/24 |
UDP |
10,000 - 20,000 |
|
Ireland |
54.171.127.192 - 54.171.127.255 52.215.127.0 - 52.215.127.255 |
54.171.127.192/26 52.215.127.0/24 |
UDP |
10,000 - 20,000 |
|
Frankfurt |
35.156.191.128 - 35.156.191.255 3.122.181.0 - 3.122.181.255 |
35.156.191.128/25 3.122.181.0/24 |
UDP |
10,000 - 20,000 |
|
Japan |
54.65.63.192 - 54.65.63.255 3.112.80.0 - 3.112.80.255 |
54.65.63.192/26 3.112.80.0/24 |
UDP |
10,000 - 20,000 |
|
Singapore |
54.169.127.128 - 54.169.127.191 3.1.77.0 - 3.1.77.255 |
54.169.127.128/26 3.1.77.0/24 |
UDP |
10,000 - 20,000 |
|
United States - East Coast (Virginia) |
54.172.60.0 - 54.172.61.255 34.203.250.0 - 34.203.251.255 |
54.172.60.0/23 34.203.250.0/23 |
UDP |
10,000 - 20,000 |
FQDNs
Please see the below FQDNs used by Outreach Voice. These are used to set up the calls (signaling).
| FQDN | Protocol | Ports |
|---|---|---|
|
Chunderw-gll.twilio.com |
TCP |
443 |
|
Chunderw-vpc-gll.twilio.com |
TCP |
443 |
|
Chunderw-vpc-gll-au1.twilio.com |
TCP |
443 |
|
Chunderw-vpc-gll-br1.twilio.com |
TCP |
443 |
|
Chunderw-vpc-gll-de1.twilio.com |
TCP |
443 |
|
Chunderw-vpc-gll-ie1.twilio.com |
TCP |
443 |
|
Chunderw-vpc-gll-jp1.twilio.com |
TCP |
443 |
|
Chunderw-vpc-gll-sg1.twilio.com |
TCP |
443 |
|
Chunderw-vpc-gll-us1.twilio.com |
TCP |
443 |
|
Chunderw-vpc-gll-us2.twilio.com |
TCP |
443 |
|
Ers.twilio.com |
TCP |
443 |
|
Eventgw.twilio.com |
TCP |
443 |
The following FQDN varies depending on your Outreach Production Environment (which defines where your specific Outreach server is). You can find your Environment in your Outreach app Org Info.
| Production Environment | FQDN | Protocol | Ports |
|---|---|---|---|
| app1a | socketron.app1a.outreach.cloud | TCP | 443 |
| app1b | socketron.app1b.outreach.cloud | TCP | 443 |
| app1c | socketron.app1c.outreach.cloud | TCP | 443 |
| app1d | socketron.app1d.outreach.cloud | TCP | 443 |
| app1e | socketron.app1e.outreach.cloud | TCP | 443 |
| app1f | socketron.app1f.outreach.cloud | TCP | 443 |
| app2a | socketron.app2a.outreach.cloud | TCP | 443 |
| app2b | socketron.app2b.outreach.cloud | TCP | 443 |
For example, if your Org Info shows an Environment of app1d, you would allow socketron.app1d.outreach.cloud.
SIP ALG
Many firewalls and routers have a setting called SIP ALG which is enabled by default. For cloud-based VoIP to work properly, this must be disabled.
Traffic Prioritization
To ensure optimal voice quality, all Outreach voice traffic needs to be prioritized across your network.
QoS
Quality of Service, also known as QoS, helps ensure an optimal end-user experience for audio communications. QoS allows higher priorities for packets carrying audio data. By giving these packets a higher priority, audio packets can complete transmission faster, and with less interruption, than network sessions involving file transfers, web browsing, or database backups. Network packets used for file transfers or database backups are instead assigned a "best effort" priority.”
Outreach voice should be set to the highest priority your network equipment allows. Without this configuration, you may experience dropped calls, choppy audio, laggy audio, and robotic-sounding calls. Depending on your equipment, you may be able to do this based on IP ranges and ports, or by using CoS.
Class of Service (CoS)
We recommend that all Outreach voice traffic is assigned a DSCP of 46 - EF and ensure that all equipment in your network is set to honor DSCP markings. If you want to learn more about CoS / DSCP, we recommend reviewing the following informational article.
WiFi
While calling over WiFi is possible, we strongly recommend against it and suggest you use ethernet where possible.
However, if you still wish to use make calls over WiFi, we recommend the following steps to ensure optimal call quality:
- Prefer 5ghz connections over 2.4ghz
- Use 802.11AC or WiFi 6 where possible
- Apply traffic shaping policies to ensure Outreach voice traffic is prioritized over other wifi traffic
- Compare the number of connected devices per wireless access point against your manufacturer's documentation. If too many devices are connected, you may experience call quality issues.
- If you are still experiencing issues, we suggest performing a wireless site survey. This will help ensure the highest quality connections across the entirety of your environment
Network Tests
Once your network has been configured, we recommend running this network test to ensure that your connection is stable and that voice traffic can pass through your network. However, please note that while a network test is a good snapshot of your network, it is possible to pass a test and still have call quality problems if traffic is not properly prioritized.
Unsupported Configurations
- Voice traffic routing over VPN
- Mobile / Satellite / Microwave internet
- Load balancers
- WAN Accelerators
- SIP ALG - if supported by your network equipment, this needs to be off
- ANY/ANY rules for traffic on firewalls
- Double NAT’d networks
- Calling through Desktop as a Service solution like Amazon WorkSpaces and Citrix
WebRTC
Our web client uses Web Real-Time Communication (WebRTC). It is a collection of communications protocols and APIs originally developed by Google that enables real-time voice and video communication over peer-to-peer connections.
WebRTC is a set of protocols and APIs that allow web browsers to request real-time information from the browsers of other users, enabling real-time peer-to-peer and group communication including voice, video, chat, file transfer, and screen sharing.
Nat Traversal via STUN / TURN servers
To traverse NATs, our client makes use of STUN / TURN servers which work as described below:
Gather Public IP Information
The device behind NAT asks the STUN server to inform it what public IP and port it appears as to the rest of the world.
Public IP Returned & Relay Option Assigned
We confirm how the device's local network's NAT has translated the device's private IP, and also issue a public IP TURN media relay option for use in case it's needed.
Direct Connectivity Test
The device shares the candidate IP/port to try direct streaming over by signaling it in SDP. Far end initiates a connectivity test to that IP to establish if peer-to-peer is possible.
Successful Peer-to-Peer Connection
If devices are able to contact each other directly through the candidate STUN returned, the session is set up with direct media.
TURN Relay Connection
If devices are not able to connect to each other directly due to symmetric NAT or other issues, the SDP negotiates the use of the offered TURN media relay IP so media relays through the geographically nearest relay point.
© 2023 Outreach.io