Security operations lead
Wants the guard force, the site manager, and the cameras looking at the same frame during an incident — without exporting clips to a third party.
Site & facility monitoring
Put the site cameras in the call, not in a portal.
Construction, facilities, and security teams already have cameras. What they don't have is a way to sit on a call with the cameras present — at full resolution, with the people who need to decide something, without pushing every frame through a vendor's cloud.
- 0
- Frames stored in anyone's cloud — media is peer-to-peer only.
- 24/7
- Session target, with self-renewing leases and unbounded recovery.
- 8K
- Peak per-camera resolution, uncapped on every plan.
- 4+
- Camera participants alongside people, budgeted from leftover uplink.
Who this is for
Construction project manager
Runs a weekly walkthrough with the client where site cameras and a phone on the deck are both in the call at full detail.
Facilities / EHS manager
Keeps a permanent multiview on a wall panel and pulls people into it the moment an alarm or a near-miss happens.
Two windows, one decision
- The camera portal lives in one tab and the people live in another, so nobody is looking at the same frame.
- Sharing the portal window drops the feed to a blurry screen share right when detail matters.
- Cloud VMS pricing scales with cameras and retention, whether or not anyone is watching.
Where normal conferencing breaks
- Conferencing tools have no concept of a camera as a participant — only a person sharing a screen.
- Long sessions get torn down by idle timeouts, tab throttling, and network changes.
- Anyone with the link can usually add whatever source they like, with no admission control.
What 4K Chat brings to it
Cameras join as participants
Capture cards and extra device cameras today; WHEP, HLS, MJPEG, and RTSP feeds are coming through a bridge that runs on your own network.
How it works →Host-approved admission
A camera stays dark until the session initiator or a delegate admits it. Approval is enforced at the publisher and at every receiver, so revoking it kills the feed instantly.
How it works →Per-camera adaptive bitrate
Each camera picks the best rung it can sustain from the uplink left over after the people on the call are served.
Built for 24/7
Self-renewing room leases, Worker-backed keepalives, a media watchdog for silent tracks, and unbounded ICE recovery.
How it works →Nothing leaves your LAN unencrypted
Media travels as an encrypted peer connection — no media server ever holds a frame. IP cameras will be bridged locally on your own network when bridging lands.
How it works →Wall displays and Smart TVs
Install as a PWA on a webOS, Tizen, or Android TV panel and leave the multiview up in the ops room.
How it works →Setting up a session
- 1
Create the monitoring room
Open a room from the ops workstation and keep the link for the crew who need it.
- 2
Add the cameras
Attach capture cards and extra device cameras today. WHEP, HLS, MJPEG, and RTSP bridging is coming.
- 3
Approve each source
As host, admit only the cameras this session should carry. Appoint delegates if a supervisor needs the same control.
- 4
Leave it running
Pin the angles that matter, put the tab on a wall display, and let the resilience layer keep the session alive.
Gear that works
ONVIF / RTSP cameras (Axis, Hanwha, Hikvision, Reolink) — coming
The most common case, once bridging lands: a local bridge on a machine inside the network converts RTSP to WHEP without the stream ever leaving your LAN unencrypted.
WHEP-capable encoders and gateways — coming
The ideal path — no bridge, no transcode. The browser will negotiate directly with the camera or gateway and get the native encode.
MJPEG and snapshot endpoints — coming
Older cameras and many industrial devices, at a polled frame rate; expect lower efficiency than H.264.
What to avoid
Plain http:// camera URLs opened from an https:// page are blocked by the browser. When bridging lands, use an https camera endpoint or the local bridge on localhost.
Will this actually work for us?
We have no public IP and strict firewalls. Does it connect?
Most networks connect on STUN alone because both ends are usually behind cone NATs. There is no TURN relay by design, so a hard symmetric-NAT-to-symmetric-NAT pair is the one case that will not connect — on a single site that is rare, since an on-site camera source and the operator are typically on the same network.
Do the cameras have to be exposed to the internet?
No. When IP camera bridging lands, the bridge will run inside your network and speak to the cameras locally — only the encrypted peer connection leaves the site. Today, capture cards and device cameras need no exposure at all.
What happens when the operator's laptop sleeps?
The session self-heals: leases keep renewing, the media watchdog notices silent tracks, and ICE restarts retry indefinitely until the link is back.
Which browsers?
Chromium-based browsers and Edge give the full feature set including per-frame encryption. Safari covers most of it; Firefox lacks the encrypted-frame transform.
Questions we get
Do the cameras degrade the call for people?
No. Camera tracks are marked low priority and are budgeted from leftover uplink, so browsers starve them before they starve a person's video.
Can a session run for days?
That's the design target — leases renew themselves, timers survive background tabs, and recovery retries indefinitely while the call is open.
Who can add a camera?
Only sources the host or an appointed delegate has approved publish anything; revoking approval drops the feed immediately.
Keep reading
Recommended plan: Cinema
Room size for a full ops crew plus multiple simultaneous camera participants, with no cap on peak resolution.