Talk network requirements

Zendesk Talk uses the internet to make and receive phone calls. For this reason, it's important to have a fast and reliable network. A wired network with Wi-Fi disabled is best, but whichever network you use, you need to configure it to work properly with Talk. If you can't make these changes yourself, contact your IT department. Making such configurations can help reduce:

• Latency: The time it takes the RTP (media) packets to arrive at the destination. Latency can cause media delivery delays, and callers to accidentally speak over each other. The lower the latency, the more your call will seem as if there were only two people talking in the same room. As latency increases, the opposite happens, and your call suffers from interruptions and pauses that cause people to talk over each other.
• Jitter: The change in latency over time. Jitter usually sounds similar to interference, or as though someone is trying (and failing) to plug in their microphone. Additionally, callers might not hear the other side of the conversation.
• Packet loss: When voice signals are digitized and transmitted, they are split into packets. If some of the packets fail to reach their destination, then small pieces of the audio signal will be missing, resulting in audible distortion on the call.

Use the information in this article to help minimize network problems, and get the best from Talk. For general information about starting out with Talk, see Preparing to use Zendesk Talk. To rule out network issues, everything should be wired: a wired 3.5mm jack headset, and a wired internet connection (disable wifi).

Some applications use a lot of bandwidth, especially streaming apps. Zendesk Talk requires 500kbps per agent using Talk, this accounts for Talk and the overhead of Zendesk Support running side by side. If you have 50 agents, they would each need a dedicated (Qos) 500kbps, meaning a minimum 50mbps line.  

As a first step when troubleshooting network issues, close applications such as Netflix, Spotify, and YouTube.

This article covers the following topics:

• Ports, domains, and IP addresses required by Talk
• Using Talk with a Proxy, MPLS, or VPN
• Using DSCP
• Further troubleshooting

Ports, domains, and IP addresses required by Talk

You may need to adjust your network to allow Talk to work. Any changes must be allowed on all firewalls, routers, switches, load-balancers, and any other hardware or software that could block or manipulate Talk network traffic.

Ports 

Ensure the ports in the following table can communicate with all of the domains and IP addresses covered in this article

Zendesk is hosted by Amazon Web Services (AWS). To see all the AWS IP ranges you need to allow for Talk, see Configuring your firewall for use with Zendesk.

You must allow your Zendesk subdomain on your network, for example:
*.{{yoursubdomain}}.zendesk.com

Talk uses the following outbound ports:

TCP / UDP:	443,3478
UDP	10,000 to 60,000 | 443 | 3478
TCP	5349

Twilio domains

Twilio is the Voice provider for Zendesk Talk. The following list contains the Twilio domains that you must allow access to.

Recently added (May 31, 2023)

chunderw-vpc-gll-us2.twilio.com	media.twiliocdn.com
voice-js.ashburn.twilio.com	eventgw.au1.twilio.com
voice-js.sydney.twilio.com	eventgw.br1.twilio.com
voice-js.dublin.twilio.com	eventgw.ie1.twilio.com
voice-js.sao-paulo.twilio.com	eventgw.de1.twilio.com
voice-js.frankfurt.twilio.com	eventgw.sg1.twilio.com
voice-js.tokyo.twilio.com	eventgw.jp1.twilio.com
voice-js.singapore.twilio.com	eventgw.us1.twilio.com
voice-js.umatilla.twilio.com	eventgw.us2.twilio.com
voice-js.roaming.twilio.com	eventgw.gll.twilio.com

Existing Twilio domains

chunderw-gll.twilio.com	chunderw-vpc-gll.twilio.com
chunderw-vpc-gll-au1.twilio.com	chunderw-vpc-gll-br1.twilio.com
chunderw-vpc-gll-ie1.twilio.com	chunderw-vpc-gll-de1.twilio.com
chunderw-vpc-gll-jp1.twilio.com	chunderw-vpc-gll-sg1.twilio.com
chunderw-vpc-gll-us1.twilio.com	matrix.twilio.com
eventgw.twilio.com	gwasset.twilio.com
sdk.twilio.com

