Skip to main content

The problem

A network blip mid-recording should cost no transcript and produce one continuous timeline — not a second recording that restarts at 00:00. The Live Speech API gives you two primitives that make this straightforward.
The full audio is the client’s responsibility to preserve. The server keeps no audio once a socket drops. Buffer the audio you send so you can resend the tail after a reconnect.

Two primitives

processed_until

On every transcript frame (and via ack), the absolute second up to which the server has consumed your audio. It only ever advances — even across trimmed silence.

timeline_offset_seconds

A config field. On reconnect, set it to the last processed_until you saw. The server then emits absolute timestamps from that point, so post-reconnect segments never collide with 00:00.

The pattern

1

Track processed_until

As transcripts (and acks) arrive, keep the latest processed_until. This is the durable high-water mark — everything at or below it has been safely consumed.
2

Trim your send buffer

Buffer the audio you send, timestamped on the same absolute timeline. Whenever processed_until advances, drop buffered audio at or below it — the server already has it.
3

On disconnect, open a new session

A reconnect is a new session. Wait for the old socket to fully close (see one session per user), then connect again with the same config, plus timeline_offset_seconds set to the last processed_until.
4

Resend only the tail

Wait for session_ready, then resend your buffered audio after the last processed_until, in order. Nothing the server already consumed is resent, and nothing is lost.
Because the server applies timeline_offset_seconds to every emitted timestamp, the segment, words, and speaker times after the reconnect continue seamlessly from where you left off. No client-side re-anchoring is required.

Timeline example

Say the last transcript before the drop reported processed_until: 42.6.
The new session’s seq restarts at a low number, but the times continue past 42.6 — so a single merged transcript reads as one continuous recording.

Reference implementation

One session per user

A user may have one active live session at a time. A second concurrent connection is rejected with an error frame of code: "session_conflict", and its socket is closed.
Reconnect only after the previous socket has fully closed. If you open the new session too early, it is refused with session_conflict. On an abnormal drop, wait for the close event (or a short delay) before reconnecting.

Diarization caveat

A reconnect is a new session, so speaker labels are assigned per session. Labels for audio after a reconnect are not guaranteed to match the labels used before the drop. Text and word timings remain continuous; only the per-speaker labels may shift. If stable cross-reconnect speaker labels matter to your use case, contact support@medisync.me.

Next steps

Messages

Where processed_until and ack appear on the wire.

Errors

Handling session_conflict, overloaded, and fatal closes.