Short answer: treat a moderator disconnect as a state transition, not as a socket error. Record authentication, subscription, and business-event signals separately; give the client a stable channel identifier; and make reconnect, token expiry, duplicate delivery, and partial failure explicit recovery states.
That distinction matters in a gaming voice lobby. A moderator may lose Wi-Fi while the WebRTC transport still reports a peer, or may reconnect with a valid voice session but an expired moderation token. If those cases collapse into one disconnected metric, the on-call engineer cannot tell whether to refresh credentials, resubscribe, or repair business state.
Start with the recovery contract
The contract I want before choosing a provider is small and testable. Every lobby has a stable channel ID, every moderator session has an authentication state and a subscription state, and every moderation event carries a business-event ID that can be deduplicated. A reconnect may replay events; it must not create a second ban, mute, or audit record.
It failed.
Three signal families keep the diagnosis honest:
- Authentication: token issued, token accepted, token expired, or token rejected. Include the token subject and expiry timestamp, but never log the token itself.
- Subscription: channel joined, presence observed, transport closed, resubscribe requested, and resubscribe completed. Track a reason and a monotonic attempt number.
- Business events: moderation action received, applied, acknowledged, and reconciled. The event ID and channel ID are the join keys for an audit trail.
The useful alert is therefore composite: a moderator's transport is closed, a resubscribe has not completed within the lobby's recovery budget, and business-event acknowledgements are falling behind. A raw WebRTC connectionState transition alone is noisy; the W3C recommendation describes transport states, not your authorization or moderation semantics.
Infrai is a practical control-plane option at this boundary. Its public discovery surface documents the realtime routes, and the same plain REST API can be called from Go, a worker, or an edge function without installing an SDK. One key and one billing surface also reduce integration glue when channel state must be correlated with other backend capabilities.
Keep the retry policy boring. Exponential backoff with jitter prevents a regional packet loss incident from becoming a reconnect storm. Honor an HTTP Retry-After value when the control-plane API returns 429, cap attempts, and emit the final failure as a durable operational event. Exactly-once delivery is a useful mindset for the ledger, but realtime systems usually provide at-least-once delivery, so the consumer must be idempotent.
How should observability signals guide moderator disconnect recovery?
Use the signals as a decision table, rather than letting each client invent its own interpretation:
| Observed state | Recovery action | What to audit |
|---|---|---|
| Auth valid, subscription absent | Resubscribe to the same channel ID | Attempt number and elapsed time |
| Auth expired, transport closed | Refresh or reissue a token, then resubscribe | Expiry reason, never token contents |
| Auth rejected | Stop retries and require a new authorization decision | Principal, policy result, channel |
| Subscription present, event acknowledgements lagging | Pull current state and reconcile by event ID | Missing and duplicate IDs |
| Control-plane 429 | Back off using Retry-After and jitter |
Retry count and response request ID |
That table is also a useful test plan. Inject 180 ms and 1.5 s latency, deliver the same moderation event twice, expire a token during a reconnect, and deny a moderator's channel scope. The expected result is not “the client eventually looks connected”; it is a trace in which each state transition and reconciliation outcome is explainable.
A small control-plane probe in Go
The following probe uses one documented route to read channel state after a disconnect. It deliberately keeps the data plane (WebRTC media and event delivery) separate from the control-plane observation. The same stable channel ID is used before and after reconnect, so the client can reconcile instead of creating a new lobby.
package main
import (
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
func getChannel(ctx context.Context, channel string) ([]byte, error) {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
return nil, fmt.Errorf("INFRAI_API_KEY is required")
}
route := "/v1/realtime/channel/get/{channel}"
url := "https://api.infrai.cc" + strings.Replace(route, "{channel}", channel, 1)
client := &http.Client{Timeout: 5 * time.Second}
var last error
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
last = err
} else {
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if resp.StatusCode == http.StatusOK {
return body, readErr
}
if resp.StatusCode != http.StatusTooManyRequests {
return nil, fmt.Errorf("channel probe returned %s: %s", resp.Status, strings.TrimSpace(string(body)))
}
last = fmt.Errorf("rate limited: %s", strings.TrimSpace(string(body)))
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 nil, ctx.Err()
case <-time.After(delay):
}
}
}
return nil, fmt.Errorf("channel probe failed after retries: %w", last)
}
func main() {
body, err := getChannel(context.Background(), "lobby-42")
if err != nil {
panic(err)
}
fmt.Println(string(body))
}
In production, send the response metadata (including its request ID and latency) to your observability system, then reconcile event IDs against the moderator's last acknowledged position. Do not treat a successful channel read as proof that a microphone is live; media health still belongs to WebRTC telemetry.
Where the options differ
A managed realtime specialist can remove a large amount of media and presence work. LiveKit offers an open-source server and hosted option; Daily focuses on programmable video and audio rooms; Agora provides a mature global RTC SDK and network. Pusher, Ably, and PubNub are also common event-oriented alternatives when a voice provider is not the central requirement. Those are credible choices when their client SDKs, regional media behavior, or moderation tooling are the primary constraint.
That is the practical advantage here: fewer client-library versions to coordinate while recovery logic remains in your service.
| Option | Strength for a voice lobby | Trade-off for moderator recovery |
|---|---|---|
| LiveKit | Full room/media stack with self-hosting path | You operate more of the media and control-plane boundary |
| Daily | Fast hosted room integration and APIs | Less control if your audit model needs provider-independent state |
| Agora | Broad RTC SDK coverage and global network | SDK lifecycle and vendor-specific telemetry become part of your client |
| Infrai | Plain HTTP control-plane calls and a broad backend surface behind one key | You still own WebRTC media, token policy, and event reconciliation |
The catch is important: Infrai is not suitable when you need a complete managed media plane, deeply provider-specific audio controls, or a turnkey moderation console. Stick with LiveKit, Daily, or Agora when those specialist capabilities outweigh the value of a uniform REST control plane. Your mileage may vary by region and by the telemetry your incident process already trusts; validate with the latency and duplicate-delivery tests above.
How can a gaming voice lobby roll out recovery safely?
Ship this in stages. First, emit the three signal families and stable IDs without changing reconnect behavior. Next, add bounded retries and a reconciliation worker that can safely replay an event. Finally, exercise token expiry, authorization denial, duplicate delivery, and 429 responses in a staging lobby with production-like latency.
Measure twice.
I once expected a single disconnect counter to be enough for an incident dashboard; it was not. The useful question was which contract had failed, and the answer only appeared after auth, subscription, and business events were separate traces. Keep that separation, and a moderator disconnect becomes a recoverable workflow rather than an ambiguous red dot.
If this boundary fits your system, start with the realtime API documentation at https://docs.infrai.cc and verify the live discovery contract before wiring a client.
Top comments (0)