1.1 Introduction

1.2 Media Gateway Control Protocol

1.2.1 Call Agents and Media Gateways

1.2.2 Applications Servers and Media Servers

1.3 Fusion MGCP Service

1.3.1 MGCP Service Endpoints

1.3.2 MGCP Service Packages

1.3.3 Natural Access Service Interaction

1.4 Natural Access Development Environment

1.4.1 Synchronous and Asynchronous Functions

1.1 Introduction

The Media Gateway Control Protocol (MGCP) defines a model for using distributed application components to build voice over IP (VOIP) and media gateways. This model recommends using separate entities to perform call control, provide bearer trunks and media channels, and control signaling links for the gateway. Each application performs a specific set of tasks to control or transfer the data that passes through the gateway.

The Fusion MGCP service provides a simple set of functions for enabling programmers to rapidly develop basic trunk-oriented media gateway applications or media server applications.

Applications use Fusion MGCP service functions to:

• Register, initialize, and unregister MGCP gateway endpoints.

• Notify the controlling call agent of events received and signals generated.

• Define MGCP standard extension packages for the application.

The Fusion MGCP Service Developer's Reference Manual describes how to use the MGCP service to develop MGCP compliant media gateways and media servers. Use this reference in conjunction with the Fusion Developer's Manual.

This document defines telephony terms where applicable, but assumes readers are familiar with telephony concepts and switching. It also assumes that the user is familiar with the C programming conventions, IP telephony terms and concepts, and the Media Gateway Control Protocol (MGCP) as defined in RFC 2705.

1.2 Media Gateway Control Protocol

The MGCP model outlines a distributed media gateway environment that identifies separate modules responsible for transferring and processing data, for providing media services for application, and for controlling the flow of data through the system.

1.2.1 Call Agents and Media Gateways

A typical MGCP gateway environment connects on one side with a public switched telephone network (PSTN), and on the other side with an IP network. Specialized call agent applications control the flow of media data across the distributed environment. Call agents determine the route that data follows as it flows through the system. Multiple call agents can control call processing and data transfer. These call agents use a separate protocol to synchronize with each other and to send coherent commands to modules under their control.

Each call agent usually controls a set of gateway applications, including at least one media gateway. Media gateways convert media signals to an appropriate format depending on whether the signals are directed to a circuit switched network format or a packet switched network. Media gateways primarily perform audio signal translation functions in accordance with call agent commands.

Note: Gateways connected to an SS7 controlled network must also include at least one signaling gateway for controlling SS7 signaling.

The MGCP connection model consists of endpoints and connections. Endpoints represent physical or virtual sources through which data can flow (for example, PSTN ports on a media gateway). Call agents combine sets of endpoints under their control to create point-to-point or multipoint connections. Connections provide data paths for transferring and processing the data that flows through the gateway environment.

In the MGCP model, call control intelligence resides in the call agents, not in the media gateways. In effect, the MGCP standard defines a master/slave relationship between call agents and media gateways, where gateways execute commands sent by the call agents.

Figure 1 shows a scenario where call agents and media gateways use the Fusion MGCP service to communicate information about voice or fax calls placed and received through the media gateways. The media gateways then use the RTP or UDP protocols to transfer the voice or fax data across the packet network according to call agent commands.

Figure 1. Communication Between Call Agents and Media Gateways

1.2.2 Applications Servers and Media Servers

In another distributed network media scenario, specialized applications called media servers provide enhanced services (such as voice play and record functions) to the media gateways that transfer voice and fax data across an IP network. Media servers are controlled by application servers in the same way that media gateways are controlled by call agents.

Application servers and call agents synchronize with each other by using a protocol such as the Session Initiation Protocol (SIP), while media gateways and media servers transfer data according to the UDP or RTP protocols.

Figure 2 shows an example of an extended distributed network environment that includes application servers and media servers along with call agents and media gateways.

Figure 2. Communication Between Application Servers and Media Servers

1.3 Fusion MGCP Service

Developers use the Fusion MGCP service to create media gateway or media server applications that carry out the commands of controlling entities such as call agents or application servers. The MGCP service provides functions for registering MGCP endpoints and then receiving commands and sending status messages to these controlling entities in accordance with the MGCP standard.

