|
|
Two types of system resources participate in a conference: conference ports and line/trunk ports. Individual port selection and function within the conference is different for each of the two types.
A conference port is allocated to a conference by the system when it receives a host command to reserve, start, or add. A maximum of eight conference ports can be allocated to a single conference. One conference port is required for each two-way conference party. A single conference port is required for all one-way conference parties (one-way parties share a single port). All conference ports must belong to a single resource group. Individual conference ports cannot be specified for use by the host. If a conference port is not reserved, in use, or deactivated (a card is taken out-of-service or a port is deactivated), it is considered available for use in a conference.
When the host issues a command to reserve a conference, the system establishes the conference structure and assigns a number to the conference. The conference structure is the chain of conference ports that is used to bridge the attached line/trunk ports participating in the conference. Reserved conference ports remained allocated to the conference and organized in the conference structure until the conference is torn down. Deleting line/trunk ports from a conference has no effect on reserved conference ports. The conference structure retains its assigned conference number until the conference is torn down.
Commands that specify to start a conference immediately establish the conference structure and attach the indicated line/trunk ports. The host cannot start a conference without specifying the line/trunk ports that represent the conferencing parties. When a party is deleted from a conference, the associated conference port is made available unless it was reserved for the conference before its line/trunk port was added. When the conference is torn down, all affected conference ports are again considered available.
The output level from a conference port to one or more line/trunk ports and the input level to the summation from each line/trunk port can be adjusted by the host. The output level of the conference port can be decreased by 3 dB.
Line/trunk ports provide input to and receive the output from a conference. These ports become parties to a conference when the system receives a host command to start or add to a conference. The host must supply the port address of the line/trunk port when an action is required. There are no conference-related restrictions on line/trunk resource grouping. The conference command does not support hunting of a line or trunk port to add to the conference.
A line/trunk port can become part of a conference under the following conditions:
These conditions allow for the following call scenarios:
While a port is in a conference, the system assigns it an internal COS of C. The port retains its incoming or outgoing characteristics as defined by the COS in the system database. While in the conference, the port remains in the CP_SETUP MState. When a port in CP_STAB or CP_SETUP state is added to a conference, any call disconnect or PSC report bit settings associated with the port are cleared. These bit settings may have been established with a previous Outgoing Port Control ($69) command.
When a conference is started or when a new port is added, the host command must specify the following information for each port:
If one port in a stable call is added to a conference (or the outgoing port is in CP_WANS), the other port in the call is placed into CP_SETUP. The host must take some action on the port left in CP_SETUP.
A line/trunk port is removed from a conference automatically when it goes on hook. The port is marked CP_GARD (depending on card type), then to CP_IDLE. When using a command to remove a line/trunk port from a conference, the host can either force the port to idle or leave it active awaiting further host action.
If a port is deleted from an active conference, the host command must specify the port address and whether to idle the port or leave it active. If idled and the COS is not A, Permanent Signal processing is begun for the port. If the port is to be left active, it goes to CP_SETUP state and remains there until further host action is taken.
When a conference is torn down, the host command must specify the ports that are to remain active. If no port information is included in the command, Permanent Signal processing is begun for all ports in the conference by default, except for those with COS = A.
The input level from the line/trunk into the conference can be adjusted at any point while the port is a two-way party to the conference. The output level from the associated conference port to the line/trunk port can also be adjusted. When a level adjustment is required, the host command must specify the following information for each port:
Fifteen preset adjustments allow the input level from each line/trunk port to be decreased by as much as 15 dB and increased by up to 6 dB.
The system arranges all system resources participating in a conference into a conference structure. A conference structure consists of all conference ports used by a single conference and their associated line/trunk ports. A conference structure can have up to eight conference ports. The system assigns a number to every conference structure when it is set up. The host must reference this number in all subsequent commands affecting a conference.
A two-way party to a conference hears the summation of all other members of the conference, plus its own voice input through the sidetone of the telephone equipment being used. One conference port is used for each two-way party. Figure 2-1 shows the structure for a conference with eight two-way parties. Note that this is the maximum number of two-way parties that can be accommodated by a single conference structure.
Figure 2-2 shows how one-way conference parties share a single conference port. Although these one-way parties also hear their voices through sidetone, it is not input to the conference. Any output adjustment made to the conference port for any one-way party applies to all other one-way parties in the conference. Any number of ports can listen to the output of a single one-way party.
Call processing allocates resources to a conference based on commands from the host. When a resource is allocated, it is linked into a resource chain for the conference. A conference uses two types of resource chaining. The conference has a primary resource chain containing all conference ports involved in the conference. Additional resource chains associate the conference ports with network interface ports. Resource chains for conference structures are illustrated in the example scenarios in "Conferencing Examples." While a resource is linked into a conference's resource chain, it cannot be used for any other conference or call. Call processing determines when a resource can be dropped from a chain and made available.
A resource can be linked into a conference but not actively participating. This is the case when a conference port is reserved for a conference but has no line/trunk port associated with it. A resource is actively participating in a call if a voice path exists (resource actively sending or receiving in-band signaling), the port is sourcing out-of-band supervision signaling, or the port is waiting for out-of-band supervision. A voice path is a logical system connection that allows the transfer of MF digits, DTMF digits, tones, prompts, or voice information. The conferencing examples in "Conferencing Examples," use a voice path diagram to illustrate the voice paths for several conferencing scenarios.
The current links and voice paths for an individual port can be monitored using the system administration Port Display screen described in "Viewing Conferences via System Administration," of this document and the Cisco VCO/4K System Administrator's Guide. System tones cannot be linked because they are a shared resource. A voice path can be established between a tone and a receiver without a link.
Posted: Fri Oct 4 08:46:01 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.