Tuesday, December 28, 2010

The Rich Communication Suite

The first time I heard about RCS, this year, when a company asked if Mobicents SIP Presence Service (MSPS) was compliant, I was curious about what it was, but I promised myself, after 6 months struggling without a MSPS release, we would not dive into another layer of over complicated specs, no way we would consider one more possible dead end. In short, we ignored it… till another company asked about the same thing, and another one, and it kept going… In the end of last summer we were involved in a big RCS network plan, and it was perfectly clear to me, the SIP Presence industry was asking for RCS, and RCS only. So I went through an evaluation of what was RCS about, to finally decide if MSPS should embrace it.

RCS stands for Rich Communication Suite, and it is a suite of IP telco standards, which works out other standards. Confusing, the least… RCS is done by the GSMA workgroup, and does not defines any new technology… What? This is getting weird!  My first thoughts, also the fact that it was done in IMS fashion, through numbered "Release"s, made me fear the worst, after all the GSMA members possibly overlap with 3GPP and OMA, chances it could be the same people, using same methodologies, drawing the RCS specs.

So I spent some time reading the specs and let me tell you, one must praise GSMA work, quite simply, RCS takes on IMS and OMA specs, rearrange them, simplify as much as possible, so it can be applied to today's networks and services, as fast as possible, an using agile methodologies! Sounds great, sign me in!

Wait a minute, I know, some would say it is all wrong, we should instead had first the basic layer, the RCS simplicity, and only then we should have it extended to provide the zillion features IMS has, and which nobody cares or needs. Not a surprise, I fully agree with such view. Also some say it is too late, that the consumer already decided for services which are not provided by operators, maybe not, hopefully not, in my humble opinion, RCS may be the very last chance, at least for SIP Presence.

Let me try to give you an insight of what we are talking about, RCS has 3 releases, each upgrades the previous one. I will focus on SIP Presence only, but RCS touches more than SIP Presence, it also works other services such as IM.

RCS Release 1 evolves around the concept of the Enhanced Address Book (EAB), an evolution of the usual address book. In short the address book is decorated with enriched information, coming from different services. This plays nicely with today's wishes for cloud stored information, unified social networks status updates, contact content such as portrait icons. I'm not going into technical details, but I for sure am someone who is aware of the design issues around SIP Presence, its hard time scaling due to huge traffic, the dozens of ugly workarounds to make it work, and RCS is a nice step forward into the right direction, there are simple decisions that deeply simplify the network design, making it more like "old" presence networks, which simply work. One remark, it takes quite an effort to define this endorsing IMS and OMA, 27 pages of functional description, plus 39 of technical realization, it should be a lesson for everyone in these standard bodies when defining more extensions or new versions.

The RCS Release 2 effort focuses on enabling access to rich communication services from a wider range of devices. In short it tells that the user has multiple devices, for instance a mobile phone and a PC, possibly concurring for services, and adapts Release 1 for that. It also introduces the Network Address Book, which is just the realization that the EAB needs to be in the network and sync the multiple user devices.

The RCS Release 3 mostly consolidates Release 2 features, and adds some minor enhancements, such as preparing the network for different usages of it, for instance users with devices, which are not connected to mobile network, instead only have broadband connections. In my humble opinion a very important and positive decision, it's about time to consider these scenarios and find out new opportunities. It is weird to say this, but the fact that the industry finally acknowledges that content sharing between two users may happen off the voice/video session is a victory, welcome to the world not session centric. Can you imagine what would be the outcome if we have specs that release the session protocols from all these extra services almost nobody uses, how much simpler, cheaper and efficient the session networks, services and clients would be?

As I said, RCS is a big step in the right direction, a revolution without new technology. For MSPS you can expect to target RCS compliancy as soon as possible, as a matter of fact the developing tasks for such work area already in the Issue Tracker, with a total estimation of about 200h of work, at this point we just need to understand what 3rd parties are interested to collaborate, to come up with a release date, Mobicents does not have the resources to walk this path alone, or perhaps I should say, not before it may be too late. Please get in touch with me if you are interested in contributing. We know that RCS needs Mobicents too, an open source implementation with a strong community behind it.

