Realtime API SIP inbound calls failing again before webhook dispatch

API Bugs
,
1

@OpenAI_Support @curt.kennedy

Hi OpenAI team,

We are seeing what appears to be a recurrence of a previous Realtime API SIP issue.

Related previous thread:

Our current setup is:

Twilio SIP → OpenAI Realtime API SIP endpoint → OpenAI webhook → Google Cloud Run / sideband WebSocket

Current symptoms:

  • New inbound SIP calls fail immediately.
  • Twilio reports a SIP failure / 400 response.
  • The OpenAI webhook is not triggered.
  • We do not receive the usual realtime.call.incoming event.
  • Our /accept flow is never reached.
  • No sideband WebSocket connection attempt appears in our logs.
  • We have not made any relevant changes to our code, Twilio configuration, SIP settings, or OpenAI configuration.

This looks very similar to the issue discussed in the thread above, where calls appeared to be rejected before webhook dispatch, possibly around SDP validation.

The issue started again around [2026-05-13 9:30 JST] / [2026-05-13 00:30 UTC] on our side.

Could someone from OpenAI please check whether there has been another regression or incident affecting Realtime API SIP ingress?

This is impacting our production voice service, so any confirmation or status update would be greatly appreciated.

Thank you.

2

We are experiencing the same technical issue as well.

We are located in South Korea, and this issue is occurring even though we are directly trunking our PBX with OpenAI, without going through a third-party provider such as Twilio.

3

I’m seeing this:

{
“error”: {
“message”: “You do not have access to the organization tied to the API key.”,
“type”: “invalid_request_error”,
“code”: “invalid_organization”,
“param”: null
},
“status”: 401
}

4

Seeing the exact same thing.
FYI we’ve setup Azure Openai project as a fallback after last time.
Realtime seems to be extremely unreliable

5

We are seeing the same issue on our production voice service as well.

Our setup is also Twilio SIP → OpenAI Realtime API SIP endpoint.

Current symptoms:

  • New SIP calls to the OpenAI Realtime SIP endpoint fail immediately.
  • Twilio reports SIP 400 failures.
  • The OpenAI webhook is not triggered.
  • We do not receive the realtime.call.incoming event.
  • Our accept flow is never reached.
  • We have not made any relevant changes to our application code, Twilio settings, or OpenAI configuration.

On our side, the issue appears to have started around 2026-05-13 09:30 JST / 2026-05-13 00:30 UTC as well.

This looks like the same regression affecting Realtime API SIP ingress before webhook dispatch.
Any confirmation from the OpenAI team would be appreciated.

6

Same issue here, Twilio to OpenAI fails with 400 failures. It’s critical.
All incoming SIP calls to sip.api.openai are failing with a 400 Bad Request response. This affects multiple OpenAI projects on our account.
This started approximately 2026-05-13 00:00 UTC. Prior to that, calls were completing successfully.

7

@OpenAI_Support @curt.kennedy

Please check it, seems all around the world SIP isn’t working at all.

8

I have a same issue

CSeq: 1 INVITE

Content-Length: 210

Content-Type: application/json

Contact: sips:OAI@sip.api.openai.com:5061

{

“error”: {

"message": "You do not have access to the organization tied to the API key.",

"type": "invalid_request_error",

"code": "invalid_organization",

"param": null

},

“status”: 401

}

9

Same issue here, trying to solve for 3 hours, after a migration. Looks a general issue.

{
“error”: {
“message”: “You do not have access to the organization tied to the API key.”,
“type”: “invalid_request_error”,
“code”: “invalid_organization”,
“param”: null
},
“status”: 401
}

10

image
image1837×1151 125 KB

API realtime status show as up, but it is not true.

11

From Twilio:

Thank you for your response and for providing detailed information and sharing the additional context. That help clarify this issue.

I understand now that this isn’t isolated to the xxxx trunk. Since all of your OpenAI-related trunks started failing at roughly the same time with the same 400 Bad Request behavior, and nothing changed on your side, that points away from a simple trunk configuration issue.

The fact that your fallback setup using Twilio Media Streams + OpenAI Realtime WebSocket API is working. Since that flow uses the same Twilio account, phone numbers, and OpenAI projects, it does suggest the issue is specifically tied to traffic going through sip.api.openai.com.

From the call samples we reviewed, we can confirm that Twilio is attempting to send the outbound SIP INVITEs to the OpenAI SIP endpoint and that the calls are failing immediately with a 400 Bad Request response from the far end. At this point, we’re not seeing evidence that Twilio is blocking, rate-limiting, or intentionally rejecting the traffic.

Please find the SIP ladder below showing that Twilio is successfully sending the SIP INVITE to the OpenAI SIP endpoint and receiving a 400 Bad Request response back from the OpenAI server during call setup.

1204×576 156 KB

We also appreciate you sharing the OpenAI community thread and the OpenAI support case reference. Seeing similar reports from multiple developers, providers, and regions around the same timeframe is useful context and does make this look more consistent with an upstream SIP ingress issue.

For now, based on the traces reviewed so far:

  • The SIP INVITEs are leaving Twilio successfully

  • The 400 Bad Request appears to be coming back from sip.api.openai.com

  • We do not currently see signs of Twilio-side filtering or throttling affecting these calls

Please feel free to reach out if you have any additional questions or need further clarification on this issue. I’ll move this case to ‘Pending’ while I await your response. If I don’t hear back from you, the case will close. You’ll also receive reminders along the way.

Kind regards,
Twilio Support

12

This has happened before. And also then status showed green until OpenAi manually set it to somewhat degraded, when nothing worked.
Feels a bit like this is not a supported way of using the service.

13

how long did it take them to resolve it back then?

14

During the previous similar incident at the end of March, it took about a full day for the service to fully recover. At that time as well, I raised concerns that the SIP service status was not being properly reflected on the OpenAI status page, but it seems this still has not been improved. I hope the OpenAI engineering team is reviewing the discussions in this thread and investigating the issue.

15

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.

  4. 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.

  5. 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.

sps 16

Hi everyone, thank you for reporting this issue and for sharing the detailed context. The team is actively investigating. We’ll continue to provide updates in this thread as more information becomes available.

You can also follow the incident status here:

You can also copy and paste the text below into the slack channel of your choice to receive live status updates:

/feed subscribe https://status.openai.com/incidents/01KRG0AZKH41DV4D9SNJSXM33Q/slack.rss
2 Likes