Media Gateway (MG) Stack

MG(4) provides an introductory manual page for MG Switching stack components and interfaces. You can also select one of the component or interface sections from the diagram below:

Components

Interfaces

Components

MG Stack Manager (MGLM)

This section provides a roadmap to Manual Pages for Voice over IP (VoIP) Stack Manager (VoIP SM).

Media Gateway (MG)

This section provides a roadmap to Manual Pages for Media Gateway (MG).

H.248/MEGACO

This section provides a roadmap to Manual Pages for Media Gateway Control (H.248/MEGACO).

Media Gateway Control Protocol (MGCP)

This section provides a roadmap to Manual Pages for Media Gateway Control Protocol (MGCP).

Channel Driver

This section provides a roadmap to Manual Pages for Multiplex/Channel (MX/CH).

Real-Time Transport Protocol (RTP)

This section provides a roadmap to Manual Pages for Real-Time Transport Protocol (RTP).

MXI

Section: Multiplex Interface (MXI) (7)
Updated: 2008-10-31
Index Return to Main Contents

NAME

mxi - Multiplex Interface (MXI)

SYNOPSIS

#include <ss7/mxi.h>
#include <ss7/mxi_ioctl.h>

int mx_stream = open(mx_device, flags);

DESCRIPTION

The Multiplex Interface (MXI) specifies a STREAMS(4)-based kernel-level instantiation of a Multiplex interface definition compatible with the Media Gateway, mg(4), driver. The Multiplex Interface (MXI) enables the user of a multiplex to access and use any variety of conforming communications media multiplexors, without specific knowledge of the provider's protocol. The service interface is designed to support any media multiplex service provider, and does not address issues concerning multiplex management, protocol performance, and performance analysis tools. The specification assumes that the reader is familiar with the ITU-T synchronous digital hierarchy, ITU-T multiplex specifications, and STREAMS(4).

MXI specifies and interface that supports the service provided by various low level device drivers such as the X400P-SS7 driver, x400p(4), and X100P-SS7 driver x100p(4). These specifications are targeted for use by developers and testers of protocol modules that require multiplex service.

The Multiplex Service Provider

The Multiplex Service Provider provides the means to manage the connection and disconnection of channels within a multiplex. It is a local control protocol in the sense that there are not necessarily any remote peer entities. Communications is between the local user entity and the local provider entity.

Model of the MXI

The MXI defines the services provided by the multiplex service provider to multiplex service user at the boundary between the multiplex service provider and the multiplex service user entity. The interface consists of a set of primitives defined as STREAMS(4) messages that provide access to the multiplex services, and are transferred between the multiplex services user entity and the multiplex service provider entity. These primitives are of two types: ones that originate from the multiplex serivce user (MXU), and others that originate from the multiplex service provider (MXP). The primitives that originate from the MXU make requests to the MXP, or respond to an indication or event of the MXP. The primitives that originate from the MXP are either confirmation of a request or are indications to the MXU that an event has occurred.

The MXI allows the MXP to be configured with any media multiplex (such as H.223 multiplexors) that also conform to the MXI. An MXU can also be a user program that conforms to the MXI and accesses the MXP via putmsg(2) and getmsg(2) system calls.

MXI Services: The features of the MXI are defined in terms of services provided by the MXP, and the individual primitives that may flow between the MXU and the MXP.
Local Management: The MXI specification also defines a set of local management functions. These services have significance only to the local stream.

MXI SERVICES DEFINITION

The MXI services as categorized as Local Management Services, Connection Services, Event Services and Media Services as follows:

Local Management Services

The multiplex service provider provides the following local management services:

Information Service. The information service provides the multiplex service user with the ability to query the multiplex service provider concerning options and parameters specific to the mutiplex service provider and associated with attached channels. The information service uses the following primitives:

---: MX_INFO_REQ(7): Requests information about the associated multiplex service provider and attached channels.
---: MX_INFO_ACK(7): Indicates information about the associated multiplex service provider and attached channels.

Options Management Service. he options management service provides a mechanism whereby the multiplex service user can query and change parameters associated with the attached channels and manage options associated wtih the multiplex service provider. The options management service uses the following primitives:

---: MX_OPTMGMT_REQ(7): Manges the specified options.
---: MX_OPTMGMT_ACK(7): Acknowledges that the management of the previously specified options is complete.

Channel Attachment Service. The channel attachment service provides the multiplex service user with the ability to attach a specified channel to a slot in the multiplex associated with the requesting stream for a stream associated with a MX_STYLE2 multiplex service provider. The channel attachment service is not available on a stream associated with a MX_STYLE1 multiplex service provider. The channel attachment service uses the following primitives:

---: MX_ATTACH_REQ(7): Requests that the specified channels be attached to the specified slots of the associated multiplex.
---: MX_OK_ACK(7): Acknowledges successful receipt of the channel attach request primitive.

Channel Detachment Service. The chanel detachment service provides the multiplex service user with the ability to detach a previously attached channel from the multiplex associated with the requesting stream. The requesting stream must be associated with a MX_STYLE2 multiplex service provider and must have previously successfully executed a MX_ATTACH_REQ(7) primitive. The channel detachment service uses the following primitives:

---: MX_DETACH_REQ(7): Requests that the specified channels be detached from the currently attached slots of the associated multiplex.
---: MX_OK_ACK(7): Acknowledges successful receipt of the channel detach request primitive.

