Simple Steps to Deploy a JRuby Rails application on JBoss 5

As part of the scheduled 0.9 version of Mobicents Sip Servlets, one of our tasks is to add telco features to JRuby on Rails applications so that it becomes quite easy to create click 2 dial or ipbx kind of apps in Rails.

Adhearsion, a framework written in Ruby by Jay Philips, allows Rails applications to control various functions in Asterisk servers.

Our goal here is a bit different we would like to enable current Rails application to leverage the Sip Servlets specification and be able to handle all the best parts of it. Not sure yet if we will try to integrate into JRuby-Rack or create a similar adapter for the Sip Servlets Specification... so stay tuned !

As I'm still a newbie on all the ruby world, feel free to comment to help us out or chime in with ideas on how to achieve this goal...

So since I'm a (J)Ruby-Rails-newbie, I started where all people start at the ruby home and documentation with their excellent tutorials. If you're a newbie as well please familiarize yourself with ruby before going farther. As my grandma said : "Learn to walk before you run!"

So after I felt like I grasped the basics of ruby I went on to play with the famous new kid in town that is getting all the hype these days (or is it already old fashionned and Scala, Haskell and such is getting the hype now ?) : Ruby on Rails. Same thing here, I followed their simple tutorial that gets you started and off I went with my first rails app. Then I wanted to get a bit farther and started with their blogging application tutorial.

I decided that this was enough for now and that I'll dig deeper as I go and since my objective was JRuby on Rails, I will retry to create the blogging app on JRuby.
So first download the JRuby version 1.1.6 and installed it in my home directory on my linux box under java/jruby-1.1.6. Set the JRUBY_HOME environment variable to the location where you installed it and add the JRUBY_HOME/bin directory to your PATH variable so that all commands are available from the command line. On linux this would be adding this to your ~/.bashrc file :

$ export JRUBY_HOME=/path/to/your/jruby/installation
$ export PATH=$PATH:$JRUBY_HOME/bin

You can test it out from the command line to issue the version by typing this

$ jruby -v

This will give the following output :

jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2008-12-17 rev 8388) [i386-java]

Ok let's install Rails now :

$ jruby -S gem install rails

This will produce the following output :

JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
Successfully installed activesupport-2.2.2
Successfully installed activerecord-2.2.2
Successfully installed actionpack-2.2.2
Successfully installed actionmailer-2.2.2
Successfully installed activeresource-2.2.2
Successfully installed rails-2.2.2
6 gems installed
Installing ri documentation for activesupport-2.2.2...
Installing ri documentation for activerecord-2.2.2...
Installing ri documentation for actionpack-2.2.2...
Installing ri documentation for actionmailer-2.2.2...
Installing ri documentation for activeresource-2.2.2...
Installing RDoc documentation for activesupport-2.2.2...
Installing RDoc documentation for activerecord-2.2.2...
Installing RDoc documentation for actionpack-2.2.2...
Installing RDoc documentation for actionmailer-2.2.2...
Installing RDoc documentation for activeresource-2.2.2...

Since JRuby doesn't support SQLite, we will use mySQL as the database (I assume it is already installed on your machine) so we install the jdbc mysql adapter for activerecord (if you don't know what activerecord, check the Rails documentation).

$ jruby -S gem install activerecord-jdbcmysql-adapter

This will produce the following output :

JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
Successfully installed activerecord-jdbc-adapter-0.9
Successfully installed jdbc-mysql-5.0.4
Successfully installed activerecord-jdbcmysql-adapter-0.9
3 gems installed
Installing ri documentation for activerecord-jdbc-adapter-0.9...
Installing ri documentation for jdbc-mysql-5.0.4...
Installing ri documentation for activerecord-jdbcmysql-adapter-0.9...
Installing RDoc documentation for activerecord-jdbc-adapter-0.9...
Installing RDoc documentation for jdbc-mysql-5.0.4...
Installing RDoc documentation for activerecord-jdbcmysql-adapter-0.9...

