{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibgblla4rogx3wuemgol3gsm2wce2egyiydlo6h3mfvqz7qbnwbiq",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mlsdhbp6jwu2"
  },
  "path": "/t/realtime-api-sip-inbound-calls-failing-again-before-webhook-dispatch/1380763?page=2#post_22",
  "publishedAt": "2026-05-14T07:49:29.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "@OpenAI_Support",
    "@sps"
  ],
  "textContent": "@OpenAI_Support @sps\nI’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.\n\n**Setup**\n\n  * Model: `gpt-realtime-1.5`\n\n  * Inbound SIP carrier: Twilio Elastic SIP Trunk → `sip.api.openai.com;transport=tls`\n\n  * Inbound flow itself works: webhook fires, `/accept` returns 200, sideband WebSocket connects in ~600 ms, conversation/transcription/tool calls run normally.\n\n\n\n\n**Reproduction**\n\nAfter a healthy in-progress SIP call, issue:\n\n\n    POST /v1/realtime/calls/{call_id}/refer\n\n\n`{\"target_uri\": \"tel:+61420351258\"}`\n\n**Response**\n\n\n    HTTP/1.1 200 OK\n\n\n`content-length: 0`\n\n`(empty body)`\n\nNo `x-request-id`, no `openai-processing-ms` — just `content-length: 0`, which is unusual versus other Realtime endpoints.\n\nFor 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.\n\n**Tried**\n\n  * Bypassed the SDK with raw `httpx` (`cast_to=NoneType` in the SDK was hiding the response body) — same result.\n\n  * `target_uri: \"tel:+E164\"` → silent failure.\n\n  * `target_uri: \"sip:+E164@sip.twilio.com\"` → silent failure.\n\n  * Twilio Elastic SIP Trunk has Call Transfer enabled and processes inbound REFERs correctly from other sources.\n\n\n\n\n**Sample call IDs** (in case anyone from OpenAI can peek at the backend):\n\n  * `rtc_u7_DfK6YZPcgSGPcQc7P3l28` (tel:, 2026-05-14T06:56:21Z)\n\n  * `rtc_u0_DfKR6woNn4gWn4VhY6e4C` (sip:, 2026-05-14T07:06:40Z)\n\n\n\n\n**Expected**\n\nEither 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.\n\nWorkaround 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.\n\nAnyone else seeing this? Any OpenAI folks able to look at those call IDs?",
  "title": "Realtime API SIP inbound calls failing again before webhook dispatch"
}