(Page 1 of 1 in this chapter)


Chapter 7

Using CT Access and the ADI Service


7.1 Introduction
7.2 Using the ADI Service
7.2.1 ADI Functions
7.2.2 Supported ADI Vocoders
7.3 Migration from AG to QX Boards
7.4 Determining DSP Resources
7.5 Other Suggestions for Using QX Boards
7.5.1 Using ctdaemon for Tracing
7.5.2 Automatically Repeated Call Attempts

7.1 Introduction

The QX 2000 board uses the ADI service component of CT Access to perform call control. Therefore, a call control program for a QX 2000 board is the same as a call control program for an AG board. See the discussion in this chapter for some differences when migrating from AG boards to QX boards. See the ADI Service Developer's Manual for details about the ADI service.

7.2 Using the ADI Service

QDIMGR is the service manager for the ADI service used with QX 2000 boards. You specify the service and service manager names when initializing CT Access, creating event queues, and opening services.

Figure 22. QDI Service Manager and the ADI Service

7.2.1 ADI Functions

The ADI Service Function Reference Manual is a detailed reference to all ADI service functions. The QX boards support all the ADI service functions except the following:

ADI Function

Description

adiAcceptIncomingAddress

Presents an incoming call without waiting for all digits.

adiGetEEPromData

Reads the on-board OEM data for the board.

adiGetTimeStamp

Converts an event timestamp to a count of the seconds elapsed since January 1, 1970.

adiModifyPlaySpeed

Sets the play speed.

adiSetBilling

Sets billing information relative to an incoming call.

adiSetExtendedArgs

Sets new arguments for the call control function that immediately follows it.

adiStartReceivingFSK*

Receives Frequency Shift Key (FSK) data.

adiStartSendingFSK*

Initiates sending FSK data.

adiStopReceivingFSK*

Stops receiving FSK data.

adiStopSendingFSK*

Stops sending FSK data.

*Not supported on QX 2000/80-4L only.

If an unsupported ADI function is called in a QX 2000-based application, the error CTAERR_FUNCTION_NOT_AVAIL is returned.

See Appendix B for details about ADI service parameters and the specific defaults and allowed values for QX 2000 boards.

7.2.2 Supported ADI Vocoders

The QX boards support the following ADI vocoders:

These vocoders are downloaded at board initialization.

Note: The QX board does not currently support the ADI_ENCODE_NMS_64 vocoder.

7.3 Migration from AG to QX Boards

When you want to use a program written for AG boards with QX boards, the following modifications must be done in your source code:

  1. Change the name of the device manager by replacing the string ADIMGR with QDIMGR in all your source code. This must be done when calling the functions ctaInitialize and ctaOpenServices.

    
    
  2. Depending on the specific QX board used, the string LPS0 must be replaced with LPS4 when using a loop start protocol (LPS4 is for QX 2000/80-4L boards; LPS0 is for QX 2000/100-4L).

    
    
  3. Change the name of the switching library by replacing the string AGSW with QXSW in your source code. This must be done when calling swiOpenSwitch.

    
    
  4. Load the country specific parameters file to avoid telephony issues due to different default settings for call control parameters (use the ctdaemon program or the CT Access function ctaLoadParameterFile).

7.4 Determining DSP Resources

The QX 2000 board has one DSP which executes functions for detection and generation of voice and telephony signals for the four ports. Most ADI function calls implicitly use the functions which run on the DSP.

The speed of the DSP is measured in millions of instructions per second (MIPS). The QX 2000/100-4L board has 100 MIPS available. The QX 2000/80-4L board has 80 MIPS available. Each function which is run on a DSP consumes MIPS. If the total MIPS consumption for all the requested functions on all the ports of the board exceed the total MIPS available, then an error event will occur.

The overhead for the DSP operating system is 4.4 MIPS. The following table shows the MIPS usage per port for the available functions:
Function

Reception

Emission

Automatic gain control

0.3

0.1

Echo cancellation

2.5

Tone detection

1.9

Tone generation

1

DTMF detection

1.4

DTMF generation

1.1

WAVE downsampling

2

WAVE upsampling

1.4

G.726 32 Kbit/s ADPCM

7.6

6.9

A-law/ mu-law to linear

0.4

0.4

Vox ADPCM

3.2

2.9

NMS 32 Kbit/s ADPCM

5.4

4.3

NMS 24 Kbit/s ADPCM

5.4

4.3

NMS 16 Kbit/s ADPCM

5.4

4.3

FSK generation

2.5

FSK detection

4.5

To determine the total number of MIPS required by your application:

  1. Determine the MIPS required by each function.

    
    
  2. Multiply the number of ports supported.

    
    
  3. Add the DSP operating system overhead.

For example, running Voice play and DTMF detection on each port requires 4.4 + 4 x ( 5.4 + 1.4 ) = 31.6 MIPS.

If an application requires functions which exceed the number of available MIPS for the QX 2000 board, reduce the number of ports available to the application.

7.5 Other Suggestions for Using QX Boards

To monitor the signaling bits in loop start protocol:

  1. Open a CT Access context on a QX port.

    
    
  2. Run the NOCC protocol with adiStartProtocol.

    
    
  3. Enable bits detection with adiStartSignalDetector.

    
    
  4. Exit the NOCC protocol with adiStopProtocol.

    
    
  5. Run the LPS protocol with adiStartProtocol.

Depending on the mask value passed on argument to adiStartSignalDetector, every change of the A bit or B bit status will be returned to the application.

To play and record in a non-connected state:

  1. Open a CT Access context on a QX port.

    
    
  2. Run the protocol with adiStartProtocol.

    
    
  3. Run adiStartPlaying or adiStartRecording.

You do not need to be in the call connected state to use media functions such as play and record.

7.5.1 Using ctdaemon for Tracing

You can use the CT Access utility program ctdaemon to display traces on a QX application. You only have to load ctdaemon with the configuration file located in the country directory (e.g., ctdaemon -f c:\nms\qx\ctry\usa\q4lpsusa.par).

For more details, refer to Appendix F.

7.5.2 Automatically Repeated Call Attempts

Your application must include, for certain countries, the control of calls internally generated by the equipment. Failing to implement this requirement will void the regulatory approval granted to NMS for this NMS equipment. See Appendix F for the requirements for each country.



(Page 1 of 1 in this chapter)


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