1.3.1 MGCP Service Endpoints

Gateway applications use the MGCP service to register and put endpoints into service that act as entry or exit points (or in the case of duplex connections, both) for data as it moves from one end of a distributed media environment to another.

The MGCP service supports the following types of MGCP endpoints:

This endpoint...	Provides access to...
DS0	Trunk and ISDN interfaces that are part of digital T1 or E1 interfaces.
IVR	Services that can play announcements and tones, and listen to responses from users.
Announcement server	Announcement services that play specific announcements over point-to-point or multipoint connections.

For information about the different MGCP service endpoint types, refer to Section 2.6. For information about endpoints in the MGCP standard refer to RFC 2705.

When a Fusion media gateway application puts an MGCP endpoint in service, the MGCP service sends a message to the associated call agent informing the call agent that the endpoint is available. The call agent can then send requests to the media gateway to create connections between MGCP endpoints on different media gateways or to perform processing tasks with the data transferred through the endpoints.

1.3.2 MGCP Service Packages

By default, the Fusion MGCP service supports a wide set of packages defined by the MGCP standard. Some of these packages are the trunk package, DTMF package, RTP package, and announcement server package. The application specifies what packages an endpoint supports as it registers the endpoint. When a call agent makes a request that the endpoint supports, the MGCP service automatically performs any signal or event processing requested by a call agent. These processes are transparent to the application.

Developers can also define extension packages of signals and events not defined in the MGCP service's default package support. When using extension packages, the application performs the signal and event processing requested by the call agent. The MGCP service conveys call agent requests to the application through events. the MGCP service also enables the application to inform the call agent (through MGCP service functions) about the status of these requests.

1.3.3 Natural Access Service Interaction

The MGCP service enables applications to register and unregister endpoints that can be controlled by remote MGCP call agents. As the application registers MGCP endpoints, the MGCP service makes necessary calls to other Natural Access services to perform functions such as CT bus switching, media channel set up and tear down, or voice message play and record. Because the MGCP service makes these calls for the application, they are transparent to the application.

Note: If the gateway application uses MGCP service extension packages or overrides the default packages supported by the service, the application may need to explicitly call functions from other Natural Access services to perform processing and event handling functions.

For example, the MGCP service uses Fusion MSPP service functions to create media channels across the gateway. MGCP service endpoints actually contain MSPP service endpoints and MGCP connections. However, these MSPP service components are insulated from the application, and the application never explicitly calls MSPP functions.

Figure 3 shows Fusion MSPP service components that make up a Fusion MGCP service DS0 endpoint:

Figure 3. MSPP Service Components in MGCP DS0 Endpoints

Note: MSPP service filters cannot receive commands from the application when the MGCP service is in use.

Figure 4 shows Fusion MSPP service components used to make up Fusion MGCP service IVR or announcement server endpoints:

Figure 4. MSPP Service Components in MGCP IVR and Announcement Endpoints

1.4 Natural Access Development Environment

This section provides background information about Natural Access and summarizes the main elements of the Natural Access environment. Natural Access must be installed on your system and running in Server mode before applications can use the Fusion MGCP service.

For more detailed information about Natural Access, refer to the Natural Access Developer's Reference Manual.

1.4.1 Synchronous and Asynchronous Functions

Natural Access employs an asynchronous programming model to take advantage of concurrent processing. When called, most functions immediately return events that indicate the operation was initiated. The application can then perform other functions while Natural Access is processing the command.

Natural Access provides two types of functions in Natural Access: synchronous and asynchronous.

• Synchronous functions are complete when the return value is received. The return value can 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, can return the reason for the failure (in the value field of the event).

While functions execute, events are generated indicating the occurrence of certain conditions or state changes. If an asynchronous function fails after being initiated, Natural 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 MGCP service functions and indicates if they are synchronous or asynchronous.

Characteristic	Asynchronous	Synchronous
Operation is complete when the function returns.	No	Yes
Natural Access returns a DONE event when the function is complete.	Yes	No
The function can fail after the function returns.	Yes	No

As shown in Figure 5, for asynchronous functions, Natural 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 Natural Access, which makes them available to the application.

Figure 5. Natural Access and MGCP Service Functions and Events