Carrier grade test lab contributed to Mobicents by Aepona

Mobicents is now being built and tested continuously on a high end Sun Netra 440 box running Solaris. This machine is a typical choice of telco carriers for their core network.

Read more: http://forums.java.net/jive/thread.jspa?messageID=34158&tstart=0#34158

Mobicents presentation at JavaPolis

The JavaPolis Birds-Of-a-Feather presentation of Mobicents was quite fun. The room was full and there were a few standing people. The audience consisted mostly of developers with explicit interest in VoIP.

The discussion started with a quick poll. It turned out that 100% of the attendees were familiar with VoIP but none of them has written a VoIP application. This was no surprise to me. The first few slides of my presentation explained why I think most developers are not writing their own VoIP code. Several people in the audience shared their own thoughts on this paradox. It boiled down to two fundamental problems - 1) Until recently there was no widely available open source platform for developers to play with; 2) Unlike the Web, there is no truly public VoIP network, such that developers can deploy a new VoIP app and have anyone try it easily. Instead there are a number of VoIP islands such as Skype, Google Talk, and Yahoo! Messenger.

Then went into several examples of new kinds of communications services. Every had a chance to voice an opinion and add new ideas to the examples. It turned into a lively brainstorming session that made everyone realize that there are a lot of interestign applications that can be implemented when voice, video, mobility, location and web are mixed together.

The conversation was so involved that we went over time and had to leave the room because the next presenter walked in. The offline discussions we also pretty interesting. A number of folks wanted to know about the Mobicents roadmap and where they could help.

We also talked about SLEE best practices and architecture blue prints for complex applications such as call centers.

Take a look at the presentation and feel free to post your comment on this blog.

Mobicents-JavaPolis-2005.pdf

A good experience overall. The JSLEE community is growing out of the Early Adopters phase.

Ivelin

Google Talk and Jabber Software Foundation submit a proposal for Jingle - standard voice and video extension for XMPP

Google Talk is delivering on its promise to standardize the voice protocol. The team chose to support an ongoing effort at the Jabber Software Foundation by providing feedback to the Jingle protocol specification.

Here is an excerpt from the spec:

Upon communication with members of the Google Talk team, it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified therein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the Jabber Software Foundation's standards process.

The spec document is written in an accessible language. It was easy for me to grasp the concepts and scetch out the basic interactions between calling parties. Looks like a protocol that should be relatively easy to implement in client devices.

The authors deliberately chose to push as much complexity as possible to gateways and servers. Even more so than in SIP. In several sections in the document the text points out why certain features were implemented differently than SIP, which shows the advantage that the authors had designing something from scratch taking into account lessons learned from SIP experience.

I have been told in the past from engineers at several telco operators that SIP is somewhat heavy to implement for thin mobile devices as compared to XMPP. At the time Jingle was not standardized, so the comparison could not have been complete. Still their experience was an indication that XMPP may be a formidable competitor to SIP for VoIP signaling.

For as long as both protocols are open standards, I am only expecting good things to happen for both mainstream developers and end user.

See the full text of the Jingle Specification Document.

Insider look at 'Open IMS'

IMS Insider explores the subject of a community driven Open IMS platform where industry players pool resources for the mutual benefit of greater ecosystem, faster time to market and better interoperability.

Do you think it will work?

VON Magazine on The Open Source Craze

The October issues of VON Magazine (vol 3, No 10) features on its front page The Open Source Craze (p58).

Doug Mohney reviews the state of Open Source in IP Communications today. He cites Irwin Lazar at the Burton Groupis whos recent survey shows that 5-6% of the companies looking at VoIP are interested in Open Source solutions.

The biggest challange is apparently to get community projects in front of big enterprises. Competing against Nortel, Cisco, Avaya with infinitely bigger marketing budgets is an obstacle. Another factor is migration path from existing legacy systems. OSS projects tend to be all or nothing or do it yourself.

The article argues that OSS VoIP will pick up as big names line up behind it. The comparison is with Linux, which gained traction in the business world after IBM started offering professional level support.

I tend to agree with these arguments as I have been able to witness them first hand on a number of very popular OSS projects.

Fortunately for the Mobicents community, the project is backed by big names both among telco operators and telco vendors. Portugal Telecom, Vodafone R&D, Lucent Technologies, and Aepona are among them. Some started piloting professional support for their products labeled "Powered By Mobicents".

The technology Mobicents builds on - JSLEE is designed to accomodate legacy systems. There have already been developed adaptors for proprietary telecom protocols such as SS7, which can be wired with SIP and XMPP applications running in the Mobicents environment.

I will try to clarify these facts with Doug and we will hopefully see a follow up article in the near future that adds more color to the picture.

It is interesting to hear other opinions on this subject. Do you think OSS stands a chance in IP Communications? Post a comment.

Java.net Features Mobicents - Aepona collaboration

Aepona joins Mobicents; bridges Parlay with JSLEE

Aepona Announces Full Complement of JAVA Support. The telecommunications Software Firm Works with Mobicents To Develop Open Source Parlay Resource Adapters for JAIN-SLEE.

