No Answer in 15 Seconds, Back to Queue: Designing SIP REFER Warm Transfer for Callbot Loops

Cold Transfer and Warm Transfer Are Not the Same Feature

A cold transfer routes the caller straight to the agent line and drops off, so the agent picks up with zero context. A warm transfer has the callbot first ring the agent on a separate leg, hand over a conversation summary, then swap that leg into the caller's active call. The caller never hears the briefing exchange between bot and agent, and that gap is what drives the perceived quality difference.

One REFER Request Isn't Enough

The actual mechanics run across two SIP standards. RFC 3515 (2003) defines the REFER method, the callbot's way of telling the agent's dialog "go act on this resource." When the URI inside the Refer-To header carries a Replaces parameter defined by RFC 3891 (2004), the receiving side compares to-tag and from-tag values and swaps the existing dialog for a fresh INVITE. The sequence runs REFER → 202 Accepted → NOTIFY (sipfrag) → an INVITE carrying Replaces, and if any carrier or SBC in that chain doesn't support one of those steps, the transfer breaks mid-flight.

From Trunk Validation to Fallback: A Warm Transfer Operations Guide

Pin down a success-rate number before rolling warm transfer out. Define warm-transfer success rate as the share of transfers where an agent actually answers and takes over the session, and set 95% or higher as the target line. Give the agent leg a 15-second answer timeout before routing the caller back to the queue, so dead-air exposure stays capped at 15 seconds. Context (conversation summary) delivery rate is a separate metric from transfer success — it tracks whether caller intent and prior-turn summary make the jump 100% of the time even when the session changes hands.

Failures observed in production cluster into four types: the call drops outright, context never reaches the agent so the caller has to re-explain from scratch, the agent leg never answers, or the caller still can't reach a human despite asking. At the protocol layer, the most common root cause is a REFER request rejected with 501 Not Implemented, which shows up whenever the SBC or carrier trunk in the call path doesn't support REFER.

When REFER gets rejected, don't fall straight back to a cold transfer — keep a fallback path ready instead. Spin up a second outbound INVITE to bring the agent leg in separately and bridge it with the caller leg through a mixer; that preserves warm transfer's core value (the agent gets briefed first) even on trunks whose REFER support you didn't know about ahead of time. If the agent leg doesn't answer within 15 seconds, send the caller back to the front of the queue, and if the same caller hits two consecutive warm-transfer failures, degrade safely to a cold transfer.

Before deployment, build a support matrix of REFER support per SBC and carrier trunk you actually use. Vendor documentation and real trunk behavior diverge often enough that it's worth logging REFER→202→NOTIFY response codes in staging and comparing per-trunk success rates on an operations dashboard. Keep the handoff payload that reaches the agent's screen from exposing the caller's identifier in plaintext SIP headers — route it through a separate channel (the agent console API) instead, so PII doesn't sit in the call-path logs.

Carrier REFER support isn't fixed. Bandwidth's June 2026 release added REFER support for inbound SIP URI calls and noted that calls transferred via REFER don't count against concurrency limits. Scan vendor changelogs like that one weekly, update the trunk support matrix accordingly, and promote your top two failure types into next sprint's regression test scenarios.

The Caller Should Never Notice the Dialog Swap

Warm transfer isn't complete on one REFER request — it only finishes once the Replaces match succeeds too. Hold a 95% success-rate target and a 15-second no-answer timeout as your baseline, and keep a second-INVITE fallback ready for when REFER gets rejected, so agent handoff survives a trunk swap without breaking.

References

RFC 3515: The Session Initiation Protocol (SIP) Refer Method — IETF

RFC 3891: The Session Initiation Protocol (SIP) "Replaces" Header — IETF