Call transfer model

The same call transfer model is used for both common channel and exchange data link signaling. Call transfer includes the transfer of an active call to a third party and the reconnection of the call if the transfer is unsuccessful. If the signaling process specifies that it is capable of supporting call transfer Blueworx Voice Response expects it to implement the call transfer model described here. Note that a switch may implement a different call transfer model from the one described here. The signaling process is responsible for mapping the Blueworx Voice Response call transfer model to that used by the switch.

There are two types of call transfer: screened or supervised transfer and blind transfer. With screened transfer, the application puts the existing party in a suspended state (on hold), and completes the transfer only if the call to the third party is answered. With blind transfer, the application puts the existing party on hold, and disconnects from the call after sending the address of the third party. The Blueworx Voice Response model is defined in terms of screened transfer.

A voice application may offer to transfer the caller to another number, for example, to transfer out of a voice mail application. An “automated agent” voice application may decide to transfer the caller to a human agent if they hesitate too long in choosing an option. The call transfer may or may not be successful. Figure 1 shows the possible outcomes and what the voice application should try to do in each case.

Blueworx Voice Response allows an application to transfer calls if the underlying telephony protocol supports call transfer. Blueworx Voice Response applications use the TransferCall and ReconnectCall state table actions to transfer calls. These actions are described in more detail in the Blueworx Voice Response for AIX: Application Development using State Tables information. To transfer a call, the application includes a TransferCall action in the state table, specifying the phone number of a third party. The TransferCall action is only meaningful for connected calls.

Figure 1. Call transfer: the sequence of state table actions and result states

This flow diagram begins with a caller connected to WebSphere Voice Response and the issue of TransferCall. Three types of result are shown. They are Succeeded; Caller hung up; or Other problems. If the result is Succeeded, the caller is put on hold and the voice application can announce the caller to the third party to whom the transfer is made. The caller remains on hold. After the TerminateCall action issues, the caller is disconnected from WebSphere Voice Response and connected instead to the third party. The voice application can meanwhile continue with other tasks. If the result is Caller hung up. The TerminateCall action puts the voice application into the Idle state. Examples of the other problems grouped into the third possible result are Phone busy, Network busy, No answer, Invalid phone number, Outbound line problem, Unexpected tone. In these cases the ReconnectCall action is issued. If it succeeds, the caller is connected to WebSphere Voice Response and the voice application can explain to the caller that the transfer failed and ask for further instructions. The outcome in other cases depends on the switch and protocol being used, and is further explained in the succeeding text.

Figure 2 shows the call transfer states, and the allowable state transitions, in terms of the state table actions:

If the TransferCall action succeeds, the original caller is placed on hold, and Blueworx Voice Response (and the state table) are connected to the third party. The state table can play an announcement to the third party. Once the state table hangs up, either by issuing the TerminateCall or the CloseEverything state table action, the original caller is connected to the third party.
If the TransferCall action fails, the original caller is assumed to be on hold, and Blueworx Voice Response (and the state table) need to be reconnected to the original caller. The state table reconnects to the original caller by issuing the ReconnectCall action. If the ReconnectCall action succeeds, Blueworx Voice Response (and the state table) is once again connected to the original caller. The state table can play an announcement to the caller explaining that the transfer has failed. If the ReconnectCall action fails, the situation is indeterminate. In this case the state table needs to clear the call, either by issuing the TerminateCall or the CloseEverything state table actions.
Figure 2. Call transfer model in terms of state table actions

The signaling interface includes primitives that correspond to the TransferCall and ReconnectCall state table actions. These primitives are SL_CALL_TRANSFER_REQ, SL_CALL_TRANSFER_CNF, SL_CALL_RECONNECT_REQ and SL_CALL_RECONNECT_CNF. Figure 3 shows the call transfer states, and the allowable state transitions, in terms of the signaling interface primitives. This is the model that signaling processes must implement to be compatible with Blueworx Voice Response.

If you are using the Nortel DMS-100 or DMS-250 you might be able to use the Blueworx Voice Response ISDN call transfer application. See the Blueworx Voice Response for AIX: Designing and Managing State Table Applications information for more information.

Figure 3. Call transfer model in terms of signaling interface primitives

The Figure follows the same sequence of states as described previously in terms of state table actions. The Connected state is changed to the Third Party state by the SL_CALL_TRANSFER_REQ and SL_CALL_TRANSFER_CNF (successful) primitives. After the call finishes, the primitives SL_CALL_TERMINATE_REQ and SL_CALL_TERMINATE_CNF return the state to Idle. If the call is unsuccessful, the SL_CALL_TRANSFER_REQ and SL_CALL_TRANSFER_CNF (unsuccessful) primitives are sent. The Connected state changes to the Caller on hold state, when the call is ended by SL_CALL_TERMINATE_REQ and SL_CALL_TERMINATE_CNF to return the state to Idle, or the reconnection primitives are sent (SL_CALL_RECONNECT_REQ and SL_CALL_RECONNECT_CNF). If the reconnection is successful the SL_CALL_RECONNECT_REQ and SL_RECONNECT_CNF (successful) primitives are sent and the state returns to Connected once more. If it isunsuccessful the SL_CALL_RECONNECT_REQ and SL_RECONNECT_CNF (unsuccessful) change the state to Indeterminate, and thence to Idle following the SL_CALL_TERMINATE_REQ and SL_CALL_TERMINATE_CNF primitives.