(Page 1 of 1 in this chapter) Version

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.2.3 Using the Local Phone and Audio Interfaces
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 mainly to perform media functions. Therefore, a media program performing voice play and record is the same as a media program for an AG board. See Section 7.3 for some differences when migrating from AG boards to QX boards. Refer to the ADI Service Developer's Manual for details about the ADI service.

Note: Call control features are now managed by the Natural Call Control service. Refer to the Natural Call Control Service Developer's Reference Manual for more information about the NCC 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.2.3	 Using the Local Phone and Audio Interfaces





The local phone or audio interface can be used either for monitoring or as external audio source for messages recording or playing. To address these I/O ports, switching functions must be used.



For more information, refer to the QX 2000/100-4L MVIP-95 switch model shown in Figure 18.



For an example of the functionality of these interfaces, perform the following:



Run ctatest (with the -A QDIMGR option) and select the commands OP and SP to open a CT Access context and run the NOCC protocol.  In another session, run the utility program swish.exe and enter the following commands: 





 To:



 Enter the command:




 Open a switching context



 SWISH: openswitch qx=qxsw 0




 Record a message from the local phone



 SWISH: makeconnection qx local:8:0 to local:5:0




 Listen to a message on the local phone



 SWISH: makeconnection qx local:4:0 to local:9:0




 Record a message from the microphone



 SWISH: makeconnection qx local:12:0 to local:5:0




 Listen to a message on the headphone



 SWISH: makeconnection qx local:4:0 to local:13:0




 Close the context and exit



 SWISH: closeswitch qx


 SWISH: exit















 







WARNING:







When modifying switching connections for recording, do not forget to re-establish the default connection settings.





















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)  Version




 




tech_support@nmss.com



Copyright © 1999, Natural MicroSystems, Inc.   All rights
reserved.