Realtime SIP POST /calls/{call_id}/refer and /calls/{call_id}/hangup returns 200 but REFER and BYE never reaches Twilio Elastic SIP Trunk

API Bugs
1

We are reproducing the issue Api-realtime SIP Refer not reaching far end (api-realtime-sip-refer-not-reaching-far-end/1396729) on Twilio Elastic SIP Trunk origination into sip.api.openai.com (transport=tls).

  • POST /v1/realtime/calls/{call_id}/refer with target_uri=tel:+E.164 returns HTTP 200 and an empty body. The Realtime session emits no REFER-outcome error.
  • POST /v1/realtime/calls/{call_id}/hangup returns HTTP 200 and no BYE reaches downstream.
  • Twilio’s call log for the origination leg shows no REFER and no SIP BYE received. The caller stays with the bot after we announce the transfer. realtime.calls.hangup is the same: accepted, never honored.
  • Ingress: Twilio Elastic SIP Trunk → sip:{PROJECT_ID}@sip.api.openai.com;transport=tls. The INVITE carries Twilio’s usual Record-Route (bare sip: URI, no transport, no port) plus X-Twilio-CallSid.
  • This matches the community repro: REFER is attempted on a new TLS connection to the Record-Route target (UDP:5060) instead of the existing dialog; handshake fails; 200 was already returned.
  • We have confirmed tel: vs sip:+E.164@<trunk>.pstn.twilio.com is not the defect.

Please treat this as the same delivery bug. We can share call_ids, cf-rays, and timestamps under NDA. A 202 plus a later session error on delivery failure would have saved a week.

Example call (already shared with Twilio, who cannot help because they never saw the REFER and BYE):

OpenAI call_id=rtc_u2_EMaSeE0ReQBnzc321oVl3,
Twilio origination CA13d24568f1c26418088f0cbffe6e640d, 2026-09-10 14:54:43Z,

OpenAI call_id=rtc_u2_EMz8daczPpUuKvIvdrV40,
Twilio origination call_sid=CAc2cefb3f43c5c0a0251c23bf6926636f

Trunk TK1b0089e0c3e9ab7c06c3aa997d787010.