How to use ISDN call transfer

Blind (immediate) transfer

Blind (immediate) transfer is a transfer that completes before knowing if the caller has successfully contacted the third party.

Figure 1. Event flow for a blind (immediate) transfer

The sequence of events in Figure 1 is:

1. The Caller state table issues a TransferCall request with the ring_wait and ring_time parameters set to zero to indicate that a blind transfer is required.
2. The ISDN Signalling Process receives the TransferCall request and initiates an outbound call to the third party using the ISDN_Imm_Xfer state table with the aid of the ISDN_Call_Transfer custom server.
3. The outgoing state table connects to the ISDN_Call_Transfer custom server. It then issues a MakeCall with the ring_wait and ring_time parameters set to zero to indicate that a blind make call is required. The make call returns as soon as the call is underway, or if there is a problem with the supplied parameters (for example, the phone number contains invalid characters).
4. When the MakeCall action returns, the outbound state table informs the ISDN_Call_Transfer custom server (and so the ISDN Signalling Process) of the result and enters into a WaitEvent. It should not hang up at this stage because this may interfere with the completion of the transfer.
5. The ISDN Signalling Process sends a message to the switch to request that the caller and third party are connected together (the actual transfer) and waits for the switch to confirm this.
6. The ISDN Signalling Process sends the result of the transfer to the incoming state table, which causes the TransferCall action to return.

Soon after step 5, the switch hangs up both the incoming and outgoing calls connected to Blueworx Voice Response. If these calls are not disconnected by the switch within a reasonable time, the Blueworx Voice Response applications disconnect the calls (after the TransferCall for the incoming call, and after the WaitEvent for the outgoing call).

For most applications, this type of transfer can be used without modification to either the user application or to the ISDN_Imm_Xfer state table. The most likely modification that may have to be made though, is to specify which channels may be used to make the outbound call (see SV178 definition in the Blueworx Voice Response for AIX: Application Development using State Tables information). This modification should be made in the ISDN_Imm_Xfer state table before the MakeCall action is performed.

Screened transfer (with call answer supervision)

Screened transfer (with call answer supervision) is a transfer that completes after knowing whether or not the third party has answered. If the third party does not answer, the application can continue interacting with the caller. These two scenarios are described in the following sections:

• Figure 2 shows what happens when the third party answers and the transfer completes.
• Figure 3 shows what happens when the third party is not contactable and the transfer is abandoned so that the incoming application can continue interacting with the original caller.
  Figure 2. Event flow for a screened transfer with call answer supervision (for a successful call)
  
  

The sequence of events in Figure 2 is:

1. The Caller state table issues a TransferCall request with the ring_wait and ring_time parameters set to non-zero values to indicate that a screened transfer is required.
2. The ISDN Signaling Process receives the TransferCall request and initiates an outbound call to the third party using the ISDN_SupA_Xfer state table with the aid of the ISDN_Call_Transfer custom server.
3. The outgoing state table connects to the ISDN_Call_Transfer custom server. It then issues a MakeCall with the ring_wait and ring_time parameters set to non-zero values to indicate that a screened make call is required. The make call returns as soon as the call is answered (because this is a successful transfer).
4. When the MakeCall action returns, the outbound state table informs the ISDN_Call_Transfer custom server (and so the ISDN Signaling Process) of the result and enters into a WaitEvent. It should not hang up at this stage because this will interfere with the completion of the transfer.
5. The ISDN Signaling Process sends the result of the transfer to the incoming state table, which causes the TransferCall action to return.
6. The incoming state table should then perform a TerminateCall to complete the transfer.
7. On receiving the TerminateCall from the incoming state table, the ISDN Signaling Process sends a message to the switch to request that the Caller and third party are connected together (the actual transfer), and waits for the switch to confirm this.
8. The ISDN Signaling Process sends a HostEvent to the outbound state table, which should then hang up.
9. The ISDN Signaling Process sends Success to the incoming state table, which causes the TerminateCall action to return.

For most applications, this type of transfer can be used without modification either to the user application or to the ISDN_SupA_Xfer state table. The most likely modification that may have to be made though, is to specify which channels may be used to make the outbound call (see the SV178 definition in the Blueworx Voice Response for AIX: Application Development using State Tables information), or to modify the ring_wait and ring_time parameters used in the MakeCall state table action. Modifications to system variables should be made in the ISDN_SupA_Xfer state table before the MakeCall action is performed.

