Random stuffs #1

Tired.

I feel like crawling to finish the chapter 4 of my video series. Well, to be perfectly honest I haven't done anything about it in the last two weeks. Sigh. I feel exhausted. I need gado-gado, sate babi, sate lilit, tum ayam, ayam betutu, nasi padang, nasi kuning, lawar bali, nasi tim ayam, nasi uduk, etc. They're all my fave indonesian foods :). Ok, one more saturday for chapter 4, and that's it. I will have to use a different strategy for chapter 5 (the final chapter) that talks about VoiceXML. I probably will record directly the training session on VoiceXML I'll try to set-up in the new company I'm working for. That will save time.

Anyway, news: I just changed workplace. I have done my service as system analyst (on the side of nextel mexico) in the implementation of their new rating and billing system (using a product named BSCS iX from a company named LHS). It was a 11-month assignment and it served me well, I got to know the possible parameters & scenarios for charging and reference about a commercial system for that purpose among other things.

Now, still in Mexico City, I work for a startup company that specializes in development of VoIP system, and more specifically teleconferencing.

In this entry I'd like to sum up a couple of things I've been thinking the last couple of days. First: I want to unify the knowledge I've gathered so far in rating & billing, SIP servlet, and VoIP in general in my effort of designing a complete teleconferencing solution (and business). Here's the list of technologies I'm currently looking at:

(1) Conferencing bridge

We have things like Asterisk (with MeetMe or ConfBridge), jVoiceBridge, and some other commercial solutions (e.g.: Avaya's spectel). I know a little about how to use MeetMe in Asterisk, I played around a bit with it in 2006.

jVoiceBridge provides a good documentation at architectural level that helps me get a better idea of the functions / possible uses of a conferencing bridge. Additionaly, someone wrote a nice intro to jVoiceBridge.

The design of the conferencing solution, of course, will have to accomodate the need to interface with several conferencing-bridge products. So, we'll have to build an abstraction layer. But, still, I need to know how those choices compare against each other in term of feature-set and performance, in order to be able to define a lowest-common denominator and prioritize the development effort.

(2) Rating-and-billing (including online-charging, which requires the use of AAA protocol).

This is important because... well, it goes hand-in-hand with the business-model. I mean, the business-model dictates the requirement for the rating and billing system. This is a top-down view in my opinion.

On the other hand, the more well-designed (flexible, extensible) the rating-and-billing system is, the more room is there for the business model to grow / move. This is the bottom-up view.

I'm wearing the engineer hat at this moment; I'm taking the bottom-up view. I need to know what level of flexibility in rating-and-billing is possible with current (readily available) tools; how far we can go. So..., I tried getting opensips + freeradius + cdrtool installed. The reasons: (a) that's the first one that appear on google for my query :), and (b) I've heard good comments about opensips, especially when it comes to performance.

I got opensips installed without problem on my debian linux. But it's completely a different story with CDRTool. The installation guide is not complete (a couple important stuffs are skipped. Apparently it assumes reader's familiarity with integration of freeradius with opensips). At the end, I failed to get it working. I wish somebody had written a better, more thorough, well-written and well-tested manual. Please let me know. I decided to drop it for a while; it already took my entire sunday last weekend!

(3) Still in rating-and-billing.

To my understanding, the combination of opensips + freeradius + cdrtool provides us only a way to decide whether a call is allowed (by querying freeradius), collect the SIP trace, store them in the database, correlate the INVITE and the BYE of a SIP session, calculate the duration, and apply the rating formulas to the session.

Another component is needed for enabling online charging, that allows the call to be terminated once the credit reaches certain threshold. AG-Projects (the same company that produces CDRTool) has a product named "Call Control" just for that. It works together with CDRTool (as the rating engine) and opensips module named callcontrol that queries the "Call Control" application every predetermined amount of time to find out whether or not the call should be dropped. That's how I see it.

However, I just get the impression that CDRTool + CallControl only address the basics of rating. In order to make it commercially viable, it has to be augmented with other software packages that allow us to work with concepts like rate plan, rating package, promotion, free units, hierarchical account, etc. Please note I'm using my knowledge of BSCS iX as a reference.

I came across this one JBilling, an open-source billing software. From a quick glance, it seems to be feature-full enough. My upcoming tasks would be: buy the manuals of jbilling which in total would cost around 140 USD (or 40 USD without the extension and integration guide), evaluate it, and later investigate if it makes sense & worth the effort integrating it with opensips + cdrtool + freeradius + callcontrol.

Worth the effort? Well..., I was a bit put off by the difficulties in getting opensips + freeradius + cdrtool to work, so I started to think: "If it's only about collecting SIP traces, detecting the start and stop of a call, and applying some simple rating functions then what's the big fuss about?". Allright, rating might be the not-so-easy part, but -- assuming jbilling is the right thing -- rating engine is already part of jbilling (see the general architecture diagram of jbilling).

So, what is missing are CDR collection, online-charging (ability to disconnect the call once the credit is up), and authentication-and-authorization. Doing all of them in-house doesn't sound unreasonable to me. I think we can use SIP-servlet to implement them, and deploy them together with jbilling as a single deployment unit.

(4) Newer AAA (authentication, authorization and accounting) protocol: diameter

My last concern about opensips + freeradius is the protocol it uses: radius. Well, there's a newer protocol, diameter. What's the real advantage it offers to the conferencing system I want to build? I don't know yet, but if we plan to sell this solution to telco operator that uses IMS then I believe we have to work with diameter (as diameter is the AAA protocol of choice in the IMS architecture).

So, again, that is another reason not to use opensips + freeradius + cdrtool combo in our solution, but instead implement the interfacing with diameter-based AAA system on our own. Furthermore, I have to think about providing a layer of abstraction in our code that would allow us to sell this solution to two kinds of customer: (a) those who don't have rating-and-billing system, and (b) those who do. For customers of type "a" we can bundle it together with our rating-and-billing system (based on jbilling, for example).

Ok, again, assuming this part of the conferencing solution will be implemented as an enterprise java application containing SIP servlet components, then the availability of diameter stack in the SIP servlet container will be very much welcome. Fortunately that's how it is now: Sailfin will (or already?) have diameter stack (using OpenBlox), read it here: http://blogs.sun.com/theaquarium/entry/sailfin_diameter_support_online_charging. The same thing with Mobicents from Redhat, it comes with diameter stack from jdiameter. More detail here: http://groups.google.com/group/mobicents-public/web/mobicents-diameter.

[Update: continued on this entry]