Reproduce
Capture the failure with your stack, timing, network conditions, and expected user-visible outcome.
For teams already shipping WebRTC
When ICE says connected, check the frames.
A three-week recovery hardening pilot for live video products that work in the office but stall, freeze, or rejoin badly on real networks.
- 3 weeks
- $2,400 fixed
- No replacement stack required
- Scope agreed before payment
Viewer health
Frame recovered
ICE stateconnected
Decoded frames0 fps
Last frame1840 ms
Recovery tierICE restart
The transport is not the health check. New frames are.
The problem is usually not "WebRTC is broken."
It is a gap between what the browser reports and what the user sees. The connection stays green, the last frame remains on screen, and your logs contain no obvious error. By the time a reconnect starts, the session has already looked dead for too long.
-
01
Transport state is treated as media health ICE can remain connected while inbound frames stop arriving.
-
02
Every recovery path runs at once Overlapping ICE restarts and full rejoins make the failure harder to diagnose.
-
03
Success is declared too early A new SDP can be applied before a fresh video frame proves the viewer actually recovered.
-
04
The failure is not reproducible Without a repeatable network-drop test, a fix is only a guess.
Three weeks, four checkpoints
The work starts with one observed failure, not a rewrite. If the problem cannot be reproduced or measured, the scope changes before implementation.
Instrument
Add frame-age, recovery-tier, attempt-count, and time-to-first-frame signals to one test path.
Harden
Implement a bounded recovery ladder: wait, ICE restart, full rejoin, and backoff reset only after new frames.
Hand over
Run the agreed matrix, record results, document decisions, and walk your team through the patch.
Four tests make a recovery claim falsifiable
The pilot records transport state, frame age, the recovery step, and the visible result. An ICE restart or full rejoin is not called successful until a fresh decoded frame arrives and remains live. The exact browsers, networks, devices, and deadlines are agreed in scope.
Failure case
Observed signal
Recovery step
Pass condition
Connected but frozen
ICE stays connected while decoded frame age keeps growing.
Keep the transport and request an ICE restart.
A new decoded frame arrives and the stream stays live for 10 seconds.
TURN-only path
Direct candidates fail and the session requires a relay candidate.
Start and restart under relay-only policy.
Relay allocation succeeds and a new frame survives renegotiation.
Restart without frames
ICE returns to connected after restart, but no new frame is decoded.
Stop retrying and escalate to one bounded full rejoin.
Recovery attempts do not overlap and the rejoin begins at the agreed deadline.
Full rejoin
The old peer connection or track remains stale after recovery attempts.
Close the old session and negotiate a fresh one.
A new decoded frame arrives and the stream stays live for 10 seconds.
Want the full test protocol?
Get the instrumentation fields, deadlines, and evidence checklist. Email only, no newsletter.
Already have a failing case? Describe it and we will check whether the pilot scope fits.
What you receive
- A reproducible failure matrix for the agreed networks and browsers.
- A focused recovery patch or integration guide against your current stack.
- Test recordings and timings before and after the change.
- A short handover document plus a 60-minute technical walkthrough.
What is deliberately excluded
- Full UI redesign, native apps, or a new product build.
- Compliance certification or clinical validation.
- Production operations, on-call cover, or an SLA.
- A guarantee to repair a defect controlled only by a third-party vendor.
Implementation starts only after the boundary is explicit.
One failure path, one test environment, one agreed handover surface.
See the failure before discussing a fix
The interactive lab freezes a real media stream while ICE stays connected. Watch frame health trigger the cheapest repair first, then escalate when a rejoin is required.
What the recording proves
ICE: connectedis not enough to call a stream healthy.- Frame age detects the frozen picture.
- ICE restart is attempted before a full rejoin.
- Recovery is accepted only after new frames arrive.
Good fit, poor fit
Good fit
- You already have a working WebRTC publisher and viewer.
- Freezes or failed recoveries appear on real customer networks.
- Your team can provide a staging endpoint and one reproducible scenario.
- You want evidence and a bounded patch, not a platform migration.
Poor fit
- You need a complete video product built from scratch.
- The main problem is recording, transcoding, mixing, or broadcast scale.
- No one can describe or reproduce the failure.
- You need medical-device validation or a production support contract.
Need the complete self-hosted publisher, SFU, viewer, TURN, and diagnostics kit instead? Start with the remote field assist kit.
Questions before a scope call
Will you replace our current WebRTC stack?
No by default. The pilot works inside the stack you already have. A replacement is a different scope and a different project.
Can you debug Safari, mobile networks, or a carrier NAT?
Those can be part of the agreed matrix. The exact browser, device, and network conditions are written into scope before work starts.
What if the problem cannot be reproduced?
Then implementation does not start. We narrow the evidence needed, change the test conditions, or decline the pilot if there is no observable failure to work against.
Do we need to give you production access?
No. The default is a staging endpoint and a test scenario. Production access is not required for the fixed-scope pilot.
Bring one real failure case.
Stack, observed behavior, and how often it happens are enough for an initial fit check.
Prefer email? Write to support@lowlatencykit.com. No newsletter or drip sequence.