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, IP addresses, and URLs 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.
This section covers the following topics:
Configuring your ports setup
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). You must retrieve and allow all the AWS IP ranges that 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 |
Providing access to 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 | voice-js.ashburn.twilio.com |
| voice-js.sydney.twilio.com | voice-js.dublin.twilio.com |
| voice-js.sao-paulo.twilio.com | voice-js.frankfurt.twilio.com |
| voice-js.tokyo.twilio.com | voice-js.singapore.twilio.com |
| voice-js.umatilla.twilio.com | voice-js.roaming.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 | media.twiliocdn.com |
Providing access to Twilio IP addresses
This list contains the Twilio domains that you must allow access to.
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 |
Allowing specific URLs for your setup
For some Talk features, the connections to Zendesk are not made via the same URL as the requests to the rest of Zendesk (such as mydomain.zendesk.com), but instead via a URL, such as pubsub-shardC-P-N.zendesk.com, which you might see as, https://pubsub-shard2-17-1.zendesk.com, for example.
- C is the cluster of the account (a value between 1 and 3)
- P is the pod of the account
- N is a random number from 1 to 4
To identify your pubsub-shardC-P-N.zendesk.com connections
- Open Chrome, and click the click the Options (
) menu. - Click More tools > Developer tools.
- In the Filter field, enter "pubsub".
To allow the following URLs
Replace the "C", and "P" with the cluster and pod number that you identified for the following URLs:
- https://pubsub-shardC-P-1.zendesk.com
- https://pubsub-shardC-P-2.zendesk.com
- https://pubsub-shardC-P-3.zendesk.com
- https://pubsub-shardC-P-4.zendesk.com
Configuring your network
You must 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, see Configuring your firewall for use with Zendesk.
- If your router includes the SIP Application Level Gateway (ALG) function, or 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
To use a Proxy, MPLS, or VPN, you must configure the IP addresses and domains used by Twilio so they are allowed to pass through the VPN, see the previous topic Ports, domains, IP addresses, and URLs required by Talk.
If you do not configure your setup accordingly, Talk will not work with a Proxy, MPLS, or a VPN, due to a service that runs in the background. This service chooses the best network path to run the call through. Trying to find the shortest route between you and your caller is also difficult when you're using a VPN, because a VPN masks your IP address. 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.
To use a Proxy, MPLS, or VPN
- Exclude traffic for the Zendesk and or Twilio domains (including your FQDN subdomain.zendesk.com).
- 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.
This section covers the following topics:
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
- In the command line, type "gpedit.msc", this opens the Group Policy rules.
- In Group Policy rules, under Computer Configuration, select Policy Based QoS Settings.
- Right-click, then select Create new Policy.
- A wizard interface opens to configure the QoS rules.
- In Policy name, type in "Salesloft DSCP" and for the DSCP value, specify '46'.
- Click Next.
- In the next dialog, select Only applications with executable name, then enter "Chrome.exe"
- Click Next.
- In this dialog you do not need to enter any settings. Click Next.
- 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
- Navigate to HKEY_LOCAL_MACHINE > CurrentControlSet > Services > tcpip > QoS.
- If the QoS Key does not exist, right-click TCP/IP and select New Key.
- For the name, enter "QoS."
- Select the QoS key.
- If the string does not already exist, create a new string value called "Do not use NLA."
- Set the value to 1.
- 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
- Open the Windows Start menu, "cmd".
- Right-click the Command Prompt icon, then click Run as administrator.
- Paste the following text into the command line:
net start QWAVE
- Press Enter. You'll see the following results.
- 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
- 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.
Troubleshooting
Call quality
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.
Error message
If you receive the error message: "Some Talk Features aren’t available right now. You can still make and receive calls." this means your browser can’t connect to the URL. If you don’t allow communication, then multiple features in Talk might not work as expected and you will only be able to accept and decline calls, or hang up.
To resolve this problem
- Contact your network administrator to enable your network to communicate with the resource.
- Disable the following:
- Wrap up. If Wrap up is enabled then the user will be immediately dropped from the call.
- Recording
- Transfers
- Hold
10 Comments
The callout in the article above does not inspire confidence that future updates will be communicated beyond this resource.
I suggest you add app.pendo.io to this list. I had problems with transfers / conferencing until I added that to my exceptions.
Was the list of twilio domains recently updated? We would need advanced notice when this happens to prevent disruption to our phone channel.
The list of Twilio domains was not recently updated. For any major changes involving networking, we would try to communicate that to folks in advance.
Ferran Barneda and Sabra, I know for a fact that this is a must for everyone who are using Talk Feature of Zendesk but is this applicable if we are operating across the globe and not using particularly one network?
Our agents all work remote and so they are all on different networks with their personal internet providers. Do they need to each configure this to their home internet networks? Or is this something we do from within Zendesk? Thanks!
Hi Jen,
This needs to be done on the user's network. This article will show what are the necessary things that need to be allowed on their network. Though most regular home internet networks do not have restrictions, it is still better to verify that they are allowing all the things discussed in this article to avoid any issues with the service.
Hope this helps.
We are trying to verify users won't have issues with the switch by testing on the recommended site: https://networktest.twilio.com/?usenewvoiceips=true
Is the Video Test Group Room important to TALK or can that fail?
Everything else appears to be working correctly.
Hi Carla Siegert,
No the video test is not important. You can read more on how to interpret the results from the twilio test here: How do I use the Twilio network test to troubleshoot Talk agent calls?
Hi Vaughan,
As I mentioned the video test results are not required for Zendesk Talk.
The article also states at the end:
But let me talk to our documentation team to have this moved to the top, and in a highlighted note
Please sign in to leave a comment.