I’ve observed a problem with gpt-realtime sessions using Twilio SIP for the last few weeks, where a session continues despite the Twilio call record showing an SIP call duration of zero seconds and a status of “No Answer”. We receive a webhook notifying our server of the call and we accept the call and connect a websocket to listen for events. Normally, the websocket connection is closed by OpenAI when the Twilio call concludes, and we log the duration of the call. In these cases, the connection stays open for an hour then closes, and we record durations of 3,608 to 3,610 seconds.
Twilio’s recordings of these calls are less than two seconds long, so it appears that the call ends when the SIP request receives No Answer (recording starts just before the call is transferred to SIP). We would expect the call session to end at this point, closing websocket connections and refusing new connections.
Here is a list of UTC datetimes and Twilio call SIDs for some of these calls. In every case, Twilio outgoing dial was made to sip:proj_hQrGn5uofTdGyHoKRjkiKbKN@sip.api.openai.com;transport=tls
2026-04-03 22:45:31 CAe73a7e55664b10ce48d7ce0073b8b970
2026-04-07 14:06:56 CA2014a85aaefe9eb4c70a79e0556c9486
2026-04-07 18:26:37 CA217c730bf75d2c6f7530e9a3c1c691d6
2026-04-10 19:35:25 CA165f547f0558a9490a131b48bab7fd5d
2026-04-12 14:41:17 CA9e3a4538da0bb9eab1c11238eea9e684
@andrew_tomis.tech, appreciate you sharing this and including the timestamps + session ID, that really helps narrow things down.
This does sound familiar. We’ve seen a similar case before where the realtime session didn’t terminate even though Twilio marked it as “No answer,” and that one ended up being resolved on the backend side. So this might be related or a regression.
I’ll flag this with the engineering team so they can take a closer look. If you happen to catch any newer examples, feel free to drop them here too, those patterns help a lot.
Also, if anyone else is seeing the same mismatch between Twilio status and session behavior, chime in. It helps confirm if this is more widespread.
-Mark G
Here’s a more complete list of the events that we’ve logged. There are more events that we suspect as having experienced this bug, but we can’t confirm those for sure. None of these events date prior to Mar 28, although there are records of additional SIP No Answers before that date in our Twilio logs. So it’s possible that the regression corresponds to code released on Mar 27 or 28.
| UTC |
Twilio Call SID |
| 2026-04-04 19:15:25 |
CA292b8e91934fc9699836794c75412566 |
| 2026-04-04 10:27:52 |
CAa049f5850c92c90ceda67b8f23a95639 |
| 2026-03-28 21:10:06 |
CA73a244248c34afbf8d930fa5b3a92278 |
| 2026-04-04 23:16:28 |
CAa49c8dddd3478fa44bce1224223bed3d |
| 2026-04-17 18:13:56 |
CA6b5832e9ad23ffe573ec04817a409c12 |
| 2026-04-11 22:25:36 |
CA6d273c39da5dfe7ef0a3e4db4c7c26ae |
| 2026-04-04 23:16:48 |
CA56bea5d63ca382374eba7ea2e29f7686 |
| 2026-04-17 13:40:50 |
CA4cd3ef8850f1bcc9cf056a245a267537 |
| 2026-04-03 18:28:31 |
CA59cc73a87851ec8d0523ee96e6c7b297 |
| 2026-04-12 19:16:42 |
CAc4a07a4f092e373feac78a5c95507920 |
| 2026-03-31 19:07:27 |
CA2b4fa5230f422df240d7bd886995e8f2 |
| 2026-03-29 08:33:26 |
CA7a15b533b254689cc6c0e9133ab76f7e |
| 2026-04-07 14:06:56 |
CA2014a85aaefe9eb4c70a79e0556c9486 |
| 2026-04-03 22:45:31 |
CAe73a7e55664b10ce48d7ce0073b8b970 |
| 2026-04-12 14:41:17 |
CA9e3a4538da0bb9eab1c11238eea9e684 |
| 2026-04-10 19:35:25 |
CA165f547f0558a9490a131b48bab7fd5d |
| 2026-04-07 18:26:37 |
CA217c730bf75d2c6f7530e9a3c1c691d6 |
| 2026-04-15 15:22:42 |
CA98bc7671e2e682321fd4a9fc5409a749 |
| 2026-04-08 18:07:14 |
CA4f2dda59891bcef8d66f8638244a778e |
| 2026-04-03 22:29:34 |
CA84d0eeca9dd69455fb1655802e2453b4 |
| 2026-03-28 20:51:57 |
CAa9e74b4e82751954e526b59ad502c700 |
| 2026-04-04 16:37:08 |
CAff4a9b36f72111a19b4b84ec0d933c76 |
Hello, Thanks for the additional examples. We reviewed the case and were able to confirm that the affected calls are reaching OpenAI’s Realtime/SIP path for the project in the timestamps you provided.
The remaining issue is correlation: the Twilio Call SIDs are not directly present in the OpenAI-side logs we can search, so we need one OpenAI-side identifier from the incoming SIP webhook to trace a specific call end-to-end.
Please reach out to our support (via help.openai.com) and share the following for one or two affected examples:
- The data.call_id from the realtime.call.incoming webhook
- The SIP Call-ID from data.sip_headers
- The Twilio final SIP response/status fields, especially SipResponseCode and DialCallStatus
- Whether your application calls POST /v1/realtime/calls/{call_id}/hangup when Twilio reports no-answer