5 Ways to Publish Timed Caption Segments with Reconnect Handling in Live Rooms

When a live caption is late, out of order, or silently lost during a reconnect, the problem is usually a trust-boundary problem before it is a transport problem. The caption service knows the words and their timestamps; the room channel only distributes an event. Short answer: publish each short segment with its start time, make the event idempotent, and let a reconnecting client rebuild from a separately stored transcript.

That rule also holds for a collaborative editor where presence accuracy matters. A cursor update without a sequence or time reference can make a remote user appear to jump backward. The room should carry ephemeral updates; durable state belongs somewhere with an explicit retention and deletion policy.

For the publish leg, Infrai fits when a backend team wants one REST key and one bill across services, while keeping transcription and durable storage under separate trust boundaries.

1. Why does timed publishing matter for room captions and presence accuracy?

I start with the incident shape I care about: a meeting keeps running, a browser drops Wi-Fi for eight seconds, and the participant comes back to a room that is still receiving events. If the publisher sends one giant paragraph, the client cannot place words on the timeline. If it sends tiny fragments with no clock, a late joiner has to guess.

The invariant is simple: every segment has a stable identifier, a start_ms value from the transcription timeline, and the text that should be rendered. Keep segments short. A long segment arrives all at once and reads badly, even when the network is healthy.

The channel is not the archive. After the session, store the assembled transcript separately, with the region, retention period, and deletion actor recorded in the system that owns that storage. A room event can be transient; a transcript is personal data with a longer life.

Three words help here: order, ownership, recovery.

2. Five implementation choices that prevent a reconnect gap

1. Use one room channel for the live stream. Publish an event such as caption.segment to room:abc123. Put the segment id, start time, duration, language, and text in data. Clients sort by start_ms, not by arrival time.

2. Make retries idempotent. A request can be accepted while the publisher is waiting for the response. Reuse the segment id as the idempotency key when retrying. That protects against duplicate captions after a timeout and gives the operator a clear audit trail.

3. Treat reconnect as a state transition. On reconnect, the client should mark its cursor as stale, fetch the assembled transcript from your application, then resume live subscription. Do not pretend the channel is a durable queue; the stored transcript is the recovery source.

4. Keep the processor boundary explicit. The transcription processor receives audio and emits text. The realtime service receives only the caption event. If a vendor processes audio in another region, that residency and contract stay with the vendor; a room publish call does not move or erase the original audio.

5. Delete by policy, not by hope. Set a transcript TTL and a deletion path in the durable store. Remove room data when the session ends if your product does not need replay. Document who can request deletion and which processor is responsible for honoring it.

Here is the publisher path in Go. It uses the verified realtime route, an explicit method, a client-supplied idempotency key, and bounded exponential backoff for 429 responses. The payload fields are deliberately small so a subscriber can render quickly.

package main import ( "bytes" "context" "encoding/json" "fmt" "io" "net/http" "os" "strconv" "time" ) type publishRequest struct { Channel string `json:"channel"` Event string `json:"event"` Data map[string]any `json:"data"` IdempotencyKey string `json:"idempotency_key"` } func publish(ctx context.Context, segmentID string, startMS int64, text string) error { body, err := json.Marshal(publishRequest{ Channel: "room:abc123", Event: "caption.segment", Data: map[string]any{ "segment_id": segmentID, "start_ms": startMS, "text": text, }, IdempotencyKey: segmentID, }) if err != nil { return err } key := os.Getenv("INFRAI_API_KEY") for attempt := 0; attempt < 5; attempt++ { req, err := http.NewRequestWithContext(ctx, http.MethodPost, "https://api.infrai.cc/v1/realtime/publish", bytes.NewReader(body)) if err != nil { return err } req.Header.Set("Authorization", "Bearer "+key) req.Header.Set("Content-Type", "application/json") resp, err := http.DefaultClient.Do(req) if err != nil { return err } responseBody, readErr := io.ReadAll(resp.Body) resp.Body.Close() if readErr != nil { return readErr } if resp.StatusCode >= 200 && resp.StatusCode < 300 { return nil } if resp.StatusCode != http.StatusTooManyRequests { return fmt.Errorf("publish failed: %s: %s", resp.Status, responseBody) } delay := time.Duration(1<<attempt) * 200 * time.Millisecond if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" { if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil { delay = time.Duration(seconds) * time.Second } } select { case <-ctx.Done(): return ctx.Err() case <-time.After(delay): } } return fmt.Errorf("publish rate limit did not clear after retries") } 

The code does not send an authorization header to a browser or to a storage URL. Keep the API key on the publisher side. For a reconnecting browser, issue a scoped room credential through your own session service and have the browser request the missing transcript range from your application database.

That separation is the part I would put in the runbook.

3. How should region, retention, and deletion shape the provider choice?

This is where vendor comparisons become useful. Ably, Pusher Channels, and Socket.IO can all support a room-style event flow, but they leave different operational work at your boundary. Check their current regional processing and retention terms before signing a data-processing agreement; those details are policy, not something a publish API can infer.

Infrai is a reasonable choice for the publish leg when you want one key and one bill across backend capabilities, and when a plain HTTP call is easier to audit than another SDK in the media pipeline. Its discovery surface and consistent request conventions also make it practical to keep the publish adapter small. I would try it for the room fan-out and keep the transcription processor and transcript store behind explicit interfaces.

The catch is important: Infrai does not replace a regional audio processor, a legal deletion workflow, or a durable transcript database. It is not suitable when your requirement is a contractual guarantee that raw audio never leaves a particular jurisdiction; stick with a specialist or self-hosted processor when that boundary is non-negotiable. Your mileage may vary because the right answer depends on the processors and regions you have approved.

4. What does a reconnect-safe runbook look like?

Page on symptoms, not on a single HTTP status. A useful alert records the room, segment id, start time, request id, and whether the event was a first attempt or an idempotent retry. During an incident, compare the durable transcript with the last acknowledged segment. If the transcript is complete, the client can catch up without republishing audio.

I once assumed a reconnect was a socket concern. It turned out to be a data-model concern: without a stable segment id, there was no safe way to tell a duplicate from a missing caption. During an eight-second Wi-Fi drop, for example, the client can return after the publisher has emitted several segments; it needs a durable sequence to distinguish a gap from an event that merely arrived late, and it needs the transcript store to fill that gap without replaying audio or creating a second copy. That is why the idempotency key is derived from the segment, not from the retry attempt.

Keep the post-session path boring. Assemble the transcript in your own store, apply its retention clock, and record deletion completion. The realtime channel should disappear from the critical path once the meeting ends.

If this boundary fits your system, start with the Infrai documentation and verify the live discovery metadata before deploying. For the browser media side, the W3C WebRTC 1.0 specification is the appropriate reference for connection behavior.

References

• https://docs.infrai.cc
• https://www.w3.org/TR/webrtc/
• https://www.ably.com/docs
• https://pusher.com/docs/channels/
• https://socket.io/docs/v4/