or some explicit event indicating that final input audio was discarded because the caller hung up before VAD/commit.
This is particularly important for phone-agent use cases because callers often finish speaking and hang up immediately. In those cases, the recording is complete, but the Realtime conversation history is missing the final utterance.
Could you confirm whether the SIP caller-hangup event draining fix is expected to cover this case?
Also, is final input audio transcription guaranteed to be emitted before the Realtime SIP WebSocket closes when the caller hangs up immediately after speaking? If not, what is the recommended way to reliably capture the caller’s final utterance?
Hi @Toshi, based on the docs, transcription is only emitted after the input audio buffer is committed. With server_vad, that commit depends on turn detection. If the caller hangs up immediately after speaking, the SIP/WebSocket session can close before the buffer is committed and before transcription events are emitted.
So I wouldn’t assume final transcription delivery is guaranteed in immediate-hangup cases.
The safest pattern right now is usually:
Use Realtime transcription for live interaction state
Treat Twilio recordings/transcripts as the fallback source of truth for the final utterance
Optionally reduce reliance on automatic VAD by manually committing audio for critical flows
Could you share more information that would help narrow this down:
Call_ID and request_ID
Whether input_audio_buffer.committed is emitted before the disconnect
Your turn_detection setup (server_vad vs manual commit)
A short event timeline/log around hangup (speech_stopped, commit, transcription events, SIP BYE, WebSocket close)
Those usually make it much easier to tell whether this is a VAD/commit timing issue or an event-draining problem during SIP teardown.
Start a Realtime SIP call through Twilio to OpenAI SIP.
Let the assistant finish its prompt.
The caller starts speaking a relatively long utterance, around 15-30 seconds, without leaving enough silence for VAD to finalize the turn.
The caller hangs up immediately after finishing the utterance, or while the utterance is still being finalized.
The Twilio recording contains the caller’s final speech, but the Realtime event stream does not emit the final input transcription events for that speech.
Internal request id in our app: 58cd683f-b34e-490f-bbbe-74fe8ca48af6
We do not have the OpenAI API x-request-id for this historical call because we were not logging the response headers from the realtime.calls.accept request at the time.
Timeline:
The assistant finished speaking at around 2026-05-11 02:11:03 UTC.
The SIP leg completed at around 2026-05-11 02:11:31 UTC.
The Realtime session disconnected at around 2026-05-11 02:11:32 UTC.
The final caller speech exists in the Twilio recording.
We did not receive conversation.item.input_audio_transcription.delta or conversation.item.input_audio_transcription.completed for that final speech.
So we cannot yet confirm whether input_audio_buffer.committed was emitted before the disconnect for this historical call. We are planning to add logging for those events.
The important pattern seems to be: caller speaks for a long enough time, then immediately disconnects before VAD has finalized/committed the input audio buffer.
Could you confirm whether Realtime SIP is expected to commit and emit a final transcription for any pending input audio when the SIP caller sends BYE / hangs up? Or is this currently a known limitation where applications should always use the recording as the fallback source of truth for the final utterance?
Hi @Toshi. There was an issue around the Realtime API SIP/WebRTC flow that caused some pretty confusing behavior for a few folks.
Can you check if you’re still seeing it now? A fix was rolled out recently, so there’s a good chance the behavior has changed since the original report.
Yes, I am aware of the recent SIP-related issues. However, the problem I reported has been occurring consistently both before and after those fixes were rolled out.
I believe the root cause is that when connecting to the Realtime API via SIP, the WebSocket session closes immediately as soon as the caller hangs up. Because of this, the final transcription events, such as conversation.item.input_audio_transcription.delta or conversation.item.input_audio_transcription.completed, are never sent.
@Toshi, your read is likely right: in SIP Realtime sessions, the WebSocket can close fast after BYE / hangup. If VAD hasn’t committed the final audio yet, the transcription events may never fire.
Right now, final transcription is not guaranteed when someone talks continuously and hangs up immediately.
A few things worth logging:
speech_started
speech_stopped
input_audio_buffer.committed
If you see speech_started but no committed before disconnect, that points to the final audio never becoming a conversation item.
Best workaround for now is to save transcription deltas as they arrive, and use the Twilio recording as fallback for the caller’s last utterance in these quick-hangup cases.
Thanks for the info. I’ll proceed with the implementation based on your advice.
If possible, it would be great to have this information documented in the API or SDK docs. It’s a tricky issue that’s hard to notice until you’ve been running in production for a while, so having a heads-up would help many developers avoid the same pitfall.
I really appreciate all your support so far. You can go ahead and close this ticket.