JSLEE Maven Archetypes

Sometime ago Eduardo spent some time to create basic maven archetypes for JSLEE. Since 2.x CR1 of JSLEE is going out and there was a lot of google group traffic regarding setting up basic project, I dedicated some time to create similar package for JSLEE 1.1.

Here is wiki page which describes how to use archetypes (iirc). I will update it once I get spare 5 minutes.
Sources can be found here.

MMS v2 Beta3 is out

It took some time to reach this point. But ... its out. Another 2.x.y media server from mobicents has been born yesterday.

Details can be found in media server blog. In short, what does it bring?

• Video support for ISO files 
• RTSP support - this includes mobicents RTSP stack and MMS Controller
• SS7 support preview

Yes, SS7. At the moment its still not full, but allows to do some cool stuff.
Currently SS7 guide is short and can be found here. However next release will incorporate it in regular guide.
Roadmap can be found here.


So what those goodies allow?
Video is self explanatory. RTSP adds live streaming capability(its a bit like showcast radios on winamp with, but bit cooler since it allows operations like: pause, rewind - VCR style).

Finally SS7. We tested with real MSC on operators side. Tests performed:

• link setup and stability(long term IN_SERVICE)
• streaming
• MU validation(it takes time to learn how to read those bits)
• SCCP,TCAP and CAMEL testing.
  

CAMEL test has been performed by JSLEE 1.x.y application with JCC RA( it can be found in svn, code is very simple )


Here is what Media Server Team planned for MMS:

• stabilize core for CR1
• add other SS7 protocols as independent stacks(that can be used without MMS)
• B/D channels endpoints
• SS7 RAs for JSLEE 2.x and similar resource for MSS
  

If everything goes smootly next release will allow JSLEE and MSS to connect to legacy network and provide means of replacing Asterisk.

Big thanks to Vladimir for hand on HDLC part for MTP layers.

Seagull on F12 and GCC 4.3+

This is going to be short post. Alex made log of his probs working out through compilation of seagull on OS X. For me it turned out to be a bit harder.
Please read his post before going through my notes.

So what is fuss all about?
As it seems, aside all problems Alex had there are few new ones on Fedora 12.


First thing is that Fedora 12 ships with GCC 4.4.something. Since GCC 4.3, gcc becomes more strict. What is significant is that generation does not include standard header files by default. This causes GCC to complain about 'memcpy', 'strncpy' and other function not beeing defined. After going through all files, which cause gcc to fail and adding includes by hand I got a bit pissed of. (not sure if this is the good sollution) Once I boiled up, decided to add includes into common/Utils.hpp file.
File modification includes two lines:
#include "stdio.h"
#include "string.h"



Second thing that poped up was error with parentheses. It seems that Seagull team went the easy way and left a lot of statements like:

if( x = (vv == x))

GCC does not like those anymore and fails. Only sollution is to edit files and add () so ifs look like:
if( (x = (vv == x)))

Now after cleaning it went quite good. To point when linker started its work.

relocation R_X86_64_32 against  - this messages makes it to screen once ld goes into action.

It seems that "-fPIC" has not made it into make file. This seemed a bit odd, but... I got work-${version}/compile.mk into vim, edited and rerun. Again failure. Now, at this point it becomes a question why there are xxx.mk files, which do not affect build?
Sollution is quite simple. Add '-fPIC' to options BUILD_EXE_CC_FLAGS_LINUX and BUILD_LIB_CC_FLAGS_LINUX, present in build.conf.

Now clean compilation worked from kick.

Hope this helps. Cheers

Good stuff comes packed. JSLEE 2.0.00B2 and MMS news

Its been a while since I had a time to post here. Made myself a promise to post quite few usefull tips regarding JSLEE 2.x but never had time. Why? Because Mobicents team worked quite hard to be able to deliver good news.

So first thing. SLEE 2.0.00B2 is about to be let loose into community!
Made a lot of effort to make it quite a pack.
- HA/FT clustering API
- new HA api for RA implementation
- full replication of data and clustering of JSLEE servers !!!!
- performance improvements
- SIP11 RA tunning(more and more cps)
- BUG fixes

Each topic deserves separate post, once I have a second, I will do that with details and examples guide.

