2.1 Introduction

2.2 Setting Up the CT Access Environment

2.2.1 Creating Event Queues and CTA Contexts

2.2.2 Opening MSPP Service Instances

2.3 Setting Up MSPP Connections

2.3.1 Configuring MSPP Components

2.3.2 Creating MSPP Endpoints

2.3.3 Sending Commands to MSPP Endpoints

2.3.4 Disabling and Enabling MSPP Endpoints

2.3.5 Creating MSPP Channels

2.3.6 Connecting MSPP Endpoints with Channels

2.3.7 Configuring MSPP Channels

2.3.8 Enabling MSPP Connections

2.3.9 Controlling MSPP Components

2.3.10 Performing Filter Queries

2.3.11 Converting Command and Query Structure Byte Order

2.4 Disconnecting and Destroying MSPP Connections

2.5 Initiating and Terminating MSPP Connections

2.6 Controlling MSPP Endpoints

2.6.1 Specifying Default Endpoint Behavior

2.6.2 Sending Commands to Endpoints

2.7 Controlling MSPP Channels

2.7.1 Specifying Default Channel Behavior

2.7.2 Sending Commands to Channels

2.8 MSPP Filter Command Events

2.8.1 Unsolicited Events

2.1 Introduction

The MSPP service enables you to set up and tear down media channels across the gateway system. You can create, connect, and enable duplex or simplex media connections by managing objects called endpoints and channels. Endpoints provide nodes for sending and receiving network data. Channels provide a mechanism for converting and transferring data as it flows from one endpoint to another.

Note: The MSPP service does not perform call control at either the PSTN or packet network interfaces. Call control is performed independently by the application through the Natural Call Control service and a third party call control stack (such as H.323 or MGCP). For more information about using the Natural Call Control service, refer to the Natural Call Control Service Developer's Reference Manual.

The MSPP service insulates developers from much of the local switching needed to take advantage of CG 6000C DSP resources. Once CG 6000C board resource management has been configured, you do not need to explicitly perform local switching between the incoming data and the on-board resources needed to process the data. However, you still need to perform local switching between the line interface and the DS0 endpoint.

This chapter describes:

• Setting up the CT Access environment

• Creating MSPP endpoints

• Controlling MSPP endpoints

• Disabling and enabling MSPP endpoints

Creating MSPP channels

Controlling MSPP channels

Disabling and enabling MSPP channels

Connecting MSPP channels and endpoints

Enabling MSPP connections

Disconnecting and destroying MSPP media connections, channels, and endpoints

2.2 Setting Up the CT Access Environment

Before calling functions from the MSPP service, an application initializes CT Access and opens the CT Access services it will use (including MSPP). Applications can only use services initialized with ctaInitialize.

To set up CT access:

1. Initialize CT Access and its services.

2. Create event queues.

3. Create CTA contexts (attaching to event queues).

4. Open service instances on CTA contexts.

To initialize CT Access and its services, invoke ctaInitialize and specify the names of the services and service managers the application will use.

The following table lists the names of services and service managers that may be used by Fusion applications:

This service...	With this service manager...	Provides...
MSP	MSPMGR	Media channel processing and control
ADI	ADIMGR	DTMF detection, tone generation, etc.
NCC	ADIMGR	PSTN call control
SWI	SWIMGR	CT bus switching functions
VCE	VCEMGR	Voice message play and record
DTM	DTMMGR	Monitors the state of the T1/E1 frame

Note: The ADI service must be open in the same context with which a DS0 endpoint is being used.

For a list of all the standard CT Access services, refer to the CT Access Developer's Reference Manual.

2.2.1 Creating Event Queues and CTA Contexts

After initializing CT Access and its services, you must now create CT Access event queues and CTA contexts.

1. Create one or more event queues by calling ctaCreateQueue. Specify which service managers to attach to each queue. The MSPP service uses the MSPMGR service manager.

2. Create CTA contexts by calling ctaCreateContext and providing a queue handle (ctaqueuehd) returned from a previous call to ctaCreateQueue. All events for services on the CTA context are received in the attached event queue.

