Architecture

Architecture Overview

There are many components to the Capcast architecture. We will first describe the major components and then go through the flow between them throughout this section. Below is the high level view of the architecture:

Below are the major components and their descriptions:

• Client1 and Client2 are peers that want to communicate with each other over Capcast. They run on a web-browser and have logic that allows them to fetch a signalling server from the load-balancer and get a private meeting URL to send to another client in order for them to connect to each other on Capcast. Clients connect to the signalling servers using Websockets.
• Signalling Server1 and Signalling Server2 are load balanced Signalling servers. The role of a signalling server is to keep track of the rooms created, and establish the connection between the communicating peers; in this case, to help Client1 and Client2 communicate.
• Load-Balancer selects a signalling server in a round-robin fashion when a client wants to setup a room.
• Google Speech API is sent audio data from Clients, which it translates to text and sends back.
• STUN Server helps with NAT traversal when establishing connection between Clients.
• TURN Server is a fallback server to relay communication between clients when STUN server fails to establish a peer-to-peer connection between the clients.

Creating a Room

This section describes the connection flow between the initiating client and a signalling server and how a room is created on a signalling server. Please refer to the figure below to get an overview of the flow.

1. Client 1 first requests a connection through the load-balancer. The load-balancer IP address is already part of the Client 1 script when the page loads.
2. The load balancer forwards the request to Signalling Server 1. The load balancer assigns connection in a round-robin fashion. This makes our architecture infinitely extensible with regards to how many signalling servers we can have.
3. Once the connection is established, Signalling Server 1 returns its own public ip address and a randomly generated room id back to client 1.
4. When Client 1 receives the public ip address of Signalling Server 1, it connects directly to the Signalling Server 1 using its Ip address. This is because initially it connected to the load-balancer, which it doesn’t need to do anymore. In addition, Client 1 sends the URL link which contains the server-ip and room-id to Client2 so they can connect over Capcast.

Joining a Room

Following are the steps for a participant to join a room and there by join a Web-RTC call. Please refer to the figure below for reference.

1. Client 1 creates a room on Signalling Server and sends the resulting link to Client 2.
2. Client 2 connects directly to the Signalling Server and joins the room.
3. Client 1 receives peer info from Signalling Server about Client 2 such as its public IP address, protocol to use, etc.
4. Client 1 generates a Session Description Protocol offer and sends it directly to Client 2.
5. Client 2 sends the response to Client 1 and the Web-RTC connection is now established between them.

The above steps have left out a key step in establishing the connection between the peers: Session Initiation Protocol and STUN and TURN servers, which we discuss next.

Connecting Using a STUN Server

Often times, one or both peers are behind a NAT. In that case, it’s difficult for peers to send connection requests to each other directly, as they don’t have each others’ public ip addresses. A STUN server helps remedy this situation by traversing the NAT and retrieving the clients’ public IP address. Capcast specifies a STUN server as part of the ICE protocol when implementing a Web-RTC connection between two clients. The steps below describe how this is accomplished. Please refer to figure below for reference.

1. Client1 and Client2 get their public addresses from a STUN server.
2. Client1 initiates a Session Initiation Protocol offer to Client2.
3. Client2 accepts the offer and the Web-RTC connection is established between them.

Using a TURN Server as a Relay

In case the STUN server isn’t able to traverse the NAT, ICE protocol falls back on to the TURN server to act as a relay server between the clients. In this case, the communication isn’t direct peer-to-peer, but rather through the TURN server.