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.
Thanks for flagging this and for the details shared so far. Issues like this are often related to the input audio, e.g. a microphone issue or an unexpected audio sample rate, but I'm happy to investigate further on our side.
For anyone still affected, could you share a few recent session IDs where you ran into the problem? It would also be helpful to see the transcription output along with any available metadata.
Hi. Problem persists. You can take a look at this req id from audio.transcriptions.create
req_4c23350313954671b280782949d49a7b
whisper looks fine, but 4o-transcribe and 4o-mini-transcribe are returning nonsense consistently (random text in random language).
Transcription(text=‘Šiandien mes tikimės išsinuomoti būtent šito buto.’, logprobs=None, usage=UsageTokens(input_tokens=69, output_tokens=22, total_tokens=91, type=‘tokens’, input_token_details=UsageTokensInputTokenDetails(audio_tokens=69, text_tokens=0)))
original audio was a common sample:
”The sun rises in the east and sets in the west. This simple fact has been observed by humans for thousands of years.”
We checked the server-side trace and the request itself completed normally, which usually points to an issue with the input audio rather than a backend error. Common causes we see with “gibberish” transcriptions are microphone issues, unexpected sample rates, channel mismatches, or audio that’s being corrupted before it reaches the API.
A couple things we suggest trying:
Experiment with the audio format (for example WAV PCM16, mono, 16kHz or 24kHz).
Double check the mic source and ensure the audio being sent is what you expect.
Use the tracing feature to listen to the audio as received server-side. This can help confirm whether the audio sounds correct before transcription.
If you can share what audio format and capture setup you’re using, or what you hear when listening to the traced audio, we'd be happy to investigate further!