A call to ctaCreateContext returns a CTA context handle (ctahd). When an application invokes an MSPP function, this CTA context handle must be specified. Events communicated back to the application are associated with the specified handle. For more information about CT Access programming models and managing CT Access contexts and queues, refer to the CT Access Developer's Reference Manual.

2.2.2 Opening MSPP Service Instances

Opening a service on a CT Access context creates a service instance on that context as well. To open an MSPP service instance on a context, invoke ctaOpenServices and specify a ctahd, the type of service (MSP) to open, and the appropriate service manager (MSPMGR) for the specified service.

2.3 Setting Up MSPP Connections

Applications create end-to-end media channels by creating MSPP endpoints and channels and joining them to form simplex or duplex connections. The following sections describe using the MSPP service to set up connections and transfer data across the Fusion gateway.

2.3.1 Configuring MSPP Components

The MSPP service allows you to control both MSPP endpoints and channels during runtime. During the process of creating endpoints and channels, the application specifies the following default configuration information:

MSPP Object	Configuration Information Given During Creation
MSPP endpoints	· Address information (specifies the locations from which the endpoint receives and sends data) · Parameter information (specifies which features or functionality enabled on the endpoint) · Board number where endpoint runs
MSPP channels	· Board number where the channel runs · Type of channel (specifies the filters that make up the channel)

Applications can change MSPP endpoint configuration information any time after creating the endpoint. In addition, applications can change MSPP channel attributes after connecting the channel to two endpoints.

2.3.2 Creating MSPP Endpoints

An MSPP endpoint provides entry and exit points through which data can flow across Fusion gateway. Endpoints perform the following sets of operations with the data that passes through them:

• Incoming data: Translate data between a network transport format (for example, UDP, RTP, DS0) and the NMS media transport format so that MSPP channels can receive the data, process it, and pass it on.

• Outgoing data: Translate processed data between the NMS media transport format and a network transport format so that the data may be transferred to the network.

There are a standard set of MSPP endpoints from which to build MSPP connections. Each type of endpoint is capable of sending and receiving data to and from a particular network-specific format.

Available endpoint types include:

Endpoint	Description
DS0	Receive and send data to and from a PCM source (for example, a PSTN).
RTP	Receive and send data (timestamped with RTP header) to and from the IP network interface. Endpoints can be simplex or duplex.
UDP	Receive and send data to and from the IP network interface (primarily used for T.38 fax over IP).

Applications can create MSPP endpoints by invoking the MSPP service function mspCreateEndpoint. This function requires that you specify a ctahd that has been used to open an MSPP service instance (refer to Section 2.2.2). In addition, you provide two structures that define the endpoint: an address structure and a parameter structure.

Note: The ADI service must be open on the same ctahd with which a DS0 endpoint is created.

The address structure provides basic configuration information about the endpoint, usually the source and destination address for transferred data. The parameter structure specifies the features that are available on the MSPP endpoint.

The following table provides an overview of the information provided with mspCreateEndpoint for different types of MSPP endpoints:

Endpoint Type	Address Information	Parameter Information
DS0	· Timeslot	· Specifies voice or fax data transmission
RTP	· Source UDP port and IP address · Destination UDP port and IP address	· IPv4 type of service (ToS) information · RTP timestamp frequency · RTCP session parameters
UDP	· Source port and IP address · Destination port and IP address	· IPv4 type of service (ToS) information

When an application creates MSPP endpoints, the MSPP service returns a unique endpoint object handle (ephd) that the application can use to configure and control the endpoint.

2.3.3 Sending Commands to MSPP Endpoints

Once an application has created an endpoint, it can control the endpoint during runtime with mspSendCommand. The application specifies an ephd, a valid endpoint command, and a value.

For more information about sending endpoint commands, refer to Section 2.6.2.

2.3.4 Disabling and Enabling MSPP Endpoints

By default, when an application creates an endpoint, the endpoint is enabled and is ready to transfer information between the network and an MSPP channel. However, the application can use mspDisableEndpoint to halt the flow of data through a particular endpoint. Although it usually makes more sense to stop the flow of data by disabling the channel that connects two endpoints, mspDisableEndpoint can also be used to interrupt the flow of data through an MSPP connection.

