RealCT Direct API Developer Guide Document Number 934-010-82 Printed August 2001
General Notices Copyright© 2001, Brooktrout Technology, a Brooktrout Company. All rights reserved. This product may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent, in writing, from Brooktrout Technology. Brooktrout Technology reserves the right to make improvements and/or changes in the products and programs described in this Developer Guide at any time without notice.
Limited Warranty Brooktrout, Inc. (“Brooktrout”) warrants the hardware component of the product described in this documentation (the “Product”) to be free from defects in materials and workmanship under normal and proper use for a period of five years from the date of purchase from Brooktrout.
Brooktrout Technology Multi-Use License Agreement Proprietary Rights The Software is subject to the protection of the copyright laws of the U.S. and foreign jurisdictions, which prohibit unauthorized copying and distribution of copyrighted works. Certain uses of the Software are covered by one or more of the patents listed on the media and associated packaging. The Software incorporates proprietary and confidential algorithms and techniques that are subject to legal protection as trade secrets.
d.
Table of Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii About this Manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Related Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Getting Help . . . . . . . .
Contents Sending and Receiving Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling Rotary Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling DTMF and MF Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handling R2 Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flushing the Digit Buffer . . . . . . . . . . . . . . . . . .
Contents Processing Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110 Handling Incoming Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Handling Outbound Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Using Internal Signaling Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Testing the E1 Setup . . . . . . . . . . . . . . .
Contents Numbering Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping Board Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping RealBLOCs Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Boards in the CT bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling or Disabling Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List of Figures Figure Page Basic Components of a Computer Telephony System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Hardware and Logical Resources on an RDSP/432 Board . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Two Processes With Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Frequencies in DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List of Figures A Call Switched to VP Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Two Boards Transmitting on the Same Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Drop and Insert Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Broadcast Connection and Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List of Tables Table Page Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Device Type Names and Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Hardware/Logical Resources Mapped to Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 API Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List of Tables RealBLOCs MVIP-95 Local Stream Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparing Vantage PCI Internal Stream Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RealBLOCs Local MVIP-90 Stream Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . H.100 Compatibility Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List of Examples Example Page RHT_DIAL_R2 Sample Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 RHT_LOAD_PROTOCOL Sample Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 CONFIG_CARRIER Sample Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Monitoring for Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preface This manual describes how to write applications using the RealCT Direct API. It includes information about the architecture of the API, and how to use the MVIP-90 and H.100 computer telephony buses.
About this Manual This guide contains the following chapters: Chapter 1 Describes how to write applications using the application architecture. Chapter 2 This chapter describes how to send and receive digit. It provides information about rotary, DTMF, MF, and R2 signaling. Chapter 3 This chapter describes T1 networking. Chapter 4 This chapter describes E1 networking. Chapter 5 Describes how to use the MVIP-90 bus to switch data between telephony resources.
About this Manual Typographical Conventions This manual uses the typographical conventions shown in the following table: Table 1.
Documentation Feedback Brooktrout is committed to continuously improving the technical accuracy and usability of our product documentation. All suggestions, comments, or corrections are welcome. Send your feedback to emgtechpubs@brooktrout.com.
Getting Help Getting Help If you encounter problems, contact Brooktrout technical support. You must give technical support your customer number. If you do not know your customer number, you can get it from your Brooktrout sales representative. U.S.A. Brooktrout Technology. VTD 151 Albright Way Los Gatos, California 95032 Phone: +1 408 874-4040 8:00 A.M. to 5:00 P.M. Pacific time, Monday through Friday Fax: +1 408 370-1171 Email: support@brooktrout.com Website: www.brooktrout.
1 Architecture This chapter describes how the API interacts with the operating systems that this API supports, discusses how the systems are designed, and explains how the components of the system are connected to and operate with each other.
Chapter 1: Architecture How RealCT Interfaces With Your System Interfacing With Windows Platforms The Win32 Application Programming Interface (API) provides a set of functions and defines how those functions behave. Microsoft provides two platforms that support the Win32 API: Windows NT and Windows 2000. Since each of these platforms support a common set of Win32 API functions, you can write one application for all platforms.
Reviewing the Key System Components Reviewing the Key System Components A PC-based computer telephony system consists of the following basic components as shown in Figure 1: n n n n One or more computer telephony boards n Application source code Firmware on the board Device drivers RealCT Direct API (Application Programming Interface) files During installation, download the firmware to the digital signal processor (DSP) on the board and load the device drivers.
Chapter 1: Architecture Computer Telephony Boards Voice processing (VP) boards, such as the Prelude, RDSP, or Vantage products, provide the voice processing and telephony hardware for your computer telephony system. The RTNI series boards provide either analog or digital line capabilities that combine with a voice processing board to expand and enhance the versatility of the voice processing system. The PRI-ISALC boards provide single or dual span E1 and T1 digital line capabilities.
Reviewing the Key System Components Digital Signal Processor The Digital Signal Processor (DSP) is a microprocessor dedicated to manipulating digital signals. Each DSP supports four voice processing (VP) resources, also referred to as channels. A board such as the RDSP/432, which provides two or four VP resources, has only one DSP. A board such as the VRS-32, which provides 32 VP resources, has eight DSPs. Firmware The firmware is a set of algorithms that run on the DSP.
Chapter 1: Architecture Devices The API identifies devices and boards by a device name as follows. Table 2.
Reviewing the Key System Components (RDSP/432). More information about the capabilities of each board can be obtained in the Introduction to Computer Telephony manual. RDSP/432 Line Interface DSP VP VP Line Interface VP VP Line Interface Line Interface Figure 2. Hardware and Logical Resources on an RDSP/432 Board The API models these hardware and logical resources as devices. Table 3 shows how the hardware and logical resources of the RDSP/432 board map to devices. Table 3.
Chapter 1: Architecture Application Programming Interface The Application Programing Interface (API) is the interface between an application and the device drivers. The interface is a set of commands the application issues to the device driver. The device driver then sends the commands to the firmware on the board.
Reviewing the Key System Components Parameters The API includes both global and device-specific parameters that determine the behavior of the driver functions. Each time you load the device drivers, these parameters are automatically set to the values specified through the Configuration Wizard. You can set any parameter value for your application by calling the RHT_SET_GLOB or RHT_SET_PARAM function tags.
Chapter 1: Architecture API Calls RealCT Direct uses the API calls listed in Table 4 to communicate with the devices. Table 4. API Calls System Calls Description BrktOpenDevice () Opens the device file. BrktCloseDevice () Closes the device file. BrktDeviceIoControl () Sends the function tag to device driver to perform specified operation. BrktGetLastError () Returns the last operating system error code for calling thread.
Application Architecture Application Architecture Processes and Threads An instance of an executing application is a process. For example, a word processing program and a spreadsheet that are executing simultaneously are both processes. You can have many processes running at once. Each process consists of data, code, and one or more threads. The processes cannot share data directly. Each process can have associated threads that execute functions of the process.
Chapter 1: Architecture A process must have at least one thread. When the last thread terminates, the process also terminates, but terminating the primary thread does not terminate the process as long as there is one thread executing. When the process terminates, all threads associated with that process also terminate. Process 1 Data Code Threads Process 2 Data Code Threads Figure 3.
Application Architecture Application Design Although you can call the BrktDeviceIoControl ( ) function in either synchronous or asynchronous mode, we only recommend using synchronous mode. This means that when the application calls a function, it cannot proceed until that function completes. If you use one thread and one process, a call on line one prevents the application from processing calls on other lines.
Chapter 1: Architecture Multithreaded Multithreaded applications use system resources more efficiently. In multithreaded applications, a single process runs multiple threads. Each thread executes a separate function. When the application begins, it immediately starts one thread for each channel. These threads constantly monitor the line. Then, if a particular thread needs to execute simultaneous functions, it can start additional threads.
2 Digit Handling This chapter describes how to send and receive digits. It provides information about rotary, DTMF, MF, and R2 signaling. All boards that provide VP resources can send and receive digits.
Chapter 2: Digit Handling Using Digits A person using a telephone or a telephony application begins a call by seizing the line, then sending digits to the receiving end. When you place a call on a standard analog phone, these digits are the ones you dial on your telephone key pad. They tell the central office (CO) where to direct the call. The CO then communicates with the other COs in the public network to route the call. Once the call is established, the receiving end processes the call.
Defining Digit Types Defining Digit Types The four methods of sending digits all convey the same information to the CO about which digit the transmitting end dialed. Some methods, such as R2 signaling, convey additional information about the call such as call priority or line status. When you dial a number on a standard analog phone, the CO receives the digits and routes the call to the appropriate destination.
Chapter 2: Digit Handling Defining DTMF Signals DTMF digits are the ones on your telephone keypad. Figure 4 shows the combination of two out of eight possible frequencies that make up each digit. All digits in a given row share the same low frequency. All digits in a given column share the same high frequency. 1209 1336 1477 1633 697 1 2 3 A 770 4 5 6 B 852 7 8 9 C 941 * 0 # D Figure 4.
Defining Digit Types Defining MF Signals MF digits use combinations of 6 frequencies to make a total of 15 dual-frequency tones, as Table 5 shows. MF signals are also called R1-MF. Table 5. Digits MF Tones Frequencies 700 900 1 x x 2 x 3 4 x x x x x x 0 KP spare ST x x 9 spare 1700 x x 8 1500 x x 6 spare 1300 x x 5 7 1100 x x x x x x x x x x x x x COs in the United States, Canada, and Japan generally use MF digits to establish calls.
Chapter 2: Digit Handling Defining R2 Signals COs outside the United States, Canada, and Japan generally use R2 digits to establish calls. Digital telephony systems in these countries also use R2 digits to communicate with the CO. R2 signals, which are also called R2-MF, involve a compelled handshake between the transmitting and receiving ends to confirm that each end receives the signal. Once the call is established, callers use DTMF digits to navigate telephony applications.
Defining Digit Types Figure 5. The R2 Compelled Signaling Sequence Each end waits for an acknowledgment or end of signal until it times out. This handshaking makes compelled signaling more robust than other non-compelled signaling methods. The speed of compelled signaling depends on the quality of the link. If the lines are good, then detection time and overall performance is fast, but bad lines delay detection and slow down the signaling.
Chapter 2: Digit Handling Assigning Frequencies The forward and backward signals use a different set of six frequencies for a total of 15 possible forward and backward tones. n Forward frequencies: 1380, 1500, 1620, 1740, 1860 and 1980 Hz n Backward frequencies: 1140, 1020, 900, 780, 660 and 540 Hz Networks can also operate using only five forward frequencies for a total of ten signals, and four or five backward frequencies for a total of six or ten signals.
Defining Digit Types Table 6 shows how the frequencies combine to form signals 1 through 15 for forward and backward signals. Each frequency is assigned a value for index (x) and a weight (y). As Table 6 shows, adding the index value and the weight value gives a number from 1 to 15. For example, to form the digit one, add the frequency for x=0 and y=1, or 1380 Hz and 1500 Hz for a forward signal. Table 6. Combination Frequencies x+y= Forward No.
Chapter 2: Digit Handling Meaning of R2 Frequencies The forward and backward signals each have two different meanings, depending on when the signal is sent. The forward signals are divided into Group I and Group II. The backward signals are divided into Group A and Group B. The first forward signal always has the Group I meaning, which the incoming register acknowledges with a Group A response.
Defining Digit Types Group I Signals Table 7 shows the meaning of the Group I signals as they are defined in the ITU-T standards. These signals convey information about the country or the language of the originating call or the digits in a number. The meaning of Group I signals depends on whether they are sent at the beginning of a call or in response to a Group A request for information. Table 7.
Chapter 2: Digit Handling Group II Signals The outgoing register switches to Group II signals after the incoming register sends signal A-3 or A-5. These signals tell the receiving end the call category: subscriber, operator, or data. Table 8 shows the meanings of the Group II signals. Table 8.
Defining Digit Types Group A Signals The incoming register sends Group A signals in acknowledgment to the Group I signals sent by the outgoing register. These signals request additional information from the transmitting end. Signals A-3 and A-5 prepare the outgoing register to both receive Group B signals and send Group II signals. Systems that use 6 or 10 backward signals have significantly different meaning for the signals.
Chapter 2: Digit Handling Group B Signals The incoming register sends Group B signals after sending A-3 or A-5. The Group B signals provide information about the subscriber’s line. Table 10 shows the meanings of the Group B signals. Table 10.
Sending and Receiving Digits Sending and Receiving Digits Handling Rotary Digits Boards with VP resources can receive rotary digits but cannot dial rotary digits. Each phone is connected to a line with unique electrical characteristics, and phones send digits with slightly different timing. For the application to properly receive rotary digits from different phones, it must train to recognize the way that phone sends rotary pulses.
Chapter 2: Digit Handling Handling DTMF and MF Digits To send and receive DTMF and MF tones, use the following procedure: 1. Specify what type of digits the application receives using RHT_SET_DIGIT_MODE. Set the mode to EN_DTMF for DTMF digits or EN_MF for MF digits. You can enable rotary detection with DTMF or MF detection, but the application cannot detect both MF and DTMF digits. The two signaling methods use similar frequencies, which could lead to inaccurate signal detection. 2.
Sending and Receiving Digits Handling R2 Digits To send and receive R2 digits, use a similar procedure to handling DTMF and MF digits, except use RHT_DIAL_R2 to send R2 tones. RHT_DIAL_R2 handles all aspects of the compelled protocol. When it returns, the application can proceed to send or receive the next signal. Send R2 digits in either compelled or pulse mode. In compelled mode, RHT_DIAL_R2 sends the digit until it detects the appropriate acknowledgment from the other end.
Chapter 2: Digit Handling The following steps show how to handle R2 signaling if the application transmits a call: 1. Set RHT_SET_DIGIT_MODE to EN_R2_BACKWARD. The application receives backward signals and sends forward signals. 2. Specify the maximum time to wait for a backward digit using RHT_SET_GLOB. 3. Transmit the forward signal using RHT_DIAL_R2. RHT_DIAL_R2 terminates when it detects the backward signal. 4. Read the digit using RHT_TWAIT_DIGIT or RHT_READ_DIGIT with a digit count of 1.
Sending and Receiving Digits Example 1 shows how to send digits using RHT_DIAL_R2. Example 1. RHT_DIAL_R2 Sample Code #include “brktddm.
Chapter 2: Digit Handling Example 1. RHT_DIAL_R2 Sample Code (Continued) /* Dial R2 backward digit. Synchronous call. */ memset (&Dial, 0 sizeof (Dial)); Dial.R2Digit = 2; /* Dial R2 backward digit 2 */ Dial.
Sending and Receiving Digits Flushing the Digit Buffer Before detecting new digits from an incoming call, flush the digit buffer using RHT_FLUSH_DIGIT. In a well designed application there should never be digits remaining in the buffer after a call, since the digits are deleted after the application reads them. However, if the application does not run properly, then extra digits might remain in the buffer even after you terminate the application, remove any bugs, and run it again.
Chapter 2: Digit Handling Troubleshooting The RHT_DIAL_R2 function returns successfully when it sends the R2 signal and detects a digit of the opposite type. When RHT_DIAL_R2 returns, you should check the termination condition in RHT_GET_STATUS. Call RHT_GET_STATUS for either a VP or line device. It returns the VP termination type in the structure VPchanStatus_s, or the line termination type in RTNI_lineStatus_s.
3 T1 Networking This chapter describes T1 networking in your system environment. The T1 and NetAccess board provides two T1 trunks for high-speed communications. The T1 board provides only T1 line resources. It must be in a system with a board that provides voice processing resources over a CT bus such as the Vantage series products.
Chapter 3: T1 Networking Understanding T1 Trunks T1 trunks provide digital communications in North America, Japan, and Hong Kong. A T1 trunk carries 24, 64 Kb/s lines. An additional 8 Kb/s signal provides synchronization information. The combination of the 24 lines plus the synchronization information yields a 1.544 Mb/s signal: (24 X 64 Kb/s) + 8 Kb/s = 1,544 Kb/s or 1.544 Mb/s The T1 board provides two 24-line T1 trunks for a total of 48 T1 lines.
Understanding T1 Trunks n The Bipolar signal, also called Alternate Mark Inversion (AMI), uses 0V to represent zero and alternating positive and negative pulses to represent ones. AMI is the default line coding method for T1 boards. Figure 6 shows the three line coding methods. 1 0 1 0 1 0 0 1 1 0 0 0 1 1 1 0 0 1 Bit Stream Code +3V 0V Binary Signal (Unipolar) +1.5V 0V -1.5V Polar Signal +3V 0V -3V Bipolar (AMI - Alternate Mark Inversion) Figure 6.
Chapter 3: T1 Networking Notice that in AMI line coding, each one alternates polarity and the voltage returns to zero between pulses. Two subsequent ones with the same polarity are called a bipolar violation. Figure 7 shows a proper AMI signal and two bipolar violations. Bipolar violations could lead to crackling on the line. To check for bipolar violations, call RHT_GET_STATUS. See Troubleshooting on page 81 for more information about how to handle bipolar violations.
Understanding T1 Trunks In B8ZS (Binary 8-Zero Substitution), the transmitting end replaces a series of eight zeros with a ones-rich pattern. B8ZS coding inserts a bipolar violation as a signal to the receiving end to reinsert the original zeros. Figure 8 shows the B8ZS replacement patterns. Notice that the replacement pattern that is inserted depends on the polarity of the preceding one.
Chapter 3: T1 Networking Organizing the T1 Data Organizing Data into T1 Frames The T1 line carries data from 24 channels over two pairs of wires (one to transmit data and one to receive it). At the transmitting end, a multiplexer receives a 64 Kb/s signal from each of the 24 channels. It interleaves 8 bits of data from each channel into a single serial stream of data. To carry 24 64 Kb/s channels plus an 8 Kb/s signal, the T1 line runs at 1.544 Mb/s.
Understanding T1 Trunks A single bit at the beginning of each frame contains synchronization information. This bit is also called the F-bit or framing bit. Figure 10 shows a single T1 frame with the 24 timeslots and a single F-bit. The 24 64 Kb/s lines plus the F-bit make up a DS1 signal. DS1 125 S Line 0 -Line 23 22 23 F 0 1 2 3 20 21 22 23 F 0 1 Line 0 -Line 23 00101101 8-bit timeslot Figure 10.
Chapter 3: T1 Networking Organizing Frames into D3/D4 and ESF Superframes The 24-timeslot frames are grouped into one of two types of superframes: D3/D4 or ESF. D3/D4 Superframes D3/D4 superframes consist of 12 frames. The framing bits at the beginning of each frame form the sequence: 100011011100. For example, the F-bit for the first frame is a 1, for the second frame it is a 0, and so on through the 12-bit sequence for the 12 frames, as shown in Figure 11.
Understanding T1 Trunks ESF Superframe Extended superframes (ESF) consist of 24 frames. Unlike D3/D4 frames, the F-bits are not all used for synchronization. Only the F-bits for frames 3, 7, 11, 15, 19, and 23 carry synchronization information. These follow the pattern: 001011. For example, the F-bit for the fourth frame is a 0, and for the eighth frame it is a 0, and for twelfth frame it is a 1, and so on through the sequence, as shown in Figure 12.
Chapter 3: T1 Networking Figure 12 shows a single timeslot within an ESF superframe. Each timeslot in the superframe follows the same pattern for signaling bits. Bits in timeslot 0 F 0 1 2 3 4 5 6 7 Frame number 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Figure 12. Data CRC Data 0 Data CRC Data 0 Data CRC Data 1 Data CRC Data 0 Data CRC Data 1 Data CRC Data 1 A Through timeslot 23 B C C D D An ESF Superframe T1 devices support both D3/D4 and ESF framing.
Configuring the T1 Environment Configuring the T1 Environment Configuring the T1 environment involves the following steps: 1. Setting the clock 2. Loading the line protocol 3. Configuring the carrier Setting the Clock T1and E1 boards must have their clock synchronized with the network and with other boards connected in a CT bus. In a CT bus, one board drives the clock and all other boards retrieve the clock from the bus.
Chapter 3: T1 Networking Loading the Line Protocol The line protocols determine how the central office (CO) and customer premise equipment (CPE) communicate using the A and B signaling bits. Both ends must use the same protocol in order to communicate properly. The most common protocols are Wink Start, Double Wink Start, Immediate Start, Loop Start, and Ground Start.
Configuring the T1 Environment Table 11. Protocol File Names Protocol File name Wink Start wink.mto Double Wink Start wink.mto (same as wink start) Immediate Start imdt.mto Loop Start stlpst.mto and colpst.mto Ground Start stgndst.mto and cogndst.mto The Immediate Start, Wink Start, and Double Wink Start protocols are symmetrical. The CO and CPE transmit identical bit patterns for each line state. Your application uses the same protocol file whether it functions as a CPE or emulates a CO.
Chapter 3: T1 Networking Example 2 shows how to load the Wink Start protocol using RHT_LOAD_PROTOCOL. Example 2. RHT_LOAD_PROTOCOL Sample Code #include “brktddm.h” int main(int argc, char **argv) { BRKT_HANDLE BoardHandle; FILE* ProtocolFile; BOOLEAN IoctlResult; BRKT_SIZE_T BytesReturned; BRKT_SIZE_T FileSize, BytesRead; USHORT* pProtocolBuffer; struct LoadProtocol_s Protocol; BoardHandle = BrktOpenDevice (BRKT_DEVICE_T1_BOARD, 0); /* Open Protocol File */ ProtocolFile = fopen ("WINK.
Configuring the T1 Environment Example 2. RHT_LOAD_PROTOCOL Sample Code (Continued) memset (&Protocol, 0, sizeof (Protocol)); Protocol.Length = FileSize; Protocol.Protocol = pProtocolBuffer; Protocol.
Chapter 3: T1 Networking Configuring the Carrier The carrier parameters determine what framing methods, line coding methods, and other parameters the board uses to send and receive data. The parameters you set must match those of the carrier. There are several ways to configure carrier parameters. Configure all channels on a given trunk to use the same values, using CONFIG_CARRIER.
Configuring the T1 Environment Configuring Debounce When debouncing is enabled, the board waits for the signaling bits to be stable before relaying the information to the drivers. Waiting for the bits to stabilize prevents errors from being handled as if they were valid signals. Debouncing, which is also called deglitching, should always be enabled. The 6 to 9 ms wait is less than the minimum time used for signal recognition protocols, so enabling debouncing should not decrease performance.
Chapter 3: T1 Networking Configuring the Line State When loaded, each protocol automatically transmits the bit pattern corresponding to the idle state. The drivers ignore the ‘Hook’ field in the carrier parameters. Transmitting the proper line state is one reason to load the protocols before configuring the carrier parameters. If you configure the carrier first, the board might transmit an invalid hook pattern on the line. This invalid signal could trigger alarms at the CO.
Configuring the T1 Environment Example 3 shows how to configure the first trunk of the first T1 board for D3/D4 framing, B8ZS coding, and default values for all other fields. Example 3. CONFIG_CARRIER Sample Code #include “brktddm.
Chapter 3: T1 Networking Example 3.
Handling Incoming and Outgoing Calls Handling Incoming and Outgoing Calls Processing Calls Call processing involves setting up and tearing down calls. Calls have to be processed before they are connected, so be sure to verify call processing in the early stages of development. Table 12 shows the functions used in sending and receiving calls over a T1 line. These functions are the same as those used in analog telephony.
Chapter 3: T1 Networking Handling Incoming Calls Handling incoming calls involves the following steps: n n n n n n Detect an incoming call Detect digits Send control tones Answer the call Monitor for a disconnect Terminate the call Detecting an Incoming Call The application calls RHT_WAIT_LINE_ON when it is ready to receive a call. This function waits until it receives a seizure or a ring, then sends any acknowledgment signals required by the protocol.
Handling Incoming and Outgoing Calls The function automatically sends any acknowledgments required by the protocol. This serves two purposes. First, it isolates the application from the protocol. You can communicate with different carriers simply by switching protocol files rather than making changes to the application. Second, it improves timing. In a heavily loaded system, threads and processes can be preempted at almost any time, and it might take several seconds before they can run again.
Chapter 3: T1 Networking Detecting Digits Once the application acknowledges the incoming call, the CO usually sends call setup digits. In T1 applications, the CO generally sends call setup information using MF or DTMF digits, although Brooktrout boards with voice processing capabilities recognize rotary, DTMF, MF, or R2 digits. Before detecting new digits from an incoming call, flush the digit buffer using RHT_FLUSH_DIGIT.
Handling Incoming and Outgoing Calls Sending Control Tones In the Wink Start, Double Wink Start, or Immediate Start protocols, your application emulates both the receiving end CO and subscriber. The CO portion sends control tones such as ringback and busy to indicate the status of the call to the other end. In Loop Start or Ground Start protocols, your system acts only as a subscriber and does not send control tones.
Chapter 3: T1 Networking Answering Calls Answer calls detected by RHT_WAIT_LINE_ON using RHT_OFF_HOOK or RHT_SEIZE_LINE. Only the underlined functions are interchangeable, so all discussion of RHT_OFF_HOOK also applies to RHT_SEIZE_LINE. When RHT_OFF_HOOK answers a call, it automatically transmits the appropriate answer supervision signal towards the switch directly connected to your system.
Handling Incoming and Outgoing Calls In Wink Start, Double Wink Start, and Immediate start protocols, the audio path is established soon after the CO sends digits so the remote end can hear the control tones. With the audio path established, the remote end will also hear any files the application plays even if the application fails to call RHT_OFF_HOOK. If the CO does not receive the answer signal, however, it times out within two to four minutes and terminates the call.
Chapter 3: T1 Networking Monitoring for Disconnect Whether you received or originated the call, you should continuously monitor the line for disconnect using RHT_WAIT_LINE_OFF. The sooner you detect the disconnect, the sooner the line is free for new calls, allowing you to reach more people in the same amount of time without increasing the number of lines. RHT_WAIT_LINE_OFF returns successfully when it detects a disconnect or returns an error if it detects other conditions.
Handling Incoming and Outgoing Calls With ‘LineTerm0’ set, the T1 driver automatically runs RHT_WAIT_LINE_OFF. It continues monitoring the line until the VP driver sends a signal that the VP function terminated or until the T1 driver detects a disconnect. When it detects a disconnect, the T1 driver signals the VP driver to terminate the function. When the VP function terminates, check the condition that caused termination using RHT_GET_STATUS.
Chapter 3: T1 Networking Terminating an Inbound Call Terminate calls using RHT_ON_HOOK or RHT_DISCONNECT. These functions are interchangeable, so all discussion of RHT_DISCONNECT also applies to RHT_ON_HOOK. RHT_DISCONNECT transmits a disconnect (idle) pattern for the time specified by RDG_LOCAL_IDLE_DUR. It then waits for the remote end to disconnect for a time specified by RDG_REMOTE_IDLE_TIMEOUT.
Handling Incoming and Outgoing Calls If your end disconnects first, RHT_DISCONNECT waits for the other party to disconnect for a time specified by RDG_REMOTE_TIMEOUT, which is usually infinite. However, the CO the other party is connected to usually times out in one to four minutes if the other party does not disconnect. When it times out, the CO transmits a disconnect signal on its own.
Chapter 3: T1 Networking Handling Outbound Calls Handling outbound calls involves the following steps: n n n n n Seize a line Dial out Monitor the line for answer Process the call Terminate the call Seizing a Line Seize an idle line using either RHT_SEIZE_LINE or RHT_OFF_HOOK. These functions are interchangeable, so all discussion of RHT_SEIZE_LINE also applies to RHT_OFF_HOOK.
Handling Incoming and Outgoing Calls Only Wink Start and Double Wink Start protocols require a wink to acknowledge the line seizure. A wink is on hook/off hook/on hook sequence where the duration of the off hook must be within a range defined by RDG_REMOTE_MIN_WINK and RDG_REMOTE_MAX_WINK. This wink must be sent within a time specified by RDG_REMOTE_ACK_TIMEOUT after the seizure. If RHT_SEIZE_LINE does not receive an appropriate wink, it abandons the call, sends an idle pattern, and returns an error.
Chapter 3: T1 Networking Dialing Out After the application seizes the line, it dials the appropriate number using RHT_DIAL. It can dial out using either MF or DTMF tones. While dialing, the application monitors the line by setting field in the RhtDialDigit_s structure as described in Monitoring for Disconnect on page 64. If the function returns successfully, the application monitors the call for answer. If the function returns T_RHT_LINEOFF, then the function terminated because of a line condition.
Handling Incoming and Outgoing Calls RHT_WAIT_ANSWER only monitors for answer based on the answer supervision signal. If the application does not use a protocol that sends the answer supervision signal, such as Loop Start or Ground Start, or if the application needs more information about the call than whether it was answered, use RHT_START_PCPM. RHT_START_PCPM accesses the Programmable Call Progress Monitoring (PCPM) algorithm that runs on the board’s DSP.
Chapter 3: T1 Networking Example 4 shows the steps involved in using RHT_START_PCPM to detect answer. Example 4. Monitoring for Answer 1. The application starts RHT_START_PCPM with VPstartStop_s fields ‘LineTerm0’ and ‘Timeout’ set. 2. When RHT_START_PCPM returns, the application calls RHT_GET_STATUS for the VP device and checks VPchanStatus_s.TermType. 3. If VPchanStatus_s.TermType contains T_RHT_PCPM, then RHT_START_PCPM determined the line state. The field VPchanStatus_s.
Handling Incoming and Outgoing Calls Transferring Calls You can transfer calls on digital lines if the equipment connected to your system supports call transfers. Most COs do not support call transfer if your application is emulating another CO. However, if your application is emulating customer equipment, the CO might allow call transfers if you have the service enabled.
Chapter 3: T1 Networking Sending and Detecting Winks The Wink Start and Double Wink Start protocols use wink signals as part of their call setup process. In order to perform a wink, the channel must be in the on hook state, transmitting the appropriate bit pattern for that protocol. An off hook pattern is transmitted for the duration specified by RDG_LOCAL_WINK_DUR, followed by the on hook pattern for the duration specified by RDG_LOCAL_WINK_GUARD_TIME.
Using Internal Signaling Streams Using Internal Signaling Streams The T1 board has internal streams that hold data received on the line. The board holds data for lines 0 through 23 in internal streams 16 and 18, timeslots 0 through 23. It holds signaling bits (ABCD) for lines 0 through 23 in internal timeslots 17 and 19, timeslots 0 through 23. Access the signaling bits using the SET_OUTPUT and SAMPLE_INPUT MVIP functions.
Chapter 3: T1 Networking Testing the T1 Setup Testing the Installation Use the samples that came with your software to test your boards, drivers, and installation before you write your application. You can use the provided source code to help develop your application. The samples are located in subdirectory \RHT\SAMP\T1. The most useful samples are: T1INIT Sets the clock, initializes carrier parameters and checks carrier status.
Testing the T1 Setup CONN
Chapter 3: T1 Networking Testing the Application There are four basic ways of testing your application: n n n n Using AccuSpan Placing calls over a live T1 line Using a T1 simulator Connecting trunks A and B Using AccuSpan AccuSpan is the best way to test the overall robustness and fault tolerance of your system. AccuSpan is a DOS-based utility that gives you full control over the carrier configuration, alarms, and bit patterns sent and received. It can also receive or generate calls.
Testing the T1 Setup Placing Calls over a T1 Line Testing your application over a live T1 line gives you a controlled environment and requires no special knowledge of the protocols. If the application passes a few tests such as making simultaneous calls or consecutive calls on the same line, the application will probably work for real calls. However, when testing the application over a real T1 line, the telephone company controls the environment so there is little chance to test error conditions.
Chapter 3: T1 Networking Connecting Trunks A and B When you connect trunks A and B, you receive data on one trunk that you send from the other trunk. Using this configuration, you can test samples that complement your application or use the samples that came with your software. Using either your own or provided samples, you can test inbound and outbound call processing, send events out of order to see how the application reacts, and stress test the application.
Troubleshooting Troubleshooting If a line function returns an error code, use BrktGetLastError () to determine what caused the error. The two most common errors are lost synchronization or a protocol error. n In a synchronization error, BrktGetLastError(DeviceHandle) returns BRKT_ERROR_CODE(UNEXP_NET_ERROR) n In a protocol error, BrktGetLastError(DeviceHandle) returns BRKT_ERROR_CODE(IO_DEVICE) Handling Synchronization Errors When a trunk loses synchronization, any bits the trunk receives are invalid.
Chapter 3: T1 Networking Yellow The CO sends a yellow alarm to indicate that it is not receiving a valid signal from your system. If the T1 board receives a yellow alarm, then the connection from the remote end to the local end is good, and the problem is in the data transmitted to the remote end from the local end. One reason for a yellow alarm is faulty wiring. The connection uses one pair of wires to transmit data and one pair to receive data.
Troubleshooting Bipolar Violation In AMI line coding, ones alternate positive and negative polarity, as described in Transmitting Digital Data on page 38. A bipolar violation occurs when a one is the same polarity as the preceding one. Bipolar violations indicate that the application and the remote end are not using the same line coding method, or the signal is too weak for the board to detect it properly.
Chapter 3: T1 Networking Handling Protocol Errors A protocol error occurs when the signaling bits read from the line don’t match what was expected at that time. For example, a function detects call answer while monitoring for disconnect. An unexpected event is not necessarily an error, since there are times when more than one event could happen. However, the driver returns an error if any event other than the one the function is waiting for takes place.
Troubleshooting BAD_STATE_ERROR A BAD_STATE_ERROR indicates that the function could not execute because the line was in the wrong state for that function. For example, ‘TermType’ would report a bad state error if the application tries to wait for a call or send a wink when the line is not idle. In a bad state error, the CO's interpretation of the previous signal on the line probably didn't match your application's interpretation.
Chapter 3: T1 Networking SIGNALING_BIT_ERROR A signaling bit error occurs when a bit pattern that does not belong in the protocol was present on the line. The invalid bit pattern must be present for longer than the debouncing and deglitching timings in order to generate this error. If you receive a signaling bit error, compare the bit pattern in RTNI_lineStatus.RawPattern to the ones expected by the protocol to be sure your application and the CO are using the same protocol.
Troubleshooting In ESF framing, bit A generally equals C and B equals D. So, if you want to transmit a pattern AB=10, set CD=AB and transmit the following: ABCD=ABAB=1010=0x0A Function ‘Function’ shows which function is currently running, or which function terminated last. You need to know the function name in order to understand the terminating code listed in ‘TermType’. The ‘Function’ field is particularly useful in finding out the cause of BRKT_ERROR_CODE(BUSY).
Chapter 3: T1 Networking Using Loopbacks Loopback configurations loop data back to where it originated. These configurations help troubleshoot where errors occur. There are several forms of loopbacks, depending on what you want to test. Set software configurable loopbacks using CONFIG_CARRIER as described in Configuring the Carrier on page 52. There are two loopback modes that you specify with CONFIG_CARRIER: n Test whether the board’s receiver and transmitter work properly using a local loopback.
Troubleshooting For other loopback modes, disable both local and remote loopbacks in CONFIG_CARRIER. n Test the cabling between the CSU and either the board or the CO using a CSU loopback. In this mode, the CSU immediately transmits all data it receives back to the CO or board, depending on which end transmitted the data. To do a CSU loopback, follow instructions from your CSU manufacturer. Figure 15 shows two CSU loopbacks: one looping data back to the CO and the other looping data back to the board.
4 E1 Networking This chapter describes E1 networking in your system environment. The E1 board (RTNI-2E1 or NetAccess E1 board) provides two E1 trunks for high-speed communications. The E1 board provides only E1 line resources. It must be in a system with a board that provides voice processing resources over a CT bus such as the Vantage series products.
Chapter 4: E1 Networking Understanding E1 Trunks E1 trunks provide digital communications in South America, Europe, and Asia. An E1 trunk carries 30 64 Kb/s lines. Two additional 64 Kb/s lines provide signaling information. The combination of the 30 lines and the signaling channels yields a 2.048 Mb/s signal: 32 x 64 Kb/s = 2048 Kb/s or 2.048 Mb/s The E1 board provides two 30-line E1 trunks for a total of 60 E1 lines.
Understanding E1 Trunks To check for bipolar violations, call RHT_GET_STATUS. See Troubleshooting on page 134 for more information about how to handle bipolar violations. 0 0 1 1 0 1 0 0 1 r Violation Figure 17. A Bipolar Violation in AMI Coding In AMI signaling, a long series of zeros is represented by a constant 0V signal. The two ends can lose timing if there is no signal on the line to synchronize them.
Chapter 4: E1 Networking Organizing the E1 Data Organizing Data into E1 Frames The E1 line carries data from 30 data channels plus two channels for framing and signaling over two pairs of wires. At the transmitting end, a multiplexer receives a 64 Kb/s signal from each the 30 lines. It interleaves 8 bits of data from each data channel plus signaling and framing information into a single serial stream of data.
Understanding E1 Trunks The transmitting end formats the E1 data into frames so the receiving end can interpret the data. One frame consists of 32 8-bit timeslots. Timeslots 0 and 16 are reserved for framing and signaling information. The remaining 30 timeslots each carry 8 bits of information for a single E1 channel. Timeslots 1RDG_15 carry data for channels 0-14, and timeslots 17-31 carry data for channels 15-29, as shown in Figure 19.
Chapter 4: E1 Networking Organizing Frames into CEPT Multiframes The E1 frames are organized into CEPT multiframes. Each multiframe consists of 16 E1 frames, as Figure 20 shows. Within the multiframes, timeslots 0 and 16 of each frame carry a specific pattern of information. CEPT Multiframe 0 1 2 3 4 5 6 7 0 1 2 28 29 30 31 8 9 10 11 12 13 14 15 01100111 8-bit timeslot E1 Frame 125 S Figure 20. A CEPT Multiframe Timeslot 0 Timeslot 0 carries framing and CRC information.
Understanding E1 Trunks Table 17.
Chapter 4: E1 Networking CRC The CRC process treats the bits from one sub-multiframe as a single binary number. It performs a calculation and transmits the remainder in the first bit of each odd frame in the following subframe. The receiving end performs the same calculation and compares its results to the transmitted CRC from the remote end. If the two ends calculate the same value, the lines are communicating properly.
Understanding E1 Trunks Timeslot 16 Timeslot 16 of each frame carries the A, B, C, and D signaling bits for each of the 30 data channels. These bits carry information about the line, such as on hook or off hook status. The first four bits of timeslot 16 carry signaling bits for one channel, n, and the second four bits carry signaling bits for channel n + 15. For example, timeslot 16 of frame 1 carries signaling bits for channels 0 and 15 (Timeslots 1 and 17 respectively).
Chapter 4: E1 Networking Configuring the E1 Environment Configuring the E1 environment involves the following steps: 1. Set the clock. 2. Load the line protocol. 3. Configure the carrier. Setting the Clock T1 and E1 boards must have their clock synchronized with the network and with other boards connected in a CT bus. In a CT bus, one board drives the clock and all other boards retrieve the clock from the bus.
Configuring the E1 Environment Loading The Line Protocol The line protocols determine how the central office (CO) communicates with the customer premise equipment (CPE). Both ends must use the same protocol in order to communicate properly. E1 boards support the R2-CCITT standard protocol, and variations for China, Brazil, and Central Europe. The protocol files convert the API functions such as RHT_ON_HOOK and RHT_OFF_HOOK into the appropriate signaling patterns and timing for the protocol.
Chapter 4: E1 Networking Table 20. Protocol File Names Protocol File name R2-CCITT r2_ccitt.mto R2-CCITT (Chinese) r2_china.mto R2-CCITT (Brazilian) r2_brz.mto R2-CCITT (Central Europe) r2_eur.mto The R2-CCITT protocols are symmetrical. The CO and CPE transmit identical bit patterns for each line state. Your application uses the same protocol whether it functions as a CPE or emulates a CO.
Configuring the E1 Environment Example 5 shows how to load the R2-CCITT protocol using RHT_LOAD_PROTOCOL. Example 5. RHT_LOAD_PROTOCOL Sample Code #include “brktddm.h” int main(int argc, char **argv) { BRKT_HANDLE BoardHandle; FILE* ProtocolFile; BOOLEAN IoctlResult; BRKT_SIZE_T BytesReturned; BRKT_SIZE_T FileSize, BytesRead; USHORT* pProtocolBuffer; struct LoadProtocol_s Protocol; BoardHandle = BrktOpenDevice (BRKT_DEVICE_E1_BOARD, 0); /* Open Protocol File */ ProtocolFile = fopen ("R2_CCITT.
Chapter 4: E1 Networking Example 5. RHT_LOAD_PROTOCOL Sample Code (Continued) memset (&Protocol, 0, sizeof (Protocol)); Protocol.Length = FileSize; Protocol.Protocol = pProtocolBuffer; Protocol.
Configuring the E1 Environment Configuring the Carrier Configure the carrier parameters for your line using the function CONFIG_CARRIER, or configure only line coding and CRC using the Configuration Wizard. Using CONFIG_CARRIER, you configure all channels on a given trunk to use the same values. To configure the ADI, invert, or loopback parameters separately for individual channels, use CONFIG_CHANNEL and RHT_CONFIG_CHANNEL.
Chapter 4: E1 Networking Configuring Debounce When debouncing is enabled, the board waits for the signaling bits to be stable before relaying the information to the devices. Waiting for the bits to stabilize prevents errors from being handled as if they were valid signals. Debouncing, which is also called deglitching, should always be enabled. The ‘6’ to ‘9’ msec wait is less than the minimum time used for signal recognition protocols, so enabling debouncing should not impact performance.
Configuring the E1 Environment Configuring the Hook State When loaded, each protocol automatically transmits the bit pattern corresponding to the idle state. The devices ignore the ‘Hook’ field in the carrier parameters. Transmitting the proper hook state is one reason to load the protocols before configuring the carrier parameters. If you configure the carrier first, the board might transmit an invalid hook pattern on the line. This invalid signal could trigger alarms at the CO.
Chapter 4: E1 Networking Example 6. CONFIG_CARRIER Sample Code #include “brktddm.
Configuring the E1 Environment Example 6.
Chapter 4: E1 Networking Handling Incoming and Outgoing Calls Processing Calls Call processing involves setting up and tearing down calls. Calls have to be processed before they go through, so be sure to verify call processing in the early stages of development. Table 21 shows the functions used in sending and receiving calls over an E1 line. These functions are the same as those used in analog telephony.
Handling Incoming and Outgoing Calls Handling Incoming Calls Handling incoming calls involves the following steps: 1. Detect an incoming call. 2. Handle call setup signaling. 3. Send control tones. 4. Answer the call. 5. Process the call, while monitoring for disconnect. 6. Terminate the call. You can block a channel at any time to prevent further incoming calls. Detecting an Incoming Call When the application is ready to receive a call, it calls RHT_WAIT_LINE_ON.
Chapter 4: E1 Networking RHT_WAIT_LINE_ON automatically sends any acknowledgments required by the protocol, which serves two purposes: n First, it isolates the application from the protocol. You can communicate with different carriers simply by switching protocol files rather than making changes to the application. n Second, it improves timing. In a heavily loaded system, threads and processes can be preempted at almost any time, and it might take several seconds before they can run again.
Handling Incoming and Outgoing Calls Detecting Digits When an application receives an incoming call, it generally receives information about the call setup from the originating end. The method used to send these digits depends on the way the CO has configured the line. Most COs use R2 compelled signaling, but some use DTMF or MF tones to send digits. Despite the name, there is no association between the R2-CCITT line signaling protocols and the R2 inter-register signaling.
Chapter 4: E1 Networking Sending Control Tones In R2-CCITT protocols, your application emulates both the receiving end CO and subscriber. The CO portion sends control tones such as ringback and busy to indicate the status of the call to the other end. When a subscriber receives a call, the CO emulation part of the application should determine the status of the line and send either a busy or ringback tone back to the caller. It should also send the hangup tone when the subscriber hangs up.
Handling Incoming and Outgoing Calls Answering Calls Answer calls detected by RHT_WAIT_LINE_ON using RHT_OFF_HOOK or RHT_SEIZE_LINE. These functions are interchangeable, so all discussion of RHT_OFF_HOOK also applies to RHT_SEIZE_LINE. When RHT_OFF_HOOK answers a call, it automatically transmits the appropriate answer supervision signal towards the switch directly connected to your system.
Chapter 4: E1 Networking In the early stages of development, it might be hard to tell if the application fails to call RHT_OFF_HOOK. The audio path is established soon after the CO sends digits so the remote end can hear the control tones. With the audio path established, the remote end will also hear any files the application plays even if the application fails to call RHT_OFF_HOOK. If the CO does not receive the answer signal, however, it times out within two to four minutes and terminates the call.
Handling Incoming and Outgoing Calls Monitoring For Disconnection Whether you received or originated the call, you should continuously monitor the line for disconnect using RHT_WAIT_LINE_OFF. The sooner you detect the disconnect, the sooner the line is free for new calls, allowing you to reach more people in the same amount of time without increasing the number of lines. RHT_WAIT_LINE_OFF returns successfully when it detects a disconnect or returns an error if it detects other conditions.
Chapter 4: E1 Networking This second approach is easier to implement because it does not involve separate threads. However, RHT_WAIT_LINE_OFF only runs when a VP function is running. If the application spends long periods of time performing non-VP functions, a disconnect would not be reported until the next VP or line function runs. This could keep the line busy longer than necessary. If this delay is not acceptable, then use a separate thread to monitor the line while no VP functions are running.
Handling Incoming and Outgoing Calls Terminating an Inbound Call Terminate calls using RHT_ON_HOOK or RHT_DISCONNECT. These functions are interchangeable, so all discussion of RHT_DISCONNECT also applies to RHT_ON_HOOK. RHT_DISCONNECT transmits a disconnect (idle) pattern for the time specified by RDG_LOCAL_IDLE_DUR. It then waits for the remote end to disconnect for a time specified by RDG_REMOTE_IDLE_TIMEOUT.
Chapter 4: E1 Networking If your end disconnects first, RHT_DISCONNECT waits for a duration specified by RDG_REMOTE_IDLE_TIMEOUT for the other party to disconnect. This parameter is set to infinite by default. However, the CO the other party is connected to usually times out in one to four minutes if the other party does not disconnect. When it times out, the CO transmits a disconnect signal on its own.
Handling Incoming and Outgoing Calls If you are using R2 inter-register signaling and you use RHT_DISCONNECT to terminate a call, the protocol sends a Clear Back signal to disconnect. This signal uses the same bit pattern as the Seizure Acknowledgment signal (A=1, B=1). The far end can not distinguish between the two signals, so the Clear Back has no effect if the application called RHT_DISCONNECT from the seizure acknowledgment state.
Chapter 4: E1 Networking Blocking a Circuit It might be necessary for an application to stop receiving calls, for example if the system is down for maintenance. In an analog environment, the system can simply ignore incoming calls. In an E1 environment using R2 line signaling, however, ignoring calls could lead to problems with the CO. When the far end sends a Seizure signal, the application responds with a Seizure Acknowledgment.
Handling Incoming and Outgoing Calls Handling Outbound Calls Handling outbound calls involves the following steps: 1. Seize a line. 2. Send call-setup information (R2 Inter-register Signaling or other proprietary methods). 3. Monitor the line for answer. 4. Process the call. 5. Terminate the call. Seizing a Line Seize an idle line using either RHT_SEIZE_LINE or RHT_OFF_HOOK. These functions are interchangeable, so all discussion of RHT_SEIZE_LINE also applies to RHT_OFF_HOOK.
Chapter 4: E1 Networking Glare Resolution If the line is not idle when the application calls RHT_SEIZE_LINE, BrktGetLastError (DeviceHandle), returns BRKT_ERROR_CODE(IO_DEVICE). See Troubleshooting on page 134 for more information on how to handle the error. It is possible for the application to try to seize the line as the CO tries to send a call. In this situation, called a glare, RHT_SEIZE_LINE returns an error but does not set the line back to idle.
Handling Incoming and Outgoing Calls Monitoring For Call Answer Determine the status of a call using either RHT_START_PCPM or RHT_WAIT_ANSWER. RHT_WAIT_ANSWER returns successfully if it detects an answer pattern or returns an error if it detects any other pattern such as a disconnect or bit errors. If RHT_WAIT_ANSWER does not detect a bit change, it continues running until the application terminates it through a call to RHT_STOP.
Chapter 4: E1 Networking The main reason to run PCPM algorithms in R2 systems would be detecting special tones such as Fax tones or operator intercept not accompanied by an R2 register signal. However, proprietary protocols running on E1 lines might require PCPM. RHT_START_PCPM only monitors audible signals on the line and runs independently of the type of line being used. Since PCPM uses only sound or silence to determine the call status, it cannot be absolutely accurate in detecting answer.
Handling Incoming and Outgoing Calls The following example shows the steps involved in using RHT_START_PCPM to detect answer. 1. The application starts RHT_START_PCPM with VPstartStop_s fields ‘LineTerm0’ and ‘Timeout’ set. 2. When RHT_START_PCPM returns, the application calls RHT_GET_STATUS for the VP device and checks VPchanStatus_s.TermType. Interpreting Results 1. If VPchanStatus_s = T_RHT_PCPM, then RHT_START_PCPM determined the line state. The VPchanStatus_s.
Chapter 4: E1 Networking Using Internal Signaling Streams The E1 board has internal streams that hold data received on the line. Streams 17 and 19 hold signaling bits from trunks A and B, respectively. Streams 16 and 18 hold data from trunks A and B, respectively. Within streams 17 and 19, 8-bit timeslots hold the signaling data.
Testing the E1 Setup Testing the E1 Setup Testing the Installation Use the samples that came with your software to test your boards, devices, and installation before you write your application. You can use the provided source code to help develop your application. The samples are located in subdirectory \RHT\SAMP\E1. The most useful samples are: E1INIT Sets the clock, initializes carrier parameters, and checks carrier status.
Chapter 4: E1 Networking DIALR2 [line] [digits] Dials R2 digits while monitoring for a disconnect on the line (0 by default). BSTAT Queries carrier status. BINFO Displays board and device information. CONN Makes MVIP connections. Usage: Conn
Testing the E1 Setup Testing the Application There are four basic ways of testing your application: n n n n Using AccuSpan Placing calls over a live E1 line Using an E1 simulator Connecting trunks A and B (Loopback) Using AccuSpan AccuSpan is the best way to test the overall robustness and fault tolerance of your system. AccuSpan is a command line utility that gives you full control over the carrier configuration, alarms, and bit patterns sent and received. It can also receive or generate calls.
Chapter 4: E1 Networking Placing Calls over an E1 Line Testing your application over a live E1 line gives you a controlled environment and requires no special knowledge of the protocols. If the application passes a few tests such as making simultaneous calls or consecutive calls on the same line, the application will probably work for real calls. However, when testing the application over a real E1 line, the telephone company controls the environment so there is little chance to test error conditions.
Testing the E1 Setup Connecting Trunks A and B When you connect trunks A and B, you receive data on one trunk that you send from the other trunk. Using this configuration, you can test samples that compliment your application or use the samples that came with your software. Using either your own or provided samples, you can test inbound and outbound call processing, send events out of order to see how the application reacts, and stress test the application.
Chapter 4: E1 Networking Troubleshooting If a line function returns an error code, use BrktGetLastError () to determine what caused the error. The two most common errors are lost synchronization or a protocol error. 134 n In a synchronization error, BrktGetLastError () returns BRKT_ERROR_CODE (UNEXP_NET_ERROR). n In a protocol error, BrktGetLastError() returns BRKT_ERROR_CODE(IO_DEVICE).
Troubleshooting Handling Synchronization Errors When a trunk loses synchronization, any bits the trunk receives are invalid. After a loss of synchronization, terminate all calls and check the trunk status using QUERY_CARRIER_STAT. When the trunk is synchronized with the network, the application can proceed. QUERY_CARRIER_STAT returns information about the current alarm and synchronization status of the line in the structure RTNI_E1carrierStatus_s.
Chapter 4: E1 Networking Sync The synchronization field indicates whether or not the network and E1 board are synchronized. If they are not synchronized, it means that the board is not receiving framing information. This can happen if there is no signal on the line, if the board is receiving an invalid or test signal, or if the framing mode is not set properly. Be sure that you have set the appropriate clock mode, CRC mode, and framing method, as described in Configuring the E1 Environment on page 100.
Troubleshooting Handling Protocol Errors A protocol error occurs when the signaling bits read from the line don’t match what was expected at that time. For example, a function detects call answer while monitoring for disconnect. An unexpected event is not necessarily an error, since there are times when more than one event could happen. However, the software returns an error if any event other than the one the function is waiting for takes place.
Chapter 4: E1 Networking BAD_STATE_ERROR A BAD_STATE_ERROR indicates that the function could not execute because the line was in the wrong state for that function. For example, ‘TermType’ would report a bad state error if the application tries to wait for a call when the line is not idle. In a bad state error, the CO's interpretation of the previous signal on the line probably didn't match your application's.
Troubleshooting RawPattern ‘RawPattern’ contains the received and transmitted signaling bits. The upper byte contains the received pattern while the lower byte contains the transmitted pattern. Each of these bytes contains only four significant bits. These bits contain the value for signaling bits A, B, C, and D. Bit A is the most significant bit, while bit D is the least significant bit. For example, if ‘RawPattern’ contains 0x0F05, then the receive pattern is 0x0F and the transmit pattern is 0x05.
Chapter 4: E1 Networking Using Loopbacks Loopback configurations loop data back to where it originated. These configurations help troubleshoot where errors occur. There are several forms of loopbacks, depending on what you want to test. Set software loopbacks using CONFIG_CARRIER as described in Configuring the Carrier on page 105. There are two software loopbacks: n Test whether the board’s receiver and transmitter work properly using a local loopback.
Troubleshooting Test individual regions of the cabling using a cable to connect transmit and receive leads at points along a trunk. This mode loops data back to either the board or CO depending on which end transmits the data and how you set up the loopback. Figure 23 shows a loopback using a cable to physically connect the transmit and receive leads along trunk A. Board CO Data stream to trunk A Data stream from trunk A Figure 23.
5 MVIP-90 This chapter describes how to develop applications for systems using the Multi-Vendor Integration Protocol (MVIP). It discusses the MVIP-90 software and hardware standard used by the MVIP-compliant RDSP, Vantage VPS, Vantage VRS, and RTNI boards.
Chapter 5: MVIP-90 Defining MVIP-90 Multi-Vendor Integration Protocol (MVIP) provides communications standards that allow boards in a PC to communicate with each other. MVIP works independently of other computer buses. It can work in a PC, between PCs, in a PBX, and in other computer-based hardware. The MVIP bus provides a way to interconnect telephony resources, even if those resources are provided by different vendors.
Working with MVIP-90 Data Streams Working with MVIP-90 Data Streams Understanding MVIP-90 Architecture The MVIP-90 bus supports eight bidirectional 2.048 Mb/s streams for a total of 16 data streams, as shown in Figure 24. These streams carry data to and from MVIP resources. Each MVIP stream has 32 64-Kb/s time division multiplexed slots, each of which supports a single resource (32 slots x 64 Kb/s/slot = 2.048 Mb/s). Each slot within a specific stream is called a timeslot.
Chapter 5: MVIP-90 Boards with switching capability such as the RTNI or Vantage PCI series boards are not assigned to a particular stream. These boards can place or retrieve data on any stream or timeslot. An application specifies the streams and timeslots to switch data between resources. The RTNI or Vantage PCI switch block then performs the switching.
Working with MVIP-90 Data Streams Numbering MVIP Streams Of the 16 data streams, the first eight are input and the second eight are output. Together, the first input (0) and first output (8) streams form the bidirectional stream 0, as shown in Figure 25. The second input (1) and second output (9) form the bidirectional stream 1, and so on through the eighth input (7) and eighth output (15), which form the bidirectional stream 7.
Chapter 5: MVIP-90 Understanding Framing Data in DSix or DSox streams are formatted into frames. Each frame contains 8 bits of information for each of the 32 timeslots, as shown in Figure 26. Each 8 bit timeslot has a period of 125 µs, for a total of 8000 timeslots per second (8 bits/timeslot x 8000 timeslots/second = 64 Kb/s). . Frame 1 Frame 2 TS0 TS1 TS2 TS3 TS4 Frame 3 Frame 4 TS28 TS29 TS30 TS31 8 bits per timeslot Figure 26.
Configuring Boards in the MVIP Bus Configuring Boards in the MVIP Bus There are several steps to configuring your MVIP bus. The following sections in this chapter discuss these steps in more detail. 1. Configure the MVIP clock. The MVIP bus uses a clock to synchronize frames. Set the clock for all boards in the bus except Vantage VRS or RDSP/xx000 boards. These boards have no clock and cannot drive the MVIP clock. 2. Map resources to streams and timeslots.
Chapter 5: MVIP-90 Configuring the MVIP-90 Clock Understanding Clocking Signals Boards connected in an MVIP-90 bus use an 8-kHz clock signal to synchronize frames. The MVIP-90 bus uses the following clocks: n n n n /F0 is the primary 8-kHz framing signal /C4 is the bus 4.096 MHz clock /C2 is the bus 2.048 MHz clock SEC8K is a secondary 8-kHz signal An RTNI board in the system drives the /F0 clock, which other boards use as a reference. You can also specify that boards use SEC8K as a backup signal.
Configuring the MVIP-90 Clock Setting the Clock Parameters Set the MVIP clock during driver installation and configuration using the Configuration Wizard. For specific information about how to set the MVIP clock during driver configuration, see the RealCT API Installation and Configuration Guide.
Chapter 5: MVIP-90 Setting up the System The following examples show how to set the MVIP clock for common scenarios: n If you have a system with a T1, an RTNI-ATSI, one Vantage VPS, and one Vantage VRS, you would set the clock in the following order: a. Set the T1 board to set the MVIP clock based on the first network trunk and to retrieve the SEC8K signal as a backup: CLOCK_REF_NET1 | SEC8K_NOT_DRIVEN (use the RHT_SET_CLOCK function) b.
Configuring the MVIP-90 Clock n If you have multiple T1 or E1 boards connected in loopback mode: a. Set the first T1 or E1 board to drive the MVIP clock from the internal oscillator and drive SEC8K from the first network trunk: CLOCK_REF_OSC | SEC8K_DRIVEN_BY_NET1 (use the RHT_SET_CLOCK function) b. Set all other boards to take the clock from the MVIP bus: CLOCK_REF_MVIP | SEC8K_NOT_DRIVEN (use the RHT_SET_CLOCK function) Example 7 shows how to set the clock for an T1 board using CONFIG_CLOCK.
Chapter 5: MVIP-90 Example 7. CONFIG_CLOCK Sample Code #include “brktddm.h” int main(int argc, char **argv) { BRKT_HANDLE BoardHandle; /* T1 board device handle */ BOOLEAN IoctlResult; /* Result of IOCTL call */ BRKT_SIZE_T BytesReturned; /* Bytes returned from IOCTL call*/ USHORT ClockValue; /* Open T1 board device */ BoardHandle = BrktOpenDevice (BRKT_DEVICE_T1_BOARD, 0); /* Configure MVIP clock. Synchronous call.
Mapping MVIP-90 Resources Mapping MVIP-90 Resources RDSP, Vantage VPS, and Vantage VRS boards each use a single data stream in the MVIP bus to send and receive data. Within that stream, the driver assigns VP and line resources on these boards to use a specific timeslot. RTNI and Vantage PCI boards use internal streams for their internal line and VP resources. Resources are pre-configured to specific timeslots on those streams.
Chapter 5: MVIP-90 Mapping RTNI Internal Resources Line resources on RTNI boards are assigned to timeslots on internal streams sequentially, starting with 0. For example, on trunk 0, the resource 0 is assigned to timeslot 0 on stream 16; resource 1 is assigned to timeslot 1 on stream 16, and so on through resource 23, which is assigned to timeslot 23 on stream 16. On E1 boards, only the 30 E1 channels that carry data are mapped to the internal streams (E1 timeslots 1-15, 17-31).
Mapping MVIP-90 Resources Mapping RDSP/xx000, Vantage VRS, and Vantage VPS Resources Mapping Boards to Streams RDSP/xx000, Vantage VRS, and Vantage VPS boards do not use internal streams. Resources on these boards are mapped directly to streams and timeslots on the MVIP bus. RDSP/xx000 Set the MVIP stream assignment for RDSP/xx000 series boards using hardware jumpers. These jumpers are factory configured to stream 6.
Chapter 5: MVIP-90 Vantage VPS Set the MVIP stream assignment for Vantage VPS boards using the RHT_CONFIG_MVIP function. When you call RHT_CONFIG_MVIP, set the stream assignment for the line and the VP resources separately. Set both the VP and line resources to use the same bidirectional stream. For example, if you set VP resources to use stream 6 (an input stream), set the line resources to use stream 14 (the corresponding output stream).
Mapping MVIP-90 Resources Mapping Resources to Timeslots RDSP, Vantage VPS, and Vantage VRS boards use one timeslot on their assigned MVIP stream per resource. Table 26 shows how resources are assigned to timeslots. VP indicates the VP resource number and TS indicates the timeslot used by that resource. Table 26.
Chapter 5: MVIP-90 Table 27 shows the VP resource number in the top row and their associated timeslots in the bottom row. Table 27.
Mapping MVIP-90 Resources In applications, the easiest way to determine the timeslot assignment is with an array: int mapping []= 1, 9,17,25 2,10,18,26 3,11,19,27 4,12,20,28 5,13,21,29 6,14,22,30 7,15,23,31 0, 8,16,24 timeslot=mapping[VP%32] For VPS boards you call RHT_CONFIG_MVIP twice: once to set stream and timeslot assignments for VP resources and once to set stream and timeslot assignments for line resources.
Chapter 5: MVIP-90 Enabling or Disabling Resources Boards that provide both line and VP resources, such as the Vantage VPS, have their resources connected to form channels. In this state, a call that comes in on line 0 is automatically processed by VP 0, as shown in Figure 27. The resources are not available to the MVIP bus. VP MVIP Bus Connector LS VP0 Line 0 VP1 Line 1 VP2 Line 2 VP3 Line 3 Figure 27.
Enabling or Disabling Resources Enable resources before you set the clock or switch data to resources on the Vantage VPS board. There are two ways to enable or disable line and VP resources. n When you call RHT_CONFIG_MVIP to set stream and timeslot assignments, enable or disable resources. n If you have already set the stream and timeslot assignments, enable and disable resources using RHT_MVIP_SETTING. The two functions enable and disable resources in the same way.
Chapter 5: MVIP-90 Example 8. RHT_CONFIG_MVIP Sample Code #include “brktddm.h” int main(int argc, char **argv) { BRKT_HANDLE BoardHandle; /* DSP board device handle */ BOOLEAN IoctlResult; /* Result of IOCTL call */ BRKT_SIZE_T BytesReturned; /* Bytes returned from IOCTL call*/ struct MVIPconfig_s Config; /* Open DSP device */ BoardHandle = BrktOpenDevice (BRKT_DEVICE_RDSP_BOARD, 0); /* Configure Vantage LS lines to MVIP. Synchronous call. */ memset (&Config,0,sizeof (Config)); Config.
Switching Calls through the MVIP-90 Bus Switching Calls through the MVIP-90 Bus When a computer telephony system processes a call, it connects the inbound or outbound line with the appropriate resource, such as VP or another line. That other resource can be on the same board, or on a different board in the system. The process of routing data between resources on different boards is called switching. All line resources have a CODEC, which codes/decodes the analog voice signal to digital data.
Chapter 5: MVIP-90 Throughout this section, boards connected in an MVIP bus are depicted as shown in Figure 29. MVIP Bus DSi6 DSo6 (6, 1) (6, 1) (16, 0) (16, 0) Trunk 0 Local Stream 16 RTNI-2T1 Figure 29. A Board in an MIVP Bus In Figure 29, the arrows above the boards represent streams in the MVIP bus. Streams running within the board to and from internal line or VP resources represent local streams. The rectangle with an X is the switch block.
Switching Calls through the MVIP-90 Bus Establishing Connections Establish or disconnect an MVIP connection using the function SET_OUTPUT. When the application calls SET_OUTPUT, it specifies the stream and slot to connect as output and the stream and slot to connect as input. It also specifies the timeslot mode. You can set the OutputParam_s.Mode field to either disable mode, connect mode, or pattern mode. August 2001 n When OutputParam_s.
Chapter 5: MVIP-90 When you use SET_OUTPUT to make a connection, you automatically break any previous connection that used the same resource as output. This is because a resource can only have one input source. For example, if an T1 board is switching data to the second VP resource on a Vantage VRS, and a second RTNI board also switches data to the second VP resource, the first connection will be broken. If two resources are both using the same MVIP bus timeslot as output, the connection is not broken.
Switching Calls through the MVIP-90 Bus Using Stream Numbers When calling any MVIP function, you refer to streams by a 0-15 numbering scheme rather than by their DSix and DSox numbers, as shown in Table 28. When you use streams in their conventional direction, the reference number is the same as the stream number. When you use streams in the reverse direction, you use the stream number plus eight. For examples of when you would use a stream in a reverse direction, see Connecting Line Resources on page 175.
Chapter 5: MVIP-90 Keep in mind that the conventional direction uses the resource board as a reference, so resource boards transmit on the DSo streams and receive on the DSi streams. When you call SET_OUTPUT, you define input and output from the network board’s perspective, since the switch block is part of the network board. From the network board’s perspective, the conventional direction uses DSi as output (input to the resource board) and DSo as input (output from the resource board).
Switching Calls through the MVIP-90 Bus Connecting Local Resources An RTNI board can connect a line to a remote resource through the MVIP bus, or connect two lines on the same board. For example, the T1 board in Figure 30 is connecting an incoming call from its second line (16, 1) with its fourth line (16, 3). In this example, the T1 board’s switch block does not contact the MVIP bus. When you call SET_OUTPUT to make this connection, you would specify the board handle of the T1 board you want to use.
Chapter 5: MVIP-90 Connecting a Call to a Resource Board When an RTNI board receives a call, it can transfer that call to a VP resource on a resource board such as a Vantage VRS or RDSP/24000. To make the connection, the RTNI board’s switch block switches the call from its internal line to the MVIP stream assigned to the resource board. Figure 31 shows an T1 board connecting a call from its first line resource to the first resource on a Vantage VRS that’s assigned to use stream 6.
Switching Calls through the MVIP-90 Bus Example 9. RHT_SET_OUTPUT Sample Code #include “brktddm.h” int main(int argc, char **argv) { BRKT_HANDLE LineHandle; /* T1 line device handle */ BOOLEAN IoctlResult; /* Result of IOCTL call */ BRKT_SIZE_T BytesReturned; /* Bytes returned from IOCTL call */ struct OutputParam_s Output; /* Open T1 line device */ LineHandle = BrktOpenDevice (BRKT_DEVICE_T1_LINE, 0); /* Make the first unidirectional connection. */ memset (&Output, 0, sizeof (Output)); Output.
Chapter 5: MVIP-90 Example 9. RHT_SET_OUTPUT Sample Code (Continued) /* Make the second unidirectional connection. */ Output.OutputStream = STREAM_MYSELF; Output.InputStream = 0; Output.
Switching Calls through the MVIP-90 Bus Connecting Line Resources When you connect resources from two boards with switching capability in a full-duplex connection, you connect the internal resource on one board to the internal resource on another board using an intermediate MVIP stream. These types of connections are called drop and insert. You drop a call from one internal resource onto an unused MVIP timeslot, then you insert that call into an internal resource on the second board.
Chapter 5: MVIP-90 If one network board transmits on the DSix stream and receives on the DSox stream (the conventional direction), then the other network board must transmit on the DSox stream and receive on the DSix stream, as Figure 33 shows. In this configuration, the boards can connect two lines through the MVIP bus. DSi0 DSo0 (0, 0) (0, 0) (8, 0) (8, 0) (16, 0) (16, 0) (16, 3) (16, 3) Trunk 0 Local Stream 16 External Lines Local Stream 16 RTNI ATSI RTNI-2T1 Figure 33.
Switching Calls through the MVIP-90 Bus Making a Broadcast Connection In a broadcast connection, a resource transmits data to a specified stream and timeslot, then several other resources receive data from that timeslot. In Figure 34, a board places data on stream 4, timeslot 2 (4, 2). Then several boards take data from that timeslot. MVIP Bus DSi4 DSo4 (4, 2) (4, 2) A Figure 34. B (4, 2) C (4, 2) D A Broadcast Connection and Distribution One example of a broadcast is a hold message.
Chapter 5: MVIP-90 Making Connections in an Application An application makes and breaks connections as a call progresses. For example, the following illustrations show an incoming call to an automated attendant. First, the T1 board receives a call, as shown in Figure 35. DSi5 DSo5 DSi6 DSo6 (16, 0) VP Stream 16 Trunk 0 Stream 16 RTNI-2T1 Vantage VRS RTNI ATSI Figure 35.
Switching Calls through the MVIP-90 Bus After the caller enters an extension, the application determines which line that extension uses and makes the appropriate connection. In this example, the requested extension uses the fourth resource on the RTNI-ATSI. The T1 board breaks the connection with the Vantage VRS and makes a connection with stream 5 on the MVIP bus. The RTNI-ATSI board also makes a full-duplex connection with stream 5. The RTNI-ATSI board then rings the extension selected by the caller.
Chapter 5: MVIP-90 Identifying the Timeslot Mode To find out the mode of a timeslot or connections associated with that timeslot, use the QUERY_OUTPUT function. QUERY_OUTPUT returns the mode and connections for the specified MVIP timeslot. QUERY_OUTPUT uses OutputParam_s.OutputStream and OutputParam_s.OutputSlot to identify the timeslot. Then it populates the OutputParam_s.Mode, OutputParam_s.InputStream, OutputParam_s.InputSlot and OutputParam_s.Message fields depending on the connection mode.
Switching Calls through the MVIP-90 Bus Example 10. RHT_QRY_OUTPUT Sample Code (Continued) /*Query unidirectional MVIP connection. Synchronous call.*/ memset(&Output, 0, sizeof(Outout)); Output.
6 MVIP-95 This chapter describes the MVIP-95 driver standard used by your H.100 bus compliant board. It includes information about the H.100 hardware standard that MVIP-95 supports. It includes the following topics: n n n n n n n n n Working with Computer Telephony Buses Defining MVIP-95 Connecting Boards in an H.100 bus Mapping Board Resources Configuring Boards in the CT bus Configuring the H.100 Clock Configuring the H.
Chapter 6: MVIP-95 Working with Computer Telephony Buses The computer telephony (CT) bus provides a way to transfer calls between telephony resources, even if those resources are provided by different vendors. With voice, fax, video, and automatic speech recognition cards connected in a single bus, you can develop fully-integrated computer telephony applications. A CT bus is comprised of two main parts: the physical bus and the switch block. The bus provides the physical connection between boards.
Working with Computer Telephony Buses Brooktrout supports two levels of MVIP: n RDSP, Vantage VRS, Vantage VPS, and RTNI boards all use the MVIP-90 software and hardware standard. n The Vantage PCI and RealBLOCs products support the H.100 Computer Telephony (CT) bus. H.100 is a hardware standard. The MVIP-95 software standard supports the H.100, MVIP-90, and H-MVIP buses. The RealCT Direct API Reference Manual has functions for both the MVIP-90 and MVIP-95 standards.
Chapter 6: MVIP-95 Defining MVIP-95 MVIP-95 is a software device driver standard that supports the MVIP-90, and H.100 hardware standards. You can connect an H.100 compliant board to RTNI or Vantage VRS and VPS products using the MVIP bus, or to boards that support H.100 using an H.100 bus. If you have several H.100 bus compliant PCI boards connected in an H.100 bus, use MVIP-95 functions for all boards in the system. If you have an H.
Defining MVIP-95 The RealCT Direct API includes 14 functions for MVIP-95 switching as shown in Table 29. Table 29.
Chapter 6: MVIP-95 Understanding H.100 Architecture H.100 is a high-speed hardware standard. Previous to H.100 there were two telephony bus standards: MVIP and SCSA. Boards with an MVIP bus could not communicate with boards using a SCSA bus. Boards using either the MVIP or SCSA standard can communicate through the H.100 bus, however, allowing developers to have boards from different vendors in a single bus. The H.100 bus supports 32 8.192-Mb/s streams, as shown in Figure 38. Each H.
Understanding H.100 Architecture Data in individual streams are formatted into frames. Each frame contains 8 bits of information for each of the timeslots, as shown in Figure 39. Each 8-bit timeslot has a period of 125 µs, for a total of 8000 timeslots per second (8 bits/slot x 8000 slots/second = 64 Kb/s). Figure 39. August 2001 Timeslots in an H.
Chapter 6: MVIP-95 Connecting Boards in an H.100 bus This section provides information about the H.100 bus, including information about how to set clocks and stream speeds for boards connected in an H.100 bus. This section only applies to boards that are physically connected in an H.100 bus to other H.100-compliant boards. For information about connecting your H.100-compliant board in an MVIP bus, see Connecting Boards in an MVIP-90 Bus on page 212.
Connecting Boards in an H.100 bus Mapping Board Resources The MVIP-95 board uses four internal data streams for a four-port board, eight internal data streams for an eight-port board, or 12 internal data streams for a 12-port board. Each stream carries four resources and uses four timeslots on the stream. The stream and timeslot assignments are set by the hardware and are not configurable. In the case of the Vantage PCI board, the first four VP resources use streams 0 and 1 to transmit and receive data.
Chapter 6: MVIP-95 Table 30.
Connecting Boards in an H.100 bus Stream number Assignment Resource Timeslot 6 Input Line4 0 Line5 8 Line6 16 Line7 24 Line4 0 Line5 8 Line6 16 Line7 24 7 Output Mapping RealBLOCs Resources This section lists the MVIP-95 local stream assignments. Table 31.
Chapter 6: MVIP-95 Stream number Assignment Resource Timeslot 2 Input Line4 0 Line5 8 Line6 16 Line7 24 Line4 0 Line5 8 Line6 16 Line7 24 Line8 0 Line9 8 Line10 16 Line11 24 Line8 0 Line9 8 Line10 16 Line11 24 Line12 0 Line13 8 Line14 16 Line15 24 Line12 0 Line13 8 Line14 16 Line15 24 3 4 5 6 7 194 Output Input Output Input Output RealCT Direct API Developer Guide
Connecting Boards in an H.
Chapter 6: MVIP-95 Configuring Boards in the CT bus There are several steps to configuring your CT bus. The following sections in this chapter discuss these steps in more detail. 1. Enable or disable resources. By default, the Vantage PCI switch block is not available to the CT bus. Enable the switch block before using the switch block. The RealBLOCs board does not provide the switch enable option. The switch is always enabled. 2. Configure the CT bus clock. The CT bus uses a clock to synchronize frames.
Connecting Boards in an H.100 bus Enabling or Disabling Resources By default, the entire Vantage PCI board switch block is not available to the CT bus. To enable or disable the MVIP-95 switch block, use the MVIP95_CMD_SET_SWITCH function. The RealBLOCs board does not provide the switch enable option. The switch is always enabled. In their default state, lines and VP resources on a Vantage PCI board are combined to make channels.
Chapter 6: MVIP-95 Example 11.
Connecting Boards in an H.100 bus Configuring the H.100 Clock You can connect an H.100 compliant board to either the MVIP or H.100 bus. You set the clocks differently depending on which bus your board is connected to. Boards connected in an H.100 bus use two primary clocks to synchronize frames. These are the A clock and the B clock. The H.100 bus also provides NETREF to synchronize boards with a digital interface to the network. Since the H.
Chapter 6: MVIP-95 Setting the Primary Clock Set the H.100 clock during driver configuration using the Configuration Wizard. For specific information about how to set the H.100 clock during driver configuration, see the installation and configuration guide that came with your software. If you need to change clock parameters after installation, use the MVIP95_CMD_CONFIG_BOARD_CLOCK function. If your board is connected to an H.100 bus, use the H.100 data structure to set the primary clock. In the H.
Connecting Boards in an H.100 bus Example 12 shows how to set the H.100_A clock from its internal oscillator. Example 12. MVIP95_CMD_CONFIG_BOARD_CLOCK (H.100) Sample Code #include “brktddm.h” int main(int argc, char **argv) { BRKT_HANDLE BoardHandle; BOOLEAN IoctlResult; BRKT_SIZE_T BytesReturned; struct MVIP95_CONFIG_H100_BOARD_CLOCK_PARMS Param; BoardHandle = BrktOpenDevice(BRKT_DEVICE_RDSP_BOARD, 0); if (BoardHandle == BRKT_INVALID_HANDLE_VALUE) return; memset (&Param, 0, sizeof(Param)); Param.
Chapter 6: MVIP-95 Example 12. MVIP95_CMD_CONFIG_BOARD_CLOCK (H.
Connecting Boards in an H.100 bus Setting the NETREF Clock The NETREF clock synchronizes the CT bus clock with a digital network. Since an H.100 compliant board does not have a digital network, you cannot set the NETREF clock for that board. If you have a board with a digital trunk in your system, use the MVIP95_CMD_CONFIG_NETREF_CLOCK function to determine which board sets the NETREF clock.
Chapter 6: MVIP-95 Configuring the H.100 Bus Speed The H.100 hardware specification supports three possible bus speeds. These speeds control how many timeslots the streams use as follows: n If the streams use all 128 timeslots, each carrying data at 64 Kb/s, the stream operates at 128 x 64 Kb/s = 8.192 Mb/s. n If the streams use 64 timeslots, each carrying data at 64 Kb/s, the stream operates at 64 x 64 Kb/s = 4.096 Mb/s.
Connecting Boards in an H.100 bus Example 13. MVIP95_CMD_CONFIG_STREAM_SPEED Sample Code #include “brktddm.h” int main(int argc, char **argv) { BRKT_HANDLE BoardHandle; BOOLEAN IoctlResult; BRKT_SIZE_T BytesReturned; struct MVIP95_CONFIG_STREAM_SPEED_PARMS Speed; BoardHandle = BrktOpenDevice(BRKT_DEVICE_RDSP_BOARD, 0); if (BoardHandle == BRKT_INVALID_HANDLE_VALUE) return; memset(&Speed, 0, sizeof(Speed)); Speed.size = sizeof(Speed); Speed.speed = MVIP95_8MBPS_STREAM_SPEED; Speed.
Chapter 6: MVIP-95 Switching Data A board with a switch block can transfer data between resources on any board connected through the CT bus. A board such as the RTNI series, which only provides line resources, would switch a call to a Vantage VRS to process the call. Only the RTNI, RealBLOCs, and Vantage PCI series boards provide switch blocks.
Connecting Boards in an H.100 bus Using MVIP-95 Switching Functions When you switch calls using the MVIP-95 switch block, use the MVIP95_CMD_SET_OUTPUT function. Unlike SET_OUTPUT in MVIP-90, MVIP95_CMD_SET_OUTPUT requires that you specify CT_Bus or local stream, since stream numbering for both begins with 0. For example, Figure 42 shows a full duplex connection between the second VP resource and the CT bus.
Chapter 6: MVIP-95 Establishing Connections Connections Between Local Resources An H.100 compliant board can establish connections between local resources. For example, if a call comes in on the first line, the switch block can connect that call to any VP resource. If the switch block is enabled, the first line resource is not automatically connected to the first VP resource to form a channel.
Connecting Boards in an H.100 bus Connections Through the CT bus See Switching Calls through the MVIP-90 Bus on page 165 for a description of connections that you can establish through a CT bus, such as drop and insert and broadcast connections. The concepts described in that section apply to switching calls using the H.100 bus. However, in H.100 there is no need to worry about stream direction.
Chapter 6: MVIP-95 Example 14. MVIP95_CMD_SET_OUTPUT Sample Code (Continued) memset(&Connect, 0, sizeof(Connect)); Connect.parms.size = sizeof(Connect); /* Connect { CT_BUS, 1, 1 } <= { LOCAL, 2, 0 } */ pOutput = &(Connect.parms.output[0]); pOutput->mode = MVIP95_CONNECT_MODE; /* Output stream / timeslot */ pOutput->terminus.bus = MVIP95_CT_BUS; pOutput->terminus.stream = 1; pOutput->terminus.timeslot = 1; /* Input stream / timeslot */ pOutput->connected_from.
Connecting Boards in an H.100 bus Example 14.
Chapter 6: MVIP-95 Connecting Boards in an MVIP-90 Bus This section provides information about connecting an H.100 compliant board in an MVIP-90 bus. When you connect an H.100 compliant board to boards in an MVIP-90 bus, you use different bus speeds, clock settings, stream numbering, and switching functions than if the board is connected in an H.100 bus. You also use the MVIP-90 functions when an H.100 compliant board is connected in an MVIP-90 bus. Use the following MVIP-90 functions with an H.
Connecting Boards in an MVIP-90 Bus Table 32.
Chapter 6: MVIP-95 Figure 44 shows the internal stream numbering for a Vantage PCI board. Lines 6, 7 7 6 5 4 DSP1 VP 4-7 3 2 Lines 4, 5 Lines 2, 3 Lines 0, 1 1 0 DSP0 VP 0-3 Vantage PCI Figure 44.
Connecting Boards in an MVIP-90 Bus RealBLOCs resources Table 33 lists the MVIP-90 local stream assignments. Table 33.
Chapter 6: MVIP-95 Configuring the H.100 Clock for the MVIP-90 Bus Defining H.100 Compatibility Clocks Boards connected in an MVIP bus use an 8-kHz clock signal to synchronize frames. One H.100 compliant board in the bus drives the clock. All other boards receive their clock signal through the 8-kHz clock signal set by the H.100 compliant board. The H.100 provides clocks that are compatible with the MVIP-90 clocks. These are shown in Table 34: Table 34. H.100 Compatibility Clocks H.
Connecting Boards in an MVIP-90 Bus Setting the Clock Parameters Configure the clock parameters using the Configuration Wizard during software installation. For specific information about the Configuration Wizard, see the installation and configuration guide that came with your software. If you want to change your configuration after software installation, use the MVIP-90 function CONFIG_CLOCK, as described in Configuring the MVIP-90 Clock on page 150.
Chapter 6: MVIP-95 Switching Data If a Vantage PCI or RealBLOCs board is connected in an MVIP bus, you adhere to the stream directionality of the MVIP bus. We recommend that you use the MVIP-90 function SET_OUTPUT to switch data over the MVIP-90 bus, but you can also use the MVIP-95 functions for the Vantage PCI or RealBLOCs board. You would use the MVIP-90 functions for any MVIP-90 board in the system.
Connecting Boards in an MVIP-90 Bus Using MVIP-95 functions We do not recommend that you use MVIP-95 functions when you connect the Vantage PCI or RealBLOCs board to an MVIP-90 bus. However, if you do choose to use the MVIP95_CMD_SET_OUTPUT function, use MVIP-95 stream numbering when you switch data. Although MVIP-90 and MVIP-95 number streams differently, the streams are physically connected.
Chapter 6: MVIP-95 Table 35. Relationship Between MVIP-90 and MVIP-95 Stream Numbering. MVIP-90 MVIP-95 DSo0 0 DSi0 1 DSo1 2 DSi1 3 DSo2 4 DSi2 5 DSo3 6 DSi3 7 DSo4 8 DSi4 9 DSo5 10 DSi5 11 DSo6 12 DSi6 13 DSo7 14 DSi7 15 For example, if a Vantage VRS or RealBLOCs board is using stream 6, transmit a call to that board from a Vantage PCI using the MVIP-95 equivalent to DSi6, which is stream 13.
Connecting Boards in an MVIP-90 Bus Figure 45 shows an H.100 compliant board connecting a call to a Vantage VRS that is assigned to use stream 6. The MVIP-95 function to switch the call uses stream numbers 13 and 12, which correspond to DSi6 and DSo6. Figure 45.
Chapter 6: MVIP-95 Figure 46 shows a connection between a Vantage PCI and an RTNI-ATSI. In this connection, both boards have a switch block. You would use the MVIP-95 function and MVIP-95 stream numbering to make the full-duplex connection between the Vantage PCI board’s internal resources and the MVIP stream. Then you would use the MVIP-90 functions and MVIP-90 stream numbering to make a full-duplex connection between the RTNI board’s internal resources and the MVIP stream.
Appendix A T1 Line Protocols This appendix describes the signaling bits transmitted in the most common T1 line protocols.
Appendix A: T1 Line Protocols Overview of Protocols The Immediate Start, Wink Start, and Double Wink Start protocols are symmetrical. The central office (CO) and customer premise equipment (CPE) transmit identical bit patterns for each line state. Your application uses the same protocol file whether it functions as a CPE or emulates a CO. The Loop Start and Ground Start protocols are asymmetrical. The CO and CPE transmit a different bit pattern to indicate the same condition.
Immediate Start Immediate Start Table 36 shows the pattern of bits transmitted by the CO and CPE in the Immediate Start protocol. Table 36.
Appendix A: T1 Line Protocols Wink Start Table 37 shows the pattern of bits transmitted by the CO and CPE in the Wink Start protocol. Table 37.
Wink Start The timing parameters for the wink depend on whether the application places the call or receives the call: n When the application receives a call, it sends a wink after the time specified by RDG_REMOTE_MIN_SEIZE. The wink has a duration specified by RDG_LOCAL_WINK_DUR. The RHT_WAIT_LINE_ON function automatically sends the wink, so there is no need for the application to call RHT_SEND_WINK.
Appendix A: T1 Line Protocols In the Wink Start protocol it is possible for the application to control when to send the wink. Since Wink Start is a derivative of Immediate Start, load the Immediate Start protocol then use RHT_SEND_WINK to send a wink in an inbound call or RHT_WAIT_WINK to receive a wink on an outbound call. Controlling the wink through the application can cause problems if the application gets preempted after RHT_SEIZE_LINE and before RHT_WAIT_WINK.
Double Wink Start Double Wink Start Table 38 shows the pattern of bits transmitted by the CO and CPE in the Double Wink Start protocol. Table 38.
Appendix A: T1 Line Protocols Double Wink Start is used mainly in Canada. It is a variation of the Wink Start Protocol in which the end receiving a call transmits a second wink after receiving digits. Since the timing for the second wink depends on the application, it requires a minor modification of the source code to explicitly send the second wink after receiving the digits.
Loop Start Loop Start Tables 39 and 40 show the pattern of bits transmitted by the CO and the station in the Loop Start protocol. Table 39 shows the pattern when the CO calls the station. Table 39. Loop Start: CO Calls Station Status CO Station Idle 01 01 Seizure: Ringing 00 --> 01 Answer 01 <-- 11 Conversation 01 Station disconnects 01 <-- 01 HookFlash 01 <-- 11/01/11 Timing Parameter 11 RDG_LOCAL_FLASH_DUR In the Loop Start Protocol, both ends transmit 01 in the idle state.
Appendix A: T1 Line Protocols Table 40 shows the pattern of bits transmitted when the station calls the CO. Table 40. Loop Start: station Calls CO Status CO Station Idle 01 01 Seizure 01 Dialtone from CO 01 11 Digits from Station 01 11 Answer 01 11 Conversation 01 11 Station disconnects 01 <-- 01 HookFlash 01 <-- 11/01/11 <-- Timing Parameter 11 RDG_LOCAL_FLASH_DUR In the Loop Start protocol, both ends transmit 01 in the idle state.
Ground Start Ground Start Tables 41 and 42 show the pattern of bits transmitted by the CO and station in the Ground Start protocol. Table 39 shows the pattern when the CO calls the station. Table 41.
Appendix A: T1 Line Protocols Table 42 shows the pattern of bits transmitted when the station calls the CO. Table 42.
Appendix B E1 Line Protocols This appendix describes the signaling bits transmitted in the most common E1 line protocols.
Appendix B: E1 Line Protocols Overview of Protocols The R2-CCITT protocols are symmetrical. The central office (CO) and customer premise equipment (CPE) transmit identical bit patterns for each line state. Your application uses the same protocol whether it functions as a CPE or emulates a CO. In Tables 43 through 44, the values indicate the A and B signaling bits transmitted by each party. The arrows point to the end receiving the bits. The driver has several parameters that control timing.
R2-CCITT R2-CCITT Table 43 shows the pattern of bits transmitted by the CO and CPE in the R2-CCITT protocol. Table 43.
Appendix B: E1 Line Protocols When the application is the incoming end, the application immediately recognizes the incoming call and the protocol sends an acknowledgment signal for at least RDG_LOCAL_MIN_SEIZURE_ACK. Then, the function waits for RDG_LOCAL_ACK_GUARD_TIME and returns. To answer a call, the protocol sends the answer signal for at least RDG_LOCAL_ANSWER_DUR, then the function waits for RDG_LOCAL_ANSWER_GUARD_TIME and returns.
R2-CCITT - Chinese Implementation R2-CCITT - Chinese Implementation The Chinese implementation of the R2-CCITT protocol uses the same timing and bit patterns as the R2-CCITT shown in Table 43. The only difference is that signaling bits C and D are both set to 1. R2-CCITT - Brazilian Implementation The Brazilian implementation of the R2-CCITT protocol uses the same timing and bit patterns as the R2-CCITT, except the receiving end answers the line by transmitting 01/11/01.
Appendix B: E1 Line Protocols R2-CCITT - Central European Implementation The Central European implementation of the R2-CCITT protocol uses the same timing and bit patterns as the R2-CCITT but with a different disconnect procedure, as shown in Table 44. Table 44.
R2-CCITT - Central European Implementation When the outgoing end terminates the call, it sends a Clear Forward signal. When the incoming end detects the Clear Forward, it transmits an intermediate signal called a Release Guard before releasing the line. The Release Guard acts as an intermediate signal to prevent bits A and B from both changing at one time. An Answer Signal (01) followed by an Idle signal (10) requires both bits A and B to change, called a double bit change.
Index Symbols B /C4 150 /F0 150 /FR_COMP B digit DTMF 18 B8ZS line coding 41 backward signal 20 BAD_STATE_ERROR E1 protocol error 138 T1 protocol error 85 binary line coding 38 BINFO sample E1 130 T1 76 bipolar violation description 40, 92 T1 troubleshooting 83 bit stuffing 40 BLKLN sample 129 blocked circuit 122 blue alarm 82 boards Brooktrout 6 RealBLOCs 6 Vantage 6 BrktCloseDevice() 10 BrktDeviceIoControl() 10 BrktGetLastError E1 synchronization error 134 T1 synchronization error 81 BrktGetLastError()
C buffer slips E1 troubleshooting 135 T1 troubleshooting 82 bulk call generator to test E1 applications 132 to test T1 applications 79 CRC reporting E1 98 T1 45 crossover cable 89 CSU cable configuration CSU loopback T1 89 CT_NETREF 216 83 C C digit DTMF 18 C2 150 call detection E1 111 T1 58 call termination E1 119 T1 66 call transfer T1 73 carrier configuration E1 105 T1 52 CEPT multiframe description 96 timeslot 0 96 timeslot 16 99 clear back 121 clock setting for H.
H documentation feedback xx double wink start 229 drop and insert 175–176 DS0 signal 42 DS1 signal 43 DSP 5 DTMF 18 dual tone multi-frequency 18 E E1 application tests 131 carrier configuration 105 CEPT multiframe 96 CRC reporting 98 debounce 106 deglitch 106 frame 0 alarm 135 framing 94 HDB3 93 internal signaling stream 128 line coding 92 line protocol configuration 101 mapping resources 155 network mode 133 ones density 93 protocol errors 137 samples 129 setting the clock for 150 Si1, Si2 98 signaling bi
I I loopback configuration T1 53 to test E1 applications 133 to test T1 applications 80 to troubleshoot a yellow alarm LSB sample E1 129 T1 76 immediate start protocol 225 incoming register 20 input streams 147 internal streams RTNI 165 signaling streams 75, 128 Vantage PCI 191 internal timeslots RTNI 156 Vantage PCI 191 inter-register signaling 20 M L line coding B8ZS 40–41 bipolar violation E1 92 T1 40 E1 92–93 HDB3 93 T1 38–41 ZCS 40 line protocol E1 description 101 loading 101 R2-CCITT 237 R2-CCITT,
R MVIP-95 board support 185 changes from MVIP-90 186 compatibility clocks 216 definition 186 functions 187 stream compatibility with MVIP-90 218, 219 stream numbering 190 MVIP-95 functions when to use 144 MVIP95_CMD_CONFIG_BOARD_CLOCK 200 MVIP95_CMD_CONFIG_NETREF_CLOCK description 203 example 201, 202 MVIP95_CMD_CONFIG_STREAM_SPEED description 204 example 205 MVIP95_CMD_SET_OUTPUT description 207 MVIP95_CMD_SET_SWITCH description 197 example 197 PLAYT sample 76 polar line coding 38 primary thread 11 proces
S RDG_LOCAL_FLASH_GUARD_TIME T1 73 RDG_LOCAL_IDLE_DUR E1 119 T1 66 RDG_LOCAL_IDLE_GUARD_TIME E1 119 T1 66 RDG_LOCAL_SEIZE_GUARD_TIME E1 123 T1 68 RDG_LOCAL_WINK_DUR 74 RDG_LOCAL_WINK_GUARD_TIME 74 RDG_REMOTE_ACK_TIMEOUT E1 123 T1 68 RDG_REMOTE_IDLE_TIMEOUT E1 119 T1 66 RDG_REMOTE_MAX_WINK 69, 74 RDG_REMOTE_MIN_WINK 69, 74 RDSP/xx000 setting the clock for 150 stream assignment 157 timeslot assignment 159 RealBLOCs PCI board 6 red alarm 81 remote loopback T1 53, 106 RHT_BLOCK_LINE 122 RHT_CONFIG_CHANNEL 52, 1
T SEC8K 150 seize line E1 123 T1 68 SET_OUTPUT sample code 173 to switch data 167 to write E1 signaling bits 128 to write T1 signaling bits 75 SETDM sample 130 signaling bits 44 signaling stream E1 128 T1 75 SIGNALING_BIT_ERROR E1 protocol error 138 T1 protocol error 86 stream assignment RDSP/xx000 157 Vantage VPS 158 Vantage VRS 157 stream description H.100 188 MVIP-90 145 stream numbering DSix/DSox 147 MVIP-90 147 conventional direction 169 reverse direction 169 MVIP-90 vs.
U timeslot use E1 95 H.100 188 MVIP-90 145 T1 42 TWAIT sample E1 130 T1 77 U user mode E1 133 T1 80 V Vantage PCI enable/disable resources 197 in an H.100 bus 190–209 in an MVIP-90 bus 212–222 internal stream numbering MVIP-90 190, 212 MVIP-95 191 internal timeslot assignment MVIP-90 212 MVIP-95 191 setting the clock for 150 setting the clock in an H.100 bus 199 setting the clock in an MVIP-90 bus 216 switching H.
