Realtime API SIP inbound calls failing again before webhook dispatch

@OpenAI_Support @sps I’m hitting what looks like a silent failure on the Realtime API’s REFER endpoint. The HTTP request succeeds, but no SIP REFER message ever leaves OpenAI’s SIP backend — the call stays on the original audio path and the transfer never happens.

Setup

• Model: gpt-realtime-1.5

• Inbound SIP carrier: Twilio Elastic SIP Trunk → sip.api.openai.com;transport=tls

• Inbound flow itself works: webhook fires, /accept returns 200, sideband WebSocket connects in ~600 ms, conversation/transcription/tool calls run normally.

Reproduction

After a healthy in-progress SIP call, issue:

POST /v1/realtime/calls/{call_id}/refer

{"target_uri": "tel:+61420351258"}

Response

HTTP/1.1 200 OK

content-length: 0

(empty body)

No x-request-id, no openai-processing-ms — just content-length: 0, which is unusual versus other Realtime endpoints.

For 30 s after the REFER the realtime WebSocket emits zero lifecycle events about the REFER’s fate (no call.transferred, call.ended, refer.completed, etc.) — only normal audio buffer events from the still-live audio path. On the Twilio side, the SIP dialog continues with no REFER ever arriving on the wire.

Tried

• Bypassed the SDK with raw httpx (cast_to=NoneType in the SDK was hiding the response body) — same result.

• target_uri: "tel:+E164" → silent failure.

• target_uri: "sip:+E164@sip.twilio.com" → silent failure.

• Twilio Elastic SIP Trunk has Call Transfer enabled and processes inbound REFERs correctly from other sources.

Sample call IDs (in case anyone from OpenAI can peek at the backend):

• rtc_u7_DfK6YZPcgSGPcQc7P3l28 (tel:, 2026-05-14T06:56:21Z)

• rtc_u0_DfKR6woNn4gWn4VhY6e4C (sip:, 2026-05-14T07:06:40Z)

Expected

Either a non-2xx response with details when the payload is invalid, or — on success — the SIP REFER actually reaches the peer with a proper Refer-To, plus a lifecycle event on the realtime sideband.

Workaround for anyone hitting the same thing: correlate the OpenAI call_id with the carrier-side CallSid at /twiml/inbound time and use the carrier’s REST API to redirect the call leg instead of relying on /refer. Works reliably but ugly.

Anyone else seeing this? Any OpenAI folks able to look at those call IDs?