Twilio IP addresses 

This list contains the Twilio domains that you must allow access to.

Important: Zendesk will contact you to advise of any recent additions to this list. However, double-check with your network team to ensure they've added them to your existing firewall, load balancer, and other network equipment rules.

Recently added (May 31, 2023)
168.86.128.0/18

Existing Twilio IP addresses

54.244.51.0/24	3.1.77.0/24	3.112.80.0/24
3.122.181.0/24	18.228.249.0/24	3.104.90.0/24
72.52.10.0/24	65.9.130.0/24	44.234.69.0/25
3.235.111.128/25	18.141.157.128/25	18.180.220.128/25
3.249.63.128/25	3.7.35.128/25	18.230.125.0/25
3.25.42.128/25	54.252.254.64/26	177.71.206.192/26
54.171.127.192/26	52.215.127.0/24	54.65.63.192/26
54.169.127.128/26	54.172.60.0/23	34.203.250.0/23
35.156.191.128/25

URLS

Additionally, you must allow the following URLs for your VPN, firewall, and any antivirus software you are using:

• https://pubsub-shard2-17-1.zendesk.com
• https://pubsub-shard2-17-2.zendesk.com
• https://pubsub-shard2-17-3.zendesk.com
• https://pubsub-shard2-17-4.zendesk.com

Configuring your network

You must also carry out the following network configurations:

• Ensure both the Zendesk and Twilio IP addresses and domains are excluded from stateful packet inspection (SPI), or you may experience high UDP or TCP connection times.
• Do not plug in hardware that is not meant to be plugged into a smart switch, and check with your network team that it's configured to reflect the settings mentioned in this article. Customers have mentioned that if a switch or other network hardware was plugged into an incorrectly configured Cisco Smart Switch it could override the allowed domains and IP addresses.
• Your firewall must allow outgoing UDP to the public internet from the browsers that will use Talk, and allow return traffic in response. Zendesk is hosted on AWS, and because of this, it is not possible to narrow down the IP range. You might see some IP addresses slightly outside these ranges due to AWS networking.
• If your router includes the SIP Application Level Gateway (ALG) function, or Stateful Packet Inspection (SPI), disable both of these functions on the networks using Zendesk Talk.
• Talk does not work with MPLS or VPN. Do not allow traffic for the domains and IP addresses listed to run through a VPN.

After you've allowed connections to all of the above IP addresses and domains for the ports mentioned (each port needs to access all domains and IP addresses listed), there should be no issues with Zendesk Talk making and receiving calls.

Using Talk with a Proxy, MPLS, or VPN

Talk does not work with a Proxy, MPLS, or a VPN setup due to a service that runs in the background called GLL. This service chooses the best network path to run the call through. If you use a Proxy, MPLS, or VPN, it will not give the true location of your agents, so Talk cannot route the call efficiently. This can lead to latency and other call quality issues. If you must use a Proxy, MPLS, or VPN, exclude traffic for the Zendesk and or Twilio domains (including your FQDN subdomain.zendesk.com) and use the IP addresses listed in this article to run through your VPN.

Zendesk Talk is not compatible with virtual desktop environments.

Using DSCP

For information about the guidelines to implement DSCP, see Configuring Quality of Service (QoS) settings for Talk on Windows domains.

DSCP tags in packets are useful for informing network appliances how to prioritize traffic. By default, Talk calls have a DSCP tag of 46. If congestion is an issue on your network, consider implementing DSCP using the instructions in this article. The Twilio Client 1.3 and later enables DSCP by default in compatible browsers (for example, Google Chrome).

Compatible browsers tag WebRTC media packets. This enables differentiated handling on a LAN so real-time media can be prioritized above other network traffic. The Differentiated Services (DS) field is located in the IPv4 header TOS octet or the IPv6 Traffic Class octet. A DS-compliant network node (for example a router) includes a classifier that selects packets based on the value of the DS field, buffer management, and packet scheduling mechanisms that are capable of delivering the specific packet forwarding treatment indicated by the DS field value.

