(Page 1 of 1 in this chapter) Version


Chapter 9

Demonstration Programs


9.1 Introduction
9.1.1 About ctademo.c
9.2 Host Port to Port Connection Program: hostp2p
9.3 Play and Record: playrec
9.4 Multi-Threaded Application: threads
9.5 Call Transfer: xferpbx

9.1 Introduction

This chapter presents the demonstration programs shipped with the ADI service.

CT Access is shipped with source code for all demonstration programs. Each demonstration program is shipped as an executable program and with its source and makefiles.

Note: The demonstration programs incta and outcta demonstrate placing inbound and outbound calls. Refer to the CT Access Developer's Reference Manual for more information about these demonstration programs.

The following demonstration programs are provided with CT Access and the ADI service:
Program

Description

hostp2p

Demonstrates a live voice connection between two ports using play and record functions.

playrec

Plays a WAVE (i.e., .wav) sound file.

threads

A simple, multi-threaded answering machine demonstration.

xferpbx

Demonstrates transfer of a call to another extension on a PBX, Centrex, or Centrex-like switch.

Before you start the demonstration programs, ensure that:

Refer to the appropriate installation manual for details on installation.

9.1.1 About ctademo.c

All of the demonstration programs use a common set of high-level functions contained in ctademo.c and ctademo.h. This demonstration code provides functions for initializing CT Access, opening and closing ports, waiting for calls, placing calls, answering calls, performing record and playback operations, and collecting digits. You can use these functions as base code for developing your applications with CT Access. Note that this library of functions is for demonstration only, and is subject to change without notice.

9.2 Host Port to Port Connection Program: hostp2p

Name

hostp2p

Purpose

Demonstrates live voice connection between two ports using play and record functions.

Usage

hostp2p options

where options are:

Option

Description

-b n

AG board number. Default = 0

-B n

Second AG board number (if different).

-s [n:]m

First port DSP address. Default = 0:0

For AG-24/30/48/60 boards, specify the MVIP stream and slot. For all other boards, you need to specify only the slot.

-S [n:]m

Second port DSP address. Default = 0:1

For AG-24/30/48/60 boards, specify the MVIP stream and timeslot. For all other boards, you need to specify only the timeslot.

-p protocol

Protocol to run. Default = LPS0

-P protocol

Second port's protocol (if different).

-e n

Encoding type. Refer to adidef.h. Default = 10

-f n

Buffer size (msec). Default = 60

-d digits

Digits to dial on port 2 (if not NOCC).

-E len:tim

Echo cancellation length:adaptime. Default = 4:100

Description

hostp2p uses simultaneous play and record of small buffers to simulate a real-time voice connection between two voice calls. It uses the asynchronous play and record functions of the ADI service.

Procedure

This procedure assumes that you are testing on an AG-8 board with loop-start line interfaces connected to phone lines. hostp2p requires rvoice.dsp and echo.dsp.

Ensure that the ag.cfg file has ENABLEMVIP=NO for the board that you are using. This ensures that the default DSP-to-line interface connections are set up by agmon.

To run hostp2p:

  1. Start hostp2p by entering the following at the prompt:

    
    hostp2p -p lps0  -d phone_number
    hostp2p starts and the following information is displayed:
    CTA host port to port voice Demo V 1.0 (Dec 8 1997)
    Port #1: Board 0 Stream 0 Slot 0 Protocol = lps0
    Port #2: Board 0 Stream 0 Slot 1 Protocol = lps0
    Encoding = 10
    Buffer time = 60 msec
    Echocanceling length = 4 msec, adapt time= 100 msec

    Initializing and opening the CTA context...
    Daemon not running. Using process global default parms.
    Trace disabled.
    --------
    Waiting for incoming call...
    hostp2p waits for an incoming call.
  2. Place a call to the telephone line connected to port 0.

    
    The following information is displayed:
    Incoming Call...
    Answering call...
    Call connected.
    -------
    Placing a call to '5551212'...
    hostp2p places a call to the number you specified. When the called party answers, you will have a connection.

9.3 Play and Record: playrec

Name

playrec

Purpose

Demonstrates voice play and record using asynchronous buffer submission and play and record callback routines.

Usage

playrec [options]

where options are:
Option

Description

-?

Displays command line options.

-h

Displays command line options.

-b n

Specifies the AG board n. Default is 0.

-s n:m

Specifies MVIP stream and timeslot. Default is 0:0.

-r

Specifies the maximum recording duration (in seconds).

-z

Specifies the application buffer size. Must be a multiple of NMS_24 frame size (62).

Featured Functions

adiPlayAsync, adiSubmitPlayBuffer, adiStartPlaying, adiRecordAsync, adiSubmitRecordBuffer, adiStartRecording, adiGetEncodingInfo

Description

This demonstration operates in two phases-asynchronous voice play and record operations and callback voice play and record operations.

If you do not specify a buffer size on the command line (-z), playrec retrieves the AG physical buffer using adiGetEncodingInfo.