Applications can restart the flow of data through an enabled endpoint by invoking mspEnableEndpoint.

2.3.5 Creating MSPP Channels

An MSPP channel is a linked set of functions (filters) that transform a real-time flow of voice or fax data from one form to another. For example, an MSPP G.711 duplex channel encodes and decodes (according to the G.711 algorithm) a two-way flow of voice data as it moves between the PSTN and packet network interface. The application creates the MSPP channel independently of the MSPP endpoints, and then uses the channel to connect two endpoints of the appropriate type. For example, a duplex G.711 channel is used to connect a DS0 endpoint with an RTP endpoint.

Create MSPP channels with mspCreateChannel. When invoking mspCreateChannel, provide a CT Access context handle (ctahd) and two structures that define the channel: an address structure, and a parameter structure. When it creates the MSPP channel, the MSPP service returns a unique channel object handle (chnhd) that the application can use to configure and control the channel. Once you have created an MSPP channel you can use it to connect MSPP endpoints to create a media path for voice or fax data.

The following channel types are provided under Fusion (each channel type is supported in duplex and simplex form):

Channel	Description
G.711	Transfers G.711 encoded data between IP network and PSTN.
G.723.1	Transfers G.723.1 encoded data between IP network and PSTN.
G.729A	Transfers G.729A encoded data between IP network and PSTN.
G.726	Transfers G.726 encoded data between IP network and PSTN.
T.38 Fax	Transfers T.38 fax data from a PSTN to an IP network via UDP. Not supported in simplex form.

Note: Applications can only send commands to MSPP channels after the channels have been connected to endpoints. For more information about controlling MSPP channels, refer to Section 2.3.9.

2.3.6 Connecting MSPP Endpoints with Channels

Use mspConnect to join MSPP endpoints with an MSPP channel to create an end-to-end gateway media path. This media path is called an MSPP connection. When invoking mspConnect, specify two endpoint handles (returned by mspCreateEndpoint) and a channel handle (returned by mspCreateChannel). These specify the endpoints through which the data will flow, and the processes that will take place (e.g., encoding and decoding) as the transferred data flows through a channel. The following table shows the types of MSPP endpoints that can be connected to particular MSPP channels:

Channel Type	Associated Endpoints
G.711 (simplex/duplex)	RTP	DS0
G.723.1 (simplex/duplex)	RTP	DS0
G.726 (simplex/duplex)	RTP	DS0
G.729A (simplex/duplex)	RTP	DS0
T.38 Fax (duplex only)	UDP	DS0

Note: When you use mspConnect, the order in which you specify endpoint handles is significant. For voice channels, the first endpoint handle (ephd1) must be associated with an RTP endpoint and the second endpoint handle (ephd2) must be associated with a DS0 endpoint. For fax channels, ephd1 must associated with a UDP endpoint and ephd2 must be associated with a DS0 endpoint.

Figure 2 shows an application creating a G.723.1 channel, an RTP endpoint, and a DS0 endpoint with MSPP service functions.

Figure 2. Creating MSPP Endpoints and Channels

Figure 3 shows the application creating a G.723.1 duplex connection by connecting the RTP endpoint and DS0 endpoint with a G.723.1 channel.

Figure 3. Connecting MSPP Endpoints and Channels

Once the connection has been established, it begins to process data when:

1. The application enables the channel.

2. The application connects data to one of the endpoints that make up the connection.
   Note: By default, MSPP endpoints are enabled when created, while MSPP channels are disabled. For this reason, channels have to be enabled to transfer data, while endpoints (unless explicitly disabled) automatically transfer any data connected to them.

Each MSPP channel is composed of a linked set of functions, called filters, organized to carry out a set of operations on data that flows through the channel. Each filter performs a specific task or set of tasks on data that flows through the channel. For more information about MSPP filters that make up standard MSPP channels, refer to the Fusion MSPP Service Filter Reference Manual or Section 2.8.

