Anatomy of a Voice Processing NLM
Articles and Tips: article
Senior Research Engineer
Systems Research Department
01 Jun 1995
Voice processing systems today integrate voicemail, FAX, E-mail, databases, and text-to-speech modules. High cost, proprietary voice processing solutions that once characterized the industry are giving way to PC-based applications that provide all of the capability of traditional systems, but at a fraction of the cost. This AppNote takes a look at how a third-party application integrates with NetWare and GroupWise and takes advantage of NetWare Directory Services, and analyzes the architecture of Call Ware, a member of this new breed of voice processing applications.
Previous AppNotes in This Series Apr 95 Unified Messaging: Paving the Road to Pervasive Computing Feb 95 Computer Telephone Integration: Call Control vs. Voice Processing
Introduction
The open architectures and down-sizing experienced by the data industry in the early '80s has come to the telephony world in the '90s. High-cost, proprietary voice processing solutions that once characterized the industry are giving way to PC-based applications that provide all of the capability of traditional systems, but at a fraction of the cost. Today these systems provide low-cost voicemail, and by integrating with FAX, E-mail, databases, and text-to-speech modules, they are turning the telephone into another terminal on the LAN using an interface we all know how to use: human language and a telephone handset.
On a second front, GUI front-ends to LAN-based voice processing and call control applications enable all members of an organization to use the full capability of the modern telephone switch. Operations that are difficult to perform using a telephone handset, such as setting up a consultation or conference call, are now accomplished from the PC in a visual environment, making a company's investment in advanced switch features pay off.
This AppNote examines this emerging technology by analyzing the architecture of a member of this new breed of voice processing applications: CallWare. At the same time, this AppNote presents a look at a third-party product that integrates with both NetWare and GroupWise and takes advantage of NetWare Directory Services.
Hardware Environment
CallWare is the first, and currently, the only voice processing system designed to take full advantage of the NetWare operating system by running as an NLM under NetWare 3.x/4.x. Like traditional voice mail software, CallWare interfaces to a switch and is controlled through a telephone keypad. Like its more advanced predecessors, it also interfaces to the LAN to provide a graphical interface to its voice processing features. The graphical interface is accomplished using CallWare's Windows-based Application Programming Interface, CWAPI.
CallWare interfaces with three types of data:
Analog Data
Integration data
CWAPI data
Analog Data. Analog data - in the form of voice and DTMF data (user key presses and so on) - is passed between the switch and one or more voice boards installed in the CallWare server. A voice board driver NLM serves as the backend to the CallWare engine. It communicates with and controls the voice board(s) whose functions include establishing connections with the switch, compressing message file data, and interpreting and generating DTMF tones. The connection between the switch and the voice board is typically accomplished through a two-wire (for single channel) or four-wire (for dual-channel) telephone cable terminated at the voice board with a standard RJ-11 or RJ-14 connector.
Integration data. Integration data is data received from the switch that conveys information about a call. This information tells whether a call is a direct dial-in or a forwarded call due to a busy extension or a no-answer. Based on this information, CallWare determines whether a box owner is accessing his mail box, or if a caller is being forwarded to the box of a busy or nonanswering extension. CallWare then treats the call appropriately.
There are several ways to convey this information. One way, in-band integration, uses DTMF tones across the analog connection (between the switch and the voice board) to convey call information to CallWare. A second method, called SMDI (simplified message desk interface), provides an industry-standard protocol for exchanging call information via RS-232 connection between the switch and a serial port on the CallWare server. Finally, NetWare Telephony Services can be used to pass integration data using Novell's Telephony Services API ( TSAPI). The physical interface between the switch and the Telephony Services server depends upon the PBX manufacturer, and can range from X.25 packets across an RS-422 connection to Ethernet.
CWAPI data. CWAPI data comprises commands and data passed across the LAN between the CallWare engine and the CallWare Windows client API DLL (CWAPI.DLL). This DLL allows users to see and manipulate new and saved messages, and to create new messages for delivery to other users. Applications that incorporate CWAPI do not require any additional integration hardware at the workstation level, since all voice-processing functions are carried out on the CallWare server; CWAPI simply provides an alternate, visual, method of entering command data to the CallWare engine. Figure 1 illustrates the CallWare I/O model.
Figure 1: CallWare physical interfaces.
Software Overview
CallWare was designed to be highly configurable while providing easy access to voice processing features. Configurability was achieved in the engine through the use of a scripting language and port-based system setup. Open access to CallWare's features is provided by its client/server architecture and CWAPI, which makes the services of the CallWare engine available to developers wishing to integrate voice processing services into their Windows applications.
The components of the CallWare system fall into two main categories:
The CallWare engine
Windows client applications
The CallWare engine provides voice processing services. It interfaces to the NetWare operating system and to system hardware, such as the voice board, and provides interfaces to the CallWare Windows client applications. The logic used by the engine to process calls is programmed into a script file and a companion configuration file.
The Windows client applications include CWSNAP.DLL and CWAPI.DLL. CWSNAP.DLL is an NDS integration utility that "snaps in" to the NetWare Administrator program to extend the NDS schema to include CallWare user data and to allow CallWare user administration from within the NetWare Administrator. CWAPI.DLL, as previously described, is an API library used to integrate CallWare services into client/server messaging applications. CallWare ViewPoint (a Windows-based CallWare client application available from CallWare Technologies), uses CWAPI to provide a graphical interface to CallWare's most commonly used services.
These two elements of the CallWare system, the engine and the client pieces, are described in the remainder of this AppNote.
The CallWare Engine
The CallWare engine provides all of CallWare's voice processing services, which include switch integration, administration interface, voice board interface (via voice board drivers) and script command interpretation. These services are provided through a three-layered system of service, engine, and driver NLMs, illustrated in Figure 2.
Figure 2: Engine architecture.
The engine NLM, CWENGN, communicates with the service layer NLMs through shared memory and with the voice board driver NLM through remote procedure calls (RPC). The driver NLM, which communicates directly with hardware, must operate in ring 0 of the Intel CPU. Using RPCs to communicate with the driver allows the CWENGN NLM to operate in either ring 3 or ring 0. This is important to system administrators who typically like to run new applications in ring 3 to prove their stability before running them in ring 0, where a faulty application can abend the server by accessing memory it doesn't own.
CallWare Service NLMs
The CallWare service NLMs provide two categories of service to the CallWare engine. CWTSAPI.NLM and CWSMDI.NLM provide advanced switch integration capabilities, while CWVIEW.NLMand CWNDS.NLM are middle pieces that stand between CWENGN.NLM and the Windows client DLLs (CWAPI.DLL, the Windows client API, and CWSNAP.DLL, the NDS-based CallWare user administration interface).
CWTSAPI. The CWTSAPI NLM is a TSAPI client application that passes information between the CWENGN NLM and the switch via TSAPI. CWTSAPI appears as a single TSAPI client. There is no direct communication between the CallWare engine and the NetWare Telephony Services interface, TSERVER. All TSAPI communications between the CallWare engine and TSERVER occur through the agency of the CWTSAPI NLM.
CWSMDI. The CWSMDI NLM provides the CallWare engine with SMDI integration capability. It interfaces the CWENGN NLM, via Novell's Asynchronous I/O (AIO) service, with SMDI (call control) data coming from the switch, and formulates call information generated by the engine into SMDI packets that are sent back to the switch via AIO. Switches that have native SMDI integration capability require only a serial connection between the CallWare server and the switch. Switches that do not have native SMDI capability can still enjoy the benefits of SMDI integration with the addition of a voice bridge. (A voice bridge is a device designed to convert call control data into SMDI packets.)
CWVIEW. The CWVIEW NLM provides the interface used by the CWAPI.DLLto communicate with the CWENGN NLM (CWAPI.DLL is the CallWare client API used to create client applications). The CWVIEW and CWENGN NLMs are tightly integrated and communicate through shared memory to allow the CWVIEW NLM access to most of the command functions and data maintained by the CWENGN NLM. The TLI protocol is used for CWAPI/CWVIEW communications. CWVIEW.NLM should not be confused with CWVIEW.EXE, the CallWare ViewPoint Windows client executable.
Requests for CallWare engine services from CWAPI-enabled client applications are received by the CWVIEW NLM and are either serviced by CWVIEW itself, or cause commands to the CWENGN NLM to be generated. Unsolicited events to CWAPI.DLL are also generated by the CWVIEW NLM based on data output to shared memory by the CWENGN NLM. This allows, for instance, dynamic updates to message lists as new messages are placed in user mailboxes by the CWENGN NLM.
CWNDS. The CWNDS NLM is a middle layer between the user administration functions built into the CWENGN NLM and CWSNAP.DLL, the Windows client application used to administer CallWare via NetWare Administrator. This NLM synchronizes with the CallWare engine, changes to user box data that is stored as NDS objects and has been modified by CWSNAP.DLL. It receives user definition data entered to the NDS CallWare user object from CWSNAP.DLL and updates the user definition database file, BOX.DAT, as well as the box data records cached in memory by the CallWare engine.
All of the service NLMs contain an optional C-Worthy (NUT) interface with standard Install and Trace options. Other menu options are specific to each NLM. For instance, for the CWVIEW NLM, there is a Connection Information option that provides capabilities similar to the Connection Information option in the NetWare Monitor NLM. This option allows you to view user activity occurring across the CWAPI connection.
The CWENGN NLM
The CWENGN NLM is the heart of the CallWare system. Among other things, CWENGN handles:
script file interpretation
message record and playback
message addressing and transport
system administration (user database administration)
switch integration
message system maintenance (nightly cleanup, etc.)
network message communications (AMIS)
notification call-outs
At the center of the CWENGN NLM is a command interpreter that processes the CallWare script. The CallWare script - an ASCII file with a .SPT extension located in the CallWare directory - contains the CallWare commands, variables, and flow-control logic that define how the engine behaves when a call is received or generated by the engine. The script-driven nature of the CallWare engine allows users to define the personality of the CallWare system by programming their own applications in the CallWare script.
The Command Interpreter. CallWare scripting language commands call and pass data to function primitives programmed into the CWENGN NLM, and provide flow control and testing logic that enable the script to branch based on the integration type, call type, box type, and enabled box services for the boxes involved in a call.
When a call is received or generated by the engine, the engine reads a tokenized version of the script and follows the logic it contains, referencing the box definition settings contained in the box-definition database file, BOX.DAT, and branching to labels that execute the appropriate actions (playing prompts, recording or playing messages, etc.). Key to the CallWare system are box types and box services, which are user definable and which give the CallWare system its personality.
Box Services and Box Types. The CallWare scripting language contains commands that test the box(es) involved in a call for both their box type and their enabled box services. When one of these test commands returns true, script execution jumps to the label defined in the command, where the commands that define the behavior of the box type or service are located.
Two box types are defined in the default CallWare script and configuration files: voicemail boxes, and audiotext boxes. A voice mail box is the type of box we typically associate with a voice processing system. Like an E-mail box, it is the box you access to send and receive your messages.
An audiotext box is typically not assigned to users and is not designed to receive or send messages. Rather, audiotext boxes are designed to hold recorded information and to provide branching logic to allow access to other audiotext or voicemail boxes. A typical instance of an audiotext box is an automated attendant that greets incoming callers and provides options to dial an extension or transfer to an operator. Another example is audiotext-driven technical support applications which are built entirely using this type of box.
The box types and box services available in a CallWare installation are defined in the CWPRTSPT.CFG file. CWPRTSPT.CFG is an ASCII file that contains the names of box types and box services. The values in this file are loaded when CallWare is started and appear in the box configuration screens where, in the case of box types, they can be assigned to a box, or in the case of box services, they can be individually enabled or disabled for a box. Each box service has an associated number, based on the position of the box service within the list of services, that serves to identify the box service in the script.
Figure 3 shows the Box Services section of the CWPRTSPT.CFG file and the resulting Services Parameters screen in the CallWare administration interface, where the services are actually enabled or disabled on a per-box basis. A script is authored to include TEST_BOX_SERVICE commands that test the boxes involved in a call to determine which services are enabled and then jump to the script commands that execute enabled services, while bypassing commands for disabled services.
Figure 3: Box Services Definition.
A script is typically authored in modules that define the functionality of a box service or box type. For instance, the standard script that ships with CallWare contains the statements shown in Figure 4. Based on the integration type indicated in the in-band or out-of-band data associated with the call, execution jumps to a label where the box type is tested. A true return value causes execution to jump to a label where logic for the given integration and box type is found.
Figure 4: TEST_BOX_TYPE Branching.
:INT_SIGNALING
clear_dtmf_buffer()
test_integration_type(0, INT_RETRIEVE_MESSAGES);
test_integration_type(1, INT_FORWARD);
test_integration_type(2, INT_FORWARD_BUSY);
test_integration_type(3, INT_FORWARD_NO_ANSWER);
test_integration_type(4, INT_DIRECT_TO_BOX);
test_integration_type(5, SELECT_BOX);
jump(GET_DEFAULT_MBOX)
:INT_RETRIEVE_MESSAGES
test_box_type(box1, 2, GET_AUDIOTEXT_PASSCODE_1)
test_box_type(box1, 1, GET_VMAIL_PASSCODE_1)
jump(GET_DEFAULT_MBOX)
:INT_FORWARD
test_box_type(box1, 2, PROCESS_AUDIOTEXT)
test_box_type(box1, 1, VMAIL_FORWARD)
jump(GET_DEFAULT_MBOX)
:INT_FORWARD_BUSY
test_box_type(box1, 2, AUDIOTEXT_BUSY)
test_box_type(box1, 1, VMAIL_BUSY)
jump(GET_DEFAULT_MBOX)
Since CallWare allows boxes to be assigned to a particular voice board port, and also allows different scripts and different greetings to be used for different ports, an end user can easily design multiple voice processing applications. Each of these applications can be accessible from lines off of different switches, with different boxes assigned to each application. In essence, as many different voice processing applications can be running as there are voice board ports, all within one instance of the CallWare engine.
For example, a service bureau might assign ports 1 - 16 and boxes 1 - 1000 to a hotel that uses a special-purpose CallWare script to provide voice mail services to hotel guests; ports 17 - 24 and boxes 1001 - 1500 to a school that uses the Education Homeline script (developed by International Voice Exchange) that allows parents to collect homework for homebound children; and ports 25 - 32 and boxes 1501 - 2000 to ABC corporation, which uses the standard CallWare script for their corporate voice mail system. The multi-threaded nature of CWENGN NLM allows simultaneous operation of each of these "virtual" voice processing systems. Figure 5 illustrates such a system.
Figure 5: Multiple CallWare applications with one CallWare engine.
CWENGN Features
Along with the scripting features described above, the CallWare engine supports several advanced features. Some of the most interesting are:
Notifications
Port-based switch integration
Port-based greetings
Template mailboxes
AMIS Networking
CallWare system setup and administration is accomplished either through the Windows NetWare Administrator, or on the server through a C-Worthy(NUT) interface. The C-Worthy interface (part of the CWENGN NLM) provides screens for administering the features listed above, along with mailbox and user setup, and switch integration. The user administration screens parallel those in the NDS integration component, described later in this AppNote.
Notifications. One of the most powerful features of the CallWare engine is notifications, a feature that can provide four different types of event-driven user notification. The four types of notification are:
Pager - you are notified by pager after a set number of messages have accumulated unplayed in your mailbox for a predefined period of time.
Telephone - you are notified by telephone after a set number of messages have accumulated unplayed in your mailbox for a predefined period of time.
Wakeup - CallWare dials you anywhere there is a phone at a predefined day and time.
Message Escalation - messages are escalated (copied) to another mailbox after a set number of messages have accumulated unplayed in your mailbox for a predefined period of time.
Notifications are set up by the CallWare administrator on an individual mailbox basis, with certain parameters, such as enabled/disabled, wake-up time, and dial-out number. These features are definable by the user from the telephone keypad. CallWare allows up to four different notification configurations to be set up for each mailbox.
These four "notification plans" can be of any type (message escalation, pager, telephone, or wakeup) so that you could define a wakeup call to go out each morning to your home to wake you up, a pager call to notify you of messages before you get to work, a message escalation notification for unanswered messages you can't get to during the day, and a telephone notification for the evening hours of the day.
Figure 6 shows the parameters screen for notification plan 1. This notification is designed to dial "9,481-8984" between the hours of 8 AM and 5 PM, Monday through Friday, when five new messages have accumulated unplayed for a period of 30 minutes in the user's mailbox.
Figure 6: Notification Parameters Screen.
Port-Based Switch Integration. Each port of the voice board can be integrated to a different switch using the Port Telephone System selection screen pictured in Figure 7. This screen lists integration values for over 100 different switches, allowing integration to in-band loop or DID lines with as many different extension digits as the switch supports.
Figure 7: Port Configuration Screen.
Once you define the switch, additional parameter screens are available to set timing, voice board, call control, and signalling integration data specific to the selected switch.
Port-based Greetings. A corporate greeting box, sometimes called an autoattendant, is a box that contains a greeting that is played for outside callers when they access the system. CallWare allows different greetings for up to six different time blocks per day for each day of the week on a per-port basis. This high degree of configurability, when added to the port based switch integration, box assignment, and scripting featuresof the engine, allow service bureaus and others to build multiple voice processing systems within a single server.
Template Mailboxes. Over 120 fields of information are required to set up a single CallWare mail box. This can make mailbox setup an arduous task. To ease the task of box set up, CallWare provides a copy function that allows a single box to be copied to a range of box numbers. By creating "template" boxes with system rights tailored to the different employee classifications within an organization, and then creating ranges of mailboxes for assignment to the employees in each job class, an administrator can substantially reduce the time required to get a voice processing installation up and running. In most cases, using this technique reduces box setup to simply changing a user's name, extension, box number, passcode, and one or two other fields.
AMIS Networking. The Audio Messaging Interface Specification (AMIS) is an industry standard for voice message exchange between different voice processing systems. The standard addresses the problems of message file format, addressing, and message transmission. By supporting the AMIS analog standard, CallWare provides cross-system compatibility with all other analog AMIS-compatible systems. This means that voice mail messages can be addressed to users of other voice processing systems anywhere in the world. This feature enables companies to link their voice mail systems across multiple sites and voice mail systems. It also makes the upgrade path to CallWare smoother, since companies can gradually phase out their old systems while preserving networking features as sites convert to CallWare.
Windows Client Applications
CallWare is a client/server application. It was designed to leverage the ease-of-use provided by a graphical user interface to make the most difficult and powerful features of a voice processing system available to all members of the organization.
CallWare's developers recognized the need to integrate voice processing system administration with the administration of the network. They also recognized the movement towards unified messaging, which is the unification of voice, text, and document (FAX) messaging within a common end-user interface and administrative structure. To accommodate these requirements, CallWare adopted a three-pronged strategy:
Develop an API to expose the services of the engine to Windows application developers.
Integrate CallWare user administration functions with NDS.
Integrate CallWare with GroupWise.
CallWare developed CWAPI, a Windows API that exposes the services of the engine to third-party applications, and CallWare ViewPoint, a CallWare client application that uses CWAPI to provide a graphical user interface to CallWare. To integrate with NetWare Directory Services, CallWare developed CWSNAP.DLL, a Windows snap-in for the NetWare Administrator utility that extends the NDS user object to include CallWare user data. CWSNAP.DLL also provides data entry screens for this data.
To integrate with GroupWise, CallWare developed two DLLs, one loaded by CallWare ViewPoint, the other by GroupWise, that together provide access to CWAPI from GroupWise. These DLLs provide integration of CallWare's message list with the GroupWise message list, and access to CallWare record, playback, and other features from within GroupWise.
CWAPI and CallWare ViewPoint. CallWare ViewPoint is a graphical interface to the most commonly-used voice processing features. The CallWare ViewPoint Main Window, shown in Figure 8 appears when the user executes the program. Most of CallWare ViewPoint's features are directly accessible from this screen, including point-and-click message playback, deletion, forwarding , and reply.
Figure 8: CallWare ViewPoint Main Screen.
Record and play dialogs provide cassette and slide bar controls to allow greater control of message playback than can be provided through a telephone keypad interface. An address book allows single or multiple addressee selection, including distribution list addressing, and a delivery options dialog allows messages to be flagged confidential, return-receipt requested, or future delivery.
With CallWare version 5.1, subject and comment fields will be supported in the message list. Users can create text messages to accompany voice messages, as well as brief descriptions of messages that will appear in the subject field. The text message will play an especially important role in GroupWise integration, where it will be converted to a native GroupWise E-mail message, and the voice message will be converted to a .WAV file attachment to the message. Distribution list creation will also be supported in the 5.1 release, so that users can create their own named and numbered distribution lists by selecting users from the address book.
CallWare ViewPoint uses CWAPI to control and communicate with the CallWare engine through CWVIEW.NLM. CWAPI is a library of CallWare functions and structures that is sold to Windows application developers as a separate product by CallWare Technologies, Inc. The library provides functions to list, record, play, and address messages, as well as functions to perform user-definable setup tasks, such as distribution list creation, notification editing, passcode change, and so on.
CWAPI was designed to be platform independent. Versions of the API for UnixWare, OS/2, and Macintosh are planned for future release.
NDS Integration. NDS integration is CallWare's solution to the problem of unifying message system and data system administration. The advantages offered to voice mail administration by NDS are the same as those offered to E-mail: single point administration, synchronization of distributed directories, simplified user data administration, and so on.
NDS provides a mechanism for NetWare applications to extend the NDS schema in order to write application-specific data to the NDS database. Using this mechanism allows applications to piggyback on NDS to gain the benefits of data distribution, synchronization, and other NDS features. The Windows version of the NetWare Administrator (NWADMIN) also provides a mechanism for application developers to augment this NDS administration interface with their own data entry screens so that data can be entered to their schema extensions from within the NetWare Administrator.
CallWare uses both of these features to provide an alternate administration interface to the NUT screens available from the server console. The first of these CallWare snap-in user administration screens is shown in Figure 9.
Changes made through the NetWare Administrator screens are relayed via CWSNAP.DLL to the CWNDS NLM so that it can update the user box database and notify the CWENGN NLM of changes made to the box database. The latter is particularly important, since the engine maintains an abbreviated box database in memory that must be kept current at all times.
Figure 9: NetWare Administration CallWare User Screen.
An interesting feature of the CWSNAP.DLL is its ability to dynamically change the Service Parameters screen to accommodate changes made to the box service definitions in the CWPRTSPT.CFG file. This feature, along with the ability to dynamically change the contents of the Box Type drop-down list based on the box types defined in CWPRTSPT.CFG, preserves the configurability of CallWare.
GroupWise Integration
CallWare Technologies has chosen to integrate with Novell's GroupWise to achieve their unified messaging solution. Figure 10 shows the GroupWise Main Window with the integrated CallWare ViewPoint icons. With GroupWise integration, new and saved CallWare messages appear in the GroupWise message list where they can be played or deleted, and receipt of a new message triggers the GroupWise notification function that pops up to inform you that a new message has arrived.
Figure 10: GroupWise Main Screen with CallWare Integration.
Just as clicking on an E-mail message opens a message viewer, clicking on a CallWare ViewPoint message in the GroupWise message list opens CallWare ViewPoint with the chosen message selected. The user can then perform any action on the message permitted by CallWare ViewPoint.
CallWare ViewPoint has a built in text editor that allows users to attach text messages to voicemail messages. In GroupWise, this text message becomes a GroupWise E-mail message, and the associated voice message is converted to a .WAV file attachment to the message. By treating the voice mail message as an attachment, CallWare messages can be forwarded to any destination available to a GroupWise message, including addresses on the Internet.
If CallWare ViewPoint is installed on the recipient workstation with GroupWise integration enabled, the message will automatically be playable either as a .WAV file or as a standard CallWare message through the phone system, since, upon receipt, the message will be automatically converted back to the native CallWare format and stored as a normal voice mail message in the recipient's mail box on the server.
GroupWise users who do not have CallWare installed can still receive and play CallWare messages as long as they have a Windows sound board (or the PC speaker sound driver) installed. The .WAV file can be played back directly within GroupWise, as pictured in Figure 11. In effect, GroupWise integration provides near universal workstation-based connectivity to CallWare.
Figure 11: GroupWise .WAV File Playback Screen.
When CallWare ViewPoint is installed with GroupWise integration enabled, it registers a CallWare message type with GroupWise, along with the name of the DLL that will handle events associated with CallWare messages. Following registration, this DLL, named GWCW.DLL, loads automatically when GroupWise is started.
GWCW.DLL provides a one-way communications path from GroupWise to the CallWare engine. For instance, when a user deletes a voicemail message through the GroupWise interface, GroupWise sends a "delete" message to GWCW.DLLidentifying the message deleted. GWCW.DLL in turn messages the CallWare ViewPoint executable, which in turn messages the CallWare engine via CWAPI. The engine then deletes the message.
CWGW.DLL is the other DLL involved in GroupWise integration. Its role is to pass messages to GroupWise from CallWare ViewPoint. For example, when a new voice mail message is received, the CallWare ViewPoint executable calls a function in CWGW.DLL, which in turn passes the data on to GroupWise via calls to the appropriate GroupWise API functions.
Acknowledgements from the CallWare engine of actions generated in GroupWise are also conveyed through this DLL. The purpose of segregating GroupWise integration functions into DLLs is twofold. First, GroupWise requires a DLL to process GroupWise events for each registered message type. Second, placing GroupWise API function calls into a DLL, instead of in the CallWare ViewPoint executable, maintains the modularity of the CallWare ViewPoint executable which is authored to load CWGW.DLL if it is present, and send messages to it once it loads, otherwise assume no GroupWise integration and omit messaging the DLL.
Figure 12: CallWare ViewPoint-GroupWise Integration.
Summary
The ability of voice processing application developers to easily gain the services of a voice processing engine gives CallWare an edge over competing voice processing development kits that are beginning to flood the market. CallWare script developers are today creating special- purpose voice processing applications in a fraction of the time required with other voice processing development kits. When CWAPI is added to the equation, developers have the ability to create custom client/server voice processing solutions. CallWare is currently the only voice processing product that can be administered via NDS and integrated with GroupWise.
As computing continues to move toward internetworking and the marketplace turns to Novell's vision of pervasive computing, the need for voice processing products positioned to operate in a client/server internetworked environment should prove the wisdom of CallWare's approach to voice messaging.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.