Stay tuned.

References and Additional Resources:

RCS Homepage
RCS Release Documents
RCS Market Survey

Wednesday, December 8, 2010

About GPL License on Mobicents - Part II

Hi all, a final and quick follow up on last post matter, the Mobicents community asked for concrete use cases where GPL linkage would be applied, and concrete information on how to apply for "the free ride". Well it was decided to not list such cases, neither there will be an automated "get a free ride" system, instead all interested should get in touch with us for a proper handling of each specific case, that is of course if you can't or don't want to apply for JBCP subscription, or want to open your code.

Thursday, November 25, 2010

About GPL License on Mobicents

From time to time people get doubts on the licensing terms of Mobicents and JBoss Communications Platform (JBCP), which uses a double license scheme, very common in comercial open source projects. Mobicents is free but gets restricted by GPL (except Sip Servlets, which is LGPL), while JBCP removes every constraints. With this post I will try to clarify what does that GPL means for Mobicents team and users.

Lets "talk" a bit about the GPL license, something that is never clear enough, the more you dig the more abstract it becomes. The Wikipedia page about GPL is a very good source of information, it identifies the "linking" between two software parts as a possible conflict situation, and presents different interpretations on that. In summary, if the linking is real then the software part which linked to a GPL software, must now follow a few rules, one of these is to have the source code published. In that Wikipedia page, after you read about some of the main features, starts on famous trials, A sues B, X sues Y, etc. In every case it involves a 3rd party that redistributed GPL code but either closed the sources, sometimes even hiding the presence of the GPL code, or changed the license. It can also be seen, in all those cases, that only the ones redistributing were making some kind of profit, and most refused to share that profit in any particular way.

With respect to Mobicents vs 3rd party components, we are not really able to extract if a deployed 3rd party application needs to be GPL, note that even if 3rd party code only imports Java or JSR API classes, in the end it needs Mobicents GPL code to run. Being sincere, only judges and attorneys decide the outcome, and probably some will have different interpretations too. If you ask for my personal opinion, I would say that yes it needs to be GPL, but simply because that removes all chances of being wrong! 

OK probably there is now some panic, people using Mobicents in production with closed sources or not GPL!!! Relax, there are two ways to forget about GPL:

1. You are having a benefit from it and make money. Then you should be fair, get a support contract and use JBCP instead in production. The Mobicents team does not works for free. And of course we work a lot to ensure that JBCP is the real deal, there are SLAs, there is a very successful company behind you, a company ensuring you succeed. The cost is cheaper than competition and also each case is a different case (and price), we do not want to make customers less competitive because they use JBCP. 

2: You can't pay now but you are helping improve the platform, lets be partners then, official or not, and then in exchange you get a free ride. The free ride means that the GPL linkage stuff is ignored, be it a real problem or not.  But note, no SLA of any kind.

Sincerely, we believe any good and fair usage will match one of these cases. Now what is your opinion?

Wednesday, November 24, 2010

Monday, November 22, 2010

Roadmap for Mobicents JAIN SLEE 3.0

You can now see the draft roadmap for Mobicents JAIN SLEE 3.0 at mobicents.org. In summary we are going to implement the more radical JAIN SLEE 1.1 extensions, Java annotations (community discussion to start soon) and the advanced ConfigProperties idea, which should result in a very different programming model. But changes/enhancements will touch the whole platform:

  • Cluster Enhancements: More flexible framework (with respect to what is used as datasource to hold clustered state), a more useful and feature rich buddy groups setup
  • Resource Adaptors: JSR 309 finally, a easy to customize "example" JDBC/Datasource RA, same for a Web Services Client RA, and an alternative Http Server RA that does not relies on HTTP Servlets
  • Service Enablers: continue the work started by the XDM Client, providing ready to integrate enablers for SLEE applications
  • Web Console 3.x: still a bit undefined at this point, but very high chances that we will have the "old" web console back, and leave Jopr/JBoss ON just for monitoring

We have set the first Beta version for the end of January, and set all the new stuff for such release, but note that it is expected some to miss the train and jump in later releases, the task list is so big. Still, our compromise is that in the middle of the year we will have the first FINAL release, and such release will have everything production quality and carrier grade.