Let's create the blog application backed by mySQL now :

$ jruby -S rails blog -d mysql

Go into the “blog” directory, then modify the config/database.yml.
Adjust the adapter name, and instead of ‘mysql’ put ‘jdbcmysql’. You might also want to delete the lines starting with “socket:” or set it to tmp dir.

Here’s a simple example for the development environment:

development:
adapter: jdbcmysql
encoding: utf8
database: blog_development
pool: 5
username: root
password:
socket: /tmp/mysqld.sock

Also edit the config/environment.rb to specify the gem dependency we have on the jdbcmysql adapter (this step is mandatory for freezing the dependencies in your app later on)

Rails::Initializer.run do |config| 
...
config.gem "activerecord-jdbcmysql-adapter", :version => '0.9', :lib => 'active_record/connection_adapters/jdbcmysql_adapter'
...
end

Now, it’s time to create our database:

$ jruby -S rake db:create:all

The next step is to create some minimal scaffolding so that you could actually play with some dynamic functionality and database access:

$ jruby script/generate scaffold Post name:string title:string content:text

We need to update the database after that:

$ jruby -S rake db:migrate

Let's the application now :

$ jruby script/server

and go to http://localhost:3000/posts

Now let's freeze the rails version and the associated gems dependencies we are using into our application so that if rails or a dependency is upgraded in the system, our application will always use the version we freezed and not the newly upgraded version of rails from the system. Note: this is highly recommended for production env and really is a best practice (google freeze rails for more information)
Note that freezing is mandatory if you wish to deploy your application to JBoss 5 with the jboss-rails plugin.

It is a 2 steps process, first freeze rails then the dependencies (in our case the jdbcmysql adapter)
Here is the command to freeze your rails application :

$ jruby -S rake rails:freeze:gems

Here is the command

$ jruby -S rake gems:unpack:dependencies

You can verify that it worked by issuing this command

$ jruby -S rake gems

That will produce the following output :

 - [F] activerecord-jdbcmysql-adapter = 0.9
   - [F] activerecord-jdbc-adapter = 0.9
   - [F] jdbc-mysql = 5.0.4

I = Installed
F = Frozen
R = Framework (loaded before rails starts)

Ok now I can restart the app and play with again (nothing will have changed but if you modify your rails installation to a newer version the app will keep using the version you froze with it).

Let's deploy our application to JBoss 5 now :
First grab a JBoss AS 5.0.0.GA zip and unzip to the location of your choice then set the JBOSS_HOME env variable to it

