First stab at chapter 1

Where do I start? Allright, this picture.

Now the context: last monday we met in my place in mexico city. By we I mean: me, Eric, and Antonio. For the recording of chapter one of the video series. There was an interesting talk (platica), mostly between Eric and Antonio.

Ok, this should've been in the video, but we simply didn't / forgot to do it :) No introductions recorded. Therefore allow me to put a brief one here.

Antonio Echeverria works as a solution architect in one of those vendors that are pushing IMS. We knew each other when I was working in a project for an (fixed) operator in mexico. His role / job in the company allows him to get some insights of the current situation of the IMS, business and technical-wise, especially for the mexican market. He's been a telco domain for quite a long time, and I'm fortunate to be able to learn things from him.

Eric Werkhoven was my colleague in the company we used to work for during 2005-2006. The company was developing a hosted call-center solution. Currently he works for another VoIP company producing & providing outbound / predictive dialing solution. A deep understanding and appreciation of the technical challenges in developing and deploying of large-scale VoIP solution is something that I learn from him now and then.

Antonio and Eric are from two different worlds that are colliding (or converging?). I was happy to be able to get them together and talk, exchanging their views, which might not be completely aligned to each other.

The talk we had last Sunday was mostly about the business-models / opportunities around IMS. We think that's the most important point to grasp before delving into technical discussion. I personally am interested to know the value-chain; to see where I -- viewing myself as a (potential :D) service provider -- might be able to fit in, and how to profit from it. That's what I would like to share with others in the video(s). Of course we don't pretend to become an authoritative source for that kind of information. We just wanted to capture our learning process. Here's the unedited conversation I managed to record (only 38 minutes).

Unfortunately, we only had an hour to get together on that day. Because of my stupidity I also forgot to record the first 15 minutes of the conversation (when we were discussing the flow of the dialog); some interesting points were brought up there.

So here I am now, grappling to collect those points and make up for the lacks. I'm trying to back up some of those points with some references I can find on the internet / other sources. Hopefully this can improve the value / usefulness of the information I'm going to provide in the video.

Ok, so that's the context. I promise to post those points as a written text in a couple of days, before presenting them as a video. The point I'm presenting here -- just one point -- is a prelude to that post.

Content proxy. That's one thing that came up during the discussion. We were exploring the scenario where the operator acts as a proxy to the contents in the internet. In Eric's opinion, telco operators are not capable to compete with the internet. The rate of innovation that's happening in the internet is unparalleled. So the operator is not supposed to go down the path trying to (re)create the existing successful services / content on the internet. Basically he considers the thinking that "with IMS the telco operator can be like Google" is misguided at best.

So, being a content proxy might be their (only?) option. Let's go back to the diagram. First and the foremost, IMS is supposed to provide the same set of basic telephony services that people already enjoyed with the current, non-IP, technologies. That's what line A represents.

IMS lives in an IP network (after all IMS is an abbreviation for IP multimedia subsystem :P). In order to be able to fully deliver its promise(s), the clients also need to be in the IP network and have SIP-stack installed (among other things that make them IMS-capable). There aren't enough mobile devices in the market with such characteristics. In fact, it is an obstacle to a wide-spread adoption of IMS.

However, people can already enjoy high-speed access to IP network; 3G. Mobile devices have improved significantly. Things like iPhone, for example, turn lack of screen-space and crippled web browsers into things of the past. People can have direct, unabridged access to services like YouTube, Last.FM, etc. That's what line B represents.

The "content proxy" idea, to my understanding, is like trying to drive the subscribers away from line B to line C. People will do that willingly if they perceive additional values. What kind of additional values can be provided (with access through line C)? What does IMS -- and only IMS -- have to offer that enable such services? There was a relevant point raised during our discussion (that might provide an answer to those questions). It has to do with subscribers' profile (stored in the HSS) or rating & billing system (that is a complex stuff to install, configure, and manage correctly). Operators might be able to bank on it in their IMS offerings. That idea is still not perfectly clear to me, give me time to investigate it further.

In the meantime, please chip in, help me enrich the discussion, help me arrive to the right conclusion.

Thanks in advance and best regards,
Raka

UPDATE: When the recording started we were talking about Connected Home that Antonio mentioned to us. It got me thinking of the effort from Ericsson to push further the widespread of this telco 2.0 app. development, by providing hosting for SIP-servlet applications (on Sailfin), and some helper APIs and other stuffs. Check it out on the Ericsson Labs page.

A little note on C++

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.

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….

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:

1. Why trying to be an "app-store", another "me too"?
2. 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

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

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]