Finally, if you have been wanting to contribute but not able to understand how, this time is a great opportunity to step in, it's specially easy to contribute on components such as the new resource adaptors and enablers.

All feedback is welcome so please let us know what's in your mind.

Thursday, November 18, 2010

Tuesday, November 16, 2010

Join the Mobicents team!

The Mobicents team will soon count with a couple more friends. If you think you have what is needed please get in touch privately. As usual we will give priority to people which have been participating on our lovely community.

Friday, November 5, 2010

Mobicents JAIN SLEE at 900 CPS!

With respect to SLEE 2.2.1.FINAL testing, I ran the usual single node SIP UAS load test, but this time it was pushed till 900cps. First time ever, there was 2.5M calls at that load without a single call failure, just a few retransmissions, memory was rock solid at 83%, and CPU at 270% (4 Cores), during that time. The test was done in the usual old QA Labs machine, compare it with the load we handled in last 1.2 release, a bit more than 200cps!

The question now is... Will Mobicents SLEE 3.x reach the special 1K? :)

Wednesday, October 27, 2010

Mobicents SIP Presence Service next steps...

The market for SIP Presence is quickly turning their heads to RCS, which more or less starts with OMA specs and make them more usable for a real presence network.

Mobicents can't ignore that, as the result we will target RCS compliancy for Mobicents SIP Presence 1.0.0.FINAL, now this could introduce more serious delays to have something concrete released and at the same time we consider it passed way too much time since our last BETA5 release. Many improvements have been committed into the SVN source code base since that release, thus we also have decided to quickly come up with a BETA6 release, addressing OMA 1.1 as much as possible, expected to be released around 6th November, a week after Mobicents JAIN SLEE 2.2.1.FINAL.

We will present a more concrete roadmap for CR1 and FINAL releases very very soon.

Monday, October 11, 2010

Mobicents JAIN SLEE 2.2.0.FINAL released!

Mobicents JAIN SLEE 2.2.0.FINAL is out, the last major release for 2.x! Please read release announcement and get download link at http://tinyurl.com/2b5jdrs

Wednesday, October 6, 2010

Mobicents Team Meeting 2010, Antalya - Turkey

Lets start this way, it's getting better every year, for sure it was the best Mobicents/JBCP team meeting ever! Participants included the developers team, quality assurance, documentation, product management and for the first time customers and community.

Regarding the participation of customers and community, how valuable is to be able to have fun, discuss and rework roadmaps in real time with the team behind the platform? In my humble opinion this meeting is just the first step to a broader event around the platform, JBoss World and generic Java events are not really our playground, I sincerely think that next year we can aim higher, double the number of participants and maybe count with presentations from customers/community.

Rafting pirates

So the meeting started with a "lets just have fun" day, where we went for a full day of rafting in a Turkish river. Great time for sure, just check the photo above, amazing uh? :-) I believe this is the right way to start such an event, breaking the ice, establishing everyone as good old friends.

Meeting room

Enough about fun (for now), we defined three days and half for presentations and discussions. As usual we went through platform projects, mainly reviewing last year achievements and shortcomings, and then defining what will be the next year. In between we had a few interesting "training" sessions to better understand what we are talking about. Personally speaking I really enjoying discussing Diameter and SS7 protocol details and the Media Server challenges and solutions. Clustering was also a topic in almost every presentation, it shown how serious the team got into it in the last year. Unfortunately we had no time to talk about everything in detail, we had to rush a few presentations, and some topics were almost not discussed such as SIP Presence, IP PBX, Seam Telco, a sign that we need to extend the meeting time some say, others say that we are simply stretching our resources too much, something to review in another time and blog post for sure.

Mobicents JAIN SLEE Presentation

