Technology
How it works, not just what it does
SRTC’s media server (SFU) and every client SDK are built in-house. Here is how it handles the four problems that break most real-time deployments: bad networks, growing scale, isolated networks, and a zoo of devices.
Weak-network resilience
Most stutter on enterprise and home networks is not a broken link but a momentary shortage of bandwidth — and blindly retransmitting only makes the congestion worse. SRTC treats uplink, downlink, packet loss and device load separately, always protecting audio first. Video stays smooth at 30% packet loss and audio at 50%.
Adaptive retransmission
Loss detection and retransmission on both uplink and downlink, with 2–4 retries depending on conditions; the added delay fades once the network recovers.
Four-tier bitrate adaptation
Uplink quality is scored from latency, loss and jitter into four tiers — full, 1/2, 1/4 bitrate, or video paused. Upgrades step up one tier at a time with growing intervals, preventing the classic drop-recover-drop oscillation.
Camera vs. screen share
Camera video trades quality and frame rate but keeps its resolution (so recordings stay consistent); screen shares must stay sharp, so only frame rate is reduced.
Motion-aware frame rate
Screen captures are scanned for changed pixels and the encoder is told how much moved; a static slide drops to 1 fps, cutting uplink usage dramatically.
Keyframe splitting
At 1 fps a stream is almost nothing but keyframes. SRTC spaces them 2 s apart and splits each into two packets sent a second apart, flattening the bursts and cutting a 1080p screen share from about 1 Mbps to about 500 kbps.
Video-to-image fallback
Below 0.5 Mbps uplink, the screen share switches from video to periodic screenshots delivered as files, so they never compete with audio — voice stays intact even at 0.1–0.2 Mbps.
Speech-to-text fallback
Under 100 kbps, when even voice struggles, on-device offline transcription turns speech into text for the other participants, so the conversation carries on through the gaps.
Dynamic simulcast (SSVC)
Senders encode up to 7 video tracks at once (content plus large/medium/small camera layers). Receivers pull high resolution (e.g. 720p) only for the main tile and low resolution (e.g. 180p) for thumbnails, switching with the active speaker — never more than one HD stream at a time.
Server-side estimation & pacing
The SFU continuously estimates each receiver’s bandwidth and switches video layers. Downlink traffic is paced: audio has its own priority lane, video queues per stream with a bounded queue time so latency cannot grow without limit.
Audio-first loss recovery
When bandwidth is short, video retransmission is reduced or turned off so audio wins the bandwidth. Voice adds redundant encoding to recover single lost packets.
Audio-only mode
When the downlink is so bad that retransmission and small layers cannot help, all video is dropped and only audio is received — the last line of defense. Video does not auto-resume, to avoid oscillation.
Dynamic audio buffers
A maxed-out CPU makes audio capture burst several frames at once and overflow the receiver. SRTC starts the capture buffer at 200 ms (up to 400 ms) and the receive buffer at 100 ms, growing them only when needed.
Scale-out & nearest-node access
Self-hosted projects range from a single-server pilot to a headquarters with dozens of regional sites. SRTC makes capacity a function of node count rather than single-server power, and connects every device to the cluster closest to it.
Three decoupled layers
The meeting and RTC layers are stateless (state lives in Redis and the database) and scale by adding instances behind plain round-robin — no sticky sessions. The media layer (SFU) scales by adding nodes, independently.
Signaling separate from media
Signaling reaches the application tier over HTTPS; media flows over UDP directly between device and media node. Scaling, upgrading or losing an application instance never drops a live call.
Channel-based sharding
Members of the same channel converge on one media node, so forwarding stays inside a single server with no server-to-server traffic. Different channels spread across nodes; capacity grows linearly.
Tuned single-node path
A lock-free forwarding path, one shared UDP port for every client (easy on firewalls) and tuned kernel socket buffers — each server is pushed to its limit before you add another.
Silence suppression (DTX)
Opus DTX cuts a speaker’s uplink bitrate by about 80% while they are silent, which adds up fast in large meetings with many sites (verified with A/B tests).
Four-step node scheduling
Session stickiness → channel affinity → least-loaded → overload protection. Nodes report connections, tracks, bandwidth and CPU/memory every 10 s; a node silent for 30 s is marked down and its clients reconnect to healthy nodes automatically.
Explicit routing, not IP guessing
NAT devices and security gateways make source-IP geolocation unreliable on private networks. Instead, your backend assigns each user a network route when it issues the join token, and the server returns the matching endpoints — predictable and auditable.
Dual-stack internal / internet
Media nodes rewrite connection addresses per network group, so one server can serve intranet and internet users at once, each side with its own domain and certificate.
Tiered, independent clusters
Headquarters and each region run their own self-sufficient cluster. Local meetings never leave the region or consume uplink bandwidth, and keep working even if the uplink goes down.
Offline delivery
Every component ships as an offline container image, with a browser-based installer and batch deploy/upgrade tooling. No internet access is ever required.
Per-node capacity depends heavily on CPU, NIC, video profiles and how many participants watch each other, so we recommend load-testing your real usage pattern before sizing hardware.
Air-gapped networks & data diodes
Defense, critical-infrastructure and OT / industrial control networks are often separated from the internet by data diodes, one-way gateways or cross-domain guards. These are not routers: they pass only a few whitelisted protocols (typically video streaming), so the APIs, signaling and UDP media of an ordinary video platform cannot cross. SRTC bridges the boundary with a pair of gateways, so external users can join meetings hosted inside the protected network without weakening the separation.
Typical topology
A gateway on each side
The outer gateway faces external users; the inner gateway talks to the platform’s API, signaling and media services. Internal users connect to the platform directly as usual.
Tunneled as an allowed protocol
Traffic crosses the boundary as standard RTSP sessions — TCP (API, signaling) over RTSP for ordered delivery, media over RTP for low latency — and is restored on the far side.
Encryption passes through
Gateways never decrypt: HTTPS, TLS signaling and DTLS-SRTP media cross untouched. Certificates live only on the internal platform, so neither the gateways nor the guard see plaintext.
Three fixed tunnels
All media shares one UDP port, so external access needs just three tunnels (API, signaling, media), no matter how many people join — and no TURN relay.
Transparent to apps
Neither the platform nor the clients change. Browsers, mobile and desktop apps and SIP / H.323 endpoints join the same meeting from either side.
One-way streaming out
Where data may only flow outward, a composited meeting can be streamed one way to an external live platform, with nothing coming back in.
Where it is used
Defense & government
Classified or restricted networks that must meet external parties without opening generic ports.
Critical infrastructure
Energy and utility operators whose control networks sit behind one-way gateways.
OT / industrial networks
Plants that need remote experts on a call while keeping the ICS network isolated.
Courts & law enforcement
Remote hearings and interviews where the internal network must stay separated from the internet.
Allowed protocols, port ranges and throughput are agreed with the boundary-device vendor during rollout; gateway capacity is sized by the number of concurrent external participants.
Unified communications
Enterprise and public-sector sites already own SIP phones, H.323 room systems, CCTV, radio dispatch — and often a third-party cloud meeting service. SRTC brings them into the same real-time session through gateways instead of asking you to replace hardware.
SIP / H.323 gateway
SIP phones, SIP / H.323 room systems, dispatch consoles and PA/intercom devices register with the gateway and call into sessions alongside desktop, mobile and browser users, including dual-stream (people + content).
GB28181 / RTSP gateway
CCTV, portable and body-worn cameras join through the device gateway; their video can be subscribed, composited and recorded like any participant.
Third-party meeting interop
Over SIP / H.323, the cloud-meeting gateway joins Zoom, Microsoft Teams and other cloud meetings as a room system, carrying audio and video both ways.
Cloud MCU
Server-side compositing for recording, live streaming and output to legacy endpoints — RTMP / RTSP / SIP output, recordings to local disk, NFS or S3-compatible storage.
Server-side participants
Recording, streaming, speech recognition and AI minutes all join as server-side participants using the same SDK and protocol as clients — no special media path needed for your own extensions.
Need the full technical white papers for an evaluation?
Contact us