Call transfer

In a typical call transfer, party A sends a SIP REFER message to party B, and this causes party B to initiate a new call according to the parameters specified in the REFER message (destination and the like). While this works just fine with IP phones on your VoIP network, it may not work in the case of SIP to PSTN or PSTN to SIP calls, since you will not always know if your PSTN carrier supports REFER messages (in fact, many do not support it).

To eliminate this problem and allow your users to make call transfers anytime and anywhere, PortaSIP will intercept the REFER message and process it entirely on the PortaSwitch side. Every REFER message is authorized in PortaBilling. So if A transfers a call to a phone number in India, the billing engine will validate whether A is actually allowed to make this call, and limit the call duration according to A’s available funds. After that, PortaSIP will proceed to establish a new outgoing call and connect the transferred party. When the call is finished, A (the party who initiated the transfer) will be charged for the transferred portion of the call; this applies regardless of whether A was the called or calling party in the original call.

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

• A dials B’s phone number (1).
• PortaSIP sends the incoming call to B (2); when B answers, the call is established between A and B (3).
• At a certain moment in the conversation, B performs a call transfer (REFER) to C (4).
• PortaSIP intercepts this message and sends an authorization request to PortaBilling to check if B is allowed to send a call to this destination and to obtain the routing (5).
• In the case of a positive reply, PortaSIP starts processing the call transfer and sends a NOTIFY message to B to convey the status of the call transfer (6), (B is present in the call until C answers) and a new outgoing call is sent to С (7).
• When C answers, PortaSIP sends a NOTIFY message to B, cancels the call leg that goes from A to B and sends re-INVITEs to A and C for codec negotiation. The call is established (8).
• When either A or С hang up, the call is terminated and accounting records are sent to the billing engine (9):
  • one is for the call between A and B, charged to its originator, A. This xDR contains the charge for the whole call (including A to B and A to C call legs), according to A’s outgoing rate to B.
  • one for the call between A and B, charged to B. This xDR contains the charge based on B’s incoming rate.
  • one for the call between A and C, charged to its transferor, B. This xDR contains the charge for the call between B and C, according to B’s outgoing rate.

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/CDRs will look like this:

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

As a result, A does not really know that a call transfer took place. A is charged for a normal outgoing call to B, and this is what A will see in the CDR history. B is charged for an outgoing call to C, since B is responsible for the transfer.

It may happen that for some reason a blind transfer is unsuccessful (e.g., the destination number is unavailable or does not answer, etc.), in which case, PortaSIP either reconnects the parties and performs another transfer or disconnects the call.

By default, if C does not answer, PortaSIP reconnects A and B. To configure PortaSIP to disconnect calls upon an unsuccessful blind transfer the administrator creates a service policy and sets the transfer_disable_recovery attribute value to Yes.

The call, in this case, flows as described above for a blind transfer, except for the last two steps (8,9):

If C does not answer, PortaSIP disconnects A from the call. The call finishes and accounting records are sent to the billing engine (9):

• one is for the call between A and B, charged to its originator, A. This xDR contains the charge for the whole call (including A to B and A to C call legs), according to A’s outgoing rate to B.
• one for the call between A and B, charged to B. This xDR contains the charge based on B’s incoming rate.
• one for the call between A and C, charged to its transferor, B. This xDR contains the charge for the call between B and C, according to B’s outgoing rate.

However, the last record (charged to B for the outgoing call to C) will have zero duration and charge, since the transfer failed.

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

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

A scenario in which it is the calling party who 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 С, and they spoke for ten minutes, there will be two CDRs, both under account A:

• A -> B, 15 minutes.
• B -> C, 10 minutes.

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 auto-attendant access number (1).
2. PortaSIP delivers the call to the auto-attendant (account A) (2).
3. The auto-attendant answers the call and the caller hears prompts to take action (3).
4. Upon taking action, the caller is sent to a call queue from which they are connected to an operator named Bob (4).
5. After a while Bob blindly transfers Pete’s call to his colleague Carol (5).
6. PortaSIP authorizes account A for the transfer in PortaBilling (6).
7. Upon an authorization check, PortaSIP establishes the call to Carol (7).
8. Bob is then disconnected from the call.
9. Carol answers the call and she and Pete begin their conversation (8).
10. Once their conversation has finished, Pete hangs up.
11. PortaSIP sends the accounting information to PortaBilling (9).
12. PortaBilling produces the charges as follows:
    • Account A is charged for the incoming call from Pete.
    • Account A is also charged for the transfer call to Bob and the call between Pete and Carol (as the result of 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 IVR instead of to Carol’s extension.

PortaSwitch supports the ringback tone generation and early media relaying during blind transfer (refer to the Ringback Tone Generation and Early Media Relying section for more details), including scenarios when a call transfer is performed from within an auto attendant menu.

The ring back tone generation and early media relaying during blind transfer is controlled via the transfer_progress service policy option. Its description is given in the table below.

An administrator configures a service policy to fine-tune the desired behavior and then assigns this policy to the account that performs the transfer.

This helps to ensure that transferred parties are kept informed about the progress of the call, thus improving the customer’s overall experience with PortaSwitch.

• A dials B’s phone number (1).
• PortaSIP sends the incoming call to B (2); when B answers, the call is established between A and B (3).
• B places A on hold (4); PortaSIP provides music on hold for A (5).
• B initiates a new outgoing call to С (6). PortaSIP sends an authorization request to PortaBilling to check if B is allowed to send a call to this destination and to obtain the routing (7). In the case of a positive reply, PortaSIP establishes a call to С (8).
• The call is now established between B and С (9); after a short exchange B decides to bridge A and C together, and a REFER message is sent to PortaSIP (10).
• PortaSIP will now connect A and C together (12) and cancel both of the call legs going to B.
• When either A or С hangs up, the call is terminated and accounting records for two outgoing calls are sent to the billing engine (13): one is the A->B call (charged to its originator, A) and the other is the A->C call (likewise charged to its originator, B).

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:

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