Regarding my main activity, leading the JAIN SLEE container development, I had half a day of very happy presentation, we had such a great year, lots of community activity, a very successful 2.x release, a huge (over 80% for sure) rework of the old generation. We did 8 (eight) binary releases, and half were of major type, that is, not simply bug fixes and stack updates, or service packs as many like to say. We achieved four times the performance of the 1.x, very very low latency values, high availability and fault tolerance, user guide documentation for every module, and over 5000 community downloads, an incredible number for a specific project. In the end of the "season" we also started with the discussion on the JAIN SLEE standard evolution, as seen on my recent posts, creating new development models, meeting the community needs, transforming the Mobicents community into the specs playground for innovation. Yes, as you can probably guess, I am that happy with the achievements :-)

Of course, it's never perfect, we had shortcomings too, specifically we failed to meet several release dates (yet last ones were on time). We had almost null contributions on new code - don't get me wrong the community provided us great feedback for bug fixing and that is priceless too - what in my opinion is the result of weak developer oriented documentation, such as code guides. Another pain point is the Jopr web console, we clearly did not achieve what we wanted, we were not able to get around UI limitations, performance is a deception and the fact that is not ready to run, that is, you need to setup every time you download, is not a good thing also. Finally we did almost nothing to improve Eclipse SLEE plugin, which now clearly doesn't match our way of developing RAs or Examples. Correct, nobody is happy with shortcomings, but what matters is how you solve them, and we have a plan to fix each during next year.

The presentation went also through the major new features released last year, namely:
- Container's core modularization and SPI
- Server's state replication
- Fault Tolerant RA API
- Congestion Control
- Event Router Stats and Execution Mapper
- Simplified Global Logging Configuration
- New or Reworked RAs (JCC, ISUP, MAP, XCAP Client)
- Jopr Web Console
- Enhanced or simplified external SLEE Connection.

Mobicents JAIN SLEE 2.2.0

Also important was the introduction to the release that is about to come out, 2.2.0, with an overview of major new features:
- Part I of clustering performance enhancements (8x compared with 2.1.2)
- Buddy groups clustering
- Twiddle Command Line Interface (CLI), which we believe will be a major tool for developers and platform administrators
- Part I of JAIN SLEE 1.1 Extensions, specially the one which allows JAIN SLEE Libraries to depend on other SLEE component types, such as RA Types
- Eclipse SLEE Plugin 2.0
- SMPP v5 Resource Adaptor
- Misc performance optimizations on SLEE facilities, such as Tracers

Mobicents JAIN SLEE 2010/11 Roadmap Draft

Last but not least, the next year roadmap draft, targeting 15th January 2011 for the first BETA version of 3.x, which main features are:
- JAIN SLEE 1.1 Extensions: Annotations & ConfigProperties
- Jopr Web Console 2.x (or something else if we are not able to solve current version limitations)
- EclipSLEE 2.1
- Mobicents Cluster Framework 3.x with Advanced Buddy Groups features such as high performance intra group broadcasting of notifications
- Second wave of SS7 RAs
- JSR 309 RA

The first Candidate Release of 3.x should be done around March 15th and if everything goes ok should have a FINAL production quality and carrier grade release around April 15th. Later during the year we plan to keep pushing the way for a new refined JAIN SLEE spec, more on that soon since it's still rough and unpolished ideas.

More fun

SLEE vs SIP Servlets? :)
Yes, fun was not only about rafting, every day we had 2h for pool time and (optional ah ah) lunch, and at night you could always count with resort's great shows, such as brazilian Samba, Shaolin Monks, Ukraine gym stars in a "Cirque du Solei" type show, and then late night talks with team members, unstressed by some wine or fine drink. There was also time for shopping or some more water sports like jetsky or windsurf.

Flying shaolins

The brazilian samba team
Very important to the event's success was the meeting place, Alva Donna, in Belek - Antalya, Turkey, a 5 star all inclusive resort, it is so pretty, the food and drinks are great, the staff is very friendly and made their best to treat us as very special people. Really recommended place, and definitely we will come back another year, just dunno when.

Beautiful resort, specially at night

Resort main pool, it had 5 or 6, one with water slides

That's it, the end, if you are interested in the JAIN SLEE presentation please click here to download.

Bye bye.

Thursday, September 16, 2010

Feedback about Mobicents

The Mobicents team set up a quick survey about the platform, if you are a Mobicents user please participate, it's valuable feedback for us.

