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
130 Voice API Programming Guide — June 2005
Send and Receive FSK Data
10.8.3 Technical Overview of Two-Way ADSI Data Transfer
In two-way ADSI data transfer, both the ADSI server and CPE device can transmit and receive
ADSI data messages. The CAS is used to initiate the transfer of ADSI FSK data and to return the
CPE to voice mode after the data exchange is completed.
The transactions that occur between the server and the CPE in two-way ADSI data transfer are as
follows:
1. The server initiates the data transfer by sending a CPE Alerting Signal (CAS) to the CPE
equipment.
2. Upon receipt of the CAS, the CPE device generates an ACK (DTMF ‘A’ signal) to the server.
At this point the CPE device has switched from voice mode to data mode. (Once the CPE
device is in data mode, subsequent FSK data transmissions do not require the CAS.)
Note: Only ADSI-compliant CPE devices will respond to the CAS sent by the server. Check
with your manufacturer to verify that your CPE device is a true ADSI-compliant
device. ADSI-compliant devices are also referred to as "Type 3 CPE Devices" by
Telcordia Technologies.
3. When the ACK signal is received, the server initiates the FSK transmission sequence. Each
FSK transmission sequence can contain anywhere from 1 to 5 messages. A "Switch to
Peripheral Mode" message (using 0x0A as a ‘requested peripheral’ code) must be included
within the FSK transmission sequence.
4. The CPE receives the FSK data and uses the checksum included within the sequence to
determine the number of messages successfully received.
5. The CPE device then responds to the server with a DTMF ‘D’ followed by a DTMF ‘0’
through ‘5’ to indicate the number of messages successfully received. In addition, the CPE
device acknowledges the "Switch to Peripheral Mode" message by responding with either
• DTMF ‘B,’ indicating that the requested peripheral is available and on line
• DTMF ‘A,’ indicating that the requested peripheral is not available
6. The server interprets the DTMF signals as follows:
• ‘D’ followed by a DTMF in the range of 1 – 5 = ACK
• ‘D’ followed by a DTMF ‘0’ = NAK
• DTMF ‘B’ = requested peripheral available (ready to receive and transmit ADSI data)
• DTMF ‘A’ = requested peripheral unavailable (unable to transmit or receive ADSI data)
Once the CPE device has acknowledged the "Switch to Peripheral Mode" message, the CPE may
transmit data to the server at any time. The server must be prepared to receive data at any time until
the CPE peripheral is switched back to voice mode. To return the CPE peripheral to voice mode,
the server sends a CAS to the CPE. Upon receipt of the CAS, the CPE responds with a DTMF ‘A’
signal. Receipt of DTMF ‘A’ at the server completes the return to voice mode transition.