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

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.