Contact usRequest a demo

Rendered co-browsing

Overview

Rendered co-browsing refers to the specific co-browsing technology that underlies the universal co-browsing, server-based 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, server-based document co-browsing, and conversation recording features of Unblu are simply three applications of the rendered co-browsing technology.

  • In a universal co-browsing session, the headless browser is used by the agent and visitor to view any accessible website or web application.

  • In a server-based document co-browsing session, the headless browser is used by the agent and visitor to view a document that has been uploaded to the server by one of the parties.

  • During conversation recording, the headless browser acts as an additional participant in a conversation, and the audio or video content streamed to it—​audio and video calls as well as any collaboration layers used—​is recorded.

Rendering Service

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). Each of these containers is in turn run within its own Kubernetes pod. For each rendered co-browsing session, the Rendering Service spins up a new pod in the cluster. When a session ends the pod is removed.

WebRTC

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:

  • A headless browser (in the Rendering Service on the Unblu server)

  • Each visitor’s browser

  • Each agent’s browser

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.

Network restrictions

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.

  • The agent browser in an on-premises installation is often behind the same firewall as the Rendering Service. In theory, it could contact the Rendering Service directly (though there may be other restrictions, depending on the internal details of the corporate network). In a cloud scenario, the agent browser accesses the Unblu Cloud over the internet and is therefore also outside the firewall.

  • The visitor browser is always outside your organization’s firewall. Additionally, is often behind its own NAT.

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.

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:

  • the target on the outside is itself not behind a firewall

  • the component on the inside initiates the connection

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.

TURN server deployment options

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

  • Unblu Cloud service

  • Unblu on-premises with the Unblu Cloud TURN server

  • Unblu on-premises with on-premises TURN server

Unblu Cloud

The Unblu Cloud and Unblu Cloud TURN server are separate products. The Unblu Cloud is the full Unblu system based in the cloud. If you enable a feature such as universal co-browsing that requires a TURN server, then the Unblu Cloud TURN server is included transparently in the system. There is no additional work required on the customer’s part to enable this.

Unblu Cloud TURN server

The Unblu Cloud TURN server is a cloud-based TURN server available by itself (without the full Unblu Cloud) for use by customers with an on-premises Unblu installation. For the vast majority of Unblu on-premises customers, we recommend using the Unblu Cloud TURN server.

On-premises TURN server

If, for compliance or other reasons, using the Unblu Cloud TURN server isn’t an option, you can install your own TURN server on your own infrastructure. Advice on installation and configuration is provided below. However, general support for this option isn’t part of the standard Unblu license.

Firewall configuration

Unblu Cloud TURN server

Outgoing connections from the Rendering Service in the Unblu Server and the agent browsers to the Unblu Cloud TURN server require:

  • Open outgoing source ports in the firewall for TCP and UDP.

  • Open outgoing destination ports 443 for TCP and 3478 for TCP and UDP.

Cloud TURN server
Figure 1. Unblu Cloud TURN server

The above diagram depicts the WebRTC connections between the parties in a cloud turn server scenario. Notice that only outgoing connections through the firewall are required.

On-premises TURN server

Incoming connections from the visitor browser to the on-premises TURN server require:

  • Open incoming destination ports 443 for TCP and 3478 for TCP and UDP.

On-premises TURN server
Figure 2. On-premises TURN server

Usually, organizations find it easier to accommodate the first option (opening the outgoing ports) than the second option (opening the incoming ports).

Data security

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.

Using server-based document co-browsing with files of a type other than PDF relies on third-party services and involves uploading the files to the servers of those third parties. Review the following configuration properties:

Configuring the Rendering Service

Considering the two deployment issues above:

  • In terms of firewall policy, the Unblu Cloud TURN server is the simplest solution.

  • In terms of data security in transit, there is no significant security advantage to the on-premises solution compared to the Unblu Cloud solution.

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

Unblu Cloud TURN server configuration

To configure your on-premises Unblu server to connect to the Unblu Cloud TURN server you need the following information:

  • The DNS address of the Unblu Cloud TURN server (<TURN_ADDR>): turn.unblu.cloud

  • The authentication key (<AUTH_KEY>): available from the Unblu delivery team

The authentication key is given to you as part of the onboarding when you register for an Unblu Cloud TURN Server account. Please consult with the Unblu delivery team for more details.

With this information you can set the following configurations properties on your Unblu server:

Listing 1. Unblu Server configuration for the Unblu Cloud TURN server
com.unblu.webrtc.iceServer=turn.unblu.cloud
com.unblu.webrtc.credentialSecretKey=<AUTH_KEY>

Additionally, for testing you can set the following:

Listing 2. Set Use Relay Only to true for testing
com.unblu.webrtc.useRelayOnly=true

