en-US.concept-chapter-Introduction_to_the_Media_Server.xml Maven / Gradle / Ivy
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"> <!-- chapter id nickname: ittms --> <chapter id="ittms-Introduction_to_the_Media_Server"> <title>Introduction to the Mobicents Media Server</title> <section id="ittms-Overview-the_Reasoning_and_Need_for_Media_Servers"> <title> Overview: the Reasoning and Need for Media Server </title> <formalpara> <title>Media Gateways Bridge Multiple Technologies</title> <para> Today, computers play an important role in modern communications. Widespread access to broadband Internet and the ubiquity of Internet Protocol ( <acronym>IP</acronym> ) enable the convergence of voice, data and video. Media gateways provide the ability to switch voice media between a network and its access point. Using Digital Subscriber Line ( <acronym>DSL</acronym> ) and fast-Internet cable technology, a media gateway converts, compresses and packetizes voice data for transmission back-and-forth across the Internet backbone for landline and wireless phones. Media gateways sit at the intersection of Public Switched Telephone Networks ( <acronym>PSTN</acronym> s) and wireless or IP-based networks. </para> </formalpara> <formalpara> <title>Why Media Gateways for VoIP Is Needed</title> <para> Multiple market demands are pushing companies to converge all of their media services using media gateways with Voice-over-IP ( <acronym>VoIP</acronym> ) capabilities. Some of the expected benefits of the architecture are as follows: </para> </formalpara> <variablelist> <varlistentry> <term>Lowering initial costs</term> <listitem> <para> Capital investment is decreased because low-cost commodity hardware can be used for multiple functions. </para> </listitem> </varlistentry> <varlistentry> <term>Lowering development costs</term> <listitem> <para> Open system hardware and software standards with well-defined applications reduce costs, and Application Programming Interfaces ( <acronym>API</acronym> s) accelerate development. </para> </listitem> </varlistentry> <varlistentry> <term>Handling multiple media types</term> <listitem> <para> Companies want <acronym>VoIP</acronym> solutions that are extensible and that will be ready to handle future needs like, video. </para> </listitem> </varlistentry> <varlistentry> <term> Lowering the costs of deployment and maintenance </term> <listitem> <para> Standardized, modular systems reduce training costs and maintenance while simultaneously improving uptime. </para> </listitem> </varlistentry> <varlistentry> <term>Enabling rapid time-to-market</term> <listitem> <para> Early market entry hits the window of opportunity and maximizes revenue. </para> </listitem> </varlistentry> </variablelist> <formalpara> <title>What Is the Mobicents Media Server?</title> <para> The Mobicents Media Server is an open source Media Server aimed at: </para> </formalpara> <itemizedlist> <listitem> <para> Delivering competitive, complete, best-of-breed media gateway functionality of the highest quality. </para> </listitem> <listitem> <para> Meeting the demands of converged wireless and landline networks, DSL and cable broadband access, and fixed-mobile converged <acronym>VoIP</acronym> —— networks from a singleand singularly-capablemedia gateway platform. </para> </listitem> <listitem> <para> Increasing flexibility with a media gateway that supports a wide variety of call control protocols, which possesses an architecture that can scale to meet the demands of small-carrier providers as well as large enterprises. </para> </listitem> </itemizedlist> <para> Because Mobicents Media Server is Java based, it is cross platform, easy to install and run on any operating system that supports Java. The available source code is a powerful tool to debug the server and understand processing logic. It also gives you the flexibility to create customized components and configurations. </para> <para> Form version 2.0.0, the Mobicents Media Server is available either as embedded in JBoss AS 5.x.y or Standalone. </para> </section> <section id="ittms-Technical_specification_and_capacity"> <title>Technical Specification and Capacity</title> <para>The Mobicents Media Server is capable of</para> <itemizedlist> <listitem> <para> Media and Coders : <itemizedlist> <listitem> <para>G711 (a-Law, u-Law)</para> </listitem> <listitem> <para>GSM</para> </listitem> <listitem> <para>Linear PCM(L16)</para> </listitem> <listitem> <para>G729</para> </listitem> <listitem> <para>DTMF(RFC 2833, INBAND)</para> </listitem> </itemizedlist> </para> </listitem> <listitem> <para> Media Files : <itemizedlist> <listitem> <para>WAV</para> </listitem> <listitem> <para>GSM</para> </listitem> </itemizedlist> </para> </listitem> <listitem> <para> Signaling and control : <itemizedlist> <listitem> <para>MGCP</para> </listitem> <listitem> <para>Java Media Control API(JSR-309)</para> </listitem> </itemizedlist> </para> </listitem> <listitem> <para> Capacity : Typical media sessions per server <itemizedlist> <listitem> <para> • G.711 , L16 @20ms – 500+ per cpu core </para> <para> • GSM @ 20ms – 95 GSM mixed with 380 G.711 , L16 , 475 overall per cpu core </para> <para> • G.729 @20ms – 45 GSM mixed with 180 G.711 , L16 , 225 overall per cpu core </para> <para> All benchmark tests where done on Amazon EC2 cloud instances. </para> </listitem> </itemizedlist> </para> </listitem> </itemizedlist> </section> <section id="ittms-Media_Server_Architecture"> <title>Media Server Architecture</title> <para> Media services have played an important role in the traditional Time Division Multiplexing ( <acronym>TDM</acronym> )-based telephone network. As the network migrates to an Internet Protocol ( <acronym>IP</acronym> )-based environment, media services are also moving to new environments. </para> <para> 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 rapidly. This is carried out in a network architecture that supports the two concepts called <emphasis>provisioning-on-demand</emphasis> and <emphasis>scaling-on-demand</emphasis> . </para> <section id="ittms-High_Level_Component"> <title>High level components</title> <para> 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 <acronym>PSTN</acronym> 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 ( <acronym>SS7</acronym> ) network, then the appropriate endpoint can be enabled, and the application is then compatible. </para> <mediaobject id="ittms-mms-MMSArchictecture-dia-MMS"> <imageobject> <imagedata align="center" width="550" fileref="images/mms-MMSArchictecture-dia-MMS2.jpg" format="PNG"></imagedata> </imageobject> </mediaobject> <para> 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 procedures such as <acronym>MGCP</acronym> , <acronym>MEGACO</acronym> or <acronym>MSML</acronym> , 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 <acronym>API</acronym> s. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> 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. </para> <section id="ittms-Endpoints"> <title>Endpoints</title> <para> 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 <acronym>PTSN</acronym> 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. </para> <para> The type of the endpoint determines its functionality. From the points considered so far, the following basic endpoint types have been identified: </para> <itemizedlist> <listitem> <para> digital signal 0 ( <acronym>DS0</acronym> ) </para> </listitem> <listitem> <para>analog line</para> </listitem> <listitem> <para>announcement server access point</para> </listitem> <listitem> <para>conference bridge access point</para> </listitem> <listitem> <para>packet relay</para> </listitem> <listitem> <para> Asynchronous Transfer Mode ( <acronym>ATM</acronym> ) "trunk side" interface </para> </listitem> </itemizedlist> <para> This list is not comprehensive. 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. </para> <variablelist> <title> Descriptions of Various Access Point Types </title> <varlistentry> <term>Announcement Server Access Point</term> <listitem> <para> An announcement server endpoint provides access, intuitively, to an announcement server. Upon receiving requests from the call agent, the announcement server <quote>plays</quote> 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 <quote>half-duplex</quote> : 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). </para> </listitem> </varlistentry> <varlistentry> <term> Interactive Voice Response Access Point </term> <listitem> <para> An Interactive Voice Response ( <acronym>IVR</acronym> ) endpoint provides access to an <acronym>IVR</acronym> service. Upon requests from the call agent, the <acronym>IVR</acronym> server <quote>plays</quote> announcements and tones, and <quote>listens</quote> for responses, such as ( <acronym>DTMF</acronym> ) input or voice messages, from the user. A given <acronym>IVR</acronym> 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. </para> </listitem> </varlistentry> <varlistentry> <term>Conference Bridge Access Point</term> <listitem> <para> 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 <quote>mode</quote> (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. </para> </listitem> </varlistentry> <varlistentry> <term>Packet Relay Endpoint</term> <listitem> <para> 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. </para> </listitem> </varlistentry> <varlistentry> <term>Echo Endpoint</term> <listitem> <para> 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 </para> </listitem> </varlistentry> </variablelist> </section> <section id="ittms-Controller-Modules"> <title>Controller Modules</title> <para> 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. </para> <para> 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" that perform the conversion of media signal between circuit and packets, and at least one "signalling gateway" when connecting to an SS7 controlled network. The Call Agent can be distributed over several computer platforms. </para> </section> </section> </section> </chapter>
© 2015 - 2025 Weber Informatics LLC | Privacy Policy