Working on an app for a few months that are using the Realtime API over WebRTC and it has been working pretty well until today.
Now it starts transcribing the user’s voice as complete gibberish in some conversations.
I can have a conversation and everything works great and then end that call and start a new and then nothing works.
See attached screenshot. For every user line the user said something that made sense and this is what it is transcribed as.
We are using: gpt-realtime-2025-08-28 and gpt-4o-mini-transcribe.
Hello, I’m glad you posted this because I’m experiencing exactly the same problem while it worked fine until today : Using WebRTC with Realtime API, user’s transcriptions randomly start to make no sense. And when this kind of gibberish transcriptions occur, the assistant seems blocked and stop responding. I have no idea why so hoping that this is fixed rapidly.
I agree. Right now, the issue is intermittent, but it’s happening fairly consistently — roughly 1 out of every 5 connections. When a client connects via WebRTC, the stream either transcribes correctly for the entire connection duration, or from the very start it fails by either transcribing incorrectly (nothing close to the input) or not detecting/transcribing speech at all. After the first sentence of a new connection, I can already tell whether that session will produce a valid transcription or if it will fail for the duration of that connection. So I have to cancel and retry until we get a “good server” or something. And to re-iterate, we did not detect this issue prior to 04 November, on either the legacy Beta API or the GA (/calls) API. Also tried gpt-4o-mini-transcribe, and gpt-4o-transcribe with the same issue. Anyone has ideas how to raise this issue to OpenAI so we know there is at least visibility from their side on this issue?
Do we know if the same issue exists if we use websockets instead?
Yeah we faced similar issues on Tuesday afternoon CET 4th Nov and yesterday. Exactly like you mentioned. No audio coming through to assistant neither transcript.
OpenAI mentionned an issue on their side “resolved” in 1h. Seems it look way longer.
Apparently working again now. But not great as we were testing with clients.
See here - corrupted audio over WebRTC. For some sessions it was working, for other it was absolutely hopeless.
Yeah looks a bit better now. But I had problems a lot longer than 1 hour. Hopefully it is starting to be resolved now. I think they added that later because when I was looking there was no indication of any problems. So the time was just made up.
I tried this morning, it worked for the first few exchanges then started responding out of context with lots of gebberish transcriptions. I tried using a different realtime model and switching from their openai/agents SDK to raw WebRTC implementation but none seem to be working so far.
I’m wondering maybe some regions are still affected after their fix.
I can confirm transcription via websockets works fine, however, there are other considerations such as being recommended for server to server only due to api key management, and sending audio in the correct format etc.
so it definitely seems to be specific to their webrtc apis, and its been a few days with no improvement.
If you are still seeing issues, please reach out to support@openai.com to try to escalate this issue. You will probably just talk to a Bot, but who knows?
If you’re still hitting this issue, could you post your call ID (from the Location header in the /v1/realtime/calls response)? That will help us understand what’s going on here.
Hi @juberti thanks for responding to this thread. Please can you check this session for me. The user input are mostly unrelated to the conversation. I am using the Realtime SDK openai/agent version 0.3.0
Here’s my call ID: rtc_u0_7517910fb54d4c91b3ef41924d5998be
I launched the test app I typically use to reproduce this issue. Previously, the issue would occur at least once within about 10 attempts. Although I haven’t used WebRTC for the past few days, as of today I can no longer reproduce the issue, so it appears to be resolved for me, and i have not changed my testing method. I’m not sure when the resolution occurred.