Rendered co-browsing

Rendered co-browsing refers to the specific co-browsing technology that underlies the universal co-browsing, document co-browsing, whiteboard, and conversation recording product features of Unblu.

For each rendered co-browsing session the Unblu server opens a headless browser on the server. The browser is referred to as "headless" because it runs without its own user interface. However, the visual result of its rendering process is captured and then streamed via WebRTC to both the visitor’s and agent’s browser.

Both the visitor’s and agent’s browsers display the video stream from the headless browser in a "browser within a browser". The rendered content appears within the "inner" browser.

Two separate communication channels, one from the visitor back to the headless browser and one from the agent back to the headless browser, allow either party to control the headless browser with keyboard and mouse.

The universal co-browsing, and document co-browsing, and conversation recording features of Unblu are simply three applications of the rendered co-browsing technology.

On the server side, the Rendering Service is responsible for managing the headless browsers. Each headless browser runs inside its own container (such as Docker).

In clustered Unblu installations each of these containers is in turn run within its own Kubernetes pod. For each rendered co-browsing session, a new pod is spun up in the cluster by the Rendering Service. When a session ends the pod is removed.

In an application server installation (and indeed in a standalone installation, though this is rarely used) the containers are hosted within a Docker environment within which the Rendering Service can add and remove headless browser containers on demand.

WebRTC is the technology used to stream the view from the headless browser to both visitor and agent. It’s a real-time peer-to-peer video and audio communications technology that’s now built into most browsers, requiring no plugins to work.

In the rendered co-browsing case there are at least three peers participating:

One video stream is established from the headless browser to the visitor and another from the headless browser to the agent. There are also two signal channels (implemented separately from WebRTC) in the reverse direction that allow either party to control the browser through keystrokes and mouse input.

For more information on WebRTC, refer to webrtc.org and Introduction to WebRTC in Unblu.

At its core WebRTC is a peer-to-peer system, meaning that it’s designed to connect two WebRTC endpoints (like two browsers) directly to each other and stream audio and video back and forth without any intervening server. However, for true peer-to-peer communication to work, both parties must be accessible to each other on the same network. In most real-world scenarios involving communication across the internet firewalls and network address translation devices typically prevent this. In the rendered co-browsing scenario this is definitely the case, since the headless browser in the Rendering Service, being part of the Unblu server, is behind a firewall.

Taken together, these restrictions mean that for all practical purposes true peer-to-peer connection for rendered co-browsing would be impossible since it would involve unacceptable security practices like opening up ports in a corporate firewall.

Luckily, WebRTC supports techniques for navigating around these kinds of network restrictions. The specific mechanism used in our case is to connect the WebRTC peers via something called a TURN server.

The TURN server is a specialized server that resides at a publicly accessible network address on the internet. WebRTC peers use the TURN server as an intermediary to communicate with each other.

The types of network restrictions that we discussed above, and that prevent true peer-to-peer communication, typically apply to incoming connections. For example, a typical firewall might prevent all incoming traffic expect HTTP requests on port 80 and HTTPS requests on port 443. However, such a firewall would usually allow outgoing requests from inside the firewall and, crucially, also permit the transit of the responses to those requests back through the firewall.

This means that a component behind a firewall can establish a connection to something outside, as long as:

A TURN server provides exactly this kind of target for both parties in a WebRTC session. Even if neither party can receive unsolicited connections, they can both initiate connections. The TURN server is purposely located on the internet in such a way that it can accept connections.

So, the WebRTC parties both initiate a connection with the TURN server and the TURN server bridges the gap and connects the parties.

Depending on your deployment model and your other requirements there are three options for deploying the TURN Server for rendered browsing:

WebRTC is always end-to-end encrypted. This means that all the data flowing back and forth between the communicating parties is encrypted the entire way. Adding a TURN server maintains the end-to-end encryption of video content. However, the IP addresses of any participants using it are exposed to the TURN server.

Considering the two deployment issues above:

Therefore, from an operational perspective, we recommend the Unblu Cloud TURN server.

The code snippet below shows how you can apply different behavior when within a universal co-browsing session.