(Page 1 of 1 in this chapter)

Chapter 2

Application Architecture

2.1 Introduction

2.2 Data Flow Model

2.3 Half-Call Control Model

: 2.3.1 Gateway Application
: 2.3.2 Controlling Calls from the
: 2.3.3 Translating IP and PSTN
: 2.3.4 Controlling IP/Packet Network
: 2.3.5 Controlling RTP Data
: 2.3.6 Providing a User
: 2.3.7 Controlling IP/Packet Network Sessions and PSTN

2.4 Using a Multithreaded Programming Model

2.1 Introduction

This chapter provides an overview of the Fusion application architecture, and gives programming models and guidelines for building Fusion gateway applications.
Gateway applications use IP networks to connect PSTN calls to multimedia terminals or other gateways. There are several models for building IP telephony gateways. This chapter uses the Sample Gateway program (provided with the Fusion application development environment) as a model for: Data flow: Controlling the flow of real-time audio data, through NMS hardware, to PSTN and packet network environments. Call control: Managing calls received and placed from both PSTN and packet network interfaces. Thread management: Developing multi-threaded gateway applications that distribute gateway management operations among non-blocking modules.

2.2 Data Flow Model

When a Fusion gateway application answers incoming PSTN calls, sets up IP/LAN sessions, and switches the audio streams together, real-time audio flows end-to-end through Fusion hardware components.
Fusion gateway applications use the following NMS hardware components to carry data between PSTN and packet networks: MVIP bus AG T1/E1or AG-8/80 telephony board AG-RT or AG-RT/2 daughterboard TX2000 or 3000 board Figure 4. Fusion Gateway Data Flow Model
Figure 4 shows where the following processes take place as data flows through a Fusion gateway host system: IP packets or datagrams enter the TX board router where RTP and RTCP protocols process each packet. Per-session jitter buffers queue packets and, at the appropriate time, forward them to associated TX board resources (called virtual ports) that run on the TX board Communications Processor (CP). The TX board CP serializes packets and sends them to an on-board FMIC switch. The FMIC switch directs the audio data packets over the MVIP bus. An FMIC switch on the AG-T1 board redirects serialized packets from the TX board to the AG TRAU channels running on AG-RT daughterboard DSPs. The compressed audio data is decoded (using the G.723.1, GSM, etc.) from digital frames to PCM audio streams. PCM audio data is sent back to the AG-T1 FMIC switch where it is redirected to the AG-T1 PSTN line interface. The PCM audio data is sent from the AG-T1 to the PSTN.

2.3 Half-Call Control Model

Fusion gateway applications manage PSTN calls and IP session as a set of half-calls. One half-call originates from a PCM audio channel that comes in through the PSTN interface. The other half-call originates from a digital packet audio channel that comes in through the packet network interface.
According to this model, gateway applications need to perform and coordinate three primary call management functions: Control PSTN half-calls. Control IP/packet network half-calls. Translate addresses between PSTN and packet network (Internet Protocol) environments.
There are several ways you can design applications to perform these functions. The sections that follow illustrate one possible model for developing gateway applications.

2.3.1 Gateway Application Architecture

The Sample Gateway program (a demonstration program in the Fusion application development kit) uses the following components:

Component

Function

Session Control Module

maintains a state machine for each connection, and controls each of the lower level modules. The lower level modules (AG Call Control module, IP/LAN Call Control module, and RTP Control module) send asynchronous events (such as incoming call indications) to the Session Control module through callback functions.

IP Call Management

Provides complete functionality to handle the IP/packet network half-call. This may include call setup with an H.323 protocol stack.

RTP/RTCP Management

Controls the embedded RTP/RTCP protocols running on the TX board.

Address Translation

Provides a look-up cross reference for PSTN numbers and IP addresses.

PSTN Call Management

Manages PSTN half-calls.This includes controlling calls that come in and go out through the AG line interface board, and using AG-RT TRAU programs to convert data from one form to another.
Figure 5 provides an overview of the major components used in the Sample Gateway program architecture: Figure 5. Fusion Sample Gateway Program compnents Note: All modules in this Fusion gateway model access host system resources through the Win32 interface.

Component	Function
Session Control Module	maintains a state machine for each connection, and controls each of the lower level modules. The lower level modules (AG Call Control module, IP/LAN Call Control module, and RTP Control module) send asynchronous events (such as incoming call indications) to the Session Control module through callback functions.
IP Call Management	Provides complete functionality to handle the IP/packet network half-call. This may include call setup with an H.323 protocol stack.
RTP/RTCP Management	Controls the embedded RTP/RTCP protocols running on the TX board.
Address Translation	Provides a look-up cross reference for PSTN numbers and IP addresses.
PSTN Call Management	Manages PSTN half-calls.This includes controlling calls that come in and go out through the AG line interface board, and using AG-RT TRAU programs to convert data from one form to another.

2.3.2 Controlling Calls from the PSTN

The AG Call Control module controls the PSTN interface and handles the PSTN half-call. In the sample program, the AG Call Control module is responsible for initializing, operating, and shutting down the PSTN interface. It uses standard CT Access services to control operations taking place on AG boards. These include the ADI Service (for call control), the Switching service (for MVIP switching), and the Voice Message service (for voice prompts). The Sample Gateway call control module also uses the AG TRAU service to control AG-RT boards and their embedded AG TRAU programs.

2.3.3 Translating IP and PSTN Addresses

The Address Translation module translates between PSTN phone numbers and IP addresses. This module provides a look-up service to the Session Control module, but it can also include a second interface to remote directory services.
This enables the Address Translation module to periodically refresh its PSTN number/IP address cross-references, while providing the Session Control module with a fast look-up capability. In the sample gateway program, the Address Translation module includes a static look-up table with a single interface to Session Control module.

2.3.4 Controlling IP/Packet Network Sessions

The IP Call Control module controls the packet network interface and manages IP half-calls. The IP Call Control module, like the AG Call Control module, is responsible for initializing, operating, and shutting down the interface. The IP Call Control module may use H.323 or a proprietary IP-based signaling protocol.

2.3.5 Controlling RTP Data Flow

The RTP Control module controls the embedded RTP/RTCP protocols running on the TX packet network interface board. The TX board uses the RTP/RTCP protocols to transmit and receive audio packets.This is independent of the call setup protocol. For this reason, the RTP Control module is separate from the IP/LAN Call Control module. It enables developers to change the IP/LAN call setup protocol, and still use an existing RTP Control module.
The RTP Control module is responsible for initializing, operating, and shutting down RTP sessions on TX board(s). It uses proprietary APIs to control TX board routers. When initialized the RTP Control module creates virtual ports that associate MVIP hyper-channels with RTP sessions. After initialization, the RTP Control module controls the flow of data through the packet network interface, including dynamically creating and tearing down RTP sessions, and dynamically configuring jitter buffers.

2.3.6 Providing a User Interface

In the sample program, the User Interface simply prompts the user for initialization parameters, starts the application, and polls the Session Control module for connection status.

2.3.7 Controlling IP/Packet Network Sessions and PSTN Calls

The Session Control module implements a state machine for each connection that joins a PSTN half-call and packet network half-call. The Session Control module keeps state definitions independent of call setup states kept at lower layers of the PSTN or packet network interface. Packet network/PSTN interface modules can be upgraded, or even converted to different protocols, without affecting the overall gateway application architecture. Figure 6. A Model for a Fusion Gateway Application

2.4 Using a Multithreaded Programming Model

This section shows how a resource-based thread model is applied to the Sample Gateway program. This is one of a number of different ways to use multiple threads to improve performance.
The Sample Gateway program uses separate modules for the PSTN and packet network interface. For example, individual modules control AG board operations (both PSTN call control and data conversion), H.323 call control operations, and the RTP/RTCP operations. Each module uses separate threads for functions that are invoked through blocking APIs (otherwise, modules would have to wait for completion events). This model ensures that any blocking occurs in local worker threads. It keeps the other main modules running, for example, while calls are being placed on either the packet network or PSTN interface.
By applying this approach to each module, every interface operates independently and at its full potential. Figure 7 illustrates the threading model used in the Sample Gateway program. Figure 7. Fusion Gateway Thread Model

(Page 1 of 1 in this chapter)

tech_support@nmss.com