WebSocket channel

platform v0.9.11verified 2026-05-14

Behind every Delphi WebRTC conversation runs a WebSocket channel between the client (browser/mobile) and the platform. It carries session control messages, tool-call requests, transcripts, and runtime updates — alongside the WebRTC media for voice calls.

⚑Feature required: webrtc

This feature is gated. Operators enable it per deployment in the Delphi Portal; if the flag is off, the surface described below is hidden from the UI and rejected by the API. See Feature flags for the full registry.

If you use the client SDK, you never see this channel directly — the SDK opens it, parses it, and gives you a higher-level API. This page documents the concept so you know what's going on under the hood, and so you can debug when something doesn't add up.

Why a WebSocket

REST is fine for "do a thing and tell me when you're done". A live conversation needs:

• Bi-directional streaming (the platform pushes transcript updates, the client pushes control inputs).
• Sub-second latency for tool callbacks and turn detection.
• Long-lived sessions that survive network blips.

A persistent WebSocket is the simplest fit; it keeps the connection open for the lifetime of the session.

Where the channel fits

• The client opens the session with a call token (for WebRTC) or directly with the SDK's session API (for other modes — see SDK sessions and modes).
• The platform routes the channel to the conversation engine running the relevant flow.
• WebRTC media is negotiated alongside the channel where applicable; the channel itself stays alive as the control plane.

What rides on it

Direction	Examples
Client → server	Microphone state, push-to-talk, manual hang-up, browser action acknowledgements.
Server → client	Transcript deltas, AI utterance markers, tool-call envelopes, runtime status, session end.

The full message catalogue lives in the SDK reference under Channel protocol. That page is the authoritative one for message shapes — they evolve with each SDK release.

When you might speak to it directly

Almost never. Reasons you might:

• You're writing a non-SDK client for a platform the SDK doesn't ship for. In that case, work from the SDK's source as the reference implementation.
• You're debugging an SDK-platform mismatch and want to look at the wire to confirm what's going past the SDK.

In both cases, the SDK source under the public client SDK is the only public source-level reference. Do not pin against an unpublished protocol version — see Compatibility.

See also

• SDK overview — the typed client to use instead of speaking to the channel directly.
• Channel protocol — exhaustive message catalogue.
• Sessions and modes — the SDK's session abstraction over the channel.