Figure 3. Event flow for a screened transfer with call answer supervision (for an unsuccessful call)

The sequence of events in Figure 3 is:

1. The Caller state table issues a TransferCall request with the ring_wait and ring_time parameters set to non-zero values to indicate that a screened transfer is required.
2. The ISDN Signaling Process receives the TransferCall request and initiates an outbound call to the third party using the ISDN_SupA_Xfer state table with the aid of the ISDN_Call_Transfer custom server.
3. The outgoing state table connects to the ISDN_Call_Transfer custom server. It then issues a MakeCall with the ring_wait and ring_time parameters set to non-zero values to indicate that a screened make call is required. The make call returns as soon as the result of the call is known (for example, no answer, or busy, because this is an unsuccessful transfer).
4. When the MakeCall action returns, the outbound state table informs the ISDN_Call_Transfer custom server (and hence the ISDN Signaling Process) of the result and terminates the call.
5. The ISDN Signaling Process sends the result of the transfer (not successful, in this case) to the incoming state table which causes the TransferCall action to return.
6. The incoming call state table performs a ReconnectCall.
7. The ISDN Signaling Process returns Success or CallerHungUp, depending on the current state of the call. This causes the ReconnectCall action to return.
8. If the edge returned from the ReconnectCall action was Success, the incoming application can continue to interact with the caller; otherwise it must hang up.

For most applications, this type of transfer can be used without modification either to the user application or to the ISDN_SupA_Xfer state table. The most likely modification that may have to be made though, is to specify which channels may be used to make the outbound call (see the SV178 definition in the Blueworx Voice Response for AIX: Application Development using State Tables information), or to modify the ring_time and ring_wait parameters used in the MakeCall state table action. Modifications to the system variables should be made in the ISDN_SupA_Xfer state table before the MakeCall action is performed.

Screened transfer (with third party consultation)

Screened transfer (with third party consultation) is a transfer that can interact with the third party, if it answers, during the transfer. The transfer can then be completed, or the application can reconnect to the original caller and continue.

Due to limitations with the Blueworx Voice Response hardware, the original caller state table cannot perform the third party interaction, and so the Blueworx Voice Response signaling model for a transfer operation cannot be followed precisely. Instead, the outbound state table must perform the third party interaction. Two custom server calls (and associated state tables) have been added to allow the inbound and outbound state tables to perform some basic communications during the transfer. This should keep any changes to your application to a minimum.

Figure 4 shows a third party consultation that ends with a transfer, and Figure 5 shows a third party consultation that ends with a reconnection to the original caller.

Figure 4. Event flow for a screened transfer with third party consultation (ending in a transfer)

The sequence of events in Figure 4 is:

1. The Caller state table decides that a screened transfer with third party consultation is required. It sets up some data to tell the outbound state table what needs to be done on the consultation. This data is set up by an OpenHostServerLink to the ISDN_Call_Transfer custom server and a SendData using the SetUserData function.
   Note: A state table called ISDN_Xfer_Data is supplied to help perform this function.
2. The Caller state table issues a TransferCall request with the ring_wait and ring_time parameters set to non-zero values to indicate that a screened transfer is required.
3. The ISDN Signaling Process receives the TransferCall request and initiates an outbound call to the third party using the ISDN_SupA_Xfer state table with the aid of the ISDN_Call_Transfer custom server.
4. The outgoing state table connects to the ISDN_Call_Transfer custom server. It then issues a MakeCall with the ring_wait and ring_time parameters set to non-zero values to indicate that a screened make call is required. The make call returns as soon as the call is answered (because this is a successful transfer).
5. When the MakeCall action returns, the outbound state table can interact with the third party (for example, to ask if the third party wants to accept a call at this time). The third party responses are gathered.
6. The outbound state table then informs the ISDN_Call_Transfer custom server (and so the ISDN Signaling Process) of the result of the MakeCall and the third party responses to the consultation, and enters into a WaitEvent. It should not hang up at this stage because this would interfere with the completion of the transfer.
7. The ISDN Signaling Process sends the result of the transfer to the incoming state table, which causes the TransferCall action to return.
8. The incoming state table should then use a SendData/ReceiveData pair of actions calling the GetUserStatus function to determine the response from the third party. This example assumes that the response is to continue with the transfer operation.
   Note: A state table called ISDN_Xfer_Stat is supplied to help perform this function.