Original article: http://www.aepona.com/press_zone/mobicents.htm.

Other related articles: http://news.google.com/news?hl=en&ned=us&q=mobicents&ie=UTF-8&filter=0

Top IMS Services

Useful survey highlighting the top 22 services that will contribute to the IMS success.

Mobicents downloads reach 1000 per month

As of today, October 25, there are 1024 downloads of Mobicents bundles for the month. This is a record number for the project. It is nearly double the number from September.

See the statistics for yourself:
http://sourceforge.net/project/stats/?group_id=102670&ugn=mobicents&type=&mode=year

Mobicents Examples 1.0 Beta 1 Released

A set of practical examples is released to accompany the Mobicents server and IDE. The examples in this release feature a comprehensive Resource Adaptor Tutorial by Michael Maretzke and a practical SLEE Wake Up Call service by Francesco Moggia. Download here.

Mobicents EclipSLEE 1.0 Beta 1 Released!

This is the first public binary release of the Open Source SLEE tool. It allows rapid creation, development and deployment of SLEE services. Read the Getting Started Guide and try it out.

State of the IP Convergence

Indu Kodukula has an interesting presentation posted on the BEA World site. The title is "WebLogic Communication Platform Overview". It actually has good highlights on the IP Convergence market itself. For example it says that the largest consumer VoIP operator in the US is built completely on the Web Logic SIP Server (hint: Vonage?). Overall 30% of the US operators are ready to do a one time sweep migration to IP Communications. This is pretty significant number in terms of market size.

70% of the US telco operators are not ready to dump their investments in legacy Intelligent Networks. The percentage in Europe is even higher. Most operators need a platform that will allow them to integrate legacy stacks such as SS7 with IP protocols like SIP.

This further helps explain the positioning of SIP Servlets vs JSLEE. The former standard is the right choice for the operators that are ready to make the sudden switch, while JSLEE will be important for heterogenous environments.

Another bit of interesting information in the presentation is that Web Logic SIP Server 2.0 does not have Session Replication and Clustering implemented yet. These features are scheduled for a new release later this year.

I can't help to mention that Mobicents already has clustering capabilities and demonstrated SIP failover at VON last week.

BEA World: Next Gen Communications in the spotlight

BEA continues to charge ahead with an aggressive IP Communications program. It has been a leading revenue source over the last few quarters. At BEA World, the company hosts a number of Communications related sessions. Many of them are available for download for free.

Mobicents presentation at VON Fall 2005

Check out the presentation that Ranga, Francesco, Phelim and I did at VON Fall 2005 in Boston.
Go to download page.

Bridging the Islands - Yahoo Messenger, MSN Messenger, Google Talk; VON Fall 2005

There was an interesting and provocative panel session at VON. Representatives from Yahoo, Google, Microsoft, Nortel and Radvision talked about the value of open standards and interoperability. Each one of them acknoledged the importance and value of communications standards such as SIP and IMS.

I took away two important comments from the discussion:

1) Standards are just the tip of the iceberg. Implementing the specifications and ensuring interoperability between implementations is far more involving and typically takes 3-4 years after the standards are published. This poses a big challange to next generation telcos. In a fast paced world, 3-4 years is an enormous amount of time. There is a chance that more agile alternatives will emerge and gain market share. Asterisk and Skype are already making this point.

The morale of the story for me is that Open Standards supporters should share resources and extend their collaboration beyond specifications into implementation. Open Standards + Open Source implementations seems to make a lot of sense. It ensures low cost, fast paced creation of a unified platforms that a large network of providers can benefit from. It cuts the costs of duplicated development and interoperability testing.

2) While Yahoo, Google and MS talked about the value of interconnected networks, they did not answer very well my SIMPLE question, which was: "When are we going to be able to send a SIMPLE message from MSN Messenger to Yahoo Messenger to Google Talk?".

Russell Bennett at Microsoft said that they supported SIP and SIMPLE since 2001 and are ready to interop with Google as soon as Google is ready. Mike Jazayeri at Google said that they are ready to interop with Microsoft as soon as Microsoft invites them. Madhu Yarlagadda said that Yahoo Messenger 7 supports SIP and they are currently piloting a bridge with MSN. Fingers crossed for the pilot to come through.

I talked to Madhu after the session and he told me that they are working on a program to allow service providers to test connectivity with Yahoo Messenger servers. Mike told me the same about Google Talk. Hopefully the Mobicents community will soon obtain access to try out SLEE services for the two major communications networks.

Here are some pictures from the session:

VON was a blast

We had exceptionally exciting days at VON. Ranga and I were approached by a number of industry players who expressed their support of the Mobicents project. This is the kind of recognition that keeps us going.

Our presentation went great. We had a small audience of experts who knew what Mobicents was and had specific technical questions. What really impressed me was that all 3 demos showed on 3 different laptops worked smoothly. The High Availability demo for SIP mid-call and registrar failover, the EclipSLEE built Wake Up service and the WiFi SIP hand held phone from ZyXel all clicked nicely. That was a surprise to me, because I usually get caught by the demo syndrom and nothing works in front of an audience :).

