Technical details of the web thumbnail system.

 

 

Table of Contents

Technical details of the web thumbnail system. 1

Changelog: 2

Notes: 2

Impero Server. 2

Accessing the stack. 2

Complete list of required ports and addresses. 2

Thumbnail view.. 2

Preferred connections. 4

Diagrams. 5

Diagnostics. 9

Checking STUN access. 9

Common problems. 11

mDNS broadcast blocked by network configuration. 11

STUN blocked. 11

Strict NAT. 11

Teacher machine cannot connect to the TURN server. 11

Student machines cannot contact the TURN server. 11

Transparent Proxies. 11

 

 

 

 

Changelog:

Date

Changes

25 Jan 2021

Initial document

25 Jan 2021

Added diagnostics for access to stun.l.google.com

 

 

 

Notes:

Strictly speaking UDP is connectionless, but when dealing with bi-directional data streams like the ones in this system, they may be considered a connection as all networking hardware will be doing so.

 

Impero Server

All cloud enabled Impero Servers make an outbound web socket connection to the Impero Cloud Stack. This is then used as a bidirectional communication channel between the cloud stack and the Impero server. Impero refer to this as the connection service. The connection is always to port 443, but the server connected to will vary by geographical region.

 

Accessing the stack

The teacher uses the Chrome browser to login to the Impero Cloud Stack. This consists of many transient connections between the browser and cloud stack. All are outbound from randomly allocated ports to port 443 on the cloud stack.


 Complete list of required ports and addresses

The following minimum specification document covers all the ports and addresses required to make a connection to edpro.cloud and display thumbnails.
Impero Education Pro - Minimum Requirements

 

Thumbnail view

When the teacher views the thumbnails view on EdPro.cloud a WebRTC connection is made to the client running on each student machine in the following way.

  • Teacher Browser sends a request for a remote connection in proprietary format to the Impero Cloud stack
  • The Impero Cloud Stack sends a proprietary message to the Impero Server the client is connected to
  • The Impero Server forwards the message to the client.
  • The Teacher browser contacts the Impero Cloud Stack to get a list of possible communication routes.
  • The Impero Cloud Stack queries Xirsys to find the best of their servers to use. This varies due to load balancing. In the example here eu-turn8.xirsys.com is used.
  • Teacher Browser creates a temporary mDNS address.
  • The Teacher Browser uses stun.l.google.com on UDP port 19302 to determine the public facing IP of the gateway.
  • The school’s router rewrites the STUN packet source address and port. This address and port then have incoming data routed back to the teacher machine.
  • Google’s STUN server replies to the STUN message indicating the IP and port where it received the packet from.
  • The teacher Browser connects* to eu-turn8.xirsys.com on port 80 using a UDP protocol. Xirsys then do the following:
    1. Open a random UDP port.
    2. Informs the Teacher browser of the IP and port just opened.
    3. Tunnels traffic between this assigned port and the Teacher Browser via the UDP connection made by the browser.
  • The Teacher Browser connects to eu-turn8.xirsys.com on port 3478 using a UDP protocol. Xirsys then do the following:
    1. Open a random UDP port.
    2. Informs the Teacher browser of the IP and port just opened.
    3. Tunnels traffic between this assigned port and the Teacher Browser via the UDP connection made by the browser.

 

  • The teacher Browser connects to eu-turn8.xirsys.com on port 80 using a TCP protocol. Xirsys then do the following:
    1. Open a random UDP port.
    2. Informs the Teacher browser of the IP and port just opened.
    3. Tunnels traffic between this assigned port and the Teacher Browser via the UDP connection made by the browser.

 

  • The teacher Browser connects to eu-turn8.xirsys.com on port 3478 using a TCP protocol. Xirsys then do the following:
    1. Open a random UDP port.
    2. Informs the Teacher browser of the IP and port just opened.
    3. Tunnels traffic between this assigned port and the Teacher Browser via the UDP connection made by the browser.

 

  • The teacher Browser connects to eu-turn8.xirsys.com on port 443 using a TCP protocol. This connection is encrypted with TLS. Xirsys then do the following:
    1. Open a random UDP port.
    2. Informs the Teacher browser of the IP and port just opened.
    3. Tunnels traffic between this assigned port and the Teacher Browser via the UDP connection made by the browser.

 

  • The teacher Browser connects to eu-turn8.xirsys.com on port 5439 using a TCP protocol. This connection is encrypted with TLS. Xirsys then do the following:
    1. Open a random UDP port.
    2. Informs the Teacher browser of the IP and port just opened.
    3. Tunnels traffic between this assigned port and the Teacher Browser via the UDP connection made by the browser.

 

  • Teacher Browser compiles a list of which of the above actions resulted in success and therefore may be a way for the student to connect to the teacher browser.
  • Teacher Browser sends this list of possible connections to the Impero Cloud Stack
  • Impero Cloud Stack sends this list of possible connections to the Impero Server
  • The Impero Server sends the list to the student

 

  • The Impero student machine uses stun.l.google.com on UDP port 19302 to determine the public facing IP of the gateway.
  • The student’s router rewrites the STUN packet source address and port. This address and port then have incoming data routed back to the teacher machine.
  • Google’s STUN server replies to the STUN message indicating the IP and port where it received the packet from.
  • The Student machine passes its real IP and a chosen port as well as the result from the STUN lookup to the Impero server.
  • The Impero server passes this information to the Cloud Stack.
  • The Cloud Stack passes the information to the Teacher Browser.

