Raka's

VoiceXML Automated Testing, using JVoiceXML

2011-09-26T01:32:00.047-05:00

Okay, just some quick & drafty entry here.

I needed a way to automate the testing of IVR applications (VoiceXML). Quick googling will take us to this (Microsoft) and this (Empirix). I can't make any comment on either of those options, because I haven't used any of them; Tellme retired its free-developer account service, so I can't access Tellme Studio any longer. As for Empirix, based on what I read on its webpage, I don't think it's exactly the one I was looking for (it talks about recognition error rate, prompt quality, etc., while my concern is mainly about the flow of the dialogs).

UPDATE: I guess this product named "Voiyager" is close to what I'm looking for. Link: http://www.syntellect.com/pages/products/voiyager_eng.aspx

What I want is really simple (to begin with): I want to verify (quickly) that if I press "1" in a dialog that asks "What do you want to drink? Press 1 for coffee, Press 2 for tea.", then the next prompt would be "You selected coffee. What type of coffee? Press 1 for cappuccino, press 2 for espresso".

This is based on my observations on how clients specify their expectations..., as a theater script with two actors in it, the IVR and the user. Like this:

IVR: What do you want to drink? Press 1 for coffee, Press 2 for tea. (or: audio_01.wav)
User: Press 1
IVR: You selected coffee. What type of coffee? Press 1 for cappuccino, press 2 for espresso. (or: audio_02.wav)
... (and so on).

So I thought it would be nice, if we can make a little program that takes that script and check it against a running IVR.

I've seen some people attempt to automate the test using automation tool like AutoIt, that basically (1) starts a softphone, (2) dial the IVR, (3) input DTMF (by pressing buttons in the softphone app), and that's it.

The problem with that is:

There's no (easy) way to verify the prompts. Tool like AutoIT is a GUI test tool, designed for testing desktop applications, to check properties of GUI elements in the application. You can't use that to capture audio, let alone to compare it against our expectation (which would be expressed in a text format).
Without a way to verify the prompts, the test is useless.

And then I came across JVoiceXML, an open-source VoiceXML interpreter, written in Java. Somebody else came up with the idea for the test-tool ( described here: http://sourceforge.net/apps/mediawiki/jvoicexml/index.php?title=UnitTest ). I simply took that idea, and implement part of it. I started with something really simple: I want to be able to express each scenario in the following format (plain text file):

i.Please enter 1 to go to formB, or 2 to go to formC%1
a.You are in prompt B
i.Please enter 34 followed by # to go to formD, or 35 followed by # to go to formE%34#
a.You are in prompt D

The line that starts with "i." means: an input collection is expected, where user will prompted with the question to right of the first "." & the left of "%", and user will respond by pressing sequence of digits specified to the right of "%". The line that starts with "a." means: user will be prompted with the question to right of the first ".".

And, to run the test (scenario), I would only have to type this command in the console:

java JVoiceXmlTest http://mywebserver/index.jsp scenario_01.txt

Where the first parameter (http://mywebserver/index.jsp) is the URL of the landing page of the IVR, and the second parameter (scenario_01.txt) is the name of the text file that contains the scenario.

So, here's what I got so far (video below). Nothing interesting :) yet, just some scrolling text in a console. What's more interesting is some findings I made when I was modifying JVoiceXml source code.

Ok, now the findings (I hope this can be a useful feedback for JVoiceXml team in refactoring effort):

JVoiceXml has a dependence to RMI (i.e.: it binds itself to the JNDI during startup). It maybe fine for the intended use of JVoiceXml (as a networked application). However, for testing tool like this one here, I just want to run it as a standalone component. Particularly, I'm only interested in the voicexml interpreter core. For now, I simply comment out the lines of code related to JNDI and RMI. I hope future versions will be refactored to let us use the voicexml interpreter as a plain java object.
JVoiceXML has this architecture that allows you to change the "platform factory". A platform factory is basically an object that creates other objects that know how to obtain and process the (spoken) input and (audio) output. Inputs and outputs go through an instance of "Telephony" (it's the canal).

The good thing is JVoiceXML comes with a "text platform factory" that takes inputs as texts and produces outputs as texts. A slight modification was needed to that "text platform factory", because its telephony read input / write output from / to server socket. I don't need that; I needed to by-pass that and use simple method invocations. So I created a wrapper around it, that's the PruebaPlatformFactory.

Another finding (lengthy one, and the most challenging), the issue with semantic interpretation of grammar.

Currently the implementation of its GrammarChecker does not support semantic interpretation. So, you can not associate a (custom) value to phrases supported by your grammar. This limits the use of JVoiceXML.

In my case, for example, I need to capture a 4-digits pin number. Well, for that actually you can simply take the "utterance" and treats it as the value. Let's suppose user is required to complete the input by pressing the # after the fourth digits. Well, for that you can also simply take the utterance, and (in your "business logic" you drop the trailing #). You don't need semantic interpretation for such case.

Anyway, semantic interpretation is important; any decent VoiceXml browser must support it (conforming to a specification like SISR). So I set out to solve this, as part of an exercise. I ran into some difficulties, because I still don't have a good grasp on how the GrammarChecker and (to lesser degree) SrgsXmlGrammarParser work; what's the principles & logic. I guess the difficulties stems from the fact that the tree structure in the static model (the SRGS grammar) is transformed to a linear structure when the input is checked against the grammar.

So I just put my modifications in some sensible places in the code where I can intercept the event of " node is visited". My code simply collects the content of those (which basically is line of JavaScript code) , and stitch those lines of JS code (in some order) when the walk is completed. The code then feeds those lines of JS code to the embedded JS-engine (Rhino), and I simply take the return value of the execution of the JS code, and assign it as the "semantic interpretation".

Take the following grammar for instance (click to enlarge).

If the input from user "34#", then the JS-codes that the GrammarChecker will produce would be:

var digits = new Object();
digits.MEANING='D';
var root_rule = new Object();
root_rule.MEAN2=digits.MEANING;
root_rule.MEAN1='form';
root_rule.whereToGo=root_rule.MEAN1+root_rule.MEAN2;

The return value from the JS execution is always the value of the last line, so effectively we will get the string "formD".

My current fix is kind of hackish. I just did the minimal thing to make the cases listed in http://box.net/files#/files/0/f/0/1/f_945790295 pass. The ideal solution would be the one that passes SISR 1.0 conformance tests. For that I will need to take a closer look at the SrgsXmlGrammarParser and GrammarChecker, and the related classes & interfaces. I feel the need for refactoring in that area. The way GrammarNodes and SrgsNode are (currently) structured doesn't make it easy to navigate through the tree / walk, which might be required for efficient implementation of semantic interpreter. I was also thinking, why not use ANTLR for generating the bulk of the grammar interpreter? I guess that would be easier & produce cleaner code.

Last finding: this time about notification. I need a way to get notified whenever any of these two things occurs:

The interpreter is waiting for input, so that I can put code that pro grammatically feeds the input in.
The interpreter is playing a prompt, so that I can put code that compares the prompt with the one specified in the scenario file.

JVoiceXml employs strategy design pattern (see interface TagStrategy), which I exploits here to achieve those two things mentioned above; I simply implements a TagStrategy that wraps around the default strategy, so I can do some interceptions, and fire the notifications from there. Hmm, well, I was lying. I mean, that would be the right way to do it, but for now (because I don't have much time), I simply modified the implementation of the default strategies. Told you, it was hackish :).

The modified JVoiceXml is available here (it is based on JVoiceXml 0.7.4.1). Actually, it's of little use for public right now (it's really yucky!); I will have to modify it anyway sometime later, only after I get a firm understanding of the grammar interpreter, in order to make it SISR 1.0 compliant.

Okay, that's all for now!

Hmm.... Pretziiii....

2011-05-16T09:50:00.004-05:00

Just toying around with Prezi....

The Software Map on Prezi

Microsoft Lifecam Cinema Component for Windows Embedded Standard 2009

2010-06-20T18:12:00.009-05:00

I have a need to have Microsoft Lifecam Cinema (high-definition PC camera) working on Windows Embedded Standard 2009.

I'm aware that several people in the internet is also looking for a solution for that task. Well here it is: download the component design file (SLD) here. You can then simply import it to your component repository, and use it in your target design (search for "Lifecam" in the component list). Download the zipped folder that contains the Lifecam's driver here.

In your target design, don't forget to add the following components as well: PNP (User-Mode) and DirectShow Capture. I still have to analyze if they both should go into the SLD file.

I'm writing "from the ground up" document with topic: building a lean custom image of Windows Embedded Standard 2009 that supports Microsoft Lifecam Cinema. Stay tuned. Will have it ready this weekend. Cya! In the meantime, enjoy the music :) -- a composition by Collin McPhee (read this one as well) from his work Tabuh-Tabuhan.

UPDATE: here it is!
Microsoft Lifecam on Windows Embedded Standard 2009

Continuing DBConan Zeta....

2010-04-05T00:35:00.019-05:00

Alright,

I changed the implementation of the domain model of DBConan Zeta. In the previous entry I mentioned the domain object (Schema, Table, Column, etc.) will make use of QExplicitlySharedDataPointer. Well..., I decided this weekend to use QSharedDataPointer instead. More on that later.

Second, on the trick to avoid that "field has incomplete type". In the previous entry I said "use pointer". Now I decided to get rid of pointers altogether. It looks so un-QT-ish :) to me. I might be wrong here..., but the * signs hurt my eyes :).

Oh no, I'm slowly becoming a QT zealot. It reminds me of my early days learning Java 12 years ago....

Source code here: http://www.box.net/shared/8zt5p6u9vz

Ok, on the jump from QExplicitlySharedDataPointer to QSharedDataPointer. Why? At first I thought QExplicitySharedDataPointer is the way to go, because -- the way I understand it -- it practically gives the effect of "pass-by-reference", which is the default mode of Java / C#.

For those who are not familiar with QT: QSharedDataPointer means implicit sharing..., while QExplicitlySharedDataPointer means explicit sharing.

In practical terms, implicit sharing means: when you modify an object, from within a function (that gets passed in the object), the caller of the function -- the one that passed the object into the function -- will not see the change you made on that object. Surprise (!). The reason is, at the point a non-const function is invoked on that object, the sharing is automatically broken; a deep copy is made, which means that object now has its own set of data, so that any changes made by that function would not ripple (inadvertently) to other part(s) of the program.

Hmm..., actually I'm not very happy with the way I explain it :). So, please head over to the authoritative source (in QT ref.) instead.

Ok, sounds like implicit sharing is not-intuitive (at least for Java / C# programmers). In Java / C#, by default, we expect the change we made in an object to ripple through the program (and we do some tricks when we want otherwise).

Here, with implicit sharing, it's exactly the opposite. So, why not use explicit sharing instead? Well, in a few words: I found it hard to achieve consistency with explicit sharing, partly because my domain objects have member fields of types that use implicit sharing (e.g.: QString and QList). Mixing implicit sharing and explicit sharing, in my opinion, is not a good thing. It will only lead to confusion.

Ok, let's suppose the Schema object is explicitly shared. Suppose you pass that Schema to a function (xxxFunc). Inside the function you obtain the list of Tables that belong to the schema. Then, you append another instance of Table to that list. You would expect that change to be seen from the part where you invoke the xxxFunc. Chance is: that's not the case. Because QList is implicitly shared.

So..., I thought "I don't want to mess with that. Let's stick with one approach only, implicit sharing". The (only) problem, or I'd rather say "consequence", with that decision is...: it requires a shift in my way of thinking (in the rest of the program). I will have to keep in mind (everytime I pass an object to a function): it's a pass-by-value, it's a pass-by-value.

That may not be as bad as it sounds. I think it has something to do with immutability. I remember Joshua Bloch in his book (Effective Java) mentions "favor immutability". Maybe this pass-by-value will force us to lean ourselves more toward that principle. I don't know..., we'll see. I'll report back on that later.

In the meantime you can download the C++ source code. Compare it with dbconan_schema.py below (complete python source: here). You see, there are many checks -- that are available in the python version -- currently not implemented in the C++ port. I'll get to that later. Ciao!

UPDATE: I also decided to change the target database from Oracle to Postgre. The reason: I don't have time to (re)compile QT on my Ubuntu Linux in order to have the QT's Oracle SQLDriver. On the other hand, Postgre SQLDriver comes out of the box (when we install QT SDK from the repository).

In the Python+Oracle version the program makes heavy use of Oracle Data Dictionary (that's how it learns the structure of the database).

The equivalent of it in Postgre is "information schema". Here are a few tables in the information_schema that I think will be useful for the program:

select * from information_schema.tables where table_schema = 'public' -- public is the default schema name
select * from information_schema.columns where table_name = 'table_a'
select * from information_schema.constraint_column_usage
select * from information_schema.key_column_usage
select * from information_schema.referential_constraints
select * from information_schema.constraint_table_usage
select * from information_schema.table_constraint

dbconan_schema.py

DBConan Zeta

2010-03-29T01:38:00.018-06:00

Right now I’m porting DBConan to C++, specifically using the QT framework (version 4.5.3). I’ve never programmed in C++ before, so the problem I’m posting here actually is an (embarrassing) basic problem in C++: it doesn’t compile :), with error message “file f_primaryKey has incomplete type”. The source code of the domain model is available here (yes, as a devout OO programmer I always start with the domain model) :D.

For those who are experienced in C++, please help me identify what exactly is the problem. I did all I knew: I’ve forward-declared the class PrimaryKey (see the top of DomainModel.h). No luck.

UPDATE: Found why. Here is the fixed code (separate file, those interested -- including myself, for not getting into the same issue -- can compare it with the earlier version). In a few words, it's another wrinkle I just learned in C++: when you declare "PrimaryKey primaryKey;" as an instance variable of "Table", I guess the compiler will look for the empty-args constructor of PrimaryKey, somewhere in the code, before the declaration of class Table. Of course, in this case, the forward declaration of PrimaryKey doesn't help as it only declares the type, not the constructors. So, the solution: use pointer. So, instead of "PrimaryKey primaryKey;", try "PrimaryKey* p_primaryKey;". Another possible way out (I think): partial class..., but there's no such thing in C++ :). Keywords for google: +"field has incomplete type" C++

Hope that helps (I also googled using that phrase, but I didn't really find a direct / specific answer). I figured out what I explained above by doing some quick experiments.

Ok, why C++? Well, I’ve never programmed in C++, though I always wanted too. The original DBConan – the prototype – was writen in Python because I had to run it on a UNIX machine, on which I didn’t have permission to install Java…, python was my only choice. It turned out to be a good thing for me, I could appreciate python more.

Then, as I already stated in the presentation, this DBConan will have to have a GUI. For usability, analytic functions (which would be really difficult to use without GUI), eye-candies, etc. I decided not to use Java (swing) simply because… I’ve done Java for too many years. I need some change :). I’ve heard that QT is one of the better GUI framework out there, and it’s in C++. I read the book on programming QT (3 years ago), I liked it, and finally now I have a good excuse to use it :).

One of my first concerns was: memory management. As I wrote in my earlier post, in my understanding, in (standard) C++ we have to worry about who is responsible for deleting objects created (e.g.: the calling functions? or the one got passed in the object?). I know there’s auto_ptr in standard C++, but since I’m in QT why don’t we use what QT provides (and work well with the rest of QT framework). So I skipped auto_ptr entirely and go straight to QSharedData and QSharedDataPointer. In my case I decided to use QExplicitlySharedDataPointer, since I think it’s the model that resembles most closely the model in Java / C# that I’m familiar with.

Ok, I’m thinking here, guys, especially uni students: if you are interested in building something useful, using QT, for your thesis maybe, why not consider working with me on this?

Well, I found DBConan quite useful. In my previous project in Nextel Mexico, the vendor required us to include relevant snapshot of the database whenever we report an issue / finding. Initially I did it the “normal way” (during learning phase): I did the querying manually, hoping from one table to another, and stop when I think I’ve covered the required subset. I quickly realized it was a waste of my time, so I wrote DBConan that allowed me to “slurp” the data quickly. I think this can be used in other situations that involve working with large and complex database structure.

Please email me if you’re interested. Favor de escribirme si te interesa. Silahkan menyurati saya (email) jika anda tertarik. raka.angga@gmail.com. It has to be in QT 4.5.x.

My current flow of thinking (related to charging)

2010-03-11T15:30:00.004-06:00

I'm digging old archives again, reviewing several charging scenarios I implemented in the rating & biling project in a mobile operator in Mexico throughout 2008-2009 (that uses a product named BSCS iX from LHS), trying to recall / rediscover the usage parameters that matter for telco operators (one of my current company's target market).