2.3.7 Configuring MSPP Channels

Applications can mix-and-match channels by joining different types of simplex connections to the same endpoint. This allows you to configure the flow of data through a connection in three ways:

Connection	Description
Simplex channel	Create simplex connections by creating simplex channels (encode or decode), and connect them with the appropriate endpoints. The connection carries data in a single direction.
Duplex (symmetrical)	Create duplex connections by creating duplex channels of the same type (encode and decode), and connect them with the appropriate endpoints. The connection carries data in two directions.
Asymmetrical duplex	Create a simplex encode channel of one type (for example, G.711 or G.723), a decode channel of another type (for example G.729A or G.726), and connect them both to the same endpoints. Each connection carries data in a different direction (and possibly encoded according to a different algorithm), but together the connections make up a full duplex data path.

For example, in Figure 4 the application creates an asymmetric duplex connection between an RTP full duplex endpoint and a DS0 endpoint by creating a simplex G.723.1 encode connection in one direction, and a simplex G.711 decode connection in the opposite direction. Since both connections share the same endpoints, data flowing across the channel is encoded and/or decoded according to a different algorithm, depending on the direction in which it flows.

Figure 4. MSPP Asymmetric Duplex Connections

2.3.8 Enabling MSPP Connections

MSPP channels are disabled when created. When you have established a connection by joining MSPP endpoints with an MSPP channel, you can enable the connection with mspEnableChannel. mspEnableChannel opens the channel so that data flows between the connected endpoints. When invoking mspEnableChannel, specify the channel handle (chnhd) of the connected channel. As soon as the application transfers data to one of the connection's endpoints, the connection channel processes the data and passes it on to the endpoint at the opposite end of the connection.

2.3.9 Controlling MSPP Components

Channel filter behavior cannot be modified by mspSendCommand until the channel is connected to two endpoints.

MSPP channels and endpoints are composed of linked sets of processes, called filters. Each filter performs a specific task or set of tasks with the data that flows through it. The mspSendCommand function conveys a filter-specific command to a particular channel or endpoint.Once you have created an MSPP connection, you can configure the way the associated channel processes data with mspSendCommand.

When invoking mspSendCommand, specify:

• A valid MSPP ephd or chnhd

• A valid filter ID concatenated with a valid command ID

• A buffer where the command structure is returned

• The size of the command structure to be returned

To build an MSPP filter command, use the macro mspBuildCommand (defined in mspcmd.h) to concatenate a valid MSPP filter ID with a command ID.

For information about the specific filters that make up each type of MSPP channel, and the commands to which these filters respond, refer to the Fusion MSPP Service Filter Reference Manual.

For more information about controlling the behavior of MSPP endpoints and channels with mspSendCommand, refer to Section 2.6 and Section 2.7. See Chapter 4 for more information on the mspSendCommand command.

2.3.10 Performing Filter Queries

The MSPP service provides query commands to solicit configuration and operation data from MSPP filters. MSPP queries to MSPP objects return filter status information in a buffer that must be released by mspReleaseBuffer.

If an application wants to send a query to a filter within a connected voice/fax encoding/decoding channel, it can invoke mspSendQuery and provide:

• A valid MSPP ephd or chnhd

• A valid filter ID concatenated with a valid query ID

To build an MSPP filter query, use the macro mspBuildCommand (defined in mspcmd.h) to concatenate a valid MSPP filter ID with a query ID.

The MSPP service returns a filter-specific structure that provides information about the filter's configuration and/or operation. See Chapter 4 for more information on the mspSendQuery primitive.

2.3.11 Converting Command and Query Structure Byte Order

The CG 6000C board has an on-board CPU that expects byte ordering in little endian format. In operating systems that use big endian byte order (for example, Sun SPARC), the following parameter structures must be converted from big endian to little endian and vice versa:

• Structures created by the application and sent to the board using mspSendCommand.

• Structures expected from the board as a result of mspSendQuery.

Not all fields within the structure are affected. Only unsigned short (defined as WORD in nmstypes.h) and unsigned long (defined as DWORD in nmstypes.h) are affected.