Now both the teacher and student have a list of ways to communicate with the other end.

  • Impero client on student machine broadcasts an mDNS query to resolve the teacher IP address.
  • Teacher PC receives the mDNS broadcast and responds with its real IP address.
  • The two machines try the combinations of addresses until a connection is achieved.

 

Preferred connections.

The best connection is a direct host to host connection, this can only be achieved if the two machines are on the same network.

The next best option is to use the public IP address obtained from the STUN query. This option will not usually be possible if both machines are on the same network as most routers do not support it.

The least favourable type of connection is via the TURN server (Xirsys in this case) where data must travel to the third-party server and be re-directed to the other machine. This introduces delays and consumes significant bandwidth.

 

 

 

Diagrams.

To visualise the above, the following illustrations may help.

A picture containing graphical user interface

Description automatically generated

A picture containing diagram

Description automatically generated

 

 

Graphical user interface, application, Teams

Description automatically generated

 

 

Diagnostics.

It is best to diagnose the issues using a single client in isolation. To so this, open the thumbnails view of a group on the teacher machine and bring one to full screen. Refreshing the page will cause the WebRTC system to reset with just the single connection.

On the teacher machine, opening a tab to chrome://WebRTC-internals shows the state of all of the WebRTC connections on other tabs. Refreshing the single full screen view after opening this tab clears up any old connections.

Wireshark can also be used but does not tend to reveal much more than the WebRTC-internals.

May firewalls can give information about what rules have blocked traffic and log what connections have been blocked. These are incredibly useful.

For testing internal connectivity Ping and Tracert on the command line can be useful, though it is common for firewalls to block some traffic but not all. Therefore there may be occasions where works, but the connection doesn’t.

Checking STUN access.

To check whether a machine can access the STUN server from that machine, open a Chrome browser and navigate to https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ on there, click “Gather Candidates” if the machine can access the STUN server, a line with “rtp srflx” will appear quickly in the Component type column.
To remotely check whether a student PC has access to the STUN server, open the windows console and find the machine in the computer list. Expand the computer and expand the properties field. If the Public IP appears valid (not 0.0.0.0) then the machine can access the STUN server.

 

A typical view of the WebRTC-internals page is shown here with explanations of the fields.

Page field

Explanation

https://beta.edpro.cloud/teacher/live/desktop/7NBFKN/client/3, { iceServers: [stun:stun.l.google.com:19302, stun:eu-turn3.xirsys.com, turn:eu-turn3.xirsys.com:80?transport=udp, turn:eu-turn3.xirsys.com:3478?transport=udp, turn:eu-turn3.xirsys.com:80?transport=tcp, turn:eu-turn3.xirsys.com:3478?transport=tcp, turns:eu-turn3.xirsys.com:443?transport=tcp, turns:eu-turn3.xirsys.com:5349?transport=tcp], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "unified-plan" },

 

This shows the initial parameters used then trying to create the connection. The most useful part is which turn server is being used.
 eu-turn3.xirsys.com in this case.

Time                                                   Event

22/01/2021, 13:49:26    > setRemoteDescription

22/01/2021, 13:49:26    > setRemoteDescriptionOnSuccess

22/01/2021, 13:49:26    > signalingstatechange

22/01/2021, 13:49:26    > createAnswer

22/01/2021, 13:49:26    > createAnswerOnSuccess

22/01/2021, 13:49:26    > setLocalDescription

22/01/2021, 13:49:26    > setLocalDescriptionOnSuccess