From there, try to understand why those parameters -- and relevant charging rules -- matter to them. That's the high-level objective.

Once we have a better / more solid idea about parameters & the charging rules, we can go backward, to identifying places in our application where we can / should tap those parameters from. The objective is to make the application "charging friendly". By that I mean, the design facilitates the need to provide the usage parameters asked by the charging system (supposedly owned by the telco operator).

After that, go forward again (to the middle). At that point we will have to verify if the data we have tapped from our application really is useful / usable. A test bed will be required. In this case, the test bed would a charging system, similar to the one(s) used by the telco operators. I will be looking into OpenRate soon.

Coming out of that we will have more confidence that we have more / sufficient knowledge to be able to deal with requests from the client (telco operator) for anything related to their charging requirements.

I'll post again once I have managed to try out OpenRate.

List of things I tend to forget how to do....

2010-03-10T15:43:00.015-06:00

Configuring DNS + SRV records for SIP.
Using tcpdump (command line).
Using sox to convert wav to gsm.

I guess I have to put a quick note for oft-used commands somewhere..., here.

Right now I'm trying to get AG-Project's CDRTool working on a Debian. It works together with OpenSIPS. I will use it as a testbed for charging alternatives we're trying to come up with for our solution offering. We're heading toward Diameter-based solution (since Diameter is the thing recommended for IMS). However, we're still in search for an opensource / free diameter server component (specifically CDF), and we haven't found one. So, we'll use this CDRTool (together with OpenSIPS and it's Radius accounting module) as a temporary solution. Let's see if it works.

Now, first I need to get this OpenSIPs taking registration for a domain (e.g.: mytelco.net). For that I need to create SRV records, somewhere in the BIND configuration. Done that before, but already forgot how. Geez :). I hope this one would work: http://www.anders.com/cms/263 ... or this... http://sipx-wiki.calivia.com/index.php/DNS_Configuration

UPDATE: Ok, done. At least now my OpenSIPS handles registrations & requests for domain "mytelco.net". I put here screenshots and quick notes. They summarize a couple of things I learned from various resources on the web during the setup (useful for future reference).

(1) Get OpenSIPS installed. For basic usage (as simple forwarding proxy) it is pretty straightforward, just follow the instructions on this page: http://bit.ly/cgFNxy. I used version OpenSIPS 1.6.1 on Debian 5, by the way. Please note, there's a little error in that manual: the author mistyped the db password for user 'opensips'. The two GRANT lines at the end, they should've been like this:

GRANT ALL PRIVILEGES ON *.* TO opensips@localhost IDENTIFIED BY 'opensipsrw';
GRANT ALL PRIVILEGES ON *.* TO opensips@127.0.0.1 IDENTIFIED BY 'opensipsrw';

