Network Requirements

This page specifies the network, device, and security configuration required to operate the Decart realtime streaming SDK. It is intended for the IT, networking, and security teams responsible for the deployment environment, and can be shared with an internet service provider where connectivity changes are required.

Updated for SDK v0.1.22 and production infrastructure as of August 2026.

Supported operating systems

The SDK does not hard-enforce a minimum OS or browser version. Device support is inherited from the underlying WebRTC stack, which transpiles broadly and checks capability at runtime rather than gating on a version number. The values below are recommended minimums for a reliable realtime experience — not hard cutoffs.

Platform	Recommended	Technical floor
iOS / iPadOS	iOS / iPadOS 15 or later	iOS 14.3
Android	Android 10 or later with the latest Chrome (or another up-to-date Chromium browser)	Android 8 with Chrome 110
Desktop	Latest stable Chrome, Edge (Chromium), Firefox, or Safari	Chrome 110, Edge (Chromium) 110, Firefox 110, Safari 16

On Android, Chrome updates independently of the OS, so a recent Chrome version matters more than the Android version number itself.

Hardware requirements

The SDK processes bidirectional realtime video at ~30 fps. Sustained performance under continuous load matters more than peak spec — a device can pass these numbers and still throttle after a few minutes of thermal load.

Component	Minimum	Recommended
Processor	Dual-core 2.0 GHz	Quad-core 2.5 GHz
GPU / video acceleration	Integrated GPU; hardware video acceleration strongly recommended	Hardware H.264/VP9/AV1 encode + decode
RAM (free at session start)	2 GB	4 GB+
Architecture	64-bit x86 or ARM	64-bit x86 or ARM (Apple Silicon supported)

Bandwidth per active session

Each live session is bidirectional and roughly symmetric — you send your camera upstream and receive the transformed video downstream at the same time, at 30 fps. A session typically consumes 1.3–2.4 Mbps in each direction simultaneously in production measurements.

Minimum: 3.5 Mbps per direction (the bitrate cap per stream).
Provision for: 4 Mbps per direction — both upload and download — per concurrent session, which covers the cap plus protocol overhead.

Fixed locations

For deployments where the experience must stay up consistently (for example, an in-store installation), we recommend:

Wired Ethernet over Wi-Fi for the device running the session. Wi-Fi introduces packet loss and jitter that cause video freezes.
~2× bandwidth headroom over the per-session requirement (about 8 Mbps per direction, per session).
A business or dedicated line if the existing connection cannot guarantee stability.

Mobile users

Mobile reception is variable and cannot be guaranteed. The recommended pattern is to gate the feature on measured connectivity — call checkConnectivity() before offering the experience and only show it when the connection is good enough. See Testing connectivity.

Connection quality thresholds

These are the exact thresholds the SDK uses to compute its live connection-quality verdict. The overall verdict is the worst dimension, smoothed over a rolling window with a short warm-up and hysteresis so it does not flicker.

Metric	Good	Fair	Poor	Critical
RTT latency	≤ 150 ms	≤ 300 ms	≤ 500 ms	> 500 ms
Packet loss	≤ 0.1%	≤ 1%	≤ 5%	> 5%
Inbound frame rate	≥ 20 fps	≥ 12 fps	≥ 5 fps	< 5 fps

Quick readiness check

Run this once per fixed location, on the actual device and network:

Run a real session

Start a real session and let it run 2–3 minutes.

Confirm the quality verdict

Confirm the connection-quality verdict holds at "good" (or at worst "fair") for the whole run — monitor it with the onConnectionQuality callback shown in In-session monitoring.

Watch for stalls and bandwidth limits

Watch for any videoStall events or limitingFactor === "bandwidth" — either one means the network is not ready.

rt.on("diagnostic", (event) => {
  if (event.name === "videoStall") {
    console.log(event.data.stalled ? "stalled" : "recovered", event.data.durationMs);
  }
});

Prefer wired

If both Wi-Fi and wired are available, test both and prefer wired.

Firewall and network configuration

Domains to allow (production)

Domain	Purpose	Protocol
`api.decart.ai`	REST API, authentication, session setup	HTTPS / TCP 443
`api3.decart.ai`	Realtime signaling (WebSocket)	WSS / TCP 443
`platform.decart.ai`	SDK telemetry, authentication, billing	HTTPS / TCP 443
`lk.decart.ai`	Realtime media signaling (US-West)	WSS / TCP 443
`*.lkc.decart.ai`	Realtime media signaling, regional edge servers	WSS / TCP 443
`stun.l.google.com`	STUN, used by the pre-connect connectivity check	UDP 19302

*.lkc.decart.ai is required, not optional. Sessions are routed to the nearest regional media server based on client geography, worldwide. A wildcard entry is necessary because the specific hostname a session receives is assigned at connect time. Allowlisting only lk.decart.ai will work in US-West and fail everywhere else.

Regional media servers worldwide are served as <region>.lkc.decart.ai (for example eu-west-1.lkc.decart.ai), and new regions are added regularly — allow the wildcard rather than individual hostnames.

Staging environments use api.stage-decart.com and livekit.stage-decart.com.

Ports and protocols

Port / protocol	Direction	Purpose
TCP 443	Outbound	HTTPS and secure WebSocket (WSS) signaling. Always required.
UDP 7882	Outbound	WebRTC media. Required.
UDP 3478	Outbound	TURN relay, used when a direct path is unavailable.
UDP 19302	Outbound	STUN, for the pre-connect connectivity check.

Media-server IPs are dynamic. Allow by protocol and port, not by fixed destination IP. This applies to UDP 3478 as well: the TURN relay is advertised to the client as a per-session server IP, so there is no single TURN hostname or address to allowlist.
DTLS/SRTP: media is encrypted. Do not attempt to inspect it.

UDP traffic and proxy configuration

This is the most common cause of “it connects but the video freezes” problems:

WebRTC prefers UDP (port 7882). Allow outbound UDP where possible.
Do not force media through an HTTP/HTTPS proxy that cannot pass UDP if you want the low-latency path.
For SNI / transparent proxies: allow the domains above, and do not TLS-intercept (decrypt) turn.decart.ai; doing so breaks the connection.

Testing connectivity with the JS SDK

Pre-connect: decide whether to show the feature

Checks whether WebRTC can leave the network over UDP, and measures path latency:

const { quality, metrics, reasons } = await client.realtime.checkConnectivity();
// quality: "good" | "fair" | "poor" | "critical"
// metrics.transport: "udp" | "relay" | "failed"

if (quality === "critical") showFallback(reasons);

In-session: warn or degrade if reception drops

A smoothed live verdict based on the SDK’s WebRTC stats, using the thresholds above:

const rt = await client.realtime.connect(stream, {
  model,
  onRemoteStream: (remoteStream) => {
    videoElement.srcObject = remoteStream;
  },
  onConnectionQuality: ({ quality, limitingFactor }) => {
    updateSignalBars(quality);
    if (quality === "poor") warnUser(limitingFactor);
  },
});

Getting started

Realtime

Non-realtime

Provider Integrations

Libraries & SDKs

Frameworks

Resources

Network Requirements

Supported operating systems

Hardware requirements