Realtime API SIP inbound calls failing again before webhook dispatch

Same outage here. Can confirm, and adding a few additional data points.

Started for us at the same time you reported (~2026-05-13 00:30 UTC). There was a very sharp cutoff:

• Last successful SIP call: CA35bdfa00a93c6d9d882e1badfebb8cbf at 2026-05-13 00:24:52 UTC , duration 88s , status=completed

• First failure: by 02:16:46 UTC , every subsequent SIP dial returned status=failed, duration=0

What we ruled out before finding this thread (in case OpenAI staff are investigating and want to skip the usual diagnostics):

1. Two separate OpenAI accounts Separate orgs, separate API keys, freshly created webhooks subscribed to realtime.call.incoming. Both fail identically.

2. Three separate Twilio subaccounts One master account + two subaccounts, using three different US phone numbers. All fail identically when dialing: sip:<project_id>@sip.api.openai.com;transport=tls

3. Minimal TwiML test Stripped everything down to the bare minimum:

   <Response>
     <Dial>
       <Sip>sip:proj_xxx@sip.api.openai.com;transport=tls</Sip>
     </Dial>
   </Response>
   

No callerId, custom headers, recording, action, or announcements. Same failure mode.

1. Control test from the same Twilio account, same minute

   <Dial>
     <Sip>sip:echo@conference.sip2sip.info;transport=tls</Sip>
   </Dial>
   

Connects successfully and bridges audio normally. This strongly suggests Twilio outbound SIP-over-TLS is healthy in general.

1. Webhook behavior realtime.call.incoming is never dispatched for failed calls. The only events our endpoint receives are OpenAI’s synthetic “Send test event” deliveries, which succeed and return 200.

Additional datapoint:

• sip.api.openai.com resolves to *.pacloudflare.com (172.65.182.150), which appears to be Cloudflare Spectrum proxying traffic to the SIP backend.

• TLS handshake from a residential IP completes cleanly using the api.openai.com certificate with *.api.openai.com SANs.

This suggests the front door is up, but the SIP service behind it is the failing layer.

This also looks very similar to the SDP-related failure discussed in thread 1377602 from March 24. Between the original post title there (“happening again”) and this thread (“failing again before webhook dispatch”), it feels more like a recurring backend regression than an isolated incident.

What would help on our end:

• A dedicated status page component for the Realtime SIP endpoint, so users do not have to build Twilio → OpenAI control tests just to detect outages.

• Ideally, a public RCA once resolved so teams can plan mitigation strategies around future incidents.

Happy to share additional CallSIDs, timestamps, or webhook delivery IDs if that helps OpenAI staff or other affected users with debugging.