Now let's get the jboss-rails plugin from the all too famous Bob McWhirter's github repo by issuing the following command (don't forget to move to another directory than your blog application) :

$ git clone git://github.com/bobmcwhirter/jboss-rails.git

from the newly created jboss-rails directory (note that JDK6 is needed for it to compile) :

$ mvn clean install

copy the content of the target/jboss-rails.deployer directory to JBOSS_HOME/server/default/deployers/jboss-rails.deployers.
Congratulations, We just installed the jboss-rails deployer into our jboss installation. Now let's tell the jboss deployers that we want to deploy a rails application by creating a blog-rails.yml file into JBOSS_HOME/server/default/deploy directory as explained by Bob that contain the following :

application:
   RAILS_ROOT: /home/deruelle/ruby/rails/blog
   RAILS_ENV: development
web:
   context: /blog
   host: *

ok we are all set up now, you can start your JBoss 5 application server :

$ cd JBOSS_HOME/bin
$ sh run.sh

and go to http://localhost:8080/blog/posts, there you go your JRuby-rails application working in jboss without the need to create a war and we are able to modify it at runtime, isn't that great !

Thanks Bob for you thesis, plugin and help !

Feel free to comment and let me know how well it worked for you !

Hacking the JBoss 5 deployers to load Sip Servlets Applications

After a great Christmas break, I came fully restored and since JBoss 5.0.0.GA was released on the fifth of December 2008, so out for about a month. Since the JBoss 5 features a great new shiny architecture :

• Check Ales' introduction to JBoss MicroContainer, the component framework that transparently binds AS modules.
• Also See Dimitris discussing the overhaul done to make AS agnostic to any particular component model.
• A great real-world use case is Bob's work over at http://oddthesis.org, where he details the steps he took to add Rails support to AS and get all sorts of enterprise features (eg. clustering) for free in the process.

So I decided it was a really good time to make Mobicents Sip Servlets able to work on JBoss 5. So I took a look at a very good blog post from Bob McWhirter to get a first understanding of how the JBoss 5 deployers worked together to deploy a .war archive and came up with a similar design to extend the existing deployers so that JBoss 5 is now able to deploy Sip Servlets and Converged HTTP/Sip Servlets applications :



So I hacked away and about a week later, Mobicents Sip Servlets was passing the Sip Servlets 1.1 TCK on top of JBoss 5, in addition to Tomcat 6.0.14 and JBoss 4.2.3 !
You can get the nightly snapshots binaries on our hudson job if you want to try it out and give us some feedback on mobicents-public google groups

It allowed us to refactor a bit Mobicents Sip Servlets to be more modular on plugging to various containers (such as Tomcat and JBoss) so it is just a matter of maven profiles now to build Mobicents Sip Servlets on top of Tomcat or various major versions of JBoss. With even more refactoring, I'm sure we could succeed to run Mobicents Sip Servlets on top of Jetty or why not Glassfish, but that's another story ;-)

This gives us a very great foundation to experiment on top of JBoss 5, such as Building converged telco applications integrated with JRuby by example so stay tuned for more in the coming months ! :-)

You can find more details here on what currently happens in the design diagram above when loading a sip servlets application :

Note : I copied most of the content of Bob McWhirter's blog post and adapted it to show how the sip.xml and annotations are parsed and injected and combined with the other existing MetaData :

"JBoss MicroContainer look in WEB-INF/ for meta-data descriptors, such as sip.xml, web.xml and jboss-web.xml. This is where true deployment of components starts. Deployment runs through a series of stages, with deployers setup to match particular files and stages, doing the right things at the right time.

One of the earliest stages is the PARSE stage. A deployer can be bound to this stage to be given an early chance to match, parse, and act upon any meta-data file. For normal WAR deployment, the WebAppParsingDeployer does exactly that. There’s a nice hierarchy of classes to make parsing XML descriptors such as web.xml super simple.

For our Sip Servlets case we are using SipAppParsingDeployer to parse the sip.xml descriptor and create the corresponding hierarchy of JAXB classes and reusing some of the existing web.xml ones when it is possible (ie when the sip_app.xsd reuses some javaee types from the web_app_2_5.xsd). It is indeed super simple :-)

The WebAppParsingDeployer is the bridge from a web.xml file sitting on the filesystem or in an archive to the MetaData deployment bits. The parser reads web.xml, and produces a WebMetaData object associated with the deployment. The WebMetaData is simply a nice object-tree representing anything you can denote in web.xml.

Same thing here in our case, we use a SipAppParsingDeployer. The parser reads sip.xml, and produces a SipMetaData object associated with the deployment. The SipMetaData is simply a nice object-tree representing anything you can denote in sip.xml.

We also might have a jboss-web.xml meta-data in our WAR, and that is parsed (during the PARSE stage) in our case by the JBossConvergedSipAppParsingDeployer (instead of JBossWebAppParsingDeployer). This deployer, like the previous, reads the jboss-web XML file and creates, in this case, a JBossConvergedSipMetaData (instead of JBossWebMetaData) object. It is also gathering the previous MetaData (SipMetaData and WebMetaData) and merged them with itself.

Once we’ve parsed these .xml files, the container has enough information to build up the classpath for the component. Some of these deployers have also thrown off or modified some ClassLoadingMetaData, which describe paths that should be added to the classpath.

As the container enters the CLASSLOADER stage of deployment, other magic occurs to actually set up the classpath.

After that, There is annotations parsing through ConvergedSipAnnotationMetaDataDeployer that produces SipMetaData and WebMetaData also but based on the annotations instead of the xml descriptors this time

In the end, it’s the JBossConvergedSipMetaData (instead of JBossWebMetaData) that drives the ultimate deployment, but what if we don’t have a jboss-web.xml? That’s where the MergedJBossConvergedMetaDataDeployer (instead of MergedJBossWebMetaDataDeployer) comes in. It looks for SipMetadata (parsed from the sip.xml and the annotation based one), WebMetaData(parsed from the web.xml and the annotation based one), and a JBossWebMetaData if one has been parsed, and merges everything into a singular JbossConvergedSipMetaData (instead of JBossWebMetaData).

I’m a little fuzzy on the ins and outs of the CLASSLOADER stage at this point, but magic occurs there.

And our app still isn’t deployed yet. But we’re getting there.

Finally, we enter the REAL stage of deployment, which fittingly-enough, is where the actual deployment occurs. Hooray!

Our TomcatConvergedDeployer (instead of TomcatDeployer) that is sip servlets aware is hanging out there, waiting for JBossWebMetaData objects to appear. When it sees one, it checks if the application is a sip servlets application (by checking if a sip.xml descriptor or Sip Servlets annotations are present), if it is not it deploy as a standard web app otheriwse it goes to work setting up information for our extended Tomcat (that is sip servlets aware) to deploy a sip-app. It configures everything in Tomcat from the information other deployers figured out from sip.xml, web.xml, jboss-web.xml and annotations and embodied in the MetaData by creating a TomcatConvergedDeployment (instead of TomcatDeployment for a standard webapp).

This TomcatConvergedDeployment also sets up the private jndi for the webapp and binds the needed objects to it (like SipFactory, TimerService and SipSessionsUtils). It also set the InjectionContainer, TomcatConvergedSipInjectionContainer(instead of TomcatInjectionContainer) so that needed objects can be injected into annotated attributes of the archive.

It jams it into Tomcat, hits the big red “go” button, and port 5080 is serving you sip-app (and port 8080 also if this is a HTTP/SipServlets converged application).

Finally. :-)

Jean

One year @ JBoss : Mobicents Sip Servlets 0.7 released !!!

It's been now one year since I joined JBoss, a division of Red Hat and about a month and a half since our last release that made Mobicents Sip Servlets the first Open Source container to become Sip Servlets 1.1 (JSR 289) certified.

So it was due time for another release and we wanted it to be feature packed so here goes the review of the latest and greatest of Mobicents Sip Servlets that you can download here

First, Concurrency Control. It defines here how a sip servlets application can be accessed concurrently and what would its expected behavior in this case. Although the JSR 289 Expert Group couldn't agree on a concurrency control mechanism for JSR 289 and that feature has been postponed to the next version of the spec, we believe this feature can greatly simplify the life of the Sip Servlets developers. Also in getting more experience on that front and feedback from the community we would like to start to draft a proposal for inclusion in the next revision of the specification.
So Mobicents Sip Servlets supports not one but three concurrency control modes :

• None - is the one defined (or not defined...) by the specification and the developer is reponsible for synchronizing access to shared resources such as SipSession or SipApplicationSession attributes or objects held by those sessions.
• SipSession : This mode guarantees that two or more messages from the same SipSession will never be processed simultaneously. They will be serialized on the SipSession meaning that they will be processed sequentially by the sip servlet in the order of their arrival so you can access SipSession attributes in a safe way.
• SipApplicationSession : This mode guarantees that two or more messages from the same SipApplicationSession will never be processed simultaneously so you can access SipApplicationSession attributes and the SipSession attributes in a safe way.

