Call transfer issues can be difficult to diagnose because users rarely report a rejected SIP REFER. Instead, they simply say the call dropped when they tried to transfer it to a colleague. Behind the scenes, the transfer involves several systems that must coordinate the handoff. When something goes wrong, understanding how these systems interact makes it easier to identify where the transfer failed and why.
How a SIP transfer works
A SIP call transfer involves three parties: the transferor, who initiates the transfer; the transferee, whose call is being moved; and the target, who receives the call.
Most transfers use the SIP REFER method, defined in RFC 3515 (The Session Initiation Protocol REFER Method). This RFC defines how one SIP device can ask another to make a new request, such as starting a call to a different destination. The destination is included in the Refer-To header, while the Referred-By header identifies who requested the transfer.
The receiving system then sends a new INVITE, the SIP method used to initiate a call, to the target. It reports the call’s progress through NOTIFY messages, which communicate updates such as whether the new call is ringing or has connected.
The process depends on the type of transfer. A blind transfer sends the call to the target immediately, without first checking their availability. An attended transfer allows the transferor to call the target first and confirm they are available before completing the handoff. It uses the Replaces header, defined in RFC 3891 (The SIP Replaces Header), to identify the existing call that the new call should take over.
For a broader look at how these mechanisms work together, RFC 5589 (Session Initiation Protocol Call Control – Transfer) describes recommended practices and call flows for implementing SIP transfers, including blind and attended transfers.
Where interoperability breaks down
SIP transfer failures usually fall into a few common categories. The first is support mismatch: not every phone system or carrier supports REFER. Microsoft Teams Direct Routing documentation provides an example of how platforms handle this, listing a fallback order of REFER, INVITE with Replaces, and then an internal transfer method that the session border controller (SBC), which manages SIP traffic between networks, cannot see. These fallback methods can behave differently, sometimes leaving callers unable to hear the phone ringing while waiting for an answer.
Header handling is another common issue. A REFER request may not contain all the information needed to route the new call, so Microsoft expects the SBC to preserve the Refer-To and Referred-By headers when creating the new INVITE. That INVITE must go back to the platform’s SIP proxy rather than directly to the telephone network. Rewriting the headers or routing the INVITE elsewhere can break the transfer.
Missing progress messages can also cause failures. The receiving system should respond to REFER with “202 Accepted” and send NOTIFY messages to report progress. If these messages never reach the initiating system, it may time out. If a BYE message, which ends an established call, arrives too early, the original call can drop before the transfer completes.
Firewall rules add another potential obstacle. REFER requests may arrive over new TLS connections from any of the platform’s signaling addresses. Firewalls that allow only specific addresses can block these requests, even when other SIP traffic works normally.
Finally, carrier behavior and platform updates can introduce unexpected problems. A 481 Call/Transaction Does Not Exist response means the receiving system can no longer find the referenced call or transaction. During an attended transfer, this can happen when the transferor’s temporary call to the intended recipient (known as a consultation call) stays on hold long enough for a carrier device to expire it.
Platform changes matter too. In June 2026, Microsoft changed its blind-transfer behavior so its side ends the original call as soon as the SBC accepts the transfer, without waiting for the final result. Configurations that worked under the previous behavior may therefore need to be reviewed.
Practical troubleshooting checks
Start by identifying the transfer type (blind or attended), its direction, and which system receives the REFER request. Capture SIP traces of both a failed and successful transfer using SBC logs or a packet capture, then compare the messages to find where they differ.
Check whether REFER is listed in the Allow header on each leg of the call. If a system does not support REFER, removing it from the advertised methods may force some platforms to use INVITE with Replaces as a temporary workaround.
Next, verify that the new INVITE preserves the Refer-To and Referred-By values and that 202 Accepted and NOTIFY messages reach the system that initiated the transfer. Check message timing too, particularly whether a BYE arrives before the final NOTIFY. If callers hear silence instead of ringing, check REFER support and the handling of 180 Ringing and 183 Session Progress responses, which provide call-progress updates.
Also review firewall rules to ensure all required signaling addresses are allowed, and confirm that destination numbers use the format expected by the next system.
Finally, test internal and external transfers separately, including both blind and attended transfers across desk phones, softphones, and mobile devices. Comparing the results helps identify which system or network connection is causing the failure.
Call transfer failures between your phone system, carrier, or cloud platform can be difficult to diagnose. Our team can capture and analyze SIP traffic, identify where the handoff breaks, and help get your calls transferring reliably. Contact us to start troubleshooting.
