Embodied systems · Explore this field ↗ · Implementation · 4 min read
Voice-session reconnect recovery: resume the service, not the side effect
Network loss is normal in voice. Restore intelligible conversation state without replaying speech, confirmations, or consequential actions that may already have happened.
Safe voice recovery
- 01Reconnect transport
- 02Read session record
- 03Reconcile operations
- 04Present recovery choice
- 05Continue or hand off
Media recovery never replays a consequential action by itself.
Original conceptual diagram · not a live trace or measured result.Separate transport from service session
A WebRTC connection, socket, or speech stream can die while the service session remains meaningful. Give each a different identifier. The transport attempt records connection negotiation and media state; the service session records authenticated scope, task state, pending operation IDs, and the last acknowledged conversational event. A fresh connection should not invent a fresh task or assume every queued media packet was heard.
MDN’s WebRTC session-lifetime guide describes signaling, connectivity, and disconnection concerns across a session. Use it to ground the transport distinction. The product rule for what survives loss is yours: keep only the minimum service state that a caller needs to recover safely.
Acknowledge what the caller actually received
For each important system utterance, record whether it was synthesized, started playback, completed playback, interrupted, or only queued. Those are different states. Likewise, distinguish speech captured locally, recognized by a server, displayed to the caller, and accepted as a confirmation. A reconnect should summarize only the last mutually established state, not the last text the server intended to send.
Hypothetical worked example: the assistant asks “Confirm Thursday at 3?” and the network drops after the caller says yes. On return, it says “I lost the connection while checking your confirmation. I could not verify the appointment outcome; would you like me to check its status?” It does not automatically book a second slot or claim the first was booked.
Reconcile operations before replay
If a disconnect occurs near an action boundary, inspect the operation ID and current job status first. If the outcome is known, report it. If it is pending or unknown, offer status checking or escalation. Do not replay the audio, tool call, or confirmation merely because the reconnect token is valid. Tie this route to the same idempotency record used by text and web channels where they share an action service.
RFC 8835 describes WebRTC transport architecture, including that media and data may use different transports and security mechanisms. That complexity is another reason not to treat transport recovery as proof of business completion. A green connection icon says nothing about whether an earlier provider call ran.
Provide an explicit recovery screen and phrase
When the user returns, show or speak a compact recovery card: connection restored, current task, last verified event, pending operation if any, and choices such as continue, check status, start over, or reach a person. Make the card available in text and captions; a caller with packet loss should not need perfect audio to regain control. Do not make them repeat secrets that the service already safely verified.
Set an expiry for resumable sessions. After it passes, require reauthentication or a fresh task rather than resurrecting old context. Expiry should invalidate the recovery token and any unconfirmed draft, not automatically cancel an operation that may have already reached an external system.
Test loss at each boundary
Exercise loss while listening, while transcribing, before a prompt plays, during playback, after a confirmation, during an external call, and while status is being fetched. Test duplicate reconnect callbacks, an old browser tab reconnecting after a newer one, and a revoked user session. Assert that actions do not repeat, captions match the recovered state, and the user can decline a proposed resume.
Success criteria are behavioral: every reconnect has a visible recovery state; no unacknowledged output is treated as received; all pending actions are reconciled by operation identity; and an unavailable status check is described as unavailable. Do not report a generic “reconnect success rate” as evidence of safe recovery.
Know when to stop resuming
Recovery can become harmful when identity, authorization, language, or the user’s goal is ambiguous. Offer a human route or a clean restart with a concise explanation. For regulated, urgent, or safety-critical workflows, the service owner may prohibit resuming certain stages entirely. That is a policy decision worth documenting before implementation.
A reconnect protocol cannot cure poor turn-taking or weak action confirmation. It is a containment layer for network interruption. Its promise should be modest: preserve enough verified state to continue safely, and make uncertainty visible when it cannot. Keep the recovery policy version beside the session record for review.
Take it into the review
Reconnect reconciliation card
| Boundary | Last verified state | Recovery action | Never assume |
|---|---|---|---|
| speech capture | audio received | show transcript for review | intent accepted |
| prompt playback | started only | offer repeat | caller heard all |
| confirmation | recognition pending | ask again | action approved |
| external call | operation pending | check status | completed |
A starting artifact to adapt to your service—not a ready-made policy, compliance certificate or test result.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.
What the sources establish
Lifetime of a WebRTC session
MDN documents WebRTC session setup and the need to handle connection lifecycle events such as signaling and connectivity changes.
Limits: It does not define application-level recovery state or action semantics.
Checked 2026-09-19 · MDN Web Docs · source publication date not established.
Open original source ↗RFC 8835: Transports for WebRTC
RFC 8835 describes WebRTC transport protocols and their media and data transport architecture.
Limits: Transport design does not establish whether an application side effect completed.
Checked 2026-09-19 · RFC Editor · source publication date not established.
Open original source ↗Procedures and worked examples are editorial synthesis. Preparation/review dates are not claimed historical publication dates.