Get started

How call transfers actually work: SIP REFER, bridging, warm and cold

A call transfer works in one of two broad ways: a system can ask another SIP endpoint to place a new call to the transfer target, usually with SIP REFER, or it can place a second outbound call itself and bridge that call leg to the original caller. A cold transfer connects without a private consultation; a warm transfer holds the caller while the transferring party speaks to the recipient first. These user experiences are related to, but independent from, the signaling mechanism used underneath.

Start with dialogs, call legs, and media

A connected SIP call is not one indivisible object. If a caller reaches an application through a carrier, the application often acts as a back-to-back user agent: it terminates one SIP dialog and may originate another. Each dialog has its own transaction state, identifiers, routing information, Session Description Protocol offer and answer, and lifecycle.

The audio is another layer. RTP packets may flow through the application or a media relay even though SIP messages follow a different path. The application can record, mix, mute, or replace audio while leaving both signaling dialogs connected. Alternatively, it can negotiate direct media between endpoints, if routing, security, and network address translation allow it.

A call leg is a useful operational name for one side of that topology. Before a transfer, there may be one caller leg connected to an automated agent. A bridged transfer adds a target leg. A REFER transfer may cause an existing endpoint or carrier to create the new leg instead.

This separation explains why "transfer the call" is underspecified. The system must decide who originates the new INVITE, who remains responsible for the original dialog, where media flows, what the caller hears during setup, and what happens if the target does not answer.

SIP REFER requests a new SIP action

SIP REFER, defined by RFC 3515, lets one SIP participant ask another to contact a URI in the Refer-To header. In transfer terminology:

  • The transferor sends the REFER.
  • The transferee receives it and attempts the referenced SIP request.
  • The transfer target is the endpoint named by Refer-To.

The common blind-transfer sequence looks like this:

  1. The transferor and transferee already have an established dialog.
  2. The transferor sends an in-dialog REFER with a target SIP URI.
  3. The transferee accepts the request, commonly with 202 Accepted.
  4. The transferee sends a new INVITE toward the target.
  5. The transferee reports progress to the transferor in NOTIFY requests, often using message/sipfrag bodies that contain status such as 100 Trying or 200 OK.
  6. The original dialog is ended when the selected transfer policy says it is safe to do so.

The 202 does not mean the target answered. It means the transferee accepted responsibility for attempting the referred request. Final success or failure arrives through the implicit REFER subscription and its NOTIFY messages, unless the participants negotiated behavior that suppresses that subscription.

REFER is control-plane signaling; it does not itself move RTP packets. The transferee's new INVITE establishes the new dialog and negotiates its media. Depending on the network, the transferee may be a phone, PBX, session border controller, carrier, or application server.

Blind REFER and attended REFER are not the same

A blind, or cold, REFER points the transferee at a target the transferor has not consulted. The caller may hear local ringback or early media while the new INVITE progresses. If the original party disconnects before success and no recovery mechanism exists, failure can strand or end the caller's session.

An attended transfer begins with a separate consultation dialog. The transferor calls the target, confirms that the target will accept, and then asks SIP to replace or join the relevant dialog. The Replaces header defined by RFC 3891 identifies an existing dialog using its Call-ID and tags. In a REFER-based attended transfer, that information can be encoded into the Refer-To URI so the new INVITE replaces the consultation leg rather than appearing as an unrelated call. RFC 5589 documents transfer flows and edge cases in more detail.

Interoperability is the practical constraint. An endpoint might accept a basic REFER but mishandle Replaces; a trunk might reject REFER entirely; policy may forbid referring a call to an arbitrary domain; or a boundary controller may rewrite contact and routing data. A platform that crosses the public telephone network cannot assume that end-to-end SIP features survive every hop.

Bridging keeps the transfer under application control

When a platform performs a bridged transfer, it does not ask the caller's endpoint to dial the target. It originates a target leg itself:

  1. Keep the caller leg connected.
  2. Send an outbound INVITE toward the target.
  3. Process provisional responses such as 180 Ringing or 183 Session Progress and any early media.
  4. When the target answers with a successful final response, acknowledge it.
  5. Connect the caller's media to the target's media.
  6. End or detach the automated-agent portion of the session according to policy.

The two SIP dialogs remain distinct. A media bridge relays or mixes RTP between them, translating codecs or packetization when necessary. Signaling events on one leg are mapped into actions on the other: a hangup on the recipient leg should end or recover the caller leg, and DTMF may need to be relayed in the negotiated form.

Anchoring the call costs more infrastructure than handing control away with REFER, but it gives the application explicit control over ringback, hold audio, recording boundaries, fallback behavior, and post-transfer events. It also works when a carrier supports ordinary outbound calling but not call-transfer extensions.

The alternative is to re-negotiate direct media after both legs are connected. That can reduce media-path work and delay, but makes topology, NAT traversal, recording, supervision, and later recovery harder. Many systems keep media anchored when those controls matter.

Cold transfer describes the experience, not the packet flow

A cold transfer sends the caller toward a target without a private conversation first. It can be implemented with blind REFER or with a platform-created target leg. The caller may hear ringing, an announcement, or silence while the attempt runs.

The essential policy questions are:

  • Does the transferring agent disconnect as soon as dialing starts, or only after answer?
  • If the line is busy, rejected, or times out, does the caller return to the agent?
  • Is a voicemail answer considered success?
  • How long can the setup phase last?
  • What identity is presented on the target leg?

Those choices determine whether a "cold transfer" is a tolerable handoff or an abrupt abandonment. A blind REFER can still report failure before the original dialog ends. A bridged cold transfer can keep the caller connected until answer. The label alone does not specify the recovery behavior.

Warm transfer adds a private consultation phase

A warm transfer preserves the caller while the transferring party contacts the recipient privately. A common bridged sequence is:

  1. Tell the caller that a transfer is starting.
  2. Put the caller's media on hold or connect it to hold audio.
  3. Create a target call leg.
  4. When the target answers, keep the caller isolated and provide context privately.
  5. Ask or infer whether the target accepts the call.
  6. On acceptance, bridge caller and recipient and remove the private agent leg.
  7. On decline, no answer, or another failure, tear down the target leg and resume the caller session.

Holding the caller can involve an SDP direction change such as sendonly or inactive, but a back-to-back application does not always need to signal hold to the caller's endpoint. It can keep the SIP dialog unchanged while its media controller stops forwarding conversation audio and supplies hold media locally.

The private briefing also needs a precise media graph. During consultation, the target must hear the briefing but the caller must not. At acceptance, the graph changes so caller and recipient hear each other. A race during that transition can leak private audio, clip the recipient's greeting, or briefly connect all participants. Media operations should therefore be atomic from the controller's perspective, even if several lower-level updates are required.

On ThunderPhone, cold and attended warm transfer are supported. In warm mode, the caller waits on hold while the agent privately briefs the recipient, connects the call after acceptance, and returns to the caller with the outcome if the recipient declines, does not answer, or reaches voicemail. Warm transfer requires an eligible production number that can place an outbound SIP leg; demo numbers and browser-based calls are limited to cold transfer.

Failure handling is part of the transfer

The target leg can return 486 Busy Here, 480 Temporarily Unavailable, 408 Request Timeout, 503 Service Unavailable, or another failure. It can ring until an application timer expires, answer with voicemail, or answer and disconnect immediately. REFER notifications can convey SIP status, while a bridged implementation sees the target transaction directly.

Voicemail is particularly subtle because it is usually a successful answer at the signaling layer. A warm-transfer workflow can listen for a human acceptance before connecting the caller. A cold transfer that treats any 200 OK as success may connect the caller to voicemail. Whether that is correct depends on the use case.

Every branch should end in a defined state: transferred, returned to agent, sent to alternate destination, left on voicemail, or disconnected with an explanation. A call-routing policy should also prevent loops—for example, when the target forwards back to the original number.

Identity, recording, and billing follow the legs

The target leg is a new outbound call, so it has its own asserted identity, carrier route, billing, and answer state. The recipient might see the caller's number, the transferring business's number, or another authorized identity depending on network policy and configuration. Passing unverified identity is not a safe assumption.

Recording and consent boundaries may also change. A platform that remains in the media path can technically continue recording, but the workflow still needs appropriate notices, access controls, and retention handling. An attended consultation may need to be excluded from the caller's recording or stored as a separately governed segment.

Detailed call records should preserve leg identifiers and causal links. Otherwise, a target-leg failure looks like an unexplained hangup on the original call. Useful events include transfer request, target dialing, provisional progress, answer, acceptance, bridge completion, REFER status, fallback, and termination reason.

Choosing between REFER and bridging

REFER is attractive when the receiving network supports it consistently and the application wants to relinquish media and signaling responsibility. Bridging is attractive when the application needs uniform behavior across trunks, precise warm-transfer control, recording or supervision, and reliable fallback. Some architectures support both and choose by route capability.

Test across the real providers, PBXs, and destinations in the call path. A successful same-network lab REFER does not prove behavior across a production SIP trunk. Verify answer, busy, decline, timeout, voicemail, early media, caller hangup during consultation, recipient hangup just after acceptance, and simultaneous disconnects.

FAQ

Does SIP REFER move the existing audio stream?

No. REFER asks its recipient to initiate a SIP request to another URI. The resulting INVITE and session negotiation establish the new dialog and media path.

Is every warm transfer an attended REFER?

No. Warm describes the consultation experience. It can be implemented with attended REFER and Replaces, or by keeping both legs anchored in an application-controlled media bridge.

Can a cold transfer return to the agent if nobody answers?

Yes, if the original leg remains available and the implementation waits for target success or handles a reported REFER failure. A policy that ends the original call immediately may not be able to recover.

Why does a transfer go to voicemail even though the line "answered"?

Voicemail normally produces a successful signaling answer. Avoiding it requires media-level voicemail detection, an explicit human acceptance step, or a policy that returns the caller when no person accepts.