Voice API Programming Guide June 2005 05-2377-002
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT.
Contents Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 About This Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents 6.1 6.2 6.3 6.4 6.5 7 Call Progress Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 4 General Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.1 Busy and Idle States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.
Contents 7.10 7.11 7.12 7.13 7.14 7.15 7.16 8 Using Call Progress Analysis on Springware Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.1 Overview of Steps to Initiate Call Progress Analysis . . . . . . . . . . . . . . . . . . . . . . 7.10.2 Setting Up Call Progress Analysis Features in DX_CAP . . . . . . . . . . . . . . . . . . . 7.10.3 Enabling Call Progress Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.4 Executing a Dial Function . .
Contents 8.10 8.11 8.12 9 Speed and Volume Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 9.1 9.2 9.3 9.4 9.5 9.6 9.7 10 10.6 10.7 10.8 10.9 Overview of ADSI and Two-Way FSK Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 ADSI Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 ADSI Operation. . . . . . . . . . . . . . . . . .
Contents 11.4 11.5 11.6 12 Cached Prompt Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 12.1 12.2 12.3 13 Overview of Cached Prompt Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Cached Prompt Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.1 Discovering Cached Prompt Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.
Contents 15 R2/MF Signaling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 15.1 15.2 15.3 15.4 15.5 15.6 15.7 16 Syntellect License Automated Attendant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 16.1 16.2 16.3 17 R2/MF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Direct Dialing-In Service . . . . . . . . .
Contents Figures 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Cluster Configurations for Fixed and Flexible Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Basic Call Progress Analysis Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 PerfectCall Call Progress Analysis Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Call Outcomes for Call Progress Analysis (DM3) . . . . . . . .
Contents Tables 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 10 Voice Device Inputs for Event Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Voice Device Returns from Event Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 API Function Restrictions in a Fixed Routing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Call Progress Analysis Support with dx_dial( ) . . . . . . . . . . . . .
Revision History This revision history summarizes the changes made in each published version of this document. Document No. Publication Date Description of Revisions 05-2377-002 June 2005 Application Development Guidelines chapter : Added bullet about digits not always being cleared by dx_clrdigbuf( ) in Tone Detection Considerations section [PTR 33806]. Call Progress Analysis chapter : Added eight new SIT sequences that can be returned by ATDX_CRTNID( ) for DM3 boards in Types of Tones section.
Revision History 12 Voice API Programming Guide — June 2005
About This Publication The following topics provide information about this publication: • Purpose • Applicability • Intended Audience • How to Use This Publication • Related Information Purpose This publication provides guidelines for building computer telephony applications on Windows* and Linux* operating systems using the Intel® voice API. Such applications include, but are not limited to, call routing, voice messaging, interactive voice response, and call center applications.
About This Publication • Independent Software Vendors (ISVs) • Value Added Resellers (VARs) • Original Equipment Manufacturers (OEMs) How to Use This Publication This document assumes that you are familiar with and have prior experience with Windows or Linux operating systems and the C programming language. Use this document together with the following: the Voice API Library Reference, the Standard Runtime Library API Programming Guide, and the Standard Runtime Library API Library Reference.
About This Publication • Chapter 15, “R2/MF Signaling” describes the R2/MF signaling protocol, the API functions for use with this feature, and programming guidelines. • Chapter 16, “Syntellect License Automated Attendant” describes Intel hardware and software that include a license for the Syntellect Technology Corporation (STC) patent portfolio. • Chapter 17, “Building Applications” discusses compiling and linking requirements such as include files and library files.
About This Publication 16 Voice API Programming Guide — June 2005
Product Description 1. 1 This chapter provides information on key voice library features and capability. The following topics are covered: • Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 • R4 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 • Call Progress Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Product Description In addition to original Springware products (also known as earlier-generation products), the R4 API supports a new generation of hardware products that are based on the DM3 mediastream architecture. Feature differences between these two categories of products are noted. DM3 boards is a collective name used in this document to refer to products that are based on the DM3 mediastream architecture. DM3 board names typically are prefaced with “DM,” such as the Intel NetStructure® DM/V2400A.
Product Description See Chapter 13, “Global Tone Detection and Generation, and Cadenced Tone Generation” for detailed information about global tone detection. 1.4.2 Global Tone Generation (GTG) Global tone generation allows you to define a single- or dual-frequency tone in a tone generation template and to play the tone on a specified channel. See Chapter 13, “Global Tone Detection and Generation, and Cadenced Tone Generation” for detailed information about global tone generation. 1.4.
Product Description 1.6.1 Play and Record Functions The voice library includes several functions and data structures for recording and playing audio data. These allow you to digitize and store human voice; then retrieve, convert, and play this digital information. In addition, you can pause a play currently in progress and resume that same play. For more information about play and record features, see Chapter 8, “Recording and Playback”.
Product Description 1.6.6 Echo Cancellation Resource The echo cancellation resource (ECR) feature enables a voice channel to dynamically perform echo cancellation on any external TDM bus time slot signal. Note: The ECR feature has been replaced with continuous speech processing (CSP). Although the CSP API is related to the voice API, it is provided as a separate product. The continuous speech processing software is a significant enhancement to ECR.
Product Description 1.10 TDM Bus Routing A time division multiplexing (TDM) bus is a technique for transmitting a number of separate digitized signals simultaneously over a communication medium. TDM bus includes the CT Bus and SCbus. The CT Bus is an implementation of the computer telephony bus standard developed by the Enterprise Computer Telephony Forum (ECTF) and accepted industry-wide. The H.100 hardware specification covers CT Bus implementation using the PCI form factor. The H.
Programming Models 2. 2 This chapter briefly discusses the Standard Runtime Library and supported programming models: • Standard Runtime Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 • Asynchronous Programming Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 • Synchronous Programming Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.
Programming Models Synchronous programming models allow you to scale an application by simply instantiating more threads or processes (one per channel). This programming model may be easy to encode and manage but it relies on the system to manage scalability. Applying the synchronous programming model can consume large amounts of system overhead, which reduces the achievable densities and negatively impacts timely servicing of both hardware and software interrupts.
Device Handling 3. 3 This chapter describes the concept of a voice device and how voice devices are named and used. • Device Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 • Voice Device Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.
Device Handling For example, a D/240JCT-T1 board employs 24 voice channels; the software therefore divides the D/240JCT into six voice board devices, each device consisting of four channels. Examples of board device names for voice boards are dxxxB1 and dxxxB2. A device name can be appended with a channel or component identifier. A voice channel device is named dxxxBnCy, where y corresponds to one of the voice channels. Examples of channel device names for voice boards are dxxxB1C1 and dxxxB1C2.
Event Handling 4. 4 This chapter provides information on functions used to retrieve and handle events. Topics include: • Overview of Event Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 • Event Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1 Overview of Event Handling An event indicates that a specific activity has occurred on a channel.
Event Handling Each of the event management functions applicable to the voice boards are listed in the following tables. Table 1 lists values that are required by event management functions. Table 2 list values that are returned for event management functions that are used with voice devices. Table 1.
Error Handling 5. 5 This chapter discusses how to handle errors that can occur when running an application. All voice library functions return a value to indicate success or failure of the function. A return value of zero or a non-negative number indicates success. A return value of -1 indicates failure. If a voice library function fails, call the standard attribute functions ATDV_LASTERR( ) and ATDV_ERRMSGP( ) to determine the reason for failure.
Error Handling 30 Voice API Programming Guide — June 2005
Application Development Guidelines 6. 6 This chapter provides programming guidelines and techniques for developing an application using the voice library. The following topics are discussed: • General Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 • Fixed and Flexible Routing Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 • Fixed Routing Configuration Restrictions. . . . . . . . . . . . . . . . . . .
Application Development Guidelines 6.1.2 Setting Termination Conditions for I/O Functions When an I/O function is issued, you must pass a set of termination conditions as one of the function parameters. Termination conditions are events monitored during the I/O process that will cause an I/O function to terminate. When the termination condition is met, a termination reason is returned by ATDX_TERMMSK( ).
Application Development Guidelines specified in the tp_flags field of the DV_TPT. When this termination condition is met, a TM_LCOFF termination reason is returned from ATDX_TERMMSK( ). maximum delay between digits (DX_IDDTIME) This termination condition monitors the length of time between the digits being received. A specific length of time can be placed in the tp_length field of a DV_TPT. If the time between receiving digits is more than this period of time, the function terminates.
Application Development Guidelines specific digit received (DX_DIGMASK) Digits received during an I/O function are collected in a channel's digit buffer. If the buffer is not empty before an I/O function executes, the digits in the buffer are treated as being received during the I/O execution. This termination condition is enabled by specifying a digit bit mask in the tp_length field of a DV_TPT structure. If any digit specified in the bit mask appears in the digit buffer, the I/O function will terminate.
Application Development Guidelines To specify an additional timeout if subsequent digits are not received, use the DX_IDDTIME (interdigit delay) termination condition and the TF_FIRST flag in the DV_TPT structure. The TF_FIRST flag specifies that the timer will start after the first digit is received; otherwise the timer starts when the dx_getdig( ) function is called. 6.1.4 Clearing Structures Before Use Two library functions are provided to clear structures.
Application Development Guidelines devices is predefined and static. The resource device also does not have access to the TDM bus and so cannot be routed independently on the TDM bus. No off-board sharing or exporting of voice/fax resources is allowed. flexible routing configuration This configuration is compatible with R4 API routing on Springware boards; that is, Springware boards use flexible routing. Flexible routing is available for DM3 boards starting in System Release 5.01.
Application Development Guidelines 6.3 Fixed Routing Configuration Restrictions Flexible routing configuration is the configuration of choice for applications using R4 on DM3. This documentation assumes that the flexible routing configuration is in use unless otherwise stated.
Application Development Guidelines • Device Initialization Hint • TDM Bus Time Slot Considerations • Tone Detection Considerations 6.4.1 Call Control Through Global Call API Library Call state functions such as dx_wink( ) and board-level parameters such as DXBD_R_ON and DXBD_R_OFF which are used in digital connections do not apply in DM3 applications.
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.
Application Development Guidelines With some applications, this may cause slow device-initialization performance. You can avoid this problem in one of several ways, depending on the type of application: • In multithreaded applications, you can reorganize the way the application opens and then configures devices. The recommendation is to do as many xx_open( ) functions as possible (grouping the devices) in one thread arranging them in a loop before proceeding with the next function.
Application Development Guidelines http://resource.intel.com/telecom/support/tnotes/gentnote/dl_soft/tn253.htm. For CSP, see http://resource.intel.com/telecom/support/tnotes/gentnote/dl_soft/tn254.htm. 6.4.7 Tone Detection Considerations The following consideration applies to tone detection on DM3 boards: • Digits will not always be cleared by the time the dx_clrdigbuf( ) function returns, because processing may continue on the board even after the function returns.
Application Development Guidelines duration = the value entered x 10 msec The syntax of the function is: int duration; duration = 15; dx_setparm(dev,DXCH_WINKLEN,(void*)&duration) If duration = 15, then DXCH_WINKLEN = 15 x 10 or 150 msec. 6.5.3 Receiving an Inbound Wink The information in this section does not apply to DM3 boards. Note: The inbound wink duration must be between the values set for DXCH_MINRWINK and DXCH_MAXRWINK.
Call Progress Analysis 7. 7 This chapter provides detailed information about the call progress analysis feature. The following topics are discussed: • Call Progress Analysis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 • Call Progress and Call Analysis Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 • Call Progress Analysis Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call Progress Analysis There are two forms of call progress analysis: PerfectCall call progress analysis Also called enhanced call progress analysis. Uses an improved method of signal identification and can detect fax machines and answering machines. You should design all new applications using PerfectCall call progress analysis. DM3 boards support PerfectCall call progress analysis only.
Call Progress Analysis • positive answering machine detection (post-connect part of call progress analysis) • fax tone detection (post-connect part of call progress analysis) Figure 2 illustrates the components of basic call progress analysis. Figure 3 illustrates the components of PerfectCall call progress analysis. These components can all operate simultaneously. In basic call progress analysis, cadence detection is the sole means of detecting a no ringback, busy, or no answer.
Call Progress Analysis Figure 3. PerfectCall Call Progress Analysis Components Incoming Signal Frequency Detection Intercept (SIT) 7.
Call Progress Analysis Table 4 provides information on call progress analysis scenarios supported with the dx_dial( ) function. This method is available regardless of the protocol being used; however, some restrictions apply when using DM3 CAS protocols. The restrictions are due to the fact that the voice capability is shared between the network device and the voice channel during the call setup time.
Call Progress Analysis 7.4.3 Setting Up Call Progress Analysis Parameters in DX_CAP The call progress analysis parameters structure, DX_CAP, is used by dx_dial( ). It contains parameters to control the operation of call progress analysis features, such as positive voice detection (PVD) and positive answering machine detection (PAMD). To customize the parameters for your environment, you must set up the DX_CAP structure before calling a dial function.
Call Progress Analysis Notes: 1. On DM3 boards, dx_dial( ) cannot be used to start an outbound call; instead use the Global Call API. 2. To issue dx_dial( ) without dialing digits, specify “ ” in the dialstrp argument. 7.4.5 Determining the Outcome of a Call In asynchronous mode, once dx_dial( ) with call progress analysis has terminated, use the extended attribute function ATDX_CPTERM( ) to determine the outcome of the call. (In synchronous mode, dx_dial( ) returns the outcome of the call.
Call Progress Analysis Figure 4. Call Outcomes for Call Progress Analysis (DM3) Incoming Signal Intercept (SIT) Faxtone CR_CEPT CR_FAXTONE Positive Voice or Answering Machine Detection Cadence Detection Frequency Detection Busy No Answer CR_BUSY CR_NOANS Connect Reason No Ringback Connect CR_NORB CR_CNCT Termi- nation Reason CON_CAD CON_PVD CON_PAMD Termination Reason: From ATDX_CPTERM( ). Connect Reason: From ATDX_CONNTYPE( ). 7.4.
Call Progress Analysis 7.5 Call Progress Analysis Tone Detection on DM3 Boards The following topics discuss tone detection used in call progress analysis on DM3 boards: • Tone Detection Overview • Types of Tones • Ringback Detection • Busy Tone Detection • Fax or Modem Tone Detection • SIT Frequency Detection 7.5.1 Tone Detection Overview Call progress analysis uses a combination of cadence detection and frequency detection to identify certain signals during the course of an outgoing call.
Call Progress Analysis TID_RNGBK2 Ringback (detected as dual tone) TID_SIT_ANY Catch all (returned for a Special Information Tone sequence or SIT sequence that falls outside the range of known default SIT sequences) TID_SIT_INEFFECTIVE_OTHER or TID_SIT_IO Ineffective other SIT sequence TID_SIT_NO_CIRCUIT or TID_SIT_NC No circuit found SIT sequence TID_SIT_NO_CIRCUIT_INTERLATA or TID_SIT_NC_INTERLATA InterLATA no circuit found SIT sequence TID_SIT_OPERATOR_INTERCEPT or TID_SIT_IC Operator intercept SIT sequ
Call Progress Analysis To enable ringback detection, turn on SIT frequency detection in the DX_CAP ca_intflg field. For details, see Section 7.4.3, “Setting Up Call Progress Analysis Parameters in DX_CAP”, on page 48. The following DX_CAP fields govern ringback behavior on DM3 boards: ca_cnosig Continuous No Signal: the maximum length of silence (no signal) allowed immediately after the ca_stdely period (in 10 msec units).
Call Progress Analysis Table 5 shows default tone definitions for SIT sequences used on DM3 boards. The values in the “Freq.” column represent minimum and maximum values in Hz. “Time” refers to minimum and maximum on time in 10 msec units; the maximum off time between each segment is 5 (or 50 msec). The repeat count is 1 for all SIT segments. N/A means “not applicable.” Table 5. Special Information Tone Sequences (DM3) SIT Tone ID 1st Segment 2nd Segment Time Freq.
Call Progress Analysis 7.6 Media Tone Detection on DM3 Boards Media tone detection in call progress analysis is discussed in the following topics: • Positive Voice Detection (PVD) • Positive Answering Machine Detection (PAMD) 7.6.1 Positive Voice Detection (PVD) Positive voice detection (PVD) can detect when a call has been answered by determining whether an audio signal is present that has the characteristics of a live or recorded human voice.
Call Progress Analysis detects live voice as accurately as PAMD_FULL but is more accurate than PAMD_FULL (although slightly slower) in detecting an answering machine. Use the setting PAMD_ACCU when accuracy is more important than speed. Default value (DM3 boards): PAMD_ACCU The recommended setting for the call analysis parameter structure (DX_CAP) ca_pamd_spdval field is PAMD_ACCU.
Call Progress Analysis Table 6. Default Call Progress Analysis Tone Definitions (DM3) Tone ID 7.
Call Progress Analysis dx_deletetone( ) deletes a specific call progress tone dx_createtone( ) creates a new tone definition for a specific call progress tone 7.8.2 TONE_DATA Data Structure The TONE_DATA structure contains tone information for a specific call progress tone. This structure contains a nested array of TONE_SEG substructures. A maximum of six TONE_SEG substructures can be specified. The TONE_DATA structure specifies the following key information: TONE_SEG.
Call Progress Analysis TONE_DATA.numofseg Specifies the number of segments for a multi-segment tone. 7.8.3 Rules for Modifying a Tone Definition on DM3 Boards Consider the following rules and guidelines for modifying default tone definitions on DM3 boards using the voice API library: • You must issue dx_querytone( ), dx_deletetone( ), and dx_createtone( ) in this order, one tone at a time, for each tone definition to be modified.
Call Progress Analysis Consider the following guidelines when creating a single tone proxy: • It is recommended that you add at least 60 Hz to the top of the dual tone range and subtract at least 60 Hz from the bottom of the dual tone range. For example: Freq1 (Hz): 400 - 500 Freq 2 (Hz): 600 - 700 Twin tone freq (Hz): 340 - 760 • Before using the TONE_DATA structure in a function call, set any unused fields in the structure to zero to prevent possible corruption of data in the allocated memory space.
Call Progress Analysis • Determining the Outcome of a Call • Obtaining Additional Call Outcome Information 7.10.1 Overview of Steps to Initiate Call Progress Analysis Perform the following procedure to initiate an outbound call with call progress analysis: 1.
Call Progress Analysis • DX_PAMDENABLE. Enables PAMD, PVD, and fax tone detection. • DX_PAMDOPTEN. Enables PAMD, PVD, DX_OPTNOCON, and fax tone detection. Note: DX_OPTEN and DX_PVDOPTEN are obsolete. Use DX_OPTNOCON and DX_PVDOPTNOCON instead. For more information on adjusting DX_CAP parameters, see Section 7.11, “Call Progress Analysis Tone Detection on Springware Boards”, on page 65, Section 7.12, “Media Tone Detection on Springware Boards”, on page 69, and Section 7.
Call Progress Analysis 7.10.5 Determining the Outcome of a Call In asynchronous mode, once dx_dial( ) with call progress analysis has terminated, use the extended attribute function ATDX_CPTERM( ) to determine the outcome of the call. (In synchronous mode, dx_dial( ) returns the outcome of the call.) ATDX_CPTERM( ) will return one of the following call progress analysis termination results: CR_BUSY Called line was busy. CR_CEPT Called line received operator intercept (SIT).
Call Progress Analysis Figure 5. Call Outcomes for Call Progress Analysis (Springware) Incoming Signal Frequency Detection No Intercept (SIT) Dialtone Cadence Detection Faxtone Busy Positive Voice or Answering Machine Detection Loop Current Detection No Answer CR_NOCR_CEPT DIALTONE CR_FAXTONE CR_BUSY CR_NOANS Connect Reason No Ringback Connect CR_NORB CR_CNCT CR_CAD CON_LPC CON_PVD CON_PAMD Termination Reason Termination Reason: From ATDX_CPTERM( ). Connect Reason: From ATDX_CONNTYPE( ). 7.
Call Progress Analysis ATDX_FRQDUR3( ) Returns duration of third frequency detected. ATDX_FRQHZ( ) Returns frequency detected in Hz of first detected tone. ATDX_FRQHZ2( ) Returns frequency of second detected tone. ATDX_FRQHZ3( ) Returns frequency of third detected tone. ATDX_LONGLOW( ) Returns duration of longer silence. ATDX_FRQOUT( ) Returns percent of frequency out of bounds. ATDX_SHORTLO( ) Returns duration of shorter silence. ATDX_SIZEHI( ) Returns duration of non-silence.
Call Progress Analysis 7.11.1 Tone Detection Overview PerfectCall call progress analysis uses a combination of cadence detection and frequency detection to identify certain signals during the course of an outgoing call. Cadence detection identifies repeating patterns of sound and silence, and frequency detection determines the pitch of the signal. Together, the cadence and frequency of a signal make up its “tone definition”.
Call Progress Analysis 7.11.3 Dial Tone Detection Wherever call progress analysis is in effect, a dial string for an outgoing call may specify special ASCII characters that instruct the system to wait for a certain kind of dial tone.
Call Progress Analysis The following DX_CAP fields govern ringback behavior: ca_stdely Start Delay: the delay after dialing has been completed before starting cadence detection, frequency detection, and positive voice detection (in 10 msec units). Default: 25 (0.25 seconds). ca_cnosig Continuous No Signal: the maximum length of silence (no signal) allowed immediately after the ca_stdely period (in 10 msec units).
Call Progress Analysis Some telephone systems return a momentary drop in loop current when a connection has been established (answer supervision). Loop current detection returns a connect when a transient loop current drop is detected. In some environments, including most PBXs, answer supervision is not provided. In these environments, Loop current detection will not function. Check with your Central Office or PBX supplier to see if answer supervision based on loop current changes is available.
Call Progress Analysis 7.12.1 Positive Voice Detection (PVD) Positive voice detection (PVD) can detect when a call has been answered by determining whether an audio signal is present that has the characteristics of a live or recorded human voice. This provides a very precise method for identifying when a connect occurs. The ca_intflg field in DX_CAP enables/disables PVD. For information on enabling PVD, see Section 7.10.2, “Setting Up Call Progress Analysis Features in DX_CAP”, on page 61.
Call Progress Analysis ca_pamd_qtemp PAMD Qualification Template: the algorithm to use in PAMD. At present there is only one template: PAMD_QUAL1TMP. This parameter must be set to this value. ca_pamd_failtime maximum time to wait for positive answering machine detection or positive voice detection after a cadence break. Default Value: 400 (in 10 msec units). ca_pamd_minring minimum allowable ring duration for positive answering machine detection. Default Value: 190 (in 10 msec units). 7.
Call Progress Analysis The voice driver contains default definitions for each of these tones. The default definitions will allow applications to identify the tones correctly in most countries and for most switching equipment.
Call Progress Analysis 7.15.1 Tri-Tone SIT Sequences SIT frequency detection operates simultaneously with all other call progress analysis detection methods. The purpose of frequency detection is to detect the tri-tone special information tone (SIT) sequences and other single-frequency tones. Detection of a SIT sequence indicates an operator intercept or other problem in completing the call. SIT frequency detection can detect virtually any single-frequency tone below 2100 Hz and above 300 Hz.
Call Progress Analysis 3. After a SIT sequence is detected, ATDX_CPTERM( ) will return CR_CEPT to indicate an operator intercept, and you can determine which SIT sequence was detected by obtaining the actual detected frequency and duration for the tri-tone sequence using extended attribute functions. These functions are described in detail in the Voice API Library Reference. The following fields in the DX_CAP are used for frequency detection on voice boards.
Call Progress Analysis ca_lower2frq Lower bound for second tone in Hz. Default: 0. ca_upper2frq Upper bound for second tone in Hz. Default: 0. ca_time2frq Minimum time for second tone to remain in bounds. Default: 0 (10 msec units). ca_mxtime2frq Maximum allowable time for second tone to be present. Default: 0 (10 msec units). Third Tone The following fields in the DX_CAP are used for frequency detection for the third tone. Frequencies are specified in Hertz, and time is specified in 10 msec units.
Call Progress Analysis ATDX_FRQDUR2( ) Duration of the tone detected in the tone detection range specified by the DX_CAP ca_lower2frq and ca_upper2frq parameters; usually the second tone of an SIT sequence (10 msec units). ATDX_FRQHZ3( ) Frequency in Hz of the tone detected in the tone detection range specified by the DX_CAP ca_lower3frq and ca_upper3frq parameters; usually the third tone of an SIT sequence.
Call Progress Analysis 7.15.6 Setting Single Tone Frequency Detection Parameters The information in this section does not apply to DM3 boards, as the DX_CAP fields mentioned in this section are not supported on DM3 boards. The following paragraphs describe how to set single tone frequency detection on Springware boards. Setting single tone frequency detection parameters allows you to identify that a SIT sequence was encountered because one of the tri-tones in the SIT sequence was detected.
Call Progress Analysis 7.16 Cadence Detection in Basic Call Progress Analysis (Springware Only) Cadence detection is a component of basic call progress analysis. The following topics discuss cadence detection and some of the most commonly adjusted cadence detection parameters in basic call progress analysis: • Overview • Typical Cadence Patterns • Elements of a Cadence • Outcomes of Cadence Detection • Setting Selected Cadence Detection Parameters • Obtaining Cadence Information 7.16.
Call Progress Analysis Figure 6. A Standard Busy Signal 50 50 50 50 nonsilence 50 silence 50 50 The timings are given in units of 10ms. Figure 7. A Standard Single Ring 200 200 ≈ ≈ nonsilence 400 ≈ silence The timings are given in units of 10ms. Figure 8. A Type of Double Ring 50 50 50 nonsilence silence 25 225 ≈ The timings are given in units of 10ms. 7.16.
Call Progress Analysis Figure 9.
Call Progress Analysis 7.16.4 Outcomes of Cadence Detection Cadence detection can identify the following conditions during the period used to establish the cadence or after the cadence has been established: • No Ringback • Connect • Busy • No Answer Although loop current detection and positive voice detection provide complementary means of detecting a connect, cadence detection provides the only way in basic call progress analysis to detect a no ringback, busy, or no answer.
Call Progress Analysis 7.16.5 Setting Selected Cadence Detection Parameters Only the most commonly adjusted cadence detection parameters are discussed here. For a complete listing and description of the DX_CAP data structure, see the Voice API Library Reference. You should only need to adjust cadence detection parameters for network environments that do not conform to the U.S. standard network environment (such as behind a PBX). 7.16.5.
Call Progress Analysis Figure 11. No Ringback Due to Continuous No Signal Dialing Complete nonsilence No Ringback Returned CA_STDELY 250 CA_CNOSIG 4000 ≈ silence The timings are given in units of 10ms. If the length of any period of nonsilence exceeds the value of ca_cnosil (continuous nonsilence), a no ringback is returned, shown in Figure 12. ca_cnosil Continuous Nonsilence: the maximum length of nonsilence allowed. If exceeded, a no ringback is returned. Default: 650 (in 10 msec units), or 6.
Call Progress Analysis ca_nsbusy Nonsilence Busy: the number of nonsilence periods in addition to ca_nbrdna to wait before returning a busy. Default: 0. ca_nsbusy is added to ca_nbrdna to give the actual number of busy cadences at which to return busy. Note that even though ca_nsbusy is declared as an unsigned variable, it can be a small negative number. Do not allow ca_nbrdna + ca_nsbusy to equal 2. This is a foible of the 2’s complement bit mapping of a small negative number to an unsigned variable. 7.
Call Progress Analysis Cadence detection will measure the length of the salutation when the ca_hedge (hello edge) parameter is set to 2 (the default). ca_hedge Hello Edge: the point at which a connect will be returned to the application, either the rising edge (immediately when a connect is detected) or the falling edge (after the end of the salutation). 1 = rising edge. 2 = falling edge. Default: 2 (connect returned on falling edge of salutation).
Call Progress Analysis After call progress analysis is complete, call ATDX_ANSRSIZ( ). If the return value is less than 180 (1.8 seconds), you have probably contacted a residence. A return value of 180 to 300 is probably a business. If the return value is larger than 480, you have probably contacted an answering machine. A return value of 0 means that a connect was returned because excessive silence was detected. This can vary greatly in practice. Note: 7.16.
Recording and Playback 8. 8 This chapter discusses playback and recording features supported by the voice library. The following topics are discussed: • Overview of Recording and Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 • Digital Recording and Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 • Play and Record Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recording and Playback 8.2 Digital Recording and Playback In digital speech recording, the voice board converts the human voice from a continuous sound wave, or analog signal, into a digital representation. The voice board does this by frequently sampling the amplitude of the sound wave at individual points in the speech signal.
Recording and Playback entry for that file. Using dx_playf( ) is more convenient for a single file playback because you do not have to set up a DX_IOTT structure for the one file and the application does not need to open the file. dx_recf( ) provides the same single file convenience for the dx_rec( ) function. For a complete list of I/O convenience functions and function reference information, see the Voice API Library Reference. 8.
Recording and Playback Table 9. Voice Encoding Methods (DM3) Sampling Rate (kHz) Digitizing Method Note: Resolution (Bits) Bit Rate (Kbps) File Format OKI ADPCM 6 4 24 VOX, WAVE OKI ADPCM 8 4 32 VOX, WAVE IMA ADPCM 8 4 32 VOX, WAVE G.711 PCM A-law and mu-law 6 8 48 VOX, WAVE G.711 PCM A-law and mu-law 8 8 64 VOX, WAVE G.
Recording and Playback Table 10. Voice Encoding Methods (Springware) Sampling Rate (kHz) Digitizing Method Note: 8.6 Resolution (Bits) Bit Rate (Kbps) File Format OKI ADPCM 6 4 24 VOX, WAVE OKI ADPCM 8 4 32 VOX, WAVE G.711 PCM A-law and mu-law 6 8 48 VOX, WAVE G.711 PCM A-law and mu-law 8 8 64 VOX, WAVE Linear PCM 8 8 64 VOX, WAVE Linear PCM 11 8 88 VOX, WAVE Linear PCM 11 16 176 VOX, WAVE GSM 6.10 full rate (Microsoft format) 8 (value ignored) 13 WAVE GSM 6.
Recording and Playback • Subsequent pairs of the code words are packed in the same way into successive octets, with the first code word of each pair placed in the least significant four bits of the octet. It is preferable to extend the voice sample with silence such that the encoded value consists of an even number of code words. However, if the voice sample consists of an odd number of code words, then the last code word will be discarded. The G.
Recording and Playback On Springware boards on Linux, use the following functions for transaction record: dx_recm( ) records voice data from two channels to a data file, memory, or custom device dx_recmf( ) records voice data from two channels to a single file See the Voice API Library Reference for a full description of functions. 8.
Recording and Playback with SCR. For more information on modifying SCR parameters, see the Configuration Guide for your product or product family. On Springware boards, you enable SCR in the voice.prm file which is downloaded to the board during initialization. You must edit this file and set appropriate values for the SCR parameters for use in your working environment before initializing the board. You cannot enable this feature through the voice API. After SCR is enabled in the voice.
Recording and Playback • G.711 PCM, 6 kHz with 8-bit samples (48 kbps) and 8 kHz with 8-bit samples (64 kbps) using A-law or mu-law coding, VOX and WAVE file formats • G.721 at 8 kHz with 4-bit samples (32 kbps), VOX and WAVE file formats • G.
Recording and Playback 8.9.2 Enabling The modes related to the voice activity detector are specified in the mode parameter of the dx_reciottdata( ) function. They are: RM_VADNOTIFY generates an event, TDX_VAD, on detection of voice energy during the recording operation Note: TDX_VAD does not indicate function termination; it is an unsolicited event. Do not confuse this event with the TEC_VAD event which is used in the continuous speech processing (CSP) library.
Recording and Playback • G.726 bit-exact voice coder at 8 kHz with 2-, 3-, 4-, or 5-bit samples (16, 24, 32, 40 kbps), VOX and WAVE file formats 8.10 Streaming to Board The streaming to board feature is discussed in the following topics: • Streaming to Board Overview • Streaming to Board Functions • Implementing Streaming to Board • Streaming to Board Hints and Tips 8.10.1 Streaming to Board Overview The streaming to board feature provides a way to stream data in real time to a network interface.
Recording and Playback 8.10.3 Implementing Streaming to Board Perform the following steps to implement streaming to board in your application: Note: These steps do not represent every task that must be performed to create a working application but are intended as general guidelines for implementing streaming to board. 1. Decide on the size of the circular stream buffer. This value is used as input to the dx_OpenStreamBuffer( ) function. To determine the circular stream buffer size, see Section 8.10.
Recording and Playback • Recommendation for the high water mark: it should be based on the following: (size of the circular stream buffer) minus (two times the size of the bulk queue buffer) For example, if the circular stream buffer is 100 kbytes, and the bulk queue buffer size is 8 kbytes, set the high water mark to 84 kbytes. (The bulk queue buffer size is set through the dx_setchxfercnt( ) function.
Recording and Playback The pause and resume play feature is not supported on Springware boards. 8.11.
Recording and Playback • It does not make sense to use the same DTMF digit as a termination condition on a play and as the pause/resume condition. • To end a paused play, use dx_stopch( ). 8.12 Echo Cancellation Resource The echo cancellation resource (ECR) feature is not supported on DM3 boards. The echo cancellation resource (ECR) feature is a functional component of a voice channel.
Recording and Playback 8.12.2 Echo Cancellation Resource Operation The echo canceller accepts two TDM bus input data streams. One stream contains data that is identical to that which was transmitted to the echo-producing circuit (Transmit Signal in Figure 15). The second stream, referred to as the echo-carrying stream, contains received data from this circuit. The received data typically contains a signal with two time-varying signals superimposed upon one another.
Recording and Playback Figure 16. Echo Canceller Operating over a TDM bus Switching Handler Echo-Generating Signal Telephone Network Echo RX Signaling Analog Device E C R ECR_RX ECR_TX VOX_TX Echo-Carrying Signal TX VOX_RX SCbus Echo-Carrying Signal Echo-Reference Signal Enabled in ECR Mode Disabled in ECR Mode Voice Device SCbus Once the ECR feature is enabled on a board, each voice channel is also permanently assigned two TDM bus transmit time slots.
Recording and Playback 8.12.3 Modes of Operation The echo cancellation resource feature has two modes of operation as discussed in the following topics: • Overview of Modes • Standard Voice Processing (SVP) Mode • Echo Cancellation Resource (ECR) Mode 8.12.3.1 Overview of Modes When the ECR feature is enabled at initialization time on a supported board, there are two possible modes of operation: SVP and ECR.
Recording and Playback ECR mode is activated using the dx_listenecrex( ) function. For technical information on ECR functions, see the Voice API Library Reference. Note: dx_listen( ) may precede or follow the dx_listenecr( ) or dx_listenecrex( ) function. If multiple dx_listen( ) and dx_listenecr( ) or dx_listenecrex( ) function calls are issued against a single channel, the echo cancellation operates on the last two issued.
Recording and Playback 2. Have both MSI/SC stations listen to the ECR transmit of the opposite voice channel. ms_listen (MS1, &CH2_ECR_TX); ms_listen (MS2, &CH1_ECR_TX); 3. Have both voice channel devices listen to their corresponding MSI/SC station device. dx_listen (CH1, &MS1_TX); dx_listen (CH2, &MS2_TX); 4. Have each voice channel connect its echo canceller’s receive time slot to the opposite echo canceller’s ECR transmit. These signals are used as echo reference signals.
Recording and Playback /* Open voice board 1 channel 1 device */ if ((chdev1 = dx_open("dxxxB1C1", 0)) == -1) { printf("Cannot open channel dxxxB1C1. errno = %d", errno); exit(1); } /* Open voice board 1 channel 2 device */ if ((chdev2 = dx_open("dxxxB1C2", 0)) == -1) { printf("Cannot open channel dxxxB1C2. errno = %d", errno); exit(1); } /* Open MSI/SC board 1 station 1 device */ if ((msdev1 = ms_open("msiB1C1", 0)) == -1) { printf("Cannot open station msiB1C1.
Recording and Playback scts = ms1txts; /* Have channel 1 listen to station 1's transmit */ if (dx_listen(chdev1, &sc_tsinfo) == -1) { printf("Error message = %s, on %s", ATDV_ERRMSGP(chdev1), ATDV_NAMEP(chdev1)); exit(1); } scts = ms2txts; /* Have channel 2 listen to station 2's transmit */ if (dx_listen(chdev2, &sc_tsinfo) == -1) { printf("Error message = %s, on %s", ATDV_ERRMSGP(chdev2), ATDV_NAMEP(chdev2)); exit(1); } scts = ch2ecrtxts; /* Have channel 1's echo-canceller listen to channel 2's echo-cance
Recording and Playback exit(1); } if (dx_close(chdev2) == -1) { printf("Error message = %s, on %s", ATDV_ERRMSGP(chdev2), ATDV_NAMEP(chdev2)); exit(1); } if (ms_close(msdev1) == -1) { printf("Error message = %s, on %s", ATDV_ERRMSGP(chdev1), ATDV_NAMEP(chdev1)); exit(1); } if (ms_close(msdev2) == -1) { printf("Error message = %s, on %s", ATDV_ERRMSGP(msdev2), ATDV_NAMEP(msdev2)); exit(1); } return(0); } 8.12.4.
Recording and Playback Figure 18. An ECR Play Over the TDM bus CH2 Voice File TX (Unused) CH1 ECR TX EC TX ECR RX RX CH2_ECR_TX S C b u s S C b MS1_TX u MS2_TX (unused) s CH1_TX MS1 MS2 Example #include #include #include #include #include #include
Recording and Playback /* Open MSI/SC board 1 station 2 device */ if ((msdev2 = ms_open("msiB1C2", 0)) == -1) { printf("Cannot open station msiB1C2. errno = %d", errno); exit(1); } /* Initialize an TDM bus time slot information */ sc_tsinfo.sc_numts = 1; sc_tsinfo.
Recording and Playback /* . . Continue .
Speed and Volume Control 9. 9 This chapter describes how to control the speed and volume of play on a channel. The following topics are discussed: • Speed and Volume Control Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 • Speed and Volume Convenience Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 • Speed and Volume Adjustment Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Speed and Volume Control dx_addvoldig( ) adds a digit that will modify volume by a specified amount See the Voice API Library Reference for detailed information about these functions. 9.3 Speed and Volume Adjustment Functions Speed or volume can be adjusted explicitly or can be set to adjust in response to a preset condition, such as a specific digit. For example, speed could be set to increase a certain amount when “1” is pressed on the telephone keypad.
Speed and Volume Control A speed/volume adjustment stays in effect until the next adjustment on that channel or until a system reset. The SVMT is like a 21-speed bicycle. You can select the gear ratio for each of the 21 speeds before you go for a ride (by changing the values in the SVMT). And you can select any gear once you are on the bike, like adjusting the current speed/volume to any setting in the SVMT.
Speed and Volume Control The default speed modification table is shown in Table 11. Table 11.
Speed and Volume Control The default volume modification table is shown in Table 12. Table 12.
Speed and Volume Control 9.5 Play Adjustment Digits The voice software processes play adjustment digits differently from normal digits: • If a play adjustment digit is entered during playback, it causes a play adjustment only and has no other effect. This means that the digit is not added to the digit queue; it cannot be retrieved with the dx_getdig( ) function. • On DM3 boards, digits that are used for play adjustment may also be used as a terminating condition.
Speed and Volume Control See the Voice API Library Reference for more information about these functions and data structures.
Speed and Volume Control 120 Voice API Programming Guide — June 2005
Send and Receive FSK Data 10. 10 This chapter describes the Analog Display Services Interface (ADSI) protocol, two-way frequency shift keying (FSK), and guidelines for implementing ADSI and two-way FSK support using voice library functions. • Overview of ADSI and Two-Way FSK Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 • ADSI Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 • ADSI Operation . . . . . .
Send and Receive FSK Data acknowledge and the data transmission (and/or reception) will then be initiated. Once the data transmission/reception is complete, the devices switch back to voice mode. This newer implementation of ADSI is supported through the dx_RxIottData( ), dx_TxIottData( ), and dx_TxRxIottData( ) functions. This implementation is referred to simply as “ADSI Support” or “Two-Way ADSI.
Send and Receive FSK Data 10.3 ADSI Operation ADSI data is encoded using a standard 1200 baud modem specification and transmitted to the telephone on the voice channel. The voice is muted for the data transfer to occur. Responses from the ADSI telephone are mapped into DTMF sequences. ADSI data is sent to the ADSI telephone in a message burst corresponding to a single transmission. Each message burst or transmission can contain up to 5 messages, with each message consisting of one or more ADSI commands.
Send and Receive FSK Data 10.5 Two-Way ADSI Two-way ADSI includes several enhancements to one-way ADSI, including two-way frequency shift keying (FSK). The following topics discuss two-way ADSI: • Transmit to On-Hook CPE • Two-Way FSK 10.5.1 Transmit to On-Hook CPE The transmit to on-hook customer premises equipment (CPE) feature allows messages to be sent to an ADSI phone when the phone is either on-hook or off-hook.
Send and Receive FSK Data information about two-way FSK transmission, see Telcordia Technologies Special Report SR3462, A Two-Way Frequency Shift Keying Communication for the ADSI. In addition to features provided by basic ADSI, two-way FSK for ADSI can be used in the following applications: • sending and receiving e-mail between display-based ADSI phones and the server • sending FSK caller ID data to a CPE device 10.
Send and Receive FSK Data 10.7.1 Library Support on DM3 Boards DM3 boards support ADSI one-way, two-way FSK, and fixed-line short message service (SMS). The following voice library functions and data structures support this functionality on DM3 boards: dx_RxIottdata( ) function Receives ADSI data on a specified channel. dx_TxIottdata( ) function Transmits ADSI data on a specified channel. dx_TxRxIottdata( ) function Starts a transmit-initiated reception of data (two-way ADSI) on a specified channel.
Send and Receive FSK Data 10.7.2 Library Support on Springware Boards Springware boards support ADSI one-way, two-way FSK, and fixed-line short message service (SMS). The following voice library functions and data structures support this functionality on Springware boards: dx_RxIottdata( ) function Receives ADSI data on a specified channel. dx_TxIottdata( ) function Transmits ADSI data on a specified channel.
Send and Receive FSK Data • Implementing Two-Way ADSI Using dx_TxRxIottData( ) 10.8.1 Technical Overview of One-Way ADSI Data Transfer In one-way ADSI data transfer, the ADSI server sends ADSI messages to a CPE device, such as an ADSI-compliant telephone. The transactions that occur between the server and the CPE during one-way ADSI data transfer are as follows: 1. The server initiates the data transfer by sending a CPE Alerting Signal (CAS) to the CPE. 2.
Send and Receive FSK Data 2. Issue dx_TxIottData( ). To generate an initial CAS to the CPE device, dwTxDataMode within ADSI_XFERSTRUC must be set to ADSI_ALERT. 3. The CAS is received by the CPE and the CPE sends an acknowledgment digit (DTMF ‘A’) to the voice device.
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.
Send and Receive FSK Data 10.8.4 Implementing Two-Way ADSI Using dx_TxIottData( ) The dx_TxIottData( ) function is used to implement two-way ADSI data transfer. The dx_TxIottData( ) function transmits the CAS and the subsequent "Switch to Peripheral Mode Message" to the CPE. To transfer ADSI FSK data, set the parameters and configure the structures as described below: • Set the wType parameter DT_ADSI.
Send and Receive FSK Data 10.8.5 Implementing Two-Way ADSI Using dx_TxRxIottData( ) After the two-way ADSI transmission is implemented using the dx_TxIottData( ) function, additional ADSI FSK messages are typically sent to the CPE peripheral to configure the display and soft keys.
Send and Receive FSK Data 8. Issue dx_RxIottData( ) to receive messages from the CPE. This function should be issued as soon as possible because the CPE peripheral can send data to the server after a minimum of 100 msec following the completion of its transmission. If data needs to be transmitted to the CPE when the server is waiting to receive data, issue dx_stopch( ) to terminate the current dx_RxIottData( ) function.
Send and Receive FSK Data The following sample code illustrates the use of the dx_TxIottData( ) function to generate a CAS tone and transmit an ADSI file: /* Setup DX_IOTT to play from disk */ /* Setup DV_TPT for termination conditions */ /* Setup ADSI_XFERSTRUC to send CAS followed by ADSI FSK upon receipt of DTMF ‘A’ */ adsimode.cbSize = sizeof(adsimode); adsimode.
Caller ID 11. 11 This chapter provides information on caller ID: • Overview of Caller ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 • Caller ID Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 • Accessing Caller ID Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 • Enabling Channels to Use the Caller ID Feature. . . . . . . . .
Caller ID ACLIP (Analog Calling Line Identity Presentation) a standard used in Singapore published by the Telecommunications Authority of Singapore and supported in the following formats: • Single Data Message (SDM) format • Multiple Data Message (MDM) format CLIP (Calling Line Identity Presentation) a standard used in the United Kingdom published by British Telecommunications (BT) JCLIP (Japanese Calling Line Identity Presentation) a standard for “Number Display” used in Japan published by Nippon Telegra
Caller ID 11.3 Accessing Caller ID Information You can process caller ID information in your application in the following ways: • For CLASS or ACLIP, the caller ID information is received from the service provider between the first and second ring. Set the ring event in the application to occur on or after the second ring. The ring event indicates reception of the CLASS or ACLIP caller ID information from the CO.
Caller ID 11.4 Enabling Channels to Use the Caller ID Feature During Intel Dialogic System Service startup, before the initial use of caller ID functions, the application must enable the caller ID feature on the channels requiring caller ID. On Springware boards, caller ID is enabled by setting the DXCH_CALLID channel-based parameter to DX_CALLIDENABLE using dx_setparm( ). The default setting is caller ID disabled, DX_CALLIDDISABLE. Caller ID on DM3 boards is available via the Global Call API.
Caller ID • Bellcore specification TR-NWT-000030 (see Telcordia Technologies contact info provided in CLASS) CLIP Contact British Telecommunications. • SIN (Supplier Information Note) 242 (issue 01) • SIN (Supplier Information Note) 227 (issue 01) JCLIP Contact Nippon Telegraph and Telephone Corporation.
Caller ID 140 Voice API Programming Guide — June 2005
Cached Prompt Management 12. 12 This chapter discusses the cached prompt management feature of the voice library. The following topics are covered: • Overview of Cached Prompt Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 • Using Cached Prompt Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 • Cached Prompt Management Example Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 12.
Cached Prompt Management 2. Call SRLGetPhysicalBoardName( ) to return the physical board name, which is in the form brdBn, such as brdB1. This function is passed the AUID of the board from step 1. For information on this function, see the Standard Runtime Library API Library Reference. 3. Call dx_open( ) with brdBn as the device name and get a handle to the physical board device. 4. Use dx_play( ) on a channel device with IO_CACHED specified in the DX_IOTT structure io_type field.
Cached Prompt Management • If the combined length of data specified in the series of DX_IOTT data structures exceeds the available on-board memory, this results in the EDX_NOTENOUGHBRDMEM error. If this error occurs, none of the series of DX_IOTT is downloaded to the board. To avoid this situation, be sure to determine that there is sufficient on-board memory available for the cached prompt using dx_getcachesize( ) before issuing a play function.
Cached Prompt Management 12.3 Cached Prompt Management Example Code This example code illustrates one way to implement cached prompt management in your application. It uses the following key steps, as indicated in the comments: 1. Get the AUIDs of all physical boards in the system. 2. Get the names of all physical boards for the corresponding AUIDs. 3. Open all physical board devices. 4.
Cached Prompt Management devh[i] = dx_open(&szBoardName[offset],0); } //Step 4 Download the prompts to a board after determining available cache size int nCacheSize; int result; int promptHandle; /* Handle of the prompt to be downloaded */ int fd1; /* First file descriptor for file to be downloaded */ int fd2; /* Second file descriptor for file to be downloaded */ DX_IOTT iott[2]; /* I/O transfer table to download cache prompt */ int totalfilesize; result = dx_getcachesize(&devh[0], &nCacheSize, DX_CACHERE
Cached Prompt Management tpt.tp_flags = TF_MAXDTMF; /* Open VOX file to play -- Linux only */ if ((fd = open("HELLO.VOX",O_RDONLY)) == -1) { printf("File open error\n"); exit(2); } /* Open VOX file to play -- Windows only */ if ((fd = dx_fileopen("HELLO.VOX",O_RDONLY|O_BINARY)) == -1) { printf("File open error\n"); exit(2); } /* Set up DX_IOTT */ /*This block specifies a regular data file */ iottplay[0].io_fhandle = fd; iottplay[0].io_bufp = 0; iottplay[0].io_offset = 0; iottplay[0].
Global Tone Detection and Generation, and Cadenced Tone Generation 13. 13 This chapter discusses global tone detection (GTD), global tone generation (GTG), and cadenced tone generation: • Global Tone Detection (GTD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 • Global Tone Generation (GTG). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 • Cadenced Tone Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Global Tone Detection and Generation, and Cadenced Tone Generation DTMF set (0-9, a-d, *, and #), and the standard MF set (0-9, a-c, and *). GTD works simultaneously with DTMF and MF tone detection. When GTD detects a tone, it responds by producing either a tone event on the event queue or a digit on the digit queue. The particular response depends on the GTD tone configuration. 13.1.
Global Tone Detection and Generation, and Cadenced Tone Generation • cadence components Adding a tone template to a channel enables detection of a tone on that channel. Although only one tone template can be created at a time, multiple tone templates can be added to a channel. Each channel can have a different set of tone templates. Once created, tone templates can be selectively enabled or disabled.
Global Tone Detection and Generation, and Cadenced Tone Generation Tips and Hints for Building Tone Templates The following are tips and hints when building a tone template for global tone detection: • After using a build-tone function to define a new tone template, you must call dx_addtone( ) to add the tone template to a channel and enable detection of that tone on a channel.
Global Tone Detection and Generation, and Cadenced Tone Generation dx_deltones( ) Removes all tone templates previously added to a channel with dx_addtone( ). If no tone templates were previously enabled for this channel, the function has no effect. dx_deltones( ) does not affect tones defined by build-tone template functions and tone templates not yet defined. If you have added tones for call progress analysis, these tones are also deleted.
Global Tone Detection and Generation, and Cadenced Tone Generation 13.1.7 Setting GTD Tones as Termination Conditions To detect a GTD (user-defined) tone, you can specify it as a termination condition for I/O functions. Set the tp_termno field in the DV_TPT structure to DX_TONE, and specify DX_TONEON or DX_TONEOFF in the tp_data field. 13.1.8 Maximum Amount of Memory for Tone Templates Table 16 gives the maximum amount of memory available for user-defined tone templates on Springware boards.
Global Tone Detection and Generation, and Cadenced Tone Generation deviation of each of the two tones minus any overlap (and minus any truncation by the GTD detection range). For example: • Single Tone: 400 Hz (125 Hz deviation) = bandwidth of 275 to 525 Hz, total of 250 Hz. • Dual Tone: 450 Hz (50 Hz deviation) and 1000 Hz (75 Hz deviation) = bandwidth of 400 to 500 Hz and 925 to 1075 Hz, total of 250 Hz.
Global Tone Detection and Generation, and Cadenced Tone Generation analysis creates 8 GTD tones; this uses 17 memory blocks on each channel on which it is activated. • On Springware boards, if you use call progress analysis to identify tri-tone special information tone (SIT) sequences, call progress analysis creates GTD tones, which reduces the number of user-defined tones you can create.
Global Tone Detection and Generation, and Cadenced Tone Generation Table 18. Maximum Tone Templates for Dual Tones (Springware) (Continued) 13.1.11 D/240JCT-T1 300 15 D/300JCT-E1 450 15 Global Tone Detection Application A sample application for global tone detection (GTD) is detecting leading edge debounce time.
Global Tone Detection and Generation, and Cadenced Tone Generation • Duration of tone The functions and data structures associated with global tone generation are described in the Voice API Library Reference. 13.2.2 GTG Functions The following functions are used to generate tones: dx_bldtngen( ) Builds a tone generation template. This convenience function sets up the tone generation template data structure (TN_GEN) by allowing the assignment of specified values to the appropriate fields.
Global Tone Detection and Generation, and Cadenced Tone Generation 13.
Global Tone Detection and Generation, and Cadenced Tone Generation b. Use the dx_bldtngen( ) function to specify this tone definition in tone[0] (the first TN_GEN tone array element) of the TN_GENCAD structure. c. Identify the off-time for the first tone element and specify it in offtime[0]. If the first tone element is followed immediately by a second tone element, set offtime[0] = 0. d.
Global Tone Detection and Generation, and Cadenced Tone Generation Figure 19. Example of Custom Cadenced Tone Generation Define the Signal as a Dialogic Custom Cadence Tome Set the TN_GENCAD Parameters tngencad.cycles = 255; tngencad.numsegs = 2; tngencad.offtime (0) = 0; tngencad.offtime (1) = 300; dx_bidtngen(&tgencad.
Global Tone Detection and Generation, and Cadenced Tone Generation 13.3.3 How To Generate a Non-Cadenced Tone Both dx_playtoneEx( ) and dx_playtone( ) can generate a non-cadenced tone. Non-cadenced call progress signals can be generated by the dx_playtone( ) function if you define them in a TN_GEN: Dial Tone, Executive Override Tone, and Busy Verification Tone Part A. The dx_playtoneEx( ) function can also generate a non-cadenced tone by using a TN_GENCAD data structure that defines a single segment.
Global Tone Detection and Generation, and Cadenced Tone Generation 13.3.6 Predefined Set of Standard PBX Call Progress Signals The following information describes the predefined set of standard PBX call progress signals that are provided by Intel: • Table 19, “Standard PBX Call Progress Signals”, on page 162 lists the predefined, standard, call progress signals and their signal IDs. The signal IDs can be used with the dx_playtoneEx( ) function to generate the signal.
Global Tone Detection and Generation, and Cadenced Tone Generation Table 19.
Global Tone Detection and Generation, and Cadenced Tone Generation Figure 20.
Global Tone Detection and Generation, and Cadenced Tone Generation Figure 21.
Global Tone Detection and Generation, and Cadenced Tone Generation Table 20.
Global Tone Detection and Generation, and Cadenced Tone Generation Table 20.
Global Tone Detection and Generation, and Cadenced Tone Generation • To generate a continuous, non-cadenced signal, you can use dx_playtoneEx( ) and TN_GENCAD to specify a single segment with zero off-time and with an infinite number of cycles and/or an infinite on-time. Alternatively, you could use dx_playtone( ) and TN_GEN to generate a non-cadenced signal.
Global Tone Detection and Generation, and Cadenced Tone Generation 168 Voice API Programming Guide — June 2005
Global Dial Pulse Detection 14. 14 Global dial pulse detection (global DPD) is a signaling component of the voice library. The following topics provide more information on global DPD: • Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 • Global DPD Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 • Enabling Global DPD . . . . . . . . . . . . . . . . . . . . . . .
Global Dial Pulse Detection • The application can enable global DPD and volume control. (Previously, there was a restriction that DPD digits had to be sent to the event queue instead of the digit queue if volume control was enabled.
Global Dial Pulse Detection Global DPD must be implemented on a call-by-call basis. Global DPD uses the dx_setdigtyp( ) function to enable DPD. See the Voice API Library Reference for information on all functions and data structures described in this chapter. For any digit detected, you can determine the digit type such as DTMF or DPD by using the DV_DIGIT data structure in the application.
Global Dial Pulse Detection 14.6 Retrieving Digits as Events To get the digits as events, use the following asynchronous programming model using the dx_setevtmsk( ), sr_waitevt( ), and sr_getevtdatap( ) functions and the DX_CST data structure. 1. Since the supported voice boards come with channels capable of global DPD, you must enable DPD on the desired channels using the dx_setdigtyp( ) function. 2. For each new connection, use dx_setdigtyp( ) with the D_DPDZ mask, which initializes the DPD algorithm.
Global Dial Pulse Detection Defines for dg_type from Digit Type DTMF 14.9 Digit Buffer Event Queue DG_DTMF_ASCII DG_DTMF DPD DG_DPD_ASCII DG_DPD MF DG_MF_ASCII DG_MF GTD DG_USER1_ASCII DG_USER1 (user-defined) DG_USER2_ASCII DG_USER2 DG_USER3_ASCII DG_USER3 DG_USER4_ASCII DG_USER4 DG_USER5_ASCII DG_USER5 Global DPD Programming Procedure Use the following procedure to implement global DPD: 1. Define a data structure of type DV_DIGIT (this structure is specified in the DXDIGIT.H file).
Global Dial Pulse Detection /* enable DPD and DTMF digits */ dx_setdigtyp(dev, D_DPDZ|D_DTMF); /* clear the digit buffer */ dx_clrdigbuf(dev); /* collect 3 digits from the user */ if (dx_getdig(dev, &tpt, &dig, EV_SYNC) == -1) { /* error, display error message */ printf("dx_getdig error %d, %s\n", ATDV_LASTERR(dev), ATDV_ERRMSGP(dev)); } else { /* display digits received and digit type */ printf("Received \"%s\"\n", dig.
15 R2/MF Signaling 15. This chapter provides a description of R2/MF signaling protocol. The following topics are presented: • R2/MF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 • Direct Dialing-In Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 • R2/MF Multifrequency Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R2/MF Signaling R2/MF signals that are used for supervisory signaling on the network are called line signals. Line signals are beyond the scope of this document. 15.2 Direct Dialing-In Service Since R2/MF address signals can provide the telephone number of the called subscriber’s line, the signals may be used by applications providing direct dialing-in (DDI) service, also known as direct inward dialing (DID), and dialed number identification service (DNIS).
R2/MF Signaling Table 21. Forward Signals, CCITT Signaling System R2/MF tones (Continued) R2/MF TONES INTEL INFORMATION Tone Number Tone Pair Frequencies (Hz) Group I Define Group II Define Tone Detect. ID 13 1620 1980 SIGI_13 SIGII_13 113 14 1740 1980 SIGI_14 SIGII_14 114 15 1860 1980 SIGI_15 SIGII_15 115 Table 22. Backward Signals, CCITT Signaling System R2/MF tones R2/MF TONES Tone Number 15.
R2/MF Signaling Figure 23. Multiple Meanings for R2/MF Signals Group I Meanings Group A Meanings Backward Signals Forward Signals Group II Meanings Group B Meanings In general, Group I forward signals and Group A backward signals are used to control the call setup and to transfer address information between the outgoing register (CO) and the incoming register (CPE). The incoming register can then signal to the outgoing register to change over to the Group II and Group B meanings.
R2/MF Signaling The incoming register backward signals can request: • Transmission of address – Send next digit – Send digit previous to last digit sent – Send second digit previous to last digit sent – Send third digit previous to last digit sent • Category of the call (the nature and origin) – National or international call – Operator or subscriber – Data transmission – Maintenance or test call • Whether or not the circuit includes a satellite link • Country code and language for international calls • In
R2/MF Signaling Table 24.
R2/MF Signaling Table 25.
R2/MF Signaling Table 26.
R2/MF Signaling Table 27. Meanings for R2/MF Group B Backward Signals Tone Number 15.
R2/MF Signaling • As soon as the CO recognizes the CPE acknowledging signal, it stops sending the forward signal. • As soon as the CPE recognizes the end of the forward signal, it stops sending the backward signal. • As soon as the CO recognizes the CPE end of the backward signal, it may start to send the next forward signal. The CPE responds to a tone-on with a tone-on and to a tone-off with a tone-off. The CO responds to a tone-on with a tone-off and to a tone-off with a tone-on.
R2/MF Signaling Figure 25. Example of R2/MF Signals for 4-digit DDI Application CPE Backward Signal CO Forward Signal Digit 3 1-3 Detected Event A-1 Send Next Digit Digit 9 1-9 Response A-1 Send Next Digit Digit 6 1-6 A-1 Send Next Digit Digit 0 1-0 Category of Calling Party: Subscriber w/o Priority-National A-3 Address Complete Changeover to Group B B-6 Subscriber Line Free Charge on Answer II-1 15.
R2/MF Signaling Four sets of defines are provided to specify the 15 Group I and 15 Group II forward signals, and the 15 Group A and 15 Group B backward signals. For a list of these defines, see Table 24, “Meanings for R2/MF Group I Forward Signals”, on page 180, Table 25, “Meanings for R2/MF Group II Forward Signals”, on page 181, Table 26, “Meanings for R2/MF Group A Backward Signals”, on page 182, and Table 27, “Meanings for R2/MF Group B Backward Signals”, on page 183. 15.
Syntellect License Automated Attendant 16. 16 This chapter discusses Intel® hardware and software that include a license for the Syntellect Technology Corporation (STC) patent portfolio: • Overview of Automated Attendant Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 • Syntellect License Automated Attendant Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 • How to Use the Automated Attendant Function Call . . . . . . . . . . . . . . . . . . . . . . . . . .
Syntellect License Automated Attendant – receives digit input and transfers the call to the proper extension • the source code and demonstration code for the automated attendant application 16.2 Syntellect License Automated Attendant Functions Intel boards that are enabled with the Syntellect Technology Corporation (STC) patent license offer a new library interface that contains several API functions.
Building Applications 17. 17 This chapter provides information on building applications using the voice library. The following topics are discussed: • Voice and SRL Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 • Compiling and Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 17.
Building Applications 17.2 Compiling and Linking The following topics discuss compiling and linking requirements: • Include Files • Required Libraries • Run-time Linking • Variables for Compiling and Linking 17.2.1 Include Files Function prototypes and equates are defined in include files, also known as header files. Applications that use voice library functions must contain statements for include files in this form, where filename represents the include file name: #include
Building Applications libsrl.so Standard Runtime Library file. Specify -lsrl in makefile. If you use curses, you must ensure that it is the last library to be linked. Windows You must link the following library files in the order shown when compiling your voice processing application: libdxxmt.lib Main voice library file. libsrlmt.lib Standard Runtime Library file. 17.2.3 Run-time Linking This section applies to Windows only.
Building Applications 192 Voice API Programming Guide — June 2005
Glossary A-law: Pulse Code Modulation (PCM) algorithm used in digitizing telephone audio signals in E1 areas. Contrast with mu-law. ADPCM (Adaptive Differential Pulse Code Modulation): A sophisticated compression algorithm for digitizing audio that stores the differences between successive samples rather than the absolute value of each sample. This method of digitization reduces storage requirements from 64 kilobits/second to as low as 24 kilobits/second.
board locator technology (BLT): Operates in conjunction with a rotary switch to determine and set nonconflicting slot and IRQ interrupt-level parameters, thus eliminating the need to set confusing jumpers or DIP switches. buffer: A block of memory or temporary storage device that holds data until it can be processed. It is used to compensate for the difference in the rate of the flow of information (or time occurrence of events) when transmitting data from one device to another.
network.
download: The process where board level program instructions and routines are loaded during board initialization to a reserved section of shared RAM. downloadable Springware firmware: Software features loaded to Intel voice hardware. Features include voice recording and playback, enhanced voice coding, tone detection, tone generation, dialing, call progress analysis, voice detection, answering machine detection, speed control, volume control, ADSI support, automatic gain control, and silence detection.
G.726: An international standard for encoding 8 kHz sampled audio signals for transmission over 16, 24, 32 and 40 kbps channels. The G.726 standard specifies an adaptive differential pulse code modulation (ADPCM) system for coding and decoding samples. GSM (Global System for Mobile Communications): A digital cellular phone technology based on time division multiple access (TDMA) used in Europe, Japan, Australia and elsewhere around the world.
on-hook: Condition or state of a telephone line when a handset on the line is returned to its cradle (or an equivalent condition occurs). See also hook state. PBX: Private Branch Exchange. A small version of the phone company’s larger central switching office. A local premises or campus switch. PCM (Pulse Code Modulation): A technique used in DSP voice boards for reducing voice data storage requirements.
silence threshold: The level that sets whether incoming data to the voice board is recognized as silence or nonsilence. SIT: (1) Standard Information Tones: tones sent out by a central office to indicate that the dialed call has been answered by the distant phone. (2) Special Information Tones: detection of a SIT sequence indicates an operator intercept or other problem in completing the call. solicited event: An expected event. It is specified using one of the device library’s asynchronous functions.
TDM bus: Time division multiplexing bus. A resource sharing bus such as the SCbus or CT Bus that allows information to be transmitted and received among resources over multiple data lines. termination condition: An event or condition which, when present, causes a process to stop. termination event: An event that is generated when an asynchronous function terminates. See also asynchronous function. time division multiplexing (TDM): See TDM (Time Division Multiplexing).
Index A Adaptive Differential Pulse Code Modulation (ADPCM) 91 address signals, R2/MF signaling 175 ADPCM, G.
call status transition event handling asynchronous 151 synchronous 151 call waiting tone 162 caller ID accessing information 137 enabling 138 error handling 138 support 135 supported formats 135 CCITT Signaling System R2/MF tones 176 channel definition 25 CLASS caller ID 135 cluster configuration 36 coders 89 compelled signaling, R2/MF 183 compile-time linking 190 compiling library files 190, 191 variables 191 CON_CAD connection type 67 CON_LPC connection type 69 CON_PAMD connection type 70 CON_PVD connecti
dx_blddtcad( ) 149 dx_bldst( ) 149 dx_bldstcad( ) 149 dx_bldtngen( ) 156 DX_CAP data structure 48, 61, 70 clearing 35 SIT tone setup 73 dx_chgdur( ) 72 dx_chgfreq( ) 72 dx_chgrepcnt( ) 72 dx_clrcap( ) 35, 48, 61 dx_clrtpt( ) 35 dx_createtone( ) 58 DX_CST data structure 172 dx_deletetone( ) 58 dx_deltones( ) 62 used with tone templates 151 dx_dial( ) 48, 61, 62 DM3 support 47 Springware support 47 dx_distone( ) 151 dx_enbtone( ) 151 dx_getcachesize( ) 142 dx_getdig( ) 34, 118, 171 used with global tone detec
ETSI-FSK channel parameters 126 ETSI-FSK specification 125 event handling 27 event management functions 27 executive override tone 162 extended attribute functions call progress analysis, DM3 50 call progress analysis, Springware 64 F fast busy 162 fax machine detection 68 fax tone detection 45, 53 FEATURE_TABLE data structure 126, 127 fixed routing configuration 35 configuration, restrictions 37 flexible routing configuration 35 forward signals (CCITT signaling system tones) 175, 176 frequency detection 4
libsrl.so 190 libsrlmt.
routing configuration (fixed/flexible) overview 35 run-time linking 191 S short message service (SMS) 121, 125 short messaging service (SMS) 21 signals cadenced, custom 157 predefined standard PBX call progress 160 silence compressed record (SCR) 20, 93 silence compression voice activity detector 96 SIT sequence returning 52 SIT tones call progress analysis parameter setup 73 detection using call progress analysis 73 effect on GTD tones 76 frequency information 77 memory usage for detection 76 tone sequenc
TID_SIT_ANY 52 TID_SIT_IC 52 TID_SIT_INEFFECTIVE_OTHER 52 TID_SIT_IO 52 TID_SIT_NC 52 TID_SIT_NC_INTERLATA 52 TID_SIT_NO_CIRCUIT 52 TID_SIT_NO_CIRCUIT_INTERLATA 52 TID_SIT_OPERATOR_INTERCEPT 52 TID_SIT_REORDER_TONE 52 TID_SIT_REORDER_TONE_INTERLATA 52 TID_SIT_RO 52 TID_SIT_RO_INTERLATA 52 TID_SIT_VACANT_CIRCUIT 52 TID_SIT_VC 52 TN_GEN data structure 156 TN_GENCAD data structure 157, 160 tone definitions DM3 56 modifying, DM3 57 modifying, Springware 71 Springware 71 tone detection call progress analysis, DM
Voice API Programming Guide — June 2005
