How Call Transfer Works in SIP: REFER, Replaces, and NOTIFY

Pressing the transfer button is one button press. What happens underneath is the most involved sequence in everyday SIP, involving a method that does nothing else, an event subscription nobody asked for, and a header whose entire job is to say "forget the call you already have, use this one instead."

It is also, consistently, the feature that breaks first in a mixed-vendor environment. Transfers work perfectly between two identical desk phones and fall apart the moment a different handset, a different PBX, or a session border controller enters the path. Knowing the message flow is what turns "transfers are broken" into a specific, fixable fault.

This post goes deep on transfer specifically. For how hold, forwarding, and conferencing work alongside it, see Call Features in SIP.

The three roles

RFC 5589 gives the participants names, and using them saves a lot of confusion, because "the caller" becomes ambiguous the moment a transfer starts:

• Transferor — the person who presses transfer. Alice.
• Transferee — the person being transferred, who is already on a call with Alice. Bob.
• Transfer target — where Bob is being sent. Charlie.

The counterintuitive part, and the thing worth internalising before anything else: Alice presses the button, but Bob's phone does the work. Alice does not connect Bob to Charlie. Alice sends Bob an instruction, and Bob's phone places its own call to Charlie. Every transfer failure mode follows from this. If Bob's phone cannot reach Charlie, or does not understand the instruction, the transfer fails no matter how healthy Alice's connection is.

The REFER method

REFER (RFC 3515) is the mechanism. It means: place a call to this address on my behalf, and tell me how it goes.

REFER sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK9921
From: <sip:[email protected]>;tag=abc123
To: <sip:[email protected]>;tag=def456
Call-ID: [email protected]
CSeq: 4 REFER
Refer-To: <sip:[email protected]>
Referred-By: <sip:[email protected]>
Contact: <sip:[email protected]:5060>
Content-Length: 0

Two headers carry the meaning. Refer-To is the destination — the only genuinely required piece. Referred-By (RFC 3892) records who ordered the transfer, which matters for both display purposes and policy: some systems reject a REFER that does not identify its originator.

Note that this REFER travels inside the existing dialog between Alice and Bob. Same Call-ID, same tags, incremented CSeq. It is not a new call, it is a new request within the conversation they are already having. This is why a transfer cannot be initiated by a third party who is not already in the dialog.

Bob's phone answers:

SIP/2.0 202 Accepted

202 Accepted — not 200 OK — and the distinction is deliberate and worth understanding. 202 means "I have received your request and I will act on it," not "it worked." At this moment nothing has been transferred. Bob's phone has merely agreed to try. Treating a 202 as success is the single most common misreading of a transfer trace.

The NOTIFY subscription nobody asked for

Alice needs to know whether the transfer succeeded. REFER handles this by creating an implicit event subscription: by sending the REFER, Alice is automatically subscribed to an refer event package describing its progress. She did not send a SUBSCRIBE. It happened as a side effect.

Bob's phone then reports back with NOTIFY messages whose bodies are fragments of SIP responses — content type message/sipfrag (RFC 3420):

NOTIFY sip:[email protected]:5060 SIP/2.0
CSeq: 5 NOTIFY
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 20

SIP/2.0 100 Trying

Then, as Charlie's phone starts ringing:

Subscription-State: active;expires=60
Content-Type: message/sipfrag;version=2.0

SIP/2.0 180 Ringing

And finally:

Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag;version=2.0

SIP/2.0 200 OK

That last one is the transfer actually succeeding. The Subscription-State: terminated closes the implicit subscription — there is nothing further to report. Only now can Alice safely tear down her call legs.

This progress stream is the most useful thing in a transfer trace and the most commonly missing. A REFER answered with 202 and then silence tells you Bob's phone accepted the instruction and then either never placed the INVITE or could not reach Charlie. That is a completely different fault from a REFER rejected outright, and the NOTIFY chain is what distinguishes them.

Some implementations suppress the subscription entirely using Refer-Sub: false (RFC 4488), typically when a B2BUA is going to handle the outcome itself. Its absence is not automatically a bug — but if you see neither Refer-Sub: false nor any NOTIFY, something has gone wrong.

