Call transfer

When a user wants to send the current call to another phone number or extension, they initiate a call transfer. The following types of call transfer are available:

• Unattended (blind) transfer
• Attended transfer
• Semi-attended transfer

Imagine an agent is on a call with a client and needs to transfer the call to a colleague. The agent presses the transfer button on their IP phone (here we are referring to Yealink SIP-T21P, but other phone models should have similar functionality). The client is automatically put on hold.

From there, let’s see what happens with each type of transfer:

• Unattended (blind) transfer – the agent dials the colleague’s phone number, and is disconnected without knowing what happens next to the call.
• Attended transfer – the agent dials the colleague’s phone number, presses #, and is connected to the colleague. The agent asks the colleague to assist, presses the transfer button to confirm the transfer, and is disconnected.
• Semi-attended transfer – the agent dials the colleague’s phone number, presses #, and waits to hear the ringing tone from the colleague’s extension to confirm its availability. Upon hearing the ringing tone, the agent presses the transfer button to confirm the transfer, and is disconnected.

Let’s say that a customer (user A) is having a call with an agent (user B) and the agent transfers the call to their colleague (user C). PortaBilling checks if user B has available funds and is allowed to make an outgoing call to user C, then instructs PortaSIP to perform the transfer. When user C answers the call, user B who initiated the transfer is disconnected from the call. As a result, when the call is finished, user B is charged for the outgoing call to C, even if user B is the called party in the initial call.

This allows you to transparently charge call transfers and avoid fraudulent activities (e.g., when a call is transferred to a very expensive international destination).

In a typical call transfer scenario, when the SIP phone of user B sends a SIP REFER message to the SIP phone of user C, PortaSIP intercepts the REFER message and processes it entirely on the PortaSwitch side. PortaSIP then sends an authorization request to PortaBilling. As a result, user B initiates a new call to user C whose phone number is specified in the REFER message.

PortaSIP always intercepts the REFER message, no matter if it’s a call between IP phones on your VoIP network or in the case of SIP to PSTN or PSTN to SIP calls. This allows your users to make call transfers anytime and anywhere.

1. User A calls user B.
2. PortaSIP sends an authorization request to PortaBilling to check if A is allowed to call B. The call is authorized successfully and PortaBilling sends the list of routes to PortaSIP for further call processing.
3. PortaSIP sends the incoming call to B.
4. When B answers, the call is established between A and B.
5. After a while, B performs a call transfer to C. The REFER message is sent to PortaSIP. B leaves the call.
6. PortaSIP receives this message and sends an authorization request to PortaBilling to check if B is allowed to call C.
7. In the case of successful authorization, PortaSIP starts the call transfer and sends a NOTIFY message to B to convey the status of the call transfer.
8. PortaSIP sends a new outgoing call to C.
9. When C answers, PortaSIP sends re-INVITEs to A and C for codec negotiation. The call between A and C is established.
10. When either A or С hangs up, the call is terminated and the following accounting records are sent to PortaBilling:
    • User A is charged for the outgoing call to user B.
    • User B is charged for the incoming call from user A.
    • User B is also charged for the call between users A and C (as the result of the transfer by user B).
    • User C is charged for the incoming call from user B.

Assuming that A spoke to B for 5 minutes before B initiated the transfer, then A spoke to С for another 10 minutes, the call charges/xDRs will look like this:

• Under account A: A > C, 15 minutes
• Under account B: A > B, 5 minutes (incoming leg)
• Under account B: A > C, 10 minutes (outgoing leg)
• Under account C: A > C, 10 minutes (incoming leg)

As a result, user B is charged for the call between users A and C as the result of the transfer.

A scenario in which the calling party initiates the transfer (shown below) is nearly identical to that described above for a transfer initiated by the called party.

If A called B and after five minutes of conversation transferred B to C, who spoke for ten minutes, then two xDRs are created for user A:

• A > B, 5 minutes.
• A > C, 10 minutes.

Let’s consider the scenario when user A calls user B and B transfers the call to user C but the blind transfer fails, e.g., user C does not answer. In this case, by default, PortaSIP reconnects user B, if it is allowed by their SIP phone, to the initial call with user A.

To configure PortaSIP to disconnect the calls after the blind transfer fails, you need to create a service policy with the Transfer disable recovery attribute enabled, and assign it to the account.

The call flow in case the blind transfer fails is the same as described above for the blind transfer (steps 1–8), except for the last two steps (9-10):

9. C does not answer and PortaSIP disconnects A.
10. The call finishes and accounting records are sent to PortaBilling:
    • User A is charged for the outgoing call to user B.
    • User B is charged for the incoming call from user A.

Assuming that A spoke to B for 5 minutes before B initiated the transfer and C did not pick up, the call charges/xDRs will look like this:

• Under account A: A > B, 5 minutes (outgoing leg)
• Under account B: A > B, 5 minutes (incoming leg)
• Under account B: A > C, 0 minutes (outgoing leg)

Note that if user C doesn’t answer but has the voicemail configured, e.g., default answering mode is set to “Ring then voicemail”, then user A is connected with the voicemail of user C and the blind transfer is considered to be successful.

In this case, PortaBilling returns routing for this call and PortaSIP sends this call to the voicemail application. Thus, user A can leave a message for user C. When user A hangs up, the call is terminated and the corresponding accounting records are sent to PortaBilling as described in step 10 in the Unattended (blind) transfer section.

This example illustrates how calls that arrive to call queue operators from auto-attendant are processed. Quite often an agent may need to further transfer such calls, e.g., to another department or to their colleague’s extension or even to an IVR to receive a fax, etc. In these cases, a blind transfer is made on behalf of the auto-attendant account as the initial recipient of the call.

Consider how it works:

