Our Solution

A unique Hybrid delivery protocol: Leveraging the best of mesh delivery and unicast
streaming for both live and VOD use cases
Transparent for end user, no plugin or software to install
A scalable technology: we currently handle >300k concurrent users and is
scalable to millions of users across any market or device.

High-Level backend cloud-based interface

Distributor (HTTPS)

Handles scalability, ramped-up deployment and configuration injection

Tracker (HTTPS)

Operates matching of peers based on variable criteria (content, customer, exclusions rules…)

Signalling (Secured Websockets)

Relays signalling messages to establish P2P data channels

Analytics (HTTPS)

Collects status and activity analytics from clients

Session setup

When starting a playback session

Step 1:

Client gets the playlist/manifest from the streaming server over http/https.
Playlist received OK -> playback starts, go to Step 2.
Playlist not received OK -> session not started. No playback (ex: stream not available, user not authorised)

Step 2

Client sends GET to https://distributor.streamroot.io (or to a locally defined URL),
with parameters CustomerId, contentID, library version.
Distributor replies OK -> returns configuration parameters, including URL for tracker, signalling, analytics servers.
Move to Step 3.
Distributor does not reply OK -> Playback on CDN only, no P2P.

Step 3

Client send an init message via https POST messages to tracker (Tracker URL
defined at Step 2.), to get session parameters such as peerId, protocol version etc.

Step 4

Client establishes a Client establishes and maintains a secure websocket with
Signalling server throughout the session (websocket is identified by peerId)

During the Session

Throughout a playback session

Client regularly send https POST messages to tracker (Tracker URL defined at Step 2).

• Peers: request an update of the list of peers based on client-side parameters
• track: provide feedback on the track being viewed

Client regularly send https POST messages to analytics throughout the session
(analytics URL defined at Step 2).

• usage: short cycle basic data about traffic (http traffic, p2p traffic)
• stats: medium cycle (~ 120 sec) detailed data about traffic and QoS
• control: long cycle (~ 10 min) data about protocol control (checksum fails, etc.)

WebRTC connection: signalling channel

Signalling channel for P2P connection establishment

Each peer uses the established Websocket to the Signalling server as a signalling channel.
The Signalling server relays messages from peer A to peer B based on the peerid obtained
from the tracker.
As the connection is a peer-initiated (secure) websocket, it can transmit through firewalls
under the same conditions as regular http traffic, as long as the URL domain is not filtered.
It is maintained throughout the session.

WebRTC: signalling messages

See https://hpbn.co/webrtc/#establishing-a-peer-to-peer-connection for more context on
WebRTC connection establishment.
When peer A wishes to establish a connection with peer B:

• A sends (through signalling) a SDP message to B to describe the type of WebRTC
  session it wishes to establish (DataChannel in this case)
• A sends an Offer message (through signalling) with one or several candidate {IP:UDP
  port} tuples
  - these tuples can be IP:ports bound to the peer’s local interfaces, and optionally IP:port
  tuples discovered via an external means such as a STUN server. See later for details
• B receives the Offer, decides to respond to A with an answer (through signalling),
  including several candidate {IP:UDP port} tuples

A and B now have a list of candidate {IP:port} on which they can try to contact each other.

• A will start by contacting B on any {IP:port} located on the same IP subnet
• If not successful (NAT, routing issues), A will try other candidates {IP:port}
• At the same time B will try with candidates from A.
• If A can reach B (or vice versa) on any candidate {IP:UDP port} then the WebRTC
  datachannel is established.

At any time, A or B may decide to close the connection (for example due to bad
performance) and request new peers from the tracker (client-side connection
management).

WebRTC: Use cases

Use case 1

1. A and B are located on the same IP subnet

   a) A send its local IP:port description to B and receives B’s local IP:port
   b) B’s IP address is on the same subnet as A’s, so A can directly contact B
   c) WebRTC connection established

2. A and B are on different IP subnets, UDP traffic between subnets is routed

   a) A send its local IP:port description to B and receives B’s local IP:port
   b) B’s IP address is not on the same subnet as A’s, so A’s WebRTC establishment
   request is sent to A’s default gateway which routes the request to B.
   c) WebRTC connection established

Use case 2

A and B are on different IP subnets, with A behind a Destination-NAT (most B2C use
cases).

a) A cannot contact B using only the {local IP:port} description
b) A is configured to query a STUN server outside A’s NAT to obtain a {remote IP:port}
description.
c) A’s query to the STUN server on A’s local UDP port enables hole punching on A’s NAT.
Requests sent to A’s {remote IP:port} will be translated by A’s NAT to A’s {local IP:port}.
d) A’s {remote IP:port} description is sent to B via Signalling channel.
e) B connects to A’s {remote IP:port}, A’s NAT translate to A’s {local IP:port}, connection is
established

Use case 3

A and B are on different IP subnets, with both A and B behind a Symmetric NAT

a) A cannot contact B using only the {local IP:port} description
b) A cannot use a STUN server as A’s NAT will not preserve UDP port allocation during
translation
c) A TURN server that actually relays the complete WebRTC connection would be needed
d) This cancels the benefits of Streamroot solution by adding RTT latency, additional server
provisioning and overhead and is not recommended

 

Detailed sequence diagrams

Client to Distributor

Client to Tracker /init

Client to Tracker /peers

Client to Tracker /tracks

Client to Tracker /geo

Client to Tracker /bye

Client A to Signalling to Client B