Architecture & data flow¶
Drovio is based on WebRTC to deliver a fast, low-latency experience using best-in-class audio and video encoding (AV1, VP9, VP8) while maintaining a highly secure, privacy-aware P2P architecture.
Overview¶
Drovio comes with a server software, Drovio Server (available on the Enterprise edition only), and a client software, Drovio (the Drovio app). The solution also provides a web client allowing users to join any screen sharing session or call without having to download, install or subscribe to anything.
The interactive walkthrough below follows a session from authentication through to media, and lists the protocols and ports involved at each step.
Connection flow¶
HTTPS · TLS 1.2 / 1.3 · 443
Authentication on Drovio operates over HTTPS (TLS 1.2 or 1.3). WebSocket connections are then initiated between Drovio Server and the clients to handle the overall signaling process.
On the Enterprise edition, the enabled protocols and cipher suites are set with http.tls_protocols and http.tls_cipher_suites.
WebSocket (WSS) · 443
Signaling, as per WebRTC terminology, refers to the exchange of streaming media capabilities (audio / video codecs) and network capabilities between endpoints (the clients). SDP and ICE candidates are relayed between the Host and the Guest through Drovio Server, over WebSocket.
To this end, SDP (Session Description Protocol) is used to enumerate supported streaming media. Meanwhile, available ICE candidates are gathered on each endpoint, each referring to a possible IP address, port and transport layer. They are exchanged, constituting ICE candidate pairs. Multiple pairs are elected but only one is selected to ensure the P2P communication (unless an ICE reset occurs, requiring the connection to be renegotiated and another pair selected; Drovio handles this seamlessly).
STUN · UDP 443
During signaling, clients may use a STUN server (Session Traversal Utilities for NAT) to cross any NAT. Their sole purpose is to answer the question “what is my public IP?”.
DTLS-SRTP / SCTP · UDP 1024-65535
P2P connections then operate directly between clients. A live video stream of the host screen or app is sent to the guests, along with any audio stream (microphone or system audio). Guests may share their microphones too and send mouse/keyboard inputs, which the host can revoke at any time (see Session access & control). Drovio Server is not involved during the screen sharing session, except to collect various statistics to improve user experience (see Statistics).
TURN · UDP/TCP 443 · UDP 49152-65535
When firewalls or NAT rules are too restrictive, direct P2P connections can't be established between clients. Relay servers (TURN, Traversal Using Relays around NAT) are then used to forward packets from one client to the other. The communication remains end-to-end encrypted: a relay forwards packets it cannot decrypt, since the keys are negotiated between the endpoints only.
On the Cloud edition, STUN/TURN servers are hosted on AWS and deployed all over the world, used by ~15% of all screen sharing sessions; the geographically closest server to a user is used when needed. On the Enterprise edition these servers are optional: we can help you deploy your own STUN/TURN servers when screen sharing over the Internet is required (see Relay server (TURN)).
A relay is not an open proxy. Obtaining an allocation requires time-limited credentials derived from a shared secret, allocations expire after a few minutes, and the relay refuses loopback and multicast destinations, so it cannot be turned against internal networks. TLS 1.0 and 1.1 are disabled on the relay, its cipher list is restricted to modern ECDHE suites, and it does not advertise its software version.
Protocols & ports summary¶
| Step | Protocol(s) | Port(s) |
|---|---|---|
| Authentication | HTTPS (TLS 1.2 / 1.3) | TCP 443 |
| Signaling | HTTPS + WebSocket (WSS) | TCP 443 |
| STUN | UDP | 443 |
| Screen sharing (P2P) | DTLS-SRTP, DTLS-SCTP | UDP 1024-65535, outbound and inbound |
| TURN (relay) | UDP / TCP to reach the relay, then UDP for the relayed media | 443, then 49152-65535 |
On the P2P range. 1024-65535 is not a list of ports to open on a server. These
are the WebRTC media ports: for each session, every endpoint picks an ephemeral
port of its own and announces it as an ICE candidate. What a firewall has to allow
is outbound UDP and its return traffic, not a fixed port. Where that is not
possible, the session falls back to TURN and everything goes through port 443.
On the relay ports. 49152-65535 is the allocation range of the relay server
itself, not of the clients. On the Cloud edition our relays listen on 443 only,
in UDP and in TCP, which crosses most corporate firewalls. On the Enterprise edition
you choose the ports: the Relay server (TURN) guide
suggests 80 and 443 for the same reason.