9 digits, one tab, no install.
From the customer pressing Start to your technician seeing pixels: about three seconds, four control-plane hops, one media path.
Customer opens the AnchorGrid app and presses Start.
The end user has no account. The app is free. They tap once, get a 9-digit code keyed to your workspace, and read it to the technician, or paste it into the email/chat thread already open.
Technician pastes the code. The server claims a slot.
The technician is already signed in to your workspace: auth and any 2FA happened at the door, not at the code entry. Pasting the code POSTs to the API with the existing session cookie, the server checks workspace membership, and hands back an HMAC-signed signalling token for that one session.
ICE picks the shortest path.
Both sides exchange candidates over the WebSocket signalling channel. We always try peer-to-peer first. If the customer's network blocks it, we fall back to a TURN relay in Ashburn without dropping the session.
Pixels, audit trail, and an honest read on the path.
The technician sees the shared iPhone or Android screen live. Every join, leave, and path change is written to the workspace audit log. On iPhone, Apple's platform rules keep the session view-only.
Three seconds, roughly.
Pair-to-first-frame on a healthy LAN sits in the low single seconds. WAN P2P adds the ICE round-trip and a renegotiation if a TURN candidate wins.
What the phone actually publishes.
iPhone uses a ReplayKit broadcast extension, while Android uses MediaProjection. Screen frames are encoded on-device before they touch the wire.
AnchorGrid does not capture or transmit the device microphone or system audio. The support session carries the shared screen only.
iPhone sessions are view-only because iOS does not permit remote input. Android attended screen sharing is available in beta, with control capabilities described separately as they are verified.