Expose cold_transfer_mode (SIP REFER) on the custom LLM WebSocket frame — prod impact

Feature Requests
1

This is affecting production today and we have no workaround left, so flagging it with urgency.

The ask: allow cold_transfer_mode to be set (and honoured) on the custom LLM WebSocket response frame, alongside transfer_number. Support confirmed it does not exist on that path today, in this thread: Audio quality problems after our agent does a cold transfer

Production impact. Our agent answers a UK clinic’s main line and cold-transfers callers to their reception team. Because the WebSocket path is hardwired to SIP INVITE, Retell stays in the media path as a B2BUA for the whole post-transfer conversation, hairpinning and transcoding Caller to Twilio to LiveKit to Twilio to destination. Reception staff and callers get lag and half-duplex, walkie-talkie audio. This happens on every transfer, every day, and the people affected are patients calling a healthcare provider. Retell support diagnosed the same root cause independently.

The capability already works, we verified it. On the same Twilio trunk and the same number, a Conversation Flow agent with cold_transfer_mode set to sip_refer transferred cleanly: Retell dropped out after 463ms and the destination stayed connected with Retell gone. Our trunk is on transfer_mode enable-all with transfer_caller_id from-transferee. So the REFER path, our carrier and our trunk config are all proven good. The only missing piece is being able to select the mode from the WebSocket.

Why we cannot work around it. We cannot move the response engine, because our own LLM drives the conversation over the WebSocket. We tested chaining to a second Retell agent that performs the REFER, and it does not help: a REFER only releases the leg directly beneath the referring agent, so the first agent stays in the media path and the audio is unchanged. Softening denoising reduces the clipping but leaves the transcoding hairpin, so it is mitigation, not a fix. The remaining option is to move call control off Retell and drive transfers from Twilio ourselves, which we would rather not do.

Why this looks small from the outside. Mode selection and the REFER implementation already exist and already work on Conversation Flow and Retell LLM. This is surfacing an existing capability on one more path rather than building new capability. Even an account-level opt-in, or accepting the field as a pass-through without documenting it, would unblock us.

Happy to provide call IDs, trunk configuration or test agents if that helps.

5 Likes
Audio quality problems after our agent does a cold transfer
2

We are seeing this issue too

1 Like
3

Adding a result we didn’t have when I filed this, because it closes off the obvious workaround.

We tested whether the caller-ID problem can be mitigated inside sip_invite mode using show_transferee_as_caller. It does work on the LLM WebSocket frame: Retell correctly puts the transferee’s number into the termination INVITE, which I can confirm still happens after the 01/23 deprecation. But Twilio rejects that INVITE with error 32204 “Invalid Caller ID” whenever the transferee is not a number on our own account. We ran it as a controlled A/B over our own trunk, identical calls with the same agent and the same destination, changing only the caller. From a number verified on our account the transfer completes. From one that is not, it fails six times over with 32204.

Inbound callers are members of the public, so they are never on our account. That means there is no configuration of sip_invite in which this works for us: the media stays hairpinned and the clinic sees our number rather than the caller’s. sip_refer fixes both at once, and our Twilio trunk is already configured for it (transfer_mode enable-all, transfer_caller_id from-transferee). The only missing piece is being able to select it from the custom LLM path.