With the Twilio Client 1.3, sent RTP packets will have a DiffServ codepoint on their local Wireshark packet captures. When you enable DSCP, the WebRTC engine marks the RTP packets with EF, and the values related to expedited forwarding:

• binary: 101 110
• hex: 0x2e
• decimal: 46

You must use a browser that supports webRTC, for example, Chrome or Firefox. If you implement DSCP (recommended), use Chrome (the latest, non-beta version) as this is the only browser that supports it.

To check if you're on the latest version of Chrome, navigate to: " chrome://help/ " in your address bar. Click the Relaunch button to update Chrome.

Checking DSCP functions correctly

In some Windows-based environments, DSCP tags are filtered out despite the network being set up for DSCP. Your network team can verify if DSCP tags are being filtered out by Windows, by running a capture in Wireshark. Either implement a group policy that enforces DSCP or, if your computers are not on a domain, implement it on a computer-by-computer basis.

To ensure Windows is not stripping out the DSCP tags, you need to perform the following steps, depending on whether your computer is on a domain or not.

Checking DSCP tags for machines on a domain

For machines on a domain, you control the QoS settings that are used for certain applications by designing different Group Policy rules.

Use the following steps to ensure that WebRTC packets are prioritized, to make the Dialer work optimally.

You must force client machines to pick up this new Group Policy for the above to work. Usually, a reboot fixes it.

To check DSCP tags for machines on a domain

1. In the command line, type "gpedit.msc", this opens the Group Policy rules.
2. In Group Policy rules, under Computer Configuration, select Policy Based QoS Settings.
3. Right-click, then select Create new Policy.
4. A wizard interface opens to configure the QoS rules.
5. In Policy name, type in "Salesloft DSCP" and for the DSCP value, specify '46'.
6. Click Next.
7. In the next dialog, select Only applications with executable name, then enter "Chrome.exe"
8. Click Next.
9. In this dialog you do not need to enter any settings. Click Next.
10. In the next dialog, select the protocol that the QoS applies to. For the Salesloft Dialer, this will be limited to UDP.

Checking DSCP tags for machines that are not on a domain

This section modifies the registry setting to allow you to specify the QoS setting that will be used based on the Group Policy settings you configure.

To check DSCP tags for a machine not on a domain

1. Navigate to HKEY_LOCAL_MACHINE > CurrentControlSet > Services > tcpip > QoS.
2. If the QoS Key does not exist, right-click TCP/IP and select New Key.
3. For the name, enter "QoS."
4. Select the QoS key.
5. If the string does not already exist, create a new string value called "Do not use NLA."
6. Set the value to 1.
7. Reboot for the settings to take effect.

Requirements for Windows computers

You may encounter issues with Zendesk Talk if you are using a computer with a Windows operating system. Zendesk Talk customers must use the Quality Windows Audio Visual Experience service and set the startup type to Automatic (not the default value Manual).

To ensure QWAVE is enabled and startup is automatic

1. Open the Windows Start menu, "cmd".
2. Right-click the Command Prompt icon, then click Run as administrator.

   

3. Paste the following text into the command line:

   net start QWAVE 

4. Press Enter. You'll see the following results.

   

5. To ensure this permanently has an automatic startup type; paste the following into the command prompt to set the service startup type to Automatic:

   REG add "HKLM\SYSTEM\CurrentControlSet\services\QWAVE" /v Start /t REG_DWORD /d 2 /f

6. Press Enter.

The "QWAVE" service has set the startup type to "Automatic". If you encountered an error when following the above steps, ask a member of your IT team or a computer administrator to perform them (The command prompt needs to be run as an Administrator).

Set up a group policy on your network to make all client computers set the service to automatic, it saves you time having to set up each computer manually.

Further troubleshooting

After working through the steps mentioned in this article, use the Twilio SDK to examine the quality of your calls. For more information, see Voice insights SDK events reference.