While the REFER request has been around since RFC 3515 (April 2003), the details on how to actually implement call transfer have been somewhat grey. In practice, this has lead to less than stellar interoperations between vendors' phones. For example, Polycom phones have a "semi-attended transfer" implementation, enabled by default, that isn’t supported by phones from other manufacturers. While my opinion is that this should be disabled by default, I have sympathy for Polycom's dilemma: they wish to offer this functionality to their users (common on traditional PBXes), but there has been no standard way to do so. As a side note, our boot server disables Polycom's semi-attended transfer feature for OnSIP users.
Assuming the recommendations in RFC 5589 (June 2009) filters into vendor implementations, better days are ahead for everyone. I recently reviewed this Best Practices outline as part of an ongoing project to upgrade some of our SIP PSTN gateways and application servers. This RFC provides a clear path for seamless call transferring not only between vendors’ phones within a domain, but also between domains across the Internet.
In the new RFC, there is a push for out-of-dialog REFER usage. I am a fan of out-of-dialog REFER. While I understand how and why dialog re-usage has come to be the standard approach to getting many SIP things done, it has also become one of the messiest corners of SIP (see RFC 5057 for more). I anticipate the new SIP Transfer RFC, along with SIP GRUU (RFC5627) and Target-Dialog header (RFC 4538), will clean these messy corners. I hope the future brings a SIP world where developers don't realize how lucky they are not to have to deal with dialog reuse.
But not to ignore the present, the new RFC covers how to best implement forms of transfer using the now common in-dialog REFER approach. If you've never given any thought to transferring a phone call, you might be surprised to learn that call transfer is typically broken down into at least two groups: Blind (or Basic) and Attended (or Consultation). The main difference boils down to whether the Transferor sets up a call with the Transfer Target prior to initiating the actual transfer. Furthermore, Attended Transfers are commonly broken down into a Semi-Attended type, sometimes referred to as Attended with Early Completion (which, as I've mentioned, has bedeviled SIP for many years. I, for one can say that I very much like the UA driven implementation recommended in the RFC.)
As I mentioned above, I'm currently working on upgrading our PSTN gateways, and this RFC also does a good job reviewing the tricky issues involved in handling transfers through a gateways. These issue may not be apparent to those who haven't implemented a PSTN gateway particularly in an environment where calls are distributed or load balanced across multiple gateways. This RFC is worth a read by anyone who is implementing or purchasing SIP PSTN gateways or SIP Session Boarder Controllers (SBC) for their platform. For example, implementing an attended transfer between two call legs that are on the same gateway instance is a different problem from implementing between two call legs that are on different gateway instances (perhaps in different data centers in different parts of the world). And, unless your requirements only call for a single gateway, the implementation of later scenario is far more important than the former!