That distinction changes how developers should read the headline. A model may decide that it needs an account lookup, but the application still defines the tool, runs it in an environment it controls, validates its arguments, enforces authorization, and returns a result. For Windows developers building browser assistants, Teams-adjacent support tools, internal help desks, or contact-center integrations, the hard work remains in that security and systems layer.
OpenAI lists GPT-Realtime-2.1 as its default Realtime model as of August 2026. The company says the model improves alphanumeric recognition, handling of silence and background noise, and interruption behavior compared with GPT-Realtime-2. It accepts audio and text, returns audio and text, accepts images as input, and supports function calling. It does not support video input, despite the broader “multimodal” description that can lead teams to assume a webcam stream can be sent to the model directly.
A live session changes the interaction model
Traditional voice bots commonly stitch together speech-to-text, a text model, text-to-speech, and separate orchestration code. That workflow can work well for voicemail processing, meeting summaries, and call transcripts, where a few seconds of delay are tolerable. It is a poor fit for an assistant expected to handle interruptions, pauses, corrections, and short back-and-forth exchanges without sounding like an IVR menu.
Realtime keeps the client or service connected while audio moves into the session and generated audio comes back. The session maintains conversational state, including the user’s messages, model output, tool calls, and any truncation that occurs after an interruption. OpenAI’s Agents SDK documentation shows why this matters: when a caller speaks over a response, the SDK can stop local playback and truncate the assistant’s audio history to the portion the user actually heard.
That is a subtle but material design requirement. If an app merely stops its speakers while leaving the model’s conversation state untouched, the model can continue as though it delivered a long explanation the user never heard. The next turn then begins from two different versions of the conversation: the user’s real experience and the model’s internal history. A voice UI that handles barge-in—the industry term for a caller interrupting an automated speaker—must keep both synchronized.
The API’s default turn-taking also relies on voice activity detection, or VAD. Developers can use semantic VAD, which tries to infer whether a speaker has finished a thought, or more threshold-based server VAD settings that react to audio levels and configured silence periods. Neither setting can be treated as a universal default. A quiet office worker with a headset, a warehouse employee near machinery, and a caller on a mobile network create different noise, pacing, and interruption patterns. Teams should test turn detection against recordings from their actual deployment environment rather than tune it on clean desktop microphone audio.
WebRTC is the browser path; WebSocket is the control path
Analytics Insight presents WebRTC, WebSocket, and SIP as choices that fit browser apps, server-side systems, and telephony. That description is broadly accurate, but OpenAI and Microsoft’s Azure documentation make a sharper recommendation: use WebRTC for browser and mobile voice applications whenever the app is streaming live microphone audio.
WebRTC exists to carry real-time media. It brings media-oriented handling for codecs, jitter, packet loss, encryption, and changing network conditions. Microsoft’s current GPT Realtime guidance explicitly says WebSockets are not recommended for real-time audio streaming when WebRTC is viable, citing the latter’s lower latency and media handling. OpenAI’s own engineering account of the Realtime infrastructure confirms that its WebRTC service terminates session signaling, encryption, connectivity checks, and media traffic before passing simpler internal protocols to inference and orchestration services.
WebSocket still has a strong place. It suits a server-managed voice service, an existing audio pipeline, monitoring systems, custom playback software, and applications that need direct access to the event stream. The trade-off is responsibility. OpenAI’s SDK documentation says WebSocket users must capture and play audio themselves; mute state and playback interruption also become application tasks. A browser team choosing WebSocket merely because it is familiar can inherit an avoidable set of audio, timing, and state-management problems.
WebRTC has a separate security implication for browser apps: the browser must never receive a long-lived API key. The documented pattern is for the application’s backend to create a short-lived client secret or proxy the session negotiation, then let the browser establish its media session. The backend remains the trust boundary for the organization’s OpenAI credentials, system instructions, tool configuration, and sensitive third-party credentials.
That boundary deserves more attention than it typically receives in voice-agent demos. OpenAI’s SDK states that local function tools run wherever the Realtime session runs. Put a session in the browser and its local tool code runs in the browser. A function called getCustomerBalance or issueRefund must therefore be a thin request to a controlled backend, where the server checks the user identity, applies authorization rules, logs the request, and talks to the financial or customer system. It should never expose a privileged database credential or business-system token to JavaScript delivered to the client.
SIP makes phone calls possible, not contact centers complete
SIP support is the part of the API most likely to attract IT departments that already operate PBXs, session border controllers, Microsoft Teams calling integrations, or carrier trunks. SIP gives the Realtime API a route into standard telephony architecture, allowing an inbound or outbound call flow to reach an AI service without asking callers to install a browser app.
That is useful, but it does not eliminate the telephony stack. Organizations still need a phone number or carrier relationship, call routing, emergency and regulatory handling where applicable, recording and retention rules, transfer logic, authentication, voicemail behavior, failure routing, and human escalation. OpenAI supplies the model-facing live session; it does not replace the operational controls that make a production call center accountable.
There is also a practical quality issue. GPT-Realtime-2.1 supports improved recognition of alphanumeric information, according to OpenAI, which is relevant to serial numbers, case IDs, tracking codes, and account references often spoken on calls. That improvement should be verified against the actual identifiers a business uses. A model that correctly recognizes “A B 8 1” in a controlled benchmark can still mishear an accented caller, a damaged mobile connection, or an identifier given quickly amid background noise. For workflows where one wrong character can expose the wrong account, confirmation rules and server-side validation remain mandatory.
SIP integrations should begin with narrow, reversible work: caller triage, office-hours information, knowledge-base answers, appointment requests, or agent-assist. Letting a voice model make consequential account changes on an unauthenticated phone call is a much larger authorization decision than adding a conversational front end.
Function calling adds latency and authority questions
The order-check and account-lookup examples in Analytics Insight are reasonable examples of function calling, but “the model can ask an external system” compresses several failure modes into a friendly sentence. The model selects a tool based on its instructions and the tool descriptions provided by the developer. It does not independently gain safe, correct access to enterprise data.
OpenAI’s Realtime Agents documentation supports local function tools and remotely executed hosted MCP tools. It also exposes an approval mechanism: a tool can request user approval before it runs. The caveat is important in a voice experience: while the agent waits for approval, it cannot process new user requests. Approval protects against an unwanted action, but it also creates dead air unless the product has a clear spoken prompt and a user interface or DTMF-style equivalent for consent.
A tool call can also freeze the conversation while the backend works. OpenAI advises that while a function tool executes, the agent cannot process new requests. Its SDK includes timeout handling and an option for background results, but those controls do not make a slow inventory system, CRM, or identity provider fast. The practical implication is straightforward: keep synchronous voice tools small and fast. Retrieve an order status, validate an appointment slot, or create a support ticket; defer long-running research, multi-stage eligibility calculations, document generation, and complicated fulfillment actions.
Developers should also separate read tools from write tools. Reading a shipping status after a caller passes authentication is lower risk than canceling an order, changing an address, issuing a refund, or exposing account information. Write actions should use narrow schemas, server-side policy checks, idempotency controls, audit logging, and explicit confirmation. The model’s natural-language statement that it “will process the refund” should never be treated as proof that a refund occurred; the backend response is the record that matters.
OpenAI provides output guardrails in its SDK that can inspect generated text transcripts and cut off a response when a configured condition is triggered. Those guardrails are useful, but they are asynchronous and operate on output as it is generated. They are a supplementary control, not a replacement for authorization at the tool boundary or for application-specific privacy rules.
The cost and model trade-off are easy to overlook
GPT-Realtime-2.1 brings a larger 128,000-token context window and up to 32,000 output tokens, plus configurable reasoning effort. OpenAI also warns that higher reasoning effort can increase latency and output token use. That warning should steer product decisions: a real-time help-desk voice assistant generally benefits more from fast routing, accurate retrieval, and short tool calls than from deep reasoning before every sentence.
The current listed price for GPT-Realtime-2.1 is $4 per million text input tokens and $24 per million text output tokens, with audio priced at $32 per million input tokens and $64 per million output tokens. Caching materially changes the economics for repeated context, but it does not make open-ended conversations free. The free usage tier is not supported for the model, and the documented usage limits vary by paid tier.
For a Windows admin tool, that suggests a disciplined pattern: send compact live context, use an internal retrieval or tool layer for current device and ticket data, cap answer length, and end inactive sessions promptly. Do not stuff a year of ticket history, inventory exports, and policy documents into every voice session simply because the context window permits it.
The Realtime API is ready for products where users genuinely need to talk, interrupt, and receive an immediate answer. It is a poor default for every task that happens to involve audio. The teams that benefit most will choose WebRTC for interactive clients, retain server-side control of all privileged tools, and treat every call to an order system, identity service, or admin console as an audited action—not as a flourish in a voice demo.