Those different concurrency modes for now only take into account SIP messages for serializing access to either the SipSession or SipApplicationSession which means that you have to be careful if you are accessing shared resources in an unmanaged way, for example if you access a SipSession attribute from an unmanaged thread or from EJB this access will not be synchronized. But we are working on it :-)

Congestion Control : All the messages that arrives in the Mobicents Sip Servlets container will go, after some initial processing, in a queue to wait for, depending on the chosen concurrency control mode, a free thread or the lock on the session to be released. If this queue gets full the container will start rejecting any new SIP requests (except ACK) with SIP error code 503 until the server catches up. Note that only SIP requests will be rejected, the SIP responses that arrive at a full queue will be stored and processed sooner or later. In the future we will be adding more congestion control mechanisms like memory threshold, CPU threshold, choose between sending 503 or just dropping any new message coming in depending on the load threshold... so stay tuned !

Enterprise Monitoring and Management Console through Seamless integration into JOPR and Embedded JOPR (JBoss Administration console), the JBoss Enterprise management solution : I just blogged about it 3 days ago so for more details see my blog post.

Mid Call Failover Support : We completed our HA capabilities for pure SIP applications so you can now failover to any node in the cluster in the middle of a call for all kind of pure SIP Applications (Proxy, B2BUA, UAC, UAS) ! We will now be working on failover for converged applications and add performance and stability automated test based on smartfrog so that it becomes final.

We also have been working on two great new features and wish some community feedback on them so we first introduce them as Technlogy Preview into this 0.7 release :
JBoss Seam framework is now able to enhance your sip servlets application : As Vladimir is currently working on a cool PBX application, he was feeling that this was not enough :-) so he started to dig and hack on how the JBoss Seam framework could be utilized to simplify the Sip Servlets application development and has been very successful, See his blog post about it and the public discussion. As we were discussing together the implications of this, we decided to start a subproject dedicated to it to rock the sip servlets world and continue our unification task (between Sip Servlets and Http or Sip Servlets and JSLEE) the same way Seam has been rocking the http servlets world. So check it out and see how it can improve your Time to Market and development experience all together and don't forget to give us your feedback and what you would like to see improved or implemented.

Diameter support : For users of Mobicents Sip Servlets, we wanted them to be able to charge calls that are going through their applications so Alexandre Mendonça who is leading the Diameter project for the Mobicents platform, has tremendously helped us in getting us Diameter support and hacked a Sip Servlets Diameter Event Charging application based on the Location Service example that performs call charging at a fixed-rate (event charging), so check it out and give us your feedback. Alex is now planning on getting more of the Diameter protocol implemented and as he go, he will hack Sip Servlets applications that showcase the different possible call flows to help you do Authentication, Authorization and Accounting on top of Mobicents Sip Servlets.

Also we got 2 new shiny examples, the Diameter Event Charging one that we just discussed and the Conference Media Server application built on GWT with server-push updates to provide desktop-like experience for the user interface. This application is in response to the high demand of the community for Media Conferencing on top Mobicents Sip Servlets and this example will be later integrated into the PBX application that Vlad is builing.

Also with all those new features, we moved to the latest version of JBoss AS 4.2.3.GA and also comes the usual round of bug fixes and enhancements comprised of an updated Management Console, more SIP Extensions (PRACK, OPTIONS, INFO), and more.

Check out our roadmap to see what's coming next !

Feel free to give us your feedback on the Mobicents Google Group
Thanks for using Mobicents Sip Servlets !

Mobicents Sip Servlets gets a shiny new Administration console !

As some of you might be aware, earlier this year JBoss released Jopr, an enterprise management solution for JBoss middleware projects and other application technologies based on RHQ, and Embedded Jopr, which will become the new JBoss Administration console and is based on Jopr.