(2) Install BIND9: apt-get install bind9
(3) Configure BIND9: create zone files (forward and reverse), register them (in named.conf.local), reload bind (/etc/init.d/bind9 reload). See picture:

Right after that, modify resolv.conf (so that your Debian use the local DNS you just configured), and verify. See picture:

One obvious caveat here: if you use use dynamic IP (as in my case), you will have to repeat doing those steps (in the two pictures above) everytime you restart your machine (change the IP in the bind conf, and re-edit the resolv.conf).

Link to pages I read for configuring this thing:

(3) Modify OpenSIPS config files: (1) /usr/local/etc/opensips/opensipsctlrc, and (2) /usr/local/etc/opensips/opensips.cfg. In the first file, modify the value of the property named SIP_DOMAIN to mytelco.net. In the second file, add this line:

alias=mytelco.net

That's it, and finally start your OpenSIPS: /etc/init.d/opensips start

The modification for file #2, I learned it from http://advantia.ca/references/opensips-1.5/INSTALL . Prior to doing that, I always got error 483 (too many hops) when trying to register from my SIP phone. I guess putting that alias is a quick fix (hey it works!), I yet have to see the surprises though (hope there's none!).

Finally, here's the configuration on the client side (X-Lite 3.0 on MS-Windows):

Now, on to the ugli(er) part: getting CDRTool working. I did that once as well, partially, also, forgot how to do it.... I will post the result once I get it done. Documentation was really scarce and inaccurate :|.

Alright, no I'm going to create a copy of my Debian's virtual harddisk. Chau!

UPDATE: This is so dissapointing. I thought after a year the situation of OpenSIPS & CDRTool has improved. Nope. Install guide of CDRTool is still inaccurate. Furthermore, although the latest release of CDRTool seems to be built in 2010, the install manual is still linked to FreeRadius 1.1.3!!! The latest version of Freeradius we have in Debian repository is: 2.0.x. Worse, CDRTool install guide doesn't mention that fact (you'll notice it only if you open the readme of the patch it provides for freeradius).

Gee.... Ok, I think I should forget CDRTool. All I need from OpenSIPS is just the usage data, raw CDR as generated by the OpenSIPS (which I will feed in to a better, more professionally-documented rating engine). So, goodbye CDRTool, adios, chau chau. I really doubt the authors if the authors of CDRTool spent some efforts to make sure it's usable for ordinary people like me.

Right now I'm reading the manual for enabling radius accounting in OpenSIPS: http://www.opensips.org/Resources/DocsTutRadius ... Alas! found some typos (filename, section 3.2., they should have typed radiusclient.conf instead of radiusclient-ng.conf). Also, in that same section, I'm kind of stuck trying to figure out what line to put in /etc/freeradius/clients.conf. Why, oh, why can't they reach the level of Asterisk (I'm referring to availability of QUALITY manuals / references).

Cataroo Presentation – Part 2 – Test cases

2010-03-08T01:36:00.010-06:00

Here it is, part 2 of the presentation about Cataroo. In this part I explain a couple of points related to defining test-cases for the sample application (callback). While I’m at it, I also touch a couple of relevant points about the design of the sample application. I believe, to excel, a Software Development Engineer in Test (SDET), just like his SDE counterpart, has to have a firm knowledge of software design. Without further ado, I hope you enjoy this part!

That stylistic figurine in the video-still is wayang (shadow puppet, a form of art spread throughout Asia. It flourishes especially in Java and Bali).

Just came to know a couple of days ago (from youtube) a very cool group based in the US that innovates on wayang, ShadowLight Productions. Thirty years perfecting the techniques, onward. That is dedication. I invite you to check out one of their works, Ambrosia of Immortality.

The short clips I used in my video are Punjabi songs I like a lot (for the beat & also for the dancing):

Jind Mahi – Malkit Singh.
Babe Bhangra Pounde Ne – Gurdas Mann.

Ok, back to tech topic :), just realized that this small series of presentations about Cataroo is actually what I had in mind for segment 2 of my IMS video-series.

Sharing: SIP-based call-recording application

2010-03-01T01:32:00.007-06:00

I found this when I was digging my old archives last weekend:

Call Recording Design

View more presentations from raka.angga.

It was a quick slides I made to highlights the design of a (prototype of) call-recording application we implemented in late 2008. As you can see in the slides, this application facilitates both manual and automatic recording of calls made with contact-center agents.

The recording itself is achieved by dragging the contact-center agent and the customer into a dynamically-created conference room, and have a silent-participant in the room, taping the conversation.

It is a sub-optimal solution. A better one would be to use things like mediaproxy or rtpproxy (have the RTP streams in the call go through that proxy, and tap the packets right there). The reason we designed it that way -- using conference -- is because they wanted to make use of the media server (with support for conferencing) that they have bought.

The source code is opened now; should serve as an additional resource for you who just started SIP-application development. I don't have time at this moment to write a how-to deploy and run it, less the detail of the design & code.

I invite you to do it. If you'd like to take that invitation, please write me an email at raka.angga@gmail.com or you can simply drop a comment here. Your help on this will be greatly appreciated, and it would really help fellow engineers out there.

Cataroo presentation -- part one.

2010-02-26T09:52:00.005-06:00

Just uploaded the first part of the presentation of Cataroo.

I already have the screen-recordings of the manual executions of the test-cases. I need to edit them to present of a single, coherent story. I still have to think about a couple of points to say especially in the design of the test-cases section and data analysis section. I might be able to post the narration for the second (hopefully final) part tonight.

In the meantime, I hope you find this one useful!

Update: Just uploaded another video in this series, part 2 of cataroo presentation.

Cataroo

2010-02-22T19:23:00.019-06:00

UPDATE: The video is available in another blog entry.

UPDATE: The user manual of Automated Scenario-Test Descriptor is available in another blog entry.

At this very moment I'm making a video presentation of a test-tool I just made. It is a cross-breed between that bastard thing, and a great test framework named KitCAT (Kit for Converged Application Test).

What's cataroo, you might ask. Well, here's the story. First, I named it BastardizedCAT (from Bastard + KitCAT). But then I found the name a bit ugly (it doesn't sound funny). A lookup in dictionary gave me this:

bastardized adj. (Arts): deriving from more than one source or style. impure (vs. pure) --- (combined with extraneous elements) [WordNet 1.5].

So, it's cross-breed, sort of. Coincidentally, when I was thinking of a better name, my cat was doing weird poses on my bed (please don't get me wrong). I was like: "Huh? Is that a kangaroo lying on my bed?". That's how the name cataroo came up (a cross-breed between cat and kangaroo).

Alright, here's the storyboard, with narration, of the presentation:

UPDATE: because I wouldn't be able to finish the video tonight, I decided to uploaded the scenario.xml (that contains the automation code) here. Look for it at the end of this posting. This is to give a sneak peek of what is to come....

(1) What's the purpose of this presentation.

In this presentation I'm going to show a way we can automate the testing of converged application. As in my other presentations, I will still be talking about telephony application, specifically the ones that use SIP as the signaling protocol.

(2) What's the story line of this presentation.

Before we get to the point of crafting the automation of our tests, we certainly have to start with an understanding of what we will be testing. Therefore I'm going to start with an explanation of the application I use as the vehicle in this presentation. You can take it as a quick-briefing about the requirement of the application.

Then, based on the understanding, we will move on to defining the test cases. We are not going to go in depth here with the techniques of designing system test-cases for this kind of application. So, we will just settle with a couple of basic / normal use-case scenarios.

Once we have the test-case defined, we, ourselves, will have to run it. This activity is useful, obivously, to validate the test-case. We might learn that we have missed a couple of steps, made several wrong assumptions, etc. Related to the automation, one of the aspect we will have to learn / investigate by manually executing the test-case is the data. At the end of the day, I think, an application is about consuming, processing, and producing data. So, we want to make sure all the elements involved in the scenario that we are testing are producing and getting the correct data, which implies -- to some degree -- it processes the data correctly. Analyzing how the data is being processed, however, is another topic. We are not going to spend much time on it in this presentation.

Assuming that the test-case passed, our aim from learning the data is to know for a fact what constitute the "correct data". Of course, ideally, a major part of that knowledge should be obtainable from the requirement or design document. However, there is always a possibility that a couple of details are missing from those places. Hopefully we will be able to find out about it by manually executing the test-cases and doing data inspection.

So, in this presentation I will show you how to obtain the data (specifically the SIP messages), and how to relate them to the steps in the test-case.

Finally, we compile all that knowledge and transform them into the the automation code.

That would be it.

(3) Explain the application.