The demonstration is constructed so that the play and record functions are synchronous within the application. This is a single-port, single-threaded demonstration.

adiStartPlaying and adiStartRecording (and consequently, this demonstration program) are not supported while CT Access is running in Client/Server mode.

Procedure

The following procedure assumes that you are using an AG-8 DID board with a 2500-type telephone connected to one of the lines.

To run playrec:

  1. Change to the \nms\ctaccess\demos\playrec directory.

    
    
  2. Start playrec by entering the following at the prompt:

    
    playrec [-b n -s n:m -r -z ]
    Make sure that you specify the proper AG board and timeslot. The default value for both arguments is 0.
    You will be prompted to record a brief message. The prompt is played using asynchronous buffer submission and you will see ADIEVN_PLAY_BUFFER_REQ displayed on your screen (assuming you haven't specified an application buffer large enough to fit the whole prompt file).
    You can terminate the prompt prematurely by entering a touchtone.
  3. At the record beep prompt, begin speaking.

    
    You should see ADIEVN_RECORD_BUFFER_FULL displayed on your screen each buffer_size time period. 
  4. You can terminate the recording prematurely by entering a touchtone, or by ceasing to speak.

    
    The recording you just made is played back. Again, the message ADIEVN_PLAY_BUFFER_REQ is displayed on your screen.
  5. Repeat steps 2 and 3. The sequence of the above procedure is repeated using callback mode. Since CT Access automatically invokes the callback routine, the displayed event messages are replaced with the corresponding callback events.

Note

This demonstration allows you to experiment with buffer sizes. The encoding format for the files is ADI_ENCODE_NMS_24, which has a 62-byte frame size. Buffer sizes you specify with the -z option must therefore be multiples of 62.

9.4 Multi-Threaded Application: threads

Name

threads

Purpose

Demonstrates handling multiple ports using one thread per port.

Usage

threads [options]

where options are:
Option

Description

-b n

Specifies the AG board number n. Default is 0.

-s n:m

Specifies the MVIP stream and timeslot for the first channel. Default is 0:0.

-n nports

The number of ports (and threads) to use. Default is 1.

-p protocol

Specifies the protocol to run. Default is lps0.

-f filename

Voice file to use for answering message. Default is answer.vce. (Encoding is assumed to be ADI_ENCODE_NMS_24.)

Featured Functions

adiAnswerCall (in DemoWaitForCall), adiReleaseCall (in DemoHangUp), adiStartPlaying (in DemoPlayFile)

Description

This demonstration application is a multi-threaded answering machine using ctademo. Each thread opens a port and repeatedly waits for calls on the port. Each time a call is received, it answers, plays the answering message, and hangs up.

adiStartPlaying (and consequently, this demonstration program) is not supported while CT Access is running in Server mode.

Procedure

Before you run this application, make sure that your system has the proper configuration, with the desired number of lines connected to loop-start hybrids having the same MVIP stream and successive MVIP timeslots.

Note

Much of the code in threads parses and documents the command-line arguments and creates threads under various operating systems. All of the call handling is performed by RunDemo.

9.5 Call Transfer: xferpbx

Name

xferpbx

Purpose

Demonstrates rerouting an incoming call.

Usage

xferpbx [options]

where options are:
Option

Description

-b n

Specifies the AG board number n. Default is 0.

-s n:m

Specifies the MVIP stream and timeslot for the first channel. Default is 0:0.

-p protocol

Specifies the protocol to run. Default is lps0.

-m n

Specifies the method of transfer. Default is 1.

1 = on PROCEEDING (after dial)

2 = on ALERTING (ringing)

3 = on CONNECTED (first voice or signal)

4 = manual (call screening)

Featured Functions

adiPlaceSecondCall, adiReleaseSecondCall

Description

Party A calls party B (which is the demonstration program) and requests a transfer to party C. xferpbx (party B) then calls party C. It reports success or failure at one of several stages, depending on the selected transfer method. (With method 4, it asks party C whether it should complete the transfer, or report failure.)

Procedure

Begin with three telephone lines: two (A and C) with two 1500-type telephone sets, and one (B) connected to the AG board. Lines B and C must be connected to a common PBX.

To run xferpbx:

  1. Make sure that you specify the proper AG board and MVIP stream, and start agmon.

    
    
  2. Start xferpbx by entering the following at the prompt:

    
    xferpbx [ -b n -s n:m -p protocol -m n ]
    Make sure you specify one of the transfer methods.
  3. From line A, call line B.

    
    The demonstration should answer. 
  4. When it requests an extension to try, dial the extension of line C.

    
    The demonstration calls line C.
  5. Answer line C.

    
    In transfer mode 4, the demonstration offers you a chance to refuse the call. The other transfer modes report success or failure at earlier stages, sometimes before the transfer is actually completed.



(Page 1 of 1 in this chapter) Version


tech_support@nmss.com
Copyright © 1999, Natural MicroSystems, Inc. All rights reserved.