{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigk4eknu3aeraf7k4f7mgprh6fm4tq5nycgppd5q5fznonism2llu",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mlpsdxklqcs2"
  },
  "path": "/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763#post_15",
  "publishedAt": "2026-05-13T07:01:35.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "@sip.api.openai.com"
  ],
  "textContent": "Same outage here. Can confirm, and adding a few additional data points.\n\nStarted for us at the same time you reported (~2026-05-13 00:30 UTC). There was a very sharp cutoff:\n\n  * **Last successful SIP call:** `CA35bdfa00a93c6d9d882e1badfebb8cbf` at **2026-05-13 00:24:52 UTC** , duration **88s** , status=`completed`\n\n  * **First failure:** by **02:16:46 UTC** , every subsequent SIP dial returned `status=failed`, `duration=0`\n\n\n\n\nWhat we ruled out before finding this thread (in case OpenAI staff are investigating and want to skip the usual diagnostics):\n\n  1. **Two separate OpenAI accounts**\nSeparate orgs, separate API keys, freshly created webhooks subscribed to `realtime.call.incoming`. Both fail identically.\n\n  2. **Three separate Twilio subaccounts**\nOne master account + two subaccounts, using three different US phone numbers. All fail identically when dialing:\n`sip:<project_id>@sip.api.openai.com;transport=tls`\n\n  3. **Minimal TwiML test**\nStripped everything down to the bare minimum:\n\n         <Response>\n           <Dial>\n             <Sip>sip:proj_xxx@sip.api.openai.com;transport=tls</Sip>\n           </Dial>\n         </Response>\n\n\n\nNo `callerId`, custom headers, recording, `action`, or announcements. Same failure mode.\n\n  4. **Control test from the same Twilio account, same minute**\n\n         <Dial>\n           <Sip>sip:echo@conference.sip2sip.info;transport=tls</Sip>\n         </Dial>\n\n\n\nConnects successfully and bridges audio normally. This strongly suggests Twilio outbound SIP-over-TLS is healthy in general.\n\n  5. **Webhook behavior**\n`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`.\n\n\n\n\nAdditional datapoint:\n\n  * `sip.api.openai.com` resolves to `*.pacloudflare.com` (`172.65.182.150`), which appears to be Cloudflare Spectrum proxying traffic to the SIP backend.\n\n  * TLS handshake from a residential IP completes cleanly using the `api.openai.com` certificate with `*.api.openai.com` SANs.\n\n\n\n\nThis suggests the front door is up, but the SIP service behind it is the failing layer.\n\nThis 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.\n\nWhat would help on our end:\n\n  * 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.\n\n  * Ideally, a public RCA once resolved so teams can plan mitigation strategies around future incidents.\n\n\n\n\nHappy to share additional CallSIDs, timestamps, or webhook delivery IDs if that helps OpenAI staff or other affected users with debugging.",
  "title": "Realtime API SIP inbound calls failing again before webhook dispatch"
}