While we were having fun at VON, the folks at Lucent did amazing work tuning the SIP RA and the SLEE engine. Leondo reported new performance peak of sustained 50cps!!! This puts us only half way from the "unreacheable" carrier grade 100cps! The folks that are tracking the project are probably as shocked as I am that we managed to get from 1 to 50cps in 2 months. Not bad.

I am done packaging the new beta release and will make the announcement later today.

Microsoft Responds to Google Talk?

I don't think so. There is no mention of open standards support in the new MSN Messenger 7.5. Windows Messenger 5.1 is still the latest known MS client that openly supports SIP. I am sticking to it for the time being.

eBay acquires Skype

This is all over the technology and business news. It's been a while since tech companies were valued at 70 times their revenue. VoIP is not all talk any more.

Microsoft Acquires VoIP Startup Teleo

Microsoft won't let Yahoo and Google ride the VoIP PR buzz by themselves. Teleo isn't nearly as popular as DialPad, and they haven't even released a product. Plus Windows Messenger was already a decent SIP client with a good IM user base. But hey, you've got to trust this is money well spent.

Google and Skype opening up a can of goodness

A few weeks after Yahoo! acquired DialPad, Google launched Google Talk and Skype followed immediately by opening up its API. Microsoft is not playing possum either.

With a large desktop install base of interoperable clients using open protocols, VoIP is explosively becoming as pervasive as the Web.

It doesn't take a genius to figure that what follows is a mushroom effect of VoIP service providers. The first big wave is coming from pure play providers like Vonage, traditional ISPs (EarthLink), incumbent telcos (SBC, AT&T) and mobile carriers (Verizon, Vodafone).

Household names like Amazon and eBay will follow next and pave the road to thousands of other web sites. After all it is more natural to ask "can I see the latest MP3 players?" than it is to write it down.

An important question is - what platform will be used to build all these new services on? There are several proprietary ones available on the market, which will flourish in the short term because of the huge demand. As history shows though, before long, Open Standards, Open Source platforms will mature and will take over the lion share. Keep an eye on the Mobicents project as it continues to grow at an accelerated rate community of industry contributors, academia and freelancers.

Ivelin

Open Cloud contributes IDE to Mobicents

Open Cloud generously contributed a fully functional SLEE development tool to the Mobicents project. The tool is an Eclipse plugin, which simplifies the process of creating and deploying VoIP services. Result of several years of research and development, this contribution represents a significant investment by the leading SLEE vendor to the Open Source community.
https://eclipslee.dev.java.net/

The Mobicents team greatly appreciates the contribution and is looking forward to continue the productive relationship with Open Cloud.

Both teams are also starting collaborative work on standardizing the SIP Resource Adaptor Type and Service Building Blocks so that SIP applications are interoperable between the two popular SLEE platforms - Mobicents and Rhino.
http://forums.java.net/jive/thread.jspa?threadID=1155&tstart=0
http://www.mobicents.org
http://www.opencloud.com/slee/intro.html

Ivelin

Sign Up for JBoss World Barcelona in October

If you haven't had a chance to come to the JBoss World conference in Atlanta this year, you won't know how much fun you missed. Barcelona should be even better.

Mobicents performs

Ranga, Fran, Leon and the rest of the team achieved dramatic performance enhancements in July. Mobicents reached 10 caps (calls per second) tested with SIPP. This is easily satisfying the requirements of any SMB PBX. Of course we are not stopping here, next milestone is carrier grade performance and high availability.

The sub-project of focus now is High Availability Demo.

JAIN SLEE, SIP Servlets, and Parlay/OSA (2nd Ed)

You are reading the second edition of this article. It was revised after a good amount of useful feedback was given to the initial version.


In a recent IM chat over Skype, Marco Moneiro and I were discussing various VoIP service delivery platforms. One of his comments struck me. He pointed out that Parlay has an easier to program API than JAIN SLEE, while SIP Servlets is about as hard as JAIN SLEE.

This was certainly intriguing to me, since we are implementing a JAIN SLEE container (the first and only open source certified implementation). I should know how it stacks up against the other competing or complimenting open standards.

Marco works at the Portugal Telecom research lab and has direct experience with multiple VoIP technology platforms. As an active contributor to Mobicents, he often shares valuable perspectives with the team.

So I took the time to look at some example applications and build out my own point of view. After hours of playing with Parlay and SIP Servlet code, I reached my non-expert conclusion, which more or less agrees with Marco, but with certain qualifiers.

Provided that each of the three technology standards have specification documents in the hundreds of pages, my thoughts below are merely scratching the surface of the problem and should be taken with a grain of salt. A lot of them are subjective as they are based on limited information and raw intuition. My opinion may change in the future as I gain more experience.

Telephony protocols and abstraction layers

Before we begin comparing the platforms, I would like to emphasize on a criteria that they will be measured against. Namely communication protocol abstraction.