Receipt Acknowledgment Service. The receipt acknowledgment service provides an indication to the multiplex service user of the positive or negative acknowledgment of the previous primitive issued by the multiplex service user requiring local acknowledgment. The receipt acknowledgment service uses the following primitives:

---: MX_OK_ACK(7): Acknowledges successful receipt and processing of the previous request primitive for which a local acknowledgment is outstanding.
---: MX_ERROR_ACK(7): Acknowledges unsuccessful (non-fatal error) receipt of the previous request primitive for which a local acknowledgment is outstanding.

Connection Services

The multiplex service provider provides the following connection services:

Enable Service. The enable service provides the multiplex service user with the ability to enable the multiplex and attached channels. Some multiplex service providers can enable channels (prepare them for operation) locally, and others will require exchanges with the transmission peers that will take some time before a multiplex can be enabled. The enable service uses the following primitives:

---: MX_ENABLE_REQ(7): Request that the multiplex and attached channels be enabled. This primitive requires local acknowledgment.
---: MX_OK_ACK(7): Acknowledges successful receipt of the enable request primitive.
---: MX_ENABLE_CON(7): Confirms that the multiplex and attached channels have been enabled as requested.

Disable Service. The disable service provides the multiplex service user with the ability to disable the associated multiplex and attached channels. Some multiplex service providers can disable the multiplex and attached channels (remove them from operation) locally, and others will require exchanges with the transmission peer that may take some time before the multiplex can be disabled. In addition, it is possible that an autonomous disabling of the multiplex occurs without the request of the multiplex service user. In this case, the multiplex disable service is used to indicate to the multiplex service user that an autonomous disabling of the multiplex has occured. The disable service uses the following primitives:

---: MX_DISABLE_REQ(7): Requests that the multiplex and attached channels be disabled. This primitive requires local acknowledgment.
---: MX_OK_ACK(7): Acknowledges successful receipt of the disable request primitive.
---: MX_DISABLE_CON(7): Confirms that the associated multiplex and attached channels have been disabled as requested.
---: MX_DISABLE_IND(7): Indicates that the associated multiplex and attached channels have been autonomously disabled.

Connect Service. The connect service provides the multiplex service user with the ability to connect a channel in the receive and/or transmit directions within an enabled multiplex. Some multiplex service providers can connect attached channels locally, and others will require exchanges with the transmission peer that will take some time before the channel can be connected in the specified direction. The connect service uses the following primitives:

---: MX_CONNECT_REQ(7): Requests that the specified attached and enabled channels within the multiplex be connected in the specified directions. This primitive requires local acknowledgment.
---: MX_OK_ACK(7): Acknowledges successful receipt of the channel connection request primitive.
---: MX_CONNECT_CON(7): Confirms that the indicated attached and enabled channels have been connected in the indicated directions as requested.

Disconnect Service. The disconnect service provides the multiplex service user with the ability to disconnect a connected channel within the multiplex in the the specified receive or transmit directions. Some multiplex service providers can disconnect channels locally, and others will require and exchange with the transmission peer that may take some time before the channel can be disconnected in the specified direction. In addition, it is possible that an autonomous disconnect occurs without the request of the multiplex service user. In this case, the channel disconnect service is used to indicate to the multiplex service user that an autonomous disconnection has occured in the indicated directions. The disconnect service uses the following primitives:

---: MX_DISCONNECT_REQ(7): Requests that the specified attached, enabled and connected channels within the multiplex be disconnected in the specified directions. This primitive requires local acknowledgment.
---: MX_OK_ACK(7): Acknowledges successful receipt of the channel disconnection request primitive.
---: MX_DISCONNECT_CON(7): Confirms that the indicated attached, enabled and connected channels have been disconnected in the indicated directions as requested.
---: MX_DISCONNECT_IND(7): Indicates that the indicated channels have been autonomously disconnected from the multiplex in the indicated directions.

Event Services

The multiplex service provider provides the following event services:

Notification Service. The notification service is used by the multiplex service provider to inform the multiplex service user that a specific event has occurred. The notification service uses the following primitives:

Media Services

The multiplex service provider provides the following media services:

Data Transfer Service. The data transfer service is ued by the multiplex service user to request the transmission of channel media data on the specified channel within the multiplex. It is also used by the multiplex service provider to indicate the reception of channel media data on the indicated channel. The data transfer service uses the following primitives:

---: MX_DATA_REQ(7): Requests that the specified media data be transmitted on the specified channel within the multiplex.
---: MX_DATA_IND(7): Indicates that the indicated media data was received on the indicated channel within the multiplex.

OPTIONS

The Multiplex Interface (MXI) does not define any general options at this time. Options specific to the underlying MX provider will be defined in the manual page for the specific MX provider.

CAVEATS

This documentation is not complete and needs some work before it is finalized.

FILES

The Multiplex Interface (MXI) is defined in the <sys/mxi.h> and <sys/mxi_ioctl.h> header files. Additional header files are specified by specific providers of the MXI interface.

DEVICES

The Multiplex Interface (MXI) does not provide any devices of its own. Specific providers of the interface will provide their own devices.

MODULES

Some generic STREAMS(4) modules can be provided that convert between the MXI interface and other interfaces (such as the CHI).

VERSIONS

This manpage was written for MXI Version 1.

REFERENCES

[1]: MXI, Multiplex Interface (MXI) Specification, Revision 0.9.2, Draft 2, July 15, 2007, (Edmonton, Canada), B. Bidulock, OpenSS7 Corporation. <http://www.openss7.org/specs/mxi.pdf>