9. The incoming state table should then perform a TerminateCall to complete the transfer.
10. On receiving the TerminateCall from the incoming state table, the ISDN Signaling Process sends a message to the switch to request that the Caller and third party are connected together (the actual transfer), and waits for the switch to confirm this.
11. The ISDN Signaling Process sends a HostEvent to the outbound state table, which should then hang up.
12. The ISDN Signaling Process sends Success to the incoming state table, which causes the TerminateCall action to return.

For most applications, this type of transfer will need modifications to be made to both the user application and to the ISDN_SupA_Xfer state table. The changes involve moving the third party consultation logic to the outbound state table (this would normally be performed in the inbound state table). Another modification that may have to be made is to specify which channels may be used to make the outbound call (see the SV178 definition in the Blueworx Voice Response for AIX: Application Development using State Tables information), or to modify the ring_wait and ring_time parameters used in the MakeCall state table action. Modifications to system variables should be made in the ISDN_SupA_Xfer state table before the MakeCall action is performed.

Figure 5. Event flow for a screened transfer with third party consultation (ending up reconnecting to the original caller)

The sequence of events in Figure 5 is:

1. The Caller state table decides that a screened transfer with third party consultation is required and sets up some data to tell the outbound state table what needs to be done on the consultation. This data is set up by an OpenHostServerLink to the ISDN_Call_Transfer custom server and a SendData using the SetUserData function.
   Note: A state table called ISDN_Xfer_Data is supplied to help perform this function.
2. The Caller state table issues a TransferCall request with the ring_wait and ring_time parameters set to non-zero values to indicate that a screened transfer is required.
3. The ISDN Signaling Process receives the TransferCall request and initiates an outbound call to the third party using the ISDN_SupA_Xfer state table with the aid of the ISDN_Call_Transfer custom server.
4. The outgoing state table connects to the ISDN_Call_Transfer custom server. It then issues a MakeCall with the ring_wait and ring_time parameters set to non-zero values to indicate that a screened make call is required. The make call returns as soon as the call is answered (because this is a successful transfer).
5. When the MakeCall action returns, the outbound state table can interact with the third party (for example, to ask if the third party wants to accept a call at this time). The third party responses are gathered.
6. The outbound state table then informs the ISDN_Call_Transfer custom server (and so the ISDN Signaling Process) of the result of the MakeCall and the third party responses to the consultation, and enters into a WaitEvent. It should not hang up at this stage because this would interfere with the completion of the transfer.
7. The ISDN Signaling Process sends the result of the transfer to the incoming state table, which causes the TransferCall action to return.
8. The incoming state table should then use a SendData/ReceiveData pair of actions calling the GetUserStatus function to determine the response from the third party. This example assumes that the response is to abandon the transfer operation and connect back to the original caller.
   Note: A state table called ISDN_Xfer_Stat is supplied to help perform this function.
9. The incoming state table should then perform a ReconnectCall to abandon and tidy up the abandoned transfer.
10. On receiving the ReconnectCall from the incoming state table, the ISDN Signaling Process sends a host event message to the outbound state table to tell it to hang up the outbound call, if it hasn't already done so.
11. The ISDN Signaling Process sends Success to the incoming state table, which causes the ReconnectCall action to return.
12. The inbound state table can now continue with the original caller.

For most applications, this type of transfer will need modifications to be made to both the user application and to the ISDN_SupA_Xfer state table. The changes involve moving the third party consultation logic to the outbound state table (this would normally be performed in the inbound state table). Another modification that may have to be made is to specify which channels may be used to make the outbound call (see the SV178 definition in the Blueworx Voice Response for AIX: Application Development using State Tables information), or to modify the ring_wait and ring_time parameters used in the MakeCall state table action. Modifications to system variables should be made in the ISDN_SupA_Xfer state table before the MakeCall action is performed.