Everyone seems to talk and write about SIP these days. It is no doubt an elegant, HTTP-simple protocol proposed by IETF that is quickly picking up momentum. However unlike the Web, where HTTP has been the predominant transport for UI content almost since the beginning of the Internet, SIP is just another kid on the telephony block.

Telecom services exist for over 100 years. You can imagine how much legacy has built up in the industry. It is a $600 (six hundred) billion global market, with enormous investments in technology and infrastructure. Add to the mix goverment regulations for service quality, downtime, and auditing. To expect that a new, even if brilliant, session initiation protocol will come in and swiftly wipe everything else out is...utopia.

VoIP represents a mere 5% of the telephony today...and VoIP has been available since the mid-90s when H323 was the packet based protocol slated to commoditize telephony. Well... the Web came to the stage around the same time, revolutionized the way we work and communicate, then crashed, then came back up. VoIP has still to make its point. How much have you heard of H323, how about http://? A recent survey by TNS confirms that consumer awareness of VoIP is still low.

Furthermore there are new emerging telephony protocols such as IAX (Asterisk) and Skype that aggressively capture developers mind-share. Examples of the influence are the new generation devices that directly support these protocols.

Here is a Skype phone on the market today:
.

And here is an Asterisk based PBX appliance:



I firmly believe that VoIP will be a significant part of our lifestyle in the near future. However it won't happen just by replacing existing infrastructure. Rather introducing new converged services, of higher value and lower cost that interoperate nicely with legacy systems will drive consumer interest and ultimately win VoIP a bigger market share.

To allow rapid development of new generation intelligent features, server side developers should not need to know whether the end points connect to the server via SIP, H323, SS7, IAX, Skype, or any other protocol. They should be able to focus on the logic that adds value for the end user.

Now that we covered the perspective on protocol abstraction, let's go back to the original topic and compare examples for Parlay, SIP Servlets and SLEE.

Parlay/OSA

Parlay has a natural programming model, which resembles the style of sequential code seen in desktop applications.

I used the Ericsson Network Resource Gateway SDK, which is freely distributed for research.

Here is a sequence diagram from working Java code implementing a Multi Call Control feature. Disregard the fancy name of the feature, it is actually pretty simple logic. If you are not familiar with telecom terminology, Feature is what a programmer would typically call a service. Take a look:



Feature.handleCall() is the key method in the application. It answers a phone call, asks the user to enter a digit, says something in return and routes the call to the next feature.

If the author had to write the same application for a text user interface, the structure of the code would be essentially the same. Start the app, open the console input, ask for a number, print a text line in response and forward the control to another routine. Plain and simple!

Here is the full source code of the feature:

/**
* Invoked by MPCCProcessor when a subscriber has dialled the service number.
* This method will reroute the call towards a destination that will be specified
* by the calling subscriber, or terminate the call if no valid destination is
* specified.
*
* @param aCall the new call
* @param aFirstLeg the one and only leg of the call
* @param anOriginatingAddress the address of the calling
*     subscriber
*/

public void handleCall(
TpMultiPartyCallIdentifier aCall,
TpCallLegIdentifier aFirstLeg,
TpAddress anOriginatingAddress)
{
// prepare playing announcements to the calling subscriber.
TpUICallIdentifier uiSession = itsUIProcessor.start(aCall);

// ask the calling subscriber to choose a destination
Object uiResult = itsUIProcessor.askDigit(uiSession,
Configuration.INSTANCE.getQuestion(), false);

// determine the destination based on the response
Configuration.Area destination = getDestination(uiResult);

// abort the call if no destination could be determined
// (e.g. because the user response timed out)
if (destination == null)
{
// no more user interaction needed
itsUIProcessor.stop(uiSession);

// terminate the call
itsMPCCProcessor.release(aCall);
}
else // a (valid) destination was determined
{
// give the user feedback on the choice that was made
itsUIProcessor.say(uiSession, destination.feedback, true);

// reroute the call
itsMPCCProcessor.route(aCall, anOriginatingAddress,
destination.address);

// cancel suspension of first leg
itsMPCCProcessor.continueProcessing(aFirstLeg);

// the application is no longer interested,
// so disconnect the association between Ericsson Network Resource Gateway and the network
itsMPCCProcessor.deassign(aCall);
}
}

Pros and Cons of Parlay

Pros:

1. Intuitive API
2. Protocol abstraction: hides the details of the communications protocol
3. Lends itself to unit testing. Features are well encapsulated in logically complete methods.

Cons:

1. Scalability
   
• Footprint: When the application code invokes Parlay methods like askDigit(), the execution environment has to remember the call stack, carry out a complex intereaction with the end point and then return control to the application. Depending on the protocol the interaction with the user can be synchronous (e.g. TCP) or asyncrhonous (e.g. UDP). The voice packets might be routed directly or via proxy servers. In any case the askDigit() method invocation has to appear as a simple synchronous call to the application developer. Such a deep level of abstraction triggers some concerns regarding the resource consumption that each such call incurs on the execution environment. How many OS threads, heap memory, TCP sockets and other system resources are tied up until the call returns?
  


