Design Calls That Can Fail to Connect

Systems & Architecture · real-time, permissions, errors

Updated 2026-08-04

Treat connecting as its own phase with its own screen. Two browsers trying to reach each other test several possible routes before one works, and that negotiation takes visible time.
Ask for the camera and microphone before the call, not during it. A permission prompt appearing at the moment someone joins costs them the first thirty seconds of the conversation.
Give the user a preview and a device picker first. Choosing the wrong microphone is the most common call failure and the only one the interface can fully prevent.
Distinguish the failures that need different actions:

Permission denied, which needs browser settings.
No device found, which needs hardware.
Cannot reach the other side, which needs a network or a retry.
Connected but no media, which usually means a muted or blocked device.

Show connection quality continuously rather than only when it breaks. A quiet indicator lets people self-correct by turning off video before the call becomes unusable.
Degrade in a stated order. Dropping video to preserve audio is almost always right, and doing it silently makes people think their camera broke.
Keep the call alive through a route change. Moving between networks renegotiates the connection, so a brief Reconnecting beats ending the call.
Say when a call is being relayed rather than direct. It explains the added delay, and in products where directness is a privacy claim it is a fact the user is entitled to.

A call is a negotiation between two networks that were not built to reach each other, and the interface should narrate that instead of showing a spinner.