Condition	Description
Proceeding	The second line's address was delivered to the switch.
Alerting	Ring tone received on the second line.
Connected	The second line has been answered.

3.8 Call Transfer

(Page 9 of 12 in this chapter)

AG Access supports the ability to transfer calls from a first line to a second line through a PBX. The call transfer functions can only be initiated when the port (first line) is in the call connected state.
There are two methods for transferring calls:

Supervised transfer via adiPlaceSecondCall

Blind transfer via adiTransferCall
Both methods deliver a flashhook to the PBX and obtain a second line. After AG Access receives a recall dial tone from the PBX, the process for placing a second call is identical to that described in Section 3.4.3, Events Used by Call Control for call control. The two transfer methods are described below.
Note: The transfer functions use the same call progress algorithms described in previous sections related to placing calls. The adiPlaceSecondCall and adiTransferCall functions also use the ADIPLACECALL parameters.

3.8.1 Supervised Transfer

The supervised transfer method allows the application to control the transfer process. The following outlines the procedure for a supervised transfer and is depicted in Figure 11.

: Call Transfer State Diagram

The application invokes adiPlaceSecondCall. AG Access obtains a second line and generates the placing second call event (ADIEVN_PLACING_CALL2). AG Access then delivers the second address to the PBX and monitors the call as described in Section 3.4.3, Events Used by Call Control.
If AG Access fails to establish the second call, a second call disconnected event (ADIEVN_CALL2_DISCONNECTED) is generated. The port changes back to the connected state for the first line.
If the second call is successfully placed, AG Access generates a second call connected event (ADIEVN_CALL2_CONNECTED). The application is now speaking to the third party (second line destination).
If the third party hangs up, AG Access generates a second call disconnected event, the port transitions back to the connected state for the first line, and the application resumes speaking with the first party.
The application can invoke adiReleaseSecondCall causing AG Access to deliver a flashhook to the PBX and generate a second call disconnected event. The port changes back to the connected state for the first line. Depending on the PBX, this may result in a three-way conversation.
The application can invoke adiReleaseCall causing AG Access to disconnect the port from the PBX. The release call event is generated and the port changes back to the idle state. This completes the transfer.

3.8.2 Blind Transfer

The adiTransferCall function provides a blind transfer capability. A blind transfer initiates second call placement and then disconnects the AG Access port from the PBX before second call placement is resolved. The application specifies one of the following conditions on which it disconnects from the switch, thus completing the transfer:

Condition

Description

Proceeding

The second line's address was delivered to the switch.

Alerting

Ring tone received on the second line.

Connected

The second line has been answered.
The following outlines the procedure for a blind transfer (refer to Figure 11).

The application invokes adiTransferCall. AG Access obtains a second line and generates the placing second call event (ADIEVN_PLACING_CALL2). AG Access then delivers the second address to the PBX.

If the adiTransferCall option is to disconnect on proceeding, AG Access generates the call disconnected event and the application must release the call as described in Section 3.5, Releasing Calls before new calls can be established on the port. Otherwise, AG Access monitors the call as described in Section 3.4.3, Events Used by Call Control.

If the adiTransferCall option is to disconnect on alerting and AG Access receives ring tone from the PBX, the call disconnected event is generated and the application must release the call as described in Section 3.5, Releasing Calls. Otherwise, AG Access monitors the call as described in Section 3.4.3, Events Used by Call Control.

If the adiTransferCall option is to disconnect when the second call is connected as described in Section 3.4.2, Call Control Mask Parameters, the call disconnected event is generated and the application must release the call as described in Section 3.5, Releasing Calls.

If the condition specified in the adiTransferCall function does not occur, AG Access generates a second call disconnected event. The port is returned to the call connected state for the first line. This might occur, for example, if the second line was busy.

3.8.3 Call Transfer Events

Following is a description of call transfer events generated by AG Access.
ADIEVN_PLACING_CALL2 - After delivering the flashhook to the PBX and getting a recall dial tone, AG Access generates the placing second call event. The destination address for the third party is then delivered to the switch.
ADIEVN_CALL2_DISCONNECTED - If placement of the second call fails or if the third-party hangs up, the ADIEVN_CALL2_DISCONNECTED event is generated. The port returns to the connected state for the first call. This event is also generated when the application releases the second call via adiReleaseSecondCall.
ADIEVN_CALL2_CONNECTED - This event is generated if the second call is successfully established via adiPlaceSecondCall. The connection criteria and processing are identical to those when originating calls via adiPlaceCall.
ADIEVN_CALL_DISCONNECTED - The call disconnected event is generated when a blind transfer succeeds. It is also generated if the first line disconnects before AG Access generates the placing second call event. The call disconnected event disconnects the port from both calls and the application must invoke adiReleaseCall as described in Section 3.5, Releasing Calls.

(Page 9 of 12 in this chapter)