Call Control Connection Management

Overview

Connection Management supports two-party connections between channels involved in the same connection, and channels involved in different connections.

Both channels must be In Service, and Channel A must not be in the Idle state.

The Connection Management feature also allows two-party connections between channels that are involved in different connections. For example, if Channels A and B are connected, and Channels C and D are connected, a Connect (A,C) message results in A and C being connected while Channels B and D are released.

This feature also applies to conferences. If Channels A, B, and C are connected to a conference, the host sends a Connect (A, B) message, which results in A and B being connected (without using conference resources) and C remains connected to the conference.

This feature also works if A and B are connected to different conferences. If Channel A is connected to Conference 1, Channel B is connected to Conference 2, and the host sends a Connect (A, B) message, Channels A and B are connected while both conferences continue with existing parties.

You can reduce host interaction of call control by off-loading some call processing to the CSP.

Standard Call Model

The figure below represents a call model that requires significant host/CSP interaction (eight API messages) to establish a connection.

Figure 5-4 Standard Call Model

Call Control Model

The figure below represents the same call scenario, except that Call Control has been programmed to handle the initial stages of call setup, with no host intervention required. Instead of the eight API messages required in the preceding diagram, only two API messages are required when you use Call Control.

Figure 5-5 Call Control Call Model