What are the network requirements for Zendesk Talk to work effectively?
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:
TCP: 80,443,843 outbound
UDP: 10,000 to 20,000 outbound
With the above ports they will need to be able to communicate to ALL of the following domains / IP addresses:
The full Zendesk public ip range needs to be accessible:
220.127.116.11/24, 18.104.22.168/27, 22.214.171.124/24, 126.96.36.199/21, 188.8.131.52/22, 184.108.40.206/20, 220.127.116.11/20, 18.104.22.168/18, 22.214.171.124/32, 126.96.36.199/32, 188.8.131.52/32, 184.108.40.206/32, 220.127.116.11/32, 18.104.22.168/32, 22.214.171.124/32, 126.96.36.199/32
Please be sure to check the link above to ensure that you have a complete list of Zendesk public IP's.
Twilio domains / ip's (our backbone provider):
With both the Zendesk and Twilio IP's/domains please ensure these are excluded from stateful packet inspection as not doing this can result in very high UDP/TCP connection times.
Once you have allowed connections to ALL of the above IPs and domains via the ports mentioned above (all ports need to access all domains and IPs 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.
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.
Client side setting to double check to ensure DSCP is working 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 do the following:
For a machine that is NOT on a domain:
1) Modifying this registry setting will allow you to specify the QoS setting that will be used based on Group Policy settings that you configure.
- HKEY_LOCAL_MACHINE > CurrentControlSet > Services > tcpip > QoS
The QoS Key may not exist, if it does not, you'll need to right click on tcpip and select "New Key". Type in the name as "QoS".
Once complete, select the QoS key and if it doesn't already existing create a new string value called "Do not use NLA". Set the value to 1.
It should look like the image below:
After you complete the registry changes, you will need to reboot for the settings to take effect.
For a machine that IS on a domain:
You control the QoS settings that are used for certain applications by designing different Group Policy rules.
To open up the Group Policy rules, go to a command line and type "gpedit.msc"
This will bring up the local group policy editor. Under Computer Configuration select "Policy Based QoS Settings", right click and select "Create New Policy". You will then run through a wizard interface to configure the QoS rules to use.
On the first screen you will be prompted to enter a Policy Name and specify a DSCP value.
Put "Zendesk Talk DSCP" as the Policy name, and specify a DSCP value of "46", and click "Next".
In the second screen you are prompted to determine which applications the policy applies to. Select "Only applications with the executable name" and enter "Chrome.exe", and select "Next".
In the third screen you can limit both the source and destination IP address. You do not need to enter any settings here. Just click "Next".
In the fourth and final screen, you'll want to select the protocol that the QoS applies to. For Zendesk Talk we will limit this 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.
Client side info 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":
Go to start --> and type in "cmd", right click the command icon and select "Run as Administrator"
To ensure that the "QWAVE" service is not disabled, paste the following into the command line that opened after completing the above,
net start QWAVE
Hit the enter key and you should see the following:
Then paste the following to set the startup type of "QWAVE" to automatic and hit the enter key on your keyboard:
REG add "HKLM\SYSTEM\CurrentControlSet\services\QWAVE" /v Start /t REG_DWORD /d 2 /f
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.