The application we will be testing is basically a SIP server that is capable of making a callback to someone (let's call it partyA) whenever someone else (partyB) is available. Here is the case:

There's a person Alice, who is very excited about an important business opportunity she just identified. She wants to tell her colleague, Bob, right away, on the phone. Bob was busy doing house chores. Being a responsible and honest person, he set his presence status to BUSY. The call from Alice, obviously, wouldn't get through.

Without this application, Alice would hear the ringing tone on her phone, which after 20-30 seconds would go away. No call is made. Alice, can retry later, of course, as long as she doesn't forget to do it.

With this application, Alice would be presented with an IVR that will ask her if she wants to be called back whenever Bob is available to take calls. Let's suppose Alice says "yes" (by pressing a key on her phone to indicate the choice). For Alice, it means one less thing to carry around in her head; "call bob, call bob later today". What a relief.

Now imagine Bob has finished washing the dishes, and ready to take calls. He will announce it on the web, saying "hey guys, I can to take calls now.". Well, for now, it actually will be as simple as picking AVAILABLE from the list statuses in a webpage that comes with the application, and specifying his SIP URI. [show screenshot].

At the very moment Bob makes that change, the application will establish a call with Alice, play an announcement to her ("Alice, we're going to connect you with Bob now. Please stay in line"), establish another call with Bob, and finally bridge the two calls, resulting in Alice and Bob talking to each other.

This application is a good vehicle for this presentations, because it has the following characteristics I'd like to show that we can write the automation for, using the tool I will present at the end of this presentation:

It involves interaction with IVR, and there's a need to pass DTMF signal from a caller to the application. This is quite common in telephony applications, and we would like to know if the test tool we will be using allows us to do that, easily.

It involves interaction using SIP (on the phone) as well as HTTP (using the web-browser). Furthermore, those two are interlinked. By that I mean an action performed during the call session (on the phone), will affect the state the application, and _that_ can be observed from the other side (the web browser). Vice versa. We _will_ see that the test tool allows us to automate the interaction from both sides.

(4) Explain a simple (basic / normal) test case
...

(5) Guide the audience through executing the test case manually
...
Also explain how to gather the data we need, and relate them to the steps in the test case.
...

(6) Guide the audience through crafting the automation
...

UPDATE: Date 25 Feb. 2010. Just uploaded the first part of Cataroo (video) presentation.

scenario2.xml

Bastard (Big Automated Scenario-Test Active Runtime-Director)

2010-01-15T17:56:00.004-06:00

UPDATE: The source code of bastard lib is now available http://www.box.net/shared/q0f90dmmx4

Anything goes just to have a nasty-sounding product name, eh? :D

Ok, so this entry is highly related to the previous entry where I post a documentation that explains (mostly) the format of the XML file in which you describe your test scenario. In this entry I'm posting the Java library I wrote that consumes the XML and runs the scenario. Download it from here: http://www.box.net/shared/nf ns0u79k9 .

Well, it's not the library per se. Instead it's a little test project that uses the library. The library itself is included in that project (look for a file named bastard_api.jar in that ZIP; that's the library you would import into your project).

Alright, time for a quick explanation. Basically you will have to create a little program -- which I refer to as "Director" -- in order to use the Bastard API. It is typically very simple. Basically what it does are: (1) Loads the content of the XML file (whose name is passed in as an argument to the program execution). Then you (2) feed that XML string into a method named loadScenarioDef that belongs to the library class named ScenarioRunner. In return you will get an instance of ScenarioDefinition. Further you (3) create an instance of ScenarioRunner and spawn a thread to run it. There's an instance method named run that belongs to ScenarioRunner, into which you will have to pass the scenario definition you created in step 1 and the instance of mediator (see the doc in the previous entry to understand the meaning of it) .

Some screenshots...:

Step (1)

Step (2)

Step (3)

As you see in the screenshot of step 1, you will have to pass the path to the scenario XML file as the argument to the program execution. The project comes with several XML files that you can use to play with. Try duh.xml first (for its nice name). If you’re using Netbeans, use the following screenshot as a reference.

By running FrijolDirector with duh.xml, you should see this in the output console:

Okay. That’s all for today. Feel free to mail me in case you have trouble running / trying / using it. Saludos.

Automated Scenario-Test Descriptor

2009-10-26T22:25:00.004-06:00

Hi,

It's been a long time, can't do much right now, lottachanges, will write about that later. However, I feel the need to share this document I wrote a little while ago; it's a documentation of a test-tool I wrote for the work.

The context of this post: Cataroo

Well, through the process, I learned two things, I believe:

I kind of see the value of functional programming now.
I feel the need to learn Scala, for its promise of better support for conccurency / parallelism.
I see the value of Continuation. I had to keep the number of active threads below certain limit. There are situations where a thread have to wait, but I can't simply use sleep(), because it would't release the thread. So, in Java, without Continuation, I had to do some tricks to achieve the effect pausing / resuming thread (basically I had to make the thread stores its current state somewhere, before entering "paused mode", and immediately exits its run() method. Later, when the thread has to be resumed, another process will retrieve its current state, kick it to run, and pick up from where it left off. Tricky, could've been easier with Continuation, I guess).

So here it is (can't share the code right now, but I hope you still find value in the documentation). Feel free to ask me if you want to know more how it was designed and implemented.

UPDATE: the JAR of the library can be downloaded from http://jananuraga.blogspot.com/2010/01/anything-goes-just-to-have-nasty.html
Automated Scenario Test

Another random stuff; randomness continued....

2009-08-06T13:51:00.013-05:00

[This is a continuation of this entry]

I just finished (quick)reading a book titled "Charging for Mobile All-IP Telecommunications"..., and I think it's a good book. It helps me get a little more into the detail of diameter (protocol). Well, this book does not only explain diameter / charging in IMS network; it also has chapters on charging in GSM and GPRS network. But the part that interests me more of course are the parts on IMS. What I like about the book: it explains the message-exchange for each charging scenario, step-by-step, with some concrete example values to further illustrate the point(s). It helps a lot.

Well, that's all my review :). Ok, I'm not so good at it. Anyway, this charging stuffs is a soup of acronyms (yuck). Here are the acronyms I think I need to know / care about for this moment: CDF, OCS, Ro, Rf, and HSS.

CDF (charging data function): the element that receives charging events from various other elements in the (IMS) network, and constructs the complete CDR, before (eventually) handling it over to the billing system.

HSS (home subscriber service): the element that stores user's profile (authentication info and subscription profile). The authentication server queries this element (that goes without saying).

OCS (online-charging system): the element that calculates service-usage charges. It is primarily used in prepaid-charging scenarios. So, whenenever a service is to be consumed by a subscriber, the SIP proxy / AS sends a request to the OCS, that will trigger a price-calculation on the OCS. Assuming the subscriber still has credits left in her account, the OCS will return a success response, containing the amount of time / volume granted, and the service starts being delivered. In case the service is session-based, the SIP proxy / AS will periodically send other requests, similar to one sent at the beginning, asking for additional credit-usage, to the OCS. All those message-exchanges go through the Ro reference point.

Ro: the "reference point" between the CDF and SIP proxies (and the SIP application server) in the (IMS) network. It is used in offline charging. The way I understand "reference point": diameter defines various reference points. I visualize a reference point as a line that connects two elements in the network, and it defines its own set of messages that can be / should be exchanged between those two elements, and in what order. Well, if diameter is a protocol, then I'd say "reference point" is a protocol inside the protocol..., or sub-protocol. So, for each event / session each it manages, those SIP proxies and application server (AS) sends a message to the CDF. Using some correlation mechanism, the CDF builds the complete CDR based on the messages it receives from those proxies and AS.

Rf: the "reference point" between the OCS and the SIP proxies and SIP AS.

Ok, those are the factoids. How am I going to use them? Well, I was trying to estimate the development effort for the teleconference system, especially the parts related to charging. First, I need to know what needs to be built. Let's go over them again:

CDF: I think we need to develop it. But I guess the "correlation function" would be quite tricky to implement; making it conform to a standard / RFC needs bunch of love, I mean, verifications and validations. I was wondering if there's any open source project, that can be used as a reference / example / base / building block. So far I haven't seen any. Anyway, if we have to build it we need a way to communicate with the SIP proxies / AS (to receive diameter requests, process them, and send the responses), and libraries like jdiameter (or openblox) can be very useful (we'll be using the diameter server library, particularly the one that abstracts away the Rf reference point).

HSS: is there such thing as "standard of structure of user profile, subscription profile, etc" for HSS? I guess there is none. At the end, it's "just another database application" in my opinion. You have more freedom in the implementation of your HSS, as long as it can be accessed through Sh reference point. Hmm.... On a second thought, implementing HSS should not be our priority. There are two possible situations: (a) the buyer does not have HSS already, or (b) the buyer already has HSS (e.g.: a telco operator that owns an IMS-network).

In case (b) we'd better spend our effort more on making sure our teleconferencing system will be able to exploit the richness in the structure of the operator's user / subscription profile (which reflects the operator's charging requirements)..., and vice versa: making sure the operator can exploit the exploit the richness of "chargeabilities" (and functionalities) of our teleconferencing system. In short, we'll have to build an adaptor, a two-way adaptor I'd call it. My tactic would be: (1) brainstorm and investigate the possible ways of charging the users of our teleconferencing system, (2) obtain all the information we can have regarding potential buyer's charging requirements / capabilities, (3) prioritize the list we made in step 1, taking into account the information we obtained in step 2.

Hmm..., allright, what about case (a)? My short answer for this moment: implement our own HSS. I mean, we define our own schema for storing user and subscriptions profile (just a database application, really, in my view), and provide a thin wrapper around it such that it can be queried using diameter protocol (through Sh reference point). The design of that schema would go in lockstep with the design of the functionalities (thus chargeabilities).

Back to CDF: I think the situation is quite similar to that of HSS: (a) the buyer does not have CDF, or (b) the buyer already has CDF. Frankly, I have a couple of doubts related to CDF. First: so, this CDF is the one responsible for the construction of the complete CDR out of the events received from various nodes, by executing the correlation function. But who defines the format of the CDR? Is it tied to the billing system that is used? I guess the answer is no, because there's a mediation element (part of the billing solution) that performs the translation / mapping of the CDRs it receives (in any format) to a format suitable for that billing system. So..., who? Some standard body? I tried googling for it, including looking at the Parlay specs., but nada. Is it the operator (that owns the entire system)? So, in that scenario, the service provider will have to deliver CDRs according to the format specified by the operator. Hmm..., I guess the answer is no, for the same reason: that's why they have the mediation element. What is left then: the service provider itself, us (with close collaboration with the operator, supposedly).

For the sake of discussion let's assume the latter is true. In that case, the CDF will produce CDR in various formats (one for each service). To me that implies: there are several "correlation functions" installed in that CDF. I picture this "correlation function" as a plugable module (one for each service). Who then is responsible for the implementation of the correlation function of a service? I guess the answer is the service provider itself (again, with close collaboration with the operator), because it posses a better knowledge of the events generated by the service (and their correlations).

Eh, wait a second..., am I wrong to think that CDF overlaps with meditation in several areas / tasks? But, hey, there's another element between the CDF and the billing system; the "charging gateway function" (CDF)..., and to me (again) it overlaps with billing mediation. This starts to confuse me.

This whole questioning got me thinking: wouldn't it be easier (and better) if we get a copy of a charging platform that has CDF and HSS, evaluate it, see how it works, see how it can / should be customized or extended in order to make it work with our teleconferencing system. That strategy will help us cast our doubts more quickly. After all, we're not in the business of charging platform (eventhough an intimate knowledge of such platform will be very helpful in designing and selling our solution).

So I googled around, and here are what I found:

http://www.digitalroute.com/product/productsolutions/ims/
http://www.sitronicsts.com/en/products_and_solutions/telecoms_and_media/bss_oss_product_lines/foris_charging_and_billing.html
http://www.intecbilling.com/Intec/Products+Services/Products/Charging+and+Billing/Intec+IMS+Charging+Solution.htm
http://www.openet-telecom.com/
http://advoss.com/IMS_offlinecharging.htmlhttp://www.marben-products.com/diameter/overview.html
http://www.tieto.com/default.asp?path=1%3B93%3B16080%3B124%3B16837%3B17193%3B16242%3B36978%3B37078

I had to check the whole set of returned links by google queries: +IMS +charging and "charging data function" just to get that list :).

Allright..., next what? Hmm.... well, I guess I'll just leave it here for now. On to OCS.

OCS: Well, like I already stated, if the 3rd-party charging system we use already has it, then fine, not much to say here. But if not, no other choice we'll have to build it in-house. It is a component that resides very close to the billing system (where subscriber's account information is managed), so I think the OCS can be made as an extension to or something that is built on-top of the billing system. I don't have much time right now to do some more research on this, but if you'd like to know some more, here is an interesting, relevant wikipage: http://en.wikipedia.org/wiki/Online_charging_system.

Finally, I'd like to turn our attention to the application server, where the core of our conferencing server, supposedly, will be deployed. The application will be sending events to various charging elements. It is quite likely that it would be something that changes quite often (i.e.: we add / change feature, we change the structure of service and user profile, etc..., and somehow it would impact the chargeability of the application, hence the the events need to be sent). I was thinking: how to design and implement the application such that those changes in charging would not imply direct change in the main code (whose concern is mainly the administration of live conferences and activities within the conference room). Could it be that aspect-oriented programming is the right answer?

Lastly, for those who like to see things explained with lines of code (me too), here's a nice article from Oracle: "Understanding IMS Charging Architecture"..., and the use of diameter API in BEA (oracle) Weblogic SIP server is detailed here:

One last note: I don't mean to suggest that this conference solution will be designed specifically for deployment in IMS network (only) with this whole rambling about charging-related IMS elements. We should take it at the conceptual level. I mean, at least we should know what things we need to be considered as far as charging is concerned: there should be something that stores user and service profile (HSS), there should be something that correlates the charge-inducing / charging-related events sent by the conference server (CDF), and there should be something that calculates the charge, on-line (OCS). That's all. The names don't really matter. However, by following / learning from how those elements are organized in an IMS network, it will be easier for us to deploy our solution in an IMS network (when the need / opportunity arises). Beside that organization is pretty common I believe, and makes a good sense.

Alright, another last note :): (and this is more a reminder to myself): this whole desk-research over charging elements should not distract us from our main objective that is "to make our conferencing solution (more) appealing, also from charging and billing perspective". I think one way to achieve is by making sure (in the design) that our solution allows us / whoever buy this solution to be as creative / innovative as posssible in charging the users :).

Yet another segment of chapter 4

2009-08-03T11:15:00.003-05:00

Another little chunk, still in chapter 4, on implementing click-to-dial application using SIP Servlet. In this chunk the use of Re-INVITE message is shown and explained for the first time.

As usual, we scrutinize-and-map the SIP-flow diagram before doing any actual coding. I hope you like this one, as well ;).

[Context: video series]

Random stuffs #1

2009-07-29T11:06:00.012-05:00

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

2009-07-05T14:41:00.006-05:00

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.

A little note on C++

2009-06-27T09:18:00.008-05:00

I just did a little rehearsal, as part of bit-by-bit effort to revive the old plan of (re)implementing DBConan (this time with GUI). I plan to implement it using QT framework, and that also means the programming language will be C++.

Why QT? It looks neat and I need that because I will be very much concerned with interactivity, ease-of-use, graphical presentation of data, some (cool) animations maybe, and all that stuffs. QT seems to be a great choice.

And why C++? I want to take advantage of Oracle OCCI, because this tool (in its first version) will be made specific for Oracle database. I haven't got a chance to check if there is something similar to Oracle Data Dictionary -- which is vital for DBConan -- in other RDBMS..., let alone study them.

Before anything else, here's the code, and below is the screenshot from running the code. I don’t have time and space right now to explain it. In fact, I don't think any explanation is needed. It's just some test-code I used to confirm / disprove my worries and cast my doubts.

Designing and writing program in C++ is one thing I don't feel very confident about myself. Well, the last time I programmed in C++ was in 2006, using wxWidget and Skype API for the early prototype of peerant's client application, which was not a lot of code, and lasted only for 6 months. So it's not enough.

I've always been a defensive programmer; I always try (up-front) to avoid making silly mistakes that can be hard to spot when the codebase gets big. To me, the keyword is "consistency". I remember my lecturer in the university taught me to be consistent in my choice of words, structure, and style in writing papers / technical documentations. I think the same exact principle holds true for software codes. First I need to know the field, understand the rules of the games, know the potential issues, make up some rules for avoiding the potential issues, and follow / apply them in a consistent manner.

Straight to the core of the matter: I worry about object-lifetime management in C++. I want to minimize the likeliness of (me) making mistakes on that area. I need to clearly describe my worries, organize / structurize them, and hopefully come up some simple rules for avoiding the pitfalls..., or at least a kind of lookup-table for scanning such mistakes during code reviews.

In Java / C# I don't remember I ever worried (too much) about this. It doesn't mean memory-related problems can not exist in applications written in those languages. Memory leaks can still occur, especially whenever in some parts of our code we cache objects (in containers like map or list) and forget to remove the cached object whenever we no longer use it, keeping the reference count from reaching 0..., and GC is of no help in that situation.

But, in my understanding, it's relatively easier to detect (and avoid) that kind of problems with those languages. Beside, those languages have been designed in such way that there are less paths to getting into trouble with object-lifecycle management.

"Less ways to get ourselves in trouble"? How come? One of the reasons, I think: in those languages we only deal with one thing, (object) reference. When we pass an object as function argument or return value, we always pass the reference to the object..., and that's the default behavior. Whenever we want to pass a copy of the object instead, we have to make that copy explicitly.

It's quite different in C++; where we have both choices. We can declare the function this way:

(a) void aFunction(Buck buck) //pass-by-value. The arg will be a new instance, whose internal values will be initialized through the copy-constructor.

or this way:

(b) void laFuncion(Buck& buck) //no copying here, it's pass-by-reference.

How does it lead to problems? Hmm..., well, it lies in the assumption that the client programmer might use. Let's suppose we go the (a) way.

If the client programmer does not read the method signature carefully enough, she might think / assume that the buck being used inside the laFuncion is exactly the same buck that she has within her code (outside the laFuncion). This assumption (mis)leads her to think the modification she made to the buck (outside the laFuncion) will be seen from inside the laFuncion. Bla bla bla, error.

Of course it is her mistake for being such a sloppy programmer. But let's not be so quick to judge (and punish). Maybe she's a decent programmer actually. It's just that she's coming from Javaland, or C#land (which is exactly my case). Well, with the intention to help her (or myself), then I thought: "Why don't we simply go the (b) way? That's the Java way she's familiar with. That would eliminate the issue, right?". Could be. But before we get to that, I'd like to review why would we consider the (a) way at the first place?

Apart from presenting the issue above, it is copious, unnecesarrily copious. That buck in the function argument is an instance whose lifetime is limited to the scope of the function; it will be automatically destroyed whenever the function returns. What's the point of creating a new instance which will be destroyed in such a short time anyway? I'm thinking of flies (I just learned that a fly lives only for a day from watching the obamaninja video). Why did She create flies? They're so useless.

To make the point clearer, let's get down to the code.
---------------
class ObjectA
{
private:
Buck buck;
public:
ObjectA(Buck buck) {
this->buck = buck;
}
};

class ObjectB
{
private:
Buck buck;
public:
ObjectB(Buck& buck) {
this->buck = buck;
}
};
---------------

When we create an instance of ObjectA, passing along an instance of Buck, the following things will take place:

(1) An instance of Buck, that corresponds to the argument "buck", will be created. The copy-constructor will be used for the creation.
(2) An instance of Buck, that corresponds to the instance variable "buck" of ObjectA, will be created. The default (no-arg) constructor will be used.
(3) When the assigment occurs, the assignment operator of of the instance variable "buck" will be called. That's how the internal values of the argument "buck" get copied to the instance variable "buck".
(4) When the function returns, the buck that corresponds to the argument "buck" will be destroyed.

On the other hand, when we create an instance of ObjectB, passing along an instance of Buck, the following things will take place:

(1) An instance of Buck, that corresponds to the instance variable "buck" of ObjectB, will be created. The default (no-arg) constructor will be used.
(2) When the assigment occurs, the assignment operator of of the instance variable "buck" will be called. That's how the internal values of the argument "buck" get copied to the instance variable "buck".

See, an (extra) invocation of copy-constructor is involved in the pass-by-value case; and the final effect is the same for both cases: either ObjectA or ObjectB will have its own instance of Buck, whose internal values are the same as that of the instance of Buck passed in by the client programmer. In Java speak: value equality, but not reference equality. So I declare (b) way as the winner; same effect, less steps.

But wait, I was supposed to come up with an answer for "why would we consider the (a) way at the first place?". Hmm, I just mentioned the key idea of the answer: owning. My initial goal was to ensure the object that gets the value (buck) passed-in, will _own_ the buck. In other word that object will be the one responsible for the lifecycle of the buck. Keyword: composition (instead of aggregation).

Well, we just saw the (b) way accomplishes that goal, as well. So I think we can completely discard the (a) way now.

Going a little further: if that object is supposed to be responsible for the lifecycle of the buck, then (ideally) it should be responsible for it from the beginning (right?); that is to say: wouldn't it be better if that object instantiates the buck (instead of being fed with it)? "Factory method" comes to mind. I think I will consider this as one of the rules for my code.

---
class ObjectB
{
private:
Buck* pBuck;
public:
ObjectB() { }
Buck& getBuck() {
if (pBuck == 0) {
pBuck = new Buck();
}
return *pBuck;
}
};
---

On the flip side: in the cases where we want to state that the object will not / is not supposed to be responsible for the lifecycle of the the buck, then we can use this form:

----
class ObjectC
{
private:
Buck& buck;
public:
ObjectC(Buck& buck) : buck(buck) {
}
};
----

The steps involved:
(0) None of the four things above (mentioned in the (a) way).

Now the problem: this code assumes the buck gets passed into it the instance of ObjectC wouldn't get destroyed before the ObjectC itself is destroyed. I'd say, in a more concrete terms, the buck must be allocated with the new operator, like this:

---
ObjectC* otroFuncion() {
...
Buck* pBuck = new Buck();
ObjectC* pobjC = new ObjectC(*pBuck);
return pObjC;
}
---

Instead of...
---
ObjectC* otroFuncion() {
...
Buck buck();
ObjectC* pobjC = new ObjectC(buck);
return pObjC;
}
---

Hmm..., I think that's not a safe assumption. How to enforce it? But wait..., if the object (ObjectC) is "conscious" that it is _not_ responsible for the lifecycle of the the buck (thus has no control over it), then it is its responsibility to do the checking to see if the buck is still alive, before it does something with it. Hmm..., I guess that's a fair rule.

Argh.... :D. I think that's all. I write down this train-of-thoughts here just in order not to repeat doing this next time. If you think there's something inaccurate / misleading / just plain non-sense here, please let me know. Thank you in advance.

The third (last) example – click-to-dial.

2009-06-22T08:09:00.002-05:00

This is the part of section 4 (on SIP servlet programming), where the audience is guided through implementing a click-to-dial application.

Hopefully by this the audience get a her first taste of "third-party call control", and begin to see the potential of the "convergence" between the telephony and web, that is becoming even more practical with protocol like SIP and programming framework like SIP-servlet.

As usual, can’t write a lot right now; will update this entry later. I hope you like this one, chau!

The usual notice: The source code for chapter 4 is available in this URL: http://www.box.net/shared/tk4ghghllg. It’s a netbeans’ project folder. Use Netbeans 6.x and follow the instruction in this video in order to be able to compile those codes successfuly.

[Context: video series]

(An attempt) to answer Eric….

2009-06-15T01:54:00.005-05:00

Allright, a couple of weeks ago I had a chat with a friend, Antonio, here in Mexico City, who works for a company that provides IMS platform to telco operators, in my attempt to get another perspective on IMS.

Remember, on the earlier chat with another friend, Eric, who comes from a different background, all we got was skepticism. Basically the questions he posed were:

Why trying to be an "app-store", another "me too"?
Why transmiting the voice -- between the mobile 3G handset and the operator -- in IP, when the infrastructure for voice transmission (non IP) is already there, working just fine? Plus we know what it takes to transmit voice over IP... serializing, packetizing, unpacketizing, deserializing, etc. It sounds like a lot of things to do, compared to simply transmiting the voice signal as, you know, waveform (that's how they basically do it, right?).

Yadda-yadda from me: this skepticism here is not nay-saying; quite the contrary. I am enthusiastic about this whole IMS thing, and I do plan to put (some of) my eggs in it. But I need to validate some of my assumptions; "this will definitely work and become a boom very soon :-)" being one of them. I would say I'm trying to do some reality checks.

For the second question above, the way I see it: if it's doable why not? I mean, the cost of operating a single infrastructure (IP for all) should be cheaper, right? I need some hard facts, some figures might help. If you have happen to have a link to that information, please share it with us.

Assuming that is true, then the next question would or should be: why haven't they done it? Why are voice calls still transmitted over non-IP channel? Allright, I don't know the answers, so I asked my friend Antonio. Here are the answers, verbatim copy, which to my (momentarily) lazy mind boil down to "it's all about money":

Mobile networks are good businesses even if they don't use IP. Operational margin in most MNOs (such as Telcel, for example) is so good, that the supposed savings coming from the IP change don't look so compelling. At least, not yet. SDH is still being supported and it does not imply large OPEX (yet).
Elaborating on the previous reason. Even though IP-based transport is said to be cheap, so it is the TDM-based one. SDH and WDM technologies have improved and became cheaper a great deal during the last 3-5 years. Many network operators have made large investments in TDM-based transport less than 3-4 years ago. In their view, that investment has not paid off enough as yet. The ROI (Return on Investment) has not been satisfactory enough in many cases. Many MNOs are waiting for their SDH/WDM networks to depreciate even more.
Paraphrasing some famous TV program: "what is the other option, anyway?"... what I mean by this is: if the MNO is supposed to throw away its SDH network, what is he supposed to buy instead? the common word in the last years is called Metro Ethernet. The truth is: even if Metro Ethernet can look as cheap as SDH in terms of $$$ per Mbps, it doesn't look as mature in other aspects, especially regarding O&M capabilities. The ones who are operating SDH networks are today very familiar with its ways of operation and maintenance, and know very well how to troubleshoot these circuit-based networks. It just does not look as clear in the case of Metro Ethernet.
Lack of know-how on IP-based technologies. Even if the change seems inevitable (it really is), there is a lot of reluctancy within the engineering and operation organizations of the MNOs to move towards the all-IP paradigm. They just don't know enough of IP to take such an important decisions.

I'll process those information later. I keep it here for my future references. Now, where am I heading, or where am I in my train of thoughts? Allright, I guess the question #2 by Eric has been addressed (more or less).

However, I really don't understand why should I be concerned (too much) about this? I mean this whole rant I'm putting here is actually just a prelude to the point I want to bring up: the switch to IP is inevitable, they're going to do it, just wait (1-2 years, depends on which country you live in), and IMS is there just waiting for adoption, as it provides the architectural framework for their needs (by the time they've switched to full IP). For me -- as software developer trying to profit from that -- that means: my investment in learning SIP Servlet, IMS, and stuffs wouldn't become a waste. That's all I wanted to say. Well, that's what I want to believe.

The kind of application I'm thinking of that I can develop is some mobile applications (together with some server side components implemented as SIP Servlet) that enables funky (yet useful) interaction scenarios (voice, image, video, etc), connected to things like social network, document management, customer management, etc., taking advantage of the nature of the protocols that enables that kind of service convergence. For that kind of applications I don't think I really need to care whether the voice is transmitted over IP or TDM. Or am I wrong? Can you tell me what kind of scenarios wouldn't be possible if the voice / video is not transmitted over IP?

Anyway, let's move on to the question #1 from Eric: why trying to be an "app-store", another "me too"?

I don't know :) So please chip in here. Anyway, in the process of trying to find the answer / get some insights, I came across this thing called SDP (service delivery platform). I was looking at a product from a company JNetX.com. Hmm, well it seems to be one of the building-block for an "app-store" of telco. I need to find out how they go, the clients they have, the reasons those clients use their product, maybe that way I'll arrive at the answer for question #1.

Wrapping up..., I need to:

Find an information that says : the cost of using IP for all their service is be cheaper.
Try to process the points mentioned by Antonio.
Keep this question alive: what scenarios would be made possible (only) if the voice & video is transmitted in IP?
Dig service delivery platform (SDP).

UPDATE: I will put my notes and the notes of some collaborators, over our findings / study of VoIP, SIP, IMS, mobile, etc in a wiki workspace here: http://jananuraga.pbworks.com. I also added a link to that wiki workspace in the menu bar. Look for this image:

YAC (yet another chunk) of section 4

2009-06-15T01:05:00.002-05:00

In this 8-minutes video we learn how to deal with the provisional responses (such as the ringing signal), success responses (such as OK), and the bye requests. This is the continuation of this video, where the application we’re developing is explained, and the way we handle the initial invite-request from the caller is explained.

The upcoming video will be about implementation of click-to-dial application, and it would conclude chapter 4.

I also decided to create a mini chapter that follows chapter 4 – I’ll name it… chapter 4 extra – where I make the test calls to and trace analysis for each SIP servlets explained in chapter 4.

There’s one more thing: the source code for chapter 4 is available in this URL: http://www.box.net/shared/tk4ghghllg. It’s a netbeans’ project folder. Use Netbeans 6.x and follow the instruction in this video in order to be able to compile those codes successfuly.

I hope you enjoy the videos! Zaijian!

[Context: video series]

Another chunk of section 4

2009-06-08T07:38:00.003-05:00

This is the part of section 4 (on SIP servlet programming), where the audience is guided through coding her second SIP Servlet, which acts as a back-to-back user agent. This second SIP servlet simply connects the caller to one specific destination (a person named alice).

In this 8-minutes video I can only explain the way we handle the initial invite-request coming from the caller; which we do inside the doInvite method of the SIP servlet. The upcoming video will cover the way we handle the other methods (doProvisionalResponse, doSuccessResponse, and doBye).

That's all. I hope you enjoy this video. Chau!

[Context: video series]

Section 4 part B.1 – programming the first SIP servlet.

2009-06-03T08:19:00.003-05:00

Here it comes, the first SIP-servlet, a very simple one that simply accepts INVITEs (thus starting a dialog with the caller). The audience will also learn how to deploy a SIP-servlet application into BEA Weblogic SIP Server.

Sorry, this is such a quickie entry, I’m so not imaginative at this moment. I will update it later tonight (or tommorow :D). Enjoy, chau!

[Context: video series]

Chapter 4, first part (intro. of SIP-servlet programming).

2009-05-31T12:31:00.001-05:00

Finally, here it is: the first part of chapter 4 (crashcourse on SIP-servlet programming). This 7-minutes video is basically a warming up before we perform the programming activities in the next part. Here we also set up our development environment (Netbeans 6.5); registering the BEA weblogic server in the IDE, setting Java platform to 1.5, and importing sipservlet JAR.

I’m at this moment editing the second section of this chapter…, so, well, see you soon. I actually wanted to upload the complete narration of the chapter 4, but the upload is very slow at this moment. Please check back later tonight.

Context: http://jananuraga.blogspot.com/2009/02/preview-of-section-2-ims-app-dev.html

Request for help: CSS stuff

2009-05-25T13:01:00.005-05:00

Dear reader,

I'd really appreciate it if you can help me with the following thing.

I need to improve the visual balance this blog with the hope of seeing an improvement of the level of interactivity. I was thinking of moving some widgets to the right. Those widgets also should be hidden initially, and there will floating tabs, one for each widget. I hope the following figure illustrates my point.

By clicking the tab, the widget will displayed, also floating on the page. Additionaly, scrolling the page wouldn't change the location where the widget (and the tabs) are displayed on the screen. Another requirement is: only one of those tabs can have its widget displayed at a time.

I've been trying to look for the answers in some CSS / web-design / blogger tricks sites, no result so far. I mean, I was not sure what the correct search expression would be.

If you have some clues please drop me a comment. Thanks in advance.

My skepticism over IMS

2009-05-20T02:17:00.004-05:00

I guess this is the first entry in my blog where I actually try to recall things and organize them into a more or less coherent rambling... :D. I need to write it down so I wouldn't forget these interesting (and possibly valid) points...; mostly skepticisms. A healthy dose of it :). And when I say skepticism what I really mean is: I need some education. So, please, feel free to chip in.

Allright, so I just had a talk in zona rosa*) with one of the guys who are going to help me with the production of chapter 1 (it's going to be a dialogue, a bit of change in the plan: from interview to a dialogue; more persons will be involved).

Where do I start? Ok: bit pipe. I picked that term from a paper that explains a couple of (suggested?) business models around IMS (IP Multimedia Subsystem). Backtrack: you know the title of this video series I'm making is "IMS Application Development using SIP Servlet and VoiceXML". Lately I think the title is a bit inaccurate though.

The production of video series was actually started from the idea to share some experience and knowledge I've acquired in developing application using SIP Servlet and VoiceXML. It just happen to be the most recent project where I used those stuffs has something to do with IMS, in the sense that the application was deployed in the IMS network of a telco operator (in mexico).

SIP Servlet, SIP, and VoiceXML, they're all internet technologies, it's not exclusively IMS (i.e.: we can use those stuffs for developing telecomunication services outside the context of / that have little to do with IMS). Anyway, I'm just trying to put some context around SIP Servlet and VoiceXML programming, and I picked IMS. Beside, I think it's useful to know / keep an eye of what those telco operators are up to, what are they going to do this IP thing (3G, etc).

That's it: what are they going to do? Actually -- according to that paper -- this is one of the business motivations for telco operators to adopt IMS: to avoid the gloomy fate of degenerating into a mere bit-pipe. Basically, what they would like to be: a kind of marketplace for the services -- IP based services -- and profit from it (that's how I understand it).

