# Call transfer and Q.SIG

Q.SIG specifications describe the behavior of nodes in a network and how they interact. NMS ISDN supports two types of call transfer operations between Q.SIG nodes:

- Transfer-by-rerouteing

- Transfer-by-join

Both operations are invoked using either nccTransferCall in the Natural Call Control service, or the ACU_TRANSFER_RQ message in the ISDN API. To invoke the transfer operation, the application must do the following:

Step | Action | Result
1 | Obtain the call ID for transfer. | The stack attempts to get the call ID for transfer by using the transfer-by-rerouteing operation. If this attempt fails, the stack uses transfer-by-join.
2 | Request the transfer. | The stack transfers the call by using the same operation it used to obtain the caller ID. For example, if the stack used the transfer-by-join operation to obtain the caller ID, it also uses this method for the transfer itself.

## Transfer-by-rerouteing

In a transfer-by-rerouteing operation, the two separate calls are connected outside the local node. After the transfer confirmation, the local node is no longer involved with the transferred calls.

The following illustration shows how the transfer-by-rerouteing operation works:

## Transfer-by-join

In a transfer-by-join operation, the two separate calls are connected through the local node, and the local node remains involved in the call (for example, the call is not rerouted).

To transfer a call, the application must perform the switching required to connect calls together by using standard calls to the Natural Access Switching service. Then, the application must invoke the transfer operation.

Once the transfer is invoked, the stack at the local node allows the two separate calls connected through the node to pass facilities information to each other without involving the local application. Basic call control signaling for the two calls (such as call clearing) must still be managed by the application. In effect, the calls are bridged (see Tandem services).

The application is responsible for assuring that the B and C parties that are joined are compatible. For example, both parties must be carrying the same type of service (data, voice).

Note: For the call bridging to be successful, the NS_IE_RELAY_BEHAVIOUR bit must be set to its default setting in the ns_behavior substructure referenced in the call to isdnStartProtocol. For more information, see the Dialogic® NaturalAccess™ ISDN Messaging API Developer's Manual.

The following illustration shows how the transfer-by-join operation works: