1.1 Introduction

1.2 About the MSPP Service

1.3 Basic Terminology

1.4 CT Access Environment

1.4.1 Synchronous and Asynchronous Functions

1.4.2 Operations, Administration, and Maintenance Service

1.1 Introduction

The Fusion MSPP Service Developer's Reference Manual explains how to use the CT Access MSPP service for creating and destroying media channels between endpoints established at different ends of a Fusion gateway. Use this reference in conjunction with the Fusion Developer's Manual and the Fusion MSPP Service Filter Reference Manual.

This document defines telephony terms where applicable, but assumes that the reader is familiar with telephony concepts and switching. It also assumes that the user is familiar with the C programming language.

1.2 About the MSPP Service

The Media Stream Protocol Processing (MSPP) service is a CT Access service that provides functions for creating and destroying media channels between endpoints established at different ends of a Fusion gateway. The MSPP service enables you to create unified voice and fax gateway applications by creating, connecting, configuring, and destroying media endpoints and channels. You can use the MSPP service in combination with other CT Access services, such as the ADI and NCC services, to provide an interface for PSTN call control and IVR applications.

1.3 Basic Terminology

The MSPP service controls three basic elements:

Term	Description
endpoint	An entry and/or exit point for data that streams through the gateway through an MSPP channel.
channel	A linked set of functions that transforms a real-time flow of voice or fax data from one form to another. The flow of data can be either be two-way (duplex) or one-way (simplex).
connection	A direct coupling between two endpoints and a channel. When the connection is enabled, data flows between the endpoints.

The CT Access MSPP service provides a methodology for parameter management, runtime attribute adjustments, and runtime commands.

Each endpoint type defines a parameter structure that governs the endpoint features established at construction.

After a channel is connected to the endpoints, commands can be sent at runtime by using mspSendCommand. Each filter function within a channel defines a set of commands capable of changing the function's behavior. For more information on MSPP filters, see the Fusion MSPP Service Filter Reference Manual.

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 Fusion MSPP functions.

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

1.4.1 Synchronous and Asynchronous Functions

CT Access employs an asynchronous programming model 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 MSPP service functions and indicates if they are synchronous or asynchronous.

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

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

Figure 1. CT Access and the MSPP Service

1.4.2 Operations, Administration, and Maintenance Service

The Operations, Administration, and Maintenance (OAM) service is the API for the NMS OAM software. OAM is an extension to CT Access that performs operations on, administration of, and maintenance of telephony resources in a system. Use OAM to configure and initialize the NMS hardware in your chassis. OAM can manage:

• Hardware components, such as NMS boards, or

• Software components, such as the NMS Hot Swap process.

Since these components are being managed by OAM, they are called managed components.

Using NMS OAM, you can:

• Create, delete, and query the configuration of a board managed component.

• Start (boot), stop (shut down), and test a managed component.

• Receive notifications from managed components.

Software processes supported by OAM include:

• Hot Swap: the ability to insert and extract CompactPCI boards without powering down the system.

• Clock management: the ability to configure the CT bus clock across all boards in a H.110 system.

OAM is available with versions of CT Access 4.0 and later. For general information about OAM, refer to the OAM System User's Manual. For more information about the OAM service, refer to the OAM Service Developer's Reference Manual.

Note: OAM operates only when the CT Access Server (ctdaemon) is running.