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.
- Long sessions
- A design target, not a 24/7 availability guarantee.
- 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
Uses a cast or mirrored wall display for extended reviews and brings people in when a site issue needs discussion.
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 long sessions
Room lease renewal, keepalives, a media watchdog for silent tracks, and ongoing connection recovery are designed to help calls stay open; uptime is not guaranteed.
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
Run the call in a phone or PC browser, then cast or mirror the picture to an ops-room display. There is no Smart TV store app today.
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
Set up the display
Pin the angles that matter and cast or mirror the browser view to a wall display. Keep the host device awake and monitor the connection during long sessions.
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?
Sleep can interrupt the call. Keep the host device awake during long sessions; when it reconnects, recovery can retry, but uninterrupted video is not guaranteed.
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?
Long sessions are a design target, not an uptime promise. Room leases renew and connection recovery retries while the call is open, but device sleep, browser behavior, and network conditions can interrupt it. Monitor important sessions.
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.