> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platform.decart.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Network Requirements

> Network, device, and firewall configuration for running the realtime SDK — for IT, networking, and security teams

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.

<Note>
  Updated for SDK v0.1.22 and production infrastructure as of August 2026.
</Note>

## 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 |

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

## 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) |

## Network requirements

### 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](#testing-connectivity-with-the-js-sdk).

## 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:

<Steps>
  <Step title="Run a real session">
    Start a real session and let it run 2–3 minutes.
  </Step>

  <Step title="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](#in-session-warn-or-degrade-if-reception-drops).
  </Step>

  <Step title="Watch for stalls and bandwidth limits">
    Watch for any `videoStall` events or `limitingFactor === "bandwidth"` — either one means the network is not ready.

    ```typescript theme={null}
    rt.on("diagnostic", (event) => {
      if (event.name === "videoStall") {
        console.log(event.data.stalled ? "stalled" : "recovered", event.data.durationMs);
      }
    });
    ```
  </Step>

  <Step title="Prefer wired">
    If both Wi-Fi and wired are available, test both and prefer wired.
  </Step>
</Steps>

## 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       |

<Warning>
  `*.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.
</Warning>

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.

<Note>
  Staging environments use `api.stage-decart.com` and `livekit.stage-decart.com`.
</Note>

### 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

The JS SDK exposes two connectivity signals — a quality verdict (`good | fair | poor | critical`) and a limiting factor (`bandwidth | latency | loss | stall | cpu | none`).

### Pre-connect: decide whether to show the feature

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

```typescript theme={null}
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](#connection-quality-thresholds):

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

## Next steps

<CardGroup cols={2}>
  <Card title="Streaming Best Practices" icon="video" href="/models/realtime/streaming-best-practices">
    Camera setup, connection management, and error handling
  </Card>

  <Card title="JavaScript SDK" icon="js" href="/sdks/javascript-realtime">
    Full reference for the connectivity and diagnostics APIs
  </Card>
</CardGroup>