After each scan Netscan provides you with the Results Data Object (RDO), a JSON object containing all the results from the tests and a summary. The summary should be all you need to make any runtime product decisions.
The Summary provides you our best guess for:
You can read more about the Summary Object in the Result Explained article.
Please take a look at our Understanding WebRTC Connectivity blog post, it explains how things work in simple language, it's a 4 minute read.
By employing STUN and TURN servers we initiate a WebRTC connection on the client and collect all the generated Candidates. Each candidate is analyzed and turns on one of the following switches:
With these four switches we can then proceed to infer the overall WebRTC connectivity of the client. If all switches are false then there can be no connection. If any of the outbound protocols is true then a WebRTC connection can be performed. And if any of the inbound protocols is true then a Peer to Peer WebRTC connection can be performed.
The WebRTC connectivity results are "best guesses", they emulate what is actually going on during the connectivity negotiation between the peers. However reality can and always is surprising. There is a 10% chance the client can perform the contrary of what the connectivity tests suggested.
For example even though connectivity tests pass the client may not eventually be able to establish a WebRTC connection because of content based firewalls, other peer's IP being blocked or a number of other unforeseen and undetectable issues. The opposite is also possible, when no connectivity is detected it is still possible to establish a connection through a TLS / DTLS TURN connection (the secure TURN connection).
So the ultimate test is to actually try and perform the WebRTC call.
The optimal way to use Netscan is for troubleshooting and network monitoring purposes. For example attach a Network scan on every ticket generated from your support portal, that way your Customer Service will be miles in front of the troubleshooting process since they'll have critical information about the client.
If you are using WebRTC you should use Netscan when a failed call occurs to study why the failure happened and what you can do about it.
During runtime you should advise the user of their detected connectivity. Meaning, provide a warning in case poor or no connectivity was detected. You should not forbid your user from attempting a connection since it is possible the connection can be established.
A "poor connectivity" condition can also be inferred by examining the other network environment information available through Netscan's Result Data Object (RDO), like XHR and Websockets ping latency tests, they should not be higher than 100ms or if it's behind an http proxy.
However the applications and integrations are boundless, we'd love to hear how you use Netscan in your application!