SIP REFER silently failing — fresh call_id with confirmed "current" payload format

Thanks for the diagnosis. You were right — the Missing required parameter: 'session.type' error came from our session.update calls over the WebSocket sideband. The SDK’s connection.session.update(session={...}) helper doesn’t automatically include "type": "realtime" inside the session object. We’ve patched that in all 3 call sites and verified sessions now run end-to-end without that error.

Fresh test call demonstrating the corrected flow but persistent /refer issue:

call_id : rtc_u0_Dh72Y82UgVr8Islheq03l timestamp : 2026-05-19 05:12:20 UTC

What happened:

1. /accept returned 200 cleanly (using SDK’s client.realtime.calls.accept())

2. Sideband WebSocket connected (connect_duration_ms=680)

3. session.update with {"type": "realtime", "temperature": 0.8} accepted with no error

4. Session ran 50 seconds — agent greeted, transcribed caller turns, responded with audio

5. Caller asked at 05:12:48: “OK, got it. Can you please transfer me to a human?”

6. Agent spoke the transfer line at 05:12:50

7. We called client.realtime.calls.refer(call_id="rtc_u0_Dh72Y82UgVr8Islheq03l", target_uri="tel:+61420351258") via the official Python SDK 2.36.0

8. /refer returned HTTP 200 with empty body at 05:12:54.348 (616ms duration)

9. Caller sat in silence for 16 seconds — no SIP REFER ever arrived on the Twilio leg

10. Twilio reports DialCallStatus: completed, sip_response_code: 200 at 05:13:10; caller hung up

Verification we’re on the current payload format:

• /accept: via SDK’s client.realtime.calls.accept(call_id, type="realtime", model=..., ...). Top-level type: "realtime" per SDK source.

• session.update over WS: explicitly includes {"type": "realtime", ...} inside the session object.

• /refer: via SDK’s client.realtime.calls.refer(call_id, target_uri="tel:+...") — no custom headers, body is {"target_uri": "tel:+61420351258"} per CallReferParams.

The session is unambiguously healthy this time — 50 seconds of normal back-and-forth audio confirms it. /refer returns 200 in <700ms but the underlying SIP REFER message never reaches Twilio’s trunk. We can confirm via Twilio’s call event log: no REFER event present, only the original INVITE and an eventual BYE when the caller hangs up.

Could you check server-side handling for this specific call_id? Specifically:

• Is the SIP REFER actually being generated and sent toward Twilio’s trunk?

• Are there backend errors after our /refer POST that aren’t reflected in the HTTP response?

Happy to provide additional call IDs if that helps.

Thanks, SP @OpenAI_Support