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]
First stab at chapter 1
Where do I start? Allright, this picture.
Now the context: last monday we met in my place in mexico city. By we I mean: me, Eric, and Antonio. For the recording of chapter one of the video series. There was an interesting talk (platica), mostly between Eric and Antonio.
Ok, this should've been in the video, but we simply didn't / forgot to do it :) No introductions recorded. Therefore allow me to put a brief one here.
Antonio Echeverria works as a solution architect in one of those vendors that are pushing IMS. We knew each other when I was working in a project for an (fixed) operator in mexico. His role / job in the company allows him to get some insights of the current situation of the IMS, business and technical-wise, especially for the mexican market. He's been a telco domain for quite a long time, and I'm fortunate to be able to learn things from him.
Eric Werkhoven was my colleague in the company we used to work for during 2005-2006. The company was developing a hosted call-center solution. Currently he works for another VoIP company producing & providing outbound / predictive dialing solution. A deep understanding and appreciation of the technical challenges in developing and deploying of large-scale VoIP solution is something that I learn from him now and then.
Antonio and Eric are from two different worlds that are colliding (or converging?). I was happy to be able to get them together and talk, exchanging their views, which might not be completely aligned to each other.
The talk we had last Sunday was mostly about the business-models / opportunities around IMS. We think that's the most important point to grasp before delving into technical discussion. I personally am interested to know the value-chain; to see where I -- viewing myself as a (potential :D) service provider -- might be able to fit in, and how to profit from it. That's what I would like to share with others in the video(s). Of course we don't pretend to become an authoritative source for that kind of information. We just wanted to capture our learning process. Here's the unedited conversation I managed to record (only 38 minutes).
Unfortunately, we only had an hour to get together on that day. Because of my stupidity I also forgot to record the first 15 minutes of the conversation (when we were discussing the flow of the dialog); some interesting points were brought up there.
So here I am now, grappling to collect those points and make up for the lacks. I'm trying to back up some of those points with some references I can find on the internet / other sources. Hopefully this can improve the value / usefulness of the information I'm going to provide in the video.
Ok, so that's the context. I promise to post those points as a written text in a couple of days, before presenting them as a video. The point I'm presenting here -- just one point -- is a prelude to that post.
Content proxy. That's one thing that came up during the discussion. We were exploring the scenario where the operator acts as a proxy to the contents in the internet. In Eric's opinion, telco operators are not capable to compete with the internet. The rate of innovation that's happening in the internet is unparalleled. So the operator is not supposed to go down the path trying to (re)create the existing successful services / content on the internet. Basically he considers the thinking that "with IMS the telco operator can be like Google" is misguided at best.
So, being a content proxy might be their (only?) option. Let's go back to the diagram. First and the foremost, IMS is supposed to provide the same set of basic telephony services that people already enjoyed with the current, non-IP, technologies. That's what line A represents.
IMS lives in an IP network (after all IMS is an abbreviation for IP multimedia subsystem :P). In order to be able to fully deliver its promise(s), the clients also need to be in the IP network and have SIP-stack installed (among other things that make them IMS-capable). There aren't enough mobile devices in the market with such characteristics. In fact, it is an obstacle to a wide-spread adoption of IMS.
However, people can already enjoy high-speed access to IP network; 3G. Mobile devices have improved significantly. Things like iPhone, for example, turn lack of screen-space and crippled web browsers into things of the past. People can have direct, unabridged access to services like YouTube, Last.FM, etc. That's what line B represents.
The "content proxy" idea, to my understanding, is like trying to drive the subscribers away from line B to line C. People will do that willingly if they perceive additional values. What kind of additional values can be provided (with access through line C)? What does IMS -- and only IMS -- have to offer that enable such services? There was a relevant point raised during our discussion (that might provide an answer to those questions). It has to do with subscribers' profile (stored in the HSS) or rating & billing system (that is a complex stuff to install, configure, and manage correctly). Operators might be able to bank on it in their IMS offerings. That idea is still not perfectly clear to me, give me time to investigate it further.
In the meantime, please chip in, help me enrich the discussion, help me arrive to the right conclusion.
Thanks in advance and best regards,
Raka
UPDATE: When the recording started we were talking about Connected Home that Antonio mentioned to us. It got me thinking of the effort from Ericsson to push further the widespread of this telco 2.0 app. development, by providing hosting for SIP-servlet applications (on Sailfin), and some helper APIs and other stuffs. Check it out on the Ericsson Labs page.