That sounds reasonable to me. The paper went on by stating this IMS will provide a framework for achieving that objective. I vaguely recall it's mentioned somewhere that the centralistic nature of the framework fits in very well with the tendencies / preferences / (or habit?) of those operators: maintaining as much control as possible.

With the subscriber base in their hands, the service providers that are hooked to them, and the premise that the subscribers are more likely to their trust their sensitive data in the hand of telco operators: throw the single sign-on thing in, and voila, the telco operator turn into a hub. Money. Money?

Somehow it reminds me of portal. I was wondering if the paper is suggesting something similar to it, but for telco. I'm quite skeptical. To begin with, portal to me is useless. I don't want to be confined in one single page with all the stuffs fitted into those small boxes throughout my browsing session. Instead, I have lots of tabs in my browser, and my homepage is set to Google. What else do I really need? I find that a more effective way of navigating this mish-mash of information. I believe unproportionately large population of netizens think that way too. So, portal is a NO to me in my browser..., and so is it in my handset (phone).

Another example closer to telco is this walled-garden approach, where the telco operators basically tries to hide the internet from the user. Yes, they tried that and they failed. Simple: lack of content only generates lack of interest. If we try again today in the age of 3G and iPhone, we will fail again, in a much harsher way. Lesson learned: don't fight the internet. Just don't.