• Fail over :If the server where the application is currently executing crashes for some reason, how does the execution continue on a fall back server transparently to the end user...hard. Possible, but very complicated.
  


2. Troubleshooting: In such highly sophisticated and complex runtime system, how does one trace bugs such as interrupted calls. How do you tell whether the reason is in the protocol layer, runtime engine or the clustering code? Since the application developer is so remote from the inner workings of the deployment platform how can s/he determine inteligently where the root cause is and communicate it efficiently to the platform vendor when needed?

I am sure the engineers who designed Parlay are aware of all the drawbacks enumerated above and have good answers. However having years of hands-on experience with scalability problems in enterprise systems I am having trouble seing comprehensible practical solutions. If you know otherwise, please let me know; Constructive criticism is welcome.

An interesting idea that is circulating in the community regarding Parlay is to implement its APIs as higher level services for SLEE. Working examples have not been shown yet, but it is a good mind teaser.

SIP Servlets

J2EE developers should feel right at home with the SIP Servlets API. This was a design goal for the authors of the spec and they did a good job at it. The most popular API within the J2EE stack is the Servlet API. There are many developers that are not familiar with EJB, JMS, JTA or JMX, but are quite comfortable with servlets. By induction, a vast majority of HTTP Servlet developers should be able to quickly jump onboard and start cranking out useful VoIP services. Right?...maybe. Take a look at the SIP Servlet API:

java.lang.Object
|
+--javax.servlet.GenericServlet
|
+--javax.servlet.sip.SipServlet 

All Implemented Interfaces:

java.io.Serializable, javax.servlet.Servlet, javax.servlet.ServletConfig

---

public abstract class SipServlet

extends javax.servlet.GenericServlet

Provides an abstract class to be subclassed to create a SIP servlet.

This class receives incoming messages through the service method. This method calls doRequest or doResponse for incoming requests and responses, respectively. These two methods in turn dispatch on request method or status code to one of the following methods:

• doInvite - for SIP INVITE requests
• doAck - for SIP ACK requests
• doOptions - for SIP OPTIONS requests
• doBye - for SIP BYE requests
• doCancel - for SIP CANCEL requests
• doRegister - for SIP REGISTER requests
• doSubscribe - for SIP SUBSCRIBE requests
• doNotify - for SIP NOTIFY requests
• doMessage - for SIP MESSAGE requests
• doInfo - for SIP INFO requests
• doProvisionalResponse - for SIP 1xx informational responses
• doSuccessResponse - for SIP 2xx responses
• doRedirectResponse - for SIP 3xx responses
• doErrorResponse - for SIP 4xx, 5xx, and 6xx responses

The default implementation of doAck, doCancel and all the response handling methods are empty. All other request handling methods reject the request with a 500 error response.

Subclasses of SipServlet will usually override one or more of these methods.

The resemblence with HttpServlet is obvious. Both extend javax.servlet.GenericServlet and have similar doOptions() methods. What else is similar? Not much.

SIP Servlets have a fundamentally different purpose in life compared to HTTP Servlets. While the latter are primarily intended to serve HTML pages back to Web browsers, the former are primarily used for registering callers and consequently forwarding call setup requests to the current IP adress of the callee. SIP Servlets can be also implemented on User Agents or Endpoints.

In a casual day-to-day scenario, a Web surfer, friendly Alice for example, uses a search engine to find a web site with the content she is looking for, then hit the URL of the site and get the HTML content from the web server powering the site.

Alice also has a SIP phone that is registered with the SIP server of her VoIP service provider. To call Bob, she uses the phone book or a people search engine on the web to find his phone number (because she always forgets it). Then she punches in the digits and her phone will ask the SIP server about the current IP address of Bob's phone, so that the two can establish a direct voice channel. The SIP server finds the information and returns it to Alice's phone, which then establishes a voice channel over RTP/RSTP (not SIP!) with Bob's phone. At the end of the call Alice hangs up the handset and her phone notifies the SIP server that the line is available to take incoming calls.

This is an oversimplified scenario, that assumes a SIP only world, but fits the scope of this text. Notice that the actual content (voice) is not delivered over SIP as it is in the HTTP case with HTML. It is instead delivered over RTP. SIP and RTP are independant standards. SIP is used for signaling, RTP is used for media. SIP Servlets do not deal with content delivery(media). It is not possible to play a voice message back to a caller directly from the SIP Servlet doResponse() method. Notice the difference with Parlay?

What about VoiceXML? Many developers have heard of it as the cool XML language similar to XHTML Forms that allows users to input data by speaking instead of typing. Maybe SIP Servlets can serve VoiceXML content to SIP phones? It's possible...but it is not how VoiceXML is used typically. In most scenarious VoiceXML is served by Web servers directly to end points or to an intermediary text-to-voice transformation engine. The following research paper from the Columbia University, illustrates well the roles of SIP, RTP, HTTP, and VoiceXML in a conference call system: http://www.nyman-workshop.org/2002/papers/2272.pdf

Here is a snippet of code from a SIP Servlet, which connects a caller to a callee either directly or via alternative SIP Proxy:

protected void doInvite(SipServletRequest req)
throws ServletException, IOException {

if (!req.isInitial()) { super.doInvite(req); return;}

List contacts = resolve(req.getRequestURI());
if (contacts.isEmpty()) contacts = resolve(req.getTo().getURI());

if (!contacts.isEmpty()) {
trace("Found contact info - " + contacts );
Proxy p = req.getProxy();
p.proxyTo(contacts);
return;
}
String next = getContextParam("next_app");
if(next == null) {
// Reject as not found
trace("User not found and no forwarding servlet info available");
SipServletResponse resp = req.createResponse( 404 );
trace(resp);
resp.send();
return;
}

// pass it to next proxy
SipURI nextUri = getPlainURI((SipURI) req.getRequestURI());
nextUri.setParameter("servlet", next);
trace("User not found, route request to <" + nextUri + ">");
Proxy p = req.getProxy();
p.proxyTo(nextUri);
}

Pros and Cons of SIP Servlets

Pros:

1. Familiar API. Most J2EE developers will be comfortable to try it without going through specialized training.
   
2. Scalability: SIP Servlets are designed to be mostly stateless. SipSession is the recommended structure where servlets should store non-persisted state. To ensure transparent failover the session has to be replicated to other cluster nodes. This is a well understood problem and there are practical solutions that can be borrowed from Http Servlet containers.

Cons:

1. Protocol Dependency: As the name implies, SIP Servlets are strictly tied to SIP and do not address other practical protocols like H323, SS7, and IAX. It is up to the application developer to come up with abstraction layers so that code written for SIP Servlets can be reused for non-SIP clients.
   
2. Danger of mixing front end with business logic: Sip Servlets seem vulnerable to some of the problems that HttpServlets exhibit.
   
• Servlet developers tend to mix flow control with business logic, which makes the code harder to maintain and reuse.
• Unit testing of servlet code is not simple, because it requires simulation of the communication protocol. Frameworks similar to Jakarta Cactus and HttpUnit will have to be developed to alleviete this inconvenience.
  
3. Lack of rigid component model: As VoIP applications mature and grow in size, there will be likely demand for component frameworks that separate the call control from the business logic classes and the persistence layer. Existing J2EE APIs like EJB and JMS will be prime candidates to fill the void. JAIN SLEE is also a contender. Time will tell, which one will be the preferred direction for developers in the long run.

JAIN SLEE

SLEE (Service Level Execution Environment) is viewed by some as the crown jewel of JAIN (Java APIs for Inteligent Networks).

If you glance through the specification you will notice that many concepts sound, look and feel like J2EE. For example ActivityContext reminds us of HttpSession, CMP semantics of SBBs and Profiles are similar to EJB CMP, transaction isolation, JMX and JNDI are also present in SLEE with almost identical characteristics as in J2EE.

That is not accidental. The expert committee took their time to learn from the J2EE lessons and cherry pick concepts, techniques, and best practices from it that best fit the needs of a Next Generation Service Delivery Platform. It took 5 long years from the initial formation of JSR 22 until its public release in late 2004.

Compared to the 100+ years of telecom legacy, 5 years is an impressive achievement for a standard that accomodates input from such a wide variety of industry players with disparate interests. The discussion took a long route starting from the possible adoption of a Java API for SS7, which is a a highly specialized telephony stack covering a wide range of networking layers including a physical layer.

Eventually the experts recognized the need to attract the mainstream application developers and made a significant effort to accomodate relevant J2EE ideas and constructs.

But the story is not all rosy. My personal initial experience with JAIN SLEE was not a positive one. The spec is overwhelming and hard to grasp at first! This is a red flag for its future adoption rate. I have 5 years of hands on experienced with J2EE and am member of the JBoss core team. JBoss is the J2EE server with #1 market share. If I cannot get up and running with SLEE in a few days, what chance does it stand to win mainstream developers mind-share?

Those who have been on the front rows of the Web technology evolution from CGI to PHP3 to JServ and eventually EJB, would probably appreciate a chance to skip a few iterations in the VoIP middleware evolution and go straight to SLEE. 7 years ago, EJB was insanely overwhelming for newcomers. Now, we all love EJB3.

Now let's look at some application code. Assume a new call comes into the SLEE. The call has one call leg that an SBB is interested in. SBBs are Service Building Blocks used to compose higher level intelligent features. They are similar in conept to EJBs.

If the SBB in question decides to immediately disconnect the connection it will do so in the call back from SLEE:

public void onAlertingEvent(JccConnectionEvent event, ActivityContextInterface ac){
JccConnection connection = (JccConnection)ac.getActivity();
connection.release();
}

For the SBB to create a new call, it will use the following sequence:

JccProvider provider = (JccProvider) new InitialContext.lookup("location");
JccCall call = provider.createCall(args);