22/01/2021, 13:49:26    > signalingstatechange

22/01/2021, 13:49:26    > icegatheringstatechange

22/01/2021, 13:49:26    > iceconnectionstatechange

22/01/2021, 13:49:26    > iceconnectionstatechange (legacy)

22/01/2021, 13:49:26    > connectionstatechange

22/01/2021, 13:49:26    > icecandidate (host)

22/01/2021, 13:49:26    > icecandidate (srflx)

22/01/2021, 13:49:26    > icecandidate (relay)

22/01/2021, 13:49:26    > icecandidate (relay)

22/01/2021, 13:49:32    > icegatheringstatechange

22/01/2021, 13:49:32    > iceconnectionstatechange

22/01/2021, 13:49:32    > iceconnectionstatechange (legacy)

22/01/2021, 13:49:32    > connectionstatechange

22/01/2021, 13:49:32    > onRemoteDataChannel

22/01/2021, 13:50:06    > icecandidateerror

22/01/2021, 13:50:06    > icecandidateerror

This is a list of events that occur during making the connection. Things to look out for:

missing cecandidate (srflx) which would indicate a problem communicating with stun.l.google.com

no icecandidate (relay) entries, which would indicate a problem communicating with the TURN server

 Some icecandidateerror lines are normal as long as some icecandidate (relay) lines are present.

> Stats Tables

> RTCCertificate_09:3B:E2… (certificate)

> RTCIceCandidatePair_1oC/tlGf_BYvlRqnf (candidate-pair)

> RTCIceCandidatePair_1oC/tlGf_MHx9ZIM5 (candidate-pair)

> RTCIceCandidatePair_3rnqxjEd_BYvlRqnf (candidate-pair)

Expand RTCIceCandidatePair lines to find the active pair with a state of succeeded. The candidates being used can then be found from the RTCIceCandidatePair line.

> RTCIceCandidate_BJLfmOF/ (local-candidate)

> RTCIceCandidate_BYvlRqnf (remote-candidate)

> RTCIceCandidate_CTth+Uq7 (remote-candidate)

> RTCIceCandidate_ComjvkPM (local-candidate)

Descriptions of the candidate routes. At least two remote candidates should be present.

 

 

Common problems.

 

mDNS broadcast blocked by network configuration.

This prevents the student machine from finding the IP address of the Teacher machine and therefore blocks the direct connection. A direct connection is by far the best option as the point to point data transfer is faster and uses no bandwidth on any part of the network not in the direct communication line. If enabling mDNS broadcasts is not possible, Google provide a Group Policy setting to allow the Teacher Browser to find its real IP address. With this option, the student machine will make a direct connection wherever possible.

 

STUN blocked.
 If the WebRTC-internals doesn’t show an icecandidate (srflx) event then the STUN request to stun.l.google.com from the teacher machine has failed. If there is only one RTCIceCandidate with the (remote-candidate) label, the STUN request from the student side has failed. The STUN server IP address resolved from stun.l.google.com is dynamic. Great care must be taken with the firewall rules to account for this.

NOTE: If the STUN server is blocked on the student side and no local connection can be made, the thumbnail view is not possible.

 

Strict NAT.

The STUN protocol is used to try to setup a UDP channel for incoming data from outside the local network. This will normally open a UDP port on the outside of the router that will route all data to the teacher machine. If the router uses strict NAT, the port is limited to receiving data from the destination of the packet that caused it to open. In this case that address will be stun.l.google.com so no other addresses will be able to send data to the machine via this route. This means connections via the public IP addresses will not work. This may result in falling back to the less efficient TURN based connections, of may result in no connection being made at all.

 

Teacher machine cannot connect to the TURN server.

If the WebRTC-internals don’t show any icecandidate (relay) events, then the teacher machine cannot connect to the TURN server. The TURN server connections should be a last resort but should be the reliable fallback.

 

Student machines cannot contact the TURN server.

This is much harder to diagnose as the symptoms of a strict NAT on the student side are the same. A general problem here is that the student side of the TURN server route is not to a known port therefore firewalls must be configured to allow access to all ports on all Xirsys servers in the relevant region.

 

Transparent Proxies.

Ports 80 and 443 may be filtered by a transparent proxy These proxies interfere with the TURN connection and prevent the system from using those routes. The Xirsys addresses should be excluded in all proxy configuration to avoid these issues. The WebRTC-internals will show icecandidateerror for connections on ports 80 and 443 if this is the case.