Metadata Reality Check Demo
What metadata exists in any internet call - and what happens to it. This demo shows the small, unavoidable details needed to connect callers, plus the clear boundary of what is not collected.
Metadata that can exist
- IP address (masked) - partial network info like xxx.xxx.113.45
- Timestamp - when a connection happened
- Session ID - a short-lived random label
- Connection path - P2P direct or TURN relay
What happens to this metadata
- Used to connect the call (routing + NAT traversal)
- May exist briefly in memory while the session is active
- Should be minimized (short-lived IDs, minimal logs)
- Not the call content - it's just the "envelope," not the "letter"
Live demo panel
Everything below is simulated to illustrate what a server could see in a typical WebRTC setup.
Explicitly not collected / not visible
Why? Keys and content stay on the devices. The server can help callers "find each other," but doesn't need your content to do that.
Connection path
P2P means callers connect directly when possible. TURN means a relay helps when direct connection fails (common behind strict Wi-Fi/mobile).
Metadata that can exist
What happens to it (in plain English)
- During the call: used for routing + keeping the session alive.
- After the call: should not be needed. Any retained logs should be minimal and time-limited.
- Important: this is not message text, not audio/video, and not encryption keys.
Glossary
P2P (Peer-to-Peer): Caller A and Caller B send media directly when a direct network path is possible.
TURN (Relay): A relay helps pass traffic when direct connection fails (strict NAT, corporate Wi-Fi, some mobile networks). A relay changes the route - it does not mean the server can see the call's contents.