Seriously I don't think that is they path they are going to (re)take. I mean: I don't want to believe it is the case. So I must be missing something here. Anyone?

This boils down to a (temporary) conclusion: this push to avoid "becoming a bit pipe scenario" is misguided. I mean, why should they try to become something that they are not? Their business has always been providing access, so why not focus on it. It's fine becoming a "mere" bit pipe. Just win the market by building bigger, better pipes. Right?

I have more to say but it's very late now. I'm sorry I can't provide the link to the paper I mentioned, I'm too tired to look for it. Again, please chip in, I'd love to hear your opinion or the facts you might have.

Oh, one last thing: the chapter 4, the introduction to SIP Servlet programming. Yes, I already have the video recordings and also the voice recordings. Now comes the tedious task of cuting-and-pasting those video and voice recording segments. I really do want to finish doing it this Saturday.

--
*) Why all the cantinas are closed tonight, that we had to walk to zona rosa just to find a place to drink and talk?

Chapter 3 is completed! – Installing and configuring Asterisk.

2009-05-03T14:59:00.005-05:00

The final step in chapter 3 (on setting up the lab): installing and configuring asterisk, which we will utilize as the media gateway in our lab.

I split it into two separate videos (because of youtube’s 10-minutes constraint). This video below is for the installation:

I simply followed the step-by-step installation procedure available on the Practical Asterisk 1.4 website.

