CA2154464C - A method and apparatus for audio teleconferencing a plurality of phone channels - Google Patents

Abstract

An improved system for connecting and processing a plurality of phone users in a teleconference on a common digital bus. The apparatus includes a plurality of digital processing units (DSPs) associated with selective phone lines and in communication with each other. Each DSP determines an activity status for each associated phone line and transmits that status to the other DSPs. The DSPs create and update respective identical "talk-lists" which reflect the active conferees whose voice data is currently being output on the phone channels. The system thus provides scaleable teleconferencing in a real-time configuration without switching between the various signals on the common bus such that each incoming caller or even a plurality of conferences has equal priority.

Description

~- 2~ ~413 4 A METHOD AND APPAR~T~S FOR AUDIO T~T ~ N~ ~:~ENCING
A PL~JRU.ITY OF PHONE r~ r..e BACKGROUND OF THE INVENTION

This invention relates generally to irnprovements in teleco~e-ellcillg, and, in particular, telecol~re,lcillg methods and appaldlus which improve the resiliency and processing of a mnltit~1dP of phone signals.
Telecol~lellcing app~dLus and methods are generally known. Telephone operating co...~ Ps and other private industries have entered this field to address the teleconferencing needs of particular groups or individuals and to improve the m~n~eme~t and control of the teleconference meeting.
A typical conference might include a plurality of individuals who are telephonically co----P~lPd into a rliccllssion by a single operator at a central locality. The teleco~ llce can be rnanaged or ~..,.~.~n~ged and can include a record/playback system to record the discussion and rnake it available over the phone lines for further consideration by the particir~ntc.
Typically teleco~ cing s~Lel ls include that described in U.S. Patent No.
4,303,804, which collects, processes and redistributes ih~llllation b( lweell a plurality of ing telçphon~ lines. Callers co.-.~;le~ to these lines can be grouped into selecte~
c~e,e~ces, or pooled together as subco~e,e,lces, and are processed to associate mpmbers accol.ling to voice energy levels.
DiffirllltiPs persist with many prior art audio tel~-co..ff ~e,l~ing sy~e.lls. Most par~icularly, the available ~y~ ,lls typically pass data signals in and out of the phone lines via control and ~vitcl~ing Ci~ ihr wlRle~ a voice is clipped by the r,.,tw~ . As more and more use~s access the If ~ ~...r ~,~ci~g system, thie ~wi~ g time Lucl~as~s al~ can notice ,t~;c~;~ initial PU1LiOnS of speech. The swi~hi~g also takes away valuable ~ p, time which is ~.1Ui1~ to ~;gJ~ ly iLUp~o~ the quality of the CO"~i os;l~ sig~als UUigOi~g to the Va11OUS pc 50~S in the co~e,-,n~.
Accoldi~lr, it is an object of the invention to ~lo~ide an audio ~1PCO~f~e~Ci~g system which provides for virtual ~roce~ g of every il-~n.. ~g caller, ~,~ lc~o~ g any ~wi~hi~g ~ ui~ed to access or L~ lPi~ data to the various callers.

,~,. p~, ~~ - 2 - ;!~54~

It is another object to provide for improved proces.si~-g of a plurality of audio phone signals data along a bus, wherein every in-~.oming phone rh~nnPl is treated with equal priority and the nurnber of users is operationally scaleable (i.e., without hlcre~sillg processing overload).
It is also an object of the invention to provide irnprovemellL~ in digital signal processing, the delivery and management of h~o~ ation on a plurality of telecol~lencillg rh~nnPls .
These and other objects will become appalellL in the description within.

SUMMARY OF THE INVENTION

The invention thus relates to an audio tPlPph~ nP confer~i~ app~alus and mPth~
which fe~lule~ a plurality of digital signal processi.-g units (DSPs) and a co.. ~l- bus for carrying voice digital data along a plurality of phone ch~nnPlc. Each DSP is coupled to the common bus and associated with particular phone ~ h~nnPlc therein. The DSPs lespo~d to the data on each ~CSoci~t~d ~cGlll~ng phone c~ and gel~,ale a status signal le~re se~ g the particular status of that phone ch~nnpl. These status signals are L~sf~ d along the COI~ f n bus for access by other DSPs.
In turn, each DSP responds to status signals received from the others to ge~,dte an output telecol~lence signal as a function of all or some of the incoming phone channels. This output signal can repleselll, for example, a digital mix of the current "talkers" on the incoll~illg phone ch~nnPlc the output signal is L~ ed by each DSP along the common bus to the ~ccoci~tPd lictening phone.

In another aspect, the DSPs include an energy detection elemPnt for gell~,aling the afole,lle,l~ioned status signal to in-lic~te wh~Lller there is a selectPd activity level, e.g., taLll;ing, on the a_sociated in~o~ g phone ch~nnPl. This status signal can be clete....i~-~d, in another aspect, by quallLirymg the energy level of the data associated in each inr.orning phone çh~nnPl.
This energy level can also be de~ellllined, in yet another aspect, by quantifying a value iepie s~ tive of the difference between the incoming channel data energy level and the average energy level in the output data signal, wherein this dirrel, nce is greater than a threshold energy value.

~.~
.,,, ~

In another aspect, the DSP inrlu(les a taLtc-list element which responds to status signals on the bus. The talk-list means, in another aspect, can gent;la~e and store a list represPntin~
active phone cll~nnplc whose incoming voice data is selected for output to the colll;.~ es.
The DSPs are ~ldnged to ge.leldte their l~eclive taLt~-lists idPnt;ral and subst~nti~lly cim~ Po..sly to one another.

In yet another aspect, the DSP taLIc-list ehPmPnt selects for leplese.lL~Lion in the "taLk-list" phone ch~nnPlc which have a selpcte~l energy level (i.e., an energy level which e~ree~S
the average energy level in the output data signals).
~ still another aspect, the DSPs respond the control parameters for at least initi~li7in~
a telPcQnff .~.lce among a plurality of phone rh~nnPlc. A host processor is coupled to the DSPs to ge .~ and store for access those control ~ t~ ~. By this ~ , the DSPs can m~int~in the trlPco~r e~ci~g filnrhon~lly lx,h._en at least sPlçctPr1 phone rh~nnPlc in the eve~nt of a selPcte~l fault by the host pl~cessor (i.e., the host plocessor goes "downn).

BRIEF DESC~ ON OF THE DRAWINGS

A more complete ~ n~ of the ~ Lion may be obtained by l~L.~nce to the d~awi~a in which:
Figure 1 depicts a tPlecQ.~r .c.~ci~ appalaLus accoldillg to the invention; and Figure 2 depicts a telecol~ c~ m-offin~l accor~hlg to the invention.

DETAILED DESCRIPTION OF THE IlLUSTRATtu EMBODIMENT

Figure 1 depicts a signal ~oce~-C;~-~, Al~p~ ll5 10 for use in a system for l~ leco~L._~cu~ a plurality of phone .~ c (e.g., T1 line 12), where that system in~ PS a co.. ~ bus 14 for Ca~ g digital signals I~JL~,~ It;~ data ;~ ;Q~ from and olltgoiug to those of phone l~h~ rlc. A further ~p~: l;o-- of these allu~ S, their .~t~ ;Oi- and operationmaybe~ byl.,fe.~ eto Sections 1-3 of Appendix A and Appendix B, filed herewith.

The a~pdld~7 10 inrlu-l~s a plurality of digital signal procescil~ (DSP) el~ 16a -16c, each coupled to the co~oll bus 14 and associated with at least one phone rh~nn~l, for (i) responding to illco~i~g data on each associated phone rh~-"~l to generate a signal rep-ese"ti3ti~e of a status of that phone ch~nn~1, and (ii) ~. A".~fe ~ g the status signal to the cornmon bus. Each of the DSP's 16a - 16c further inrhldes functionality for (i) responding to the status signals associa~d with the plural phone rh~nn~lc to gel~e.dL~ for each phone ch~nn~l associated with each DSP an output data signal as a function of at least sel~cte~ ones of the hlco~ lg data signals, and (ii) "~I"~r~ g the output data signal on the CO~ OIl bus to the associated phone ch~nn~l A further a~lc~,iation of these structures, t_eir ill~.a~;Lion and operation may be ~tt~in~ by reference to Appendices B-D, file~ herewith.

Each DSP 16a - 16c in~lu~es energy ~etection functionality 18a - 18c for gene.dLing the status signal to be in~ tive of a selected activity level on the associated incoming phone ch~nn~l. That energy detection functionality generates the statussignal as a function of an energy level r~l~s~ by data in the associated incol l~lg phone ch~nnPI and, more particularly, as in~ tive of a value r~lY s~ e of the dirr~ cebeLween the h-rr..,.i.,g data energy level and the average energy in the output data signal being greater than a threshold energy value. A filrther a~ ei~l;o.~ of these ~Lluc~ul~es, their ~tc~d~n and operation may be ~tt~inpd by lefe~ to Sections g-16 of Appen~ix B filed herewith.
The DSP's 16a - 16c include ~talk-list" filnrtion~lity 20a - 20c re~.~o~si-_ to the status signals to ge~ àt~_ the r e s p e c t i v e output data signals as a ~ln~ tion of in~ data on a sel~t~ .. ke ~ of the phone ch~l~flrlc at the .sel~ level. The tall~-list r~ .Ality 20a - 20c gf, ~ 5 and stores a talk-list l~les~ g the phone ch~n~tc that have the s~le~ tt~
acLivily level, e.g.. phone ~ h~""~l5 that have an energy dirI; ~ence ~ en the inro...;.~ data energy level and the average energy in the output data signal that e~ c~s a Aesi~n~t~l value, or phone ch~f..~lc having an ;.-~c,~..;.~g data energy level that e~cce~c an average ;n~o...;.~ data energy level of the ch~nnl~lC l~e;~-ltl~1 by current talk list. These tallc-lists gf ~ by each DSP are ~.~ t~i i.d~ lly and S~lbal ~ y sim~ ..cl,~ tvith each othcr. A fi~rtheral,~l. ci~;o~ of these ahu~.;lu~_S, their ;- ~ I;on and O~e~aLiOn rnay be ~ ;nfA by ref.,,c~lce to Section 9 of Appendix B filed herewith.

The DSP's are ~ onsive to control ~al~ele~s for at least initi~li7ing t~lçcQ~lr~L~ cing between the plurality of phone rh~nnPlc A host processor, that is coupled to the DSP's, generates and stores such that control pararneters for access by the DSP's, which are capable of m~int~ining telecollÇelellcillg between at least s$1ected ones of the rh~nnP1c in the event of fault by the host ~l.,cessor. A further a~lccialion of these structures, their interaction and operationrnaybe~tt~inedbylercie~ceto Section 4.10 of Appendix A, Appendices B-C, Section 3 of Appendix F, and Appendix I, filed herewith.

A rnPthod for teleconfelencillg a plurality of phone ch~nnels according to the invention is shown in Figure 2. The method inrl~ s the steps of (i) coupling a plurality of digital signal proc~Ccin~ elPm~ntc (DSP's) to a common bus (step 22), such that each of the DSP's is ~csoci~ted with at least one phone ch~nnPl, and every DSP receives data from all illCo~ g phone rh~nn~ol.c; (ii) responding to incoming data on each associated phone ch~nnPI to gelle~dtc a sig,nal lcpr~se..l~;ve of a status of that phone ch~nn~l (step 24); (iii) Ll~fcllmg that status signal to each DSP (step 26); (iv) responding to the status signals associated with the plural ch~nn~lc to ge~ c, for each channel, an output data signal as a function of at least selected ones of the incoming data signals (step 28), and (v) llal~fclling those output data signals on the common bus to the associated phone ch~nnelc (step 30). A further appreciation of these structures, their ;..leldc~;on and operation may be ~tt~inrd by lcf~rellce to A p p e n d i c e s B - D, f i 1 ed heréwi th . - -Des~. il.~ above is a plefell~d system for use in a teleconfe~ cillg system m.oeting theobjects hereof. Those skilled in the art will ap~l~,cialc that other ~lcllls, i~col~olalions, mnrlifir~tionc, tl~letiorC or additions hereto _ay fall within the scope of the invention, in which we claim:

;~ ~

Table of Contents For Appendices Appendix A - Digital Conferencing Bridge Product Specification Appendix B - Digitai Signal Processor Hardware Specification Appendix C - Digital Conferencing Bridge Hardware Specification Appendix D - Digital Signal Processor Card Design Specification Appendix E - Host Software Specification Appendix F - Digital Signal Processor - Host Interface Design Specification Appendix G - Command Processor Design Specification Appendix H - Event Processor Design Specification Appendix I - Initialization of the Digital Conferencing Bridge Appendix J - Digital Conferencing Bridge MVIP Bus APPPENDIX A
1. Objective The objective of this Product Specification is to define the external functions,features, interfaces, and displays that the customer sees in the completed first version of the Digital Conferencing Bridge (DCB) product.

2. General Product Goals The first DCB product release is a replacement of the System 60 (a "digital MOPS").
The MOPS operator interface is very similar to the current System 60 with changes where necessary to accommodate DCB features such as more lines and more conferences. Some of the older, less used features of the current bridge are dropped in the DCB.
The DCB has a flexible digital hardware and software base to allow future development of enhancements such as an unattended conferencing bridge with remote moderator features, advanced reservation capability, voice and data bridging for groupware teleconferencing, video and ISDN.

3. Hardware The hardware architecture is based on a PC/AT. The DCB supports a maximum of 96 conferencing channels, 8 operator channels, 3 record\playback, 1 music, 2 Link Lines, and 8 annunciators (7 incoming messages, 1 outgoing). The cards needed to conduct a 96 port conference include: 2 Dual T1 Interface Boards or 4 Single T1 Interface Boards, 4 DSP
Conferencing Boards, 1 Analog Interface Board, and 1 Multiple Serial Port Board. Future systems may support tape backup, lan interface, EGA\VGA video, etc. The DCB can be configured as a 24, 48, 72, or 96 channel conferencing bridge. Each configuration is fully contained in a rack mountable PC chassis or optional tabletop chassis. System maintenance and diagnostics are done via an ASCII terminal. An optional Hewlett Packard DeskJet printer is available for operator or system printing.
3.1 External Interfaces The external DCB interfaces include T1 interfaces, printer ports, remote m~intçn~nce port, analog interface, serial I/O, and alarrns. Each of these interfaces is described below.
3.1.1. T1 Interface All user voice and data enters the system via the T1 channels. The T1 connector is located on the back of the PC and consists of an RJ45 connector for each T1 interface (up to 4). The standard interface is DSX-1. Up to 24 voice channels can be carried on one T1 circuit. The system is designed to allow enhancement to European El lines in the future (up to 3 E1 circuits, 30 voice channels each).

Analog Conferencing - The DCB can be used to conference analog lines however external channel banks, not available from MultiLink, are required for this application.
3.1.2. Printer Ports A Centronics parallel printer port is located on the back of the chassis for use in general system printing of CDRs, Dialing Lists, Logs, Configurations, Network Statistics, Operator Printouts, and Alarm statistics. Operator initiated printouts, such as polling results, may be redirected to this printer.
3.1.3. Remote Maintenance port An internal modem is provided for remote maintenance access. The modem supports 9600 mnpS bps async communication. This port can be used for maintenance or remote ~mini~trator concurrently with the local console.
3.1.4. Additional Administrator Terminal An additional ASCII terminal may be connected to the comO port located on the back of the system. This port can be used for ~-lmini~trator and m~inten~nce use. Operator screens can be displayed from this terminal however no audio comm~n-l~ (Select Conference, Access, etc.) can be performed.
3.1.5. Analog Interface The DCB utilizes a 24 channel 2 wire analog interface board, contained in the PCchassis, to interface the various analog I\O, such as operators, music, record\playback, and link lines, into the system. The analog board interface is on the back of the chassis and each channel can be separately broken out from the cable harness. The 8 local operators are supported with 16 analog channels (2 per operator). The music input requires 1 analog channel, record/playback requires 3 analog channels and 2 analog channels are used for the 2 Link Lines supported by the DCB.
3.1.6. SerialI\O
Seriai I\O to local and remote operator displays is implernentecl via an 8 port serial I/O card contained in the DCB. ASCII tennin~l~ interface via RS232 sign~lin~ on RS232 connectors.
3.1.7. Local Operators There are a maximum of 8 local operator displays supported in the DCB. Local operator displays are connected to ASCII terminals via the 8 port serial I/O card. Each operator ASCII terminal may have an optional serial printer, connected to the printer port on the rear of the terrninal, for operator initiated printing of dialing lists and polling results.
The operator audio interface to the DCB is accomplished through the 24 channel 2wire analog card which is contained in the DCB. R Jl l connectors are used to connect ~ i~

operator audio to the DCB. Headsets, with volurne controls, are supplied at the operator stations.
3.1.8. Remote Operators - Leased I~ine Operation Leased line operation requires 1 4-wire leased line for the data connection. Theoperator audio path is established by calling into the one of the 96 user channel. Operators must be configured as remote and a user channel must be specified as a remote operator channel. The data connection requires 2 leased line extt rn~l modems (9600 bps. rnnpS), 1 local and 1 remote. The local modem is connected to the serial I/O card and leased line at the DCB and the remote modem connects to the operator terrninal and leased line at the remote site. Any or all operators stations may be configured for remote leased line operation. Upon configuring an operator as remote, the local operator audio path becomes inactive. No audio comrnands (Select Conference, Access, etc.) can be performed until the remote audio path has been established. No headset is supplied for remote configurations.
3.1.9. Remote Operators - Dial Up Operation Remote dial up operation requires 2 external dial up modems (9600 bps. rnnpS) for each remote operator dial up station. The selected operator termin~l(s) are substituted with modems at the DCB and each remote operator terminal is connected to a modem. Theremote operator audio is established by calling into one of the 96 ports on the DCB which is configured as a remote operator audio path. Any or all of the 8 local operators may be configured as remote dial up operators. Upon configuring an operator as remote, the local operator audio path becomes inactive. No audio commands (Select Conference, Access, etc.) can be performed until the remote audio path has been established. No headset is supplied for remote configurations.
3.1.10. MusicInput The DCB inputs using 1 of the 24 channels of the analog board. An RJ11 connectoris used to connect the music into the DCB.
....
3.1.11. Record~Playback Conference recording\playback is done via the 24 c~nnçl analog board. There are 3 record/playback channels available. Rll 1 connectors are used to conllect the Ç~tPTI15~1 recorders to the DCB.
3.1.12. TinkLines The Linking together of DCBs is supported via the 24 channel analog board. The DCB supports 2 4-wire Linlc Lines. Each Link Line uses 2 charmels of the analog board, one pair for transmit and the other pair for receive, for linking. RJI l connectors are used as the linking interface from DCB to DCB or DCB to analog bridge.
,JS
Y:''' p~

~- 1o ~ 4 ~ ~
3.1.13. External Alarms A DB 15 connector is used as the external alarm interface from the DCB. It provides 4 contact closures in the event of an alarrn condition -- major audible, major visual, minor audible, minor visual. The closure or opening of contacts can be monitored by an external device to signal network personnel of major/minor alarIns. Alarm conditions include:
So~vare Errors, T1 failures, Dead-man timer, loss of power. The contact ratings for the alarrns are 100v, 1 A. An alarm cutoffswitch is available which opens the major and/or minor audible alarms on request. This switch is located on the front of the unit. The CPU
may be reset remotely.
3.2 Power 90-230 VAC external switch, user selectable, 47-63 hz power supply or a 48 VDC
power supply. Suitable for use in central offices, Europe and Japan.
3.3 Environmental Specif;cations The DCB is designed for office or equipment room use. It is not designed to be installed in Central Office locations requiring Bellcore CO certification.
Temperature: 0-40 degree C
Relative Humidity: 10% - 90% non condensing 3.4. Controls 3.4.1. Main Unit Power on/off - located on front of the unit. Key Required.
Reset - located on front of the unit. Key Required.
Audible Alarm Cutoff - located on front of the unit. Key Required.
3.4.2. Operator Station Wyse 60 (or sirnilar) controls and setup menus.
A volume control on the h.o~ et 3.5. Displays 3.5.1. M ain U ~it Power Supply Status - +5v, -5v, +12v, -12v green LED for each.
Hard Disk activity - Green LED.
CPU Status - Green LED.
Major Alarrn - Yellow LED.
Minor Alarm - Yellow LED.
3.5.2. Operator Station Wyse 60 display. For the function, refer to MMI under the software description.

. .

3.6. Packa~in~
The paek~ging for the DCB main unit is a 19" rack mountable PC chassis. An optional cabinet is available for stand alone systems. Wyse 60 terminals, headsets, and optional HP Deskjet printer are also part of the system. MultiLink logos are used on the termin~l~, PC chassis, optional cabinet"ulhltels, and headsets.
3.7. Internal Specification Hi~hli~hts 3.8. Options Port capacity - up to 96 total conferencing channels configurable in 24 port increments.
Operator stations - 2 per 24 ports installed, up to a maximum of 8 total operator stations with each separately configurable as local, remote leased line, or remote dial up.
Administrator Terminal - 1 t~rmin~l in addition to the 8 operator termin~l~ may be connected to the comO port located on the back of the system for ~lmini~trator and m~inten~nce use.
Link lines - 1 per 24 ports installed, up to a maximum of 2 link lines are available.
Record\Playback - 1 per 24 ports installed, up to a maximum of 3 record\playback lines are available.
Annunciators - 2 per 24 ports installed, up to a maximum of 8 annunciators are available.
4. Software The multi-user bridge operating system and digital signal processing software come with the basic system. A relational c~t~b~e is not needed in the basic system because the functionality is basic System 60. All local and remote CRTs are simple async/ASCII
termin~l~ or user supplied PCs with ASCII t~rmin~l emulation. No windows or mice are used. The Man-Machine Interface software is designed to allow it to operate in the future with X windows and a mouse. It is a goal to m~int~in as much of the look and feel of System 60 to minimi7~ the learning time of a person f~mili~r with the System 60. The software supports 96 conr~.e,lcillg l~h~nn~ l~, 8 operator rh~nnPl~ (local or remote), 1 music input, which can be placed into any and all conferences simultaneously, 3 record\playback ch~nnel~, and 2 link lines. Up to 48 simultaneous interactive conr~,.ences can be held on the bridge.
System configurations, and dialing lists are stored on the hard disk.

- - 12 - ~ 4 4.1. System Features Digitized Audio Messages Programmable Operator t~rrnin~l bit Rate Port count / 2 Simultaneous Conferences Programmable conference Tones on Entry/Exit DTMF Dialing-direct, speed dial and blastup Touch Tone into conference minimi7~A
Call closed transaction log files (CDRs) Hot reboot- O/S reboot without losing conference Linking multiple systems ("link lines") ~
4.1.2 Terminal Accessible Features There are five types of users:
1. The ordinary conferee (user) using a telephone with touch tone keypad.
2. A moderator using a touch-tone telephone. He has the capabilities of an ordinary user plus some special privileges.
3. An operator using a CRT locally or remotely to run a conference.
4. A system ~flmini~trator at a local or remote CRT.

5. M~intt~n~nce personnel at a local or remote CRT or computer.
4.2. Man-Machine Interfaces There are two man-machine interfaces:
1) A normal telephone h~n~lset with DTMF keyboard is used by the conferee and the moderator. The user responds by typing numbers on his telephone keypad.
2) An ASCII terminal or a PC with ASCII terminal emulation is used by the Operator, the System Administrator and Maintenance personnel.
4.2.1. Conferee MMI
When the bridge answers an incoming call a message is played to the caller.
Incoming calls may be set to not hear a message when the bridge answers the call. When the call enters the DCB and has passed through the annunciator state the caller is then placed into the ENTER conference, where music is played, and remains there until an operator accesses the caller.
Each of the 48 conferences may be configured to generate a tone to other conferees when a new caller is added to the conference (Entry Tone). This tone is heard, if enabled, by all ch~nnel~ in the conference.
Each of the 48 conferences may also be configured to generate a tone when a caller disconnects from a conference (Exit Tone). This tone is heard by all rem~ining conferees.
The system can be configured to generate a 2 beep DTMF acknowledge tone to each caller that enters a valid DTMF digit. Valid DTMF digits include: DTMF '0' - Help Request, 1" ~

- _ 1 3 - ~ 4 DTMF 'l' - Add to Q&A question queue, DTMF '#' - remove from Q&A question queue, and DTMF 'l' - '9' while in polling.
4.2.2. Moderator-mollitoring via telephone MMI
Conference moderator(s) obtain all the conferee MMI described above with some added features. When a conference is lectured only moderators can be heard by other conferees. If Conference Security is enabled the moderator may secure the conference (i.e.
lock out the operators) by pressing a DTMF '7'. Upon securing a conference the moderator hears a 2 beep tone informing them the conference is secure. Conferences can be unsecured by pressing a DTMF '7' upon which a 3 beep tone is heard by the moderator and the operators can now move into the conference.
4.2.3. Sign-In MMI
Operator, Administrator, and Maintenance screens are all accessible from any terminal. All terminals have a Sign-In display and the proper sign-in name and password must be entered to gain access to the system. When entering the password '~'s are displayed in place of the characters entered to m~int~in security. Valid sign-ins can be entered from any t~rmin~l Operator sign-ins have access to only the operator screen. Administrator sign-ins have access to the ~lmini~trator and operator screens and m~int~n~nce sign-ins have access to maintenance, a(1mini~trator, and operator screens. The default sign-ins are:
Operator Screen: Sign-InName - oper Password - abcl23 Administrator Screen: Sign-In Name - admin Password - abcl23 Maintenance Screen: Sign-In Name - maint Password - abcl23 The system can save hundreds of different sign-ins to the hard disk and these are created and deleted via the ~-lmini~trator menu. When a termin~l is powered on the screen displays the sign-in screen, shown below. The window at the top of the screen displays messages from the system. The last 8 messages received are displayed.
Exiting from either the operator, ~lmini~trator, or m~inten~nse screens brings up the sign-in screen. If power is turned off when an operator, ~mini~trator, or m~intçn~nce screen is up, the systëm automatically exits the current screen and, when power is restored, the sign-in screen is displayed.
4.2.4. Operator MMI
The DCB Operator controls and displays are intçnded to perform the same functions in a f~nnili~r manner to the System 60. Some enhancements are necessary becaL~se the DCB
has more lines and more conferences. The operator stations each consist of a dedicated terminal and audio path. Operator display #l is dedicated to operator audio port #l on the ~nalog interface board and so on.
Logging into the system correctly ~nd entering the proper password clears the screen and screen #6, summary screen, is displayed. When the session is finished the operator may log out of the system by executing the "Exit" comm~n-l under the "Options" submenu.
Powering down the t~nnin~l automatically executes the logout procedure as does a modem disconnection in the case of remote operators. Operators logging out of the system return the display to its initial state, i.e. any accessed lines are released, any command lines being built are aborted, and the Main menu is displayed.
4.2.4.1. Screen Displays The DCB supports a total of 8 operator stations running independent conference screen displays. The screen displays vary the number of channels displayed, the number of lines per display, and whether or not the conferee name is displayed. Each screen display is divided into three sections; 1>. Line Status Area - This displays information about all lines in the bridge. 2>. Conference Status Area - This displays information about all the conferences on the bridge. 3>. Operator Status Area - This displays operator information.

4.2.4.1.1. LineStatus The Line Status area is the same for each screen (line detail, surnmary, etc.). The surnmary screen, however, does not display the line name. The display forrnat for each line ~S:
"*01-C01 LS AG NAME"
* - Talk indicator, displays current talker.
01 - Line number.
C01- Conference number.
LS - Line Status. Can be any of the following:
- DC - Disconnect. Any line that has disconnected from the DCB is displayed in reverse video with 'DC' in the line status field. The conference the line was in before it disconnected is also displayed as is the name of the co~ e.
MO - Moderator. Indicates if the line is the moderator of the conference. This is set from the 'Access' or 'Line' menu.
MU - Mute. Indicates if the line is muted. This is set from the 'Access' or 'Line' menu.
FL - Fault Line. Indicates if the line is faulted. Faulting a line is done from the 'Access' or 'Line' menu.
OS - Out of Service. Indicates a line has been taken out of service by he system.
AG - Automatic Gain. Indicates Automatic Gain Control is turned on for the specifled line. Gain is set through the 'Access' or 'Line' menu.
NAME - Displays the name associated with the line. Up to twenty (20) characters.

- 15 ~ 5 4 ~ ~ 4 4.2.4.1.2. Conference Status The conference status area of the screen displays all pertinent conference information.
This includes total participants, conference name, current speaker, etc. The top of the conference status area displays a header and under each header item is the conference information pertaining to that item. The following describes all the conference status information.
"C TP NAME SP MLRPSTL"
C - Conference Number (01-48).
TP - Total Participants in conference.
NAME - Operator assigned conference name. If Display Minutes per conference comm~n-l is issued the 'NAME' header is changed to 'MINS' and the minutes are displayed. The minutes are cleared and the names displayed if a refresh comm~n~l is issued. Up to 12 characters.
SP - Current speaker in conference.
M - Music. An 'M' is displayed if music is in the conference. Nothing is displayed if music is not in the conference.
L - Conference Lecture. An 'L' is displayed if the conference is lectured else nothing is displayed.
R - Record Conference. The record/playback channel in the conference is displayed (1 - 3) if the conference is being recorded. If there is no record channel in the conference nothing is displayed.
P - Playback Conference. The record/playback channel in the conference is displayed (1 - 3) if the conference is being played to. If there is no playback channel in the conference nothing is displayed.
S - Conference Security. If the operator turns on security an 'S' is displayed. If a moderator activates the security feature the 'S' is reverse video. If the security feature is turned off nothing is displayed.
T - Conference Tone. If the Entry tone is turned on for the col~lellce an 'E' isdisplayed. If the exit tone is turned on an 'X' is displayed. If both entry and exit tones are turned on a 'B' is displayed. If neither entry or exit tones are turned on nothing is displayed.
L - Link Channel. Displays which link channel (1 or 2) is ~ clllly in the conference.
If there is no link channel in the conr~lence nothing is displayed.
4.2.4.1.3. O~erator Status The operator status area of the screen displays information concellling available lines, number of disconnects, etc. The definitions of all the operator status items are:
AVL - Number of unused lines available on the system. Not including disconnects.
DC - Number of disconnects on the system.
- ~
.,, - 16 - ~ ~ ~ 44 ~ 4 ENT - Number of lines in the 'ENTER' conference.
FLT - Number of lines faulted.
HLP - Number of lines or conferences requesting help.
Q&A - Nurnber of callers in the Q&A queue. Only if running a Q&A session.
PLL - Number of callers that have responded to a poll. Only if running a polling session.
OPR - The conference the operator is eullell~ly in.
TLK - Tells the operator whether or not they can be heard by conferees. (on or off).
4.2.4.1.4. OperatorScreens Operators can select l of 7 differént screen displays. Selecting screens is done by entering the appropriate screen number at any menu.

4.2.4.2. Command Menu The operator interface so~ware supports up to six simultaneous operators. Each operator has access to all commands. The DCB product supports a softkey operator interface based upon the culTent System 60 product. Comm~n(l~ may be accessed tllrough the menu structure. The command options are displayed at the bottom of the operator screen. Upon the implementation of a comm~n-l the Linx prompts the operator for the necessaryinformation (i.e. line nurnbers, conference numbers, etc.). All comm~nclc may be run or submenus displayed by moving the cursor to the desired selection and pressing return or by entering the first letter, or capitalized letter, of the item. If a comm~nr~ (Italics) is selected the operator is prompted for the information necessary to perform the comm~ntl, or the command is simply run if no information is required. If a submenu (Bold) is selected the options under that submenu are displayed. The 'ESC' key aborts any comm ~n(l in progress or moves the operator to the MAIN menu. A line editor is present and allows operators to insert and delete characters on the comm~n-~ line using the le~L and right alTow keys, the del key, and the backspace key.

MAIN: Access Conference Display En~er Fastdial Help Line Options Purge Refresh Set Transfer ACCESS: Dial Fault Gain Hangup Moderator mUte lVame Release Transfer COI~FEREI~CE: Clear_all Entry tone Hangup Lecture Name Playback pOlling Q&A
Record Security eXit_Jone ~. ~

- 1 7 - ~ ~ ~ 4 4 ~ ~
POLLI~G: Clear Help mUte print_AII print_Summary Release Tag_digit Q~: Clear Gain reDraw Resume DISPLAY: aNswer Calls Gain Line_connect_times Minutes~er_conference Operator_status Show_conferences Total_line_times FASTDIAL: Blastup Create_list Dial dUplicate Modify Print Remove_list MODIFY: ,4dd Change Delete LINE: Fault Gain Hangup Moderator MUte Name OPTIONS: Annunciator Chat Exit Scan ANNUNClATOR: Play~ack Record PURGE: Call_counts Disconnects Minutes~er_conference Total_times SET: ~ighttime Scan_time TRANSFER: Conferees Link_lines There are default cornmands which are not displayed in the command menu. These comm~n(l~ are used to turn on operator talk, change operator displays, and select conferences.
These comm~ntls consist of:

Operator Talk --- sp~ceb~l or dash (-) Conference Group Select --- F13 - F16 F13 = Col~le.lce Group 01 - 12 F14 = Col~,,nce Group 13 - 24 F15 = Col~nce Group 25 - 36 F16 = Col~nce Group 37 - 48 Conference Select 01 - 12--Fl - F12 Conference Select 15 - 24--F1 - F12 Conference Select 25-36--Fl - F12 Conference Select 3748--F1 - F12 Screen Displays--0 - 6 The default comm~nrls work from any menu. The Operator Talk command allows the operator to speak to a conference. The Conference Group Select commands select which ~.
, ~ .

group of conferences the system displays and which conferences the operator can move to using function keys Fl - Fl2. The Conference Select keys move the operator and the accessed line, if a line is accessed, to the specified conference. The Screen Displays are defined in the next section of this document.
4.2.4.3. Command Definitions 4.2.4.3.1 Main Menu Commands Access Access is a dual function command. If an operator is accessed to a line the ACCESS
submenu is displayed. If an operator is not accessed to a line the system prompts:

ACCESS
~line>-The operator may enter a line nurnber (1-96) and be moved automatically to the access menu. If a remote operator is to be accessed entering a Ol - 08 accomplishes this.
The operator cannot move into the ACCESS submenu without being accessed to a line. If a <return> is entered with no line number at the command prompt the Linx finds a free line, accesses that line to the operator and moves to the ACCESS submenu. If a line is active (i.e.
in a conference) the Linx responds with:

Access Line xx Conference #yy ARE YOU SURE (YIN):

Entering a 'Y' accesses the line. An 'N' or 'ESC' aborts the command. Any other key has no effect. If a line accessed cannot be viewed by the opera~or because of the operator screen being displayed the system automatically switches to a similar display which supports the viewing of the line.
....
Conference This item displays the CONFERENCE submenu.
-Display This item displays the DISPLAY submenu.

Enter Enter is a command which automatically accesses the operator that initiated the command to the next line in the ~ENr conference. A line is moved into the ~ENT' conference ~ ~ 9 ~ 4 by calling into the bridge. Upon the operator being accessed to a line using the 'Enter'command the ACCESS submenu is displayed.

Fastdial This item displays the FASTDIAL submenu.

Help Help is a command which either:
a). Moves the operator to the conference that has requested help.
b). Accesses the line that requested help to the operator which initiated the help comm:~n(l and then displays the ACCESS submenu.

The two different modes of help may be set in the configuration menu. The help requests can either be by conference or by individual line. When conference help is requested the apployL;ate conference number in the conference status area of the display is reverse video. When individual help is requested the appropriate line number in the line status area of the display is reverse video. When conference help is selected and a muted line requests help, the line is placed into the help queue, not the conference.

Lme This item displays the LINE submenu.

Music This command places music into a conference. Upon initiating this command the Linx prompts:

MUSIC
<conf#>-.....
The operator may then enter the desired conference. If Music is presently in theconference then it is removed. If music is not in the conference then it is added. Upon adding music to a conference the conference status window is updated displaying an 'M' in the location corresponding to the a~ .;ate col~ere~lce and all the lines in the conference are muted.

Options This item displays the OPTIO~S submenu.

,,~

Purge This item displays the PURGE submenu.

Refresh This command clears the entire screen and rewrites it.

Set This item displays the SET submenu.

Transfer This item displays the TRANSFER submenu.
4.2.4.3.2 Access Submenu Definitions Dial This command allows the operator to dial a telephone number on the line accessed. A
name may also be entered. The system prompts:

DIAL
<name>~number>-A telephone nurnber of up to 40 digits in length may be entered along with a name of up to 20 characters~ The '#' and '*' digits may be dialed simply by ~ntering them from the keyboard. A dial pause can be issued by entering a 'space' between digits.

Fault This comm~n(l allows the operator to take a line out of service. Upon faulting a line the Line status area of the display reflects the new status. The fault command under the line submenu is used to unfault faulted lines.
.
Gain This cornrnand turns on the automatic gain feature for the accessed line. When on, the line is aulo~ ically given gain if the input level received from the line is det~ c(l to be low. The m~hl~ l arnount of gain which can be given to a line is 10 dB. If the line currently does not have automatic gain then the gain is turned on. If automatic gain is currently on then it is turned off.

Hangup This cornmand hangs up the accessed line from the system.

P~

- 21 - 2 ~ ~ ~ 4 ~ ~ -Moderator This command flags the accessed line as a moderator and updates the line status area accordingly. If the line is currently a moderator then the moderator flag is turned off. If the line is not a moderator then the moderator flag is turned on.

mUte This command allows the operator to mute the accessed line. If the line is currently muted then it is unmuted. If the line is not muted then it is muted.

Name This command allows the operat~or to assign a name to the accessed line. The system prompts:

NAME
<name>-The name may be up to t~,venty (20) characters in length and is displayed in the line status area.

Release This command releases the accessed line from the operator and places it back into the conference from which it was accessed~ If the line was previously inactive or faulted it is disconnected from the system~

Transfer This command allows the operator to transfer the accessed line to another port~ The system prompts:

TRANSFER ~
<number/extension>-The system then flash hooks the line and dials the specified digits. The line is then disconnected from the operator and the operator is moved back to its previous conference.
This feature only works if the system is conntocted to a switch or PBX which ~up~ol ~ call transfers.

4.2.4.3.3 Conference Submenu Definitions Clear all This command turns all conference options off and removes any peripheral channels from the conference. Upon initiating the comm~nd the Linx prompts:

CLEAR ALL
<conf(s)>-The operator may then enter the desired conference(s). All conference options are turned off and any record/playback or link lines are removed from the conference. Upon clearing a conference, the conference status window is updated to reflect the change.
Entry_tone This command toggles the entry tone heard by conferees as they enter a conference.
Upon initiating the comm~nd the Linx ~ lpt~:

ENTRY TONE
<conf(s)>-The operator may then enter the desired conference(s). If the entry tone is presently turned on for a conference then it is turned of~ If the entry tone is presently off then it is turned on. Upon turning on or off the entry tone the conference status window is updated to reflect the change.

Hangup This command hangs up all conferees in the conference which is specified in the comm~nd Upon initiating the comm~ncl the system plol;lpl~:

HANGUP
<conf#>: - -After .ont~nng a conference number the system plon HANGUP CONFERENCE #XXARE YOU SURE (Y/N):
Entering '~ hangs up the conference. Entering ~' or 'ESC' brings the operator back to the Main Menu.

4 ~ ~
Lecture This comm~n~ allows the operator to lecture an entire conference. Only lines flagged as moderators are able to be heard by other conferees. The command prompt is:

LECTURE
<conf#>-The specified conference is then lectured and this is displayed in the conference status window. The lines in the lectured conference display an 'MU' in the line status area to show the lines cannot add speech to the conference.

Name This command allows the operator to assign a name to a particular conference andhave the name displayed in the conference status window. The system prompts:

NAME
<conf#><name>-The entered name may be up to 12 characters in length.
Playback This comm~nd allows the operator to place one of the playback/record channels into a conference and, through the use of an external tape recorder, play a tape or music to the entire conference. Upon inserting a playback channel into a conference the conference is lectured.
The system prompts:

PLAYBACK
<conf#/'Remove><ch#~-If an 'R' is input in place of a conference number then the specified channel isremoved. Upon removing or inserting a channel into a conference the conference status area of the display is updated to reflect the changes.

Polling This comm~nd allows the o~e,~lor to poll a conference for DTMF digits. The operator or a moderator may ask a yes/no or a multiple choice question that requires conferees to depress any one key on their keypad. This command is located in the'Conference' submenu. Upon initiating the command the system prompts:

POLL

<conf#>-After entering a conference number the system then updates the conference statuswindow and displays the polling submenu. Upon callers entering digits the screen is updated to reflect the total numbers of each digit entered and each line displays the digit entered in the conference number field of the line status display.
Digits 1-9 are supported.

Entering 'ESC' from the polling submenu prompts:
EXIT POLLING
ARE YOU SURE (Y/N):
Entering a 'Y' returns to the Main Menu. Entering a 'N' or ESC' displays the polling submenu.

Clear- Polling The operator is able to clear out all digits to prepare for another poll by pressing a 'C'.
The system ~lOlllpt~.

CLEAR LINES
<line(s)/'All>-Lines may be entered an 'A' to clear all lines.

Help - Polling The operator can access a line in the polling conference that has requested help by pressing an'H'.
....
Mute - Polling The opel~or may mute or unmute lines while in polling by entering a 'U'. The system prompts.

MUTE
<line(s)>-then prompts for line to muted or unmuted, depending on their present state.

..... ~. .

25~
-Printing - Polling The operator printing of the results is supported by pressing an '~' (print_All), to print all line information along with totals and digit information, or an 'S' (print_Surnmary), to print only totals and digit information. Upon printing the system prompts:

ENTER TEXT
The operator can now enter any comments that should be printed out with the results (i.e. the question asked). The printing can be done via the operator terminal, the system printer, or it can be saved to the hard disk. See System Administrator Operator Station Configuration for details.

Release - Polling Pressing an 'R' releases the accessed line and the operator back into the conference.

Tag_digit - Polling The tagging of digits is supported by pressing a 'T'. This prompts the operator with:

TAG DIGIT
<digiP<tag'-The operator can enter a digit and the tag, up to 18 characters, which is then displayed in the conference status area of the screen.

Default Commands - Polling The operator talk comm~n~l and the switching of screel- displays is supported while in polling.

Question & Answer The Q&A co~ AI~l performs as follows: The ol)elalor selects Q&A mode from the operator display. The Linx plOll~t~ the operator for the confelellce and upon entering this inforrnation all lines in the conference, except for the moderator(s), are muted.

Q&A
<conf#>-;

The screen display changes to display the moderator(s) and the lines which have pressed the "question" key (DTMF '1'). Upon pressing the question key the Linx displays the lines according to their queue position not according to line number.

Help requests are displayed on the screen with the line number in reverse video. The operator may service a help request while in Q&A by moving the cursor to the line requesting help and pressing <RETURN>. This ~ccesses the line to the operator. Pressing <return>
again places the line back into the conference.

Operators may access the moderator(s) by moving the cursor to the moderator lineand pressing <RETURN>. This access the moderator to the operator. Pressing <RETURN>
again places the moderator back into the conference.

The first caller in the queue is displayed on the top left corner of the screen, after the moderator(s) in reverse video. Callers may remove themselves from the Q&A queue by entering a DTMF '#'. No lines except the moderators and the lines wishing to ask a question are displayed on the screen. The operator can use the arrow keys to move from caller to caller. By pressing <RETURN> the highlighted line is unmuted, begins blinking and can be heard by other conferees. When the operator presses <RETURN> again, the line is removed from the screen and the next person in the queue is now hi~hli~hte~l Entering 'ESC' from the Q&A submenu plo EXIT Q&A
ARE YOU SURE (Y/N):

Entering a 'Y' returns to the Main Menu. Entering a 'N' or ESC' displays the polling submenu.
Pressing an 'ESC' termin~tes the Q&A feature however the status of all lines are saved and is displayed when Q&A is entered again.

Clear- Q&A, The queue can be cleared out by issuing the 'Clear' comm~n-l Entering this comm~n~
clears all lines in the Q&A queue and updates the screen accordingly.

Gain - Q&A
While a line is hi~hlighted the operator may turn gain, for that line, on or offby pressing a "G". If gain is presently on for the line it is turned off. If gain is plesell~ly off for that line it is turned on. This command turns on the automatic gain feature for the accessed line. When on, the line is automatically given gain if the input level received from the line is determined to be low. The maximum amount of gain which can be given to a line is ??? dB.

, ~.~

Redraw - Q&A
This is similar to the refresh command. It clears and redraws the entire Q&A screen.

Resume - Q&A
After the operator unmutes a line by pressing <RETURN> the line can then be muted again and either removed from the Q&A queue by pressing <RETURN> again or it can be left in the Q&A queue by entering an 'R'.

Default Commands - Q&A
The operator talk comm~nfl and the switching of screen displays is supported while in Q&A.

Record This command allows the operator to place one of the record/playback channels into a conference and, through the use of an external tape recorder, record a conference. The system prompts:

RECORD
<conf#/'R'emove><ch#>-If an 'R' is input in place of a conference number then the specified channel isremoved. Upon removing or inserting a channel into a conference the conference status area of the display is updated to reflect the changes.

Security This command allows the operator to setup a conferense for security. Upon turning on security for a conference the moderator in that conference may then activate the security feature by pressing a '7' on their DTMF telephone. Operators are then denied access to that conference uIIless a request for ~si~t~nce is made. The system plo SECURITY
<conf#(s)>-Upon turning security on or off the co~ ce status area is updated. A secured conference can no longer request operator help. The conference security must be turned off in order to request operator help.

eXit_tone This comm~n<l toggles the exit tone heard by conferees as other conferees exit aconference. It works the same as the Entry_tone command.
4.2.4.3.4 Display Submenu Definitions aNswer The display answer comm~n(l allows the operator to view the answer status (whether or not a line answers a call) of each line on the system.

Calls The display calls command allows the operator to view the nurnber of calls per line and the total number of calls per system.- Calls are incremented when a conferee disconnects.

Gain The display gain comm~ntl allows the operator to view the status of the automatic gain feature of each line on the system.

Line_connect_times The display line connect times cornrnand allows the operator to view the currentconnect time for each active line on the system (from system answer to current time).

Minutes per_conference The display minutes per conference comm:~n-l allows the operator to view the number of minutes accumulated for the 12 conferences being displayed.

Operator_status This comm~n-l allows each operator to view the status of all operators on the system.
The conference status window is updated to display (1) type of operator card (local or remote), (2) the line ~l~cessed by the o~ld~or, (3) if the operator is remote and the operator is ~ccessecl by another operator, which operator is ?~cessing it, (4) automatic gain, on or off, for remote operators, (5) which conference the operator is currently in, (6) operator talk, on or off, (7) operator name up to 8 characters (this is not labeled). This screen is displayed and updated until either a refresh co~ l or a screen change comm~n-l iS issued. Note: Leased Line operators are displayed as LOCAL.

Show Conferences This comm~ntl toggles the operator between viewing all lines in all conferences or only the lines which are presently in the sarne conference as the operator. Default is all lines in all conferences. The message "One Conf.~ is displayed on the top of the screen when the system is displaying only active conferences. When the system is displaying all conferences the message "All Confs." is displayed.
Total_line_times This command allows the operator to view the total number of minutes accumulatedon all lines and the total amount of system time.
4.2.4.3.5. Fastdial Submenu DeI~nitions The Fastdial submenu allows operators to create dialing lists for use in blast up dialing or speed dialing. There can be up to 25 dialing lists with each list cont~inin~g up to 96 telephone numbers and names. Upon creating a list it is automatically saved to disk. The lists may be acces~e~l by any operator or all operators simultaneously. Along with creating lists, operators may remove entire lists, print, duplicate, or modify these lists.
Upon accessing a dialing list the operator may scroll through the list using the arrow keys.
Entering an item number and pressing <RETURN> moves the operator immediately to the specified item. Dialing lists may accessed from any of the 6 operator displays and the differences between the 25 line and 43 line displays is shown below.

Blastup Dialing This command allows the operator to blastup an entire dialing list. This comm~n.l is located in the 'Fastdial' submenu. Upon initiating the command the system proll~ts:

BLAST
<conf#>-A conference may be entered or, if only a ~return> is pressed the system selects an empty conference.
The system then plolllpls with:

BLAST .
.~ ..
<Starting Line>-A line number may be entered or, if only a ~return> is pressed line #l is used.
The system then displays all the dialing lists available. The operator must choose the list they wish to blastup. Choosing a list may be done by using the arrow keys to hi~hlight the desired list and then pressing <return>.

After a list has been selected, the items in that list are displayed on the screen. Items in the list can be flagged not to dial by using the up and down arrow keys to move through ~ ~ - 30 -the list and pressing <return> when the item in question is highli~hte-l Upon doing this the item is flagged and is not dialed during the blastup procedure.

When the operator is ready to begin, pressing a 'B', initiates the blastup procedure.
Lines are dialed and placed into the "CLPG" conference where they hear a repeating message (this message is recorded on annunciator #5). The callers can then press a DTMF ' 1 ' on their telephone and are moved into the conference. An 'N' may be pressed to automatically access the next caller in the call progress queue. Pressing an 'Nr again places the line into the selected conference. Pressing an 'H' hangs up the accessed line.

Create_list This command allows the operator to create a dialing list and enter a series of telephone numbers and names to that list. Upon initiating the comrnand the systems prompts:

CREATE LIST
<name>-Upon entering a name (~z for this example) the system prompts:

CREATE LIST - xyz <name><number>-The telephone number may be up to 40 digits in length and the name up to twenty (20) characters. The <name><number> prompt continues to appear until either the list is full (i.e. 96 items have been entered), or an 'ESC' is pressed. If an 'ESC' is pressed the operator is returned to the FASTDIAL menu and not the MAIN menu.

Dial This c~ d allows the operator to fastdial a specific dialing list. Upon initiating the comm~n~l the system plOlll~:

~ DIAL
<conf#>-A conference may be entered or, if only a <return> is pressed the system selects an empty conference.
The system then displays all the dialing lists available. The operator must choose the list they wish to dial. Choosing a list may be done by using the arrow keys to highlight the desired list and then pressing <return>.

~I- ~ 31 ~ 2 ~ 4 After a list has been selected, the items in that list are displayed on the terrnin~l The operator may then, using the arrow keys, move down, or up, through the list until the desired item is highli~hte~l When the operator presses ~return> the system finds a free line, accesses that line to the operator, opens the operator talk path, updates the screen, and dials the number.
If a connection is made the operator may place the line into the selected conference by pressing ~return>.
If no connection is made (busy, ring no answer) the operator may hangup the line by pressing an 'H'.
The operator talk key comm~n-l works while in the fastdial mode.

Duplicate List Upon pressing a 'U' (dUplicate) the system displays all the available dialing lists. The operator may choose the list to reproduce by using the arrow keys to highlight the desired list and pressing <return>. After selecting a list the system prompts with:

DUPLICATE
<NAME>-The operator enters the name and a new list is created.

Modify List The Modify list comm~n(l allows the operator to add, change, or delete items to/from a dialing list. Upon selecting the modify list option a submenu appears prompting the operator with ADD, CHANGE, and DELETE.
After selecting either ADD, CHANGE, or DELETE all the dialing lists are displayed on the screen. The operator may then choose a list by using the arrow keys to hi,~hlight the desired list and pressing <return>.
If ADD is selected the system plo~ L~:

Add item to list - xyz <name>~number>-The ope.dtor may now enter new items to the selected dialing list until either, the list is full, or an 'ESC' is entered.
If CHANGE is selected the system displays the items in the selected dialing list. The operator can select an item to change by using the up and down arrow keys. The left and right arrow keys may then be used to move the cursor through the field and make the necessary changes to the telephone number and/or narne. The 'DEL', 'BACKSPACE', 'HOME', and arrow keys are used for editing. Insert mode is always enabled and any .

- ~ - 32 character entered updates the screen. When updating the telephone nurnber use only '0' - '9', '*', '#' or a space. Once editing an item is complete, pressing <RETURN> modifies the dialing list and updates the other operator screens. To abort an edit use the up or down arrow keys.
If DELETE is selected the system displays the items in the selected dialing list. The operator may delete an item by using the arrow keys to select the desired item and press <return>.

Printing Dialing Lists This comm~ncl allows the printing of dialing lists. Upon pressing a 'P' the system displays all the available dialing lists. The operator may choose the list to print by using the arrow keys to hi~hlight the desired list and pressing <return>. The printing can be done via the operator terminal~ the system printer, or it can be saved to the hard disk. See System Administrator Operator Station Configuration for details.

Remove List This comm~n-l allows the operator to remove a list from the system. Upon initiating this comm~ntl, all the dialing lists in the system are displayed. The operator may then, using the arrow keys, select the list to be deleted. Pressing ~return> initiates the ylolll~;

Delete list- xyz (Y~) ~

Entering a 'Y' deletes the dialing list. Entering an ~' or 'ESC' aborts the deletion.
Deletion may only be performed if no other operators are in the fastdial submenu.
4,2.4.3.6. r~ine Submenu I)efinitions Fault This ~omm~n~1 allows the operator to take a line out of service. Upon initiating the comm~n~1 the Linx prompts:

FAULT
<line(s)>-The oyel~or may then enter the desired line(s). If a line is presently faulted then it is unfaulted. If a line is unfaulted then it is faulted.

Gain This comm~rld turns on or offthe automatic gain feature for the specified line(s).
When on, the line is automatically given gain if the input level received from the line is determined to be low. The maximum amount of gain which can be given to a line is 10 dB.
Upon initiating the command the Linx prompts:

GA~N
<line(s)>-The operator may then enter the desired line(s). Upon turning gain on or off thescreen is updated to reflect the change.

Hangup This comm~n~l allows the operator to hangup a line or group of lines from the system.
Upon initiating the command the Linx plolllpls:

HANGUP
<line(s)>-The operator may then enter the desired line(s). If a line entered by the operator is presently active or it is in the 'DC' state it is disconnected from the system. Upon h~nging up lines from the system the screen is updated to reflect the change.

Moderator This comm~nd allows the operator to flag a line or lines as moderators. Upon initiating this comm~n(l the system prompts:

MODERATOR
<line(s)>- ~.

The operator may then enter the desired line(s). If a line entered by the operator is not presently active it is not ~e-;~ed by this comm~n-l Upon making a line a moderator the screen is updated to reflect the changes.

Mute This command allows the operator to mute a line (no audio from the line enters the conference) or group of lines. Upon initiating the command the Linx prompts:

MUTE

- 34 - ~ 4 6 4 <line(s)>-The operator may then enter the desired line(s). If a line entered by the operator is not presently active it is not affected by this Comm~n(l If a line is presently muted when the comm~n~l iS issued the line is then allowed to talk to the conference. If the line was presently allowed to talk to the conference and the command was issued the line is muted. Upon muting or unmuting lines the screen is updated to reflect the changes.

Name This command allows the operator to name a line. Upon initi~ting the comm~n~l the Linx pro NAME
~line><name>-The operator may then enter the desired line followed by a maximum 20 character name. If a line entered by the operator is not presently active it is not affected by this comm~n(l Upon n~ming a line the screen is updated to reflect the changes. Operator lines may be named by entering o l - o8 for the line number. The operator name may only be 8 characters in length. The op~ldlor names are displayed when the display operator status command is executed.
4.2.4.3.7. Options Submenu Definitions Annunciator The annunciator command displays another submenu with the options PLAYBACK
and RECORD. Upon selecting the PLAYBACK command the Linx prompts:

PLAY MESSAGE
<annunciator (1-8)>-The op~ldlor may then enter an armunciator channel to playback. The annunciator plays and the operator may listen from the audio console. After recording or playing back an annunciator the operator is returned to the annunciator submenu.

Upon selecting the RECORD cornmand the Linx ~ro~ t~:

RECORD MESSAGE
'annunciator (1-8)>-~ ~ ~ 4 ~ 6 ,...

The operator may then enter an annunciator channel to record. The recording is done via the operator headset.

Chat This command allows any operator to send a message to any other operator. A
character string of up to 60 characters may be sent. Upon initiating this comm~n~l the system proml)t~:

CHAT
<operator> <texP-Any operator (1 - 8) may be entered and the text string. Upon pressing <RETURN>
the string is displayed on the top of the specified operator display (see below). The operator which sent the string is also displayed. If the operator has a name assigned to it then the name is displayed in place of the operator number. Messages from the system display "System" in place of the operator name.

Exit The operator may log out of the system by entering this comm~n-l Upon entering this command any accessed line is released, the operator station is returned to the main menu, the screen is cleared and the sign-in prompt displayed.

Scan This command automatically moves the operator from conference to conference. If a conference is empty it is skipped. Sc~nning continues until ar y key is pressed.
4.2.4.3.8. Purge Submenu Definitions Call_counts~
This command zeros the accumulated calls on each line.

Disconnects This command purges the disconnects for a desired conference or all the disco~c~ls on the system. The system pro~llpt~: -PURGE DISCONNECTS
<conf#/'A'Il>-The operator may then enter either a conference number to purge or an 'A' to purge all disconnects present on the system. Purging disconnects clears the name and telephone number and turns off the gain associated with the line being purged.

Minutes per_conference This command allows the operator to zero the conference minlltes for a specific conference and set the start time for all lines in that conference to the present time. The system prompts:

PURGE MINUTES PER CONFERENCE
<conf#>-The operator may then enter the conference number to purge.

Total_times This command zeros all the accnm~ ted line times for each line in the system.
4.2.4.3.9. Set Submenu Definitions Nighttime This command tells the system to ignore all incoming calls. Once the operator initiates the command the message "Nighttime Mode Set. Press any key to stop" appears on all operator screens. This message stays on each screen until a key is pressed from any operator station. After a key is pressed the Nighttime mode is disabled and all operators go back to the Main menu.

Scan This command allows the operator its own independent sc~nning time for the conference scan feature. The system prompts:

SET SCAN TIME
<time(1 -59)>-4.2.4.3.10. Tr~n~ferSubmçnuDefil~ition~
Conferees This comrnand allows the operator to ~ sr~ groups of conferees to different conferences. The system prompts:

TRANSFER CONFEREES TO
<conf#>~line(s)>-i~ - 37~ 4 J
The operator may then enter a conference number and all the lines to be transferred to that conference.

Link_lines This command allows the operator to kansfer the link channels from conference toconference. The system prompts:

TRANSFER LINK LINES TO
<conf#/'R'emove><link line>- -The operator may enter a conference number or an 'R', along with a link line, to either transfer the link line to a conference or remove the link line from all conferences.
4.3 Annunciators The DCB supports 8 annunciator channels and 8 messages. The messages are digitized, when recorded by an operator, and saved on the hard disk. Each of the 8 annunciator channels can play any of the 8 messages. Upon channels calling into the system an annunciator is played to them. This annunciator can be any of the 8 annunciator charmels however the actual message is the one assigned via the ~lmini~trator console. This configuration allows any message to be played to any annunciator.
4.4. CDRs A feature is provided for storing/printing line information upon the disconnection of a line from the DCB. The CD~ (Call Detail Record) for each line, CDRs are generated when lines disconnect from the bridge, is saved to disk. CDR's can be printed via the printer port on the back of the bridge (see system a-lmini~trator printer options for details). CDR printing is not supported through operator t~rmin~l~. The CDR format is as follows:

LINE# CONF# START END CONNECT NAME MODERATOR PHONE# CONF
NAME

Line # - The line that disconnected.
Conf # - The conference from which the line disconnected.
Start Time - The time the line either called into the Linx or was dialed out by the operator.
End Time - The time the line discoi-n~-c~e~ from the Linx.
Connect Time - The amount of time (in minutes) the line was on the Linx.
Name - The name assigned to the line.
Moder~tor - If the line was a moderator this field contains a 'Y'. If the line wasn't a moderator this field contains an 'n'.
Phone # - The telephone number if the line was dialed out.

Conference Name - The name assigned to the conference.
4.5. Music The DCB can supply music to any and all conferences simultaneously using a single music source. The INPUT and ENTER conferences are also supplied from the same music source. Inserting and removing music from a conference is done via the operator t~Trnin~
The insertion of music to the INPUT and ENTER conferences is done during system initialization and cannot be removed from these conferences.
4.6. Record/Playback The DCB has the capability of recording from, or playing to, up to 3 conferencessimultaneously. Each channel may be cQnfigured via the operator termin~l for either recording a conference or pla~ing to a conference. Record and playback cannot be done simultaneously on the same channel. There can be a maximum of 3 record/playback channels installed into DCB.
4.7. Conf~uration Menu The DCB product allows the system ~mini~trator to configure system parameters pertaining to lines, conferences, operators, and the entire system.

4.8. Operator Printin~
By connecting a serial printer to the back of an operator station ASCII terminal, operators can initiate the printing of dialing lists and polling results.
System ~lmini~trators may redirect printer output from the operators to a printer connected to the back of an operator t~rrnin~l, to the system printer, or to a file saved on the hard disk.
4.9. Administrator MMT
The Digital System 60 (DCB\60) Administrator Console allows conferencing operations sùpervisors to configure the DCB\60 to meet their conferencing needs. Channel.
operator, and system parameters, may be configured through the ~(lmini~trator console.
Backups of these configurations, the printing of system reports, setting system date and time, and password\sign-in m~n~em~nt are also done through the ~mini~trator console. Upon starting the ~mini~trator process, the screen is cleared and the ~rimini~trator main menu is displayed. The entire process is menu driven.

Pressing the 'ESC' key returns you to either the previous menu or to the Main Menu, depending on what command you are executing. If the terminal loses power or becomes ~ ,,r disconnected from the system the ~11mini~trator process aborts and the sign-in process is started. Upon reception of a shutdown comm~n-l the a(lmini~trator process is killed.
4.9.1. Main Menu The Main Menu is displayed upon startup of the ~lmini~trator process. It consists of the following items.
System Date/Time - Sets the system date and time.
System Configuration - System Configuration Menu.
Channel Configuration - Channel Configuration Menu.
Operator Configuration - Operator Configuration Menu.
Disk Utilities - Format and view removable media.
File Management - View, print, and export files.
Backup/Restore - Backup and restore directories.
Sign-In Management - Sign-In Management.
Operator Display - Allows the ~lmini~trator start the operator console process.
Exit - Exits ~tlmini~trator screen.
4.9.2. System Date and Time The system date and time are changed using this menu option. The ~lmini~trator can move between the date and time fields on the screen using the arrow keys and input the proper values.

Only numeric characters are allowed to be entered into the fields. Pressing 'ESC' piOlllp~ with "Save Changes (Y/N)?". Entering an 'N' or 'ESC' does not change the date and time. Entering a 'Y' changes the date and time.
4.9.3. System Conf~uration The system configuration menu gives the ~lmini~trator the ability to name the system, set the number of simultaneous talkers, configure dialout supervision, set annunciator and dial delays, set wink, flash hook and guard times, and enable\disable DTMF acknowledge, Disconnect Mode, Help Mode, and 1 or 2 digit mode. The a.~minictrator can move bet~,veen these fierds by using the arrow keys.

Alpha~ leric cha~a ;le.~ are allowed in the narne field and numeric characters only are allowed in the Sim~llt~nçous Talkers, Annunciator Delay, Dial Delay, Winlc Time, Flash Hook Time, and Guard Time fields. The rem~ining options may be changed by selecting the desired option, using the arrow keys, and pressing the space bar, which toggles through all available options for the specific field. Pressing 'ESC' p~o~ t~ with "Save Changes (Y/N)?".
Entering 3n 'N' or 'ESC' does not implement the changes. Entering a 'Y' changes the parameters in memory and on disk.

e~ Dial Out Supervision Options - Delay or Wink Default- Delay _ 40 - .~ 4 ~
Description - After seizing out on a line either, 1> delay for the duration entered in Dial Delay or 2> execute a wink of the duration entered in Wink Time, before dialing digits.

Simultaneous Talkers Options - 1 -3 talkers Default - 3 Description - Number of simultaneous talkers per conference.

Annunciator Delay Options - 0-5 seconds Default - 0 Description - Amount of delay before annunciator message is played after a call is answered.

DialDelay Options- 1-5 seconds Default- 1 Description - Arnount of delay before dialing digits. See Dial Out Supervision.

Wink Time Options - 300-800 ms. Default - 300 Description - Duration of wink signal. See Dial Out Supervision.

Flash Hook Time Options - 300-800 ms. Default - 300 Description - Duration of flash hook, used for call transfers.

Guard Time Options - 300-800 ms. Default - 300 Description - Duration of time from when a line disconnects in both directions until that line may be used again for either outgoing or incoming calls. Prevents glare condition which occurs when both ends seize the line simultaneously.

DTMF Acknowledge Options - Yes or No Default - No Description - Send the caller 2 beeps informing them of the reception of a validDTMF digit.
.~ ..
Disconnect Mode Options - Yes or No Default - No Description - Upon a line disconnecting from the system either, 1> keep the lineseized out and display 'DC' state on the operator screen or 2> disco~ e~;L the line imme~ tely and clear line from the operator screen.

Conference Help Options - Yes or No Default - No Description - Respond to help by either 1> conference, operator moves to conference requesting help or 2> individual, operator accesses caller that requested help.

Two Digit Mode Options - Yes or No Default - No ., Description - Requires an '*' be pressed preceding any DTMF option. Callers mustpress '*', '0' for operator help.
4.9.4. Channel Confi~uration The channel configuration menu gives the ~lmini~trator the ability to assign a specific annunciator message to a channel, set the answer status of a channel, set the timeout time of a channel, or restore all channels to their defaults. The ~(1mini~trator selects a configuration option by using the arrow keys to move between menu items and pressing return. Selecting defaults prompts with an "ARE YOU SURE? (Y/N):" message and sets all channels to their default configurations if a 'Y' is entered. Selecting 'Main Menu' returns the ~-lmini~trator to the main menu. The channel configuration menu window is shown below.

The window relating to I of the 3 channel menu items (annunciator, answer, timeout) is displayed upon choosing an item. Each window displays 24 channels and the rem~ining channels can be viewed/modified by using the page-up/page-do~,vn keys.

The announcement message (1 - 7, message #8 is reserved for blast out dialing) can be entered via the keyboard and each channel has a default of message #1. Channels do not hear a message if a 0 is entered in the annunciator field. The answer configuration can be a 'Y'es or 'N'o and these are toggled by pressing the space bar. Answer defaults are 'Y' for all channels. Channel timeout can range from 0 - 60 minutes and these can be entered via the keyboard. Timeout defaults for all channels is 0 seconds, i.e. no timeout. Pressing 'ESC' plo~ s with "Save Changes (Y/N)?". Entering an 'N' or 'ESC' does not make the changes.
Entering a 'Y' changes the parameters in memory and on disk.
4.9.5. Operator Confi~uration The operator configuration menu gives the ~lmini~trator the ability to independently configure each of the 8 operator stations and the ~clmini~trator station. Terminal bit rate, printer o~tions, terminal beeps, operator talk character, and local\remote op~ tol setups for each operator can be configured from this menu. The ~clmin~ rator terrnin~l can only be configured for baud rate, printer options, and te~nin~l beeps. The operator configuration menu lists all 8 operator stations plus the ~lmini~trator station.

Upon selecting an o~ atol station to configure, the operator configuration window for the opeldtor selected is displayed.

The Baud Rate selections include 9600 and 19200, selectable by pressing the spacebar. The default baud rate is 19200.

2 ~ ~ 4 ~ ~ ~

The Printing selections include local, system, file, none or any combination of local/system/file. The print options are selectable by pressing the spacebar and the default for each operator is local.
The Beep Mode selections include single beep, continuous beep or no beep. The beep time option is the interval between beeps, 1 - 5 seconds, when the continuous beep option has been selected. The Beep Mode options are selectable by pressing the spacebar. The default for Beep Mode is single beep and the default Beep Time is 1 second.
The Talk Key selections include the spacebar and the dash key, selectable by pressing the spacebar. The default is 'spacebar' controls operator talk.
The Remote selections include 'Y'es or ~'o, selectable by pressing the spacebar. The default is No, i.e. Iocal operator.
The Channel selection gives the a(1minictrator the ability to assign a remote operator a channel number. These channel numbers can be any of the user channels currently in service on the system however the channel must be inactive to be assigned remote operator capabilities. Only remote operators can be assigned channel numbers, local operators use the channel ~ssi~nments given by the system and these cannot be modified.
Pressing 'ESC' plo~ with "Save Changes (Y/N)?". Fnterin~ an ~' or 'ESC' does not make the changes. Entering a 'Y' changes the parameters in memory and on disk.
4.9.6 Disk Utilities The Disk Utilities menu allows the ~lmini~trator to format or list the files on a floppy disk.

Selecting Format or Directory Listing prompts with the drive select menu, shown below. The ~lmini~trator must select the disk drive to use and press return, or press 'ESC' to exit.

After selecting a drive the screen is cleared and the following messages are displayed.

"Format of A:" or "Directory Listing of A:"
"Please insert disk into drive A:"
"Press 'ESC' to abort, any other key to continue."

Pressing 'ESC' aborts the procedure, otherwise the command is executed, and whenfinished, a "Press any key" message is displayed on the screen. If either of these comm~n~c are executed without a floppy disk inserted into the appro,u~;ate drive the screen hangs until a disk is inserted. Disks are forrnatted with the DOS forrnat command.
-. ~

4.9.7. File Man~l~ement The file management menu gives the a-lmini~trator the ability to delete, export, print, and view files on the system which include Alarm Statistics, CDRs, dialing lists, logs, network statistics, and operator printouts. Alarm statistics are written to a file and displayed when this item is selected. CDR, and Log, files are assigned names corresponding to the date they were created (i.e. SepO6) and the system m~int~in~ a maximum of a months worth of each type of file and deletes the oldest file as necessar,v. Network Statistics files are ~ssi~ned names corresponding to the date created and T1 trunk (i.e. SepO6.0 for trunk 1) and are updated every 15 minutes The system m~int~in~ network statistics files using the same method for m~int~ining CDR and Log files. Dialing list files are named by their creator and the number of these files is limited only by disk space. Operator printouts are named by the system as operl.prn, oper2.prn, etc.
Alarm Report file contains a snapshot of the alarms currently active on the system.
CDR files contain Call Detail Records for each line that entered the system.
Dialing List files contain system dialing lists created by operators for use in blastup and fastdial.
Log files contain messages from all software processes used by the DCB\60. Theseinclude information messages, software errors, T1 alarms, etc. for use in systemm~int~n~nce and performance evaluation.
Network Statistics files contain counts of various T1 events (i.e. alarms, T1 errors, etc.) If this file contains all zero's no T1 problems have occurred.
Operator Printout files contain all operator printouts that have been redirected to a file.

4.9.8. Backup/Restore The Backup/Restore menu gives the ~imini~trator the ability to backup and restore system configurations, CDRs, Dial Lists, Logs, and Sign-Ins. The a~mini~trator selects an option by usirig the arrow keys to move between menu items and pressing return.

4.9.9. Si~-~n M~na~ert The Sign-In Management menu gives the ~lminictrator the ability to create and delete operator, ~imini~trator~ and m~intf n~nc e sign-ins. M~;..ten~.~ce sign-ins can only be created/deleted if the ~fimini~trator process was started via the m~i~.tf ..~nce process. The ~rlministrator selects an option by using the arrow keys to move between menu items and pressing return.

4.9.10. Operator Display Monitor This menu item clears the screen and starts the operator console process. If theoperator console was started from the ~-lmini~trator process then, upon exiting the operator console the ~mini~trator process is started.
4.9.11. Exit This menu item exits the ~lmini~trator process and starts either the sign-in or maintenance depending upon which process started the ~mini~trator.
4.10. Maintenance MMI
The Digital System 60 (DCB\60) ~inten~nce Console allows maintenance personnel to configure and m~int~in T1 links, perform a system shutdown or re-initialization, access the ~mini~trator or operator console processes, and clear network statistics. Upon starting the maintenance process, the screen is cleared and the maintenance main menu is displayed. The entire process is menu driven. The copyright window (shown below) is displayed for each menu selected.

Pressing the 'ESC' key returns you to either the previous menu or to the Main Menu, depending on what comm~n-l you are executing. If the terrninal loses power or becomes disconnected from the system the maintenance process aborts and the sign-in process is started. Upon reception or issuance of a shutdown cornmand the m~inten~nce process is killed.
4.10.1. Main Menu The Main Menu is displayed upon startup of the maintenance process. It consists of the following items.
T1 Configuration - Configure the T1 trunks.
T1 Status - Display T1 status for all trunks.
T1 Enable/Disable - Enable/Disable Tl trunks.
~ ~ Clear Network Statistics - Clear the days Network Statistics file.
mini~trator Menu - Start the ~rlministrator process.
Operator Display - Start an operator console process.
Re-~r~i*~li7~tic- - Re-boot the system while ret~inin~ current conferences.
System Shutdown - Shutdown the system.
Exit - Exits ~rimini~trator screen.
Tl terminology used in this section is defined as follows.
B8ZS (Binary 8-Zero Suppression) - Ensures a minimurn 1 in 8, ones density by replacing any group of 8 consecutive zeros with a known bipolar violation sequence.
Blue Alarm - All l's intentionally sent if norrnal data is unavailable.
CRC - Cyclic Redundancy Check - Deterrnines how many frames have errors.

_ - 45 -D3/D4 - 12 bit T1 framing format.
Err. Secs. - Number of seconds that have at least 1 CRC error.
ESF - Extended Super Frame - 24 bit T1 framing format which contains CRC and Err. Secs.
Jammed Bit - The system changes bit 7 to a ' 1 ' if 8 bits of a word are zero.
OOF - Out of frame, i.e. no recognizable received signal, red alarm.
RED Alarm - Occurs when the near end of a T1 line detects loss of frame. A Yellow alarm is sent to the far end of the T1 line upon detection of a Red alarm.
Slip - An unequal number of frames received from 2 T1 lines.
Sync Source - The source of clock which synchronizes the T1 links.
Yellow Alarm - Occurs when the far end of a T1 line detects a loss of frame.
Zero Code Suppression - Ensures the data output stream never has more than 15 consecutive zeros. This is a T1 line clock recovery requirement. Either B8ZS or Jammed Bit.
4.10.2. T1 Confi~uration The T1 configuration is set/modified through this menu item. Moving through the configuration fields is done using the arrow keys.
The spacebar is used to toggle between options in the Sync. Source, Primary, Secondary, Framing, and Zero Code Suppression fields. The rem~inin3~ fields, Error Thresholds, Slip, BPV, CRC, Err. Secs., and Detect and Clear timers are modified by entering the applo~iate value.
The T1 Synchronization source can be internal or external and the primary and secondary source can be configured to any of the installed trunks. A public telephone network is the preferred source.
Minor alarms are generated when Out of Frames, Slips, Bpv, CRC, and Err. Secs reach their specified limits. The default limits are 0 which indicates the alarm is never generated. If a minor alarm is generated by one of these conditions it is cleared after a 15 minute interval passes without re~hing the specified alarm limit.
Major alarms occur upon indication of a Red or Yellow alarm condition. The Red or yellow alarm condition must occur for a minimum of "Detect" seconds. Detect and clear are entered in tenths of seconds. The alarm is cleared if there is no occurrence for a duration of "Clear" Seconds.
Framing can be set individually on each trunlc as can zero code :jU~ es~ion. Setting framing to ~one' disables the Tl trunk.
Pressing 'ESC' prompts with "Save Changes (Y/N)?". Entering an 'N' or 'ESC' doesnot make the changes. Entering a 'Y' makes the changes active and saves the Tl configurations to disk.
,. p~

4.10.3. T1 Status T1 status is displayed by selecting this menu item. The T1 status screen, shown below, is updated every 2 seconds and is exited by pressing 'ESC'. The status screen size varies depending on the number of T1 trunks installed.

Alarm status displays any pending alarm either Red, Yellow, Blue, or None.
Framing, Zero Code, and Sync display the current T1 configuration.
The ABIn and ABOut displays which of the 24 channels are seized in and/or seizedout.
Alarm counts displays the total number of Red, Yellow, and Blue alarms.
The rem~ining fields display the nurnber of Out of Frarnes, Slips, BPVs, CRCs, and Err Secs.
4.10.4. T1 Enable/Disable The T1 Enable/Disable option allows for the disabling or enabling of all installed T1 trunks. The T1 Enable/Disable menu, shown below, displays the current tmnk status. The options are configured by using the arrow keys to move between menu items and pressing the spacebar. Pressing 'ESC' prompts with an "ARE YOU SURE? (YIN):" message and enable or disables T1 trunks as defined if a 'Y' is entered. Entering an 'N' or 'ESC' aborts all changes.
4.10.5. Clear Network Statistics The Clear Network Statistics option allows m~int~n~nce personnel to clear the days Network Statistics file. The Network statistics file is available for exporting, printing, and viewing through the ~fimini~trator file management menu.
4.10.6. Administrator Menu This menu item-clears the screen and starts the a-lmini~trator process. Upon exiting the a~ ini~trator console the maint~qn~nce process is started.
....
4.10.7. Operator I)ispla~Y Monitor This menu item clears the screen and starts the operator console process. Upon exiting the operator console the m~intçnance process is started.
4.10.8. Re~ itiali7~tion This option allows the system to be rebooted while l~,a;~t;~ g co~ cing. The reboot of the system brings down all software processes and finally shuts Unix down.
Conferencing is still active as all DSP cards continue to run. Unix is then rebooted which starts up all DCB\60 processes and the conferencing information is uploaded from the DSP
Dual Port Rarn to the system for initialization purposes.

_ -- 47 --Upon selecting this item an "ARE YOU SURE? (Y/N):" message is displayed.
Entering 'Y' reinitializes the system. Entering a 'N' or 'ESC' aborts the re-initialization.
4.10.9. System Shutdown Upon selecting this item an "ARE YOU SURE? (Y/N):" message is displayed. If conferences are active on the system this information is also displayed. Fntering 'Y' executes a system shutdown. Fntenng a 'N' or 'ESC' aborts the shutdown.

4.10.10. Exit This menu item exits the ~1mini~trator process and starts either the sign-in or maintenance depending upon which process started the ~-lmini~trator.
4.11. User Pro~ram Interfaces There is no user progr~mming on the system~
5. Service and Maintainability Specifications 5.1 MTBF
20,000 to 50,000 hours for 96 to 24 port system.
5.2 MTTR
lS minutes S.3 l)i:~nostics A full suite of power-up, off-line and on-line diagnostics are provided for the use of customers and customer service.
5.3.1 Power-up (li~nostics Power-up test and diagnostics include:
Full memory tests of DSP cards including dual port, quad port, and static RAM.
DSP Load Code DSP intell~t - DSP s~om~ph-)re DSP card connectivity Reference memor,v Analog card xrnit & rcv.
MVIP interface - 48 - ~ 4 ~ ~
5.3.2 Off-line (lia~nostics Off-Line system testing includes:
CPU
I~lLe~lu~ul Controller DMA Controller Interval Timer CMOS Clock System memory including base, extended and expanded RAM.
Floppy Drive Serial Port Parallel Port Printer Speaker 5.3.3 On-line dia~nostics The system continll~lly checks all software processes to ensure their sanity. If an error is detected a message is logged and an alarm is initiated.
5.4 Remote Access A built-in modem allows remote dial-in at speeds up to 9600 bps. The maintenancefea~llres available remotely include:
Remote operator Remote ~-lmini~trator Remote m~int~ n~nce:
Remote reboot File transfer and software update Remote dump analysis Viewing of network management statistics and logs 5.5 ~oftYv~re maintenance Customer service software ...~i..t~ nce tools which may be run locally or remotely include:
Dump analysis Network management- T1 network interface monitoring Resources monitoring- E.G.: memory, buffers, disk, processes, etc.
Program Debug and memory inspect and change File transfer and software update ~ 49 ~
5.6 Field Replaceable Units The field replaceable units include each circuit board and the power supply as well as each external assembly.
Power supply Backplane CPU board System enclosure T1 Interface PCB
DSP PCB
Diskette drive Hard disk drive Analog board Serial port board Terminals Internal modem board Note that the DCB is intended to be small and easily m~int~ined by technicians famili~r with PCs. It is easy to replace a board by opening the case or an entire box. No boards may be replaced with the power on.

6. Performance Specifications Speed of Blast Up, 96 channels, less than 30 seconds.
DTMF Digit processing - 96 simultaneous DTMF inputs, no missed digits.
Ring Detection - Detect Ringing and answer line within the first 2 rings.

7. Compatibility Specifications 7.1 Existing MultiLink Products The DCB is compatible in function, user operation and operator operation with the System 60. ~he Conferee and Moderator touchtone controls and audible responses are identical with the System 60. The Operator displays, while nPcesc~rily dirrer~,lt to address the additional capacity of the DCB are functionally very similar. Only the "Config" menus of the System 60 are appreciably different. An operator trained on the System 60 should be able to use the DCB to run conferences with a mini . . .~ t of training time.
The DCB may be linked to existing MnltiT ink bridges with 4 wire Link Lines or through the direct Tl connection to the DCB.
7.2 Customer Equipment The customer may use any IBM compatible PC with a modem and off-the-shelf or MultiLink supplied terminal emulation software to access the DCB.

.

~ 50 ~ ~ $ ~
The DCB may be connected behind the customer's switch or PBX using Tl or 4 wire connections as long as this equipment provides the proper wink disconnect si~n~ling.
7.3 Standard Equipment The DCB conforms to a variety of standards for Telecomm, I:~atacomm and PC/AT.
Telecomm- Tl DSX-l interface to local equipment or internal CSU
Accunet Tl.5 compatible (TR6241 l) with ESF (TR54016) support Datacomm- Modem V.32?

8 Aaency Approvals Safety- UL/CSA approvals are provided for rack mountable units. Designed to meetTIJV/VDE. EMI- FCC Part l 5 class A for rack mountable units.
Telecomm-Tl connection- (AT&T?), DOC?, JATE?
FCC part 68- (only for analog voice connections. Excludes 4 wire E&M as these are all local to customer and MultiLink equipment.) C~n~ n DOC- (only for analog voice connections. Excludes 4 wire E&M as these are all local to customer and MultiLink equipment.) JATE- (only for analog voice connections. Excludes 4 wire E&M as these are all local to customer and MultiLink equipment.) 9 Deliverable Confi~urations l0 Customer Documentation 10.1 Site Prep Guide lQ~2 Tnst~ tion Manual 10.3 Operation/~int~ lce Manual .~..

11 Future Product Mi~ration Specifications ll.l. Networked Operator Attended Conferpn~i~ System The LAN/operator attçn.1~o~ software option allows:
Operator tç-min~1s can be PCs on a LAN with tç-rnin~l emulation software.
Up to 5(?) simultaneous remote operators can have sessions to the bridge in addition to the local operator.
The local operator station can access as many as 8(?) remote bridges at one timeHigh resolution displays with X Windows or Windows 3.0 allow multiple operator screens to be displayed simultaneous1y.

4 ~

In the future the customer may access the bridge with his own workstation using MultiLink supplied software.
11.2. Reservation and Database System A relational database can be added to support the advanced reservation of bridgeresources for conferences. Conference, user, client and billing ~l~t~baces can be provided.
The reservation system can support attended operator usage and later unattended client reservations and inquiries. The client may make a reservation using his DTMF handset and the Interactive Voice Response (IVR) capability of the DCB or by dialing in with an ASCII
terminal.
11.3.3 Personal Teleconferencin~ -The Digital Conferencing Bridge can be enhanced to incorporate the functions of adata bridge. The data bridge functionality allows personal computers at multiple conferee's desks to be bridged into a combined voice/data conference. This functionality requires the bridge to support a large number of data connections. The data connections may be from users modems that enter the bridge as analog or Tl connections or from data networks such as LANs or X.25.
11.4. ~dditional Future Product Extensions The DCB is designed with an integrated digital voice and processor architecture that allows a wide variety of future products and options to be added to the base product. The following are additional capabilities that might be needed:
Fax- Notification of a conference via automatic sending of fax. Storage of fax to be used in personal teleconferences. Faxmail.
Email/media mail-- storage of Email(including files, images and faxes) on the bridge.
Email X.400 gateway to corporate or public Email systems.
Voice mail- to support the conferencing ISDN
CEPl' (2mbps, 30 channel) capability , ~

- 52 ~ 4 ~

APPENDIX B

1.0 Introduction Digital signal processing involves the conversion of signals to sequences of nurnbers and the subsequent processing of these sequences. The principle governing conversion of continuous-time signals to discrete-time signals is expressed in the Sampling Theorem.

Sampling Theorem: A continuous-time signal can be completely recovered fi om itssamples if, and only if; the sampling rate is greater than ~wice the signal ~andwidth.

For telephone voice data this rate is 8000 samples/sec. The discrete-time signal can be operated upon by a software process, which is faithful to the invertibility, causality, stability, time invariance and linearity properties of the corresponding continuous-time system. Digital signal processing specific microprocessor architectures and instruction sets have made real-time execution of software algorithms possible. Now processing, which was previously accomplished in hardware, can be done in software. The Digital Conferencing Bridge will be realized using digital signal processing hardware and algorithrns.
2.0 DSP Hardware Overview The Digital Conferencing Bridge will consist of up to four DSP boards, connected by an MVIP bus. Each DSP board contains four Texas Instruments TMS320C31 digital signal processors. The TMS320C31 is a high performance CMOS 32-bit floating-point device. The processors are employed in the Microcomputer/Boot Loader Mode. In this mode a bootloader is mapped into locations 0000h through OFFFh. Each processor communicates with the PC Host via a 4kx16 dual port ram, featuring arbitration control, 8 semaphore registers and interrupt generating mail-box registers. At the M-VIP interface two DSP
processors each share 2kx8 quad port rams. Passage of data between the quad port rams and the MVIP bus is facilitated by serial to parallel and parallel to serial conversion PLDs. The output serial line destination of quad port ram buffered data is controlled by time slot specific bytes, written by the host to the 1kx8 dual port control ram.
3.0 TMS320C31 Memory Map Note: This memory map must also be incorporated into the linker command file. The Linker defines module addresses using the memory map as a reference.
0000000H - 0000FFFH reserved for Boot Loader (see TMS320C3X User's Guide section 3.4) 0808000H - 08097FFH Peripheral Bus Memory-Mapped Registers (6K internal) 53 - ~ ~ ~i 4 ~ ~ 4 0809800H - 0809BFFH Ram Block O
(1 K internal) 0809COOH - 0809FCOH Ram Block 1 (1 K intern~l) 0809FClH - 0809FFFH Interrupt and'Trap Branches (64 intern~l) OAOOOOOH - OA007FFH Quad Port Ram (2kx8) external MVIP input and output Buffers OBOOOOOH - OB~ I SemaphoreRegisters OECOOOOH - OE(~ 'H Code Ram (SIMM, 64kx32) OFCOOOOH - OFCOFFFH Dual Port Ram (4kx16 external) Host-Dsp Communication Interrupt Generating Mail Boxes Boot 3 - Loader Input File Area MVIP Bus Reference Memory Window 4.0 l)ual Port Memory Data Structures The TMS320C31 Processors communicate with the host via data structures defined within the dual port memory. The intent is to define structures which enable the logical association of an MVIP time slot with an information port managed primarily by the Host.
The association of a time slot and a port defines a channel. Secondly, lists and queues are m~int~ined as means of communicating global information.
4.1 nata Transfer B~ffers Two ~ ffers are provided for record and playback of voice data. The buffers are each 2 Kbytes and are located at DPM addresses Seg.:O and Seg.:800. A semaphore is allocated to each of the buffers for access control.
4-~ Ch~nnel nata Structure ~rray An array of eight Channel Data Structures is located at DPM address Seg.:OxlOOO.The structure is composed of the following items.
Dual Port Memory Port (O - 191) (node~3 + sequence number) (initialized to assigned port) Command (initialized to O) Error (initialized to O) Conference (initialized to O) , . ~

.~ -- 54 --Mute (0 - 1) (initialized to 0) AGC (0 - 1) (initialized to 0) Music (0 - 1) (initialized to 0) Talk (0 - 1) (initialized to 0) Time Slot Type (initialized to 0) Event Queue Head Pointer (initialized to 0) Event Queue Tail Pointer (initialized to 0) Event Queue, 10 words (initialized to 0) Digits-Out, ascii string 50 bytes maximurn (initi~1i7P~ to null string) 4.3 Channel MVIP Time Slot List The Channel Time Slot List contains one word entries, indicating the time slot numbers of channels. The list consists of 192 entries sorted by port number ( (6 boards) x (8 channels/node) x (4 nodes/board)). Each entry consists of two parts; byte 0 = location within serial receive line, byte 1 = serial line . The list irnmediately follows the Channel Data Structures. During initialization the entire list is converted to quad port ram buffer indices and stored with other tables in the external coderam. The transmit buffer indices are equal to byte 0 of the dual port memory time slot entries.

4.4 Conference Number of Talkers List 91 (48 user + 8 operator + 8 annunciator + 1 enter + 1 input conferences) one word entries sorted by conference numbers. Each entry indicates the maximum number ofsimultaneous talkers allowed for each conference. Located immediately following the Channel MVIP Time Slot List.
4.5 System Parameters The 50 word System Parameters List is preceded by an unoccupied memory location which immediately follows the Conference Number of Talkers List. System parameters are constants which control certain aspects of the digital conferencing bridge, but which may be modified during execution. During initialization the parameters are read into the internal memory of each TMS320C3 1. Neces~ conversions are done at that time. An item can be changed following system initialization. Entry 0 is a pointer to an item in the list which has been changed. Entry 0 is checked once ever,v sample period. A value of zero implies no change to the list.
Item Pointer pointer to changed item Node Number node number Active Node Mask [part 0] one bit per node (1=active, 0=inactive) Active Node Mask [part 1] one bit per node (I=active, 0=inactive) The mask determines nodal participation DTMF On Time 100 ms DTMF Off-Time 50 ms DIALTone-Wait S sec unused DTMF Level -7 dBm Forward Twist (receive) 8 dB unused ReverseTwist(receive) 8 dB unused Talk Detect Level -35 dBm Maximum Talkers per Conference 8 unused Gain (pointer to multiplier in table) 00001000 Speech Level Out -16 dBm unused Channels per DSP Node 6 channels/node 4.6 Channel Conference Queue and Pointers Two pointers and a Channel Conference Queue immediately follow the system parameters. Muting and Movement of channels between conferences are controlled via this structure. An entry consists of the port number concatenated with the new conference number; byte O = conference, byte 1 = port number. The host increments the head pointer when adding an item to the queue. The DSP increments the tail pointer when removing an item from the queue. The queue is empty when the pointers are e~ual. As items are removed from the queue, a table of conference numbers sorted in port number order is built internally.
The table consists of 192 entries ( (6 boards) x (8 channels/node) x (4 nodes/board)). Placing an item in this queue automatically causes the port number to be purged from the current conference talk list. This is why the queue also plays a role in the muting of channels. If a channel is muted it must be removed from the talk list. Prior to ch~nging a channel's conference number the host should mute the channel, preventing tr~n~mi~sion of a talk bit.
The Channel Conference Queue of the node on which the channel resides should be the last updated with the new conference number.
5.0 Internal Data Structures S.1 Port Information Data Record An information data record is m~int~ine~l internally for each of the ports a node is responsible for. The data and history relevant to the port is m~int~inPd here and varies by sample period.
.....
position name type description O INFO_x float x~n], current input sample INFO_avm float average magnit~de of observed voice sarnples 2 INFO_confavm float average magnitude of conference voice sarnples 3 INFO_confid integer conference number channel is ~cign~l1 to 4 rNFO_queue integer address of talk list corresponding to conference S INFO_type integer channeltype; conferee, operator, annunciator, . . .etc 6 INFO_rcv integer input quad port ram buffer index (timeslot) 7 INFO_xmt integer output quad port rarn buffer index INFO_talker integer talklist resident indicator 9 INFO_mode integer toneorsilence indication ;~ - 56 INFO_time integer tone or silent period duration 11 INFO_switch integer tone initializationindicator 12 INFO_count integer digit buffer index 13 INFO_xtdl float double tone state variable; x[n-1]

14 lNFO_xtd2 float double tone state variable; x[n-2]
INFO_ytdl float double tone state variable; y[n-1]
16 INFO_ytd2 float double tone state variable; y[n-2]
17 INFO_clo float coefficient of low member of tone pair 18 INFO_chi float coefficient of high member of tone pair 19 ~NFO_yldl float dtmffilter#1 statevariable;y[n-1]
~NFO_yld2 float dtmffilter#1 statevariable;y[n-2]
21 INFO_avmyl float dtmffilter#1 - outputaveragemagnitude 22 ~NFO_y2dl float dtmf filter #2 state variable; y[n-1]
23 ~NFO_y2d2 float . dtmf filter #2 state variable; y[n-2]
24 INFO_avmy2 float dtmf filter #2 - output average magnitude INFO_y3dl float dtmf filter #3 state variable; y[n-1]
26 ~NFO_y3d2 float dtmf filter #3 state variable; y[n-2]
27 ~NFO_avmy3 float dtmffilter#3 - outputaveragemagnitude 28 INFO_y4dl float dtmf filter #4 state variable; y[n-1]
29 INFO_y4d2 float dtmf filter #4 state variable; y[n-2]
INFO_avmy4 float dtmffilter#4 - outputaveragemagnitude 31 INFO_y5dl float dtmf filter #5 state variable; y[n-1]
32 INFO_ySd2 float dtmf filter #S state variable; y [n-2]
33 INFO_avmy5 float dtmffilter#S - outputaveragemagnitude 34 INFO_y6dl float dtmf filter #6 state variable; y[n-1]
INFO_y6d2 float dtmf filter #6 state variable; y[n-2]
36 ~NFO_avmy6 float dtmffilter#6 - outputaveragemagnitude 37 INFO_y7dl float dtmf filter #7 state variable; y[n-1]
38 rNFO_y7d2 float dtmf filter #7 state variable; y[n-2]
39 INFO_avmy7 float dtmffilter#7 - outputaveragemagnitude INFO_avmyt float O.S * (avmylo + avmyhi) 41 INFO_peak float greatest magnitude of 256 samples 42 INFO_sum float sum of 256 sarnple magnitudes 43 INFO_intcnt integer inter digit count 44 INFO_pfcnt integer sarnple count; 0 - 256 INFO_rowcol integer dtrnf digit row and colurnn 46 INFO_talkdet integer talkdetectindication 5.2 Channel Confer~nce List As entries are removed from the~channel conference queue a list is m~;..t~ d intern~lly. The list is in port number order and contains the conference number a port is nefl to.
5.3 Talk Lists Each conference has a Talk List assigned to it. The Talk List is a three member FIFO
queue. As participants satisfy the talk list criteria they move onto the talklist until pushed off ..

~ ~4~

by future conference activity. If a port is moved to a new conference or muted, it is purged from the current talk list.
5.4 Talk Bit Translation Table During each sample period a DSP node can transmit one byte to cornmunicate new talk list candidates. The bit positions correspond to the sequential order of the ports serviced by the node. A non-zero bit indicates that the corresponding port is a candidate. The translation table members are 32 bit words. The table members are ~ccesse~l using the talk bits as an index. A string of four bit numbers is recorded within each translation word to denote the specific bits set in the index. Each number equals bit position plus one. The four bit numbers within the translation word are processed right to left. As numbers are processed the 8 nibble string is shifted right 4 bits to place the next nibble at the extreme right. A zero value in this location indicates end of string. The port numbers written to the talk lists are formed from these numbers; Port Number = (Node << 3) + (N-1).
Talkbits (byte) Translation (word) ~~~~~~~~ =>1~1~1~1~1~1~1~1~l 00000001 =>1010101010101011 00000010 =>1010101010101012 00000011 =>1010101010101211 00000100 -->1010101010101013 00000101 =>1010101010101311 00000110 =>1010101010101312 00000111 =>1010101010~31211 00001000 =>1010101010101014 ,.",."""""" => , """"""""" => , """"""""" => , 11111100 =>1010181716151~13 -11111101 =>1018171615141311 11111110 =>1018171615141312 ,, 1 1 1 1 1 1 1 1 =>1817161514131211 6.0 Data and ~nterrupts 6.1 Data I-~put Input data is ~ ,lilled from the Tl interface via the input MVIP bus at 64 Kbits (8000 sarnples/sec). The serial to parallel converter deposits the input sarnples in the quad port ram. Prior initi~li7~tion (by the host) of the Receive Control Register (value = 01H) positions four 256 byte buffers at address 0000H. One quad port ram contains buffers for nodes A and B, while the other contains buffers for nodes C and D. The buffer pairs alternate within a quad port ram. The buffers automatically switch ~s interrupts occur. The external pin XFl has been configured to indicate the buffer being filled. As XFl toggles its current 2 ~ ~ 4 4 6 4 state is mirrored by bit #7 of the IOF Register. The IOF register is queried following the ~fVIP interrupt; TSTB 128,IOF. The result ofthis test causes the correct address to be loaded into the buffer pointer.
6.2 Data Output Prior initialization (by the host) of the Transmit Control Register (value = 85H) positions four 32 byte buffers at address 0400H in the quad port ram. One quad port rarn contains buffers for nodes A and B, while the other contains buffers for nodes C and D. The buffer pairs alternate within a quad port ram. The parallel to serial converter transfers the data from these buffers to the output MVIP bus at 64 Kbits (8000 samples/sec). The buffers automatically switch as interrupts occur. The external pin XF0 has been configured to indicate the buffer being transferred. A~ XF0 toggles its current state is mirrored by bit #3 of the IOF Register. The IOF register is queried following the MVIP interrupt; TSTB 8,IOF.
The result of this test causes the correct address to be loaded into the buffer pointer.
6.3 Mulaw to Linear Conversion The data entering the conference system is in eight bit u255 format (mulaw -psssqqqq). The polarity bit (p) determines the sign of the number. sss is the segment number of the piece-wise linear logarithmic approximation curve. qqqq represents the qll~nti7~tion number within a segment. Conversion of mulaw data (psssqqqq) to floating-point linear is accomplished by table look up. The mulaw codeword is used as the table index.
6.4 Linear to Mulaw Conversion The conversion has been implemented by indexing into an 8K table, based upon thefollowing sequence of steps. The number is converted to an integer. The mulaw polarity bit (p) is set to 0 or 1, indicative of either a positive or negative number. The number is replaced by its absolute value. The bias factor 33 is added to the absolute value. If the value is greater than or equal to 8192, sss=7 and qqqq=F. Otherwise the bit position of the highest non-zero bit is ~let~rnined. The segment number (sss) equals the bit position minus 5. The quantization bin number (qqqq) is equal to the four bits immef~i~tely following the high non-zero bit. Form the mulaw code word psssqqqq from the individual parts. Complement the code word prior to tr~ncmi~sion.
6.5 Interrupt Ser-~ice Yec~ors Unlike the microprocessor mode, the microcomputer/boot loader mode uses a dual-vectoring scheme to service interrupt and trap requests. In a dual-vectoring scheme, branch instructions to an address, rather than direct inte.~ vectoring are used. The TMS320C3 l's last 63 locations of RAM Block I (address 00809FCIH) are assumed to contain interrupt and trap branch instructions. The following code segment is written to that location prior to bootloader operations.

- sg ~ 4 _INT0 BR mvip ; MVIP data ready in quad port ram _INTI BR mailbox; Host/Dsp mailbox _INT2 BR OOOOH; Boot Loader _INT3 BR errant ; inactive interrupt _XINT0 BR errant ; inactive interrupt _RINT0 BR errant ; inactive interrupt .space 2 _TINT0 BR errant ; inactive interrupt _TINT1 BR errant ; inactive interrupt DINT0 BR errant ; inactive interrupt .space 20 _TRAP0 BR errant ; inactive interrupt .. .. .. .. .. .. .... .. .. .. .. .. ..
.. .. .. .. .. .. .... .. .. .. .. .. ..
_TRAP27 BR errant ; inactive interrupt 6.6 MVIP Data Ready Interrupt Service Routine "mvip" is the MVIP frame interrupt service routine. In order to avoid context save, no work is actually done in the interrupt service routine. At the beginning of the processing loop, the program waits as long as register BK=0. The interrupt service routine sets register BK to 1 as a signal for program continuation. At program continll~tion BK is set to 0. The mulaw data is processed directly from the input buffer.
6.7 Node Mailbox Interrupt Service Routine "mailbox" is the Node Command Processing interrupt service routine. The hl~t;ll.lpt service routine reads the Host/DSP mailbox at dual port memory location FCOFFFH. The word in the mailbox indicates the action to be taken.
7.0 Node Command Processin~
Some command processing is necessary at the Node level. At present I see this being used primarily to allow orderly progress through the initialization phase. During system initialization, a Node waits in a loop for mailbox comm~n~ls from the Host. The comm~ncl.
are input via the Host/Dsp mailbox in the dual port memory at location FFE (lFFC in byte offset from the PC side). When the host writes a comm~nt~ to the mailbox, the DSP is interrupted. The DSP clears the interrupt by reading the mailbox and branches to the procedure which handles the command.
Commands Actions OOOOH No command OOOIH Enter Node Command Mode (future use) 0002H Invoke Boot Loader 0003H Synchronize with other processors and enter Charmel Command Mode " c . .

7.1 Invoke Boot Loader The Host initially invokes the Boot Loader by resetting the processor. In this implementation the input file is expected to be input via the dual port memory. The dual port memory is of limited size (4kx16). The Boot Loader will have to be re-entered as many times as required to transfer the entire input file. The first section of code to be loaded will consist of the comm~nd interpreter for Node Level Comm~nd processing, the interrupt service branches and a waiting loop. The Boot Loader entry point is read from address OOOOH and written to the INT3 interrupt branch field at location 0809FC3H. Interrupts ~NT2 and INT3 are enabled. If the next comm~nfl is Invoke Boot Loader (0002H), the DSP sets bit #3 in the CPU Interrupt Flag Register. This generates an interrupt, which causes a branch to the entry point at which the Boot Loader normally polls the IF. Subsequently, a branch is made to the Boot Loader section responsible for transfers from the dual port memory. Upon completion of each block transfer, control again returns to the waiting loop.
7.2 TMS320C31 Processor Synchronization Each processor branches to a waiting loop following boot loader operations on its node. The Host issues the command Synchronize (0002H) by writing to the mailboxes. Each DSP branches to the mailbox interrupt service routine and retrieves the command. In response The DSPs branch to a synchronize procedure and enable interrupts. Each processor sets and transmits bit #0 in its Talk Bits Byte. Following the next interrupt, each processor retrieves all the transmitted bits and arranges them in register bit positions corresponding to the sender's node number. The goal is to form a pattern, which mirrors the active node mask.
All processors will repeat the process until the goal can be attained globally.
8.0 Channel Command Processin~
The host communicates a comm~n~l to a channel by writing a non-zero value to theChannel Comm~n(l field. The DSP decodes the comm~ntl, executes a specific software routine and sets the channel comm~n(l field to OOOOH indicating completion. The host writes a comm~nCl to a channel only when the Channel Command field equals OOOOH. If a comm~n~ prQ.cessing error occurs, the DSP writes FFFFH to the Channel Comm~n-l field and a nurnerical value to the Channel Error field. In this case the Host must take some corrective action.
8.1 Record Voice Data Record allows an annunciator channel to transfer mulaw data, entering via the quad port ram, to a disk file. The processor receives the command Start Record (0003H) on an armunciator channel. The Dual Port Memory resident buffers are filled alternately starting with #0. Prior to filling a buffer the DSP must first acquire its semaphor and subsequently set it active low. Completion of a fill operation requires the DSP to reset the semaphor, write the corresponding Data Buffer Ready value to the Channel Event Queue, and write OxFFFF to the host mailbox at address FCOFFFH, generating an interrupt. If the channel is not an - 61 - ~ 4 ~

annunciator, the host has committed an error. FFFFH is written to the Channel Comm~nd field. The error indicator value 0001 H is written to the Channel Error field. The host tennin~tes Record by issuing the command Stop Record (0004H).
8.2 Play Voice Data Play allows an annunciator channel to transfer mulaw data from disk to the output MVIP bus via the quad port ram. The processor receives the comm~n~l Start Play (0001 H) on an annunciator channel. The Dual Port Memory resident buffers are filled alternately starting with #0. Prior to emptying a buffer the DSP must first acquire its semaphor and subsequently set it active low. Completion of a empty operation requires the DSP to reset the semaphor, write the corresponding Data Buffer Ready value to the Channel Event Queue, and write 0xFFFF to the host mailbox at address FCOFFFH, generating an interrupt. If the channel is not an annunciator, the host has committed an error. FFFFH is written to the Channel Comrnand field. The error indicator value 0002H is written to the Channel Error field. The host termin~tes Play issuing the command Stop Play (0002H) 8.3 Tone Generation Tone Generation is accomplished in software by recursive production of the unit sample response of a second order harmonic oscillator.
y[n] - (2.0 * R * COS(a)) * y[n-l] + (R*R) * y[n-2] = x[n]
a= (2.0*p*f)/F
f= tone frequency, F = 8000.0 samples/sec, p = 3.1415927, R = 1.0 The behavior of the oscillator is determined by the coefficients of the y terms. The frequency of oscillation depends upon alpha, while damping is controlled by R. R is the distance of the pole from the unit circle in the complex Z-plane. For an oscillator R equals 1.0, placing a pole directly on the unit circle at the frequency of interest. Production of samples com~ences two sample periods beyond t = 0 t = 2, x[n] = 0, y~n-1] = 2.0 * R * COS(a), y[n-2] = 1.0 The samples produced lie between -1.0 and +1Ø Multiplication by a scaling factor adjusts the samples to the proper power level. Scaling factors are provided to the DSP as Decibel values. Conversion to a linear scaling factor is acco~ )lished prior to use. The scaled samples are converted to mulaw, complemented and written to the channel's quad port ram buffer. One new output datum is produced each sample period.

i_ "j 6 2 - ~ 4 8.3.1 DTMF Acknowled~e Tone The Host issues the comm~nd Generate DTMFAcknowledge Tone (0007H) to a channel in response to reception of a valid DTMF tone. Sequence: { [single tone - 1477 hz, 200 msec], [single tone - 1447 hz, 200 msec}.

8.3.2 Conference Entry Tone The Host issues the comm~ncl Generate Conference Entry Tone (0008H) to all conference channels in response to entry of a new conference participant. Sequence: {[single tone - 1209 hz, 200 msec]}.

8.3.3 Conference Exit Tone The Host issues the comm~ncl Generate Conference Exit Tone (0009H) to all conference channels in response to the departure of a conference participant. Sequence:
{[single tone - 1633 hz, 200 msec]}.

8.3.4 Security-On Tone The Host issues the comm~n-1 Generate Security-On Tone (OOOAH) to all conferencechannels when the moderator toggles conference security on (DTMF 7). Sequence: {[single tone -1209 hz, 200 msec], [single tone - 1336 hz, 200 msec]}.

8.3.5 Security-Off Tone The Host issues the comm~n~l Generate Security-Of~Tone (OOOBH) to all conferencechannels when the moderator toggles conference security off (DTMF 7). Sequence: {[single tone -1209 hz, 200 msec], [single tone - 1336 hz, 200 msec], [single tone - 1209 hz, 200 msec] } .

8.3.6 Dial a Telephone Number - DTMF Generation DTMF generation is accomplished by s.. l.. i~-g the scaled output samples of two second order harmonic oscillators, implemented as described previously. The oscillator frequencies are taken one each from the row and column frequencies; row: 697, 770, 852, 941 column: 1209, 1336, 1477, 1633. The DTMF on and offtimes are specified as system pararneters. A number to be dialed is placed by the Host in the Channel Digits-out field (ASCII). The Host issues the command Dial a Telephone Nu m ber (0005H) to a channel.
The double tones corresponding to the ascii digits are generated one at a time separated by pauses. One output datum is generated each sample period.

,_ 8.4 Acknowle~e When the host wishes to determine if a DSP node is functioning, the comm~n~l ~cknowledge (0006H) is issued to a channel serviced by that DSP. If it can, the DSP
responds by clearing the comm~nd field.
9.0 Talk During a conference the speaking privilege is rationed among the active channels.
9.1 Talk Detection The articulated speech signal exhibits non-stationary characteristics, which are the basis for distinguishing it from noise. A simplified model of the speech signal equates it to the product of two random processes: an "envelope" and a "carrier". The carrier has a spectrum lying between 300 and 3400 Hz, while the bandwidth of the much narrowerenvelope is 0 to 50 Hz. A channel's activity level is tracked continuously using a single pole integrator. The cut-off frequency of the integrator should completely elimin~te the fine structure due to the carrier, but pass the rough structure due to the envelope undisturbed.
Input to the integrator is the magnitude of the current codec sample on that channel. The output is considered the average magnitude of the input signal. This calculation is also done for the composite conference output to yield a conference average magnitude.
mk[n] = (1.0-a) * mk[n-1] + a* ABS(x[n]) a= 0.01 = "filtertimeconstant"
((1.0 - a) / a) = 99 = number of samples integrated over A channel has to be on a Conference Talk List in order for its voice data to be broadcast. Two conditions must be satisfied for ~rlmi~sion to the talk list. A channel is considered talking when its integrator output is greater than the talk level threshold (-3 5 dBm).
(i) mk[n~ > TalkLevel => "talking"

An above threshold çh~nnel is considered a candidate for the conference talk list, if its average m~gnit~ e is greater than one third the average magnitude of the conference.
(2) mk[n] > (ml[n] + m2[n] +m3[n]) / 3 => "talklistcandidate"

, ~

'~ - 64 9.2 Talk IJists Each processor has 8 bits reserved for MVIP bus broadcast of talk list candidacy.
One bit is reserved in sequential order for each of the channels a processor is responsible for.
If a channel satisfies both of the stated criteria its talk bit is set. Each processor writes its talk byte to the quad port ram for broadcast over the MVIP bus. The talk bytes are made available to all processors next sampling period. One talk byte is processed per sample period in round robin sequential order. Each node also transmits a sequential count variable which corresponds to the node numbers. The count variable specifies which node's talk bits are to be processed this sample period. Only the lowest active node's count variable is heeded.
Synchronization is thus m~in~ined by the lowest active node. The processor accesses the Channel Conference List to determine what conference the candidate belongs to. The talk byte acts as the index into the talk bits translation table. The corresponding talk list is updated with port nurnbers formed by the conc~ten~tion of the count variable (node number) with sequence numbers removed from the translation table. The new candidates are added at the top of the list as current members are pushed down and eventually off. If a processor adds or removes one of its channels from the list, it must update the relevant items in its internal information data structure. A muted or current talk list channel is never eligible for Talk List consideration. When a talk list member talks or becomes quiet, the DSP informs the HOST. The DSP sets the Chan_talk field to either 1 (talking) or 0 (silent).-9.3 Broadcast Each DSP node uses its channel conference ~ssignments and the Conference TalkLists to determine which quad port ram input samples are to be summed, scaled, and to whom broadcast. If a channel is on a Talk List his speech sample is not included in the sum broadcast to him. A channel, whose music indicator is set, receives music instead of voice data.
10.0 Music Music can be supplied to any conference participant. If the Channel Data Structure's Music (CHAN_music) indicator equals " 1", data samples from the music input time slot are routed to the ch~nnel~ time slot over the output MVIP bus.
-1 1.0 Record/Pl~yback A channel is a Record/Playback Charmel if its corresponding MVIP time slot is arecord/playback time slot. The Time Slot Type field of the Channel Data Structure should equal 0005H. Though in~nim~te a Record or Playback Channel is treated virtually the same as a regular conference participant. The mode of operation is dependent upon the mute status. If unmuted the channel can gain access to the talk list and broadcast to conference participants Otherwise the channel will act as a passive conference participant and listen w -- 65 --(record). A Record/Playback Channel is placed in a conference by placing an entry in the dual port memory Conference Queue.
12.0 Link Line A channel is a Link Line Channel if its corresponding MVIP time slot is a link line time slot. The Time Slot Type field of the Channel l:)ata Structure should equal 0006H. A
Link Line joins two DCBs and is capable of transmit and receive of voice data. A Link Line Channel is treated the sarne as a regular conference participant.
13.0 I~TMF Detection Dual Tone Multi-Frequency (DTMF) is the generic narne for push button telephone sign~ling. DTMF si~;n~ling allows channels another means of communicating with the DCB.
Valid DTMF digits include; "0" = Help Request, " 1 " = Add to Q&A queue, "#" = remove from Q&A queue, {"1" - "9"} = Polling responses. DTMF detection is performed on conferee channels constantly. A DTMF signal results from the addition of two sinusoids at - different frequencies. The frequencies are selected from row and column frequency groups, having four members each. The row frequencies are 697, 770, 852 and 941 hertz. The colurrm frequencies are 1209, 1336, 1477 and 1633 hertz. Decoding a DTMF tone requires separation and i~entific~tion of the members forrning the tone pair. The input samples are input to a parallel bank of eight infinite impulse response digital resonators, centered at the previously listed frequencies.
yk[n3 = (al * x[n~) + (a2 * x[n-1~) + (bl * yk[n-13) + (b2 * yk[n-2]) bandwidth = (0.03 ~ f) + 4.0 filter coefficients frequency al a2 bl b2 697 0.0782560 -0.06689201.6912040 -0.9806259 770 0.0851360 -0.07014401.6279699 -0.9789406 852 0.0928640 -0.07298801.5507061 -0.9770511 941 ~ 0.1012520 -0.07505601.4596493 -0.9750043 1209 0.1265120 -0.07418001.1460505 -0.9688669 1336 0.1384800 -0.06976800.9795147 -0.9659721 1447 0.1517720 -0.06172000.7838895 -0.9627682 1633 0.1664720 -0.04891200.5571413 -0.9592359 Each resonator has associated with it a single pole integrator for measurement of its output.
rnk[n] = (1.0 - a) * rnk[n- 1] + a * ABS(y[n]) a= 0.0119934 For a single tone the magnitude of the integrator output approaches the rms value of the signal. A DTMF digit is indicated when a row frequency and column frequency dominate their respective groups. To be valid the two magnitudes must lie between -30 dBm and +3 dBm. An integrator's output magnitude must represent more than half the total energy of its group. A DTMF signal is considered present as long as the two single tones are above -30 dBm. It is expected that these conditions will prevail for 32 milliseconds prior to further testing. When considered over the total time present, this becomes an exercise in repeated trials with the probability of a correct determination increasing with the nurnber of observations. The statistical differences between tones and speech are used to increase the certainty of DTMF detection. The Gamma probability density function is a good approximation to the probability density function of speech amplitudes. A single tone's amplitude probability density function is uniform. The amplitude probability density function of a double tone is the convolution of two uniform probability density functions and is therefore triangular. These statistical differences manifest themselves in a factor called peak factor. Peak factor is defined as the ratio of peak magnitude to root mean square value during some time interval. The time interval chosen is 32 msecs. To simplify the calculation the average magnitude rather than the root mean square value is used. For double tones embedded in white noise the resulting value falls within the interval; 2.344 - 2.714. In contrast, the peak factor range of speech is 3.5 - 27Ø A valid DTMF tone should be longer than 40 msec and above a threshold of -30 dBm. The difference in power between the tones should not exceed 8 dB. Any other energy must be 20 dB below the DTMF power for 40 msec to guarantee detection. When a new digit is detected it is written to the dsp/host channel event queue in the form xx02h. The DSP interrupts the host by writing OxFFFF to the dsp/host mailbox at address FCOFFFH.
14.0 Volume Controls The energy levels of output signals are controlled. This is necessary both for user comfort and conformity to compliance standards.
14.1 Systeni Wide Gain A system-wide multiplicative gain factor is always applied. The magnitude of this factor is indicated by a gain parameter, having 16 binary values (0000 - 1 l 1 1). The gain parameter acts as index into a table cont~ining the multipliers, which each correspond to a specific dB change. The gain factor is initialized on request or at initialization.
14.2 Automatic Gain Control A composite conference output sample is transmitted to each conference participant.
These output samples are subjected to either automatic gain control or automatic limiting. In either case the necessary multiplier is read from a table containing 128 values. The mulaw equivalent of the conference average magnitude acts as the table index. The tables were computed by converting a power level input/output characteristic to one involving signal magnitudes.
Po = average output power Pi = average input power Mo = average output magnitude Mi = average input magnitude AGC Function Po = -16.0 + 0.3*(16.0 + Pi) yielding in terms of average magnitude Mo = 79.582009 * MiO 3 Limiting Function Po = -13.0 + 0.1*(13.0 + Pi) yeilding in terms of average magnitude Mo--379.21491 * MiO 1 The table values are the ratios of the Mi's to the Mo's. The Mi's are the linear values corresponding to the mulaw values 00H to 7FH. The resulting tables are piece wise linear and have the sarne q~ ti7~tion bin behavior as the mulaw table. The multiplier chosen from the table does not often change in response to a small change in the conference average magnitude 15.0 Prog.ram Flow (1) Wait for interrupt (2) Updateparametersifnecessary (3) Process Channel Commands (if comm~n-1 field is non-zero) (4) TalkDetect (5) DTMF l~etection (6) Output Voice Sums, Music, Annunciators or Playback to Channels (7) Update Talk Lists (8) Service Conference Queue 16.0 Real~ime Operation Each TMS320C3 I DSP microprocessor comprising the Digital System 70 Conferencing Bridge must execute all of the tasks it~mi7Pd in item 15.0 completely every 125 microseconds. Successful operation of the system is dependent upon this. Thedistribution of tasks (i.e. channel type; conferee, annunciator, operator, linkline, .,. .;
. ~

- 68 ~

record/playback) per node is itemi7~d in document # 14002082, "DCB Tables for MVIP Bus and Related ~si~nments".

~' ~ ~ ~ 4 ~ ~ ~
APPENDIX C
Introduction The DCB-96 will be an all digital audio conference bridge, featuring 96 ports in the first release. Four Tl trunk interfaces provide access to the 96 conference ports. Digital Signal Processing will combine the required speech samples and transmit them to the conferees. Two analog ports provide the ability to expand a system -- linking it to another DCB-96 or an installed LINX system 60. Operators can monitor conferences through eight analog ports; and music may be sent to the conferees on another. The system will be available in three sizes, 24, 48, 72, and 96 ports initially. Future expansion to 144 ports will be studied, but will not be part of the initial release.

The T1 provides access to the bridge through the telephone network. The speech samples flow onto the DSi section of the MVIP Bus where they are accessible to all of the Quad DSP boards. Digital Signal Processors (DSPs) can analyze the speech, analyze tones, generate tones, and combine add speech samples. The DSPs can then output the speech onto the DSo section of the MVIP Bus. These output speech samples are transmitted to the listeners through the T1 card and the telephone network. An analog board provides access to the system for operator headsets, music, playback & record, and link lines to other bridges. A
486 processor runs the UNIX operating system, downloads codes to the Quad DSP Boards, controls the conferences, etc. A serial card provides access to operator terrnin~l~, either directly or through modems. A modem card is provided for remote maintenance.

Interface Specifications The following is a summary of the hardware specifications at the interfaces to the system. Some hardware features are not supported in the first software release.
. ~
T1 Interface Frame Rate 8 kHz Bit Rate 1.544 MHz Framing Pattern D3/D4 (12 frame pattern) or Extended SuperFrame ( 24 frame pattern) Supervisory Common Channel Sign~lling (Primary Rate D Channel) Sign~lling Termin~ting 100 Ohms Impedance Cable Type Shielded twisted pair(l pair transmit; l pair receive) Plug 8 PinModularPlug P~

- 70 _ Maximum cable 655 feet length Clocking Normally received from network (+/- 130 ppm) Optionally internally generated Operator Interface Audio 4 wire headset, 6P4W modular plug;
24 VDC Max, 30 mA Max 600 Ohms, >30 db return loss Data RS-232, DB25 Other Audio Interfaces Link Line 4 wire, 6P4W modular plug 600 Ohms, balanced dry connection Record/Playback 2 wire, 6P4W modular plug 600 Ohms, balanced dry connection Music 2 wire, 6P4W modular plug 600 Ohms, balanced dry connection Alarm Interfaces Major Alarrn 2 contact closures rated at l00V, lA
Amber LED indication Minor Alarm 2 contact closures rated at 100V, lA
Amber LED indication CPU LED fl~hing green LED
Local l~inten~nce Port RS232,DB9 T1 Telephone Interface Board T1 advantages Using T1 telephone interfaces in place of analog 2500 set illlelf~ces provides the following advantages --Low noise, No ~(e.~ l;on, Low cost, Reduced cabling, and Dense p~ck~ging per telephone channel, Alarrns for system maintenance.

I~

_ 7~

T1 circuits are commonly restricted to trunk interfaces, which will provide quick call set up and disconnection and features such as ANI and DNIS.

Mitel The DCB-96 will use the Mitel MB89110 Dual T1 Card. It provides 48 telephone trunk circuits with two Tl interfaces and offers the following features --Two T1 interfaces per card, Programmed through PC bus, Extended Super Frame, D3/D4, or SLC-96 Framing options, Robbed bit (channel associated) ~i~n~llin~ of each trunk, or common channel si~n:~lling, Alarm detection and generation, Diagnostic loop back, DSX line equalization, MVIP interface with a Time Slot Interchange ability, Hand set jack for test purposes, Certified in US and C~n~
Description of Hardware The card supports two independent, bi-directional T1 lines. Each T1 requires a Line Interface Unit Circuit which amplifies the received signal, recovers a clock signal from the received bit stream, amplifies and shapes the tr~n~mitted bit stream. Each T1 also requires a framer circuit. This framer circuit assembles the 24, 8 bit, Pulse Code Modulated speech samples into a frame. It adds the framing bits and robbed bit ~ign~llin~ bits when required on the transmitted signal. It also reverses the process in the receive direction. All of the speech samples flow through a time slot interchange switch matrix. This matrix is programmed through the AT Bus. Once programmed, the switch repetitively connects any T1 time slot to any time slot on the MVIP bus, or connects a tirne slot to a data memory in the switch accessible by~he AT Bus, or connects a time slot to the other T1. This switch is discussed in more detail later in this section. The 48 port capacity provided by this card reduces the board count 24:1 over the L~NX product.

Hardware Setup T1 line connection One top connector (J1) is referred to as trunk A and another connector is referred to as trunk B. The board should be optioned as the user side of the line. Optioning the board for the network side reverses the transmit and receive pair assignments.

;,,~. ~

T1 line Equalization The output can drive up to 655 feet of cable. Equalization is provided in three steps from 0 to 655 feet. This cable equalization is for the cable distance from the DS60 to a DSX-1 crossconnect panel if there is one. (The DSX-1, crossconnect panel, is a restoration facility in large telephone offices. Where the DSX-l is not used this is the demarcation point where service is handed with the far facility. If the far end equalizes the entire cable length, use a length of 0 feet in setting the cable length.) PC Interrupt Interrupt IRQ 12 is the standard selection on P4 (the jumper on header P3 would move to P4) of the board. The board offers IRQ 3, 4, 5, 6, 7, 9, 10, 11, 12, 14, and 15 as options. The first T1 board must use thè termin~tion selected by position 6 of header P3. All other boards using the same interrupt should remove the jumper from that position and reposition it so that the lower position of the jumper contacts the higher pin of the header at pin 6. This way the option is not selected, but the jumper is not lost for future reconfiguration.
PC Base VO address The first T1 board will use I/O address 300; the second 2300.
MVIP Bus Positions 1, 2, 3, and 4 of P1 select the tennin~tions for the MVIP bus. These should be optioned on the last board on the MVIP bus. Otherwise the jumpers should be positioned so that the jumper contacts only one pin on the header.
Software Options Tl Framing Chip Setup To initialize the framing device there are Master control words and Per Channel Control Words. There are two Master control words for each T1 framing chip.
Master Control Word l This controls the following functions D3/D4 Yellow Alarrn -- returns the indication that a loss of frarne condition was received if f~aming pattern is D3 or D4.
Robbed Bit -- enables robbed bit ~ig~lling.
ESF Yellow Alarrn -- returns indication that a loss of frame condition was received if framing pattern is Extended Supe,Ldllle.
External Control Pin 8 kHz Output Select -- chip outputs a frame sync signal, only one frarner can beenabled at a time.

-Binary Eight Zero Suppression -- used in wide-band data tr~n~mi~.sions.
Transparent Zero Code Suppression -- stops zero code tr~n.~mi~.~ion in data tr~ncmi.ssions.
Debounce -- removes 6 to 9 ms transitions in the received robbed bit sign~ling information.
Master Control Word 2 This controls the following functions Maintenance Mode -- 4 out of 12 consecutive errored Ft bit causes a RED alarm, out-of-frame.
CRC/MIMIC -- detemmine the mode of finding frame in out-of-frame condition.
SLC-96 Mode select -- not enabl~ed in release 1.
Reframe -- a change from high to low will force the framer to find frame again.
ESF Select -- set for Extended Super Frame7 clear for D3/D4 frame.
All One's Alarm -- sends all l's, blue signal.
DGLOOP -- Used for diagnostics.
Remote loopback -- Used in far end testing of T1 line.
Normally the Master Control Word2 is 00 for D3/D4 framing, and 10 for Extended Superframe.
Per Channel Control Wordl This controls three functions on each channel.
Data Channel Enable -- disables the robbed bit sign~lling Per Channel Loopback -- loopback one channel.
Polarity -- inverts the bits in the channel.
Nomlally the PCCW1 is 04.
Per Channel Control Word2 This contains the robbed bit sign~lling infommation. There is one PCCW for each channel.

Time Slot Interchange Setup The time slot interchange circuit is composed of four, 256 ch~nnel, digital switches.
One digital switch chip connects the framers to the MVIP Bus; one connects MVIP Bus to ~the framers; one connects framer to framer; and one connects MVIP channel to MVIP
channel. Each device must be programmed to set the necess~.~ connections bet~,veen 256 inputs and 256 outputs.

Also7 each switch device contains intemal memory that may be comlecled to a channel input or output. The AT bus can assess this memory to control the supervisory signaling. The memory is bank switched by a control word; therefore only a small portion of the memory is available at one time.

Control Register The control register is accessed anytime that A5 bit is equal to O and the device is selected. The control registers control which serial bit stream can be accessed, and which control byte for each channel in the bit stream. There are four functions in the control register.
Line Address Bits -- to select the serial line to control.
Memory select bits -- select between the following three byes --Data memory ~ Connection Memory Low Connection Memory Hig~hMessage Mode --Split Memory -- When set to 1, reads are from data memory, writes are from Connection memory low.
Connection Memory High This has three per channel control bits.
Output Enable -- can tristate any given channel output CSTo Bit -- (unused in switch #3 & 4, set to 1) Message Channel -- sends information from data memory on designated channel Connection Memory Low Bits This normally deterrnines the input connection for this output time slot. It has two components.
Channel Address -- selects the input channel Line Address Bits -- selects the input line Alternatively, if the channel is ~iesi~n~ted a message channel, the contents of this register are sent.
Framing Format This board supports the two most common framing formats -- the Extended Super Frame or D31~134. The D3/D4 is the largest installed base, while the new ESF is common in new in~t~ tions. This must be optioned to be compatible with the equipment on the other end of the line. Otherwise the system will not find the frame, resulting in a constant alarm condition. This option is set in bit 4 of the Master Control Word 2, offset address OClF.
Supervisory Si~n~llin~
Release 1 of the DCB-96 product will offer channel associated si~n~linE; also known as robbed bit sign~lin~, or AB bit siEn~lin~, or ABCD bit sign~lin~. This forrnat transfers the on-hoolc/off-hook inforrnation in both directions of tr~n~mi~sion. Release I will support E&M forrnat sign~lling. In this case the A bit transfers the inforrnation that a relay would otherwise send. When A =O the channel is idle; when A= I the channel is active. During a ~' - 75 _ ~ ~ ~i 4 ~ ~ ~
call set up period there may be transitions -- winks, etc. For E&M si~n~llin~ the transmitted B, C, and D bits are defined to equal the A bit. On the receive line only the A bit is read.
The sign~ling state is stored in a nibble in the PCCW, the Per Channel Control Word. These are located at offset addresses 0C00 to OClE h.
PC Interface Interrupts The T1 boards will share interrupt IRQ12.
I/O Memory Map Each T1 board must have a unique base address, set by the DIP switch on the board.
Board 1 will use 300h; board 2, 2300h; and board 3, 4300. Eight blocks of memory are defined on each board based on this basè address.
Load and Drive The data, address, and reset inputs will present a 0.1 ma load on the bus. The IOchrdy and the IOchwr inputs will present a 20ua load to the PC bus. The drive capability is 24 ma except for IOchrdy that is 4ma.
Alarms T1 has two important alarms Red (out-of-frame), and Yellow. The alarms are reported to status registers that must be polled. No LED's or alarrn contacts are provided on the option board. When a fault occurs in a T1 line, the terminal on the receiving end generates a Red alarm, and sends a Yellow alarm to the far end. Another condition 'Blue Alarm' is only detected if the signal is unframed; and then it is reported as Red. The Blue alarm state is an all one's pattern generated as a keep alive signal when repeating equipment receives no input signal to transmit. If you receive a blue signal you know you are out-of-service, but you also know the problem is down stream. The T1 Board can send a Blue Alarm to indicate out-of-service conditions.
Customer Service Unit If this board connects to the public telephone network from customer premise equipment, a Customer Ser~ice Unit is required. Also in in~t~ tions where the T1 cable exceeds 655 feet a CSU may be n~cess~ry. The CSU is external box that Drives up to 6000 ft of cable, May tprrnin~te the 130 Volt power feed, Provides loopback functions and Provides a 'keep alive' signal when the conference bridge is serviced.
Provides data buffering, necessary to tolerate clock variations.

~. ~, - 76 ~ 2 Certifications The MB89110, T1 board is certified in the USA and Canada by UL, CSA, FCC, part 68, and DOC CS-03. This board level certification reduces the required system level.

(The MB89120, El board ispending UKcertification to BABTrequirements. However, using this dumb board to support multiple El lines with common channel signalling is an open issue) Di~ital Si~nal Processin~ Board The Tl board connects to the Quad Digital Signal Processing Board through the MVIP Bus. The Receive gate array reads all 256 DSi time slots on the MVIP bus and stores them in a buffer. These PCM time slots are then available to the C3 1 Digital Signal Processor as required. The Digital Signal Processing detects signals, generates tones, and conferences channels together. DSP adds flexibility to the system. DSP provides functions described in code that were previously provided in hardware, allowing rapid changes and additions to functions. All code, commands, host to DSP interrupts, and data structures are sent through the dual port RAM. All output samples are sent in PCM format through the Transmit buffer. The Transmit gate array reads this buffer together with the reference memory and places the time slot on a DSo time slot. There are four TMS320C3 1 processors on each board in this system.

~IVIP INTERFACE
The telephone channels from the T1 boards occupy part of the first six MVIP Bus lines; each T1 uses the first 24 channels on the 32 channel line. The channels 24 to 31 are reserved for operator services, music, recording, etc. The last two lines, D Si(6 & 7), are reserved for inter-processor communication.
I~ECEIVE
A field programrnable gate array writes all information received on the 256 channels into two quaa port rams. Each of these RAMS is connected to two processors. This gives each DSP processor access to all of incoming telephone information. This information is double buffered, i.e. while the new bus information is written into one section of memory, the processors are reading it from another. The content of the RX control register ~letermin~s the memory locations used.

The board provides an option to comle~;l the last two receive lines to the transmit D So(6 & 7) lines, providing inter-processor communication. This option will be enabled in all boards in release 1. The option is e~cercised by setting bit I in the Base Address ~egister.

_ 77 - 2 ~
TRANSMIT --The transmit connections to the MVIP bus attempt to reverse the receive process. The processor can write a speech sample into any of 32 memory locations, each repres~ntin~ a channel on the MVIP Bus. The gate array will automatically retrieve the information and together with a line assignment from the reference memory. This process however contains blocking; because once a speech sarnple is stored in the location for channel 1; it is the only channel 1 that processor can transmit on. This complicates the time slot, or channel ~c~i~nments on the MVIP bus. One processor can transmit up to 32 channels of information as long as each has a unique channel nurnber (0 to 31).

The PC loads the reference memory with a map of channel assignments while the system is out of service. Thereafter the gate array reads a location each time it reads from the quad port RAM and the content of the memory does not change. Every 1 25us frame, the gate array will access 32 locations in the quad port RAM and 32 locations in the reference memory looking to place the quad port information on the bus. One bit in each reference memory is used to indicate if this channel is unused.
DIAGNOSTIC LOOPBACK
A diagnostic loopback circuit is provided at the MVIP interface. Position 8 of SW1 controls the clock connection at the interface. In the ON position, the clock is derived from the 33Mhz board clock; in the OFF;position, the MVIP Bus clock is used.

DSP

Each TMS 320C3 1 Digital Signal Processor operates at 33Mhz. It has static RAM for code and data space. The quad port RAM is used to communicate with the MVIP bus; and ~
dual port ram provides communication with the PC Bus. The four processors on a board can communicate with each other through their serial port or they can cornrnunicate to a sibling through ~e quad port RAM.

PC INTER~ACE
The switch S1 is used set a unique VO address for each board between 10 to 300h.Load and Drive The Quad DSP prese~ a 0.6ma load on the AT bus and a 24 ma drive to the bus.

- 7~ ;i 4 4 ~ 4 -APPENDIX D
SCOPE OF DOCUMENT
This documents is intended as a design specifications document for the Multi-Link DSP Processor or MDP Card.

Provides a functional description of the MDP card, a summary of the various sub-sections in the MDP card is presented.

Describes the PC Interface and Shared Memory Circuit Implementation and Related Timing.

Describes typical TI320C3 1 based DSP Node circuit with reference to Related Timing. The Memory and Register MAPs for each Node is described.

The MVIP Interface using PLD 1 and PLD2 and is described. The functionality of the MVIP Transmit and Receive Sections are described in detail.
INTRODUCTION

The Multi-Link DSP Processor (MDP) is being designed to meet Multi-Link's performance objectives for Voice Conferencing applications. The MDP card is a full size PC-AT card which is based on a distributed processing architecture using four Texas Instru-ments TNS320C3 1 DSP Nodes. The MDP card is designed to process (voice) channel data from eight (Tl/CEPT lines) on the MVIP bus. This design allows all four DSP Nodes access to a total of 192/256 voice channels.
A Feature summary of each sub-section of the MDP card is given below.
FEATURE SUMMARY
PC Interface (detailed in Section 2) - Full 16 Bit PC-AT Interface - I/O Mapping Range 0x100 to 0x3FF
- Memory Mappable ln full 16 Meg Range of PC-AT
- Window sizes of 16K & 32K supported.
- Jumper Selectable PC-AT Interrupts (IRQ3 - IRQ 15) DSP Node, detailed in Section 3) - ?9 - ~ ~ ~ 4 4 ~ 4 Processor 33 MHz Texas Instruments TMS320C31 - 33 MFLOPs - 16.67 MIPS
- 2 K 32-bit Tntern~l RAM
- 64 x 32 Tnt~ l Cache - 16 Megaword Addressing Range Memory:
4 K x 16 Dual Ported SRAM (shared with the PC) 64 K x 32 Private Code SFWM (expandable to 256R) (SIMM Connector) Inter-Node Cornmunications This maybe accomplished via the Quad Port RAM or Dual Port RAM by the PC-Host MVIP Interface (detailed in section 4) The MVIP Interface is to have the following features:
* 1 MVIP Interface Receive PLD
* 1 MVIP Interface Transmit PLD
* Dual Port reference memory which is shared with the PC.
* Two Quad Port RAM which are accessible by all DSP Nodes.
SECTIONS 1 and 2 INTRODUCTION

The MDP card is designed to meet the full 16-bit ISA (PC-AT) specification. The MDP may be Memory mapped in the full 16 Megabyte address range of the PC-AT.

The PC Interface allows the PC to reset, run, upload code via a shared memory window, exchange inLe~l~t~ and data with all four DSP Nodes. This interface allows the MDP card to be uniquely I/O and Memory Mapped in the PC.

I/O MAP

The MDP is I/O mapped into the I/O Address space of the PC Host Processor. The ~/0 base address of the MDP card is determined by the settings of the first six positions of switch Sl.

MDP registers are org~rli7~ into seven Group Base Addresses by the decode logic performed by decoders U7, U9 and U10 in conjunction with PC Address Lines Al0, Al l, Al2 and Al3.

,~ ,"

- 80 ~
There are three functional I/O Mapped register groupings:
a. PC-Interface Control Registers ( IO Address Group 0) b. Dual Port Semaphore Registers ( IO Address Group 1-4) c. MVIP Interface Control Registers ( IO Address Group 5&6) These three groups are described in more detail in this section.
MEMORY MAP

The MDP presents a 1 6K Shared RAM window which maybe opened or closed and rapped anywhere in the 16 MB range of the PC-AT. The Memory Decode and Control functions are performed by the PC Contrlol Register, Base Address Register, Virtual Mode Register and associated control logic. The fimction of these Registers is described in the paragraph on PC-Interface Control Registers.
PC-rNTERFACE CONTROL REGISTERS (IO Address Group 0) The I/O MAP for these group of Registers is selected by PBA13 being low and completely decoded by U10. These registers provide the PC Host processor access to several I/O registers for controlling shared RAM access pararneters, Node Reset and Interrupt Control. The function of each host;register is as described.
PC Control Register (PCR) (R/W) U8 This is a PC Host controlled Read/Write register which controls resetting and rurming the C3 1 processors, opening and closing the shared RAM windows and resetting of the MVIP
Interface Control logic (PLDl & PLD2). This register is cleared on Power-up and by PC
Reset.

Base Address Register (BAR) (R/WJ) U11 The b'ase address of DSP Node Dual Port or MVIP Reference shared RAM Window in PC Memory is set and enabled by writing to this register. The MVIP Reference Memory is shadowed by the Dual Port RAM. ~n the inten(1ed application, the Reference Memory would be ~ccec~ed by the PC-Host during initialization, after which it is switched back into the 'shadowl. Note that the Du~l Port RAM interface for the Nodes is 16 bits, while the Dual Port Reference Memory for MVIP Tlo~ls~lliL function is 8-bit. The format of the MVIP reference memory is described in more detail in Section 4 of this Appendix.

The base addresses should be selected as increments/offsets of the window size of 1 6K. This register is cleared on power-up but not by PC Reset.
,a~

"_ eg. BAR=80 for PC Base Address of 80000 BAR=A0 for PC Base Address of A0000 Virtual Mode Register (VMR) (Ul3) This register is used in mapping the MDP in Extended PC Memory above the 1 MByte Intel Real Mode range. This register in combination with the BAR allows the shared RAM window to be located anywhere in the l 6 Mbyte Addressing range of the 80236/803B6 PC Host. Address AD20 to AD23 are programmed into Bits 0-3. The ENVPM bit in the PCR
must be set to activate the Protected Mode Address defined by this register.

INTERRUPT CONTROL

The interrupt control logic allows each Node to Interrupt the PC Host or the PC
Host to Interrupt each DSP Node separately. The generation of interrupts in both directions is performed by writing into two fixed mail-box locations (offset FFE from the PC-Host side and offset FFF from the DSP Node side) in the Dual Port RAM (IDT 7024).
PC to DSP Node Interrupts The PC which has access to the Right Hand Port of each Dual Port RAM (U29, U35, U42, U48) writes into location FFE, ( lFFC in byte offset from PC side) this causes an interrupt to be generated on the Left Hand Port (INTL). The INTL interrupt outputs of all DPRAM are synchronized by PALs Ul7 and Ul8 before being connected to the /INT1 input of each DSP Node. The DSP Node may clear the interrupt by reading location FFE.
DSP Node to PC Interrupt Each DSP Node which has access to the Left Hand Port of the Dual Port RAM
generates an hlltll.lpt to the PC by writing to location FFF. This causes an hlte~ pt to be generated out of the Right Hand Side of the DP RAM, this INTR h~te~l u~l line (NDX INT) is fed to Ul6 which is responsible for or-ing all Node Interrupts to the PC and driving the selected IRQ Line. The PC has to ~etçrrnin~o the source of the Node Interrupt by polling software defined pararneters in the DP RAM. Since the Inle~ t Line may be sharedthrough a 'WIRED-OR' arrangement, the PC-Host will have to determine the Interrupt Sources by pol~ing the DP RAM of all DSP Cards in the system.

~~ - 82 -The PC may clear each node interrupt by reading location FFF (IFFE in byte offset) in the al,propliate DP RAM. The interrupt level to the PC-HOST is jumper selectable from among IRQs 3,4,5,9,10,11,12 or 15 at J 1 NODE SEMAPHORE REGISTERS (IO Address Group 1-4) These eight registers located within the Dual Port RAM of each Node are IO
Mapped for PC-Host access. The decode down to each register is performed within each DP RAM. These registers are Memory mapped into each DSP Node access the DP RAM
from the Left Port.

The group base address (PC Side) for each Node is as below:
Node A - 2000 + Board I/O base address Node B - 2400 + Board I/O base address Node C - 2800 + Board I/O base address Node D - 2000 + Board I/O base address For each C31 node Semaphore register address is as follows:
RegO B00000 Regl B00001 Reg7 B00007 Example for Node A and semaphore Regl C31 node A attempts to set semaphore Regl by writing 0 to B00001.
If C31 reads back 0. It has control.
If it reads back Oxff, PC has control.
PC ~l~elll~ to set semaphore by writing 0 to I/O address 0x2002 + Board Base Address.
If PC reads back 0. It has control.
If PC reads back 0xff. C31 A has control.
To release sernaphore register, C31 or PC rust write 1 to the ~;spe.;Li~/e address.
MVIP INTERFACE CONTROL REGISTERS (I(~ Address Group 5 & 6) The third I/O decode grouping is for MVIP Receive Control registers internal to PLDI
(U52) and MVIP Transrit registers internal to PLD2 (U50). Up to eight (8 bit) individual registers for each Group Base Address is decoded within each PLD. The functions of individual registers is described in Section 4 of this Appendix.

'- A
.

SECTION 3. DSP NODES
INTRODUCTION

The processing power of the MDP card is provided by four DSP Nodes. The main building blocks for each DSP Node is provided by a 33MHz Texas Instruments TMS320C31 DSP (RISC) Processor, an Address decoder/ wait state generator, up to 256 KBytes of Private (Code) Static RAM, a 4Kx16 Dual Port RAM and a Quad Port RAM. The C31 accesses the MVIP through a Shared Memory Interface for both Receive and Transmit functions.

The TMS320C31 is a cost reduced version of the C30 Processor packaged in a 132-pin plastic guad flat pack. The following is a surnrnary of its features:

* 64x32 byte cache * Two lK Internal RAM blocks * Addressing Range: 16 Meg *DataBus:32 * 1 DMA Controller, 2 Timers & 1 Serial Port.
ADDRESS DECODER & WAIT STATE GENERATOR

The memory address decode function at each node is performed by a SnS, 16L8 PAL.This PAL is selected because there are currently no standard Decoders that can meet the speed requirement.

For access to slower Code and Peripheral Memory, a wait state generator is implemented using a 16V8 GAL in conjunction with a two position jumper. The output of this GAL is fed to the decoder PAL in order to assert wait states. The decoder PAL has a ready output which connects to the Ready input of the C31.

PRlVATE (CODE) RAM

Up to 256K of 32 bit private Code RAM Space mapped between EC0000 to k~
is available to each C31 processor. When 64K x 32 RAM SIMM modules are used, they are mapped from EC0000 to ECFFFF. The Speed of SRAM modules used dictate whether wait- ;
states need to be asserted for accessin~ Private RAM code. (SRAM Speeds of 45 NS require I wait state, SRAM Speed of 25nS does not require wait states.) '. ,~

DUAL PORT RAM (BOOT & PC-INTERFACE) The Dual Port RAM is used for booting each DSP Node and for exchange of Code and Data with the PC Host.

Each DSP node has access to the left port of a (4K x 16) Dual Port RAM, the right port is accessible by the PC. Only the lower 1 6-bits read by the C3 1 Processor contain valid data, the upper 1 6-bits are in an undefined state. Software 'blanking' of the upper 16 bits is necessary to put them into '0' state The IDT7024 has been selected for this application. The IDT7024 includes such features as arbitration control, semaphore registers and interrupt generating mail-box registers. The arbitration control feature asserts a BUSY output signal to hold-off any device trying to access a 'busy address'. The mail-box register locations nay be used by the DSP
nodes and the PC to interrupt each other. A more detailed explanation of this interrupt scheme is provided in Section 2 of this Appendix.
QUAD PORT RAM

There-are two IDT7052 2kx8 Quad Port SRAM, these are shared by two DSP Nodes each. The QUAD Port RAM provide a shared RAM interface to the MVIP Interface Circuit.
Each DSP Node may read and process received MVIP DATA and output data to be Transmitted by the MVIP Interface.

This Quad Port RAM does not feature a~ dtion logic, for preventing address collisions. It is the responsibility of the applications (protocol) code to ensure data integrity. The func-tions of the QUAD PORT RAM in conjunction with the MVIP Interface is described in Section 4 of this Appendix.

SECTI(~N 4~ IVIP Interface INTRODUCTION

The MVIP Interface pelro~l~ls t~,vo basic functions which include receiving MVIP Bus Data from the Serial Input Lines and transmitting MVIP data onto the MVIP Serial Output lines.

The Received MVIP Data is formatted and deposited in Quad RAM receive buffers for processing by DSP Nodes. The Data to be transmitted is formatted for transmit on the NVIP Serial Output bus.
~:} _ ., .~

MVIP RECEIVE INTE~FACE

The functional blocks within PLDI (Actel-1020) device consist of a PC-Host Interface, Control Logic and a Serial to Parallel Converter.

PC-Host Interface - The PC has access to registers for configuring and monitoring the status of this circuit. One register is receive control register. The register includes a 'run' bit.

One register is the 'run' bit (when in 1 state) is responsible for initi~ ing and starting the Receive Interface. The register also includes an 'AddrlO' bit which selects the level of address 10 line. This determines the 1 Kbyte block of the QPR to be written. Bit 3 of this register is Read Only, and provides the status of Address line 9 to the QPR. The Status of this 'Ping-Pong' bit points to the 256-byte block that is being currently written to by the MVIP Receive circuit. STAT1 bits indicate the state of the 'ADDRESS' lines respectively.
A'CLKSEL' bit drives the SELECT line to a PAL, to control clock muxing function.
Other registers in the PC-Host Interface are the Receive and Clock Status registers which are used for diagnostics purposes to monitor the state of the respective lines. An abnormal line state such as 'open' and 'stuck' line can be detected by reading these registers.
Test Mode The 'Test Mode' bit enables the local Test bus loopback path for testing functionality of both the Transmit and Receive MVIP Interfaces. The Test Mode connect all four (4) transmit MVIP lines to the MVIP Receiver. Within the MVIP Receiver these loopback receive lines are 'doubled' by connecting Line 0 to 4, 1 to 5, 2 to 6, and 3 to 7. This doubling of loopback lines allows all the Serial to Parallel conversion logic for 8 lines to be tested.
(Note that the corresponding received data is also duplicated in the receive buffers).
Timing & Corltrol Logic This state m~.hine is .e~l~ollsible for generating the basic timing, muxing, address generation (RAD0-RAD10), write strobes and status lines. This circuit block is les~onsible for writing received data in parallel to two Quad Port RAMS. The received block for each Frarne is written alternately to two 256 byte blocks, a status line (PlNG) which connects to the XFO input of all C3 l's is toggled to indicate the 'current' received buffer.

: ~.
. .

MVIP TRANSMIT INTER FACE (U52, Sheet 7) ~ d~

The org~ni7~tion of functions within this device is the opposite of the Receive Interface device. The main functional blocks include the PC-Host Interface, Control Logic and the Parallel to Serial Converter PC-Host Interface - This interface consists of one control register for controlling and monitoring the Transmit Tnterf~ce. The transmit control register has similar functions to its counterpart in the Receive section.
Parallel to Serial Converter This circuit is responsible for converting byte parallel data to bit serial data forrnat for output onto the MVIP Bus. The logic for this function is the reverse of the Receive Circuit.
Control Logic This circuit generates addresses and performs two data fetches from quad port (transmit buffers) and the 'steering' or reference dual port ~AM.
Transmit Control Register This register must be initialized ~ropliately by the PC Host.
This register is cleared to all '0's on power-up. A value of '1' indicated an active state. Bit 0, the 'RUN' bit is used to start or stop the Transmit 'State Machine'. The 'Test Mode' bit when active enables the four 'Test Output' line feedback to the MVIP Receive PLD. The 'Master Output Enable' bit enables the Transmit MVIP outputs to drive the MVIP bus. This bit must be inactive ln 'Test Mode' but active in normal operation. The 'Addr6' bit is a read only bit which shows the status of the Address 6 line. This bit will 'toggle' when the MVIP Transmit State Machine is in the 'RUN' mode. Bits 4 to 7 of this register are used for locating the base address,,of MVIP Transmit Buffer in the Quad Port RAM.

MVIP TRANSMIT BUFFER MEMORY ORGANIZATION

The MVIP Transmitter uses 2 Quad Port RAMS as the source of data which can be routed out to any of the 8 MVIP Bus output serial streams. The dual-port reference memory which provides the output routing information on a r~l~nnf~l by channel basis is described in the next section.

The transmit buffer section of each Quad Port RAM is partitioned into four 32 byte buffer 3reas. The transmit buffer may be located on any of the sixteen (16) 128 byte A

- 87 - 2 ~
boundaries by progr~mming Address lines 7,8,9 and 10 in the MVIP Transmit Control Register.

The MVIP Transmitter will alternately transmit ('ping-pong') the buffer start address on a frame by frame basis. Bit 3 of the Transmit control register when read by the PC will indicate the current transmit buffer. The Transmit 'PingPong' status is reflected by Address Line 6(TAD6) which is connected to the XFO flag pin at each processor. Each Nodeprocessor can hence track and output to the appropriate transmit buffer.

Each of the 32 bytes of the transmit buffer corresponds to the 32 time slots available on each of the 8 MVIP bus lines. The contents of the MVIP Transmit references memory determines which time slots and lines are to be driven.

MVIP TRANSMIT DUAL PORT REFERENCE MEMORY

This Dual Port Reference RAM is accessible by both the PC and the MVIP Transmit Control Logic. This steering memory should be initialized for each channel ('transmit byte time slot').

The dual port reference memory is partitioned into two 32 byte reference buffers.
This reference buffer is fixed at location 0 within the reference memory. Proper setup of this reference memory (from PC Host) allows data from the any DSP Processor to be steered onto any channel (time slot) of any of the 8 output MVIP lines.

,~A

APPENDIX E
1. Host Software Environment The Host Application software consists of individual processes running under VENIX/386 3.2. This operating system was chosen for a number of reasons:

UNIX standard: VENIX conforms to the standard AT&T system V interface spec. (they are a source licensee of AT&T). This allows our software to conform to the industry standard (SVID). It also allows us to add "shrink wrapped" software in the future if needed (i.e. database, X-Windows support).
Networking: VENIX supports standard TCP/IP and NFS implementations.
This can be used both as a development tool, and can be integrated into the software for future applications (i.e.
communicating to, monitoring multiple bridges).
Real Time: VENIX has a pre-emptable kernal. This way, our software can respond appropriately to real time external events 2. Data Flow Di~ram 3. InterProcess Communications This is a "message driven" system. Each process is assigned an input message queue.
Receipt of a message will "wake up" a process if it is sleeping. Message sending/receiving will follow the standard UNIX guidelines for message passing between processes.
3.1 Standard Mess~e Format Source Process ID Identifies which process sent the message. Each process is assigned a specific "process ID" that will be recognizable by all the other processes. These IDs are assigned at initialization ~ -~.......... time, and not the same as the UNIX PID.
Priority Norrnal or High. High priority messages will get placed ahead of normal priority messages in the destination process's queue.
Tag 0= no response needed to this message; Nonzero= REPLY
expected upon completion of operation (for example, digits dialed successfully). This tag number would be included in the REPLY message. This way, the sending process would know which message was being acknowledged.
MSGTYPE The high byte of the message ID.
CF_COMMAND identifies this message as a low-level command to initiate some action for a channel, or list of channels.

.

- - 89 _ CF_EVENT identifies this message as one that is generated by an asynchronous event (i.e. a Tl line seizing in).
CF_REPLY identifies this message as a response to a comm~n~1 (i.e. dialed digits completed).
CF_GENCMD identifies the message as a general conferencing comrnand to initiate action for channel(s) or conference(s).
CF_HLCMD identifies the message as a high-level comm~n~l These comm~nflc typically get tr~n~l~tecl into multiple low-level comm~nl1s CF_APPCMD identifies the message as an application-level comm~nc~ These commands typically place an entire conference (or the system) into a particular state of operation.
MESSAGE The low byte of the message ID. This identifies the actual message.
wParam Parameter word. Usage depends on the values in the CMD
field.
lParam Parameter long. Usage depends on the values in the CMD field.
data Optional data field. Usage depends on the values in the CMD
field.
3.2. Conference Mes~es The following is a list of message descriptions. The following rules apply:
"Channel" refers to the logical channel number (LCN). LCNs get tr~n~l~te~ to MVIP
timeslots by the various processes that deal with them. LCNs are expressed as hex numbers (0-255).
DIGITDATA refers to a data structure that contains DTMF digits. This is a null terrninated ASCII string of digits (0-9, A-F).
CHANDATA refers to a data structure that contains a list of LCNs. This is a series of LCNs terrnin~te~l by a-1.
3.2.1 T ow T evel Command Mrgg:~s .~ ..
Disconnect Out Description: Physically hang up the line (i.e. go onhook). No DataBase update.
Destination Process: T1 Handler MSGTYPE: CF_COMMAND
MESSAGE: CMD_DISCONNECT
wPararn: channel (LCN) lParam:
r)ata:

9o -Seize Out Description: Seize a line (i.e. go offhook). When this comm~n<l is issued prior to dialing out, it acts as an offhook. When this comm~n-l is issued in response to a Seize In event, it answers the line.
Destination Process: T1 Handler MSGTYPE: CF_COMMAND
MESSAGE: CMD_SEIZE_OUT
wParam: channel (LCN) lParam:
Data:
Fault Line Description: This comm~nfl is a "toggle". The first time it is sent, it faultsout a T1 line. This causes a "seize out" on this line, so it will appear to be offhook. The next time this comrnand is sent, the line is placed back onhook.
Destination Process: T1 Handler MSGTYPE: CF_COMMAND
MESSAGE: CMD_FAULT
wParam:
lParam:
Data: CHANDATA channel list Hookflash Out Description: Initiate a hookflash on a line.
Destination Process: T1 Handler MSGTYPE: CF_COMMAND
MESSAGE: CMD_HOOKFLASH
wParam: channel (LCN) lParam:
Data:
Mute Line Description: This comm~n-l is a "toggle". This comm~nrl either connects or disconnects the "mouthpiece" of the specified line to/from the ~. "earpieces" of the rest of the lines in the conference.
Destination Process: DSP Comm~n~ Processor MSGTYPE: CF_COMMAND
MESSAGE: CMD_MUTE
wParam:
lParam:
Data: CHANDATA ch~nnel list Gain Description: This command either turns on or offthe automatic gain control for a line.
Destination Process: DSP Commarld Processor MSGTYPE: CF_COMMAND
MESSAGE: CMD_GAIN
A

wPararn: On/Off flag IParam:
Data: CHANDATA channel list Put Line Into Conference Description: Place line into a conference. This automatically removes the line from any previous conference it was in. This essentially connects the "earpiece" of this line to the "mouthpieces" of all the other lines in the specified conference. If this line is not muted, it also connects the "mouthpiece" of this line to the "earpieces'' of all the other lines in the specified conference.
Music can be played to this line as well. If music is played, the channel is automatically muted.
Destination Process: DSP Com~and Processor MSGTYPE: CF_COMMAND
MESSAGE: CMD_PUT_INTO_CONF
wParam: Music On/Off flag IParam: conference number Data: CHANDATA channel list Play Tone Description: Generates the specified tone to the specified channel(s) Destination Process: DSP Comm~ntl Processor MSGTYPE: CF_COMMAND
MESSAGE: CMD_PLAY_TONE
wParam: Tone ID
IParam:
Data: CHANDATA channel list Play Announcement Description: Plays a specified digitized voice message to the specified annunciator channel.
Destination Process: Annunciator MSGTYPE: CF_COMMAND
MESSAGE: CMD_PLAY_ANNUN
u;Para~m: message nurnber (predefined to specific filename) IParam:
bata: Annunciator channel number: Specifies the dedicated annunciator channel that the message will be played to. Any line that is to hear this mess~ge must have previously been placed into conference with this ch~nnel.
Filespec: Complete UN~X filename (including path) of file that contains the digitized voice data to be played.
Mode: Single Play or Continuous Play. Continuous Play will cause the message to be repeatedly played until a Stop Armouncement command is issued.

Record Announcement Description: Records a digitized voice message on the specified annunciator channel. Records until a Stop Announcement command is received, or the duration has expired.
Destination Process: Annunciator MSGTYPE: CF_COMMAND
MESSAGE: CMD_RECORD_ANNUN
wParam: message number (predefined to specific filename) lParam:
Data: Annunciator channel number: Specifies the dedicated annunciator channel that will be used to record the message.
The line that is "speaking" the voice message (typically an operator) must have previously been placed into conference with this channel.
Filespec: Complete UNIX filename (including path) of file that will receive the recorded digitized voice data. If the file exists, it is overwritten. If not, it is created.
Duration: Maximum duration of message (in seconds) Stop Announcement Description: Stops the playing or recording of a digitized voice message on the specified annunciator channel. This will, in turn, trigger an Announcement Done event message for that channel.
Destination Process: Annunciator MSGTYPE: CF_COMMAND
MESSAGE: CMD_STOP_ANNUN
wParam: annunciator channel number lParam:
Data:
Dial DTMF Digits Description: Outpulses DTMF digit(s) on specified line.
Destination Process: DSP Comm~n-l Processor MSGTYPE: CF_COMMAND
MESSAGE: CMD_DIAL_DTMF
~Param: ch~nnel (LCN) lParam: -Data: DIGITDATA digit string Start Timer Description: Start a timer. When the specified duration has el~psed the sending process will receive a Timer Complete event message, cont~inin~ the specified tag value. Many di~lel~t timers (TBD) can be running concurrently. If a process needs to have multiple timers running, they must each contain a different tag value.
Destination Process: Timer MSGTYPE: CF_COMMAND
MESSAGE: CMD_START_TIMER

~_ _ 93 _ ~ . . .
wParam: auto-repeat flag lParam: duration (increments of 100ms) TAG: Tag value: Sending process assigns this value so it knows which timer has completed upon receipt of a Timer Complete event message.
Data:
Stop Timer Description: Stops the specified timer. If this message is sent before the timer's duration has elapsed, no Timer Complete event message will be sent for that timer.
Destination Process: Timer MSGTYPE: CF_COMMAND
MESSAGE: CMD_STQP_TIMER
wParam:
lParam:
TAG: Tag value (matches the one specified in the Start Timer message) Get T1 Statistics Description: Obtain current settings of T1 network management statistics.
These values consist of cumulative data collected since the last time the statistics were reset.
Destination Process: T1 Handler MSGTYPE: CF_COMMAND
MESSAGE: CMD_GET_T1_STATS
wParam: starting line (?) (or T1 span?) lPararn: ending line (?) Data: Tl network statistic data (forrnat TBD) Reset T1 St~tistics Description: Resets the T1 network management statistics Destination Process: T1 Handler MSGTYPE: CF_COMMAND
MESSAGE: CMD_RESET_Tl_STATS
wParam: starting line(?) (or Tl span?) lParam: ending line (?) Data:
3.2.2. Asynchrollous Fvent Me~es Seize In Description: This event message is sent when incoming line seizure is detectecl (i.e. someone has dialed in on a particular line). It is also sent when the far end has answered in response to our dialing out.
Destination Process: Call Handler Priority: Normal MSGTYPE: CF_EVENT
MESSAGE: EVENT_SEIZE_IN

wPararn: channel (LCN) lPararn:
Data:
Disconnect In Description: This event message is sent when far end disconnect has been detected on a line (i.e. the far end has gone onhook).
Destination Process: Call Handler Priority: Norrnal MSGTYPE: CF_EVENT
MESSAGE: EVENT_DISCONNECT
wPararn: channel (LCN) lPararn: -Data:
DTMF Digit(s) In Description: At least one DTMF digit has been received on a particular line.
Destination Process: Call Handler MSGTYPE: CF_EVENT
MESSAGE: EVENT_DTMF_DIGIT
wPararn: channel (LCN) lPararn:
Data: DIGITDATA digit string DSP Failure Description: A failure has been detected on a DSP processor. This may mean that voice data is no longer being processed for the specified channels.
Destination Process: Call Handler MSGTYPE: CF_EVENT
MESSAGE: EVENT_DSP_FAILED
wPararn:
lPararn: -Data: CHANDATA channel list T'l Alarm Set Description: A Tl alarrn condition has been detected for the specified t~.h~nnPI~:.
Destination Process: Call Handler MSGTY~E: CF_EVENT
MESSAGE: EVENT_TlALARM_SET
wPararn: type of alarm (red, yellow) lPararn:
Data: CHANDATA channel list T1 Alarm Clear Description: The Tl alarrn condition for the specified lines has been cleared.
Destination Process: Call Handler MSGTYPE: CF_EVENT
e~

MESSAGE: EVENT_TlALARM_CLEAE~
wParam: type of alarm (red, yellow) lParam: -Data: CHANDATA channel list Line Clear Description: This event message is sent in response to a Disconnect Out comm~n-l Typically, when a line goes onhook, there is a "guard time" that must elapse before it can go offhook. Thus, when a Disconnect Out is executed for a line, one should wait for the Line Clear event message before attempting to seize out on the line again.
Destination Process: Call Handler MSGTYPE: CF_EVEN.~
MESSAGE: EVENT_LINE_CLEAR
wParam: channel (LCN) lParam:
Data:
3.2.3. Reply Messsl~es Announcement Done Description: This message is sent when the playing of an annunciator message has completed (in response to a Play Announcement comm~nd). This means that the specified annunciator channel is now available to play another message. It is also sent when the recording of an annunciator message has completed, either by timing out or the sending of a Stop Announcement command.
Destination Process: Call Handler MSGTYPE: CF_REPLY
MESSAGE: E~EPLY_ANNUN_DONE
wParam: annunciator channel lParam: -Data:
~ookflash Done Description: This message is sent in response to a Hookflash Out command.
Typically, a hookflash takes about 500ms to 750ms to complete. This message informs the sending process that the - hookflash has completed.
Destination Process: Call Handler MSGTYPE: CF_REPLY
MESSAGE: REPLY_HOOKFLASH_DONE
wParam: channel (LCN) IParam: -Data:

~,~
~, - ~ - 96 -Timer Complete Description: This message is sent in response to a Start Timer comm~n~l This informs the sending process that the duration specified in the Start Timer comrnand has elapsed.
Destination Process: Call Handler MSGTYPE: CF_REPLY
MESSAGE: REPLY_TIMER_DONE
wParam:
lParam:
TAG: tag (corresponds to the value specified in Start Timer message) Data:
Dial Done Description: This message is sent in response to the Dial Out comm~ncl This inforrns the sending process that the DTMF outpulsing has completed. It does not, however, indicate that the far end has answered.
Destination Process: Call Handler MSGTYPE: CF_REPLY
MESSAGE: REPLY_DIAL DONE
wParam: channel (LCN) lParam:
Data:
3.2.4. General Commands Hangup Channel(s) Description: Tells the Call Handler to generate Disconnects to the specified channels. This also causes the Database entries for each channel to be updated (i.e. channels taken out of conferences).
Destination Process: Call Handler MSGTYPE: CF_GENCMD
MESSAGE: CMD_HANGUP
wParam:
lParam: -Data,~. CHANDATA channel list Toggle Music Description: Tells the Call Handler to turn music on/off for a particular conference. This causes the Call Handler to generate PUT_INTO_CONF messages for each ~h~nnel in the conference with the music flag set app.o~l;ately.
Destination Process: Call Handler MSGTYPE: CF_GENCMD
MESSAGE: CMD_TOGGLE_MUSIC
wParam: Conference number lPararn:
Data:

4 ~J
. ~ -- 97 ---Transfer Channel Description: Causes a channel to be transferred from one PBX line to another. The Call Handler initiates the transfer by hookfl~hin~
and dialing the supplied dtmf digits (the new extension).
Destination Process: Call Handler MSGTYPE: CF_GENCMD
MESSAGE: CMD_TRANSFER
wParam: channel (LCN) lPararn:
Data: DIGITDATA digit string Restore Previous Conference Description: When the operator accesses a channel, that channel is placed into an ope,rator conference. When that happens, the number of the conference that the channel was in is saved. This comm~n-l places the channel back into that conference.
Destination Process: Call Handler MSGTYPE: CF_GENCMD
MESSAGE: CMD_REST_PREV_CONF
wParam: channel (LCN) lParam:
Data:
3.2.5. F~ h Level Commands Blast Dial Description: Initiates a Blast Dial sequence. Basically, the Call Handler finds a free outgoing line, places the operator into conference with it, and dials all the numbers in the specified list.
Destination Process: Call Handler MSGTYPE: CF_HLCMD
MESSAGE: CMD_BLAST_DIAL
wParam: index into dialing lists lPararn:
Data: - -Han~ Up Conference Description: Hangs up all the channels in a conference, and takes them allout of the conference.
Destination Process: Call Handler MSGTYPE: CF_HLCMD
MESSAGE: CMD_HANGUP_CONF
wParam: conference nurnber lPararn:
Data:
Purge Disconnects Description: When a channel hangs up or is disconnected, it cannot be used again until it is "cleared". This comm~nd clears all the disconnects for a specified conference.
~' .

Destination Process: Call Handler MSGTYPE: CF_HLCMD
MESSAGE: CMD_PURGE_DISC
wParam: conference number (-1 = all conferences) lParam:
Data:
Operator Play Annunciator Message Description: This sets up an armunciator conference with the specified operator, and initiates a Play Message sequence. The annunciator channel is allocated dynamically.
Destination Process: Call Handler MSGTYPE: CF_HLCMD
MESSAGE: CMD_OP ANN_PLAY
wParam: operator channel (LCN) lParam: annunciator message number Data:
Operator Record Annunciator Message Description: This sets up an annunciator conference with the specified operator, and initiates a Record Message sequence. The annunciator channel is allocated dynamically.
Destination Process: Call Handler MSGTYPE: CF_HLCMD
MESSAGE: CMD_OP_ANN_REC
wParam: operator channel (LCN) lPararn: annunciator message number Data:
Operator Stop Annunciator Message Description: This command stops the playback or recording of an annunciator message with the specified operator.
Destination Process: Call Handler MSGTYPE: CF_HLCMD
MESSAGE: - CMD_OP_ANN_STOP
wPararn: operator channel (LCN) lP.ararn:
Data:
Set Nighfflme Mode Description: Enabling this mode tells the Call Handler to ignore all incoming line seizures. Disabling it tells the Call Handler to use the original configurations for each ch~nnPI
Destination Process: Call Handler MSGTYPE: CF_HLCMD
MESSAGE: CMD_SET_NIGHT_MODE
wParam: EnablelDisable IParam: -Data: -~' 3.2.6. Application Level Commands Place Conference Into Lecture Mode Description: This comm~nd basically mutes all the channels in a conferenceexcept that of the moderator. This can be enabled or disabled.
Destination Process: Call Handler MSGTYPE: CF_APPCMD
MESSAGE: CMD_LECTURE_MODE
wPararn: conference number lParam: Enable/Disable Data:
Place Conference Into Q & A Mode Description: This comT~l~n(l basically sets up one moderator, enables digit recognition, and places conferees into the Q&A ~ueue upon receipt of digit(s).
Destination Process: Call Handler MSGTYPE: CF_APPCMD
MESSAGE: CMD_QA_MODE
wPararn: conference nurnber lPararn: Enable/Disable Data:
Place Conference Into Polling Mode Description: This comm~ncl basically sets up a moderator, enables digit recognition, and collects digits into various queues.
Destination Process: Call Handler MSGTYPE: CF_APPCMD
MESSAGE: CMD_POLL_MODE
wPararn: conference nurnber lPararn: Enable/Disable Data:
4. Host/DSP Interface The 4Qst software will comrnunicate to the DSP card(s) via the DSP Command Processor, the DSP Event Processor, and the DSP Driver. Refer to the individual descriptions of these processes for more information about them.

Each DSP card contains a block of dual ported RAM; 4k x 16 for each DSP
processor. There are 4 DSP processors on each card. Each DSP processor handles 6 user channels. Each DSP processor also handles TBD ~ tor 5h~nn~1~, and TBD other internal channels. Thus, each 4k x 16 RAM is partitioned into areas to handle each channel.
Each user channel area contains a data structure that describes the current state of the channel.
This data structure will be defined as part of the Host/DSP design.

- 1oo -When an asynchronous event occurs (i.e. digit reported by the DSP), the DSP
processor that handled the event will generate an interrupt. This will cause the card cont~ining that DSP processor to generate an interrupt to the host (i.e. UNIX). The DSP
Driver will process the interrupt. It will figure out which channel the interrupt occurred on, and signal the Event Processor, passing the channel number to it. The Event Processor, having the channel number, will look at the channel data structure for that channel, and figure out what the event was (i.e. incoming digit). At that point, the Event Processor can do what it wants with the information (i.e. signal the Call Handler).

If the host software wants to initiate some action for a channel via the DSP, it does it via the DSP Command Processor. This process initiates action for that channel via the corresponding channel data structure in the shared 4k x 16 R~M for the DSP processor that handles that channel. The actual command processing and han-lsh~king between the DSP
Comm~nd Processor and the DSP will be defined as part of the ~Iost/DSP design.

The Annunciator also has direct access to the 4k x 16 RAM for dedicated annunciator channels. This is described further in the process description for the Annunciator. The actual mech~ni.sm of how the data is passed will be defined as part of the Annunciator process design.
5. Global Data Base Global (system-wide) data structures will be accessible by all processes. For example, multiple Operator Console processes will access this data base for any information they need for their respective console displays. The issue of "data locking" would need to be addressed (multiple processes accessing the same data). Some of the data structures that need to be defined are:
* per-channel configuration & real-time data * global system configuration pararneters *-per~onference data structures * per-operator configuration data * lists (names, phone nurnbers, conferences) * network management stats (gathered from T1 card) * parfial CDR records * raw report data (conference & ~h~nnel stats) 6. Conference Assivlments A conference is a virtual grouping of MVIP channels. Any channel within a -conference is "connected" to all other channels within the same conference. Channels may individually be set to talk, listen, or both. ~f a channel is set to talk, its mouthpiece is broadcast to all the other channels in the conference. ~f a channel is set to listen, its earpiece is connected to all other channels in the conference. Typic.~lly, a channel is always set to - 1n1 -listen. However, it may be "muted", meaning that its mouthpiece is disconnected from the other channels.
The following conferences are predefined for various functions:
Conf. Assignment 0 Quiet (no talkers). Channels are placed into this conference by default, when they are not connected to any other channel.
1 - 48 User conferences. These are the 48 conferences that are managed by the operators.
49 - 56 Annunciator. Each annunciator channel has a conference reserved for it. Any channel(s) listening to an annunciator message will be placed into one of these conferences.
57 Enter Conference. All channels that have "entered" the system are placed into this conference. This happens after a user has listened to an annunciator message. A music (or radio) channel is placed into this conference (permanently) so that users who enter this conference have something to listen to while they're waiting for an operator.
58 Input Conference. Any channel that calls into the system when no annunciator channels are available is placed into this conference. A music channel is permanently placed into this conference. The charmel stays in this conference until an annunciator channel is available. Then it is placed into that annunciator's conference.
59 - 66 Operator Conference. Each operator (up to 8) is assigned one of theseconferences. When an operator accesses a channel, it is placed into its corresponding operator conference with that channel.
7. Error Handlin~

In this initial implementation of the DCB-60, our strategy is to detect errors whenever they occur. The process that detects the error will log an error message to the system error log file. In this release, we will not try to take corrective action. There are 3 levels of errors that we are concerned with:

"Normal" Hardware Errors: These are errors that we expect to happen every now and then, ~uch as T1 alarms. The Call Handler can detect these conditions and take appropliate action, such as faulting out the affected T1 lines.

- "Unexpected" Hardware errors: These are more serious hal.lw~e failures such as an interface card that fails to respond properly, or a DSP processor crashing. Our current strategy is to periodically "poll" our hardware interfaces. If we detect a failure, we will log the error, and take the affected lines out of service. We will not attempt to restart or reinitialize any faulty hardware component.

Software errors: In the unlikely event of a software error, the detecting process will log the error (if possible). These types of errors include: A process receiving an ~;
, . ~..

unexpected message type; A software condition that should not be met, etc. Another type of software error is when a process fails to respond to a poll from the Diagnostic process. In this case, the Diagnostic process would log an error message.
8. Process Descriptions Each process is listed as follows:
D Data flow C Control flow O Output from process Input to process 8.1. Initialization Process To begin with, we need to at least initialize & download code to the DSP and T1 cards. We need to set up the control RAM on the DSP (at least with some default configuration). This should have been done in the DSP Loader. Later, we can add more functionality to Init, such as starting up individual processes, initi"li7ing the global data areas, reading config data from disk, and eventually, some warm restart capability. This process will have to pay close attention to any special requirements of Embedded VENIX.

This process could consist of 2 processes. The 1 st would be the 'UNIX initialization process. This process is run once at system start up (boot). It performs all UNIX initialization.
It then loads the 2nd init process. This would be the application init. This would load and start up the applo~liate application processes. It would determine if this was a cold or warm restart. Based on this, it would initialize all processes and data structures accordingly. For a cold restart, it would initialize and load all configured hardware (T1 card, DSP card(s), analog card(s), etc.). For a warm restart, it would have to "regenerate" some data structures from these cards (i.e. DSP cards' channel arrays and conference list).
Data/ControlFlow Type Descnption Analog Config Info D,O Data used to configure the analog interface cards Init Analog Card C,O Comm~ntlc sent to analog interface cards to initialize them.
DSP Config Info D,O Data used to configure DSP card(s). This would includethe code downloaded to the cards to run the DSP
processors. Also, the dual port control RAM data that maps tne MVIP channels to their TDM time slots.
DSP Config Info D,I Data read from the dual port 4k x 16 RAM buffers on the DSP cards in the case of a warm restart.
Init DSP Board C,O Commands sent to DSP cards to initialize and start them.
Tl Config Info D,O Data used to configure T1 interface cards.

- t03 -Init T1 Card C,O Comm~nt1c sent to T1 interface cards to initialize and - start them.
Config Info D,I System conf1guration data read from disk. This data is used to configure all hardware int~ce cards, and the system's Data Base.
Start Process C,O This is the UNIX control mechanism that is used to start up the individual processes.
8.2. DSP Driver Assurning that a driver must be written to handle the interaction between the DSP and the host, this work would be done here. A probable design scenario would be as follows: The DSP would interrupt on some real-time condition (i.e. active talker). The driver would handle the interrupt, passing data and sign~ling-the Event Processor of this condition. The Event Processor would then notify the appropriate process(es) accordingly. This minimi7es the amount of time spent in the driver, allowing the user-mode processes to do most of the work.

The driver would have access to the shared RAM on the DSP card(s). This way, it could pass the channel number of the interrupting channel to the Event Processor. This would be sufficient for most event h~nclling. Once the channel number is passed, the Event Processor could get any other information it needs from the channel data structures on the DSP card itself.
Data/Control Flow Type Description Channel Event C,I This is the interrupt that occurs when an individual DSP
processor wishes to report an asynchronous event.
Examples of this are digit(s) in, talk indication.
Channel Info D,O Infonnation about the channel for which the event occurs (typically the channel number).

8.3. DSP Command Processor .
This process receives comm~nl1c from various processes to initiate actions for aparticular DSP ~h~nn~l It sends the proper command to the a~pro~,liate DSP. ~t should not send a comm~nd for a particular channel unless that channel is ready to process it (i.e. the DSP may not be finished proceccing the previous comm~nc~ for the channel). Thus, this process could "buffer" multiple comm~n~c for a particular rll~nnrl while pc.rol~ning an 'ack/nak" procedure with the DSP for each comm~n~l This process would "sleep" until it is woken up by receipt of a message.

We may want to build into this process a "statistics" area that keeps counts & other info about the commands that are sent to the DSP. This could be useful for later debugging, or general information gathering (i.e. system performance, loading, etc.).

, ~ ~ 104 ~ ~ ~ ~ 4 ~

This process should be able to run in a "simulation" mode. In this mode, it would send comm~n~ls to the Application Test process instead of the DSP card. It would get its channel status information from this process rather than the channel data structures in shared RAM on the DSP card.
Data/Control Flow Tvpe Description Channel Comm~n~ls C,I These are the comm~n~ls that are intended to initiate some action for a channel via the DSP. For example, place a channel into a conference, dial digits, adjust gain, etc.
Channel Info D,I,O This is the data portion of a channel comm~n-l This may include the channel number, digits to be dialed, etc.
Send Channel Command C,O This is the mechanism used to communicate a channel command to the DSP. Refer to the Host/DSP interface for more details.
8.4. DSP Event Processor This process handles events reported "up" from the DSP card(s). Typically, when an external event occurs asynchronously (i.e. active talker, dtmf digit detected), the affected DSP card will interrupt. The driver will field this interrupt, and notify the DSP Event Processor. The Event Processor will then obtain the ~p~ pliate information from the channel data structure in shared }~AM on the DSP card. It will then take the appropriate action (i.e.
send a message to the Call Handler Process, or modify a data structure in the Global Data Base, then signal the Operator Console Processes, etc.).

This process would "sleep" until it is woken up by receipt of a message, or a signal.

We may want to build into this process a "statistics" area that keeps counts & other info about the events that were detecte-~ from the DSP. This could be useful for later debugging, or general information gathering (i.e. system perforrn~nçe, loading, etc.).

This process should be able to run in a "simulation" mode. In this mode, it would respond to messages & signals from the Application Test process instead of h~t~ u~l~ from the DSP card. It would get its channel status information from these messages rather than the channel data structures in shared RAM on the DSP card.
Data/Control Flow Type l~)escription Channel Event (in) C,I This is the message (or signal) that tells the Event Processor that ~n event has occurred on the DSP that needs attention.
'?
.' ' - t05 -Channel Event (out) C,O This is the message that is sent to the Call Handler to - inform it that an asynchronous event has occurred (i.e.
digie in).
Channel Info D,I,O This is the data that is included in a channel eventmessage. Input from the DSP Driver, it may only contain the channel number. Output to the Call Handler, it may contain digit(s), etc.
Talk Indication C,O This message is sent to all active Operator Console processes when reported by the DSP Driver.
8.5. T1 Handler The 1 st phase of development of the T1 handler is detection of far-end answer, incoming line seizure, or far end disconnect. It would also have to invoke outgoing line seizure, disconnect, and answer. This part of the process would periodically gather the A/B
bits from the Tlcard's registers. It would determine if answer, line seizure, or disconnect has occurred for any channel. If so, it would send a message to the Call Handler process. To invoke action for a channel, the ~propl;ate A/B bit combination for that channel would be written to the card.

The second part of the T1 Handler process collects data from the Tl card and stores it in the Data Base. The data is comprised of T1 statistical data, stored in the card's registers.
The data collected would be available to the Reports process. The actual mechanics of how this data is gathered will depend on what the Mitel card can offer us.

We may want to build into this process a "statistics" area that keeps counts & other info about the data collected from the T1 card. This could be useful for later debugging, or general information gathering (i.e. system performance, loading, etc.).
Data/Control Flow Tvpe Description Incoming Line Seizure C,O Sent to the Call Handler when incoming line seizure has been detected for a channel on a Tl card (i.e. someone dialed in). Typically, the ch~nnel number is passed as data.
Outgoing Line Seizure C,I The Call Handler sends this message to the T1 Handler when it wants to "seize out" on a line, in plep~d~ion to dial out. It can also use this to "fault" a line.
Far End Disconnect C,O Sent to the Call Handler when disco~ ,t has been ~letected for a channel on a Tl card (i.e. someone went onhook - hung up).
Disconnect C,I The Call Handler sends this message when it wants togo onhook (i.e. hang up) for a particular Tl channel.
Answer Detected C,O Sent to the Call Handler when an offhook (i.e. answer) is detected for a channel on a Tl card.
~' Answer C,I The Call Handler sends this message when it wants to answer (i.e. go offhook) a particular channel. Typically, this is in response to an incoming line seizure.
Tl Alarm C,O This message is sent to the Call Handler whenever an alarm condition (red, yellow) is detected on a T1 span.
Tl Stats D,I,O This consists of any statistical data that is kept by the Tl card. This would consist of periodically polled registers on the card. This data is forrn~tte(l (TBD) and kept in the global Data Base.
Obtain T1 Stats C,O This is the mechanism that this process uses to obtain Tl statistical data from the T1 card(s).
Update Net. Mgmt. C,I This message tells the T1 Handler to reset any counters etc. on the T1 card(s), and also, if nec. in the global Da,ta Base.
A/B Bits D,I The T1 Handler will periodically read the A/B bits from the T1 card's registers. From this, it can determine incoming line seizure, far end disconnect, or far end answer. It can also write the A/B bits to invoke outgoing line seizure, disconnect, or answer.
Hookflash C,I This message tells the T1 Handler to invoke a hookflash for the indicated channel.
Fault C,I This message tells the Tl Handler to "fault out" the indicated channel.
8.6. Annunciator Process This process handles the recording and playing back of digitized voice messages.Special channels on the MVIP bus will be dedicated for Annunciator use. It keeps track of which annunciator channels are in use, and which ones are available. Upon initialization, this process will just load the messages from disk into a set of buffers (one for each message).
When a message is to be played, it will just read it from RAM and send it to the DSP that is responsible for that particular annunciator channel. This elimin~tes real-time disk latency problems upon playback. We will probably change this in the future if we wish to add more messages for voice-response applications. The recording of messages will send the data to RAM and di3~.

The actual meçh~ni~m~ used to record & play digitized voice messages will be ~etermin.od in the design of the HostlDSP Interface, and the Annunciator process. However, the general theor,v of operation is as follows:

Play A Message: This process receives a Play Message message for a selected annunciator channel. This process then populates a specified buffer on the 4k x l 6 dual port RAM with a digitized voice message (from disk or host RAM), and signals the DSP that the data is there. The DSP then "plays" the data on the selected annunciator channel, and signals when the buffer has become available. Any channels in conference with that annunciator .
tV

channel will hear the message. We will probably use a double-buffering scheme, so that the host can be filling one buffer while the DSP is playing the other buffer. The actual han~lsh~king mechanism will be determined as part of the Host/DSP interface. When the Armunciator process has finished sending the digitized voice message, it sends a message to the Call Handler, indicating that the annunciator channel is available.

Record A Message: This process receives a Record Message message for a selected annunciator channel. This process then reads a specified buffer on the 4k x 16 dual port RAM, and stores it in host RAM and disk. It does this until the specified duration has expired or receipt of a Stop Record message. Again, a double buffering scheme would be used. The record procedure has a maximum duration of TBD seconds, for safety.

This process has the capability to inform the Call Handler process of the availability of annunciator channels. The Call Handler is signaled when l) no channels are available, and 2) a channel has become available. This process will also stop playing a message when signaled to do so. Note that this will cause a "channel available" message to occur.

This process will have the capability of playing a message in "continuous play" mode.
That is, it will play the same message over and over until it receives a message to stop.
Data/Control Flow Type Description Digitized Voice (disk) D,I.O The input data is read from disk upon initialization, and stored in a local RAM buffer. It contains the digitized voice messages for each annunciator channel. The output data is stored to disk when annunciator messages are recorded.
Digitized Voice (DSP) D,I,O The input data is read from the apl)rol,liate DSP dual port RAM buffer while an annunciator message is being recorded. The output data represents the digitized voice data sent to the DSP dual port RAM buffer while an annunciator message is being played.
Start/Stop Record C,I This message tells the Annunciator process to either start or stop the recording procedure for a desi~n~t~d annunciator ch~nnel Start/Stop Play C,I This message tells the Annunciator process to either start or stop the play procedure for a d~ n~t~l annunciator channel. This message may tell the Annunciator to play a message leped~edly until told to stop.
Channel Available C,O The Annunciator process sends this message to the Call Handler whenever an annunciator channel has finished playing a digitized message. It tells which channel has become available.

~- - 108 -8.7. Call Handler This process handles all calling scenarios for each channel. It keeps track of which state each channel is in, and takes the appropriate action depending on the input received concerning that channel, the state it is in, and its configuration at that time. Input can be received from an operator console action (i.e. dial a number, move a line from conf. x to conf.
y), by the DSP Event Processor (i.e. receive digits, etc.), by the Tl Handler (offhook, line seizure, disconnect), or by the Annunciator (annunciator channels available - yes/no). Some real-time events (such as talk indication~ can be reported by the DSP Event Processor directly to the Operator Console processes, without needing to bother this process.

This process operates on each configured channel according to a state diagram (TBD).
When it receives input from another process pertaining to this channel, it will perform whatever action is called for, according to the type of message received, and the current state of the channel.

All channel information is updated in the central Data Base. The Operator Console processes are notified of any changes that require an update to the console display.

- The state diagrams can be designed as "templates", so that they may be more easily modified to handle various calling scenarios in the future (i.e. unattended operation). Initially, these templates may just consist of some code and their associated data structures (i.e.
"objects" ?). These would be m~int~ined in house "by hand". In the future, we may want to develop a utility that configures these templates, so that call h~n~lling scenarios can be developed by 3rd party vendors (or the customers themselves?).
This process would "sleep" until it is woken up by receipt of a message.
nata/Control FlowType l:)escription Channel Event C,I This tells the Call Handler that an event has occurred for a particular ch~nnpl It contains the n~c.ess~, r inforrnation for that channel about the event. For example, a Digit In message would contain the channel nurnber and the digit(s).
Chcannel Comm~n~l C,O This message is sent to the Cornmand Processor to initiate action for a particular çh~nnPi It contains the necess~ ~ inforrnation for that ~~h~nnPI for the DSP to initiate the action.
Channel Available C,I Says that an annunciator channel has become available.
Start/Stop Play C,O Tells the Annunciator to start or stop playing a digitized volce message.
Channel InfoD,I,O This represents any inforrnation about a channel that resides in the Global Data Base.

. . .
c, .

~ ~4~4 Console Update C,O Tells the Operator Console processes that some inforrnation about a particular channel has changed (in the Global Data Base).
CDR Update C,O Tells the CDR process that a call on a particular channel has been completed. Passes all info for that call to the CDR process.
T1 Alalm C,I Alarm message from the Tl Handler. Call Handler may have to "fault" out a T1 span by seizing out on all 24 channels. Minor alarrns may just have to be tracked.
Seize,Disconnect,Answer, Described in Tl Handler process description.
Hookflash, Fault 8.8. Lo~in Process A copy of this process is attached to each TTY port. Up to 8 TTY ports are used as functioning operator consoles. The others are used for maintenance, and admin functions.
This process allows someone to log into the system as an operator, system ~1ministrator~ or m~intçn~nce person. Depending on how one logs in, the corresponding process will be spawned from the Login process. For exarnple, if the operator login is given, the Operator console process will be spawned from the Login process that is ~ çhe~l to that TTY port.
Each TTY port capable of running the Operator Console process will be assigned to a specific analog port for its headset (voice path).
Data/Control ~low Type Description Maint. Login C,O Spawn Maintenance process. Only one Maint process allowed to run at any given time.
Operator Login C,O Spawn Operator Console process. This process may be run on each TTY port.
Admin Login C,O Spawn Admin process. Only one Adrnin process allowed to run at any given time.
8.9. Operator Console Process This process m~int~in~ the operator console screen, and handles all interaction with the operator.~t responds to keystrokes from the operator, and sends messages to other processes, informing them of action initi~ted by the opc;~tor (i.e. place a line into a conference). It m~int~in~ the "state" of the console, depending on which keystrokes have been hit (i.e. how many lines are displayed, which status display is active, which menu are we in).
It also updates the console according to messages it receives from other processes (i.e. show active talker).

Multiple copies of this process may be running to support multiple operator consoles.
Each Console process knows which data it must display (i.e. which channels, conferences~
etc.). This data is made available by the ~Data Base". Each Console process accesses the Data Base for whatever information it needs to store or retrieve.

~10 ~ 4 ~

The physical console itself would be any ASCII terminal that supports the necessary screen features (i.e. 43 line mode). Refer to the Product Specification for more details. We could use CURSES to provide a nice color operator console interface for the console if it were running an EGA/VGA monitor.
Data/Control Flow Type Description Start/Stop Record C,O Starts/Stops the recording of a digitized voice message on a particular annunciator channel.
Channel Command C,O Initiates action for a particular channel on the DSP. Sent to either the Call Handler, or directly to the Command Processor.
Talk Indication C,l Indicates active talker currently on (lesi~;n~tecl channel.
Operator Console process must flash '*' next to channel if displayed.
Console Update C,I Information for designated charmel has been updated.
Console display must be updated to reflect new info.
The channel info resides in the Global Data Base.
Channel Info D,I,O This represents any information about a channel that resides in the Global Data Base.
Hookflash C,O Tells T1 Handler to initiate hookflash for indicated channel.
Fault C,O Tells Tl Handler to fault out indicated channel.

8.10. Maintenance Console Process This process allows various reports to be run. It also allows initiali7ing of network management data. It allows the user to perform various system maintenance functions such as the forrn~tting of diskettes, running diagnostics, etc. It does this by "wrapping a shell" around various UNIX utilities, if nPcess~. ~, to shield the user from UNIX. It also allows the operator console function to be run in a "display only" mode. In this mode, no voice path is provided, and no access to lines or conferences is allowed. Line and conference activity can only be monitored ir~his mode.
~t~/Control Flow Type nescription ~nitiate Report(s) C,O Message sent to the Reports process. This initiates any reports to-be printed (TBD).
Update Net. Mgmt. C,O Tells the Tl Handler to initi~li7e any Tl network stats it hapl,e.ls to be keeping track of.
8.11. Ad~nini~trator Con~ole Process This process allows various system configuration parameters to be set (per line, per conference, per operator, etc.). ~t also allows other system configuration such as the i . ~

- ", ~4~4 adding/deleting of user accounts and passwords. Disk backups may be performed here. It may do this the same way as in the ~inten~nce process (hiding UNIX from the user).
Data/Control Flow Type ~escription Config Data D,I,O Represents System configuration data read or written to/from disk or the global Data Base.

8.12. Reports Process This process generates all the required reports. It accesses data resident on disk, forrnulates reports, and prints them. The data that it uses was collected by other processes.
This process may clear or initialize certain data after running a report (i.e. network management statistics). It may be beneficial to support various types of printers. This process could use UNIX to keep the actual printer type "transparent" (similar to the way different termin~l types could be used for operator consoles).
Data/Control Flow Type Description Raw Report Data D,I This represents any data stored in the global Data Base that must be formatted into reports. This data can be collected by any process.
Initiate Report(s) C?I Message sent to the Reports process. This initi~tçs any reports to be printed (TBD).

8.13. Status/Error Log~in~

This process collects messages from other running processes. It formulates thesemessages into status or error logs. It writes these logs to disk file(s). Certain messages may need to be reported to the operator console(s). This could be done by sending a message to the desired operator console process queue. Other messages may need to go to the printer.

Error logs can be generated by any process. A process may run into an error condition during tlie various phases of its operation. There are at least 2 categories of error conditions:
(1) Tntern~l software errors. These can be attributed to faulty data, conditions which shouldn't exist, and so forth. (2) System errors. These can be hardware faults, etc. Some errors may only need to be reported ~ logged, while others may require a system restart.
n~t~/Control Flow Type Desc"ylion Update Log C,I This message tells this process to update either the Status Log, or the Error Log.
Log Info D,I,O This is the log data that is part of the above message. It is forrnatted, and written to the disk log file(s).

8.14. CDR Process This process collects CDR records from the Call Handler. These records are generated when a call is completed, and contain all the information needed to log the call (i.e. start/end time, channel #, dialed digits if outgoing). This process merely formats the record and writes it to a disk file. This process thus acts as a "buffer" for the Call Handler, elimin~ting the need for the Call Handler to access the disk.
Data/Control Flow Type Description CDR Update C,I This message tells the CDR process that a call has completed for a particular channel. It contains all the information needed to log the call.
CDR Record D,O This represents the formatted CDR records that are written to disk.

8.15. Dia~nostics Process This process periodically sends a message to each host process, just looking for an acknowledgment. If it gets an ACK, then it knows that the host process is running, or at least able to receive and respond to messages. If it doesn't receive an ACK, it will log an error message. In the future, it could kill & restart that process (individual process initialization becomes an issue here). Another (more undefined) thing it could do is to periodically execute some real-time diagnostics on the various configured pieces of hardware that are installed.

It could execute the set of power-up diagnostics when the system is started from a cold boot. It could also execute some set of tests that could be run from the Maintenance menu. These all have to be defined in more detail before we can get into specifics.
Data/ControlFlow Type Description Poll Process C,O This message polls the destination process to see if it is running and able to respond.
ACK . ~ C,I This represents the ACK that would be received as a correct response to a Poll message.
8.16. Timer Services This process manages all of our system timers (maximum number TBD). When a process wants to know when a specific time duration has elapsed, it sends a Start Timer message to this process. A tag value identifies the timer, and is defined by the sending process. A duration value is also set (increments of l OOms). This process allocates a timer, and decrements the timer every I OOms. When the timer has reached zero, it sends a timer event message, cont~ining the tag value, to the sending process. If it receives a Stop Timer message from the process, it will stop the timer that contains the matching tag value. No timer event message is sent in this case.

This process combines the tag value with the sending process's ID to identify the timer. This elimin~tes any problems with multiple processes using the same tag values.
nata/Control Flow Type Description Start Timer C,I Starts a timer operation for the sending process.
Stop Timer C,I Stops a timer operation for the sending process Timer Event C,O Sent to the sending process when the timer's duration has expired.

.~

APPENDIX F

1. Introduction The principal areas for which the Digital Signal Processor (DSP) board and the host computer need to communicate are:
DSP initialization, command and information exchange, and notification of events (digits in, talk indication, etc.) acquired by the DSP.

The DSP-Host interface design:- .
specifies the commands and data structures that need to be exchanged, assigns the Dual Port Memory (DPM) locations used for these purposes, and relates the sequence of steps needed to initialize and to communicate with the DSP.

The global header files, dsp_cnfgh, dsp_host.h and dsp_regs.h, contain manifest constants and macros defining the data structures, member values, DSP registers, register contents, and operations on the registers.
2. System Data Most configuration information is m~int~ined in the DPM. Per channel, per conference, and per DSP node information are supported. As used in this document, a node refers to that part of the system supported by a single DSP.
2.1. DPM Data Structures Each DSP Node contains the following data structures:
A. Two Data Transfer Buffers (0 and l) used for the transfer of voice data during record and playback operations each of size 2 KBytes located at DPM Addr. Seg.:0 and DPM
Addr. Se,~.:800, respectively. One semaphore each is used to control access to these buffers (see later section on semaphores).

B. An array of eight Channel Data Structures located at (DPM Addr Seg.:OxlO00). Six of these structures are used for Tl channels, one is used by an annunciator or operator channel, and one is reserved for future use. Each structure member is two bytes (l word) in size except as noted below. The structure is comprised as follows:
DPM Port (0-l9l) (initialized to the assigned port) Command {see command section} (initialized to 0) Error (TBD) (initialized to 0) ,~ . Event {see command section} (initialized to 0) ",_ Mute (0-1) (initialized to 0) Gain (0-1) (initialized to 0) Music (0-1) (initialized to 0) Time Slot Type {see type section} (initialized to O) Digits-in - ASCIIZ string 50 b,vtes max. (initialized to null string) Digits-out - ASCIIZ string 50 b,vtes max. (initialized to null string) C. Channel Conference List following the Channel' Data Structure Array.
192 (6 boards x 4 DPM's/board x 8 charmels/DPM) entries sorted by channel (one word each cont~ining the conference number) D. MVIP Time Slot List following the'Charmel-Conference List.
192 (6 boards x 4 DPM's/board x 8 channels/DPM) entries sorted by charmel (one word each cont~ining the chanIlel MVIP time slot) E. Conference Number of Talkers List following the Channel MVIP Time Slot List.
67 (48 user + 8 operator + 8 annunciator + 1 enter + 1 input + 1 null line conferences) entries sorted by conference (one word each cont~ining the maximurnnumber of talkers allowed) F. Node Inforrnation located following the Conf. Number of Talkers List.
Node Number (0-15) (initialized to assigned node) Active node mask - one word (16 bits) with one bit per node (1=active; O=inactive) G. System Parameter List Buffer located following the Node Inforrnation.
50 words will be reserved for the System Parameters including those currently defined (see later section on System Parameters) and possible future items.
2.2. Command Values The DSP comm~n~ recognized in the Charmel Data Structure are:
No comm~nc~ (Comrnand value = OxOOOO) Start playing a message (Command value = OxOOO1) Stop playing a message (Comrnand value = Ox0002) Start recording a message (Comrnand value = Ox0003) Stop recording a message (Command value = Ox0004) Dial a telephone nurnber (Comrnand value = OxO005) Acknowledge (Comrnand value = Ox0006) Generate DTMF acknowledge tone (Comm~n~i value = Ox0007) Generate conference entry tone (Comrnand value = Ox0008) Generate conference exit tone (Com~nand value = OxOOO9) Generate Security-in tone (Comrnand value = OxOOOA) Generate Securit,v-out tone (Command value = OxOOOB) 2.3. F.vent Indicators The set of event indicators recognized in the Channel Data Structure is:
No change (value = OxOOOO) Talk indication (value = OxOOO I ) DTMF digits in (value = Ox0002) ~; . DatabufferO ready (value =Ox0003) Data buffer l ready (value = OxO004) Dial done (value = Ox0005) Play-tone done (value = Ox0006) 2.4. Time Slot Types The set of time slot indicators supported in the Channel Data Structure is:
Unused (value = OxOOOO) Conferee (value = OxOOO l ) Local Operator (value = Ox0002) Remote Operator (value = Ox0003) Annunciator (value = Ox0004) Tape Record (value = OxO005) Tape Playback (value = Ox0006) Link Line ~ (value = OxO007) Music (value = OxO008) 2.5. System Parameters Each system parameter is stored in one word (2 bytes) with units as indicated below. The System Parameter List in order of contents is:
DTMF On Time (default = l OO ms.) DTMF OffTime (default= 50 ms.) Dial Tone Wait (default = 5 sec.) DTMF Level (default = -7 dBm) Forward Twist - Receive direction (lO dB) Reverse Twist (lO dB) Talk Detect Level (-35 dBm) Max. Talkers/conf. (default= 8 talkers/conf.) Max. Gain (lO dB) Speech Level Out (-16 dBm) Channels Per DSP Node (default = 6 channels/node) 2.6. Semaphores Eight semaphores are supplied for use with each node. The content of a semaphore is OxOOOl whelrnot in use. The sPm~rh(lres are acquired when either side successfully writes and then reads a value of OxOOOO from the location specified below. The side that acquires the semaphore must return it when fini~hP~1 using the resource by writing OxOOOl to the same location. The current ~si~nmpnt of sPm~rhores is as follows:
Control access to Data Transfer Buffer O (Ox2000 + I/O Addr. + O) Control access to Data Transfer Buffer 1 (Ox2000 + I/O Addr. + l) Unassigned (Ox2000 + I/O Addr. + {2-7}) ~ p~
;

~ _ 117 - ~ 4 ~,.,~
2.7. Interrupts - DSP to Host Event Notifications When a DSP detects one of the previously specified events, the occurrence will be indicated by writing the event number in the corresponding Channel Data Structure. Subsequently, the DSP will generate an interrupt by writing OxOOFF to DPM internal address OxFCOFFF, which corresponds to the host's mailbox located at byte offset OxlFFE in the DPM. The host clears the interrupt by reading its mailbox.
2.8. Interrupts - Host to DSP Mode Control Several interrupt commands have been defined to control the operating mode for aDSP node. They currently provide a means of controlling the installation of the load module, initialization, and DSP start synchroniz~ion.
No command (value = OxOOOO) Enter Node Command Mode (future use) (value = OxOOOl) Invoke Boot Loader Mode (value = Ox0002) Synchronize and Enter Channel Command Mode (value = Ox0003) The first value is not actually issued by the host; rather it is the mailbox value after the DSP
reads the mailbox. The second value is reserved for future use. A later section on downloading DSP code describes how the last two commands are used.
3. DSP Initialization The initialization operations required for each DSP board are described in the following sections. Up to four I/O Addresses are configured by unique jumper settings on each board and acquired during installation from the set: {Ox220, Ox240, Ox250, Ox260, Ox2AO, Ox2BO, Ox300}. The Base Memory Address Segments for the boards are assigned contiguously in virtual memory.

3.1. Reset each DSP Board A. Write Base Addr. Reg. (BAR) (I/O Addr + 2) ~= Mem. Addr. Seg.>>8 B. Write Virtual Mode Register (VMR) (I/O Addr + 4) ~= OxOO
C. Write PC Control Reg. (PCR) (VO Addr. + O) ~ OxlO
D. Reset Receive Control Reg. (3000 + I/O Addr.) ~= OxOO
E. Reset Transmit Control Reg. (3400 + I/O Addr ) ~ OxOO
F. Write Clear RCV Line Status Reg. (3000 + I/O Addr +2) <= OxOO

;
~: ' r~

-118- ~ 5~
3.2. Clear Interrupts and Semaphores for Nodes A, B~ C, & D
A.Read Mailbox for each node (Mem. Addr Seg.:OxlFFE + {0x0000, 0x2000, 0x4000, 0x6000}) B. Clear 8 Semaphores per node ({0x2000, 0x2400, 0x2800, 0x2A00} + I/O Addr + {0-7}) ~= OxOl 3.3. Write Reference Memory A. Read PCR (I/O Addr. + 0) B. Write PCR (I/O Addr. + 0) <= PCR I 0xl0 C. Write BAR (I/O Addr + 2) ~ 0xDl D. Transfer 32 bytes to MVIP DPM (Mem. Addr. Seg + {0-633) ~= file(contents TBD)E. Write BAR (I/O Addr + 2) ~ 0xD0 3.4. Download DSP Code on all Nodes Avoiding the interrupt mailbox addresses, the host uses the rest of the DPM to download to the DSP its code/data from the COFF file, dsp_code.out, generated by a DSP
cross-compiler on DOS. Source code for a COFF loader was obtained from the TexasInstruments bulletin board; this loader is used to translate the DSP code file to the download module. The loader includes a host supplied software module to write the loader output to the DPM. The following procedure is used to download the first block to the DSP:
A. Read PCR (I/O Addr. + 0) B. Write PCR (I/O Addr. + 0) ~= (PCR & ~current node bit) 1 0xl0 C. Write boot code (Mem. Addr. Seg.:{0-OxOFFF}) ~= COFF loader output D. Write PCR (I/O Addr. + 0) ~ PCR l current node bit The built-in DSP Boot Loader takes over from there, moves the block to the destin~tion address(es) and starts the DSP at the first destin~tion narned in the download. The host will write the sarne block to all nodes before returning to the COFF loader to download another block of the DSP load module. To avoid writing boot code for the DSP, the first block includes code in which the DSP waits for the host to download another block from the COFF loader and to interrupt the DSP by writing the Invoke Boot Loader illte.~u~t comm~n-1 to its mailbox before procee~lin~ The DSP will, in turn, vector to the start of the DSP Boot Loader. The host will repeat the above procedure for each block of the DSP load module. The host includes enough of the first block with each download to cause the built-in DSP Boot -Loader to start the DSP at the original entry point after each pass.

4 ~
;.,_ " g 3.5. ~nitialize DPM Data Structures For all nodes, the host initializes the Channel Data Structures, the Channel-Conference List, the Node Information, and transfers the System Parameter List to the DSP.

A. Read PCR (I/O Addr. + 0) B. Write PCR (I/O Addr. + 0) <= PCR I 0x10 C. Write data structures (Mem. Addr. Seg.:{0-x}) ~ data 3.6. Enable MVIP Re~i~ters A. Read PCR (I/O Addr. + 0) B. Write MVIP Receive Register (I/O Addr. + 0x3000) ~ 0x01 C. Write MVIP Transmit Register (I/O Addr. + 0x3400) ~ 0x85 D. Write PCR (I/O Addr. + 0) ~ PCR l D0 3.7. Mark all active nodes and Start Full DSP Operation on all Nodes The host updates the Active Node Mask in the Node Information structure on all active nodes. The host then interrupts the DSP one final time by writing the Synchronize interrupt command to the DSP's mailbox. After that, the DSP's begin full operation.
4. Command and Information Exchan~e The major operations required are:
Send channel information and comm~nclc to the DSP.
Send node configuration information to the DSP.
Acquire channel events from the DSP.
Detect DSP failures.

4.1. Channel Commands ~or the comm~n~C identified in the earlier section on comm~n~l~, the host checks for a ....
clear command member in the Channel Data Structure which indicates that the DSP has completed any previous co.. Irl l~.-d for that charmel. If the DSP encounters an error before completing a comm~nrl, it returns an error code in the error member of the Channel Data Structure and then sets the command member to 0xFFFF instead of clearing it. When the host encounters an error return from the DSP, the host's Comman& Processor sends an ap~ropl;ate message to the Log process.

For the Dial comm~n~1, the telephone nurnber is first placed in the Channel DataStructure of the target channel. For the Dial and the Play-Tone comrnands, the command value is set in the command member of the Channel Data structure. When these comrnands P~

- 12û -are completed, the DSP interrupts the host with the appropriate event indication as described later in the acquire events section.

For Playback and Record commands, control of the Data Transfer Buffers is detailed in the next section. The cornInand value is then set in the command member of the Channel Data Structure. The DSP clears this member when the comm~n~l has been started.

To change the conference for a channel or to mute a channel, the host notifies the DSP
as described later in the update talker-conference section.

4.2. Record and Playback Voice The Data Transfer Buffers are used alternately beginning with Buffer #0 to record or playback voice data. These operations are required, respectively, by an Operator or an Annunciator channel. Access to each buffer is controlled by a designated semaphore.

For recording, the host first issues the start record comm~n(l The DSP then acquires the Buffer #0 semaphore, fills the corresponding buffer, releases the semaphore, sets the Data Buffer 0 Ready event, interrupts the host, acquires the Buffer #1 semaphore, fills its buffer, releases that semaphore, sets the Data Buffer 1 Ready event, interrupts the host, and continues at the be~innin~. At the same time, the host waits for an interrupt, acquires the first semaphore, transfers data from the first buffer, releases the first semaphore, waits for another interrupt, acquires the second semaphore, transfers data from the second buffer, releases the second semaphore, and continues at the beginning The host must issue the stop record cornrnand to tçrmin~te this action.

For playback, the host acquires the Buffer #0 semaphore, fills the correspondingbuffer with voice data, releases the semaphore, issues the start playback comm~n~, waits for an interrupt, acquires the second semaphore, fills its buffer, etc. The host issues the stop playback'corrunand to end the playback action. The DSP follows with actions analogous to the record scenario. Unless the playback is aborted, the host will termin~te the playback by filling an extra buffer with zero level data (0x7F) and wait until the DSP acquires the semaphore for that buffer before issuing the stop playback comm~

4.3. Chan~e Node Conf~uration When it is necessary to update the Channel-Conference List, Channel MVIP Time Slot List, Conference Number of Talkers List, Node Information, or System Parameters List, data structures that concern an entire node, the host will update the appropriate data structure. The host will make a single change in the lists at any one time. To minimize differences in ~r information among nodes, the change is made as quickly as possible to all nodes in a round-robin fashion. No additional indication of the change will be made to the DSP's.
4.4. Acquire Events When a DSP detects one of the previously specified events, the occurrence will be indicated by writing the event number to the Channel Data Structure. Subsequently, the DSP
will generate an interrupt by writing OxFF to DPM intern~l address OxFCOFFF, which corresponds to the host's mailbox located at byte offset OxlFFE in the DPM.

Upon receipt ofthe hltell~pl, the host will examine the Node Interrupt Status Registers for each board. The register is-located at address (I/O Addr. +6). Within the register, bits 0-3 indicate which node generated the interrupt. More than one register may have a bit set. The host side determines which channel or channels on an interrupting node are reporting events by detecting a non-zero event field in the Channel Data Structure. The host side will acknowledge receipt of the event by setting the event field to zero.

4.5. DSP Failure Detection The host will periodically transmits the Acknowledge command to one or more channels on a node to determine the DSP's ability to respond.
5. Issues Before initialization, we may need to determine if we are doing a warm restart and if the DSP board is already in operation.

Does the DSP/Host interf~e suffer from the big-endian/little-endian syndrome; i.e., does one side need to do byte-swapping? If so, the host will do the byte-~w~phlg.

~..

- 122 - ~ 6 ~ z APPENDIX G
l. Introduction The Comm~nd Processor is one of the processes that comprise MultiLink's Digital Conferencing Bridge (DCB). It accepts messages from other DCB processes to control the operation of a line connected to the DCB. The operations include:
dialing a number on one of the lines, setting the gain factor on or off for a group of lines, muting or unmuting a group of lines, playing an acknowledge dtmf, conference entry, conference exit, security on, or securit,v off tone on a group of lines, and putting a group of lines into a specific conference with or without music.
The Comrnand Processor will execute these requests by passing the command to the Digital Signal Processor (DSP) that handles the affected line.
2. Design Description At a high level, each of the requests is performed through an interface provided by the Command Processor for one of the purposes already enumerated. A non-blocking interface is provided for each of those purposes. With the exception of dialing a number, the comm~ncl is perforrned without an indication of completion to the requestor. When a nurnber is dialed, a completion reply is provided to the caller. Commands directed to failed lines will be recorded in the Error/Status Log.

At the low level, the Command Processor will determine the board, node, and DSP
channel associated with each requested line. The appropriate channel data structure will be checked for an error indication due to a previous request. If an error is indicated by the DSP, the Command Processor will record it in the Error/Status Log and report the affected lines as failed to the Call Handler. After the DSP performs dial-dtmf and pl~y-tone requests, the Command Processor expects to receive a completed event message via the Event Processor.
.~..
3. Data Structures The Comrnand Processor will keep a bitmask of the active nodes to deterrnine which nodes are active. Upon initi~li7~tion of the Command Processor, ail possible nodes will be assumed active until proven otherwise. In the first release of the DCB once a node is m~rked inactive, it will remain so until the Comm~n~l Processor is restarted. A node will be m~rkPd inactive if an error is encountered or if the node does not respond to an acknowledge comm~n~l discussed later in the detailed design section.

., -~ A

The Comm~n~l Processor communicates with each DSP via data structures located inthe associated Dual Port Memory (DPM). These structures are defined and their usage is described in the DSP-Host Interface Design, see Document 14002059.

When the Comm~n~ Processor can not immediately execute a dial-dtmf or a pl~-tonerequest because the DSP is busy with a previous request, it will temporarily acquire memory to store the request and repeat the execution attempt after a fixed period of time.
4. Detailed Desi~n For requests on nodes that have been marked inactive, the Comm~nd Processor willlog an error in the Error/Status Log and ignore the request.

When the request is to change the gain factor or muting for a group of lines, the Command Processor will simply update the corresponding flag located in the ap~lo~l;ate DSP channel data structures. If the request is to place lines in a conference, the Comm~n~1 Processor will set the music indicator on or offas requested for the specified lines and update the Channel-Conference structures on all active nodes as quickly as possible.

For dial-dtmf or play-tone requests, the Comm~n-l Processor will individually determine if each requested DSP channel is ready to accept a new comm~n~l If it is not, the Command Processor will privately store the request for that channel in a queue. The request will be aKempted again when the appropriate completed event message arrives from the DSP
Event Processor. The Command Processor provides an interf~ce for the completed event messages.

When the DSP is ready to accept another comm~n~l on a desired channel, any associated data will first be placed in the associated ch~nn~l data structure followed by the comm~n-l If the request is dial-dtmf, each DSP ch~nnt l will be checked when theco~ ,o4ding completed event arrives from the DSP Event Processor and if the dialing was succe~lly completed, the line number will be retumed to the caller with a REPLY_DIAL_DONE reply.

An alarm will be set a~rox;...~tely every 5000 ms. which will cause the Comm~
Processor to interrogate each active node with the acla~owledge "are you active?" comm~
If the DSP does not respond by clearing that co...,--~...i before the next alarm arrives, the incident will be recorded in the Error/Status Log, the Call Handler will be informed of the lines affected through its interface provided for th~t purpose, and the associated node will be marlced inactive both internally and in the DSP node data structures for all DSP~s that remain active.
., ~.

~ -- 1 24 --., .
Finally, a dsp-failed interface is provided for use by the Annunciator Process. Its purpose is to consolidate knowledge of DSP failures in the Comm~rld Processor. The Cornmand Processor will handle this notification as it handles intern~lly detected DSP
failures, just described.

- 125 - 2 ~

APPENDIX H
1. Introduction The Event Processor is one of the processes that comprise MultiLink's Digital Conferencing Bridge (DCB). It reads a bit-array of Digital Signal Processor (DSP) nodes that are interrupting the host from the DSP Driver. It then accesses the DSP's Dual-Port Memory (DPM) to deterrnine the event(s) causing the interrupt(s) and processes those event(s). The events include:
Digits have arrived from a specific user channel, The talk-present flag has been set or reset for a specific user channel, A data buffer is ready for a specific annunciator or operator channel, A play-tone request previously issued by the Command Processor has been completed, and Dialing has been completed for a previous dial-digits comrnand issued by the Command Processor.

The design of the DSP Driver is also described in this paper. It provides the following functionality for the host software:
Access to the DSP device through the open() interface.
A bit-array of interrupting DSP nodes through its readO interface, and A means to reset each node, get the physical address of the DPM's, get and put a bit-array of active DSP nodes, get and put I/O register contents, and enable or disable printing of register accesses through its ioctlO interface.
2. Desi~ Description The existence of a DSP Driver is closely associated with the Event Processor because of a desire to reduce possible process context switches when h~ntllin~ interrupts from the DSP.
2.1. Event Processor Desi~

....
The Event Processor blocks while waiting for an interrupt from the DSP Driver. It detennines which channels indicate an event and it processes each event. The possible events are enumerated in the introduction section. Depending on the event, the Event Processor executes an interface provided for the purpose by another interested process. ARer processing all the indicated events, the Event Processor waits for another intel~ t to occur.

6 ~
.~ - 1 2 6 2.2. DSP Driver Desi~n The DSP Driver handles all DSP interrupts and provides the sole interface to the DSP
registers. It is also the source for information such as the address of the DPMrs and the active DSP nodes.

The DSP Driver is a character device. It provides handlers for dspinitO, dspopenO, dspioctlO, dspreadO, dspintrO, and dspcloseO. During initialization, the driver attempts to determine the existing boards from a list of possible I/O base addresses specified in the driver's System inct~ tion file. The contents of the driver's installation files are given in the appendices. The driver assigns the starting address of the physical memory for the DPM to the first memory address indicated in the System installation file.

The driver allows any number of cooperating processes to open the DSP device. Ioctl calls are used to reset each DSP node, to get and put information about the DSP's from and to the driver, and to control printouts of each register access on the console for debugging purposes. The supported ioctl comm~n-ls are defined in the dsplib.h header file which is included in the appendix. In a future software release, an ioctl command may be added to support a DSP test function.

When an intell ~t occurs, the intr section of the driver forms a bit array of all interrupting nodes and stores it in a buffer managed by existing kernel routines. The information is subsequently acquired by the read interface.

The device is closed when the last process having the DSP open issues its close call.
3. Data Structures The device readO int~ e uses an unsigned long to provide a bit array of the h~ ptillg nodes in the first 24 bits.
.,~ .
Ary,~ullcnt~ for the various ioctlO co.,...-~n-lc are defined below.
ln.~i~Pd short is used to specify the board to be reset in a RESET_DSP request.
This will be used only by the InitDCB rr~c~s.
An lln~ig~.otl integer is used to get and put a bit array of active DSP nodes in the first 24 bits for GET_ACTIVE and PUT ACTIVE requests. The active-nodes information is acquired and saved during the higher level interface open_dspsO call, described in the attached dsp manual page.
A long integer is used to get the starting physical memory address of the DPM's via the GET_DSPMEM request. This inforrnation is also acquired and used during the open_dspsO c~ll.
A DSPIO structure, defined in the dsplib.h header file, is passed through the interface to A get and put DSP register contents for GET_REGISTER and PUT REGISTER requests.

For debugging purposes, a long integer is used to define a bit array of interrupting nodes to simulate an interrupt via the PUT_INTERRUPT request. This value is returned during a subsequent read request.
An array of six integers is used to get the base I/O address of each possible DSP board ~ ia the GET_IOBASE request. Since the information contained therein is automaticallyinserted by the driver during register accesses, this interface is c~lelltly used only to provide debugging information.
No argument is necessary for the DEBUGON or DEBUGOFF requests.
4. Detailed Desi~

Additional details of the design outlined above are provided here.
4.1. Event Processor Details When started, the Event Processor initializes the interprocess communication routines, opens the DSP device, and initializes the shared database. It then enters an infinite loop in which it reads the bit array of interrupting nodes, processes each event and reads again.

To process each interrupt, the event member of each channel data structure on each node having a bit set in the bit array is examined for the presence of an event. If an event is detected, the logical channel number (Icn) is detennined and filrther processing is dependent on the type of event as described below.

For a talk event, the talk flag is obtained from the DPM and stored in the talk indication slot of the shared ~l~t~b~se for the lcn.

For a dtrnf-digits-in event, the digit(s) are copied to a DIGITDATA structure, the source in the DPM is set to a NULL string, and ReportDigitsO int~ ee is used to send the inforrnation to the Call Handler.
When a data-buffer-ready event occurs, the annun_bufrdyO interf~ce is used to send the info~ aLi.3i1 to the Annunciator Process.

When a dial-done or tone-done event is received, the Command Proc~ssor is il~llnedviathe cmd dial doneO or cmd tone doneO int~ e, ,e~e~,~ively.

Finally, to signal the DSP that the event has been ~roceased, the event member of tne DSP channel is cleared by storing NULL EVENT in it.

- si . ,9~ ~.

~~ - 128 ~ 4 ~ 1~ 4 4.2. DSP Driver Details During driver inct~ tion, a system-wide config.h file is formed from the System file of all device drivers. The Space.c file will be supplied in source form to each DCB software installation site and used to obtain configuration information from the config.h file.
Through global variables initialized in the Space.c file from the config.h information, the DSP Driver learns the ~ipnment of the starting DPM address and the base addresses for each board's I/O registers.

On system startup, the driver's init handler prints MultiLink's copyright notice and indicates whether each of the six possible DSP boards was detected or not. With this, a DCB
system ~minictrator is assured that the driver is present and that it has recognized the presence of all installed boards. Since the DSP has no ID register, the Receive Control Register of each board mentioned in the System file is examined. This address (offset 0x3000) is seldom used by other devices. The register is clear on power-up and is never purposely set to 0xFF, which is returned when no device is present. Therefore, if 0xFF is not read, a DSP is assumed to be present.

When a board is detected, its I/O base address is stored in an array of iobases for - future reference.

The first process to open the driver causes the initialization of read buffers managed by existing kernel routines. The buffers are used to store a bit array of interrupting nodes formed from the Node Interrupt Status Register on each l~SP board by the interrupt handler.
Subsequent device open calls simply increment the count of processes having the device open.

The close routine dec~el~le,ll~ the count of processes having the device open. When the count goes to zero, the read buffers are actually closed.
~..
The read routine is simply a call to the afole.,le.ltioned buffer handler managed by the kemel.

Ioctl co.. ~A~ c control specific requests including DSP resets and all IIO register operations. The user ~ e.l~ are copied from user memory to kemel memory, acted upon, and retumed by copying from kemel n.e.llol ~ to user memory, depending on the specific comm~n(l The attached dsp manual pages specify high level interfaces to access driver filnctionality while hiding some of the low level interface details.
~A

,i.~

5. Issues A DSP sem~rhore is probably needed to signal when the host is removing digits following a dtmf-digits-in event.

The DSP Driver could provide a means for software manufacturing to insert sourcelevel identification of version or configuration information through initialization of aIl additional character string in the Space.c file that could be printed upon DCB system startup.
-APPENDIX I
1. Introduction The InitDCB Process is one of the processes that comprise MultiLink's System 70Conferencing Bridge. It manages the System 70 st rt-up and sanity operations:
pre-service diagnostics, resource initiali_ation or recovery, process creation, process sanity checks with de~(lm~n placation, alarm reporting, and System 70 reinitialization or shutdown.
2. Desi~n Overview Initdcb is the first System 70 process to be invoked. It is designed to be called by the UNIX~3) init process from an entry in the inittab file. Depending on the boot status, described below, it performs a sequence of preliminary diagnostics and initializations, as required, including but not limited to Digital Signal Processors (DSP's), T1 boards, the analog board, serial board, shared memory, databases, displays and the de~-lm~n timer. It creates the rem~inin~ System 70 processes, providing each with prescribed startup arguments.

Initdcb finally enters a lifelong loop in which it periodically placates the System 70 de~(lm~n circuit and requests a reply to the CMD_RU_THERE message from each process that accepts messages. It sends signals to other processes, to which the receiver similarly replies by message. The init_signalsO interface, described in the appendix, is provided for this purpose. If any process does not respond within a limited time, an error message is logged and an alarm is fired.

Initdcb accepts messages to set and to retire major and minor alarms. It also accepts a message requesting System 70 reiniti~li7~tion or shutdown. It subsequently sends a CMD_SHU~I)OWN message or corresponding signal to all processes, thereby requesting them to exit gracefully. When all processes have exited, up to a specified time limit, initdc~
causes the UNIX kernel to reinitialize or shutdown.
3. Data Structures ~ nitdcb keeps an array of child process names, process id's, process priorities, message queue id's, and process alarrn states for use by system reinitialization, interprocess communication, or system shutdown. It also keeps a count of the number of outstanding requests for major and minor alarms.

- 131 - ~ ~ $ ~

The multi-processor architecture of the DCB allows conferences to remain active while the system is reiniti~li7pf~ This process is called a 'warm boot.' While the host processor reinitializes, the conferences remain active because the DSP processors and Tl Network Interfaces run asynchronously from the host processor. However, the host software must correctly recover the information required to restore the conference arld channel data structures to their correct state. All conference and channel data, which is updated in real-time (e.g. call counts and timers), are'stored in the dual-port memory of the DSP. Other channel and conference data, that are not updated in real-time, are stored on disk. This information includes conference and channel names, conference modes, etc.

Data structures stored in the Digital Signal Processor's (DSP's) Dual-Port Memory (DPM) are examined by initdcb to determine the warm vs. cold boot-up status of the system and, for a cold boot, initi~li7~.1 Information stored in the DPM data structures survives System 70 warm boot-up reinitializations and is sufficient to recover per-channel and per-conference data, including time and billing records. Thus, the reinitialization has a minimum impact on pre-existing conference calls.
4. Detailed Desi~

Initdcb processing is performed in the order of the following sections describing its functionality.
4.1. DCB Environment The root of the DCB directories is defined by DCBPATHto be /usr/dcb in the attached init_lib.h header file. Tnit-lcl~ first adds DCBPATHto the set of environrnent variables and sets the current ~e~;lol~ to that value. There are sub-dile~ tol;es of DCBPATH
for various functions: -announce contains voice data files, bin contains the DCB pr~ce~s ~ cut~le files, cct~ contains call detail record files, dbase contains ~l~t~b~e, dial lists, pa~wold and related configuration files, some of which are stored in subdihc~,lol;es of dbase, new co,.t~ .pcl~ed P~ec lt~ files to replace those in the bin di~,lul~ on the next DCB restart, Iog contah~s files with error and status . ..~ s~g~s, reports contains DCB report files, and tmp contains t~.npol~ ~ files destined for the print spooler.

'~ - 1 32 ~ 4 ~ ~

4.2. DPM Access Access to the array of DPM data structures is through interfaces described in the DSP-Host Interface Design Specification. These interfaces obtain the physical starting address of the array of DPMs and map that address to virtual memor,v in the current process. A global pointer to the array of DPM structures is saved. Using this, DPM data is obtained sirnply by de-referencing the pointer.
4.3. Boot and Pre-service Test Status~

The following algorithm is used.to decide when to declare a cold/warm boot situation and when to perform pre-service diagnostics:
When initdcb is started, the warmboot boolean variable is initialized to TRUE and the testdsp boolean variable is initialized to FALSE.
If initdcb was executed with the -t option, testdsp is set to TRUE.
If initdcb was executed with the -O option, warmboot is set to FALSE.
If warmboot is now TRUE, initdcb examines known information stored in active DSPnodes. The active_nodes value must match the DSP driver's value. The value of this_node must match the assigned value. For all ports, the dpm port value must match the assigned value. If anv of these conditions are false, warmboot is set to FALSE.
4.4. Pre-Service Di~nostics Using the results of the initialization status algorithm described in the previous section, if warmboot is FALSE and testdsp is TRUE, pre-service diagnostics are performed.
Initdcb performs hardware diagnostics on the serial board, DSP's, Tl boards, and an integrated ~i~gnostic that verifies operation of DSP's, Tl boards and analog ports. No hardware r~ nostics are p~"r~ lled upon a warrn boot.
The serial card ports are ch~r~ by looping back the outputs and detecting the tr~n~ni~$ion of a prescribed sequence of ASCII characters. The op~"dt(,r may visually d~t~. ."i.-e proper baud rate co~ a~ibility and display operation when plesGnted with the first console display screen.
DSP ~ nostics are based on SDL provided source code for the DSP and the host that have been tr~n~l~teli to DCB-callable functions.
Tl ~ gnostics primarily checks that registers can be wriKen and read back col~etly.
An inte~.dled ~i~gnostic loops back and detects DSP generated signals ~luo~ the Tl board, analog card and back to verify signal co~u.e.,li~/ity.

4.5. Hardw~re and Resource Initialization Hardware and resource initializations are performed as follows:
if there are executable or DSP code files in the new directory, initdcb will move them to the bin directory (if present, a new version of initdcb will be exec'ed to replace the one executing), InitSHMO initializes the memory database and the alarm database, init_dspO is called to initialize the I)SP's for cold boots, the warm/cold boot initialization procedure for T1 boards is called, and InitDBColdO initializes system databases for cold boots; InitDBWarmO does the same for warm boots while taking into account the per channel conference numbers, in-conference tirne, and signaling inforrnation deri~ed from the hardware. InitDBWarmO recovers the conference number per logical channel unit and in-conference minutes from the DSP's Dual-Port Memory (DPM) and the per channel sign~lin~ information from the T1 Status registers (polling and Q&A data will be lost). The algorithrn used for warm bootinitialization and conference recovery is outlined below:
~ For each channel in the system, obtain the channel's current voice path information (this includes the conference number, mute state, gain state and music state) and network hook state settings (both incoming and outgoing).
~ Channels which are idle (on-hook in both directions) are placed in the Null Conference.
~ Channels which are connected (off-hook in both directions) and are in a user or operator conference are left in that conference. Channels in any other conference are placed in the Enter Conference. The channel's status information is recovered from both dual-port memory and from disk. A delta-time operation is performed on the channel's seizure time and the current time to recover any time information lost during the reiniti~li7~tion.
~ Channels which are disconnected (off-hook in one direction only) are placed in the Null Conference. The channel's status information is recovered from both dual-port memory and from disk for Call Detail Record (CDR) l~ollillg.
~ Co~ference status information is recovered both from dual-port memor,v and from disk for conf.,.e.~es which have I or more user rl~nn.olc ~ Record, Playback, Operator and Annunciator r11~nnrl.~ are all left in their current confer~nces.
4,6 Process Creation Next, initdcb creates the other DCB processes using their assigned priorities and provides the boof status as their first argument. The order of process creation is:
first, processes providing low level services - Error/Status Log, Timer, DSP Event and Tl Event processes, - 134 - ~ ~ 4~

processes providing higher level services - DSP Comm~n~i Processor, Annunciator, Call Handler, and Tl Handler, Iastly, user interface processes - Netrngr, Cdr, Report, Display Handler, and Login's (8).
Admin, Maint, Opcon's (8) and Display Update's (8) will be exec'd by the DisplayHandler and Login processes.
If any diagnostic problems or mic~in~ boards have been detected, initdcb executes an interface provided by opcon to relate the problem to the operator(s) and an interface provided by the Error/Status Log to record the problem in a disk file and send it to the system printer.
4.7. Sanity Checks and Deadman Placation Initdcb then sets a repetitive timer alarm for 3 second intervals and automatically placates the de~tlm~n circuit each time the timer reply is received. As each timer reply is received, initdcb requests a sanity check reply by sen~ing a message or signal to one of its child processes. It sends the request to each child process in round robin fashion and expects a reply before the same process is addressed again. Disphand and the login processes will answer with knowledge of the sanity of their child processes in mind. If the process has not replied to the sanity check request when it is due for another message, initdcb sets a major or minor alarm, depending on whether or not the process is a core process (critical to conferencing). It then repeats the de~lm~n placation and sanity check processingcontinuously.
4.8. Alarm Reportin~

Initdcb accepts messages, through an interface described in the appendix, for reporting major and minor alarms. It keeps a count of the number of times each alarm is exercised. If the count is greater than zero, the corresponding alarm is fired. It retires an alarm only when the count for the corresponding alarm drops to zero.
Initdcb sets the major alarm if the following core processes do not respond the sanity check:
Timer, DSP Event, Tl Event, DSP Comm~n-l, Call Handler, and Display Handler.
The minor aiarm is set if the following, non-core, processes fail to reply to tne sanity check:
Error/Status Log, ~nmln~ tor, Login's, Cdr, and Netmgr.
4.9. SystPm Shutdown Finally, initdcb also accepts a me~a~ge for a system rein~ i7~tion or shutdown.
This is expected to originate only from the maint process so that m~ f ~ ce pe,so~lel can install new boards, new lines, etc. or cleanly shutdown the system for any reason. It is the maint process's responsibility to insure that no conferences are still active before issuing this request. lnitdch then sends ~ message or signal to each process requesting that the process - 135- ,~

exit gracefully. After allowing 20 seconds for processes to close resources and to exit, initdcb then:
kills any surviving child processes, closes the DSP's with the close_dspO interf~re, closes other resources that have provided an applopliate interface, and . exits.

When initdcb exits for shutdown, the inittab script is designed to shutdown the UNIX kernel and wait for interaction from m~int~n~nce personnel; for reinitialization, a warm reboot is automatically invoked.

APPENDIX J
1. Introduction MultiLink's Digital Conferencing Bridge (DCB) MVIP bus and ST bus time slot assignments and related tables are documented here. These tables view the data from various points of view as described in the tables section.
One T1 line is assigned to each of the first six MVIP bus rails; only four T1 lines are planned for the first DCB release. On each rail, the first 24 time slots are allocated to T1 channels in channel order.
MVIP rails 6 and 7 are reserved for DSP internal communication. The first 24 time slots of these rails are allocated for talked and talk lists, respectively. A node sync is assigned to one of the rem~inin~ time slots on rail 6.
One operator or one annunciator channel is assigned to each of the first 16 Digital Signal Processor (DSP) nodes for a total of eight channels each, evenly distributed on the first four DSP boards (there are four DSP nodes per board). The operators and annunciators are assigned the rem~ining (i.e. last) eight time slots of separate MVIP bus rails. The transmit and receive sides of the operator channels are assigned to the lower and upper of two adjacent rails, respectively.
A music channel, the receive side of two link lines, and three record/playback channels are assigned to unused time slots on another MVIP bus rail. The transmit side of the two link lines is assigned to the lower adjacent rail. One link line and onerecord/playback channel are allocated to each of the first two and first three DSP boards, respectively.

....

8~Ll~oo8cNwrENDlx DOC

Claims (12)

We claim:

1. A signal processing apparatus for use in a system for teleconferencing a plurality of phone channels, said system being of the type including common bus means for carrying digital signals representing data incoming from and outgoing to said plurality of phone channels, comprising:
A. at least one digital signal processor (DSP), coupled to said common bus means and associated with at least three of said plurality of phone channels, and including means for:
(i) responding to incoming data on each of said associated phone channels by generating status signals, wherein each of said status signals is representative of a status of one of said associated phone channels;
(ii) transferring said status signals onto said common bus; and (iii) responding to a control parameter for at least initializing teleconferencing between said plurality of phone channels;
B. host processing means, coupled to said at least one DSP, for generating and storing for access thereby, said control parameters;
C. said at least one DSP further including means for:
(i) responding to said status signals associated with said plurality of phone channels to generate output data signals, wherein one of said output data signals is generated for each of said associated phone channels and wherein each of said output data signals is a function of at least selected ones of said incoming data signals;
(ii) transferring to each of said associated phone channels, one of said output data signals by way of said common bus; and (iii) maintaining teleconferencing between at least selected ones of said plurality of phone channels in the event of a selected fault by said host processing means.

2. A signal processing apparatus for use in a system for teleconferencing a plurality of phone channels, said system being of the type including common bus means for carrying digital signals representing data incoming from and outgoing to said plurality of phone channels, comprising:
A. a plurality of digital signal processors (DSPs), each of said DSPs being coupled to said common bus means and associated with a different one or more of said plurality of phone channels, and including means for:
(i) responding to income data on each of said associated phone channels by generating one or more status signals, wherein each of said status signals is representative of a status of one of said associated phone channels; and (ii) transferring said status signals to each other ones of said DSPs;
B. each of said DSPs further including means for:
(i) responding to said status signals associated with said plurality of phone channels to generate output data signals, wherein one of said output data signals is generated for each of said associated phone channels and wherein each of said output data signals is a function of at least selected ones of said incoming data signals; and (ii) transferring to each of said associated phone channels, one of said output data signals by way of said common bus.

3. An apparatus according to claim 2, wherein each of said DSPs include energy detection means for generating said status signals, wherein each of said status signals is indicative of a selected activity level of incoming data on one of said associated phone channels.

4. An apparatus according to claim 3, wherein said energy detection means includes means for generating each of said status signals as a function of an energy level represented by incoming data on one of said associated phone channels.

5. An apparatus according to claim 4, wherein said energy detection means includes means for generating each of said status signals as indicative of a value representative of a difference between said energy level represented by incoming data on one of said associated phone channels and an average energy level in said output data signal being greater than a threshold energy value.

6. An apparatus according to claim 3, wherein each of said DSPs include talk-list means responsive to said status signals for generating said output data signals as a function of incoming data on a selected number of those of said plurality of phone channels that have said selected activity level of incoming data thereon.

7. An apparatus according to claim 6, wherein said talk-list means includes means for generating and storing a current talk-list signal representing said selected number of said plurality of phone channels that have said selected activity level of incoming data thereon.

8. An apparatus according to claim 7, wherein said talk-list means includes means for generating said current talk-list signal identically and substantially with each other of said talk-list means.

9. An apparatus according to claim 7, wherein said talk-list means includes means for selecting for representation in said talk-list signal ones of said plurality of phone channels that have an energy difference between an energy level represented by incoming data on one of said plurality of phone channels and an average energy level in said output data signal that exceeds a designated value.

10. An apparatus according to claim 7, wherein said talk-list means includes means for selecting for representation in said talk-list signal ones of said plurality of phone channels having an energy level represented by incoming data on one of said plurality of phone channels that exceeds an average energy level of said current talk list signal.

11. An apparatus according to claim 2, wherein A. each of said plurality of DSPs include means responsive to a control parameter for at least initializing teleconferencing between said plurality of phone channels, B. said apparatus further comprising host processing means, coupled to said plurality of DSPs, for generating and storing for access thereby, said control parameters, C. each of said plurality of DSPs further including means for maintaining teleconferencing between at least selected ones of said plurality of phone channels in the event of a selected fault by said host processing means.

12. A method for teleconferencing a plurality of phone channels in a system having a common bus means for carrying digital signals representing data incoming from and outgoing to said plurality of phone channels, comprising the steps of:
A. coupling a plurality of digital signal processors (DSPs) to said common bus means wherein each of said DSPs is associated with a different one or more of said plurality of phone channels, and wherein each of said DSPs receives said incoming data from said associated phone channels;
B. responding to incoming data on each of said associated phone channels by generating status signals, wherein each of said status signals is representative of a status of one of said associated phone channels;
C. each of said DSPs transferring said status signals of each associated phone channels to each other of said DSPs;
D. responding to said status signals associated with said plurality of phone channels to generate output data signals, wherein one of said output data signals is generated for each of said associated phone channels and wherein each of said output data signals is a function of at least selected ones of said incoming data signals; and E. transferring to each of said associated phone channels, one of said output signals by way of said common bus.