Skip to main content
In a SIP transfer, the party transferring the call doesn’t dial the transfer destination. Instead, it sends a REFER asking the SIP peer on the other end of the call (the transferee) to dial it, and that new call replaces the current one. This guide explains how that works when a Guava agent transfers a call, and what it means for your transfer destinations.

​
A basic call setup

Let’s start by reviewing a basic call setup. Say you have an ITSP (like Twilio Elastic SIP) that converts inbound PSTN calls to SIP calls. These calls are forwarded to Guava’s SIP trunk and land on a specific Guava agent. From Guava’s point of view, the ITSP is the SIP peer. Every SIP message for this call is exchanged between Guava and the ITSP.

​
What happens when you transfer

When the agent calls call.transfer(), Guava sends a SIP REFER to the ITSP. The Refer-To header contains your transfer destination.
Phone numbers work the same way. A destination like +18005550199 becomes a tel: URI in the Refer-To header, and the ITSP dials the number.
The refer destination is not dialed from Guava. It’s dialed by the side that receives the REFER, so the transfer destination must be routable from the transferee.

​
Choosing a destination

Since the ITSP places the new call, pick destinations that the ITSP can reach:
The ITSP also decides whether to accept the REFER at all. Some ITSPs require REFER to be enabled, or limit which destinations they will dial. Please see your ITSP provider’s docs for more information.

​
Sending information to the transfer destination

The transfer URI can carry extra data for the transfer destination, such as the caller’s account ID or why they’re calling. There are two ways to attach it, and which one to use depends on the system you’re transferring to.
You can use the SipUri helper to build your transfer destination URI. It automatically handles escaping in header and URI params. You can also build the URI string yourself.
URI parameters are appended to the URI after a ;. The ITSP dials the URI with the parameters included, so the destination can read them from the Request-URI of the incoming INVITE.
Header parameters are appended after a ?, with multiple headers joined by &. The ITSP adds each one as a SIP header on the INVITE it sends to the destination. Use the X- prefix for custom headers.
These options only apply to sip: destinations, not phone numbers.
The ITSP builds the new INVITE, so it decides which parameters and headers reach the destination. Many ITSPs drop header parameters, or only keep X- headers. Check your ITSP’s docs before relying on either.

​
User-to-User (UUI) information

Many contact center platforms and PBXs expect call data in the standard User-to-User header (RFC 7433) rather than in custom X- headers. You can send it as a header parameter like any other header. The value is usually hex-encoded, followed by an encoding=hex parameter.
Include ;encoding=hex in the header value. SipUri URL-encodes it along with the rest of the value, since ; and = aren’t allowed unescaped in a URI header value. The format of the payload itself is up to the receiving system, so check what it expects. Some systems also limit the payload size, so keep it short.