Call.center



MCCT’s Matrix2 Fax Application Using Aculab Resources

I. Introduction

MCCT has chosen the Aculab Prosody platform to be the foundation for its Matrix2 Fax application. Features of the Matrix2 Fax application include the ability to send and receive faxes, broadcast fax and fax-on-demand. The fax framework uses a .tiff image (Group 3 TIFF) for both transmit and receive; however, the fax source may be .txt, .doc, .rtf (and many more) that may be converted to a .tiff image.

In the Matrix2 Plan Editor, all that is required for Fax commands is a simple set of the basic receive and send commands to invoke the Aculab Fax resources. The Plan Editor already contains a robust set of commands that can handle the remaining aspects of any fax application such as setting up a fax broadcast and selecting fax titles to be sent in a fax-on-demand scenario. The FAXRECEIVE and FAXSEND commands are shown in Figures 1 and 2, respectively.

[pic]

Figure 1. FAXRECEIVE Command Screen.

[pic]

Figure 2. FAXSEND Command Screen.

In this paper, there are discussions on Aculab Prosody DSP resources required, fax applications using the Matrix2 Plan Editor and .tiff format usage. The thrust is the integration of the fax resources with the capabilities of recording and sending voice messages and sending e-mail; in essence, these are the components of Unified Messaging. (The next White Paper will be on Unified Messaging once it is formally packaged in the Plan Editor with special commands and supporting documentation). All the pieces are in place; it is just a matter of formal presentation and appearance.

II. Matrix2 Aculab Fax Overview

The Matrix2 system has historically run on RedHat Linux 7.2, kernel 2.4.20-28.7. The Aculab software ran on dtk132, which did not support Aculab Fax. Aculab was upgraded to dtk141, as this version was developed to support both Fax and VoIP. After this upgrade, there were problem in compiling using the gcc2.96-98 compiler – in fact, there were problems compiling with other compilers such as gcc2.96-112. It was decided to upgrade RedHat to version 7.3 since a later version would not have some of the bugs in the compilers. We decided to install Aculab dtk141 on RedHat Linux 7.3 with the gcc2.96-110 compiler and Fax compiled as expected.

Prosody Resources – General

Aculab’s voice resource boards are made up single, dual or quad T-1/E-1 modules with additional Sharc modules available: there can be 1, 2, 3 or 4 Sharc modules on a board – each providing a maximum of 64 voice resources, depending on the features used. For a quad board with 96 channels for T-1 and 120 channels for E-1 there are criteria for determining how many voice resources are required. These are (assume quad boards):

Feature Resources per Sharc

Play/Record w/DTMF 64

Conferencing 64

Speech Recognition and DTMF 64

Speech Recognition w/Barge-in & DTMF 25

Fax Send 46

Fax Receive 12

