SIP REFER and Call Transfers: Blind vs Attended, and Why They Fail

What REFER does

Transferring a call sounds trivial until you have to debug one. The mechanism behind it is the SIP REFER method, defined in RFC 3515, and its job is precisely what the name suggests: it asks the recipient to refer to a resource named in the request — in telephony terms, "please go and call this other party."

The target is carried in a mandatory Refer-To header. That header holds a URI, normally the SIP address of the transfer destination.

Two details of the specification explain most of the confusing behaviour people see in traces. First, a REFER implicitly establishes a subscription to the refer event — the party that receives it must report back on how the referred action went. Second, that reporting happens through NOTIFY requests whose body is a message/sipfrag fragment containing a SIP status line, such as SIP/2.0 200 OK.

So a successful transfer produces a small conversation: REFER goes out, the recipient answers 202 Accepted (which RFC 3515 requires before the REFER transaction expires, if no other final response was generated), and then one or more NOTIFYs arrive describing progress. The subscription ends when the final result is reported, with Subscription-State: terminated;reason=noresource.

The 202 is worth internalising: it does not mean the transfer succeeded. It means the request was accepted for processing. The outcome arrives later in a NOTIFY. Plenty of "the transfer said OK but the call dropped" reports come from reading the 202 as success.

Blind vs attended transfer

A blind (or unattended) transfer is the simple case. The transferring party sends REFER pointing at the destination and immediately drops out. The destination rings; whoever answers gets the caller. Nobody speaks to the destination first, so if it is busy, broken or unattended, the caller finds out the hard way.

An attended (or consultative) transfer puts the transferrer on the destination first. The original caller is held while a second call is placed; the transferrer explains who is calling; then the two are joined and the transferrer leaves. In SIP terms this is more involved, because the REFER must identify an existing dialog rather than just a destination — carried by a Replaces parameter in the Refer-To header, telling the destination to replace the consultation call with the caller's call.

Attended transfers give a much better experience and fail in more interesting ways, because more state has to survive.

Where transfers break

• REFER is not permitted. A 405 Method Not Allowed means the far end recognises REFER but refuses it. Many carriers deliberately disallow REFER on trunks so they are not asked to hairpin calls. The workaround is to keep the transfer inside your own PBX rather than pushing it upstream.
• Attended transfer loses the held call. Usually a Replaces problem — the dialog identifiers do not match anything the destination still holds, often because a session timer or a re-INVITE already changed the dialog underneath.
• Transfer completes but audio is one-way. The signalling succeeded and the media path did not. After a transfer the RTP endpoints change, so this is a NAT problem surfacing at exactly the moment the media path is renegotiated. Check the SDP in the re-INVITE and confirm symmetric RTP is on.
• The caller hears silence, then hang-up. Look for the NOTIFY. If it carries a 4xx or 5xx sipfrag, the destination rejected the call and the transferrer had already left, leaving nobody to recover.
• Timeouts on slow destinations. If the referred party rings for a long time, some devices give up on the subscription before the final NOTIFY arrives.

Transfers in Asterisk

Asterisk can either handle a transfer itself or pass the REFER through to the far end. Which one you want depends on whether you need to keep control of the call.

For PJSIP endpoints, allowing transfers is controlled per endpoint:

[1001]
type=endpoint
allow_transfer=yes

Setting this to no makes Asterisk reject REFER from that endpoint — useful when you want transfers to happen only through dialplan features rather than by phone button.

The dialplan alternative is the built-in transfer features, enabled with the t and T options to Dial(), which let a party trigger a transfer with a DTMF feature code handled entirely inside Asterisk. Because the PBX stays in the media path, these avoid the whole class of problems where a carrier refuses REFER.

Debugging a transfer

Watch the actual messages rather than reasoning about what should happen:

asterisk -rvvv
pjsip set logger on

Follow the sequence: is a REFER sent at all? Is it answered 202 or rejected? Does a NOTIFY come back, and what status line is in its sipfrag body? That last one is the single most informative piece of a failed transfer, and it is the part most people never look at.

For a clearer picture of the whole dialog, sngrep renders the exchange as a ladder diagram, which makes it obvious where the flow stops.

Frequently asked questions

What is the difference between blind and attended transfer?

A blind transfer sends the caller to the destination immediately with no announcement. An attended transfer calls the destination first, lets the transferrer speak to them, then connects the two — using a Replaces parameter to swap the consultation call for the original one.

Why does my transfer return 202 but the call still fails?

202 Accepted only confirms the REFER was accepted for processing. The real outcome arrives in a subsequent NOTIFY containing a SIP status line. Read that NOTIFY.

Why do carriers block REFER?

Honouring a REFER can require the carrier to re-originate a call, with cost and fraud implications. Many disable it and expect the PBX to bridge the legs itself.

Why is there no audio after a transfer?

The media path is renegotiated at transfer time, so a latent NAT misconfiguration shows up exactly then. Verify the SDP addresses after the re-INVITE and enable symmetric RTP.