Blind transfer

Blind (or unattended) transfer is the simple case. Alice does not speak to Charlie first. She sends the REFER shown above, with a bare Refer-To, and typically drops her leg to Bob as soon as she gets the 202.

The flow:

1. Alice and Bob are talking
2. Alice sends REFER with Refer-To: <sip:[email protected]>
3. Bob's phone returns 202 Accepted
4. Bob's phone sends a fresh INVITE to Charlie, including Referred-By: <sip:[email protected]>
5. Bob's phone NOTIFYs Alice with progress
6. Charlie answers, Bob and Charlie are talking
7. Alice's leg is torn down with a BYE

The unresolved question in blind transfer is what happens when Charlie does not answer, and the specification does not settle it. Some phones return Bob to Alice if she is still on the line. Some drop Bob entirely, which from the customer's perspective is a hang-up. Some send Bob to Charlie's voicemail, which may or may not be what anyone wanted. If Alice has already hung up — which most phones do immediately — there is nothing to return to regardless.

This is why blind transfers behave inconsistently across a mixed fleet. It is not that one vendor is wrong; the standard genuinely leaves it open. If callers are being dropped on unanswered transfers, the fix is usually configuration on the transferee's device or the PBX, not the network.

Attended transfer and the Replaces header

Attended (consultative) transfer is where Alice checks with Charlie first, and it needs one more piece of machinery.

1. Alice and Bob are talking (call A)
2. Alice puts Bob on hold — a re-INVITE with a=sendonly in the SDP
3. Alice calls Charlie. This is call B: a completely separate dialog, its own INVITE, its own Call-ID
4. Alice tells Charlie what the call is about. Charlie agrees to take it
5. Alice sends a REFER to Bob — and this is where it differs

REFER sip:[email protected]:5060 SIP/2.0
CSeq: 4 REFER
Refer-To: <sip:[email protected]?Replaces=a84b4c76e66710%40host
  %3Bto-tag%3Dxyz789%3Bfrom-tag%3Dabc123>
Referred-By: <sip:[email protected]>

The Refer-To now carries an embedded Replaces parameter. Decoded, that escaped string is Replaces: a84b4c76e66710@host;to-tag=xyz789;from-tag=abc123 — the Call-ID and both dialog tags of call B, the consultation call between Alice and Charlie.

Replaces (RFC 3891) means: when this INVITE arrives, do not treat it as a new incoming call. Find the dialog it identifies, and substitute this one for it.

So Bob's phone INVITEs Charlie with a Replaces header. Charlie's phone matches it against the live call with Alice, accepts, and swaps the media over. Charlie's phone never rings a second time. The audio simply changes from Alice's voice to Bob's. That seamlessness is the entire point of the Replaces mechanism, and it is why an attended transfer feels different from a blind one at the receiving end.

The escaping matters, incidentally. Those %3B sequences are semicolons and %40 is an at-sign, escaped because they are being carried inside a URI inside a header. Implementations that escape this incorrectly produce transfers that fail in ways that look inexplicable until you decode the header by hand.

Where the transfer actually happens

Everything above describes endpoints talking to each other. Real deployments usually have something in the middle, and this changes what you will see on the wire.

Most hosted platforms put a B2BUA or an SBC between the phones. When Alice sends a REFER, it frequently does not reach Bob at all. The SBC terminates it, and then re-originates the transfer itself — building its own INVITE to Charlie and bridging the legs internally. From Bob's phone's perspective, no transfer occurred; the audio just changed.

This has three practical consequences:

Where you capture determines what you see. A capture at the handset may show a clean REFER and 202 while the failure is happening on the far side of the SBC, or show no REFER at all on a transfer that plainly worked. Capture on both sides of the middlebox before concluding anything.

The platform's REFER support is what counts, not the phone's. A handset that implements RFC 3515 flawlessly will still fail if the platform in front of it does not relay or re-originate correctly.

Some trunks forbid REFER outright. Many carriers will not accept a REFER from the customer side, because it asks them to originate a call leg they cannot bill cleanly. The platform must instead keep the call anchored and bridge it internally — which works, but means the media stays in the provider's path for the life of the call rather than flowing directly.