NMS provides the following macros for converting values from host byte ordering to board byte ordering format for operating systems that use big endian byte order:

H2NMS_DWORD(DWORD val) 
H2NMS_WORD(WORD val) 

The following two additional macros convert values from CG 6000C board byte ordering to big endian byte ordering format.

 NMS2H_DWORD(DWORD val)
 NMS2H_WORD(WORD val)

The following example code shows how to use the byte order conversion macros:

DWORD dword;
WORD  word; 

// From host to board byte ordering format
dword  = H2NMS_DWORD(dword);
word = H2NMS_WORD(word);

// From board to host byte ordering format
dword = NMS2H_DWORD(dword);
word = NMS2H_WORD(word);

Note: These macros do not need to be wrapped around an #ifdef _OS_ preprocessor. On systems that do not need any conversion, output from these macros is the same as input.

2.4 Disconnecting and Destroying MSPP Connections

Use the following commands to destroy MSPP connections.

MSPP Command	Description
mspDisableChannel	Interrupts the flow of data on a specified MSPP connection.
mspDisconnect	Disassociates the MSPP endpoints and MSPP channel in a specified connection (if the channel is enabled when the command is issued, the MSPP service automatically disables the connection before breaking up the connection).
mspDestroyEndpoint	Destroys a specified MSPP endpoint (and disables and/or disconnects the associated connection if the endpoint is part of an enabled connection).
mspDestroyChannel	Destroys a specified MSPP channel (and disables and/or disconnects the associated connection if the channel is part of an enabled connection).

Note: The order in which the commands are called is important, and should match the order listed in the table.

2.5 Initiating and Terminating MSPP Connections

Figure 5 shows a typical MSPP function sequence for setting up and tearing down MSPP connections.

Figure 5. MSPP Function and Event Sequence

When setting up and tearing down MSPP connections, keep the following in mind:

• The application can create endpoints and channels in any sequence.

• Applications can interrupt a connection either by disabling the channel (with mspDisableChannel) or by disabling one of its component connection endpoints (with mspDisableEndpoint).

• Channel filters cannot receive commands until the channel is connected.

Figure 6 is a state diagram for creating and destroying an MSPP connection. This diagram can be correlated with the function sequence diagram in Figure 5 to gain a comprehensive understanding of MSPP call states and events.

Figure 6. MSPP Call States

2.6 Controlling MSPP Endpoints

Endpoints are used to send and receive data to and from a network or host. Each type of endpoint provides an entry-point suitable for sending data across the Fusion gateway. Consequently, at minimum, all MSPP endpoints provide the following:

• An input terminus for receiving network (or host) formatted data

• An output terminus for sending out network (or host) formatted data

Endpoints may also perform other processing tasks with data that passes through them. In addition, a DS0 endpoint may take specific actions during runtime (after a command has been sent by the user), such as switching from voice to fax transfer mode to accommodate a fax transmission.

2.6.1 Specifying Default Endpoint Behavior

When an application creates an MSPP endpoint with mspCreateEndpoint, it uses an address structure to specify the addresses associated with the endpoint. A parameter structure defines the endpoint's default behavior. The following example shows the DS0_ENDPOINT_ADDR structure:

typedef struct tag_DS0_ENDPOINT_ADDR
{
  /* Address attributes */   
  INT32           nTimeslot;           /* Timeslot address */
} DS0_ENDPOINT_ADDR;

The following example shows the DS0_ENDPOINT_PARMS structure:

typedef struct tag_DS0_ENDPOINT_PARMS
{
  MSP_MEDIA  media; 
} DS0_ENDPOINT_PARMS;

The DS0_ENDPOINT_PARMS structure defines whether the DS0 endpoint transfers data in voice or fax mode.

When the endpoint is connected, it will process data according to the settings specified when it was created.

For more specific information about MSPP endpoint address and parameter structures, refer to Appendix C.

2.6.2 Sending Commands to Endpoints

