What are the network requirements for Zendesk Talk to work effectively?
The most important thing is a good solid reliable network, so if you can have your agents hard wired with wifi disabled this will be a real advantage for you. Zendesk Talk works with the webRTC technology and in some cases your network will need to be adjusted to allow the Talk application to work. These changes should be allowed on all firewalls, routers, switches, load-balancers, and any other hardware or software that could block or manipulate network access to the destinations listed below.
Zendesk Talk uses the following ports (outbound):
- TCP: 80, 443
- UDP: 10,000 to 20,000
The above ports will need to be able to communicate to all of the following domains/IP addresses.
See the full Zendesk public ip range for a complete list of Zendesk public IP's.
Below are the Twilio domains and IP's you will need to allow access to.
Once you have allowed connections to all of the above IP's and domains via the ports mentioned above (all ports need to access all domains and IP's listed) there should be no issues with Zendesk Talk making and receiving calls.
In some instances customers have advised that if a switch or other network hardware is plugged into an incorrectly configured Cisco Smart Switch it can override the whitelisting, to get around this I recommend that you do not plug any hardware other than hardware that is meant to be plugged into a smart switch, and ensure with your network team that it is configured to reflect the settings above.
Trouble with audio after implementing the suggestions in this article? Try a 3.5mm jack headset (Not USB, not Bluetooth) some customers have found that this is useful in achieving optimum audio quality for their Talk setup.
DSCP tags in packets are useful for letting network appliances know how to prioritize traffic. By default Zendesk Talk traffic call gets a DSCP tag of 46. If congestion is an issue on your network, consider implementing DSCP on your network/domain. To implement DSCP see the details below:
- Twilio Client 1.3 enables DSCP by default in compatible browsers (Google Chrome at launch).
- Capable browsers (Chrome) will tag WebRTC media packets, enabling differentiated handling on a LAN, so that real-time media can be prioritized above other network traffic. Differentiated Services Field is located in the IPv4 header TOS octet or the IPv6 Traffic Class octet. A differentiated services-compliant network node (e.g. 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 Client 1.3 sent RTP packets will have a DiffServ codepoint on their local Wireshark packet captures. When we 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
Keep in mind that you should use a browser that supports webRTC. If you have difficulties please try using Talk with the latest stable version of a webRTC-supporting browser, e.g. Chrome or Firefox. If you implement DSCP (recommended) then use Chrome (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 and if there is a 'Relaunch' button click it, this will 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. To make everything play nice, please either implement a group policy that will enforce DSCP or if your computers are not on a domain then do it on a machine by machine basis.
To ensure Windows is not stripping out the DSCP tags, you will need to perform the following steps, depending whether your machine is on a domain or not.
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
- Navigate to - HKEY_LOCAL_MACHINE > CurrentControlSet > Services > tcpip > QoS
- If the QoS Key does not exist, right click tcpip and select "New Key".
- Enter the name "QoS".
- Once complete, 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.
Your window should resemble the image below:
- Reboot for the settings to take effect.
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.
To check DSCP tags for machines on a domain
- Open up the Group Policy rules, by typing "gpedit.msc" in the command line.
- Under Computer Configuration, select "Policy Based QoS Settings.
- Right click, then select "Create new Policy."
A wizard interface will open to configure the QoS rules to use.
- On the first screen, enter "Zendesk Talk DSCP as the Policy name and specify a DSCP value of "46".
- Click Next.
- On the second screen, select "Only applications with executable name", then enter "Chrome.exe".
- Click Next.
- On the third screen, you do not need to enter any settings, click Next.
- On the final screen, select the protocol the QoS applies to. For Zendesk Talk this will be limited to UDP.
Additionally you can select different port ranges on this page, We don't need to worry about setting specific port ranges for now.
Once complete your rules should look something like this:
The above steps will ensure that that WebRTC packets get prioritized which will make Zendesk Talk 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.
Requirements for Windows operating system users
You may encounter issues with Zendesk Talk if you are using a computer with a Windows operating system. Zendesk Talk customers need to have the service, "Quality Windows Audio Visual Experience" set to startup type "Automatic" and not "Manual" as this is the default.
With this in mind we recommend that everyone using Zendesk Talk on a Windows machine should carry out the following steps to ensure the "QWAVE" service is both enabled and has startup type "Automatic":
To ensure QWAVE is enabled and startup is automatic
- Navigate to Start, then type "cmd".
- Right click the command icon, then select "Run as Administrator".
- Paste the following into the command line:
net start QWAVE
- Hit the enter key. You should see the following.
- Paste the following to set the startup type to automatic:
REG add "HKLM\SYSTEM\CurrentControlSet\services\QWAVE" /v Start /t REG_DWORD /d 2 /f
- Hit the Enter key.
And thats it, the "QWAVE" service is now set to startup type "Automatic". If you encountered an error when following the above steps, you may need to have a member of your I.T team or a computer administrator perform them.