If you’re running a multi-site Contact Center and you need to transfer a call from one agent to another agent in a different location, you can now send Twilio a SIP REFER message requesting that transfer.
About call transfers
A call transfer is just what it sounds like: It’s when you transfer a customer’s call from one call center agent to another. You might need to initiate a call transfer for several reasons, such as when a customer requesting to speak to the manager. Quick, easy call transfers are a necessary function in today’s business telecom environments.
When an agent presses the “Transfer” button on a SIP-enabled IP phone, the phone issues a SIP REFER method requesting the call to be transferred to a third party using the contact information provided in the request.
A very common type of call transfers is “blind” transfers. Blind transfers occur when a call center agent transfers a customer to another agent without talking to the new agent first. Blind transfers are easy and quick.
Call transfers and Elastic SIP Trunking
Twilio’s Elastic SIP Trunking product now supports blind call transfers. This means you’re now able to request a call be transferred by sending Twilio a SIP REFER message from your SIP communications infrastructure. Twilio will serve as the pivot-point and handle the call redirect thereby allowing you to free up resources in your IP communications infrastructure that are no longer needed.
Call transfers are enabled on a per-Trunk basis, enabling transfers to any SIP destination. Optionally, you may also enable call transfers to the PSTN.
Initiating a call transfer via your Elastic SIP Trunk is free; however, you’ll continue to be responsible for the per-minute Trunking charges to the referred-to destination on your account.
You’ll need to do a few things to start transferring calls:
- Log into the Twilio Console, and navigate to an existing Elastic SIP Trunk (or create a new Elastic SIP Trunk).
- Enable Call Transfers on that Trunk under General Settings.
- Optionally enable call transfers to the PSTN via your Trunk. This is optional as you may not want to allow calls to be transferred to the PSTN, given the associated billing implications of such a transfer.
Place a call via your Elastic SIP Trunk; once established, initiate a transfer from your phone. Twilio will receive that request and transfer your call. Check your Twilio Call Log in the Console to confirm the transfer worked as requested and to see all relevant call details.
The call transfer flow
Let’s take a look at what a call transfer to another SIP endpoint looks like.
For example, let’s start with an active Elastic SIP Trunking Call established from your PBX/SBC via Twilio to the PSTN.
The players are:
- Transferor (your PBX/SBC) – The party initiating the transfer of the Transferee to the Transfer-target.
- Transferee (Twilio/PSTN) – The party being transferred to the Transfer-target.
- Transfer-target (your PBX/SBC) – The new party being introduced to the Transferee.
Everything kicks off with the SIP REFER message from your PBX/SBC towards Twilio. Within the SIP REFER is a Refer-to header (designating a new SIP endpoint as the Transfer-target). Upon receiving the SIP REFER, Twilio returns a 202 Accepted response to your PBX/SBC. This informs you that Twilio is willing to carry out the transfer.
The original call is placed on hold (not shown in the call flow).
The SIP REFER creates a quasi-subscription between the Transferor (your PBX/SBC) and Twilio. Even though there wasn’t a SIP SUBSCRIBE message sent, for the duration of the transfer, Twilio will act as if such a subscription exists.
Twilio sends a SIP INVITE to the new SIP endpoint which processes the SIP INVITE as a normal, incoming call. At this time, Twilio will send SIP NOTIFY messages to inform the Transferor of the status (100 Trying, 200 OK) of the new call from Twilio to the new SIP endpoint.
Once the new call is answered, the Transferor will terminate the existing, held call to the original SIP endpoint.
Your call logs
If you look at your Elastic SIP Trunking call logs, you’ll notice that the Original Call has a “Child Call” representing the new call established as a result of the requested call transfer.
Learn more: Call Transfer User Documentation
We can’t wait to see what you’ll build!