# Handling Guest Disconnects and Connection Recovery

When guests randomly disconnect, freeze, or reconnect in loops, there is rarely one single fix. This guide gives a layered approach so you can choose the least disruptive option first, then escalate only when needed.

## Fast checklist before going live

1. Have guests use wired Ethernet where possible.
2. Ask guests on unstable links to test Chrome and Firefox ahead of time.
3. Keep a fallback path ready:
   * P2P first
   * Meshcast/WHIP+WHEP fallback
   * Mix-minus patching for critical audio continuity

## Option 1: URL-only recovery tuning (quickest)

Use these on room/director/push/view links as needed:

* `&autorecover=1` enables the recovery bundle.
* `&autorelay=1` allows TURN escalation during recovery.
* `&p2pfailtimeout=<ms>` sets recovery timing window (default `12000`, clamp `3000-45000`).
* `&peerrecoversteps=<n>` sets retry depth (default `3`, clamp `1-6`).
* `&pendingicettl=<ms>` controls queued ICE candidate retention (default `15000`, clamp `3000-60000`).

Suggested presets:

* Balanced:
  * `&autorecover=1&p2pfailtimeout=12000&peerrecoversteps=3&pendingicettl=15000`
* Aggressive recovery:
  * `&autorecover=1&autorelay=1&p2pfailtimeout=7000&peerrecoversteps=5&pendingicettl=20000`
* High-latency environments:
  * `&autorecover=1&p2pfailtimeout=18000&peerrecoversteps=4&pendingicettl=30000`

## Option 2: Browser and network remediations

* Switch guest browser (Chrome <-> Firefox) for problematic links.
* Disable VPN/proxy/security middleboxes where possible.
* Prefer Ethernet over Wi-Fi; avoid double-NAT and overloaded consumer routers.
* If direct P2P is consistently failing, test TURN path reliability using [`&relay`](/advanced-settings/turn-and-stun-parameters/and-relay.md).

## Option 3: Meshcast or WHIP/WHEP fallback

If room topology is large or network quality is inconsistent:

* Publish through Meshcast / WHIP and distribute WHEP playback where appropriate.
* Use `&whepshare=` (+ optional `&whepsharetoken=`) for external WHEP sources.
* Keep P2P for low-latency workflows, but use WHIP/WHEP paths when consistency is more important than absolute lowest latency.

## Option 4: Director operational fallback

When a specific guest-to-guest P2P edge fails during a live show:

* Use **Mesh Network Debug** to identify failing edges.
* Apply **Patch via Mix-Minus** to restore audio continuity for critical contributors.
* Use **ICE Restart**, **Refresh Video**, **Refresh Mic**, or **Refresh All** actions per guest.
* If a guest is publishing via WHIP output, use **Restart WHIP** from director controls.

## Broadcast-mode resiliency pattern

For larger productions:

* Use broadcast-oriented workflows so not every guest must maintain every P2P edge.
* Keep a dedicated fallback scene/source path in OBS for temporary degraded guests.
* Combine with retry/reload controls for unattended overlays:
  * `&retry`
  * `&retrytimeout=5000`
  * `&autoreload` / `&autoreload24`

## Example link templates

* Director:
  * `https://vdo.ninja/?director=ROOM&autorecover=1&peerrecoversteps=4&p2pfailtimeout=9000`
* Guest:
  * `https://vdo.ninja/?room=ROOM&push=GUESTID&autorecover=1`
* Viewer/Scene:
  * `https://vdo.ninja/?scene&room=ROOM&retry&retrytimeout=5000`

## Related

* [Primary and Backup Guests with `&scene` and `&slots=1`](/guides/primary-and-backup-guests-with-scene-and-slots.md)
* [Mesh Network Debug](/guides/mesh-network-debug.md)
* [`&autorecover`](/advanced-settings/settings-parameters/and-autorecover.md)
* [`&autorelay`](/advanced-settings/turn-and-stun-parameters/and-autorelay.md)
* [`&p2pfailtimeout`](/advanced-settings/settings-parameters/and-p2pfailtimeout.md)
* [`&peerrecoversteps`](/advanced-settings/settings-parameters/and-peerrecoversteps.md)
* [`&pendingicettl`](/advanced-settings/turn-and-stun-parameters/and-pendingicettl.md)
* [Packet Loss](/common-errors-and-known-issues/packet-loss.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.vdo.ninja/guides/handling-guest-disconnects-and-connection-recovery.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.