Friday, June 19, 2009

Mobicents Media Server (MMS) v2.0.0.BETA1 Released!

Here comes a new improved Mobicents Media Server 2.0.0.BETA1. The 2.x.y efforts were focused on improving performance and at same time leveraging JBoss Microcontainer to come up with component based Media Server. All the media resources (sources or sinks) are POJO based. A common theme for Mobicents Media Server 2.x.y is the breaking out of internal fixed subsystems into stand­ alone components implemented as POJOs and the introduction of SPIs throughout the server codebase. Those changes should not affect directly the end user but they are an important part of the Mobicents Media Server strategy for making available the various voice/video services as independent components, so that they can be wired­ together on demand.

Architecture

The component architecture divides the process of constructing media services into two major parts:

  1. The implementation of components which generates or consume media data
  2. The assembly of chains of media components to build media flow path.

The following diagrams illustrates media components wiring and "implementation” process.As depicted on the diagram above we can isolate three main groups of the media components:

  • components which used for generation of media content or media source;
  • components which consumes media or media sink;
  • components which itself are neither sources nor sinks but provide access to sink or source like components A and B on diagram allow to access Input which acts as a sink and Output which is a source. The component which provide access to media sink as input is known as Inlet and component getting access to output as media source is called as Outlet.

The example of Inlet is Demultiplexer that has one input (sink) and many output (source). The example is Outlet is Multiplexer which has many input's (sinks) and one output (source)


Channels and pipes

This is one of the most important fundamentals of MMS and useful if you planing to create custom media path (custom Endpoint) in MMS. Channel is not a media component but it is able to join with Media Source and Media Sink or joined with other channel. The role of channel is to construct media flow path by joining components using pipes.Channel allows to easy assembly a required media path flow. Using multiplexers and demultiplexers media stream can be merged or splited, different signaling processors may be plugged in different places to achieve more flexibility or performance.


Performance

The initial test shows that for 300 concurrent announcements there is zero Jitter (no DSP involved). This is much better compared to MMS 1.x.y. The main reason for performance improvement is number of Threads has been reduced to very few. This was achieved by making use of NIO instead of plain sockets.

Here is a comparison table between the MMS 1.x.y and MMS 2.x.y

























































MMS 1.X.Y MMS 2.X.Y
Standalone MMS Server Not available Available
Embedded in JBoss AS JBoss AS 4.X.Y JBoss AS 5.X.Y
MGCP Support MGCP Support available via MGCP JAIN SLEE Service (SBB). Hence to use MGCP control protocol one needs to install JAIN SLEE Server, MGCP RA and mgcp-controller-sbb service MGCP Controller is inbuilt with MMS. No SLEE required
JSR-309 Support Not available JSR-309 is availale which uses MGCP as MS control protocol
MSC API Available. This is custom API developed by Mobicents Media Server. Not available
Performance Compared to 2.x.y, 1.x.y has very high Jitter problems due to large number of threads used. It uses plain sockets for RTP Very less Jitter as compared to 1.x.y. It uses NIO for RTP
Basic Architecture MMS 1.x.y is built on JMX Microkernel. No flexibility of deciding the media-path for endpoints. For example for IVR, DTMF detection will be used irrespective of application may use it or not. MMS 2.x.y is built on top of Jboss Microcontainer. Flexibility of defining the media-path for endpoints. For example if application will never detect DTMF but only recording, the DTMF detector media component can be completely removed from IVR endpoint and hence save some processing.




You can download the MMS 2.0.0.BETA1 from here

Follow the announcement here

Your valuable feed-back is welcome


Enjoy the MMS :)

Mobicents JSR-309 Impl 2.0.0.BETA1 Released!

A brief intro on what is JSR-309

JSR-309 defines a programming model and object model for Media Server (MS) control independent of MS control protocols. JSR-309 API is not an API for a specific protocol. It will take advantage of the multiple and evolving Multimedia Server capabilities available in the industry today and also provide an abstraction for commonly used application functions like multi party conferencing, multimedia mixing and interaction dialogs.

Some of the commonly used MS control protocols are MGCP (RFC 3435), MEGACO (RFC 3525), Media Server Markup Language (MSML) (RFC 4722) and VoiceXML. The Mobicents implementation of JSR-309 API makes use of MGCP as MS control protocol.

The Mobicents JSR-309 Impl is first and only open source implementation of JSR-309 available as of today. To further understand the JSR-309 API, download specs from here.

Still the TCK for JSR-309 is not available. We are eagerly waiting for TCK to be out.


The diagram bellow shows the high-level architecture of how application can make use of JSR-309 over MGCP


The first binary release is Mobicents JSR-309 IMpl 2.0.0.BETA1. This implementation can be used not only for controlling Mobicents Media Server, but any Media Server that understands MGCP Protocol.

You can download the mobicents-jsr309-impl-2.0.0.BETA1.zip from here

The public announcement is here

Cheers!