HA/FT clustering API(topic for another post) has ben created to ease development on this "side of moon".  It allows quite easy plugability into cluster, making application aware of changes. It is based on JBoss Cache and supports different replication strategies. I will describe it a bit more deeply in another post. If someone feels a desire to play with it I recomend browisng and playing with repository. So far we created a standalone, distributed timers(not tied to any of our project) it is quite good alternative to EJB3 timers and other implentation available(I would say its so far a best sollution, but...).I will describe example in another post(if someone feels like playing in a dark this will help.).


SLEE 1.1 specification is a great improvement since 1.0. Changes are quite significant so I even doubt why its 1.1, not 2.0, but thats just a speculation.  However, among all changes there is no definition of HA/FT api aside of Marshaller ( which is of no use without something specific to container). Thats why each implementation of JSLEE specification has to have some specific API to handle replication and FT in RA layer.
So, we had to do it. So far only SIP11 RA is aware of cluster. We have to make some more test, but its working and its quite nice feature, atleast after hours of coding its something that pays of effort.


Full replication. Yes, JSLEE 2.x container is FULLY replicable among cluster. There is no exception. Data and local server resources are handled properly to make SLEE developers work in unified enviroment, even though server runs on mulitple nodes.



Now what about MMS? Well me, Amit and Oleg took our time. All news will be official near release date. But what I can reveal is:
 - we are working on video and its going good
 - performance improvements - based on media path
 - SS7 enabled!, right now we are running test to see how SS7 link is stable, next are tests with CAMEL, ISUP, SCCP.


Thats it for now.

MMS 2.X - Console comes back

It happened. In 1.X branch we dropped console for some reasons (many discussion, outcome the same). During last MMS chat Oleg spoke words we believed noone will witnes him say: "Maybe its time for..."

Well thats the background. To make it short. We would like to announce that MMS 2.X will have management console. How it will look like? It all depends on feedback we get from users. We have general idea, but feedback and ideas are mostly welcome.
Design Wiki can be found here , public thread can be found here.

MMS - Control Protocols

In mobicents projects we have different EE:

• SLEE
• MSS
• . . . (maybe more)

In addition we also have Media Server. Media Server is only responsible for media part of applications. To make it short: regardless of application logic, signaling protocol utilized by application, media server role is always the same, to  process media.


EE is driven by some sort of protocol chosen by development team - which has complete freedom to choose one protocol over another, restricted only by project requirements. In case of media server it is not that easy. Over time different "parties" created different control protocols for media server (media gateway).
For instance with CISCO equipment media server is controled with MGCP, in IMS environment media server is controled with H.248, in WWW it can be controled with RTSP, etc, etc.

In Mobicents Media Server 1.x.y we support only MGCP (aside of local MSC API), however we felt that this is not enough to meet demand from partners and community (more on this here).
So for MMS 2.x we have more in plans:

• RTSP
• H.248
• MSML
• VXML

During Brno we were supposed to iterate over this short list, high light use  cases, differences and basic concepts. However we did not have enough time. So in order to compensate I decided to post it here.
Here we go.

Media Server Operation Model

As mentioned above media servers follow certain model of operation. See image below:

 

Media Server estabilishes only RTP stream exchanged between UAs. To setup streaming application makes use of some dedicated control protocol. Dedicated controler on Media Server side converts control protocol reqeusts into physical setup of underlying resources(generators,detectors, codecs, etc....). This happens regardles of signaling protocol used(on image it is SIP, but in reality it could be any suitable for application).

MSML: Media Server Markup Language

Basic inforamtion:

• XML Based
• It is independent of transport protocol ( SIP, HTTP, IP, ...)
• Follows simple request/response model
• Supports transactions
• Supports semi-recovery from errors
• Requires resource reservation
• RTP service oriented

MSML supports something similar to transaction on Media Server side. It is not strictly defined as transaction but has very similar semantic/behaviour. Each MSML request can be seen as set of actions. Each action has arbitrary ID, set by application developer.  If particular action fails, error response will contain this ID to make application aware of failure point - this is semi-recovery of error condition. MSML pinpoint exact place of failure, allowing application to free resources (yes, responsibility is pushed to application). This is required since Media Server does not reclaim them (according to MSML specs).

MSML is also RTP service oriented. Protocol does not define endpoint types as MGCP does for instance. It only defines actions that need to be undertaken to produce stream/interaction with user stream.