To receive events on this call, the SBB must subscribe in the following manner:

ActivityContextInteface ac =
JccActivityContextInterfaceFactory.getActivityContextInterface(call);
ac.attach(sbbLocalObject);

You probably notice the resemblence with Parlay. The call protocol is abstracted via the JCC API, which nicely fits in the context of SLEE.

One unique characteristic of SLEE is its asynchronous signaling model. SLEE encourages components to communicate among each other via asynchronous events. SBBs are expected to implement self-contained units of logic, which react to events, promptly perform their assignment and produce another event as ouput. The resulting event can be a message to another SBB or a Resource Adaptor.

SBBs are mostly stateless, but they can have CMP fields which allow them to keep non-persisted state, similar to Stateful Session EJBs. Persisted state is stored in Profile Tables, which can be viewed as simplified relational database tables.

SBBs do not directly interact with objects outside of SLEE. Instead they receive and send events to specialized Resource Adaptors, which in turn are responsible to interface with the world. Examples for RAs include SIP RA, EJB RA, Web Services RA.

Multiple SBBs are assembled into Services (aka Features) such as Find Me and Call Forward.

Here is a SLEE component diagram:



Another important characteristics of SLEE is that it defines event delivery semantics based on SBB priority level. Since most of the signaling is asynchronous and goes through the SLEE event router, the prioritization semantics allows emergency (e.g. 911) calls to quickly go through despite the presence of other ongoing calls no matter how many of them there are.

To learn more about SLEE, you can start with the following white papers and articles:
http://tinyurl.com/8appk

Pros and Cons of JAIN SLEE

Pros:

1. Protocol Abstraction: SLEE promotes multiple planes of abstraction. However it does not go as far as hiding the asynchronous nature of call signaling.
   
2. Scalability: Mostly stateless, well defined structures for replication and persistence. Asynchronous messaging allows the runtime engine to quickly route important calls. A simple event routing algorithm, which lends itself to multi-threading.
   
3. Component model: Strong component model reflecting best practices derived from vast experience with telecom systems. Rigid mathematical model for event routing and well defined state machines for the life cycle of each component should make it safe to switch between compliant vendor implementations.
   
4. J2EE friendly: SLEE APIs heavily borrow from J2EE. There is also a set of best practices for interoperability between SLEE and J2EE.

Cons:

1. Steep learning curve: Developers will likely need initial training before they can write proper SLEE applications. Availability of visual tools, self-guided tutorials and best practices will be essential to flatten the learning curve.
   
2. Integration testing:Well designed, self-contained SBBs should be easy to unit test. However testing end to end scenarious that involve multiple SBBs are harder to write, because the flow sequence can be time sensitive. The SLEE TCK provides a good base for writing end-to-end tests and it offers good examples, which alleviates the problem to some extend. There seems to be a need for a testing framework which further simplifies matters.

Conclusion

In this text we looked at three viable VoIP middleware platforms - JAIN SLEE, SIP Servlets and Parlay/OSA. We saw some of their key diferences and similarities. Since each of the three open standards has been implemented by multiple vendors and deployed in real-life production systems, they have all proven their qualities.

Adoption however remains limited to relatively small communities as compared to mainstream middleware systems such as J2EE or .NET. Google search returns 8,370 results for Parlay/OSA, 40,300 for JAIN SLEE, and 45,800 for SIP Servlet. Compare that to 8,870,000 for J2EE and40,900,000 for Microsoft .NET. The question still remains, which VoIP platform, if any, will come close to these numbers.

For completeness, it should be noted that there are reports of alternative solutions, which bypass the forementioned VoIP platforms altogether. For example a click-to-dial application can be constructed with a plain HTTP Servlet container and a JAIN SIP library.

So there it is. Now that the cards are on the table. which direction are You most likely to take?

Related reading

The following resources offer alternative views on the comparison between the three platforms discussed here:

• A SLEE for all Seasons; White paper by Open Cloud
• JAIN SLEE and SIP Servlet; White paper at jainslee.org
• JAIN SLEE and OSA/Parlay; White paper at jainslee.org
• Parlay Java API Rulebook Overview; Presentation by Kieran McPeake, AePona
• JAIN Overview; Presentation by Sun Microsystems, Japan
• Java in Communications; Presentation by Steven Grover, Sun Microsystems

Acknowledgements

I would like to thank Ranga, who is a respected expert in the JAIN community, for taking out of his own time on the weekend to review this text and provide important corrections. I would also like to thank Phelim O'Doherty, Swee Lim and the rest of the people who posted comments to this text since it was initially published.

JSR 281: IMS Services API

Bob Bickel at JBoss pointed me to this new JSR proposal. It looks like a Java ME device API that will standardize the client side of mutimedia services.
http://www.jcp.org/en/jsr/detail?id=281

Interestingly it does not cite relationship to JAIN.

Does anyone have thoughts on its significance and the relevance it has to JAIN SLEE or SIP Servlets?

Mobicents presentation at VON Fall 2005

