Visitor and host lifecycle
The visitor opens the video-call module and supplies optional contact details.
The browser asks for camera and microphone permission.
A waiting room appears in the surface's Video calls inbox.
An authenticated team member opens the room and joins.
Either participant can end the call; expired rooms stop accepting new signaling.
Offer video without changing the integration contract
import { setModules, open } from "demoloop-widget";
setModules([
{ id: "product-demo", experience: "demo", presentation: "modal" },
{ id: "video-call", experience: "video-call", presentation: "modal" }
]);
// Offer this after the visitor asks for a person.
open({ module: "video-call" });Explicit permission
Camera and microphone are requested only after the visitor or host chooses to start or join.
No Demoloop recording
Expert-call media is not recorded or stored by Demoloop.
Peer-to-peer media
WebRTC sends encrypted audio and video directly between participant browsers.
What Demoloop stores
RoomSurface id, status, visitor name and email when supplied, creation time, and expiration time.
SignalingOffers, answers, connectivity candidates, ready state, and leave state used to establish the peer connection.
MediaAudio and video do not pass through Demoloop application storage and are not recorded.
Current beta boundary
The initial implementation uses STUN-assisted peer-to-peer connectivity. Most ordinary networks work, but restrictive corporate firewalls or symmetric NAT may prevent a connection. A managed TURN relay is required for universal enterprise connectivity and is not part of the current beta.
Before testing
Use a current browser with WebRTC and media-device support.
Serve the host application and Demoloop over HTTPS.
Allow camera and microphone access for the embedded frame.
Test with two different browser windows or devices.