Realtime API over SIP: inbound calls never trigger realtime.call.incoming webhook (Twilio Elastic SIP Trunk)

API Bugs
1

Realtime API over SIP: inbound calls never trigger realtime.call.incoming webhook (Twilio Elastic SIP Trunk)

Project ID: proj_o9om3ZbZuTeUd1lVuVKZ6Oa4

Summary

Inbound PSTN calls forwarded via a Twilio Elastic SIP Trunk (Origination URI sip:proj_o9om3ZbZuTeUd1lVuVKZ6Oa4@sip.api.openai.com;transport=tls) consistently fail to trigger the realtime.call.incoming webhook. Twilio’s call log shows the SIP leg to OpenAI as Failed or No Answer with 0 second duration, every time, for every real call attempt (10+ attempts across two different Spanish phone lines/carriers).

What I’ve verified/ruled out

  • Twilio SIP Trunk configuration is correct: the Origination URI is properly set (sip:proj_o9om3ZbZuTeUd1lVuVKZ6Oa4@sip.api.openai.com;transport=tls), and Twilio’s own call log confirms it successfully attempts the outbound SIP leg toward OpenAI’s endpoint every time (Direction: “Trunking Originating”).
  • Webhook endpoint itself works correctly: using the “Send test event” button in the Webhooks settings page (event type realtime.call.incoming), the test event is delivered successfully (HTTP 200) to our server, with a valid signature that our server verifies correctly.
  • Rotated the webhook signing secret and updated our server — no change.
  • Deleted and recreated the webhook from scratch (same URL, same event type) — no change.
  • Confirmed via our own request logs (server + ngrok tunnel inspector) that literally zero HTTP requests ever arrive at our webhook URL for any of the real call attempts — only the manual “Send test event” requests arrive. This means the failure happens before OpenAI would even dispatch the webhook, i.e., on the SIP call-acceptance side, not on the webhook-delivery side.
  • Billing/credits are not the issue: active credit balance ($9.92), well under the $100/month budget cap, current usage this month only $4.16.
  • Verified the project ID in the SIP URI is correct and matches the project where the webhook is registered.

