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'll likely need to configure it to work properly with Talk. If you can't make these changes yourself, talk to your IT department. Making these 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 might speak over the top of each other. The lower the latency, the more your call will seem like two people talking as if they are in the same room. As latency increases, you’re likely to be left with interruptions and pauses that make people talk over each other.
• Jitter: In effect, jitter is the change in latency over time. Jitter usually sounds like interference, or someone is trying and failing to plug in their mic. Callers might not hear the other side.
• Packet Loss: When voice signals are digitized and transmitted, they are split into packets. Some of these packets fail to reach their destination – small pieces of the audio signal will be missing, resulting in audible distortion on the call.

Use the information in this article to help you minimize network problems, and to get the best from Talk. For general information about getting ready to use Talk, see Preparing to use Zendesk Talk. To rule out network issues, everything should be wired, wired 3.5mm jack headset, 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 for each agent, meaning a minimum 50mbps line.  

When troubleshooting network issues, try closing applications like Netflix, Spotify, YouTube, etc.

Note: Talk will not work with a Proxy, MPLS or a VPN setup due to a service that runs in the background called GLL. This service decides on the best network path to run the call through. If you use either of these it will not give the true location of your agents and as such cannot route the call efficiently, potentially leading to latency and other call quality issues. If you must use a VPN or Proxy or MPLS, please exclude traffic for the Zendesk / Twilio domains (including your FQDN subdomain.zendesk.com) and the IP addresses listed in this article to run through VPN. Note: Zendesk Talk is not compatible with virtual desktop environments.

This article contains the following topics:

• Ports, domains, and IP addresses required by Talk
• Using DSCP
• Further troubleshooting

Ports, domains, and IP addresses required by Talk

Your network might need to be adjusted to allow Talk to work. Any changes need to be allowed on all firewalls, routers, switches, load-balancers, and any other hardware or software that could block or manipulate Talk network traffic.

Ports

Talk uses the following ports (outbound):

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

The above ports need to be able to communicate to all of the following domains and IP addresses.

Zendesk is hosted by Amazon Web Services (AWS). To get a list of all AWS IP ranges you'll need to allow, see Configuring your firewall for use with Zendesk.

Additionally, allow your Zendesk subdomain on your network, so: *.{{yoursubdomain}}.zendesk.com .

Twilio domains

Twilio is the voice provider for Zendesk Talk. This list contains the Twilio domains that you'll need to allow access to.

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-jp1.twilio.com

chunderw-vpc-gll-sg1.twilio.com

chunderw-vpc-gll-us1.twilio.com

matrix.twilio.com

eventgw.twilio.com

chunderw-vpc-gll-de1.twilio.com

gwasset.twilio.com

sdk.twilio.com

Twilio IP addresses

This list contains the Twilio domains that you'll need to allow access to.

Important: While we endeavour to contact our customers to advise them of the recent additions to this list, double-check with your network team to ensure they have added them to your existing firewall, load balancer, and other network equipment rules.

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

Recently added

54.244.51.0/24	44.234.69.0/25
3.1.77.0/24	3.235.111.128/25
3.112.80.0/24	18.141.157.128/25
3.122.181.0/24	18.180.220.128/25
18.228.249.0/24	3.249.63.128/25
3.104.90.0/24	3.7.35.128/25
72.52.10.0/24	18.230.125.0/25
65.9.130.0/24	3.25.42.128/25

Additional considerations

The following additional network configurations must be carried out:

• Ensure that both the Zendesk and Twilio IP addresses and domains are excluded from stateful packet inspection (SPI), or you might experience high UDP or TCP connection times.
• In some cases, customers have advised that if a switch or other network hardware is plugged into an incorrectly configured Cisco Smart Switch it can override the allowed domains and IP addresses. To prevent this from happening, do not plug in hardware that is not meant to be plugged into a smart switch and ensure with your network team that it is configured to reflect the settings above.
• Your firewall must allow outgoing UDP to the public internet from the browsers that will be using 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 SIP Application Level Gateway (ALG) function or Stateful Packet Inspection (SPI), disable both of these functions on networks that you are using Zendesk Talk.
• Talk will not work with MPLS or VPN. Do not allow traffic for the domains and IP addresses listed to run through a VPN.

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

Using DSCP

Guidelines to implement DSCP can be found here.

DSCP tags in packets are useful for letting network appliances know how to prioritize traffic. By default, Talk calls get 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 that real-time media can be prioritized above other network traffic. The Differentiated Services Field is located in the IPv4 header TOS octet or the IPv6 Traffic Class octet. A differentiated services-compliant network node (for example a router) includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value.

With 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 below are 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. If you see a Relaunch button click it 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 will enforce 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 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.

The above steps will ensure that that WebRTC packets get prioritized, which will make the Dialer work optimally.

You will need to force client machines to pick up this new Group Policy for the above to work. Usually a reboot will sort it.

To check DSCP tags for machines on a domain, follow these steps:

1. Open up the Group Policy rules by typing "gpedit.msc" in the command line.
2. Under Computer Configuration, select "Policy Based QoS Settings."
3. Right click, then select "Create new Policy."
4. A wizard interface will open to configure the QoS rules to use.
5. On the first screen, enter "Salesloft DSCP as the Policy name and specify a DSCP value of '46'."
6. Click Next.
7. On the second screen, select "Only applications with executable name," then enter "Chrome.exe."
8. Click Next.
9. On the third screen, you do not need to enter any settings; click Next.
10. On the final screen, select the protocol the QoS applies to. For the Salesloft Dialer this will be limited to UDP.

Checking DSCP tags for machines not on a domain

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

To check DSCP tags for a machine not on a domain, follow these steps:

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. Enter the name "QoS."
4. Once complete, 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 might encounter issues with Zendesk Talk if you are using a computer with a Windows operating system. Zendesk Talk customers must have the service, "Quality Windows Audio Visual Experience" set to startup type "Automatic" and not the default value "Manual".

To ensure QWAVE is enabled and startup is automatic

1. In 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 has an automatic startup type permanently; 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 is now set to startup type "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 (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 will save you time doing each computer manually.

Further troubleshooting

In addition to the steps above, you can also use the Twilio SDK to examine the quality of your calls. For more information, see Voice Insights SDK Events Reference.