1.1 About This Manual

1.2 Introduction

1.3 Fusion Gateway Components

1.3.1 Host-Based Fusion Configurations

1.3.2 AG TRAU Programs

1.3.3 AG TRAU Channels

1.4 CT Access Environment

1.4.1 Synchronous and Asynchronous Functions

1.1 About This Manual

The Fusion AG TRAU Developer's Reference Manual provides information for creating applications that use AG TRAU (Transcoding and Rate Adapter Unit) service functions, events, and error codes.

This manual is targeted to programmers and system integrators who develop IP telephony gateway applications using the AG TRAU service. The manual assumes readers are familiar with basic concepts relevant to telephony and internet data communication as well as the C programming language.

1.2 Introduction

The Fusion AG TRAU service is a set of functions for controlling TRAU (Transcoding and Rate Adapter Unit) DSP programs on NMS boards. The AG TRAU service enables applications to perform processor-intensive, low latency data conversion tasks on NMS board DSPs. These tasks include converting PCM voice data into digital packets, and converting digital packets into PCM voice data. Other tasks may include A-law and mu-law encoding, echo cancellation, and DTMF suppression.

1.3 Fusion Gateway Components

Fusion gateway applications use the AG TRAU service to convert voice data from Public Switched Telephone Networks (PSTNs) into digital packets and vice versa. Figure 1 shows a typical Fusion gateway application using AG TRAU programs.

Fusion gateways use NMS boards to send and receive voice data to and from the PSTN. CT Access provides functions for placing and receiving PSTN calls on NMS boards (such as AG 4000 or AG 2000 boards), and the AG TRAU service provides functions for controlling data conversion. Voice data is carried to the packet network either through a TX packet network interface board (typically a TX3210 board) or standard network interface board. Systems that use standard network boards rather than the TX3210 are called host-based Fusion configurations.

Figure 1. Fusion TX-based Configuration with AG 4000 board

Note: Not all NMS boards can run AG TRAU programs.

1.3.1 Host-Based Fusion Configurations

Fusion host-based configurations use standard network interface boards, rather than TX3210 boards, to provide the packet network interface. These gateways use the HBF service (another CT access service), to control the flow of data between the host processor and the PSTN and packet network interfaces.

Unlike Fusion TX-based configurations, Fusion host-based configurations use the host processor (in addition to NMS board resources) to transfer data from one end of the gateway to the other. They also use the host system's TCP/IP stack and the Fusion H.323 stack to control calls at the packet network interface.

Figure 2. Fusion Host-Based Configuration with AG 4000 board

1.3.2 AG TRAU Programs

An AG TRAU program is an NMS DSP program that encodes and decodes channels of voice data according to a particular standard (for example, G.723.1or G.711). AG TRAU programs frame and de-frame data so that it can be sent to the PSTN interface, to the packet network interface, or to the host processor.

Figure 3 shows an AG TRAU program receiving data from a PSTN, performing echo cancellation, encoding the data (for example, according to the G.723.1 algorithm), and framing the data (in HDLC or A.bis format). The data can then be packaged in IP datagrams and sent over a packet network or processed by the host processor (in Fusion host-based configurations).

Figure 3. AG TRAU Program: PCM to Packets

Figure 4 shows the AG TRAU program receiving data from the packet network (or the host processor) and performing operations to deframe and decode the data for transmission over a PSTN.

Figure 4. AG TRAU Program: Packets to PCM

Note: Because different NMS boards contain different numbers of DSPs, they may be able to run different numbers of AG TRAU programs. In addition, some boards require that a particular number of DSPs be reserved for performing PSTN call control.

1.3.3 AG TRAU Channels

An AG TRAU channel is a unique voice path processed by an AG TRAU program. AG TRAU programs may support different numbers of channels. The total number of channels an NMS board can support is determined by the number DSPs that are running AG TRAU DSP programs, and the number of channels each of these programs supports.

Note: A number of onboard DSPs are usually used to perform other operations such as call control. This also limits the number of channels the board can support..

1.4 CT Access Environment

This section provides background information about CT Access and summarizes the main elements of the CT Access environment. You must have CT Access installed on your system to build applications using the AG TRAU functions.

For more detailed information about CT Access, see the CT Access Developer's Reference Manual.

1.4.1 Synchronous and Asynchronous Functions

CT Access employs an asynchronous programming model in order to take advantage of concurrent processing. When called, most functions return immediately indicating the operation was initiated. The application may then perform other functions while CT Access is processing the command.

There are two types of functions in CT Access, synchronous and asynchronous.

• Synchronous functions are complete when the return value is received. The return value may be either SUCCESS or an error code.

• Asynchronous functions return events that indicate the success or failure of the operation, and if the operation fails, may return the reason for this failure (in the value field of the event).

During the function execution, events are generated indicating the occurrence of certain conditions or state changes. If an asynchronous function fails after being initiated, CT Access delivers a DONE event to the application and the event value field contains an error code.

The following table summarizes the differences between asynchronous and synchronous functions. Chapter 3 lists AG TRAU service functions and indicates if they are synchronous or asynchronous.

Characteristic	Asynchronous	Synchronous
Operation complete when function returns	No	Yes
Returns a DONE event when function is complete	Yes	No
Function can fail after function returns	Yes	No

As shown in Figure 5, for asynchronous functions, CT Access sends a command to the service which sends a command to a telephony board. The board performs the requested functions and sends events to the service indicating its state
(e.g., function was started, function is complete, etc.). The service sends events to CT Access, which makes them available to the application.

Figure 5. CT Access and the AG TRAU Service

See Appendix A for a complete list of AG TRAU events and errors.