# Realtime API SIP inbound calls failing again before webhook dispatch **URL:** \ **Category:** Bugs\ **Tags:** realtime, sip\ **Created:** [May 13, 2026, 1:10am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763 "2026-05-13T01:10:20Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![s-nishihara1](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/s-nishihara1/32/739767_2.png) [@s-nishihara1](https://community.openai.com/u/s-nishihara1)\ **Post date:** [May 13, 2026, 1:10am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/1 "2026-05-13T01:10:20Z")
@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: > [@Invalid SDP error on new call to SIP endpoint](https://community.openai.com/t/invalid-sdp-error-on-new-call-to-sip-endpoint/1377602): > > The previously reported SIP SDP error is happening again. We are dead in the water trying to place new SIP calls into gpt-realtime. SIP/2.0 400 Bad Request Contact: sips:[my email]:5061 { “error”: { “message”: “Invalid SDP offer.”, “type”: “invalid\_request\_error”, “code”: “invalid\_offer”, “param”: “” } } 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. ---
**Author:** ![dvercorp](https://avatars.discourse-cdn.com/v4/letter/d/958977/32.png) [@dvercorp](https://community.openai.com/u/dvercorp)\ **Post date:** [May 13, 2026, 1:23am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/2 "2026-05-13T01:23:13Z")
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. ---
**Author:** ![davidtsprouse](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/davidtsprouse/32/732612_2.png) [@davidtsprouse](https://community.openai.com/u/davidtsprouse)\ **Post date:** [May 13, 2026, 2:03am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/3 "2026-05-13T02:03:15Z")
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 } ---
**Author:** ![Idan\_Elad](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/idan_elad/32/732928_2.png) [@Idan\_Elad](https://community.openai.com/u/Idan_Elad)\ **Post date:** [May 13, 2026, 2:13am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/4 "2026-05-13T02:13:16Z")
Seeing the exact same thing. FYI we’ve setup Azure Openai project as a fallback after last time. Realtime seems to be extremely unreliable ---
**Author:** ![Toshi](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/toshi/32/449473_2.png) [@Toshi](https://community.openai.com/u/Toshi)\ **Post date:** [May 13, 2026, 3:08am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/5 "2026-05-13T03:08:18Z")
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. ---
**Author:** ![ServicePack](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/servicepack/32/739770_2.png) [@ServicePack](https://community.openai.com/u/ServicePack)\ **Post date:** [May 13, 2026, 3:46am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/6 "2026-05-13T03:46:58Z")
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. ---
**Author:** ![s-nishihara1](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/s-nishihara1/32/739767_2.png) [@s-nishihara1](https://community.openai.com/u/s-nishihara1)\ **Post date:** [May 13, 2026, 4:06am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/7 "2026-05-13T04:06:36Z")
@OpenAI_Support @curt.kennedy Please check it, seems all around the world SIP isn’t working at all. ---
**Author:** ![TeamLearners](https://avatars.discourse-cdn.com/v4/letter/t/ecd19e/32.png) [@TeamLearners](https://community.openai.com/u/TeamLearners)\ **Post date:** [May 13, 2026, 4:30am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/8 "2026-05-13T04:30:59Z")
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 } ---
**Author:** ![leandro-ligmee](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@leandro-ligmee](https://community.openai.com/u/leandro-ligmee)\ **Post date:** [May 13, 2026, 5:54am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/9 "2026-05-13T05:54:24Z")
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 } ---
**Author:** ![leandro-ligmee](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@leandro-ligmee](https://community.openai.com/u/leandro-ligmee)\ **Post date:** [May 13, 2026, 5:56am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/10 "2026-05-13T05:56:48Z")
![image](https://us1.discourse-cdn.com/openai1/original/4X/2/7/2/2725ddfa7aed2ebf52c069364be7b83bfad88c86.png) API realtime status show as up, but it is not true. ---
**Author:** ![ServicePack](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/servicepack/32/739770_2.png) [@ServicePack](https://community.openai.com/u/ServicePack)\ **Post date:** [May 13, 2026, 6:35am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/11 "2026-05-13T06:35:55Z")
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. ![](https://us1.discourse-cdn.com/openai1/original/4X/2/a/a/2aa309669ee3a7e61ddd9950a62a52c7d69c47d9.png) 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 ---
**Author:** ![tobbeling](https://avatars.discourse-cdn.com/v4/letter/t/bbce88/32.png) [@tobbeling](https://community.openai.com/u/tobbeling)\ **Post date:** [May 13, 2026, 6:39am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/12 "2026-05-13T06:39:22Z")
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. ---
**Author:** ![ServicePack](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/servicepack/32/739770_2.png) [@ServicePack](https://community.openai.com/u/ServicePack)\ **Post date:** [May 13, 2026, 6:43am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/13 "2026-05-13T06:43:31Z")
how long did it take them to resolve it back then? ---
**Author:** ![s-nishihara1](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/s-nishihara1/32/739767_2.png) [@s-nishihara1](https://community.openai.com/u/s-nishihara1)\ **Post date:** [May 13, 2026, 6:53am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/14 "2026-05-13T06:53:13Z")
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. ---
**Author:** ![Nixtheworld](https://avatars.discourse-cdn.com/v4/letter/n/c0e974/32.png) [@Nixtheworld](https://community.openai.com/u/Nixtheworld)\ **Post date:** [May 13, 2026, 7:01am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/15 "2026-05-13T07:01:35Z")
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:@sip.api.openai.com;transport=tls` 3. **Minimal TwiML test** Stripped everything down to the bare minimum: 4. **Control test from the same Twilio account, same minute** 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. ---
**Author:** ![sps](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/sps/32/7736_2.png) [@sps](https://community.openai.com/u/sps)\ **Post date:** [May 13, 2026, 7:04am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/16 "2026-05-13T07:04:48Z")
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: > **[Realtime API - SIP/WebRTC flow are down - OpenAI Status](https://status.openai.com/incidents/01KRG0AZKH41DV4D9SNJSXM33Q#01KRG0AZKHH37CKBST5E3WBQW6)** > > Investigating | We are investigating the issue for the listed services. You can also copy and paste the text below into the slack channel of your choice to receive live status updates: ```plaintext /feed subscribe https://status.openai.com/incidents/01KRG0AZKH41DV4D9SNJSXM33Q/slack.rss ``` ---
**Author:** ![OpenAI\_Support](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/openai_support/32/561845_2.png) [@OpenAI\_Support](https://community.openai.com/u/OpenAI_Support)\ **Post date:** [May 13, 2026, 9:50am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/17 "2026-05-13T09:50:18Z")
Hey everyone, Apologies for the inconvenience. Our engineering team has deployed a fix and this issue should now be resolved. Thank you! ---
**Author:** ![lnobrega](https://avatars.discourse-cdn.com/v4/letter/l/ea5d25/32.png) [@lnobrega](https://community.openai.com/u/lnobrega)\ **Post date:** [May 13, 2026, 10:08am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/18 "2026-05-13T10:08:57Z")
Is it possible to get a RCA of the issue ? Are there fallback strategies that can be followed to mitigate the impact ? ---
**Author:** ![leandro-ligmee](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@leandro-ligmee](https://community.openai.com/u/leandro-ligmee)\ **Post date:** [May 13, 2026, 3:53pm UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/20 "2026-05-13T15:53:36Z")
Hi everyone! The original SIP inbound issue seems to be partially resolved on my side now: the `realtime.call.incoming` webhook is being dispatched again, and the `/v1/realtime/calls/{call_id}/accept` endpoint is returning `200 OK`. However, I’m still seeing a problem in the next step, when trying to connect the server-side WebSocket using the `call_id` from the webhook: wss://api.openai.com/v1/realtime?call\_id={call\_id} The WebSocket handshake consistently returns: { “error”: { “message”: “No session found for the provided call\_id”, “type”: “invalid\_request\_error”, “code”: “call\_id\_not\_found”, “param”: “” } } The first WebSocket attempt is happening very quickly after accept, usually within less than 1 second, so it does not look like a delay on our side. So it looks like the SIP inbound webhook/accept flow is working again, but the accepted call session is still not available through the WebSocket `call_id` connection. Is anyone else still seeing this after the reported fix? * * * * * * * * * After further investigation, we believe the WebSocket error may be a consequence of an earlier failure in the SIP call establishment flow, not the root cause. According to the Realtime SIP documentation, the `/accept` endpoint returns `200 OK` once the SIP leg is ringing and the realtime session is being established. The WebSocket connection using `call_id` is then used to monitor/control the same existing session. In our case, the flow is now: 1. SIP INVITE reaches OpenAI. 2. OpenAI dispatches the `realtime.call.incoming` webhook to our server. 3. We call `/v1/realtime/calls/{call_id}/accept`. 4. The accept request returns HTTP 200. 5. Immediately after that, connecting to `wss://api.openai.com/v1/realtime?call_id={call_id}` returns: ```auto { "error": { "message": "No session found for the provided call_id", "type": "invalid_request_error", "code": "call_id_not_found", "param": "" } } ``` This suggests that although `/accept` returns 200, the SIP/realtime session may not actually be established or propagated internally. As a result, the WebSocket layer cannot find the session for the accepted `call_id`. ---
**Author:** ![leandro-ligmee](https://avatars.discourse-cdn.com/v4/letter/l/ee7513/32.png) [@leandro-ligmee](https://community.openai.com/u/leandro-ligmee)\ **Post date:** [May 14, 2026, 1:44am UTC](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763/21 "2026-05-14T01:44:09Z")
We found the root cause on our side: the payload we were sending to `/v1/realtime/calls/{call_id}/accept` was malformed or invalid. However, the main issue is that the `/accept` endpoint was still returning HTTP 200 even though the payload was not valid enough to successfully establish the SIP/Realtime session. This made troubleshooting very difficult because the flow looked successful from the HTTP side: 1. SIP INVITE reached OpenAI. 2. OpenAI dispatched the `realtime.call.incoming` webhook. 3. Our server called `/v1/realtime/calls/{call_id}/accept`. 4. `/accept` returned HTTP 200. 5. After that, SIP failed with `400 Bad Request` / `error code: 504`. 6. The WebSocket connection returned `404 call_id_not_found`. The actual problem was the accept payload, but because `/accept` returned 200, the failure appeared to be a SIP/WebSocket/session propagation issue. OpenAi should to improve the validation and error handling for the `/accept` endpoint If the accept payload is invalid or malformed, the endpoint should return a clear 4xx response with details about the invalid field, instead of returning 200 and later failing the SIP session indirectly. This would make the Realtime SIP integration much easier to debug and would prevent misleading downstream errors such as SIP `400 / error code: 504` and WebSocket `call_id_not_found`. PS: Basically this problem was generated by the main INCIDENT after our team try to solve first problem that was not us. [Next page](https://community.openai.com/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763.md?page=2)