For a system with 96 ports (92 assuming ISDN where the D-channel is not counted) being used for fax and standard Play & Record, 276 resources would be required if the system were full and every feature was being used simultaneously (This is calculated based on three features per channel, i.e., 1. Play OR Record, 2. fax send and 3. fax receive ( 3 x 92 = 276).

Since not all features will ever be used simultaneously, fewer resources are required. As an example, when a caller is sending a fax he is not receiving one, and vice versa. The more accurate estimate of maximum resources used at a given time is 184. In this situation, due to the limited resources provided from one Sharc for fax send & receive, more sharcs will be required than in a simple voice resource environment. Based on the “Resources per Sharc” numbers shown on the previous page and assuming that any given time there could be a maximum of 92 voice resources (2 Sharcs = 128), 12 fax receive (1 Sharc) and 46 fax send (1 Sharc) you would need 4 Sharcs to provide the required resources. For voice resources, 2 Sharcs provide 36 more resources (128 – 92 = 36) than required for a full system so these could provide a buffer for the 12 fax receive and 46 fax send estimates. If more fax activity than the estimates was encountered, more Sharcs would need to be added and since there is a maximum of four Sharcs per quad board and additional board would be required which would not be cost-effective unless more ports were added. The management of resources will require good planning for a cost-efficient system. Note: Typically, for 92 ports, 12 fax receive and 46 fax send are more than adequate for any given peak time.

Fax Firmware Requirements

For each Aculab feature being used, there are firmware modules that must be loaded when the system is booted. The specific modules are edited into the “LoadSharc.sh” shell script as will be shown. The modules are in the form of .elf files as shown below:

[root@linux9 /]# cd /usr/aculab/dtk141/ting/sharc/gen/

[root@linux9 gen]# ls

11_to_8.elf fast.elf passthru.elf recA.elf timerx.elf

8_to_11.elf fskasyrx.elf play16b.elf recima.elf tonegen.elf

ansdet.elf fskpll.elf play8b.elf recms8b.elf v110.elf

asyrx.elf fskrx.elf playablk.elf recmu.elf v110rlpr.elf

asytx.elf fsktx.elf playA.elf recoki.elf v110rlpt.elf

civ.elf gainbg.elf playima.elf six2five.elf v17tx.elf

conf.elf grunt.elf playms8b.elf sixkin.elf v27rx.elf

cpumon.elf hdlcrx.elf playmu.elf sixkout.elf v27tx.elf

cwrx.elf hdlctx.elf playoki.elf slow.elf v29rx.elf

cwtx.elf inchan.elf prefsuf.elf sync.elf v29tx.elf

datarx.elf kernel.elf rec16b.elf syncrx.elf

datatx.elf kernel.smf rec8b.elf synctx.elf

echocan.elf outchan.elf recablk.elf td.elf

The required modules for any Aculab feature can be determined by using the Aculab TiNG Channel Capacity Calculator; a list of software modules is given once all of the feature requirements are filled in. The required modules can also be determined manually using the Prosody Software Modules tables, shown on the next few pages.

Prosody software modules

Prosody uses modular firmware, with each module performing a function. This allows the exact mix of firmware to be downloaded.

Data communications

|Data Communications modules |

|Module |Purpose |

|asyrx |Async receive. This is used to implement the async encoding in a receive protocol. It decodes a stream of digital data into a sequence of |

| |characters. |

|asytx |Async transmit. This is used to implement the async encoding in a transmit protocol. It encodes a sequence of characters as a stream of |

| |digital data. |

|cwrx |CW modem receiver. This decodes an incoming signal from a CW modem. However it does not convert it to digital data, so either fskpll or |

| |fskasyrx must be used, depending on how the data is encoded, to complete the decoding. |

|cwtx |CW modem transmitter. |

|datarx |Raw data receiver. This is used to run a protocols directly on a digital bearer channel (in contrast to speech and modems which encode the |

| |data as sounds). |

|datatx |Raw data transmitter. This is used to run a protocols directly on a digital bearer channel (in contrast to speech and modems which encode the|

| |data as sounds). |

|fskasyrx |Async receiver for FSK modems. This decodes a sequence of characters from the data received by an FSK modem receiver. This is different from |

| |running async on other received data streams because there is no clock. |

|fskpll |Reconstruct a clock from a received FSK data stream. If the output of an FSK modem receiver is to be interpreted as a synchronous encoding, |

| |then the data must be divided into bits using a clock recovered from the signal. This module does this, converting the received signal into a|

| |digital data signal suitable for decoding by HDLC or sync. |

|fskrx |FSK modem receiver. This decodes an incoming signal from an FSK modem. However it does not convert it to digital data, so either fskpll or |

| |fskasyrx must be used, depending on how the data is encoded, to complete the decoding. |

|fsktx |FSK modem transmitter. |

|hdlcrx |HDLC receiver. |

|hdlctx |HDLC transmitter. |

|six2five |A helper module used by the modem transmitters V.27ter, V.29, and V.17. |

|syncrx |Synchronous data receiver. |

|synctx |Synchronous data transmitter. |

|v110 |The V.110 protocol. |

|v110rlpr |The V.110 RLP receiver. |

|v110rlpt |The V.110 RLP transmitter. |

|v27rx |V.27ter modem receiver. |

|v27tx |V.27ter modem transmitter. Also requires six2five |

|v29rx |V.29 modem receiver. |

|v29tx |V.29 modem transmitter. Also requires six2five |

|v17tx |V.17 modem transmitter. Also requires six2five |

|prefsuf |Prefix/suffix provider. Adds a prefix and a suffix to each transmission. The prefix and suffix can by any number if bits in length. |

Data communications modules must be used in the combinations described in Prosody data communcations Protocols and Encodings.

Speech recording

This diagram shows the relationship between the modules needed for recording. Those shaded are optional. One of the rec... modules is always needed.

[pic]

|Speech input modules |

|Module |Purpose |

|inchan |Generic companded input. This is required for any form of processing on incoming data which is a speech or analogue signal. The only input |

| |which does not need it is digital data communications. If this module has not been downloaded, no recording, conferencing or detection will |

| |work. |

|Speech recording modules |

|Module |Purpose |

|gainbg |Volume control, automatic gain control, and addition of a background signal. These can all be used with sm_replay_start() or |

| |sm_replay_adjust(). |

| |This module is also used to implement the volume control and automatic gain control facilities used by sm_record_start(). |

|rec16b |Record 16-bit linear data. |

|rec8b |Record 8-bit linear data. |

|recms8b |Record 8-bit linear data with offset of 128 (Microsoft .WAV 8-bit). |

|recA |Record A-law companded data. |

|recablk |Record data encoded in ACUBLK format. |

|recima |Record data encoded in IMA format. |

|recmu |Record mu-law companded data. |

|recoki |Record data encoded in OKI format. |

|sixkin |Converter to allow recording at 6kHz instead of 8kHz. This is used in conjunction with a recording format to reduce the size of the recorded|

| |data by 25%. |

|timerx |Timer to provide a limit on recording duration. |

Note: all speech recording modules require inchan as well.

Speech playing

This diagram shows the relationship between the modules needed for playing. Those shaded are optional (and you would never have both fast and slow in use at the same time). One of the play... modules is always needed.

[pic]

|Speech output modules |

|Module |Purpose |

|outchan |Generic companded output. This is required to produce nearly any form of speech or analogue output signal. The only outputs which do not need|

| |it are tone generation and digital data communications. If this module has not been downloaded, no replay or conferencing will work. |

|tonegen |Tone generation. This is used by sm_play_tone(), sm_play_cptone(), and sm_play_digits(). |

|Speech playing modules |

|Module |Purpose |

|fast |Replay at speeds over 100%. The speed is selected by sm_replay_start() or sm_replay_adjust(). If this module has not been downloaded, the |

| |replay will play at normal speed. |

|gainbg |Volume control, automatic gain control, and addition of a background signal. See gainbg listed under speech recording. |

|play16b |Play 16-bit linear data. |

|play8b |Play 8-bit linear data. |

|playms8b |Play 8-bit linear data with offset of 128 (Microsoft .WAV 8-bit). |

|playA |Play A-law companded data. |

|playablk |Play data encoded in ACUBLK format. |

|playima |Play data encoded in IMA format. |

|playmu |Play mu-law companded data. |

|playoki |Play data encoded in OKI format. |

|sixkout |Converter to allow playing of 6kHz signals at 8kHz. This is used in conjunction with a replay to play data which was recorded as a 6kHz |

| |variant of a format normally used at 8kHz. Such a variant is used to reduce the size of the recorded data by 25%. |

|slow |Replay at speeds below 100%. The speed is selected by sm_replay_start() or sm_replay_adjust(). If this module has not been downloaded, the |

| |replay will play at normal speed. |

Note: all speech playing modules require outchan as well.

Detection

|Detection modules |

|Module |Purpose |

|grunt |Grunt detection and silence elimination. Used by sm_record_start() for silence elimination in recordings and by sm_listen_for(). If this |

| |module has not been downloaded, no grunt will be detected and recordings will not have silences removed. |

|td |Tone detection. Used by sm_listen_for() for tone detection and by sm_record_start() for tone suppression in recordings. If this module has |

| |not been downloaded, no tones will be detected and tones will remain in recordings. |

Conferencing

|Conferencing modules |

|Module |Purpose |

|conf |Conferencing. This is required if you want to start a conference (which is done using sm_conf_prim_start()). If this module has not been |

| |downloaded, any attempt to start a conference will produce an error. |

Echo cancellation

|Echo cancellation modules |

|Module |Purpose |

|echocan |Echo cancellation. If this module has not been downloaded, an attempt to use echo cancellation will use an unmodified signal. |

|passthru |A module which permits an incoming signal to be directed to an output. This is used by echo cancellation to output the processed signal. It |

| |is not needed if the processed signal is only being recorded. |

Signal categorization

|Signal categorization modules |

|Module |Purpose |

|ansdet |Answering machine detection. Used by sm_catsig_listen_for() to distinguish between a live speaker and an answering machine. |

Test and debug

|Test and debug modules |

|Module |Purpose |

|sync |Synchronizer. Allows the start of certain operations to be synchronized. This is used for testing where it is useful to record several |

| |signals with a known relationship. The implementation of this facility relies on some features which are liable to change between versions. |

|cpumon |Cpu usage monitor. |

Using the above information to group modules into categories plus knowing what modules are needed from the calculator or the tables above, the script structure for the “LoadSharc.sh” shell script can be formulated as shown on the next pages.

LoadModule (./lm) portion of the LoadSharc.sh Shell Script for the first Sharc:

############ Board 1 ###############

T1board="-c Prosody_156799 -m 0"

echo "Load Modules T1 Board Sharc 0 $T1board"

(This column not in Shell Script – Info Only)

# play Category from Prosody Software Module Sheet

./lm outchan $T1board Speech Output Module

./lm gainbg $T1board Speech Playing Module

./lm playA $T1board “ “

./lm playmu $T1board “ “

./lm playoki $T1board “ “

./lm playablk $T1board “ “

./lm fast $T1board “ “

./lm slow $T1board “ “

./lm sixkout $T1board “ “

# record

./lm inchan $T1board Speech Input Module

./lm recA $T1board Speech Recording Module

./lm recmu $T1board “ “

./lm recoki $T1board “ “

./lm recablk $T1board “ “

./lm sixkin $T1board “ “

./lm timerx $T1board “ “

# detections

./lm td $T1board Detection Module

./lm grunt $T1board “ “

# generation

./lm tonegen $T1board Speech Output Module

./lm ansdet $T1board Signal Categorization Module

# fax services

./lm fskrx $T1board Data Communications Module

./lm fsktx $T1board “ “

./lm v27tx $T1board “ “

./lm v27rx $T1board “ “

./lm v29tx $T1board “ “

./lm v29rx $T1board “ “

./lm v17tx $T1board “ “

./lm fskpll $T1board “ “

./lm hdlctx $T1board “ “

./lm hdlcrx $T1board “ “

./lm synctx $T1board “ “

./lm syncrx $T1board “ “

./lm six2five $T1board “ “

./lm datatx $T1board “ “

./lm datarx $T1board “ “

# continuous word speech recognition

#./lm echocan $T1board Echo Cancellation Module

#./lm passthru $T1board “ “

# conferencing

#./lm conf $T1board Conferencing Module

Once all of the correct modules are loaded for the desired features, the application can perform as desired. The modules are used in conjunction with the function calls and event handlers that the C/C++ programmer sets up in the code. This aspect is beyond the scope of this paper.

III. Integration of Fax in the Matrix2 Platform

There are many Matrix2 commands that perform a variety of functions in a Plan (or application). Looking at some of the Command Groups, we can see that there are pre-existing commands that perform the functions required for Unified Messaging but are not labeled as such (yet). A sampling of these includes:

Command Group Command Function

General PLAYMSG Plays a voice file to caller in

an appropriate format

RECORDMSG Records caller’s message in

.wav file format

LINUXCMD Can be used for e-mail and

other Shell Scripts as needed

Program Flow IF Tests for conditions such as

Fax or Voice

SELECT Gives options for callers to

choose from; this can be via

DTMF or Speech Recognition

Telecom DIAL Allows the caller to dial out to

another telephone number

from the inbound call

GETDTMF Allows caller to enter digits via

the touchtone keypad or to

enter numbers or word strings

using Speech Recognition

Command Group Command Function

Text-to-Speech FILETOFILECONVERT Converts text such as e-

mail to an appropriate

voice file (.wav or other)

VARTOFILECONVERT Converts text in a User

Variable (e-mail, web

page text, etc.) to an

appropriate voice file

Fax FAXRECEIVE Receive fax files in tiff

format and assign a

filename

FAXSEND Send one or more fax

files in broadcast or

on-demand mode

There are numerous Matrix2 commands that make up a Plan (application), however the ones in the previous table are those that will be used in a Unified Messaging (UM) environment until formal UM commands are created. The LINUXCMD is versatile in that any shell script can be written in Linux command line format to accomplish a wide variety of functions such as sending e-mail and connecting to a web-site.

The next White Paper will be on the subject of Unified Messaging. In this paper, it has been shown that the pieces are in place. MCCT’s next step is to develop the formal UM commands with supporting documentation so that there is a more streamlined appearance for the person writing the Plan or Application. There will be a new Command Group with potential commands such as:

CHECKEMAIL – specifically search for unopened e-mails in an account;

CHECKFAX – check for new faxes;

CHECKVOICE – look for new voice mail messages;

CONVERT – Text-to-Speech commands with added features;

SENDEMAIL – this will include functions such as CC, Attach, etc.;

SENDFAX – reuse the existing FAXSEND command;

SENDVOICE – Initiate, forward or reply to a voice message.

Of course, these will be discussed and determined by the design team and the commands may appear differently than shown here; the purpose is to satisfy the requirements of Unified Messaging as used by the community - this includes web-interface.

V. Summary

The addition of Aculab Fax to the MCCT Matrix2 platform provides the missing piece for Unified Messaging on an IVR. All of the functionality exists and Plans are currently written that use all of the UM functions. MCCT can write custom Plans or Applications that will meet your detailed requirements. You can contact MCCT at 1-800-GO-4-MCCT (domestically), 603 524-2214 (internationally) or info@.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download