Jitsi is the right default for meetings. Here is the narrower case where it is not

Disclosure: I sell Low-Latency Kit, a commercial WebRTC source kit. This post compares it honestly with Jitsi Meet, an Apache-2.0 project. I do not earn anything from a Jitsi deployment.

Jitsi Meet is the stronger default when the product you are building is a meeting.

It has multi-party rooms, mature browser and mobile clients, authentication integrations, recording and streaming options, and an established deployment ecosystem. If users need to join a room, see a grid of participants, mute each other, share a screen, and use the same experience on desktop and mobile, adopting Jitsi is usually the shorter path.

Low-Latency Kit solves a narrower problem: one phone or screen publisher to one or many browser viewers. The camera is effectively a remote pair of eyes. The important parts are the media path, what happens when frames stop, and whether an operator can see why the session failed.

I wrote a fuller comparison here: Jitsi Meet vs Low-Latency Kit. This post is about the engineering decision behind that comparison, not the feature count.

The failure that makes the two products diverge

In a meeting, the room is the unit of the product. In a remote inspection or field-support workflow, the camera session is the unit. That changes the failure model.
A conferencing UI can show a participant tile, a connection state, a mute icon, and a device selector. A field-support UI usually needs to answer different questions:

Is the publisher still sending new frames, or is the last frame frozen?
Is the selected candidate pair direct or relayed through TURN?
Did the WebSocket reconnect, and did the publisher rejoin the correct session?
Is the failure packet loss, bandwidth limitation, CPU pressure, or no picture at all?
Can the session recover without asking the technician to reload the page?

These questions matter because iceConnectionState === "connected" does not prove that video is moving. A track can remain live while the displayed frame is stale. Browser APIs commonly report the connection as connected during exactly the kind of mobile-network transition that makes a support call useless.

The recovery chain I use has three steps:

Detect a frame-level stall with requestVideoFrameCallback, falling back to currentTime when needed.
Try an ICE restart on the existing peer connection.
Rejoin the session only if the restart does not produce frames.

The order is deliberate. An ICE restart is cheaper and preserves the existing media tracks. A full rejoin is the fallback for stale server-side session state, a signaling reconnect, or a republished track. Repeated rejoins need jittered exponential backoff so a tower coming back online does not cause a retry storm.

You can try the failure path in a browser with no account or installation: the 18-second freeze and recovery demo.

Where Jitsi is the better engineering choice

Choose Jitsi if any of these statements describes the product:

Users need more than one participant to publish media.
The primary interface is a meeting room.
You need the Jitsi mobile applications, meeting UI, or authentication integrations.
Your team already operates the Java, web, and supporting services in a Jitsi deployment.
You need the Apache-2.0 licence path and not a commercial source licence.

Those are not small advantages. Rebuilding a meeting product around a small kit would be worse engineering, even if the kit has better diagnostics for a frozen viewer.

Jitsi is also the safer choice when procurement or legal requires a well-known open-source project and an established licence model. Verify the current project and deployment requirements before deciding because licences and supported topologies can change.

Where a one-publisher kit makes sense

Consider a smaller kit when the workflow is closer to this:

A technician points a phone camera at a machine, asset, or fault.
One or more experts watch in a browser.
The expert does not need to publish video or manage a meeting.
The application owns the buttons, branding, session IDs, and business workflow.
The media path must stay on infrastructure the buyer controls.

That is a different product from a conference room. The buyer usually has an existing field-service app, inspection workflow, teleoperation dashboard, or IoT camera interface. The missing piece is the reliable camera session and its operational details, not another meeting application.

The kit is source code, not a hosted service. It includes a Go signalling server, a Pion SFU, a browser publisher and viewer, reconnect logic, diagnostics, Docker and Caddy deployment examples, TURN wiring, and notes on the failure modes that showed up in practice.

A deployment mistake worth checking first

One of the most common cloud failures has nothing to do with JavaScript. The server has a private network interface, while the public address is supplied by the provider NAT. If the server advertises its private address in SDP, a remote browser may never reach the media path. On a TURN server, the equivalent setting is external-ip. In a Go server, the deployment needs a public IP flag or a relay-only policy. The symptom is easy to miss: two machines on the same office network connect instantly, while an outside browser never receives frames.

Another common case is the phone moving from Wi-Fi to cellular. The old five-tuple is gone, so the old candidate pair cannot be revived. The connection object may keep saying connected while the viewer is looking at a still image. The application needs frame health, ICE restart, a full-rejoin fallback, and useful diagnostics. This is exactly the gap between a WebRTC demo and a support product.

What I would decide from

If the product needs a meeting, choose Jitsi. You will spend your time on the workflow instead of rebuilding rooms and mobile clients.

If the product needs one camera publisher, many viewers, a self-hosted media path, and visible recovery behavior, the narrower kit is worth evaluating. Start with the live demo, then read the implementation notes and pricing:

The source package is a one-time purchase with a seven-day refund window. A lower-priced copy is also available through Codester.

If you are deciding between these paths, the useful question is not which project has more features. It is whether your users need a conference room or a remote pair of eyes.