But for production this should be changed to

Listing 3. Set Use Relay Only to false for production
com.unblu.webrtc.useRelayOnly=false

On-premises TURN server configuration

If you choose to install your own TURN server on-premises then a common choice is the open-source Coturn Project To create a secure key, we recommend programmatically creating a pseudo-random string using code like the following:

Listing 4. Create an authentication key
#!/usr/bin/env python3

from base64 import b64encode
from random import SystemRandom
from string import ascii_letters

def generate_turn_auth_secret(length = 36):
    """Generate a Base64 encoded random string to be used as the turn server auth secret"""
    character_set = ascii_letters + '#$%&()*+,-./:;<=>?@[]^_`{|}~'
    random_string = ''.join(SystemRandom().choice(character_set) for _ in range(length))
    # print('secret is: ' + random_string)
    return b64encode(bytes(random_string, 'utf-8')).decode("utf-8")

print("Generated, random auth secret: " + generate_turn_auth_secret())

The resulting key should be used in place of <AUTH_KEY> in the configuration files below.

Note the TURN server address

Since you are installing the TURN server on your own infrastructure you control the address of the server. This value should be used in place of <TURN_ADDR> in the configuration files below.

Use the standard ports

The ports configured for TCP and UDP transport should be the standard ones, the same as with the Unblu Cloud TURN server option:

  • <UDP_PORT>: 3478

  • <TCP_PORT>: 443

Determine listening IP address

The IP address on your internal network at which the TURN server should listen for connections is represented by the placeholder

<LISTENING_IP>

in the configuration file below.

Determine external IP address

The external IP addresses (that is, as seen from the internet) at which the TURN server is listening for connections is represented by the placeholder

<EXTERNAL_IP>

in the configuration file below.

Determine relay IP addresses

The relay IP addresses used to relay the packets to the PEER are represented by the placeholder

<RELAY_IP>

in the configuration file below.

Determine denied peer IP addresses

The denied IP addresses defines the banned IPs that cannot be reached as peers and are represented by the placeholder

<DENIED_IP_PEER>

in the configuration file below.

Unblu server configuration

The configuration on the Unblu server side will be similar to that used with the Unblu Cloud TURN server above, except that the <AUTH_KEY> will be the one you created and the <TURN_ADDR> will be the one you specified when you did the installation.

Coturn server configuration

The coturn TURN server is configured in the file turnserver.conf. Follow the recommandations for hardening COTURN installations. You can adapt the example below by substituting appropriate values for the placeholders:

Listing 5. turnserver.conf
prometheus
no-software-attribute
pidfile="/var/tmp/turnserver.pid"
listening-device=eth0
listening-port=<UDP_PORT>
tls-listening-port=<TCP_PORT>
listening-ip=<LISTENING_IP>
external-ip=<EXTERNAL_IP>
relay-ip=<RELAY_IP>
verbose
use-auth-secret
static-auth-secret=<AUTH_KEY>
realm=unblu.com
cert=/etc/ssl/localcerts/tls.pem
pkey=/etc/ssl/private/tls.key
log-file=/var/log/turn.log
simple-log
cipher-list=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
no-tlsv1
no-tlsv1_1
#Prevent peer connection to sensitive Ip (server reachable by the turn server)
denied-peer-ip=<DENIED_PEER_IP>

Here is an example configuration with the placeholders filled in:

Listing 6. turnserver.conf
prometheus
no-software-attribute
pidfile="/var/tmp/turnserver.pid"
listening-device=eth0
listening-port=3478
tls-listening-port=443
listening-ip=172.16.2.54
external-ip=193.159.170.115/172.16.2.54
relay-ip=172.16.2.54
min-port=20000
max-port=20200
verbose
use-auth-secret
static-auth-secret=W3dEO1VoSURAJVtCeGdPVHoqYWtOJiMoaUhCYEFRemFsSW0q
realm=unblu.com
cert=/etc/ssl/localcerts/tls.pem
pkey=/etc/ssl/private/tls.key
log-file=/var/log/turn.log
simple-log
cipher-list=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
no-tlsv1
no-tlsv1_1
#Prevent peer connection to sensitive Ip (server reachable by the turn server)
denied-peer-ip=172.16.2.55

Check connection to TURN server

To check whether the TURN server is accessible from the internet, perform the following:

Listing 7. Checking the connection to an on-premises TURN server
openssl s_client -connect turn_server.com:443

Apply behavior only within a universal co-browsing session

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

<script type="text/javascript">
if( navigator.userAgent.indexOf("UnbluRenderingService") != -1 ) {

	// Your code that should only run in a universal co-browsing session, e.g.
	// load additional CSS or manipulate the DOM

}</script>