As protocol MSML is designed to be extensible, just as Diameter does. Functional elements are grouped into package. Each package defines set of primitives which affect Media Server. Prmitives are tags and their parameters which are intepreted by Media Server controler.
MSML allows new packages to be defined along ability to extend already defined. This is how whole language structure is defined. Definition from RFC are grouped as follows:

• Core
• Dialog-Core
• Conf-Core
• Audit-Core
  

Dialog-Core defines primitives to control automated actions of Media Server, it defines also subpackages to extend those capabilities:

• Dialog-Base
• Dialog-Transform
• Dialog-Speech
• .....

 MSML: Base abstraction

Base MSML abstraction defines functional elements which are aligned as in image below:

• conn - connection is logical unit which termiantes all RTP sessions from one UA
• operator - logical unit representing DSP
• dialog - set of automated actions like: play, DTMF generator/detector, etc...
• conf - logical unit which mixes streams

MSML: Protocol use example

 Below is use case of MSML encapsulated in SIP protocol.

MSML used inside SIP requires usually dialog to be established between application server and media server. MSML Requests/Answers are embeded in SIP INFO/INFO OK message.  

In image above there is only one UA, which awaits video to be played. However for different number of UAS scheme is similar - only difference is dialog time when dialog is estabilished between app server and media server.

In example scenario app server asks Media Server to play announcement like (this is MSML Dialog): "Press one to play movie XXXXX, Press two to play movie xXXYYx" and detect DTMFs. Once UA sends DTMF, Media Server sends DTMF embeded in SIP INFO back to application server and indication that MSML Dialog has ended. Application server decodes INFO, picks file to be streamed back to UA and starts new MSML Dialog: "Play Movie Dialog".

Other protocols will follow in subsequent posts.

Slee 1.1 Classloader demystified!

Here we go.

During our dev struggle to get v2 of Mobicents JSLEE container operational we encountered quite big problem: Class Loading scheme.
Usually class loaders are organized in classic tree structure:

• one root
• each leaf can have only one parent
• each leaf can be a root of a subtree

This has certain limitations, as proven by our JSLEE 1.0 container. Without classloader repositories/isolation there is no way for two versions of the same ra(service/Sbb/Profile) to be deployed and enabled.
Moreover it is not possible to maintain integrity of classes loaded - consider situation:

• DU1 has service using lib.jar
• DU2 also has service using lib.jar
• order of deply is: DU1,DU2
• when DU2 is deployed, classloader finds lib.jar classes and does not load them
• DU1 and DU2 services kick in, instances of lib.jar classes are created (from DU1 definition)
• now DU1 is undeployed
• error on class casting - vague information: can not cast XXYX.class to XXYX.class

Now regarding Mobicents JSLEE v1. JSLEE Specs did not define any way of providing dependency classes. To resolve this problem we altered a bit DU structure, each DU jar could have "library" dir with dependencies for particular DU. This proved to be enough to solve dependencies, however all above problems still apply.
Obviously JSR240 specs lead got a notion that specs lack something valuable here and in 1.1 it has been improved.
In 1.1 container "library" component has been introduced. It is not a functional component/jar - not in terms of slee, like SbbComponent or ProfileCompoment. Its only purpose is to provide standarised and versioned way to provide classes to Slee components. So no more DU/library!!
Now about classloaders. In SLEE v1.1 model has changed as well. Its a bit tricky. Consider classic model - tree, where each classloader with one parent. This is not sufficient for SLEE v1.1. New model allows multiple parent for each leaf to reflect components relation.

Classloaders are defined per component - that is not jar, but actual identifiable component(which has ComopnentID). Component class loader loads all classes from component jar "and" all classes from referenced components.
Consider case of jar file which contains definition of Sbb1, Sbb2 and Sbb3 - all sbb classes are in jar.

So:

• three classloaders - Sbb1,Sbb2, Sbb3 - each "has" classes from jar
• SbbX classloader has access to all referenced component classloaders

Actually component class loaders deffer queries to jar domain classloader to avoid that vague ClassCastException described above. Through references in xml descriptor classlaoder association is built(multiple parents - Sbb components usually references events, ras, other sbbs, profiles, etc...) - this is place where multiple parents are introduced. See diagram below, this should give a hint: