Realtime SIP call ended unexpectedly while caller was still speaking (Twilio -> OpenAI SIP, child leg completed with 200)

API
,
1

Hi team,

We observed an unexpected call termination in a Twilio → OpenAI SIP → Realtime setup, and I’d like to check whether anyone has seen similar behavior.

Summary

A live call was transferred from Twilio to an OpenAI SIP endpoint for a Realtime voice agent.
While the caller was still speaking, the child SIP leg ended as completed from Twilio’s perspective, and our parent call then hung up because our scenario treats child-call completed as end-of-call.

At the moment, we do not have evidence that our app explicitly ended the session.

What happened

  • Parent inbound call started at 2026-04-13 00:17:52 UTC
  • Caller selected the AI transfer option via DTMF
  • Child SIP leg connected to OpenAI and became in-progress at 2026-04-13 00:18:23 UTC
  • Twilio shows the child leg ended at 2026-04-13 00:18:52 UTC
  • Twilio status for the child leg was:
    • CallStatus=completed
    • SipResponseCode=200
    • CallDuration=29
  • Our parent call then ended because our TwiML flow maps child completed → end → <Hangup/>

Why this looks unexpected

The recording suggests the caller was still talking when the call ended.
The call does not sound like a natural hang-up by the caller.

In Japanese, the caller was cut off around:
...to iu renraku ga kite ita ndesu kedo mo...
which roughly means:
...we had received a message about that, but...

So from the recording, it sounds like the call was interrupted mid-sentence.

What we confirmed on our side

1. No explicit app-side session finish

In our application logs, we did not find:

  • our normal finish_session tool execution
  • our app-side forced hangup logic
  • relevant application exceptions around the termination point

2. Realtime transcript stopped earlier than the recording

In our Realtime-side logs, the last user transcript entries were approximately:

  • Green Eco Construction, this is Kishi speaking.
  • Um...

However, the recording contains additional caller speech after that point.
So it appears the Realtime / SIP path may have stopped processing before the caller had actually finished speaking.

3. Twilio sees this as a normal completion, not an error

Twilio call events for the child leg were roughly:

  • initiated
  • ringing
  • in-progress
  • completed

And the final SIP response code was 200, not an obvious failure code.

Architecture

Our flow is roughly:

  1. inbound Twilio voice call
  2. IVR / DTMF selection
  3. Twilio <Dial> to OpenAI SIP endpoint
  4. OpenAI Realtime voice agent handles the conversation
  5. if child leg completes, our current scenario ends the parent call

So in this case, the parent call ending is a downstream effect.
The main question is why the child SIP / Realtime leg completed while the caller was apparently still speaking.

One related thing we noticed

Twilio logged one warning on the child call:

  • Warning code: 32113
  • Message: Specifying this header is not allowed: SipHeader_X-Parent-CallSid

We are not sure this is related to the unexpected completion, but mentioning it in case it matters.

Question

Has anyone seen a case where:

  • Twilio → OpenAI SIP call becomes completed
  • SIP response code is still 200
  • there is no app-side finish_session
  • and the caller appears to be cut off mid-sentence?

Also, is there any OpenAI-side logging or known Realtime/SIP behavior that could cause the SIP leg to close cleanly from Twilio’s perspective even though the conversation was not actually finished?

Redacted identifiers / metadata

  • Date: 2026-04-13
  • Parent call duration: 60s
  • Child SIP leg duration: 29s
  • Region / carrier details omitted for privacy
  • Full call SIDs omitted here, but available if needed in a private support channel

Any guidance would be appreciated. Thanks.

2

Hey @Toshi, I totally get why this one’s concerning, especially since the caller was still speaking and the SIP leg shows a clean 200.

What this points to isn’t really a SIP failure, but more likely the Realtime session ending underneath. In this setup, the SIP call and the AI session are loosely coupled, so it’s possible for the AI side to stop (due to a timeout, error, or backend hiccup) while the SIP side still wraps up “normally.”

That lines up with what you saw:

  • transcript stops early
  • no explicit session finish
  • Twilio shows a clean 200 completion

So the likely flow is the Realtime session dropped first, then the SIP leg closed cleanly afterward.

There’s also some overlap with the recent 401 issues. Those can cause backend instability, which can interrupt active Realtime sessions without surfacing as a SIP error.

A couple things worth checking:

  • any error or input_audio_timeout_triggered events
  • session disconnects or gaps in streaming
  • timestamps lining up with the 401 incident

Feel free to check the Realtime API with SIP setup here: Realtime API with SIP or create a support ticket via help.openai.com if the issue persists.

-Mark G

1 Like