Difference between revisions of "Duplex Conference"
From Zenitel Wiki
(→Hardware configuration) |
(→Hardware configuration) |
||
Line 194: | Line 194: | ||
The hardware for conferencing will initially be an AGA board, where each of the 16 bi-directional channels have 3 subchannels (timeslot selectors, like each subscriber on an ASLT). This means that 3 timeslots can be listened to, and the sum is returned in a 4. timeslot via an on-board loop. The figure is a simplified representation of use of timeslots. | The hardware for conferencing will initially be an AGA board, where each of the 16 bi-directional channels have 3 subchannels (timeslot selectors, like each subscriber on an ASLT). This means that 3 timeslots can be listened to, and the sum is returned in a 4. timeslot via an on-board loop. The figure is a simplified representation of use of timeslots. | ||
− | [[Image: | + | [[Image:Hardware_configuration.jpg ]] |
− | Conference mixers only in Master | + | Conference mixers only used in Master |
Open Duplex participant in master: | Open Duplex participant in master: |
Revision as of 11:22, 19 December 2007
A duplex conference in AlphaCom can have maximum 4 participants.
There are 20 numbered conferences, with directory numbers 8301 to 8320. The number of simultaneous active conferences depends on the resources installed in the exchange. Resources used by the conference are allocated from pools at the time a participant enters a conference.
It is also possible to convert an ordinary two-part conversation to a duplex conversation (new in AMC 10.00). This is actually a “transfer to conference”. The last 5 of the 20 conferences are used for such “ad-hoc” conferences.
Participants in a duplex conference are busy (must disconnect before receiving a conversation). A participant leaves the conference by normal disconnection (C-key or replacing handset).
The core of the duplex conference is audio mixing. Each participant speaker gets the audio mix of the microphone signals from the other participants. This is called a conference bridge.
A station with handset lifted is connected directly to the conference bridge in open(full) duplex. (Same applies if the station is marked as having Acoustic Echo Cancelling).
A station in loudspeaking “handsfree” mode is connected to the conference bridge via a vox-duplex connection. (New in AMC 10.00, earlier versions only supported open duplex with lifted handset).
The duplex conference can have a mix of participants connected in open duplex and vox-duplex. (New in AMC 10.00).
New in AMC 10.00: Stations connected in slave modules can also join a duplex conference. Conferences may have 4 priorities. Conferences with higher priority may snatch resources from lower priority functions. The highest priority override the single subscribers priority in situations like conversation, absent state etc.
Contents
- 1 Joining and leaving conference
- 1.1 Direct entry
- 1.2 Transfer from conversation to “ad-hoc” conference (new in AMC 10.00)
- 1.3 Direct inclusion from within conference
- 1.4 Inclusion by inquiry call form conference (new in AMC 10.00)
- 1.5 Remote setup from station
- 1.6 Remote disconnection from station
- 1.7 Data Protocol messages
- 1.8 Common for setup functions
- 2 Programming options for conference
- 3 Nitty-gritty details
- 4 Limitations
- 5 Installation and technical details
- 6 Issues
Joining and leaving conference
Direct entry
Direct entry to a specific conference: Dial the conference number (83xx).
Transfer from conversation to “ad-hoc” conference (new in AMC 10.00)
Transfer from a two-part conversation: Dial “56” during conversation. An unused “ad-hoc” conference is allocated, and the two stations are transferred to the new conference.
In case of an inquiry call from a parked conversation, all three stations will be transferred to a “ad-hoc” conference. Both ends of the open conversation can initiate the transfer by dialling “56”. This is probably the most natural way to establish a conference.
Care has been taken to ensure that also PNCI calls can be transferred to a ad-hoc conference. (no disconnection message during the transfer)
Direct inclusion from within conference
Expand a conference: A participant in a duplex conference can include other stations into the conference: Dial
- 56 < station number>
or
- 56 <group number>
The dialler immediately goes back to the conference after terminating the dialling.
This is a “raw” setup function. Transfer and absence status of the target stations are ignored.
Inclusion by inquiry call form conference (new in AMC 10.00)
Expand a conference: A participant in a duplex conference can also make an inquiry call to a station, and ask if somebody there want to join. If yes, dial “56” to transfer the inquired station to the conference. The dialling station returns to the conference as well.
If the inquiry was unsuccessful, just pres C, and the dialler returns to the conference.
In summary:
- 2 < station number> 56
With the inquiry method, transfer, private and absence status of the target station is followed.
Remote setup from station
Dial from Idle:
- 74 < station dirno> <conference dirno>
or
- 75 < group number> <conference dirno>
(Requires appropriate ClassOfService privileges.)
Remote disconnection from station
This feature disconnects specified stations from a duplex conference. Dial from idle:
- 74 < participant dirno> 8300
or
- 75 < group number> 8300
This is not a “conference disconnect” function. If the conference has additional members, these will remain in the conference.
Data Protocol messages
Two different messages for forcing stations into a conference:
Dedicated message: $odc, $O_DUPL_CONF, m006F:
- $odc <station-or-group> <conference> [<mode>]
Null value or directory number for “duplex conference off” disconnects the subscriber or group from the conference.
- (<mode> = 2 means “toggle”).
Response is “COMMAND_RESPONSE” or ILLEGAL_PARAM.
New in AMC 10:00: General call message: $call; m0008:
- $call <station> <conference> [<setup-flags>]
The response is COMMAND_RESPONSE. But the response is only transmitted if bit one (“RETURN_ACK”) in the setup-flags is set (append “w1” to the message).
$call also support inclusion of station into a conference in another exchange over AlphaNet.
Identifying a conference:
The entity class ECL_O_DUPL_CONF = 15 is defined for duplex conferences, letter “f” in the “simple linklayer”. So you don’t want to depend on directory numbers, you can send:
- $call N3 NF5
is the equivalent of
- $call L103 L8305
Common for setup functions
For all remote setup variants it applies that a busy subscriber can not be included in the conference if not the conference has the highest priority to force the subscriber idle.
Group setup variants are still limited to 4 group members. If the number of members in the group exceeds the max number of participants in the conference, the first members of the group that are free are included in the conference.
If a group member is busy with high enough priority, he is skipped and the next group member is involved.
Programming options for conference
These options can be set for each duplex conference:
Master member
Per conference one “master” station can be programmed. The semantics is that when the conference master station leaves the conference, the whole conference is taken down.
(The conference master is not automatically included in the conference. The conference disconnect function only applies if the conference master is included in the conference in the first place.)
Priority
The conference priority controls the priority of resource allocations.
If set to the highest (alarm) priority, the conference can snatch resources from other stations/functions. Busy stations will also be disconnected from normal priority functions in order to be included in alarm-priority conference.
low, medium
and high |
The conference is treated like an ordinaru conversation. |
alarm |
|
Nitty-gritty details
If in vox-duplex, lift the handset, the station will go to open duplex (wox-duplex resources are released).
If in open-duplex with handset lifted: replace handset while M-key is pressed, will go to vox duplex, provided wox-duplex resources avaliable.
If open duplex mixer allocation succeeded, but no duplex resources was available, the station starts ringing, and you can enter in open duplex by lifing handset.
If the ”dupl_conf_no_vox” nvram-flag is set: Vox duplex is not allowed. When a station is included into a duplex conference, it will start to ring, and the handset has to be lifted in order to connect to the conference audio. If the handset was lifted in the first place, the station is connected to the conference audio directly. The timeout on the ringing is default 30 seconds, the duration is controlled by the same programming as normal private ringing.
Limitations
The conference does not survive an exchange reset.
Participants in slave modules are only supported for multimodules using AGA boards for interconnection (no support for IP voice interconnection)
Installation and technical details
AGA board and programming
The duplex conference requires proper installation of an AGA board.
All audio mixing takes place in the Master module. At least one AGA board is needed, and some AGA resources must be programmed to “2 Open Duplex Conf Mixer” in the “Board” programming. (Each “port” defined in AlphaPro makes two mixer circuits, each 1/16th of AGA).
Other NVRAM programming
Backwards-compatibility flag (new in AMC 10.00)
The behaviour of the 83xx conferences is changed with the introduction of vox-duplex. If there is a need to enforce the old mode, that is only low speaking mode using handsets, that can be done. Set the system wide nvram flag:
.ex_profile.flags.dupl_conf_no_vox = 1
The autoload value is zero, allowing use of vox duplex. So normally there is no need to change this flag.
This flag is currently not accessible in AlphaPro, the “nvram” command must be used in “TST-console”.
Ad-hoc conference flags (new in AMC 10.00)
Conferences 15 to 20 are by default used for transfer from call to ad-hoc conference. This is controlled by the NVRAM flag
- .ex_profile.dupl_conf_profiles[].anonymous
Prior to AMC 10.00 this flag was unused, and autoloaded to zero for all conferences. With AMC 10.00 the anonymous flag is set to “1” for conferences 15 to 20 during autoload.
This flag is currently not accessible in AlphaPro, the “nvram” command must be used in “TST-console”. Normally there is no need to change this flag. However:
If upgrading from an early X-version of AMC 10.00, you have to either set the anonymous-flags manually, or do a cold-start of the AMC board. Otherwise transfer from call to ad-hoc conference will not work.
Resource usage summary
- --> One ASLT board is needed for each participant in vox-duplex, two scanner resources are needed
- --> A participant in open duplex requires one mixer resource ; 1/16th AGA
- --> A participant in vox duplex, connected in master module requires two mixer resources; 2/16th AGA
- --> A participant in vox duplex, connected in slave module requires one mixer resources in master; 1/16th AGA + one inter-module ring + two duplex resources in slave.
Hardware configuration
The figure shows an example of 4 participants in a conference, using AGA resources to perform the conference mixing.
The hardware for conferencing will initially be an AGA board, where each of the 16 bi-directional channels have 3 subchannels (timeslot selectors, like each subscriber on an ASLT). This means that 3 timeslots can be listened to, and the sum is returned in a 4. timeslot via an on-board loop. The figure is a simplified representation of use of timeslots.
Conference mixers only used in Master
Open Duplex participant in master:
port_in -> ts_in_m ->>> other mixers port_out <- ts_out_m <- mixer(own)
VoiceControled Duplex participant in master:
port_in -> ts_in_p -> fader -> ts_in_m ->>> other mixers ts_in_p -> scan_p port_out <- ts_out_m <- mixer(own) scan_m <- ts_out_m Duplex operating on port_out and fader
Open Duplex participant in slave:
port_in -> ts_in_p -> icch -> ts_in_m ->>> other mixers port_out <- ts_out_p <- icch <- ts_out_m <- mixer(own)
VoiceControled Duplex participant in master:
port_in -> ts_in_p -> icch -> ts_in_m ->>> other mixers ts_in_p -> scan_p port_out <- ts_out_p <- icch <- ts_out_m <- mixer(own) scan_m <- ts_out_m Duplex operating on port_out and fader (in slave)
Issues
Problem that each stations must disconnect from conference individually. With the introduction vox duplex conferencing, unattended stations can easily be included remotely by the “56” feature. These stations can be hung up in conference for long time, after the active participants have disconnected. This locks up resources. The best solution will probably to let stations which has used the “56” features to become “conference master”, so that the conference is automatically disconnected when the master disconnects.
Additional Information
- Default directory numbers: 8300 - 8320
- Both stations connected to ASLT-board and ATLB-board can be participants
- The remote set-up of duplex conference is a toggle feature. You can program a single-touch key with the remote set-up number + the station number + conference number. On the first press of the key, the station is included in an ongoing conference, on second press the station is removed from the conference. It is possible to do this from a station which is already a member of the conference.
Software
- AMC 07.20: open duplex conference implemented.
- AMC 08.00: remote set-up as toggle feature.
- AMC 10.00: Stations can join the duplex conference in loudspeaking "handsfree" mode. Stations connected to slave modules can also join the duplex conference. A two-party conversation can be converted to a duplex conference ad-hoc.