1. Pete, an external caller, dials the number that has auto-attendant configured.
2. PortaSIP intercepts this request and sends it for authorization to PortaBilling to check if account A is allowed to accept an incoming call.
3. PortaSIP delivers the call to the auto-attendant (account A).
4. The auto-attendant answers the call and the caller hears prompts to take action.
5. Upon taking action, the caller is sent to a call queue from which they are connected to an operator named Bob.
6. After a while, Bob blindly transfers Pete’s call to his colleague Carol and hangs up.
7. PortaSIP authorizes Bob for the transfer in PortaBilling.
8. Upon an authorization check, PortaSIP establishes the call to Carol.
9. Carol answers the call and she and Pete begin their conversation.
10. Once their conversation has finished, Pete hangs up. PortaSIP sends the accounting information to PortaBilling which produces the charges as follows:
    • Account A is charged for the incoming call from Pete. Bob is also charged for the call between Pete and Carol (as the result of the transfer by Bob).
    • Bob and Carol are charged for incoming calls from the auto-attendant.

The same flow occurs if Bob sends Pete to the fax number instead of Carol’s extension.

1. User A dials user B’s phone number.
2. PortaSIP sends an authorization request to PortaBilling to check if A is allowed to call from B. The call is authorized successfully and PortaBilling sends the list of routes to PortaSIP for further call processing.
3. PortaSIP sends the incoming call to B.
4. When B answers, the call is established between A and B.
5. B places A on hold.
6. PortaSIP provides music on hold for A.
7. B initiates a new outgoing call to C.
8. PortaSIP sends an authorization request to PortaBilling to check if B is allowed to call C.
9. In the case of a successful authorization, PortaSIP sends a call to C.
10. The call is now established between B and C.
11. After a short exchange B decides to bridge A and C together, and sends a REFER message to PortaSIP.
12. PortaSIP receives this message and sends an authorization request to PortaBilling to check if B is allowed to call C.
13. PortaSIP sends a new outgoing call to C.
14. When C answers, the call between A and C is established and then B is disconnected.
15. When either A or C hangs up, the call is terminated and accounting records for two outgoing calls are sent to PortaBilling: user A is charged for the call to B and user B is charged for the call between users A and C.

Attended transfer by DTMF allows users not only to answer calls forwarded to their mobile phones from their extensions but also to transfer such calls via DTMF to any extension on the PBX just as they do using a SIP phone.

With attended transfer by DTMF enabled, all that users need to do is:

• Dial the special pre-configured transfer code *66, the number of the extension to which the call is to be transferred, and #.
• Make sure that the called party is available and willing to receive the call.
• Complete the transfer connecting the two parties.

The following diagram illustrates this flow in detail:

1. User A dials the extension of user B. The call arrives at PortaSIP and once authorized by PortaBilling is routed to B.
2. PortaSIP sends the incoming call to B, but B does not answer.
3. The call is forwarded to B’s mobile number.
4. When B answers the call, the call is established between A and B.
5. B realizes that the call is intended for C, and initiates a transfer to C from the mobile phone by dialing *66 followed by C’s extension number plus #.
6. PortaSIP intercepts the *66 transfer code, collects the extension number and sends an authorization request to PortaBilling. PortaBilling verifies that B is allowed to transfer calls via DTMF and returns routing to PortaSIP.
7. PortaSIP places A on hold and sends a call to C.
8. The call is established between B and C.
9. After a short exchange, C confirms acceptance of the call from A, whereupon B hangs up to finish the transfer. PortaSIP connects A and C.
10. When either A or C hangs up, the call is ended and the following accounting information is sent to PortaBilling:
    • User B is charged for two call legs, for the incoming call forwarded from user A to user B’s mobile phone, and for the call between user A and user C.

Semi-attended transfer lies between unattended (blind) and attended transfer.

Semi-attended transfer is helpful if, for example, that colleague’s phone is offline or is in the “Do Not Disturb” mode. In such scenarios, instead of the ringing tone, the agent will hear a “busy” signal or a voicemail prompt. Knowing that the colleague is currently unavailable, the agent can make an informed decision on how to proceed with the call. They may choose to return to the client and ask if they would like to leave a voicemail message, ensuring the client’s needs are addressed appropriately.

Example

John, a call center agent, receives a call from a client asking about discounts. John decides to transfer the call to the sales manager. First, he informs the client about the transfer, and then follows these steps (which may vary depending on the IP phone model):

1. Presses the transfer button on his IP phone, automatically placing the client on hold.
2. Dials the sales manager’s extension number and presses #.
3. Confirms the extension availability by hearing the ringing tone. This assures John that the manager’s extension is online, and the call will either be answered by the sales manager or eventually go to voicemail without being dropped.
4. Presses the transfer button to complete the call transfer without waiting for the sales manager to answer.

John gets disconnected from the call. Once the sales manager answers the call, they are connected with the client and consult on possible discounts.

• The IP phone from which the call is being transferred should have semi-attendant transfer functionality enabled.
• PortaSwitch supports semi-attendant transfer according to the industry standard described in RFC 5589.
  In the call flow described in the RFC, Music on Hold (MOH) is played for the user to whom the call is transferred to prevent them from hanging up prematurely. For example, say the call is transferred to John, he picks up the phone, but the connection of the user who is transferred is still in progress, so MOH is played for John until the call is connected. However, because this connection process is typically completed almost immediately in PortaSwitch, it doesn’t play MOH for the user to whom the call is transferred.
• In case the user to whom the call is transferred does not respond, the user who initiated the transfer will not be rung back and the call will be disconnected.
• You can enable your PBX customers to use semi-attended transfer via applications, such as a receptionist console, developed in-house or by a third-party. This feature can be implemented via the call control API. The application can use the CallControl/join_calls and CallControl/originate_advanced_call methods to enable semi-attended transfer.