Finally, this video below covers the configuration and quick-test (to see if we’ve installed and configured the asterisk correctly).

Even if you’re not into the IMS, SIP Servlet programming, or VoiceXML, you can still use this video as a quick intro to the asterisk (just enough to get you up and running in no time). I’d recommend the book Asterisk: the future of telephony for you who want to dig deeper into it.

I'd also recommend a booklet I wrote in 2006 on telephony application development using Asterisk and Java. It might be a good companion to these videos, especially for you who'd like to program something with Asterisk.

I hope you enjoy the videos and find them useful. Coming up: section 4, on introduction to SIP Servlet programming. Stay tuned!

Update: chapter 4 has just taken off. This way: http://jananuraga.blogspot.com/2009/05/chapter-4-first-part-intro-of-sip.html.

[Context: video series]

Section 3 A – Setting up the lab.

2009-04-20T01:01:00.001-05:00

Allright, another bit just came out of the oven :). This one contains the quick guide of the installation of BEA Weblogic SIP Server and Voxpilot Media Server.

Enjoy! Coming up next: quick guide of the installation of Asterisk (and right after that we’ll start coding, the SIP Servlet, in section 4).

Section 2 is finished – finally.

2009-03-27T13:27:00.004-06:00

These two videos below close the chapter 2 of the “IMS application development tutorial” video series.

In the first we make a comparison between the call we made through SIP proxy and the call through back-to-back user agent. At the end of it I explain the reason why – in my opinion – we are more likely to develop back-to-back user agents (using SIP servlet technology).