Applications can change some parameters in an existing endpoint's configuration with mspSendCommand. The mspSendCommand enables applications to change settings specified in the address and parameters structures when the endpoint is created. In addition, applications can use mspSendCommand to change IP addresses and parameters, and DS0 parameters.

When using mspSendCommand, specify a unique ephd (returned by mspCreateEndpoint), the name of a valid endpoint command, and the new value to assign for the associated parameter. If data is returned in the MSPEVN_SENDCOMMAND_DONE event, the event.buffer field will contain a pointer to the data and the event.size field will contain the size of the data returned. After receiving a MSPEVN_SENDCOMMAND_DONE event, the application must always free the associated buffer with mspReleaseBuffer.

Note: RTP and UDP endpoints must be disabled before any commands are sent to them.

2.7 Controlling MSPP Channels

Each MSPP channel is composed of a linked set of processes, called filters, organized to carry out a set of operations with data that flows through the channel. Each filter performs a specific task or set of tasks with the data that flows through the channel. For example an MSPP G.723.1 channel includes the following filters:

Filter	Description
RTP disassembler	Disassembles RTP packets into one or more media frames.
Jitter	Eliminates or reduces jitter in a packet sequence by rearranging the packets in the correct temporal order.
Bridge	Interprets signals from the DSP to pull data from a filter at fixed intervals and provide the DSP with a uniform flow of data for decode processing.
G.723.1 decoder	Decodes and decompresses G.723.1 voice data.
G.723.1 encoder	Encodes and compresses voice data according to the G.723.1 algorithm.
RTP assembler	Assembles one or more media frames into a single RTP packet.

Figure 7 shows the linked filters that make up a G.723.1 full duplex channel. Notice that a separate set of filters process the data depending on the direction in which it moves between the two networks. For more information on MSPP filters, see the Fusion MSPP Service Filter Reference Manual.

Figure 7. MSPP G.723.1 Channel Filters

2.7.1 Specifying Default Channel Behavior

When you create an MSPP channel with mspCreateChannel, you specify two structures that define the channel: an address structure and a parameter structure. Each MSPP channel type consists of a predefined set of filters linked together to perform a particular combination of tasks. For example, a G.723.1 channel encodes/decodes data according to the G.723.1 algorithm as the data passes between a PSTN and packet network. Other predefined channel types include G.729A channels, G.711 channels, G.726 channels, and T.38 Fax channels.

By specifying the channel's type, you specify the particular chain of filters that will process the data sent between two endpoints. Any filter that can perform a range of tasks initializes in its default configuration. For example, a G.723.1 channel's decoder filter does not perform frequency suppression for DTMF tones by default. You can change this setting with mspSendCommand.

For more information about the filters that make up each type of MSPP channel, refer to the Fusion MSPP Service Filter Reference Manual.

2.7.2 Sending Commands to Channels

Once you have created an MSPP channel and connected it to a pair of endpoints, you can control the component channel filters with mspSendCommand. mspSendCommand conveys a filter-specific command to a connected channel.

Note: MSPP channels must be connected before they can receive mspSendCommand commands. In addition, certain channel filters (voice encoders, voice decoders, and T.38 fax modulator/demodulator filter) have to be enabled before you can command them.

When invoking mspSendCommand, you specify a chnhd, a valid filter ID concatenated with a valid command ID, and a buffer where you have specified specific command information.

Channel commands are executed by the filters that make up the channel. Each filter that makes up the channel responds to a specific set of commands, and command information is passed in the form of a predefined structure.

For example, if the application wants to send a command to the Jitter filter within a connected G.723.1 channel, it must invoke mspSendCommand and provide:

• A valid MSPP chnhd

• A valid filter ID concatenated with a valid command ID

• A pointer to the following structure:
  typedef struct tag_msp_FILTER_JITTER_CMD
  {
  DWORD value;
  } msp_FILTER_JITTER_CMD;

• The size of the previous structure

To build an MSPP filter command, use the macro mspBuildCommand (defined in mspcmd.h) to concatenate a valid MSPP filter ID with a channel command.

The specific manner in which the MSPP Service executes the command is based on the entry the application provides in the value field of the jitter_cmd structure. Within this structure, the application can control transmission jitter by adjusting the jitter depth.

