SIP: Caller hangup closes session WebSocket immediately, preventing event draining + early-hangup calls still accepted

API
, ,
1

Summary

When using the Realtime API over SIP, two related issues occur when the caller hangs up:

  1. If the caller ends the call after it’s connected, OpenAI immediately closes the session WebSocket.
    This prevents pending events (tool calls, transcription, output buffering) from being delivered, resulting in incomplete tool calls and partial transcriptions.

  2. If the caller hangs up while the call is still ringing, OpenAI still accepts the call and starts an agent session as if the call were active, even though no caller is present.
    This causes the agent to speak into a dead session, which then hangs until timeout.

Both situations differ from expected behavior and make proper cleanup difficult.

Issue 1: Immediate WebSocket close on caller hangup

Actual Behavior

  • When the caller hangs up, the session WebSocket is immediately closed by OpenAI.

  • No further events are delivered (e.g., tool calls, output_audio_buffer.stopped, transcription chunks).

  • This results in incomplete processing of the agent’s final output.

Expected Behavior

  • When the caller hangs up, OpenAI should not close the WebSocket immediately.

  • Instead, the session should enter a draining state:

    • Finish delivering any pending events from the agent.

    • Then close the WebSocket once no more events remain.

  • Optionally, the API could emit a specific event indicating that the caller disconnected before draining began.

Rationale

We encountered a similar issue when integrating with Twilio.
The fix there was to drain the agent’s event loop before closing the WebSocket.
The same pattern would avoid dropped tool calls and partial transcriptions in the SIP flow.

Issue 2: Caller hangs up while ringing, but OpenAI still accepts the call

Actual Behavior

  • Caller dials but hangs up before the call is answered.

  • The SIP provider still notifies the OpenAI webhook.

  • OpenAI accepts the call as if the caller were present.

  • The agent session starts (greeting, output events), but no events come from the caller side.

  • The session then hangs until timeout.

Expected Behavior

OpenAI should not accept the call if the caller has already disconnected.
Possible correct behaviors:

  • Reject the accept API call if the caller is no longer on the line, or

  • If accepted, immediately close the control WebSocket since there is no active caller.

Impact

  • Tool calls remain unfinished.

  • Transcriptions are incomplete.

  • Agent sessions leak or hang unnecessarily.

  • Confusing behavior especially in production environments with SIP trunks.

Proposed Improvements

  • Introduce a draining phase on caller hangup (deliver remaining events before closing).

  • Emit a “caller disconnected” event to let applications react cleanly.

  • Reject accept requests or close the session early when the caller drops before answer.

1 Like
2

Would be great to get a quickfix/workaround for Issue 2 in particular.

3

Thank you so much for the bug reports! I ticketed these and will get to work on them soon.

2.) I am especially surprised by. What SIP provider are you using, maybe we aren’t getting a BYE?

1 Like
4

That’s great to hear, thank you!

  1. We are using Twilio. The issue turns up quite regularly in prod for us, but it’s quite difficult to get the timing right in testing.
5

Thanks for the response, was fearing this will go unnoticed. Glad you’re taking a look as issue #1 in particular has been causing us headaches as people generally just hang up when done talking to AI.

As for issue #2, we’re also using Twilio Elastic SIP trunk. We’ve done some testing with Asterisk but I can’t say if the issue was present there as well. Let me check and get back to you.

6

Hey everyone, Can somebody confirm if the issue still persists. Seems like our engineering team has resolved this issue but if not happy to take a look. Thanks!

1 Like