Getting Started with Netscan

Table of Contents

  1. Reading Scan Results
  2. Understanding WebRTC Connectivity
    1. How Netscan Detects WebRTC Connectivity
    2. How Reliable Are the WebRTC Results
  3. How to handle the results

Reading Scan Results

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:

  • WebRTC Connectivity If the client is WebRTC capable and can perform a connection either it be Peer to Peer or via a proxy TURN Server.
  • Web Sockets Connectivity If the client is capable of Web Sockets connections and if a connection could be established with one of our servers.
  • Ping Latency What is the average ping time of the client using a combination of ICMP pings and Web Socket roundtrip echoes.
  • Network Environment We can reliably determine if the client is in a local network behind a NAT router and or if it supports ipv6.

You can read more about the Summary Object in the Result Explained article.

⬆ back to TOC

Understanding WebRTC Connectivity

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.

How Netscan Detects WebRTC Connectivity

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:

  • Inbound TCP The client accepts inbound TCP connections. This can be inferred by a STUN candidate on the Internet IP of the client. For a client to accept incoming TCP connections is has to have an actual Internet Address and not be behind a NAT router.
  • Inbound UDP The client accepts inbound UDP connections. Again, this can be inferred by a STUN candidate. UDP inbound connectivity can happen event if the client is behind a NAT router, due to the stateless nature of the UDP protocol. This is the single fact that enables NAT traversal and all the home based clients to perform a WebRTC connection.
  • Outbound TCP The client can perform outbound TCP connections on ports other than those of the web and secure web (80 & 443). This can be inferred by TURN candidates and performing XHR connections on high ports.
  • Outbound UDP The client can perform outbound UDP connections. We infer this from TURN candidates.

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.

How Reliable Are the WebRTC Results

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.

⬆ back to TOC

How to handle the results

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!

⬆ back to TOC