Since the project does provide great extensibility and thanks to the good documentation of the project and its plugin architecture (see http://pilhuhn.blogspot.com/2008/05/writing-rhq-plugin-part-1.html and http://support.rhq-project.org/display/RHQ/RHQ+Plugin+Community) we decided that it was time for Mobicents Sip Servlets to be seamlessly integrated into those great projects and finally have a way to being administrable into large scale enterprise deployments.

So we hacked our own plugin. We decided to start simple with http://support.rhq-project.org/display/RHQ/Writing+Custom+Plugins#WritingCustomPlugins-GettingStartedQuickly and provide accessibility to the SipApplicationDispatcher, which is a central piece in the Mobicents Sip Servlets Architecture since it has the responsibility of dispatching the SIP requests and responses (that is gets from the underlying jain-sip stack) to the deployed Sip Servlets applications.
So you can control the concurrency and congestion control of the server through it. This was really a piece of cake and was done and working in an afternoon.

Excited by the easiness to integrate into jopr, we decided to provide metrics for Sip Sessions and Sip Applications Session available into standard pure SIP Servlets applications or converged Java EE/SIP applications about the same way it is currently done in Jopr for HTTP Sessions. Same thing, it was done real quick and with a result showing seamless integration into jopr. See our Mobicents Sip Servlets jopr plugin that works for both Jopr and Embedded Jopr.

It took us about 2 days to complete the task 1 day of coding and discovering and one day of polishing and documenting... To try it out just download the latest release of Mobicents Sip Servlets and drop the embedded jopr war that contains our plugin in the server/default/deploy directory and hit http://localhost:8080/embedded-jopr

I have only one thing to say, thanks to the JBoss Operations Team for providing such a good project that saved us quite a bit of time to have a full blown enterprise management solution for our project. Keep up the good work, guys !

Jain Sip is working on top of android

I had a bit of free time yesterday night and I noticed the first google android powered phone hit the market in USA so I said to myself, what if I tried to port jain sip stack to android...
Not so much work should be needed since android supports a lot of the JDK 1.5 packages natively. So I tried and believe it or not, no work was actually required to make the jain sip stack work on android, it just runs :-)
Again kudos to Ranga for such a great stack :-) and to Google for having a nice OS where you can really reuse most of your Java applications (pending a rewrite of the UI)

So here is my proof of concept :
I ported the well known Shootist and Shootme examples from the sip stack to android and uploaded a zip here that you can play with.

The zip contains shootist and shootme standard examples and shootist and shootme android examples. Unzip in a location that we will call

So first you need to have the android SDK installed and have the android tools on your path (see the Android installation instructions for that)

Then you can start the android emulator with the following command:

$ emulator

from , do the following :

$ cd shootme-android/bin/

and then

$ adb install shootme-android.apk 

this install the shootme android example application into the emulator
go back to and do the following :

$ cd shootist-android/bin/

and then

$ adb install shootist-android.apk 

this install the shootist android example application into the emulator

You can see the applications installed in the emulator by clicking on the gray arrow at the bottom of the android phone screen :



Ok so much for the installation of the applications into android. Now let's get real and have some fun. Let's try the shootme android application first.

