DMS user-side specifications describe interactions between an application and the network from a user's point of view. In a DMS configuration, the network performs actual transfer operations. The application's role in a call transfer is to send a request to the network to perform a release link trunk (RLT) operation.
The following terms are used in the illustrations in this topic:
|
This term... |
Refers to... |
|---|---|
|
Call #1 |
The call between the controller and user A. |
|
Call #2 |
The call between the controller and user B. |
|
Controller |
The application requesting RLT, using the user-side DMS protocol. |
|
User A |
The first user connected with the controller that is to be transferred to user B. User A does not need to be an ISDN terminal or connected to an ISDN exchange. |
|
User B |
The second user connected with the controller that the transferred user (user A) is to be connected to upon completion of RLT. User B does not need to be an ISDN terminal or connected to an ISDN exchange. |
RLT enables a controller on a PRI to request that the switch connect two independent calls. The two calls can be served by the same PRI trunk or by two different PRI trunks that both serve the application, as shown in the following illustration:
If the switch accepts the request, the controller is released from the calls and the other two users are directly connected, as shown in the following illustration:
RLT works only when all of the following conditions are met:
The controller has subscribed to RLT.
The controller has at least two independent calls.
The bearer capabilities of both calls are compatible.
Both calls are in the connected state at the time RLT is invoked.
Call #2 is an outbound call originated by the controller. The call origination must specify that the call may become a candidate for RLT, by setting the getcallid field in the PLACECALL_EXT structure.
Call #1 can be either inbound or outbound.
Call #1 can be established either before or after call #2.