Architecture
The component architecture divides the process of constructing media services into two major parts:
- The implementation of components which generates or consume media data
- 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 :)
Posts