Why transfers fail

| What you see | What it means | |---|---| | 405 Method Not Allowed or 501 Not Implemented to the REFER | The device does not implement REFER. Common on ATAs, older handsets, and stripped-down clients. The PBX must handle the transfer instead | | 202 Accepted, then no NOTIFY at all | The instruction was accepted but the INVITE to the target never happened or never got a response. Check whether the transferee can route to the target | | 481 Call/Transaction Does Not Exist on the Replaces INVITE | The dialog named in Replaces is gone or never matched. Usually the consultation call was torn down too early, or a B2BUA rewrote the tags so they no longer correspond | | 603 Decline or 403 Forbidden from the trunk | The carrier is refusing to originate the referred leg. Anchor the call on your platform instead of passing REFER upstream | | Transfer works internally, fails to external numbers | Almost always the trunk. Internal transfers stay inside your PBX; external ones ask the carrier to accept a REFER or a re-INVITE it may not permit | | The target rings twice on an attended transfer | Replaces was dropped or not understood, so the INVITE was handled as a brand-new call rather than a substitution | | Transfer completes but audio is one-way | Not a signalling failure. The transfer succeeded and the media path is wrong — see below |

The SIP response code reference covers what each of these codes means outside the transfer context.

One-way audio after a transfer

This one deserves separating out, because the instinct is to blame the transfer and the transfer is not at fault.

A transfer necessarily renegotiates media. New endpoints, new SDP, new RTP path. If that renegotiation produces a path that works in one direction only, you get a completed transfer where one party cannot hear the other — and the SIP trace looks perfect, because the signalling did exactly what it should.

The usual causes are the usual causes of one-way audio generally: NAT translating an address that the new SDP advertises incorrectly, a firewall that has pinholes for the original media path but not the new one, or SIP ALG rewriting SDP it does not fully understand. The transfer is not causing the fault, it is exposing one that was already there — the original call path happened to work, and the new one does not.

The diagnostic that settles it quickly: compare the c= line and media port in the post-transfer SDP against where RTP is actually arriving. If they disagree, the problem is address translation, not transfer.

Reading a transfer in a capture

When you have a capture and need to determine what happened, work through it in this order:

1. Find the REFER. No REFER at all means either a middlebox absorbed it or the phone used a different mechanism entirely. Both are worth knowing immediately.
2. Check the response. 202 means accepted. Anything in the 4xx or 5xx range means rejected, and the code tells you why.
3. Decode Refer-To. Is there a Replaces parameter? That tells you attended versus blind, regardless of which button the user believes they pressed.
4. Follow the NOTIFY chain. The sipfrag bodies are the transfer's own account of itself: 100, then 180, then 200 is a clean transfer. A chain that stops early localises the failure precisely.
5. Find the new INVITE. It carries Referred-By, and on attended transfers a Replaces header. Its response is the real outcome — everything before it is preamble.
6. If audio is wrong, ignore all of the above and compare the negotiated SDP with the actual RTP flow.

Capturing VoIP traffic in Wireshark covers getting a usable capture in the first place, and our PCAP analyzer will lay out the dialogs and media streams from a capture file without your having to trace tags by hand.

What to check first

When transfers are failing in a given environment, the sequence that resolves it fastest:

Does it fail for everyone, or for specific devices? Device-specific failures are almost always REFER support or its configuration. Universal failures are the platform or the trunk.

Internal or external? External-only failures point at the carrier and how your platform passes transfers upstream.

Blind or attended? Attended-only failures point at Replaces handling — usually a B2BUA rewriting dialog identifiers.

Signalling or audio? If the parties are connected but cannot hear each other, stop investigating transfer entirely. That is a media path problem that a transfer merely revealed, and it will bite you on other call flows too.

Transfer sits on top of everything else SIP does — dialogs, tags, SDP negotiation, media paths. That is exactly why it breaks first when something underneath is not quite right. Most of the time, a broken transfer is a symptom rather than the disease.

This post expands on the transfer section of Call Features in SIP: Hold, Transfer, and Forwarding, part of SIP Signaling From the Wire Up. For how a call gets established in the first place, start with The First Call Flow: INVITE to BYE.