on the emulator, go to the menu and select the application called shootme.
It says that the jain sip stack has started on 10.0.2.15 (localhost's emulator ip address of android)

Since the emulator has its own ip address system we need to setup a UDP redirection from our host's localhost:5070 to the emulated system's localhost:5070 so that teh shootme android application can be pinged from our shootist standard application with the following command

$ adb emu redir add udp:5070:5070

let's start the standard shootist example so that it calls shootme and that a SIP call flow (INVITE-OK-ACK and then BYE-OK) is done between them.
go back to and do the following :

$ cd shootist/dist

and then

$ java -jar shootist.jar

you should now see the messages being exchanged between the shootme android application and the shootist standard application.

if the emulator sip messages are not enough, more log is available through the command

$ adb logcat

now kill the shootist app with Ctrl+C and close the emulator

You can also do the reversed example and start first the shootme:

Since the emulator has its own ip address system we need to setup a UDP redirection from our host's localhost:5060 to the emulated system's localhost:5060 so that the shootist example application can be pinged back from our shootme standard application with the following command

$ adb emu redir add udp:5060:5060

let's start the standard shootme example so that it waits to be called by the shootist android applicationand that a SIP call flow (INVITE-OK-ACK and then BYE-OK) is done between them.
go back to and do the following :

$ cd shootme/dist

and then

$ java -jar shootme.jar

on the emulator, go to the menu and select the application called shootist.

You should now see the messages being exchanged between the shootme android application and the shootist standard application.

if the emulator sip messages are not enough, more log is available through the command

$ adb logcat

Please post comments if you have problems running the examples or if you want to give me some feedback...

Mobicents Sip Servlets is Sip Servlets 1.1 ( JSR 289) certified !!!!

Mobicents is the First Open Source Certified Server - Again.
After being the first JSLEE 1.0 certified open source server (To my great delight, I hacked on that part too about 5 years ago and had the pleasure to pass this TCK too), now Mobicents is the first Open Source SIP Servlets 1.1 server as well....
which makes JBoss the first vendor to certify even among commercial vendors, not counting the company who wrote the TCK....
In other words, we were the latest to enter the game of the SIP Servlets vendors, we built our server from scratch in about a year and now are the first to be certified, isn't that great :-) ?
Not only that but we also features capabilities that are outside the scope of the specification such as :

• HA and mid call failover support
• SIP Load Balancer
• Media support
• STUN suport
• Management Console

We are also driving towards a converged model between SIP Servlets and JSLEE and the first logical step : interoperability has been made possible on the Mobicents Platform since JBoss is the only vendor to implement both specifications so that you can benefit from the best of both worlds.
The IEEE paper that has been published related to this work will be made available soon.

I would like to personally thank all the people that worked with me in making this dream (actually it was a hell of a work :-)) come true :

* M. Ranganathan that mentored me in the open source world from my early days of work (I always remember my first assignment hacking with you on the jain sip applet phone hearing our voices fast forwarding in the NIST premises :-) ) that started this project and put all of us in it :-), for your help working with us to design and hack together during the first versions of the project and later on in giving your gold advices to keep us on track, for your work on jain sip and the nist sip stack (jsip rocks and rolls !!!) that we use as the underlying sip connector and for having the passion of the true digital monkey hacker. My inner bonobo is jumping around :-)

* Valdimir Ralev for working like hell on the project during the beginning until the fun of the last month while passing the TCK and the joy of today :-) and for the fun we had in our virtual garage :-). Thanks so much for the great work.

* Bartosz Baranowski for your help working with us to design and hack together during the first versions of the project.

* Ivelin Ivanov for making me part of the JBoss dream, that made the Mobicents Open Source Platform possible and what it is now and mentoring me along the way and for all the fun during the wild trips abroad... You're a hell of a guy, wild at heart :-)

* Our fellows at Tomcat and JBoss that build the containers on which this work has been made possible.

* Mihir Kulkarni from Oracle for its timely replies about the TCK tests.

* The JSR 289 expert group members for their commitment and hard work
on the specification. (it was good to see you guys in LA)

It feels so good... I love this job !

Note : See Ivelin's post and Vlad's post about it also.

Mobicents Webinar recording now available !

There is an online recording available of the Mobicents Webinar recently hosted by me where you can see most of the products that are composing the Mobicents Communications Platform as well as a demo showcasing a converged application built on top of Seam, Mobicents SIP Servlets and Mobicents Media Server deployed on Jboss AS.
If you missed the live session, make sure to take the time to watch this update on the latest and greatest from Mobicents. You will also learn where we are headed in the future.

Please post feedback about the webinar to this thread.

Have fun !