Click to read the survey announcement.

Sunday, September 5, 2010

More SLEE 1.1 Extensions

Lately I have been introducing a few extensions to the JAIN SLEE 1.1 standard, first by teasing about Java Annotations (more on this soon) and then promoting the extension of the Resource Adaptor's ConfigProperties concept to SBB and Profile's component types, it is now time to promote a few more extensions, allowing the Mobicents community to be an important playground for SLEE specs innovation too. The newest extensions are:

  • SbbContextExt - extension of javax.slee.SbbContext interface, exposing methods to retrieve SLEE facilities, factories and RA objects. An API more consistent with the RA API which does not uses JNDI
  • ProfileContextExt - extension of javax.slee.ProfileContext, exposing a method to retrieve the Alarm Facility, same reasoning as the extension of SbbContext 
  • ActivityContextInterfaceExt - small extension of javax.slee.ActivityContextInterface, allowing the retrieval of the timers and names bound to the ACI
  • Library References - extension of the Library Jar XML Descriptor, allowing the reference of other component types such as SBBs or RA Types
Read and discuss all about those extensions by clicking here. Any feedback and contribution is welcome.

Friday, September 3, 2010

JAIN SLEE 1.1 Extensions: ConfigProperties

This should be interesting if you care about the development of the JAIN SLEE specification, it is about extending the JAIN SLEE 1.1 Resource Adaptor API ConfigProperties concept to other component types, namely Services, SBBs and Profile Specifications.

Click here to read the proposal and engage the community discussion.

Friday, August 20, 2010

Summer teaser

Click here for some tasty code

All descriptor's metadata and service logic in a single class.

Stay tunned, more next week ;-)

Wednesday, August 18, 2010

Creating XCAP App Usages for Mobicents XDMS

The process of developing and deploying a XCAP Application Usage in Mobicents XDM Server was enhanced and simplified. In case you're interested on the subject download and read the slides explaining everything. Update: please refer to Mobicents XDM Server  documentation, it includes a section on how to create new XCAP App Usages.

Saturday, July 3, 2010

Mobicents JAIN SLEE 2.1.1.GA released

A new build of Mobicents JAIN SLEE 2.1.x is out, download links and the full announcement here.

Wednesday, June 16, 2010

Mobicents JAIN SLEE 2.1.0.GA released

Lots of enhancements, read announcement at http://groups.google.com/group/mobicents-public/browse_thread/thread/7679c8dba934b532

Thursday, May 20, 2010

How would you change JAIN SLEE 1.1

There is some brainstorming going on at mobicents-public google group, with respect to Sbb configuration means. Click here to read or participate.

Anyway I think we could go beyond the proposed changes and for instance support annotations (as alternative to xml descriptor parts) or replace the usage of JNDI with a richer SbbContext, but I'm really interested in your point of view, so let us know what you don't like in the current revision of JAIN SLEE and how would you fix it.

Monday, April 26, 2010

May I have your attention please

Hey there, Mobicents JAIN SLEE 2.1 is coming fast, and I would like to give you an insight of particular and very important changes on the foundations, which I believe will greatly evolve the container's code and how the community interacts with it, and could otherwise really go unnoticed.

But then, my 3rd anniversary in Red Hat is due in 4 days too, so I will take the opportunity to also talk a bit about JAIN SLEE and Mobicents history or how close we became.

In case you are not *that* familiar with the JAIN SLEE container, and Mobicents JAIN SLEE in particular, sometimes it is defined as - specially by competing specifications :) - as a heavy weight platform, mostly with respect to 2 ideas: it is a lot more than you will ever need, and a bit as a consequence, it is impossible that it keeps up in performance.

The above ideas are both very wrong, lets begin with the first one. SLEE was designed to fulfill the requirements for full feature carrier grade telco apps, and those, if taken serious, will always needs the army of management APIs that SLEE provides and others competing specs don't. It's hard to conceive, if you are responsible for a serious telco app, that you think it is important that the app runtime code follows a spec but then all the management can be proprietary... Sure one can say that now one has JMX and other frameworks, but those are just generic frameworks, it's way too far to bind to the runtime application needs, I would say that one needs to develop more on the management side that on service runtime logic, and that is of course a bad thing. SLEE used to have the muddy and proprietary RA API, but the 1.1 revision nailed it, making it a complete platform spec.