For information about the filters that make up each type of MSPP channel, the commands to which these filters respond, and structures by which command options are specified, refer to the Fusion MSPP Service Filter Reference Manual.

2.8 MSPP Filter Command Events

When applications send commands to MSPP endpoints and channel filters (with mspSendCommand), they receive events that specify:

• The endpoint or channel that received the command

• The command that was sent

• Whether the command was executed

• Channel filter object ID (if the command was sent to a channel)

• Any additional information concerning the process taking place

Endpoints and channel filters return event information in the following ways:

Command Type	Event Information
endpoint commands	The lower byte of the event.id field in the MSPEVN_SENDCOMMAND_DONE event identifies the command. The event.objHd field specifies the associated endpoint handle.
channel filter commands	The lower byte of the event.ID field in the MSPEVN_SENDCOMMAND_DONE event identifies the command ID. The event.objHd field specifies the associated channel handle. The event.buffer field provides a pointer to the filter ID and can also include additional return data (when event.size is equal to 0).

The following table shows information included in the MSPEVN_SENDCOMMAND_DONE event returned in response to mspSendCommand:

This field...	Specifies...
event.id	The command ID.
event.objHd	ephd or chnhd of the endpoint or channel to which the command was directed.
event.value	CTA_REASON_FINISHED or an error.
event.buffer	For channel filter commands, specifies the channel filter ID. Depending on the value specified in the event.size field, this may return addition information.
event.size	Size of the buffer.

The lower byte of MSPEVN_SENDCOMMAND_DONE event.id field specifies the command ID of the associated filter command. The event.obj field specifies the endpoint or channel handle of the MSPP component that received the command. For example, if an application uses mspSendCommand to set jitter depth, then the MSPEVN_SENDCOMMAND_DONE event.id will be:

0x001b2100

Where the event.id filed is 0x001b21xx and the command ID for MSP_CMD_JITTER_CHG_DEPTH is 00. The event.value field for that event indicates the status of the command (i.e., SUCCESS or a failure reason code).

Because each MSPP filter may support up to 240 unique commands, the range of command codes for each filter is between 0x00 - 0xEF.

2.8.1 Unsolicited Events

The MSPP returns unsolicited events to the application when a channel or endpoint detects a particular condition. These events are not responses to specific filter commands, and can be returned at any time while a channel or endpoint is active. Depending on the filter, the endpoint may automatically send unsolicited events when it is created, or may need to be configured or commanded to send the unsolicited events.

For example, when an application creates and connects a T.38 fax standby channel, the T.38 fax UDPTL decoder automatically begins monitoring any data passing through the connected UDP endpoint to see if it detects any T.38 packets. If it detects a T.38 fax packet, it automatically sends up an unsolicited event notifying the application. For information on the T.38 fax decoder, as well as other MSPP filters, consult the Fusion MSPP Service Filter Reference Manual.

However, RTP endpoint filters don't return unsolicited events with RTCP monitoring information unless the application explicitly turns on this monitoring. The application initiates RTCP monitoring by setting certain parameter values in the RTPRTCP_ENDPOINT_PARMS structure it sends when creating the endpoint filter (with mspCreateEndpoint).

Note: After receiving a DONE event, the application must always free the associated buffer with mspReleaseBuffer.

The following table describes unsolicited events returned by MSPP filters:

Event	Associated Filter	Description
MSPEVN_RTCP_REPORT	RTP endpoint filter	Provides RTCP information concerning a particular voice connection. Useful for monitoring packet quality of service (QOS).
MSPEVN_FAXRELAY_FAX_BEGIN MSPEVN_FAXRELAY_FAX_END MSPEVN_FAXRELAY_PASSED_PAGE	T.38 fax modulator/demodulator channel filter	Returns status information about an active T.38 fax session.
MSPEVN_T38_PACKET_DETECTED	T.38 UDPTL decoder channel filter	Notifies the application that a T.38 fax packet has been received by a T.38 fax standby channel (that is, voice fax switchover can be initiated).