Ranga, myself and a panel of Java VoIP experts will present at the Open Source VoIP Summit co-located by Pulver at VON Fall 2005 on September 19. Here is the abstract:

As VoIP applications are growing in number and complexity, the development community is naturally looking out for prevalent middleware standards to enable deployment of platform independent, interoperable services.
SLEE (Service Level Execution Environment, JSR 22) has been carefully crafted to fit at the heart of Next Generation Service Delivery Platforms (SDP) and IP Multimedia Sub-systems (IMS). This presentation will introduce the audience to SLEE and the first certified open source implementation - Mobicents. It will also study an end-to-end example to illustrate:
- Composing VoIP application from SLEE Service Building Blocks (SBB).
- Guidelines for exposing management information via JMX
- Best practices for integration with SOA via Web Services interface
- Best practices for native Java integration with J2EE

Mobicents presentation at Java One 2005

For the folks that could not attend the presentation at Java One, I am posting a PDF document and two pictures taken by Michael Maretzke.

Mobicents Presentation at JavaOne 2005.






Ivelin

Another book on Asterisk

I noticed Ted's blog on his new book - "Switch to VoIP". Following the Amazon link I noticed that there already are several more books on Asterisk. Last year there were none.

Wonderful things happen at JavaOne - Java PBX appliance is born!

Tomorrow at 3pm I have a talk at the Java.net Community Corner. I will present JAIN SLEE and a demo of the first certified open source implementation - Mobicents. The demo will show a simple SIP PBX deployment scenario. I will run the server on my laptop, then register two phones with it and establish a voice call. Come see it if you are at J1. As I was checking on the Java.net booth today to prepare for the talk, I noticed two pods showcasing a slick looking box with the Java logo on it. It turns out this is the new JBox - embedded Java box. It is a joint product of Sun, VIA and iGoLogic. Priced around $300 and fully capable of running Java Standard Edition 5, it is the new reference platform for embedded Java devices. This is the box that Ted Kosan, Embedded Community lead, has been excited about lately. The light bulb suddenly came on. Instead of showing the demo on my laptop, why not set it up on JBox. That will be the First Java PBX appliance!. Just a prototype of course, but how far can a marketable product be? 3 months, 6 months max.

Mobicents - Open Source Java VoIP Middleware is Here

The Mobicents team released version 1.0a, which is an officially certified implementation of JAIN SLEE 1.0. This opens a new page for application development on Open Source VoIP middleware.

VoIP on your cell phone?

http://pulverblog.pulver.com/archives/002404.html

How long until the cell phone providers sell fixed-price bandwidth and you get to use your favorite VoIP client?

Ivelin

Sun sheds light on its VoIP plans

Sun Microstems launched two press releases around the SUPERCOMM conference in Chicago this week. Taking advantage of their established reputation with the telcos, Sun is positioning its servers and Solaris 10 at the base of a Service Delivery Platform program, giving way to other vendors like Open Cloud and jNETx to build the higher-level software layers. This is consistent with the recent $4.1B acquisition of StorageTek tightening Sun's focus on hardware and OS.

http://www.sun.com/smi/Press/sunflash/2005-06/sunflash.20050606.5.html
http://www.sun.com/smi/Press/sunflash/2005-06/sunflash.20050606.1.html

Ivelin

Applying the Professional Open Source Development Process to Your Project

Sys-Con TV published a video replay of my presentation at JBoss World 2005. Check it out if you want to know how Professional Open Source is written. You might learn a few tricks that will help your development process.


http://education.sys-con.com/read/84518.htm

Skype engineers were NOT telco specialists

This was the quote that Niklas Zennstrom, Skype CEO, made during VON Europe last week before an overflowing room of attendees. You can download his presentation. The statement is on slide 13, "Why Skype":

Outside-of-the-box technology - none of our engineers were telecom engineers – they just solved the problem

This should put VoIP in a whole different perspective for mainstream application developers.

New Community Leader for Java.net Communications

I am happy to let you know that I was invited to become Community Leader for Java.net Communications.

This is a result on our collective progress with Mobicents.

It is an honor to take the offer from Doug Tait and share the role with Ranga and Emil.

To rejuvenate the community excitement on JAIN SLEE, I will kick-off the new season with a mini-talk at JavaOne on the Community Corner show floor. It will be on Wednesday, June 29 at 3pm PST. Join me if you can.

Parallel with that we started conversation with the top management of Java.net to scetch out a plan for accelerating the growth of the Communications Community.

It's a good day for JAIN SLEE...:)

Ivelin

JAIN/SLEE: EJB for Communications

Sven Haiges wrote a good introduction to JAIN SLEE. I would encourage follow up artcles exploring best practices for developing applications on SLEE. That in combination with the fully open source implemention at http://www.mobicents.org should lower the entry barrier for new developers.

JAIN/SLEE: EJB for Communications
— While the JAIN APIs still play only a minor role on Sun's Java Web site, the JAIN initiative is getting stronger. The JAIN technologies (Java APIs for Integrated Networks) have the potential to radically change the existing service architecture for communications service providers.