Environment

  • Telecom: Twilio Elastic SIP Trunk (“Tecnicom Voicebot”), Spanish Twilio number (+34960323090)
  • Origination URI: sip:proj_o9om3ZbZuTeUd1lVuVKZ6Oa4@sip.api.openai.com;transport=tls
  • Webhook URL: served via ngrok tunnel (https://steadfast-roving-gradient.ngrok-free.dev/openai-webhook)
  • Webhook event type: realtime.call.incoming
  • Node.js server using the official openai SDK (v7)

Sample Call SIDs (Twilio, all “Failed” or “No Answer”, 0 sec duration)

  • CAd4d17a041a41d9459648981e970b65ac (06:26:23 PDT 2026-09-21)
  • CA66eb3c0ed45cff5a50c3adb466fb94b3 (06:26:07 PDT 2026-09-21)
  • CA569813bee34a48daabd3b822dff0923f (06:25:51 PDT 2026-09-21)
  • CA653077379632124733e08cc53036ff2e (06:25:35 PDT 2026-09-21)
  • CAb956eea7b783e7d90f3faae51a332356 (06:14:17 PDT 2026-09-21)
  • CAadd83a84061ebecef5354b8783011291 (05:23:33 PDT 2026-09-21)
  • CA5005309a321b4ea4debad144bf426d3f (05:23:17 PDT 2026-09-21)
  • CA35e0ef39f0886b5e2944318016b8cceb (05:23:01 PDT 2026-09-21)

Question

Is this a known/active issue on OpenAI’s side with the Realtime SIP connector accepting inbound INVITEs from Twilio? Is there anything project-side (beta access, tier, region) that could cause 100% of real inbound SIP calls to fail at the signaling level while the webhook delivery mechanism itself works fine?

Related threads I found describing similar (but reportedly intermittent, ~10-20%) failures:

2

Update: Opened a support ticket with Twilio and got a concrete answer. Twilio confirmed the SIP INVITE is being sent successfully over TLS to sip.api.openai.com:5061 (that’s why my downloaded PCAP was empty — Twilio’s PCAP only captures the customer-side boundary, and the destination severed the connection immediately during signaling hand-off, before any media/downstream packets existed on that boundary).

The key finding: OpenAI’s SIP gateway itself is actively rejecting the INVITE with:

for Call SID CA66eb3c0ed45cff5a50c3adb466fb94b3 (2026-09-21 13:26:07 UTC), sent from Twilio to sip:proj_o9om3ZbZuTeUd1lVuVKZ6Oa4@sip.api.openai.com;transport=tls.

So this isn’t a network/connectivity mystery anymore — it’s a deliberate rejection at the OpenAI SIP gateway layer, with a 400 Bad Request carrying an internal error code: 504 in the body (unusual to see a gateway-timeout-style code wrapped inside a 400 rather than returned as its own SIP status, which itself might be a clue).

Given the webhook delivery mechanism itself works fine (manual “Send test event” succeeds every time), the rejection is happening before OpenAI’s application layer ever gets to dispatch realtime.call.incoming — purely at SIP signaling. Could someone from the OpenAI team check what error code: 504 maps to internally for the Realtime SIP connector? Happy to share the full Twilio support thread if useful.

3

Adding another data point — same failure, different carrier (Telnyx instead of Twilio), so this is not provider-specific.

Project: “Tropico téléphone” — proj_7kkggNv6axCAu5bXzAFkVMHs
Webhook “Tropico-Telephone” configured for realtime.call.incoming. Correction: “Send test event” does NOT work in my case — manual attempts on 2026-09-28 returned “Failed to POST to webhook endpoint”. So the webhook delivery path fails even for test events here (unlike the OP’s setup); the SIP-side failure (400 + error code: 504 ~15 s after INVITE) is identical.

Every real inbound call fails identically:

  • Telnyx sends a well-formed INVITE over TLS to sip.api.openai.com:5061: INVITE sip:proj_7kkggNv6axCAu5bXzAFkVMHs@sip.api.openai.com:5061 SIP/2.0 (valid SDP, SRTP/RTP-SAVP offered, G.711 included — full trace verified by Telnyx support)
  • Your edge replies 100 Trying (~105 ms), then 180 Ringing (~136 ms)
  • ~15.1 s after the INVITE, your edge returns SIP/2.0 400 Bad Request with Content-Type: application/json and body error code: 504
  • No realtime.call.incoming webhook is ever dispatched; no media is ever established

Sample calls (2026-09-28):

  • Call-ID ed613823-f96b-4e3e-bb1c-814f86775641 — INVITE 19:12:26 UTC, 400 at 19:12:41 UTC
  • Call-ID 246ba840-8dd9-491d-9699-1d34778f0a9d — INVITE 19:12:41 UTC, 400 at 19:12:56 UTC
    Caller +1-450-521-1997 → +1-579-589-6997 (via Telnyx)

Telnyx support confirmed this is server-side: the 400 is not a malformed-INVITE rejection (the INVITE passed initial validation — hence 100/180), but an upstream timeout inside OpenAI’s SIP service, mapped to a 400 with an HTTP-style 504 in the body. No Reason or Warning header on the 400; the JSON body is the only diagnostic.

Same questions as the OP:

  1. What does the internal “error code: 504” map to on the SIP gateway?
  2. Is there a known incident affecting the Realtime SIP connector since ~Sept 21, 2026?

Happy to provide the full SIP ladder if useful.

4

Hey @toniblascotecnicom, we checked your September 21 calls: incoming events were created, but no webhook delivery was queued. Can you check that the webhook’s saved subscriptions include realtime.call.incoming? The manual test can succeed without that saved subscription.

@DanyBonneau, your September 28 delivery attempts failed during the TLS handshake. Can you check your webhook’s HTTPS listener/proxy logs at those call times?

5

Hi, thanks for looking into the webhook deliveries — on our end the TLS issue seems resolved now (certificate renewed Oct 4, endpoint healthy).

I’d like to bring back the main question though: our inbound calls via Telnyx get a SIP 400 Bad Request from the OpenAI SIP server about 15 seconds after a well-formed INVITE (we see 100 Trying / 180 Ringing first), with “error code: 504” in the response. The call never reaches the webhook stage because of this.

Could you clarify what “error code: 504” means in this context, and what typically causes the 400 on an inbound INVITE to sip.api.openai.com:5061? Happy to provide a sanitized SIP trace if that helps.

Thanks!

6

Hey @DanyBonneau! A SIP 400 can include an error from call setup, so it doesn’t necessarily mean the INVITE was malformed or that webhook processing never started. I also checked your saved webhook, and it’s subscribed to realtime.call.incoming.

We still haven’t confirmed what produced the 504 in your case. If this happened again after the October 4 certificate renewal, could you share the sanitized SIP trace you offered from one of those calls? Please keep the Call-ID, UTC timestamp and full 400 response, but remove phone numbers and auth headers