JBoss.orgCommunity Documentation
Media services have played an important role in the traditional Time Division Multiplexing ( TDM )-based telephone network. As the network migrates to an Internet Protocol ( IP )-based environment, media services are also moving to new environments.
One of the most exciting trends is the emergence and adoption of complementary modular standards that leverage the Internet to enable media services to be developed, deployed and updated more rapidly than before in a network architecture that supports the two concepts called provisioning-on-demand and scaling-on-demand .
The Media Server's high degree of modularity benefits the application developer in several ways. The already-tight code can be further optimized to support applications that require small footprints. For example, if PSTN interconnection is unnecessary in an application, then the D-channel feature can be removed from the Media Server. In the future, if the same application is deployed within a Signaling System 7 ( SS7 ) network, then the appropriate endpoint can be enabled, and the application is then compatible.
The Media Server architecture assumes that call control intelligence lies outside of the Media Server, and is handled by an external entity. The Media Server also assumes that call controllers will use control procedure described by protocols such as MGCP , MEGACO or MSML , among others. Each specific control module can be plugged in directly to the server as a standard deployable unit. Utilizing the JBoss Microcontainer for the implementation of control protocol-specific communication logic allows for simple deployment. It is therefore unnecessary for developers to configure low-level transaction and state management details, multi-threading, connection-pooling and other low-level details and API s.
The Mobicents Media Server call control intelligence can be a JSLEE Application deployed on Mobicents JAIN SLEE Server or any other JAIN SLEE container. In case of Mobicents JSLEE Server there is already MGCP Resource Adaptor available.
Mobicents Media Server can also be controlled from Mobicents SIP Servlets or any other SIP Servlets container using any of the above call control procedures or using the Mobicents JSR-309 Implementation. Mobicents JSR-309 Implementation internally leverages MGCP protocol to controll media server. Mobicents JSR-309 implementation details is out of scope of this document.
It is also possible to control the Mobicents Media Server from any third party Java application (including standalone Java apps) or other technologies like .NET etc as far as they follow standrad protocols like MGCP, MEGACO etc. There is no dependency on call controller but the protocol used between the call controller and Mobicents Media Server.
Many key features of Mobicents Media Server are provided by integrating individual components operating using generic Service Provider Interface. There are two of types of high level components: Endpoints and Controllers.
It is convenient to consider a media gateway as a collection of endpoints. An endpoint is a logical representation of a physical entity such as an analog phone or a channel in a trunk. Endpoints are sources or sinks of data and can be either physical or virtual. Physical endpoint creation requires hardware installation, while software is sufficient for creating virtual endpoints. An interface on a gateway that terminates at a trunk connected to a PTSN switch would be an example of a physical endpoint. An audio source in an audio content server would be an example of a virtual endpoint.
The type of the endpoint determines its functionality. Our analysis, so far, has led us to isolate the following basic endpoint types:
digital signal 0 ( DS0 )
analog line
announcement server access point
conference bridge access point
packet relay
Asynchronous Transfer Mode ( ATM ) "trunk side" interface
This list is not final: other endpoint types may be defined in the future, such as test endpoints which could be used to check network quality, or frame-relay endpoints that could be used to manage audio channels multiplexed over a frame-relay virtual circuit.
Descriptions of Various Access Point Types
An announcement server endpoint provides access, intuitively, to an announcement server. Upon receiving requests from the call agent, the announcement server “plays” a specified announcement. A given announcement endpoint is not expected to support more than one connection at a time. Connections to an announcement server are typically one-way; they are “half-duplex” : the announcement server is not expected to listen to audio signals from the connection. Announcement access points are capable of playing announcements; however, these endpoints do not have the capability of transcoding. To achieve transcoding, a Packet Relay must be used. Also note that the announcement server endpoint can generate tones, such as dual-tone multi-frequency (DTMF).
An Interactive Voice Response ( IVR ) endpoint provides access to an IVR service. Upon requests from the call agent, the IVR server “plays” announcements and tones, and “listens” for responses, such as ( DTMF ) input or voice messages, from the user. A given IVR endpoint is not expected to support more than one connection at a time. Similarly to announcement endpoints, IVR endpoints do not possess media-transcoding capabilities. IVR plays and records in the format in which the media was stored or received.
A conference bridge endpoint is used to provide access to a specific conference. Media gateways should be able to establish several connections between the endpoint and packet networks, or between the endpoint and other endpoints in the same gateway. The signals originating from these connections are mixed according to the connection “mode” (as specified later in this document). The precise number of connections that an endpoint supports is characteristic of the gateway, and may, in fact, vary according to the allocation of resources within the gateway.
A packet relay endpoint is a specific form of conference bridge that typically only supports two connections. Packet relays can be found in firewalls between a protected and an open network, or in transcoding servers used to provide interoperation between incompatible gateways, such as gateways which don't support compatible compression algorithms and gateways which operate over different transmission networks, such as IP or ATM.
An echo—or loopback—endpoint is a test endpoint that is used for maintenance and/or continuity testing. The endpoint returns the incoming audio signal from the endpoint back to that same endpoint, thus creating an echo effect
Controller Modules allows external interfaces to be implemented for the Media Server. Each controller module implements an industry standard control protocol, and uses a generic SPI to control processing components or endpoints.
One such controller module is the Media Gateway Control Protocol (MGCP). MGCP is designed as an internal protocol within a distributed system that appears to outside as a single VoIP gateway. The MGCP is composed of a Call Agent, and set of gateways including at least one "media gateway" which performs the conversion of media signal between circuit and packets, and atleast one "signalling gateway" when connected to SS7 controlled network. The Call Agent can be distributed over several computer platforms.
The Mobicents Media Server is developed on top of existing Java technologies. The Java platform is ideal for network computing. It offers single, unified-and-unifying programming model that can connect all elements of a business infrastructure. The modularization effort is supported by use of the JBoss Microcontainer which allows to deploy services written as Plain Java Objects into a Standard Java SE runtime environment in controlled manner and achieve great level of customization. Dependencies are fully managed to ensure that new services cannot be deployed until services they depend on have first been deployed. Where it makes sense to do so you can even re-deploy services at runtime providing that you access them via the microcontainer bus. Undeploying a service causes all dependent services to be undeployed first in order to maintain the integrity of the system.
To achieve the modularization every media component's in Mobicents Media Server (like AudioPlayer, Recorder, DTMF Detector/Generator) are identified as either MediaSource or MediaSink. As name suggests MediaSource is the one that has capability to generate media (AudioPlayer) while MediaSink (Recorder) is the one that consumes media.
For creating any component Media Server uses suitable Factory. Each component has its unique identifier and name defined by its factory. Component identifier is unique within the entire server implementation. The name of component in opposite way is shared across component produced by same factory.
Each of the Endpoints declared in Mobicents Media Server are composition of these Media Source/Sink and also depends on how each of these media components are ordered. For example which media component is first in line to consume/produce media. The transition of media through this ordered media components is achieved by Channels.
Channel is not a media component but it is able to join with Media Source and Media Sink or join with other channel. The role of channel is to construct media flow path by joining components using pipes.
Each Pipe has either inlet or outlet or both defined. A Pipe with only inlet defined acts as exhaust for a channel while Pipe with only outlet acts as intake for a Channel. If a Pipe has both inlet and outlet defined, it means its an internal pipe joining two components.
For example in diagram above Pipe1 (joining source and Component A) is the one with only outlet defined and Pipe3 (joinig sink and Component B) is the one with only inlet defined while Pipe2 (joining Component A and Component B) has both inlet and outlet defined and hence acts as internal pipe joining Component A and Component B.
Endpoints may only decalre Channel to receive media (Rx-Channel) or Channel to send media (Tx-Channel) or Channel for both receiving as well as sending media.
In addition to Channels, each Endpoints also has either MediaSource or MediaSink or both acting as primary source/sink of Media. If Endpoint doesn't have primary MediaSource or MediaSink it needs to declare the ResourceGroup which is a container for MediaSource and MediaSink. For exampl IVR Endpoint has both MediaSource and MediaSink while Conference Endpoint has ResourceGroup (ConferenceBridge)
Table 4.1. Component Definition
Component | Media Source | Media Sink | Component Factory | Description |
---|---|---|---|---|
AudioPlayer | yes | no | org.mobicents.media.server. impl.resource. audio.AudioPlayerFactory | AudioPlayer is capable of playing pcma, pcmu, speex, gsm, linear, linear 44100 mono, linear 44100 stero encoded files |
Recorder | no | yes | org.mobicents.media.server. impl.resource. audio.RecorderFactory | Recorder is capable of recording in pcma, pcmu, linear formats |
Rfc2833Detector | no | yes | org.mobicents.media.server. impl.resource. dtmf.Rfc2833DetectorFactory | Rfc2833Detector is capable of detecting RFC2833 RTP Events. Basically used for DTMF detection. |
Rfc2833Generator | yes | no | org.mobicents.media.server. impl.resource. dtmf.Rfc2833GeneratorFactory | Rfc2833Generator is capable of generating RFC2833 RTP Events. Basically used for DTMF generation. |
InbandDetector | no | yes | org.mobicents.media.server. impl.resource. dtmf.InbandDetectorFactory | InbandDetector is capable of detecting inband DTMF. InbandDetector is mostly used when detecting DTMF from conventional SS7 line where as Rfc2833Detector is used only for IP netwrok |
InbandGenerator | yes | no | org.mobicents.media.server. impl.resource. dtmf.InbandGeneratorFactory | InbandGeneratorFactory is capable of generating inband DTMF. InbandGenerator is mostly used when generating DTMF on conventional SS7 line where as Rfc2833Generator is used only for IP netwrok |
Player | yes | no | org.mobicents.media.server. impl.resource. audio.soundcard.PlayerFactory | This is special kind of component to play the media directly on sound hardware installed on Media Server. The sound hardware is any hardware that can understand the Format of media arriving. For example to directly play media on audio card of computer where media server is running |
Demultiplexer | yes | no | org.mobicents.media.server. impl.resource. DemuxFactory | A Demultiplexer is one that has one media stream as input but can produce many media stream as output. For example Demultiplexer can be in path of IVR endpoint RxChannel and output's from Demultiplexer can be connected to InbandDetector as well as Rfc2833Detector using Pipe. |
Multiplexer | no | yes | org.mobicents.media.server. impl.resource. MuxFactory | A Multiplexer is one that has many media stream's as input but will produce only one media stream as output. For example Multiplexer can be in path of IVR endpoint TxChannel and input's of Multiplexer can be connected to InbandGenerator as well as Rfc2833Generator using Pipe. |