User's Manual
Table Of Contents
- Contents
- Figures
- Tables
- Revision History
- About This Publication
- 1. Product Description
- 2. Programming Models
- 3. Device Handling
- 4. Event Handling
- 5. Error Handling
- 6. Application Development Guidelines
- 7. Call Progress Analysis
- 7.1 Call Progress Analysis Overview
- 7.2 Call Progress and Call Analysis Terminology
- 7.3 Call Progress Analysis Components
- 7.4 Using Call Progress Analysis on DM3 Boards
- 7.5 Call Progress Analysis Tone Detection on DM3 Boards
- 7.6 Media Tone Detection on DM3 Boards
- 7.7 Default Call Progress Analysis Tone Definitions on DM3 Boards
- 7.8 Modifying Default Call Progress Analysis Tone Definitions on DM3 Boards
- 7.9 Call Progress Analysis Errors
- 7.10 Using Call Progress Analysis on Springware Boards
- 7.11 Call Progress Analysis Tone Detection on Springware Boards
- 7.12 Media Tone Detection on Springware Boards
- 7.13 Default Call Progress Analysis Tone Definitions on Springware Boards
- 7.14 Modifying Default Call Progress Analysis Tone Definitions on Springware Boards
- 7.15 SIT Frequency Detection (Springware Only)
- 7.15.1 Tri-Tone SIT Sequences
- 7.15.2 Setting Tri-Tone SIT Frequency Detection Parameters
- 7.15.3 Obtaining Tri-Tone SIT Frequency Information
- 7.15.4 Global Tone Detection Tone Memory Usage
- 7.15.5 Frequency Detection Errors
- 7.15.6 Setting Single Tone Frequency Detection Parameters
- 7.15.7 Obtaining Single Tone Frequency Information
- 7.16 Cadence Detection in Basic Call Progress Analysis (Springware Only)
- 8. Recording and Playback
- 8.1 Overview of Recording and Playback
- 8.2 Digital Recording and Playback
- 8.3 Play and Record Functions
- 8.4 Play and Record Convenience Functions
- 8.5 Voice Encoding Methods
- 8.6 G.726 Voice Coder
- 8.7 Transaction Record
- 8.8 Silence Compressed Record
- 8.9 Recording with the Voice Activity Detector
- 8.10 Streaming to Board
- 8.11 Pause and Resume Play
- 8.12 Echo Cancellation Resource
- 9. Speed and Volume Control
- 10. Send and Receive FSK Data
- 11. Caller ID
- 12. Cached Prompt Management
- 13. Global Tone Detection and Generation, and Cadenced Tone Generation
- 13.1 Global Tone Detection (GTD)
- 13.1.1 Overview of Global Tone Detection
- 13.1.2 Global Tone Detection on DM3 Boards versus Springware Boards
- 13.1.3 Defining Global Tone Detection Tones
- 13.1.4 Building Tone Templates
- 13.1.5 Working with Tone Templates
- 13.1.6 Retrieving Tone Events
- 13.1.7 Setting GTD Tones as Termination Conditions
- 13.1.8 Maximum Amount of Memory for Tone Templates
- 13.1.9 Estimating Memory
- 13.1.10 Guidelines for Creating User-Defined Tones
- 13.1.11 Global Tone Detection Application
- 13.2 Global Tone Generation (GTG)
- 13.3 Cadenced Tone Generation
- 13.3.1 Using Cadenced Tone Generation
- 13.3.2 How To Generate a Custom Cadenced Tone
- 13.3.3 How To Generate a Non-Cadenced Tone
- 13.3.4 TN_GENCAD Data Structure - Cadenced Tone Generation
- 13.3.5 How To Generate a Standard PBX Call Progress Signal
- 13.3.6 Predefined Set of Standard PBX Call Progress Signals
- 13.3.7 Important Considerations for Using Predefined Call Progress Signals
- 13.1 Global Tone Detection (GTD)
- 14. Global Dial Pulse Detection
- 14.1 Key Features
- 14.2 Global DPD Parameters
- 14.3 Enabling Global DPD
- 14.4 Global DPD Programming Considerations
- 14.5 Retrieving Digits from the Digit Buffer
- 14.6 Retrieving Digits as Events
- 14.7 Dial Pulse Detection Digit Type Reporting
- 14.8 Defines for Digit Type Reporting
- 14.9 Global DPD Programming Procedure
- 14.10 Global DPD Example Code
- 15. R2/MF Signaling
- 16. Syntellect License Automated Attendant
- 17. Building Applications
- Glossary
- Index
Voice API Programming Guide — June 2005 39
Application Development Guidelines
6.4.3 DM3 Media Loads
Different configurations for DM3 products are supported in the form of media loads. For instance,
a specific media load is available for users who need to implement continuous speech processing
(CSP) and conferencing in their applications. See the appropriate Configuration Guide for specific
media loads that are available.
6.4.4 Device Discovery for DM3 and Springware
Applications that use both Springware and DM3 devices must have a way of differentiating what
type of device is to be opened. The TDM bus routing functions such as dx_getctinfo( ) provide a
programming solution. DM3 hardware is identified by the CT_DFDM3 value in the ct_devfamily
field of the CT_DEVINFO structure. Only DM3 devices will have this field set to CT_DFDM3.
For more information on the dx_getctinfo( ) function and the CT_DEVINFO structure, see the
Voice API Library Reference.
Note: Use SRL device mapper functions to return information about the structure of the system. For
information on these functions, see the Standard Runtime Library API Library Reference.
The following procedure shows how to initialize an application and perform device discovery when
the application supports both DM3 and Springware boards.
1. Open the first voice channel device on the first voice board in the system with dx_open( ).
2. Call dx_getctinfo( ) and check the CT_DEVINFO.ct_devfamily value.
3. If ct_devfamily is CT_DFDM3, then flag all the voice channel devices associated with the
board as DM3 type.
4. Close the voice channel with dx_close( ).
5. Repeat steps 1 to 4 for each voice board.
For information on initializing the Global Call API on DM3 devices, see the Global Call API
Programming Guide.
6.4.5 Device Initialization Hint
The xx_open( ) functions for the voice (dx), Global Call (gc), network (dt), and fax (fx) APIs are
asynchronous on DM3 boards, unlike the standard Springware versions, which are synchronous.
This should usually have no impact on an application, except in cases where a subsequent function
calls on a device that is still initializing, that is, is in the process of opening. In such cases, the
initialization must be finished before the follow-up function can work. The function won’t return
an error, but it is blocked until the device is initialized.
For instance, if your application calls dx_open( ) followed by dx_getfeaturelist( ), the
dx_getfeaturelist( ) function is blocked until the initialization of the device is completed
internally, even though dx_open( ) has already returned success. In other words, the initialization
(dx_open( )) may appear to be complete, but, in truth, it is still going on in parallel.