Anyway, I'm not saying the SLEE spec is perfect, no way, in my humble opinion it is far from that... For instance I'm not a big supporter of SLEE profiles, it's a bit like reinventing the wheel, and Java EE has very nice round and shinny ones! Another bad point is the too strong relation with Java transactions, I would prefer something transparent as all Java EE APIs, if you want/need then use it, otherwise skip it, this would be really nice specially when the big majority of external resources use APIs which are not transaction aware, making the recover of a rollback a lot of trouble. Shhhh... it's also very true, then even when it is good to use it, a lot of developers tend to ignore or run away from it, it's scary some say. On top of it add a good mix of abstract components which most people struggle to understand difference of objects and entities and there you go, SLEE API runtime gets ugly and complex... well, at least till you get it after a couple weeks or months, by that time if you're still on SLEE there are high chances that you now are in love with it and try to apply it to everything out there, even if it is nothing more that an hello world, perhaps because it is was such a challenge? Okay, enough enough ;-)

The second argument, SLEE is slower, this one I really don't understand, SLEE is by all means at least at same performance of other specifications, and by the time you start adding extras that you end up needing, such as management parts or data sources/transactions, SLEE is probably way faster than anything out there, and that is simply - on top of the highly efficient async model - because that big platform design/api was fine tuned considering all parts, and there are very high chances that the user will fail to come up with something proprietary that tuned. Right, nothing impossible of course, but how many apps do you known with good performance that don't need a fine profiling and tuning till you end up loosing most of the language high level charm? Doesn't even matter of which spec...

And that's it, my bla bla bla of why SLEE is big, why SLEE is full of features you may not need in your app first release, etc etc, which leads to what really this post is about. Maybe a bit of more preliminaries first? Okay, lets talk about Mobicents history, right someone of you are now awake...

Mobicents open source started right in the middle of the java.net boom, and once JAIN SLEE 1.0 spec was out, a top secret society - including Ivelin Ivanov (now JBoss Commnications / Mobicents platform lead), Ranga (now JAIN SIP API and RI lead), Jean Deruelle (now Mobicents SIP Servlets! lead) and others (it's funny the well known OSS related names you find out in the oldest sources) gather around that new shinny platform, maybe noticing that it could very well be the most wanted piece of telco software in the following years, and knowing that the telco middleware cost was outrageous it was difficult to not succeed...

Well, that didn't came fast, even with very good developers, JAIN SLEE is not an easy platform to implement, it took quite some time to achieve certification, and surprise surprise... after all those years it's still is a 3 vendor world, well 2 if we only consider the certified ones. Others have tried, and with a lot of resources, but eventually gave up, the JAIN SLEE market really struggled to justify that investment too, be it because another spec, more high level took off - Sip Servlets, be it because it was damn hard to understand the API in one week, or even because the serious offers at that time were not that cheap. And this is the world which I got in right after university, but hey I was really really lucky, I was always around good people, first in Portugal Telecom Inovação, and then in Red Hat, and those persons gave me the chance to learn a lot in such short time. What better places to learn both telco related and OSS Java development than those companies, they are fors sure in the top for each "world" :-)

Moving on, I switched to Red Hat/JBoss in the 1st of May 2007 , when the company bought the rights for the Mobicents code and the first year and half was just to make it a product. Like I said the code was complex, many different authors in many different times, we started with SIP performance around 10/15 cps, no kidding. By the time we achieved version 1.2 we were able to come up with around 150 cps, at that time we were getting almost all we could get of it, and was time to kickoff the development of the second generation, targeting the new 1.1 spec revision, which EG I joined late.

