| Media Gateway (MG) StackDescription: OpenSS7 Project Manual Pages Media Gateway Switching StackMG(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:
ComponentsThis section provides a roadmap to Manual Pages for Voice over IP (VoIP) Stack Manager (VoIP SM). This section provides a roadmap to Manual Pages for Media Gateway (MG). 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). 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). MXISection: Multiplex Interface (MXI) (7)Updated: 2008-10-31 Index Return to Main Contents NAMEmxi - Multiplex Interface (MXI)SYNOPSIS#include <ss7/mxi.h>
DESCRIPTION
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 ProviderThe 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 MXIThe 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 DEFINITIONThe MXI services as categorized as Local Management Services, Connection Services, Event Services and Media Services as follows: Local Management ServicesThe 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:
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:
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:
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:
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:
Connection ServicesThe 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:
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:
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:
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:
Event ServicesThe 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 ServicesThe 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:
OPTIONSThe 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. CAVEATSThis documentation is not complete and needs some work before it is finalized. FILESThe 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. DEVICESThe Multiplex Interface (MXI) does not provide any devices of its own. Specific providers of the interface will provide their own devices. MODULESSome generic STREAMS(4) modules can be provided that convert between the MXI interface and other interfaces (such as the CHI). SEE ALSOMX_ATTACH_REQ(7), MX_CONNECT_CON(7), MX_CONNECT_REQ(7), MX_DATA_IND(7), MX_DATA_REQ(7), MX_DETACH_REQ(7), MX_DISABLE_CON(7), MX_DISABLE_IND(7), MX_DISABLE_REQ(7), MX_DISCONNECT_CON(7), MX_DISCONNECT_IND(7), MX_DISCONNECT_REQ(7), MX_ENABLE_CON(7), MX_ENABLE_REQ(7), MX_ERROR_ACK(7), MX_INFO_ACK(7), MX_INFO_REQ(7), MX_OK_ACK(7), MX_OPTMGMT_ACK(7), MX_OPTMGMT_REQ(7). VERSIONSThis manpage was written for MXI Version 1. REFERENCES
TRADEMARKS
Other trademarks are the property of their respective owners. IDENTIFICATION
Copyright©1997-2008OpenSS7 Corp.
All Rights Reserved.
Index
This document was created by man2html, using the manual pages. Time: 20:28:34 GMT, November 11, 2014 | |||||||||||||||||||||
Last modified: Thu, 30 Nov 2006 15:29:10 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. |