Troubleshooting Connection Issues
Our Desktop Recording Client works by streaming data in real-time over WSS (secure web sockets) to a media server hosted by us towards port 443.
The connection is established as soon as the user presses [Record Video], [Record Audio], or [Record Screen] on the initial screen.
Initial Connection
Depending on the Region setting on your environment and the location of the user, the initial connection attempt will be made against one of four ingestion servers across the world.
EU2 and CA1 regions
In case the 1st attempt fails, the Desktop Recording Client will make 30 more attempts to connect to the same region. If all 30 extra attempts fail, the message “Could not establish a secure websocket connection to the media server.” will be shown:
Fallback mechanism between the two US regions (US1 & US2)
If the initial connection attempt fails, the Desktop Recording Client will attempt to connect to the other US region. For example, if the user is closer to US1 (N. California) and the recording client fails to connect to US1, it will switch to US2 (New York) and try to connect to US2. In case the 2nd attempt fails, the Desktop Recording Client will continuously try to connect to the same region (US2 in our example) without stopping. During this process, the message “Connecting…” will be displayed in the center of the recording client.
Reconnection Mechanism
In case of a network problem resulting in disconnection, the Desktop Recording Client will try to reconnect 30 times before giving up.
Each of the 30 attempts to reconnect can timeout after 10 seconds. After each timeout or failed re-connection attempt, the recorder will wait between 0.5 and 5 seconds before making another attempt. Thus, it can take a maximum of 450 seconds ((10s timeout + 5s delay) * 30 attempts = 450 seconds = 7.5 minutes) for the recorder to spend all 30 attempts. This interval can be even higher if there’s anything blocking the JavaScript client side.
If a disconnection happens while recording, the recording process will continue, but a message will be shown to the user. If the connection is re-established, the data recorded while the connection was interrupted will start uploading to the media server while the recording process continues.
Why an established WebSocket connection might disconnect
- A busy or high latency WiFi network might cause continuously open websocket connections to disconnect.
- The Internet connection might fail (ISP problems, power failure, tripping over the router, etc.).
- Conditions on the network (proxy, firewall) have changed not allowing WebSockets connections anymore.
Connection Error messages
In case of a connection problem, the HTML5 desktop recorder will show one of the following messages:
Not Connected. Reconnecting in a few seconds
This message is shown when the first connection attempt ever to the media server fails.
Not Connected (wss). Attempting to connect in a few seconds…
This message is shown when a subsequent (re)connection attempt to the media server fails.
Connection timeout. Reconnecting in a few seconds…
This message is shown when a connection attempt times out after 10 seconds.
Not Connected. Reconnecting…
This message is shown when Pipe attempts to connect or reconnect. If the connection attempt fails right away, this message is shown for a fraction of a second. If the connection attempt fails through a time out, this message will be shown for the duration of the timeout (10 seconds).
Reconnected
Shown for a moment after a successful reconnect attempt.
Connection failures
Two different messages provide more specific details about connection failures:
Could not establish a secure websocket connection to the media server.
Displayed when all 31 initial attempts to connect to the EU2 or CA1 region are unsuccessful.
The secure websocket connection to the media server has been lost and a new connection could not be re-established.
Displayed when, after a connection is established, the connection is lost and all 30 attempts to re-connect are unsuccessful.
Causes:
- The user can’t establish a connection to our media servers (restrictive networks or proxies, very slow or high latency connections, etc.)
- The user looses Internet connection (ISP problems, power failure, tripping over the router, etc.)
- Very rare but theoretically possible: our media server is down for some reason
Recovering Unsaved Recordings
For recordings made with our Desktop Recording Client by capturing from the camera or screen, the ingestion media servers have a recording recovery mechanism in place that recovers the recording if, while streaming the recording (so while recording or uploading it), the connection is interrupted, and a new connection can’t be established. This mechanism is triggered only if the autosave option is enabled in the embed code (by default, it is enabled).
Desktop Recording Client
Recordings made by capturing from the camera or screen and streaming back to our ingestion servers
In case of a network problem resulting in disconnection, the Desktop Recording Client will try to reconnect 30 times before giving up. As shown above, this process can take up to 450 seconds and even more. That’s why the ingestion media server, under normal circumstances, will wait 15 minutes - from the moment the disconnection is detected server-side - before attempting to recover an unsaved recording. It needs to give the user all the time it needs to cycle through his 30 reconnect attempts.
Recordings made by uploading an existing recording
The recovery mechanism does not function with existing recordings uploaded through the desktop recording client.
Mobile Native Recording Client
Recordings made by uploading an existing recording
The recovery mechanism does not function with new or existing recordings uploaded through the Mobile Native Recording Client.
Using webhooks instead of the JS Events API
We recommend relying on Webhooks for integrating the Pipe Recording Client instead of relying on the JavaScript APIs because webhooks will trigger for recovered recordings.
When a disconnection is the result of the user navigating away, closing the tab, browser crash, or the window/tab being accidentally closed, the JS API events will not trigger. As a result, your JS functions will not trigger and any POST or GET requests (made within your JS) back to your server (to save the data) will never trigger. If the recording is recovered, webhooks will be triggered.
When the disconnection results from a network connection problem like a high latency connection, the JS will execute on the client, but any POST or GET requests might fail. If the recording is recovered, webhooks will be triggered.