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:

Mobicents Diameter - reaches 1.0.2.GA !!!

Yes, thats true. Me and Alex managed to contribute enough time(even though he was sick and I was busy with personal erands) to make another diameter release. Still follow up will contain standalone documentation (yupieeee!!) with examples of configuration and setup.

More about release here.


Would like to make reminder about VM image we created with openIMS predeployed to make users life a bit easier, atleast for testing:

• image.
• readme.

Thats it for today. Cheers

3rd Annual Mobicents Metting: Brno 2009

This august was quiet a big deal, Mobicents Team met in Brno office which was kind enough(or else) to host annual meeting. Almost all of us made it to office without any incident, however we still missed three team members which did not make it.
As usual it was tons of work and work. Since last year mobicents grew a lot (maybe not a good estimate but svn code and commits have been more than doubled, with team not expanding at all) so we had a lot of topics to go through. During las year three of our project reached GA status:

• Sip Servlets
• Media Server
  
• Diameter

Two other has already got successor:

• Media Server
• JAIN Slee

In short last year achievements are:

• JSR 289 certification (Sip Servlets 1.1)
• JSR 240 certification( JSLEE 1.1, achieved by container v2.0.0.B1)
• Media Server modular architecture
• Diameter GA
• Seam Telco Framework reaching stability

During meeting four topics reached level of "hot":

• SS7 world mobicents role in IMS cloud
• JSLEE 1.1 container architecture
• HA
• Media Server architecture

(See next post for some cool stuff that we talked about or did not talk )
Thats how we spent our time in the office - except me and Amit killing each other bond style(we were supposed to go for paintball, but eventually it has been canceled).

My main project(aside Diameter and JSLEE) is Media Server for the time beeing. Thats the one me and my co-mates were supposed to cover during this meeting.
However one of our MMS team member did not make it to Brno me and Amit were supposed to cover his topics(MMS Architecture & SS7 introduction) - in practice presentations we created were covered by Amit.
Topics that left for me were

• Base HA framework - how to achieve HA for non cache replicated resources
• MMS Control protocols(which I did not present, see my other posts)

Seems like very abstract topic, atleast first one. Well thats correct. Moreover its not a trivial one (HA). During my preparations for this subject I made a lot of tests and research to get a hint what lies ahead of team to achieve. Its a bit scary I must tell. It gets insanly complicated since Mobicents covers different EE - just consider case when one has different EEs, different protocols and must provide HA and FT balancer for that bunch - feeling that headache comming?
Aside my HA session we had one covered by Jean D and Vladimir R. Outcome? To make it short:

• improve JSIP stack
• make JSIP stack modular so it supports replication of data
• finalize LB strategy
• cooperate on Fault Tolertant Framework

What if FTF? Simple acronym that should in future cover some cool features(See next posts :) ).

What about fun part?
It was not bad at all, even though academic year has not started:

Before plunging into disco:
Get up early, go to work, eat late and party till morning. Here we are at eating part, good food, perfect beer, even portugal folks prefered it over wine:

And here we give a go to extreme sports part, carts made it a day, except few of us getting burns blisters from engine, it was worth chasing other team members around track: