Fresh releases from Mobicents Kitchen

Last week or two were quite fruitful for mobicents team. What came out from under our hood?
Well:

• Jain MGCP Stack RC7 - last RC, more info can be found here.
• Diameter 1.2.0 GA - JSLEE 2.x resources, more info can be found here.
• MMS 2.0.0.RC1, first Release Candidate from 2.x trunk of MMS, more info can be found here.

More will come.

Maven Archetypes update

Some changes in maven tools in mobicents platofrm:

• fix metadata
• add jslee 1.1 service archetype

So now all desired archetypes are there.

Maven archetypes can be found here.

Also there is good article how to use archetypes to quick start projects, it can be found here.

How to use archetype from CLI? Please follow:

1. checkout
2. install with mvn install
3. use following command(for service):  mvn archetype:generate -DarchetypeGroupId=org.mobicents.tools.maven.archetype.slee -DarchetypeArtifactId=jain-slee-11-service -DgroupdId=xxx.y -DartifactId=TestSLee11Archetype_service -DarchetypeVersion=1.0.0.BETA2-SNAPSHOT , where:

• archetypeGroupId - archetype group
• archetypeArtifactId - id of archetype
• archetypeVersion - archetype version, once it is released, it should not be required
• groupdId - new groupd id of created project
• artifactId - new artifact id of created project, also directory name

JSLEE 1.1 service composition vs class loading

My last post about JSLEE 1.1 describes theory of classloading in v1.1 containers. However, how does it look in practice?

Well, I must say it looks and works much better than earlier model. But.. yes, there is one small "but", due to inheritance restriction it may sometime prove to be problematic, atleast for certain cases. 

Case 1: General Class Loading scheme

To make problem a bit closer, lets consider two services, each service is composed from the same sbbs:

 - Sbb[1]

 - Sbb[2]

 - Sbb[3]

Each sbb references the same RA Types and Profiles

 - RAType[1]

 - Profile[1]

 - Profile[2]

To make this a bit more complicated - each service is independent. That is each can be deployed separetly and provide service.

Now lets imagine two things:

• SBBs extends super class which provides common fields(RA Type SBB Interface) methods to manipulate profile, etc
• There is shared Utility class which manipulate RA Type message factories to create specific messages, manipulate profiles, etc.

Now there is no problem in 1.0 container as classloading was flat. Everything works fine, one or many sbb jars/DUs - it still works.

However when one wants to deploy this set of services in 1.1 container, problem shows. In 1.1 container (as it is a bit more organized) we would like to have everything separated:

• library(Library[1]) with: super class of SBBs, Utility classes and similar
• sbb-jar.xml, sbb-jar file for each sbb
• DU for each somponent - services,library,profile and RA

Since library contains classes each sbb use, each sbb-jar.xml declares dependency on library.

From first glance it looks like this deployment should work from kick. Well, it wont...

Lets consider Utility class, it operates(depends) on:

 - RA Type events

 - RA Type classes

Sbb super class is very similar in this matter. Both classes are contained in our Library[1].

What is wrong? Library[1] does not have any way of referencing RAType classes. That means that Utility class (as well as Sbb super class) has no access to definition of those classes. This will cause failure during runtime or sbb verification.

Conclusion: using single jar file for sbbs allows to make this problem dormant. However there seem to be more favored way for 1.1 container. That is:

• each functional component declares library with classes it uses
• functional component declares dependency on its library in its xml file
• any other component may ow declare dependency on library to use certain classes

For this example it would mean following:

 RA Type[1] Library[1] is declared. LIbrary[1] declares dependency on  RA Type[1] Library[1].

Case 2: Event sharing

This problem happens only on shared deployment. That is JSLEE and non JSLEE aplication is deployed in the same container.

Lets consider simple web application which fires event "X" into SLEE. Event "X" is received and processed by SLEE service.

This makes it clear that X.class should be present in two places:

• SLEE - since there is service depending on it.
• web application archive, since it fires it.

Since JSLEE v1.1 container no longer shares its classes outside container, it is logical to assume that jar containing X.class should be in both: JSLEE and web archive.

Well, logic fails here. It wont work. It will cause well known exception:

ClassCastException: Can't cast X to X

To make this work following steps should be followed:

- jar containing X.class should be in container library directory

- events.jar deployed within SLEE should contain only xml file with even definitions

Thats it.

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.