Talkdesk Network Test Tool provides the user with a series of widgets displaying valuable information regarding location and connection details, namely:
To proceed with the test, please insert your email and a reason for doing it. Afterward, you will have access to the Start option.
Throughput
The Throughput Widget tests for the data channel throughput. This can be used as a gross estimate to the number of concurrent sessions potentially available.
The number of sessions is calculated based on the codecs used in a session and the average bitrate necessary for good transmission of these codecs in a WebRTC session. For G.711, this is calculated as 100kbps per session and for Opus voice calls, this is calculated as 50kbps per session. This test connects a data channel via the TURN servers of the tested infrastructure, sending data payloads of 1,024 bytes each over the channel for a few seconds and measuring the rate at which they are received. It is performed by using the SCTP protocol relayed via TURN.
This test gives a global indication of the available throughput for the network being used from the perspective of the specific machine running the test. It should be taken into account here that SCTP has its own throttling mechanism which is slightly different than the one used by audio and video transmission over WebRTC.
|
Maximum |
The maximum throughput measured throughout the test conducted. |
|
Average |
The average throughput achieved during the test conducted. |
|
Minimum |
The minimum throughput measured throughout the test conducted. |
Things to notice
Low minimum throughput, as well as the high variance between minimum, average and maximum, may indicate a connection that is unstable and jittery. If you see this, expect to see the same in jitter data collected in other tests conducted and further explained.
Call Quality
The Call Quality Widget tests for the actual session quality when connecting a WebRTC session with Talkdesk.
|
MOS Score |
Mean Opinion Score. A value between 1-5 indicating a subjective quality measurement. The verbose explanation next to the number is usually enough. |
|
Round Trip |
The time it takes for a packet to be sent and a reply to be received back. The shorter the roundtrip, the higher the media quality. Jitter - Is the accuracy of the packets showing up in the right order at the destination. |
|
Packet Loss |
Percentage of packets lost in the test. The lower the value, the higher the media quality. |
|
Jitter |
The jitter of the session in the test. Corresponds to the accuracy of the packets showing up in the right order at the destination. The higher the value, the lower the media quality. |
Things to notice
Bad scoring immediately means low media quality. Specifically, since this tests an actual WebRTC session towards Talkdesk.
All links in the chain from sender to receiver can cause a drop in mean opinion score. Everything from a human's health to audio and video equipment to computer settings can cause a degradation in communications’ quality. However, network effects are most readily apparent and measurable on these calls - jitter, latency, and packet loss lend themselves to numerical measurement and have a direct effect on perceived call quality.
Other widgets provide more hints to the reasons why the quality is low (type of connection, capacity, etc).
Turn Connectivity
The Turn Connectivity Widget tests the connection time of the TURN servers in your deployment. It does so over UDP, TCP, and TLS.
The results shown indicate the time it takes a connection to be established between the machine being tested and the TURN server. This time includes gathering the candidate, connecting to it and negotiating any necessary certificates.
If any of these connectivity checks fail, the numeric round trip time will be replaced by a red X mark.
WebRTC media traffic takes place over UDP as much as possible to reduce latency and improve media quality. When direct UDP connections aren’t available, we resort to the use of TURN servers where we can connect WebRTC sessions over UDP, TCP or TLS - as needed for the given scenario.
|
UDP |
The time it takes to create an initial full connection to the TURN server using UDP. |
|
TCP |
The time it takes to create an initial full connection to the TURN server using TCP. |
|
TLS |
The time it takes to create an initial full connection to the TURN server using TLS. |
Things to notice
If UDP is blocked and marked with a red X, this means that your WebRTC sessions either don’t get connected at all or that their quality will be degraded by the use of either TCP or TLS. It is highly recommended that the network you use be open for UDP traffic and configured properly to be reachable for live media exchange.
The number is no indication of latency or roundtrip - only on the initial connection time.
Location
The Location Widget looks for the geolocation of the user. It does that by making use of the public IP address the browser is using.
|
IP |
The public IP address of the browser conducting the test. This is where the test sees the request coming from. |
|
City |
By using an external geoIP service, we convert the IP address to a city. The accuracy of the city is usually 50-75%. |
|
Country |
By using an external geoIP service, we convert the IP address to a country. The accuracy of the country is usually 95-99%. |
|
Org. |
The organization/carrier/service provider who owns the IP address. |
Things to notice
Sometimes, there is a gross mismatch between the known and the assumed location of the user. This can be attributed to either stale information about the IP address in our database or it can be an indication that the user is behind a VPN or configured with an HTTP proxy. In the case of a VPN or a proxy, what we see in our service is the public IP address of the proxy server itself.
Having a configured proxy or VPN automatically affects the media quality. If the proxy/VPN is located far from the user’s machine, this will introduce further latency and media quality degradation.
Bandwidth Speed
The Bandwidth Speed Widget runs an HTTPS speed test from the user’s device to our closest data center location.
This test gives a general indication of the link quality, hinting at the availability of a fiber connection, ADSL, or other. It also gives an estimate of the upper limit of the connection speed available between the user’s location and our infrastructure.
|
Best Region |
The best region is the elected speed testing data center selected to conduct the test. It is selected based on the latency of the DNS request and the geoIP of the client versus the available data centers. |
|
Uplink |
Shows the uplink speed of the connection. The speed at which an HTTP connection can send data from the client to the server. |
|
Downlink |
Shows the downlink speed of the connection. The speed at which an HTTP connection can send data from the server to the client. |
|
Jitter |
Calculated by conducting a quick succession of short ping tests, checking the delay variation in the replies’ arrival time. |
Things to notice
WebRTC sessions prefer sending media over UDP and need low latency to establish real-time sessions.
The bandwidth speed test does not focus on the needs of WebRTC, but rather on the link capacity. This test takes place over HTTPS (a TLS connection), sending and receiving a large static file and calculating the time it takes to send it over the wire.
From the information collected, you can deduce the type of connection and its symmetricity.
The higher the uplink and downlink values and the lower the jitter values, the better.
DNS Lookup
The DNS Lookup tests the reachability and connectivity to a list of HTTPS or WSS addresses.
By doing this test, a connection to the servers used for the ongoing operation of the service (not necessarily directly linked to WebRTC) is established, to make sure they are accessible from the browser.
If none of the addresses result in a successful connection, some or all parts of your service might not work.
The test also checks and logs the time it takes to connect to the servers.
| Connected | The number of connected addresses out of the total that was attempted. |
| Average Connection Time | The average time it took to connect to the servers. |
| Highest Connection Time | The highest time it took to connect to one of the servers. |
| Shortest Connection Time | The shortest time it took to connect to one of the servers. |
Things to notice
If any of the addresses is unreachable, there’s a good chance the service won’t work.
When there are high connection times, it may indicate a routing issue.
The log includes the details of the failed connection as well as connection times.
|
📎 Note
|