Direct answer
Reconnect quickly once, then use capped exponential backoff with jitter. Reset the delay only after the stream remains healthy for a defined stability window.
Why this happens
Immediate infinite retries can overload a rebooting camera and synchronize hundreds of clients into a reconnect storm. A very slow fixed retry, however, leaves routine outages unresolved for too long.
Reliable camera viewing depends on bounded retries, observable health and a deliberate main/substream policy.
A controlled test
Define states for connecting, playing, stalled, backing off and stopped, with one timer owner per stream.
Change one variable at a time. Keep the camera model, firmware, endpoint and account recorded; then test network reachability, protocol response, media transport and decoding as separate layers.
Use a dedicated view-only account and a trusted local diagnostic tool. Redact credentials, private addresses and identifying data before sharing output.
Diagnostic sequence
| Check | Action | Evidence of progress |
|---|---|---|
| First retry | Allow a prompt retry for a brief path interruption. | Short outages recover quickly. |
| Backoff | Increase delay after repeated failures and add jitter. | Clients do not retry in lockstep. |
| Health reset | Reset the attempt count after sustained good playback. | One good packet does not erase a persistent fault. |
| Stop rule | Stop or alert after the operational limit. | A dead camera is visible rather than silently retried forever. |
Evidence to keep
Log attempt number, reason, delay and time since last good frame. That supports both operations and root-cause analysis.
Boundary and safety note
Reconnect logic should not bypass authentication failures, revoked access or an explicit operator stop.
For remote viewing, use a managed VPN instead of exposing RTSP or camera administration ports directly to the public internet.
SmartRTSP
SmartRTSP is a camera-focused RTSP and ONVIF viewer for Apple devices, Windows and Android. It fits direct viewing, discovery and multi-camera checks; keep a dedicated NVR or VMS when continuous recording, evidence export or centralized enterprise controls are required.
Frequently asked questions
What is a good reconnect strategy?
A fast first retry followed by capped exponential backoff with jitter and an explicit stop or alert threshold.
When should backoff reset?
After a defined period of healthy playback, not immediately after the socket opens.
Should 401 errors retry automatically?
Repeated authentication failures should stop or alert rather than hammering the camera with the same rejected credential.
Primary references
- IETF RFC 7826 — Real-Time Streaming Protocol 2.0
- CISA — Secure by Design guidance
- SmartRTSP — official platform and product information
Related SmartRTSP guide
Open related guideDesign bounded retries, jitter and visible connection states for cameras that reboot or briefly lose the network.