SIP transfer

What is a SIP transfer?

A SIP transfer is the act of moving an established voice call from one endpoint to another using Session Initiation Protocol signaling. The call leg the customer is on stays alive while the signaling layer negotiates a new destination, then re-points the media so audio flows to the new party.

SIP was first published by the IETF in 1999 and revised into its current base specification, RFC 3261, in 2002, and it has carried the majority of business voice traffic since carriers retired legacy circuit switching. Almost every transfer inside a modern contact center, whether a human or an AI voice agent initiates it, resolves to a SIP message on the wire.

How a SIP transfer works

A SIP transfer runs through three layers: signaling, media, and application state. Signaling is the SIP dialog itself. The transferring party sends a REFER request naming a target in a Refer-To header, the transferee sends an INVITE to that target, and NOTIFY messages report progress back so the original party knows whether the new leg answered, rang out, or was rejected.

Media is where audio actually travels, negotiated by SDP inside those INVITE bodies and carried over RTP. A transfer that succeeds at the signaling layer can still fail here if codecs mismatch or if one side sits behind a NAT that never opens the return path, which produces the classic one-way-audio complaint. This is the layer where echo cancellation tuning also has to be re-applied, since the acoustic path changes mid-call.

Application state is the layer SIP does not carry. The protocol moves the session; it does not move the caller's verified identity, the automatic speech recognition transcript, or the intent already collected by an AI IVR. Contact center platforms attach that context through SIP headers, a screen-pop API, or an automatic call distributor lookup keyed on the call identifier.

Types of SIP transfer

• Blind (unattended) transfer: The transferring party sends REFER and immediately drops off, with no confirmation the target answered, which is fastest and riskiest.

• Attended (consultative) transfer: The transferor places the caller on hold, dials the target, speaks, then completes the REFER, so the handoff is confirmed before release.

• Semi-attended transfer: The transferor waits for ringing but not for an answer, trading some certainty for shorter hold time on high-volume queues.

• Bridged or re-INVITE transfer: The platform keeps both legs anchored on its own media server and swaps the far end, which preserves recording and analytics continuity.

• Refer-to-replaces: A specialized form that substitutes one existing dialog for another, used heavily in park, retrieve, and call-pickup features.

SIP transfer vs warm transfer vs call forwarding

Teams conflate these three because they all end with the caller talking to somebody new, and the vocabulary mixes protocol mechanics with operational practice. SIP transfer is the signaling mechanism that moves an established session. Warm transfer is the operational practice of briefing the next party before releasing the caller, usually implemented as an attended SIP transfer but definable without reference to any protocol. Call forwarding is a routing rule applied before or during setup, so the call reaches an alternate destination without ever establishing the original leg. The distinction that matters day to day: one is the wire protocol, one is the customer experience choreographed on top of it, and one never involves a live handoff at all.

If your problem is that customers repeat themselves, you need a warm transfer discipline, and the SIP mechanism underneath it is an implementation detail. If your problem is dropped calls, silent legs, or handoffs that fail at 3 a.m. only, the problem is genuinely in the SIP layer.

Why SIP transfer matters for customer experience

When transfers work, they are invisible. When they fail, they fail loudly: the caller hears silence, gets disconnected after already waiting in queue, or lands with an agent who has none of the context collected in the first four minutes. Each of those outcomes forces a callback, and a callback costs more than the original contact because the customer arrives annoyed and the history has to be reassembled by hand.

The tradeoff is speed against certainty. Blind transfers clear the transferring agent immediately and keep handle time low, but they push the risk onto the caller, who discovers the failure. Attended transfers hold two agents on the call at once and consume more capacity, which is why teams under queue pressure quietly drift toward blind transfers and then wonder why abandonment climbed.

How is a SIP transfer measured?

The IETF specification defines the mechanism and the message flow, and it stops there: no operational quality figure, no compliance number, nothing a support team can be held to. Public voice-quality scales such as MOS do exist, but they score perceived audio quality rather than handoff outcomes, so a transfer success rate has to be built out of your own call records.

What you measure instead is derived from your own traffic. Pull the SIP signaling logs and count the ratio of REFER requests to NOTIFY messages reporting a 200-class final response, which gives transfer completion rate. Segment failures by SIP response code, since 486 busy, 408 timeout, 480 temporarily unavailable, and 5xx server failures each point at a different owner. The message semantics behind every one of those codes are defined in RFC 3261, which is the reference to reconcile your logs against before you trust any dashboard built on top of them.

How AI agents change SIP transfer

An AI voice agent changes who initiates the transfer and what can be carried across it. The agent holds a structured record of the conversation: verified identity, resolved intent, values collected, and actions already attempted. That record can be serialized into custom SIP headers or handed to the receiving desktop through an API call fired at the same moment the REFER goes out, so the human picks up with the screen already populated.

The consequence is that the transfer decision becomes a modeled one. Instead of a fixed menu path, the agent evaluates confidence, sentiment, and policy limits, then transfers when continuing would waste the caller's time. Getting that threshold right is the substance of call containment and transfer quality, and the same logic governs AI chat with human fallback on text channels.

What to look for in SIP transfer implementation

Start with coverage: does the platform support attended, blind, and replaces-based transfers, or only the simplest one. A stack that offers blind transfer alone will force operational workarounds within weeks.

Integration surface is next. Confirm that context can travel with the call, whether through SIP headers, a CTI event, or a call-identifier lookup, and test what the receiving agent actually sees rather than what the datasheet claims.

Governance covers who may transfer to which destination, whether external transfers off-net are permitted, and how recordings continue across the handoff. For regulated teams, SOC 2 Type II, ISO 27001, ISO 42001, HIPAA, and GDPR all constrain how call audio and transcripts are retained through a transfer. The operational constraint most teams hit is the session border controller: media anchoring choices there decide whether transfers survive NAT traversal and codec renegotiation at all.

SIP transfer and telephony infrastructure

A SIP transfer only makes sense inside the broader telephony stack that carries it, because the same REFER message behaves differently depending on whether the carrier trunk, the session border controller, or a cloud platform terminates the leg. Teams that debug transfers without a map of that path usually blame the wrong component.

Transfers also intersect with input handling. Legacy menus collect account numbers through DTMF tones, and those digits have to be re-collected or forwarded explicitly after a handoff, since keypad input belongs to the leg it was entered on and does not follow the session automatically.

What does a SIP transfer mean in plain terms?

Think of a SIP transfer as handing someone a phone that is still connected, rather than hanging up and asking them to call back. SIP stands for Session Initiation Protocol, the rulebook computers use to set up, change, and end a voice call over the internet. The transfer is one of the changes that rulebook allows mid-call.

Without it, every handoff would mean a disconnect and a redial, and the caller would lose their place in line. With it, the audio keeps flowing while the destination quietly changes underneath.

The tradeoff is that the rulebook moves the call, and moves nothing else. Everything the caller already told you has to be carried across separately, by deliberate design, or it is gone the moment the handoff completes.

Common SIP transfer mistakes

Treating blind transfer as the default is the most expensive pattern. It optimizes for the transferring agent's handle time and moves the entire failure risk onto the caller, who is the only party who finds out when the target never answered.

Assuming context follows the session is second. Engineers see the call arrive intact and conclude the data arrived with it, but the protocol carries dialog state and nothing about the customer, so context propagation has to be built and tested as its own path.

Skipping media-path testing is third. Transfers are usually validated inside one network, where NAT and codec negotiation are trivial, and then they fail on real carrier traffic with one-way audio that no signaling log will explain.

The fourth is not instrumenting SIP response codes. Teams track a single transfer failure percentage, which tells them something is broken without indicating whether the carrier, the target endpoint, or their own timeout configuration caused it.