The second video contains the demo of the EZ-IVR application (that's the complex application we are going to develop at the end of this video tutorial -- chapter 6, 7, and 8 -- utilizing all the knowledge we acquire throughout the preceeding chapters). In addition to the demo, the video also gives a quick overview of the interaction between the elements that make up the application.

Well, that's all for section 2. I learned something from this process: I did it the wrong way (I mean, the technique of making the video), that's why the process was slower than I expected. In the upcoming chapters I'm going to record all my activities on the screen first (without saying anything), and do the voice-overs after that.

What about chapter 1? A good news: a friend of mine is going to help me with that. He's more knowledgable and experienced in this area. I'm glad and honoured to have him in this video. Chapter 1 is going to be an interview with him. We're still working on the script, expect to see the video in 7-10 days from now.

IMS Application Development - Section 2 part C - 2

2009-03-14T09:29:00.001-06:00

Here comes other chunk…. In this part, we make a call through a SIP proxy, and followed by another call through back-to-back user agent.

Sorry for the short commentary; I’m still working on the editing of this video series. *Phew*. Hang on, we’re almost there. One more part, where we’ll make a comparison between the two calls in the video above followed by short demo of EZ IVR, and we’ll be done with section 2.

Be right back. Chau.

IMS Application Development - Section 2 part C - 1

2009-02-24T08:32:00.001-06:00

Wow..., editing video is not as quick & easy as I thought before. This is what I managed to come up with last weekend.

Actually I planned to stuff all the remaining of section 2 in the same video..., but due to time constraint, I decided to cut it at the end of the explanation of the SIP signals exchanged during the demo direct-call we saw in section 2 part B.

That means, two parts are still missing from section 2:

Demo of call through back-to-back user agent (along with some explanations).
Demo of call through sip proxy (+ explanations).
Quick demo of EZ IVR (I hope it will serve as a teaser / another dose of dope..., for motivation).

They all will be available in the upcoming section 2 part C-2 (which I'm going to start editing this Saturday).

I hope you enjoy this part, and..., until next week!

IMS Application Development - Section 2 _PREVIEW_ (B)

2009-02-16T08:46:00.002-06:00

This is the second chunk of section 2. I decided to deliver series of small chunks (3-4 minutes). Psychologically it's a better way to go, I believe :). In this chunk a little demo of basic SIP call is presented.

Coming up next (in the other chunk -- taping is already done, missing the editing):

SIP Headers and SDP
Call through SIP Proxy
Call through Back-to-back User Agent
Demo of EZ IVR (motivation)

..., and that would conclude section 2.

Side note: the videos in this series are put together in a play list titled IMS Application Development using SIP Servlet and VoiceXML on my channel on youtube.

Preview of section 2 – IMS App. Dev. Tutorial

2009-02-11T16:26:00.016-06:00

This is a 5-minutes preview of section 2 of the video series "IMS application development using SIP Servlet and VoiceXML. The video series will have 8 sections, with the following organization:

Segment I
1. Overview of IMS and the series: this entry is our first stab at it.
2. Brief introduction to SIP: this entry, this one, this one, and this one :).
3. Installation of servers (SIP Servlet container, VoiceXML server, Asterisk as media gateway, and sip softphones): here and here.
4. Programming SIP Servlet quick course: (so far) this, this, this, this, this, and this :).
5. Programming VoiceXML quick course.
Segment II
1. Designing of the EZ IVR
2. Implementing EZ IVR
3. Testing EZ IZR

Playlist available on YouTube.

The source code of the SIP-servlet crashcourse: http://www.box.net/shared/tk4ghghllg

They're all brewing. Up to this date I already have the narrations done for section 1-5. All the parts for section 2 have been fully recorded, but most of them have not gone through editing room. What I’m showing here is what I managed to come up with last night. When completed, this section 2 will have a demo (and explanation) of SIP calls (various scenarios) and call-tracing (with wireshark).

UPDATE: Date 25 Feb. 2010. Just uploaded the first part of Cataroo (video) presentation. The video is still related to this series (also talks about SIP application development). This time it's about a technique to test such applications, specifically on automating the testings.

Update: I just realized that the series of Cataroo presentation is actually what I had in mind for segment II of this IMS App. Dev. Tutorial. Oh, well.

Xpectador 1.0

2008-12-10T05:19:00.002-06:00

Xpectador is a command-line tool for verifying the content of XML-documents, any XML-documents. It's very easy to use, and requires almost zero learning.

Suppose we expect our XML document to have the following "profile":

<root>
<element_a attr_1="X">value_a</element_a>
<element_b>
<element_c>value_c</element_c>
</element_b>
</root>

What we would do is: save that expectation as an XML file, and executes Xpectador the following way:

xpectador my_expectation.xml document_tobe_verified.xml

That is all. In case xpectador finds that your document doesn't meet the expectation, it will exit with code -1, and print out some messages, such as: "Expected element could not be found: <element_b>...</element_b>". That will help you identify the issue in your document more quickly.

Note that I used the word "profile" instead of "content" because Xpectador performs more than simple text-comparisons.

It allows you to express the following expectations:

Positive expectation: I want to see this particular element that contains these attributes, etc.
Negative expectation: I don't want to see this particular element.
Don't care: I don't care whether the document contains this element or not.

The neat thing about Xpectador: you don't need to learn any new syntax (format). You state your expectations -- as XML document -- using the same format as the document that you want to verify.

You've seen the an example of "positive expectation" above. To state a "negative expectation", in the expectation file you only need to insert a special attribute in the element that you don't want to see. Example:

<root>
<element_b>
<element_c Expected="N">value_c</element_c>
</element_b>
</root>

That's a way of saying "I don't want to see element_c whose value is value_c, inside element_b". In case that expectation is not met, you will get the following message from the xpectador: "Non-expected element was found: <element_c>...</element_c>".

"Don't care"? Well, it's the easiest: just omit the element from your expectation document.

You can specify a different name for that special attribute. You do that by specifying the third in the execution of xpectador. Example:

xpectador my_expectation.xml document_tobe_verified.xml esperado

We'll, I guess that's all for the intro. There actually isn't much to talk about how-to-use this application due to its simplicity. However I know you will ask "can I trust the outcome?". That was also my concern, and I do have the list of test-cases for this application. I'll try to find a time sometime next week to be able to write a couple of things about it.

In the meantime, feel free to use it. Grab it from here (box.net). Just unzip the file, you'll find one EXE file in there (xpectador.exe). You will reap the real benefit of this kind of tool if you integrate it to your chain of automated-tests.

The source: http://www.box.net/shared/u55s51p9hf

Feel free to drop me an email if you have any question regarding this tool or in case you find anything that looks like a bug. My email: raka.angga@gmail.com.

Credits: this tool is written in Python, with a 3rd-party library for XML-processing (lxml), and compiled to EXE using py2exe..., on Vista :D

DB Conan 1.0

2008-12-02T10:55:00.003-06:00

DB Conan is a data-retrieval tool. It's named after a manga character, Conan, kind of little Sherlock :).

This tool allows you to define a subset of the database that you're interested in (so you wouldn't be bogged down by unnecessary details / information overload during your testing / investigation activities). Once you have your subset-of-schema -- and some filters that you can also define -- set, you can load the data again and again, without typing any SQL query. This can potentially save your time.

The following slides provide a more detailed description of this application (download the PowerPoint file from Box.net):

DB Conan 1.0

View more presentations from raka.angga.

The application itself is available on the following URL: http://www.box.net/shared/5ag8ja4eli

The source: http://www.box.net/shared/k00tkdmhza

Its current status is prototype. Anyway, it's usable; I'm already using it in my daily work. I hope you'll find it useful as well.

I do plan to further develop it (with GUI, etc), but only after I've finished my other project that has been pending for so long (a series of video on how to develop IMS application using SIP-Servlet and VoiceXML). Once I've finished it -- hopefully within this one month period -- I'll get back to this DB Conan. In the meantime, feel free to drop me some feedbacks / questions.

Quick showcase - demo EZ-IVR application

2008-08-13T03:08:00.001-05:00

Hover your mouse over the video to see the thumbnails / shortcuts to the other videos in this series.

Troubleshooting: if you see "the video is no longer available" message, try to refresh this web page. Hope that solves the problem for you. Otherwise, you can go directly to the YouTube page here.

The images displayed in Part 1 in this video presentation can be downloaded from: http://www.box.net/shared/vkyu7w1s00

A friendlier-for-the-eyes version of this blog entry is available at the following URL: http://www.geocities.com/rakabali78/ezivr.html

This is a series in progress, more videos are coming up starting next month.

The following is the brief overview of each video in the series (so far):

Part 1 : Domain overview. In this part the (business) use of this application is explained. The domain model of this application is also explained here.

Part 2.a : Demo execution - intro. In this part the cases that will be demo-ed in the subsequent videos are explained.

Part 2.b : Demo execution - call transfers. For case 1 & 2, the call transfer is answered by the callee. For case 3 & 4, the call transfer is rejected by the callee.

Part.2.c : Demo execution - call transfer and queue. For case 1 & 2, the call transfer failed because the callee is busy, so the caller is asked whether she wants to wait in the queue. There's a timer for each element in the queue, that timeouts after a couple of seconds (45 in this demo), and checks the current position in the queue; if it's the 1 (the first) the call-transfer will be retried.

Part.2.d : Demo execution - call transfer and queue (two callers). It's the same as case 5, but with two callers. Here we verify that the positions are calculated correctly, and that the queue actually moves (so when the element that was first in the queue terminates the call, the element that directly followed it will move forward in the queue).

Part.2.e : Demo execution - play a message in the IVR. In the IVR tree you can configure some "messages node". The subscriber can use it to allow callers access announcements / advertisements through the IVR.

Part 3 : Brief development info. Here I explain briefly the modules that make up this application. I also explain the pattern that I employed when I implemented this application. Lastly, I glazed over some testing concerns & challenges.

Raka's Core Competencies

2008-08-13T03:00:00.024-05:00

Below is a document I wrote explaining my core competencies, and the traits I have, and why I can be a good fit for the job you might have. Your browser must have Adobe Reader. You can also download the PDF document by clicking on this link that will take you to Scribd's site: http://tinyurl.com/rakacompetencies .

My curriculum vitae can be obtained from http://tinyurl.com/resumeraka (the link will take you to Box.net, an online-storage service).

Feel free to drop me some comments or questions regarding my experiences and core competencies on this email: raka.angga@gmail.com .

Cokorda Raka's Core Competencies

Booklet: Telephony application development with Asterisk, Java, and SIP

2008-08-13T02:58:00.001-05:00

The booklet takes you through the process of developing a simple telephony application made using the stuffs mentioned above. Along the way (I hope) you'll develop a firm basic understanding of those stuffs, and be ready for your further adventure in telecommunication application development.

Download the booklet (PDF, 5 Mb).
Download the source code of the application explained in the booklet (TarGz, 1.5 Mb).

Booklet: telephony application development using Asterisk, Java, and SIP Booklet: telephony application development using Asterisk, Java, and SIP raka.angga

Publish at Scribd or explore others: How-to-Guides & Manu java voip