← All guides · Voice agents in production

Voice Agent Transport: WebRTC vs WebSocket, and Where SIP Fits

Part 5 of Voice agents in production · 1,231 words · ~6 min read · published 2026-10-09 · updated 2026-10-09 · Markdown variant

WebRTC vs WebSocket for voice AI agents: which transport each vendor documents as of the corpus's 2026-07-09 verification, how cascaded stacks use WebSocket components, a decision tree by client type, and a per-transport test checklist.

Part of the Voice AI Agent in Production: Architecture, Latency, Handoff and Launch guide.

The transport for a voice agent is the channel that carries audio between the caller's client and the model, and the voice-realtime-agents reference says the choice tends to follow the client: WebRTC for browsers and mobile, WebSocket for server-to-server, and SIP where a vendor adds it for telephony. This article is the deeper companion to the transport section of voice AI agent in production. It adds a per-vendor matrix, the cascade case, a decision tree and a test checklist, and leaves the contract itself to voice and realtime agents.

Every vendor fact below was web-verified by that reference on 2026-07-09. Its 2026-09-28 pass re-checked only the open-framework versions, not the vendor APIs, so re-confirm a row before building on it.

What transport does each voice API document?

Each of the four native speech-to-speech APIs in the corpus documents WebSocket, and OpenAI is the only vendor the reference records with first-party WebRTC and SIP paths (AWS publishes a WebRTC reference implementation for Nova Sonic). The matrix below restates the reference per vendor.

Absence from the table is not proof of absence in the product. The reference records what it verified, and a vendor may have added a path since.

Why does OpenAI recommend WebRTC for browsers?

As of July 2026, OpenAI recommends WebRTC for browser and mobile clients because of lower jitter and NAT traversal handling, per the reference. That is the only reason the corpus gives for WebRTC. It states no benchmark comparing WebRTC with WebSocket and no latency figure per transport, so this article claims neither that one transport is faster than another nor a number for either.

What does "OpenAI-compatible" mean for transport?

It means the client protocol is shared, so switching vendors is not a transport migration. The reference says xAI matches the OpenAI Realtime specification and that clients built for OpenAI Realtime can point at it with minimal changes. Both sides use WebSocket in that pairing, so the change is endpoint, credentials and model name. Test event handling anyway, since "minimal" is the reference's word, not a guarantee.

Which transport do the cascade components use?

The streaming components the corpus lists for a cascaded stack are all documented over WebSocket: Deepgram for speech-to-text, and ElevenLabs and Cartesia for text-to-speech. For how cascaded and native stacks differ, see voice agent architecture: cascaded vs speech-to-speech.

This is inference, not a corpus claim: in a cascade with a browser or mobile caller, the WebRTC leg typically ends at your server, and your server speaks WebSocket to the transcription and synthesis services. The consequence is that the client-facing transport and the component-facing transport are separate decisions. Choosing WebRTC for the caller does not change how the components connect, and a WebSocket-only component does not rule out a WebRTC client.

How should you choose a transport by client type?

Start from where the caller is, then check what your chosen vendor or framework documents. The tree below is the author's inference built on the reference's pattern.

1. Caller in a browser or mobile app. Use WebRTC if the vendor offers it. OpenAI does, Pipecat lists WebRTC transports, and LiveKit Agents runs on LiveKit's WebRTC infrastructure. If the reference records only WebSocket for a vendor, as it does for Gemini Live and xAI, a relay or framework may need to sit between the app and the model (as inference; the reference also notes a LiveKit plugin for xAI).
2. Your server talks to the model. Use WebSocket. Every vendor in the matrix documents it, and OpenAI recommends it for server-to-server.
3. Caller on a phone. Look for a vendor SIP path or a telephony integration, covered in the next section, and treat the vendor documentation as the authority.
4. More than one of the above. Keep the model-facing leg on one transport and vary only the client-facing leg, so a new client type does not touch the model integration. This is a design preference, not a corpus claim.

Where does SIP fit, and what does the corpus not say?

SIP is a telephony path that the corpus records for OpenAI and nothing more: the reference says an OpenAI SIP integration path is available for telephony and gives no detail beyond that. It also records that Amazon Nova Sonic works with Amazon Connect, Vonage and Twilio.

Phone-specific mechanics are out of scope because the source material is silent on them: trunk setup, DTMF and phone-network effects get no claims here. For phone calls, rely on the vendor's own telephony documentation and test with real calls.

Which transports do the open frameworks support?

In the reference, Pipecat's transport list spans WebRTC (Daily, LiveKit, SmallWebRTC), WebSocket and telephony, while LiveKit Agents sits on LiveKit's WebRTC stack. Pipecat models its pipeline as frames flowing through transport, speech-to-text, language-model and synthesis stages, which suggests, as inference, that the transport is one stage among several.

Picking a framework therefore picks a transport menu. If you need WebRTC to a browser and a vendor offers only WebSocket, a framework can sit between them. The reference lists OpenAI Realtime, Amazon Nova Sonic and Gemini Live among Pipecat's speech-to-speech services, and says LiveKit Agents covers cascaded and native backends without application changes.

What should you test for each transport?

Test each transport for connection lifecycle, interruption behavior and failure handling on the real network path, because the corpus gives no transport-specific test guidance. The checklist is inference.

• Connect and reconnect. Drop the connection mid-turn and confirm the agent recovers or hands off audibly rather than going silent.
• Barge-in across the wire. Interrupt the agent from the real client and confirm queued audio stops. The method is in testing turn detection and barge-in.
• Real client networks. Run from a mobile network and a restrictive office network, not only a developer machine, because the corpus names NAT traversal as a WebRTC concern.
• Tool calls on the same session. Confirm function calls and results flow over the chosen transport. See function calling in a voice agent.
• Measure per leg. Time the client leg and the component legs separately, per the voice agent latency budget.
• Phone path. Place real calls, since nothing else in the corpus covers it.

What does ChangeGamer's own experience add?

Nothing about voice transport: as of October 2026 ChangeGamer runs no voice agent and carries no call traffic. Its own agent-facing surface, is HTTPS and JSON endpoints, an llms.txt file, and an HTTP 402 payment-required response, so nothing here is a measured result from its own WebRTC, WebSocket or SIP deployment. Everything transport-specific comes from the reference and its 2026-07-09 vendor verification.

The remaining sub-articles in the voice agents cluster cover the other production decisions.

#voice #webrtc #websocket #sip #transport #realtime #agents #production