Clearly we need to start from its foundations, but we couldn't simply throw away the 1.2 code, too risky and not much time, but even with such constraints the team came up with something like 75% of new code, and it paid off, the 2.0.0.GA born with strong features and performance (well above the 500 cps mark). The "core" code had now new modules to deal with JAIN SLEE components building and management, combining stuff like JAXB or Javassist, or very different code such as the SLEE profiles mapping to JPA, attractive to any open source developer for sure, all the latest and challenging APIs or tools (big bet in JBoss AS5 and Maven2 also) to get dirty, improve skills and why not, get a better job around Mobicents or these technologies, that's what happened to me and all of the Mobicents team, it's that real, open source communities pay off!

Okay, against my believes, the community didn't jumped on board right away, sure it's still too fresh, and there are already some great success stories, but lets clearly say, 90% of the community boards are requests for help, the ones that the team can't fully embrace as one would like, it's not that difficult to understand the why. Now this lack of contributions is a trend in nowadays open source platforms, a lot confuse it with free software with free support, that is not what makes the community evolve. In all my community or sales talks I try to really make a point about the advantages of the open source community, it's such an opportunity to evolve the code and skills (both the user, dev team and work process) in a friendly environment that truly most really don't understand what is the miss when being shy.

But then, there must be a reason for the lack of contributions, and it's the team job to get around it, and spice the community, and in my opinion that can only be done in two aways, either we make a Mobicents Bingo with nice prizes or we make the code, tools and development process more attractive, and yeah - not the bingo ah ah - that's what we will be trying to start with Mobicents JAIN SLEE 2.1.

In Mobicents JAIN SLEE 2.1, most of those 25% of code in 2.0 that were not new, which were the foundations of the whole platform, and how the modules glued together, will now be completely reworked, targeting an attractive multi module platform, on top of an SPI that overrides the javax.slee interfaces. Sure at first this SPI may not come in the best shape, it's a big effort to extract a big set - hundreds - of interfaces which mean something in a couple of weeks, but we will get there. On those modules, the idea is to make them more and more efficient, both in the SPI and Implementation, have their own configurations (and pluggable) means, for instance different implementations of the event router mapping of thread executors to activity contexts, different datasources to store every kind of instance state, all wrapped and tighten by a great packager named JBoss Microcontainer, making it so easy to replace modules or sub-modules as dropping jars and change XML or JMX properties. In summary, it's the container that you easily personalize to your own needs, whiteout meaning the change to proprietary specification, easily target a single module for your contributions. Yes, I'm that excited with this kind of move.

Okay, I must stop it for now, initial work is now on the svn trunk, documentation on the Core modules and SPI will start popping up in the mobicent public wiki, hopefully by the community users too. Hope you enjoy our work and join efforts to make it better and better, we all win.


Wednesday, March 17, 2010

Mobicents JAIN SLEE 2.0.0.GA Performance

Something cool, Luis Barreiro (JBoss QA Labs) just published performance test results for the first GA release of Mobicents JAIN SLEE 2.x, and you know what, that old server we have been using, and that at some point was ranking Mobicents JAIN SLEE 1.2.x SIP Call Setup Load Test with results such as 200 cps, is now capable of reaching 750 cps!!! The development of the new JAIN SLEE generation was though and took some additional time, but I really believe our community and customers now have a true carrier grade, certified, open source, telco AS. Enjoy!

Full details about the report here

Tuesday, March 9, 2010

Mobicents JAIN SLEE Plans

Chances are that you are already aware of the announcement I made in mobicents-public google group, but in case you didn't, please read important information regarding the plans for Mobicents JAIN SLEE 1.2.x, the old generation branch, and the next 2.x releases.

Click here.

Thursday, February 25, 2010

Mobicents JAIN SLEE 2.0.0.GA unleashed!

Mobicents JAIN SLEE 2.0.0.GA is released, see detailed announcement at http://groups.google.com/group/mobicents-public/t/8a560b2ee30d4261

Thursday, January 28, 2010

Mobile World Congress 2010 at Barcelona

I will be 2 days in the Red Hat boot, 16 and 17, showing demos and giving all details on the current Mobicents platform and its future. If you are attending the premier telco event please come by and say hello.

Wednesday, January 27, 2010

It's out! It's out!

Mobicents JAIN SLEE 2.0.0.CR1 is released, full release announcement at http://groups.google.com/group/mobicents-public/t/aab870d283c9483