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.
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 ...
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/nfns0u79k9 .
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.
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.
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).
Feel free to ask me if you want to know more how it was designed and implemented.
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).
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 :).
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 ;).
