Telstra allows iPhone tethering

Apparently the australian Telstra has reversed their iPhone tethering policy. You can read more at ZDNET.

While some might view this to be a move towards enabling future 3G/Internet convergence that IMS is supposed to bring to the market, in my humble opinion it is more likely that it's just a response to customer requirements.

Opensource phones vs. operators

According to the PCMag, the current state of opensource platforms for mobile phones is not very promising since the wireless carriers in the US "hate the unexpected" which is argued to be one of the key attributes of open source technologies. The author basically argues that if you provide phone users too much power through an extendable OS like Linux, the networks would go "poof" as somehow a lot of "geeks" would start overusing the network.

I do agree that the author has a point in that open source tools and technologies are less likely to have a predictable development path, thus making it harder for incumbent operators to re-train and re-deploy their huge staff. Not to mention the trouble with documentation that (does not) come with opensource tools and technologies.

However, I don't think that the operators are worried about geeks "overusing" the network. The operators actually have quite solid tools for monitoring and operating the network, and they are actually very good at denying access to network hackers, barring the DDoS crowd.

Besides, in all networks the "geeks" make up a very small percentage of total user count. Network planners certainly would not make major network planning decisions based on the behaviour of this marginal group.

The author of the PC Mag article also argues that some of the incumbent operators like T-Com and Sprint were fully focused on becoming a sort of 'telecom for geeks' . I would like to point out that no large operator, could ever split even, let alone make profit if it was focusing on a very small group of users. The reason is that these already have made huge investments in software and hardware platforms and need a very stable cash flow just to cover their operating expenses.

Having discussed the importance of geek portion of market for operators, now imagine say, 50% of network, "average users" using an advanced opensource platform phone in the network.

The so-called average users are much more likely to (check all that apply) :

a) do something wrong with the advanced platform

b) not notice that they did something wrong

c) have their phone eventually malfunction as a consequence of a) and b)

d) forget what exactly they did wrong since they did not understand what they did in the first place

e) call support staff

f) call support staff again

g) decide that the operator sold them a broken phone

h) switch to a different operator

Due to their technical incompetence, the non-geek users are far likely to make trouble by using a thirdy party app they do not understand (and which could theoretically be malicious software).

Since they do not understand what they did in the first place, they are less likely to be able to self-recover from the problem, and possibly giving a lot of trouble to the operator's support staff.

As a reaction to this problem, the operator would invest more in staff, software and hardware in order to provide better "user experience". This step will not actually solve anything as each operator tries to get a larger market share so under the presumption of an ever increasing number of users additional investments to support department are required.

Eventually, the number of available 3rd party apps, and custom-made extensions makes things so complex for maintenance that operator decides to scale back. Since the staff, software and hardware investments are cut down, so is the support for the platform, and operator goes back to supporting the simple and predictable platforms.

Therefore I conclude that the core issue with the open source on mobile phones is the same as open source on desktop computers - it's simply not simple enough for the average user.

On .NET : Components.Efficient.Design

Recently, as I was extending a product my company is working on,  I found something that in my humble opinion can be treated as an inconsistency of Microsoft .NET development team. 

First of all, let me point out that my views are heavily influenced by OO and I usually try to enforce as much encapsulation as possible in my UDTs , because that's one of the core benefits of OO . For me that's the most important benefit of the OO, as it reduces my stress level when managing components in a project. 
So, my issue is with .NET System.Windows.Forms.ListView component . You see, if I'm  creating one or more  ListViewSubItem instances via the new ListViewSubItem(ListViewItem owner, string name) constructor, I am expecting that the .NET will automatically copy this sub-item into ListViewItem's SubItems collection. However it does not, and I have to invoke the AddRange method on that collection each time I'm doing an operation on a ListView.   Now for me , it just creates unecessary overhead, almost always incurs additional time costs as I practically always forget about this tiny fact . 

To be honest, surely, I too  make such mistakes when designing my own components, so I've come up with an evergrowing checklist for OO component compliancy enforcement. Bear in mind that these are here just so that one can reduce the stress factor, and not to claim that one follows some fancy philosophy, for the sake of it. 

W/O further ado :

1. If you find simple code sequences repeating themselves, put them in a method

2. If you use an empty constructor, and afterwards setup the UDT instance by various method calls or value copying, consider a constructor that does this for you.

3. Test-case your UDT's method to check for possible inconsistencies. For example , if you find your self writing code like this: 

UDT a= new UDT();

int nFirst = a.First;

int nLast = a.Last;

if(nLast!=nFirst)

{

DoSomething();

}
You might be better off with something like this : 

UDT a= new UDT();

if( a.IsEqualityOK() )

{

DoSomething();

}
In the latter example , you have not only reduced the clutter in main logic block, but have also made it much easier to maintain your  comparison logic later on, as you might need to check for equality in other code blocks as well. 

4. When creating  complex data types, layered one on top of another, make sure that one method call does all that is required . 

5. When primitive types  count starts growing in your UDT (i.e. you have 50 string properties), it might be wise to group them into smaller UDTs, and provide accessors . This of course is managed by your own prefs. And there is always the issue on not overdoing with the UDTs. In my experience, a UDT is of optimally managed when it contains at most 10 properties and at most 5 methods. Of course, this is my ideal case, which is not always possible to maintain.

6. Design your components before you start coding, but do so in an environment-aware setting. That is , make sure you understand  how your component will be used. Setup a scenario on the whiteboard, explore possible interactions with other pieces of components , explore why these make sense (or not). This is IMHO the single most important step, altough it is often understood well only after running into trouble with a quick-designed component. Yeah, happened to me a few times too ..

7. If at all possible, try to keep one constructor for your component .

8. Reject the "Code first, refactor later" rule. If on the other hand you use this rule to write code efficiently and on-time, please accept my sincere apology and envy. In my humble opinion this rule is of no good.

9.  When you need to use threads, use .NET method delegates instead of standard threads (if your particular application need does not specifically call for use of System.Threading namespace of course) . It will make thread management far easier , as .NET creates and manages these threads for you, which bring us to point 10.

10. Keep program flow as simple as possible. And here is how I do it : I usually enforce a predictable program flow eventhough I really overuse the .NET delegates and events, by making all events and delegates go through a single "worker" class instance ,which is responsible for dispatching them further . That way I know that no matter what happens in my program, I have a single entry/exit point for all program data . It also gives additional benefit of  stripping other smaller UDT components of responsibility for main processing logic , so it narrows bug tracking to two essential areas :

• Main logic
• Data formatting and forwarding by UDTs

And that's about it. Simple, no ?

OpenIMSCore and SUBSCRIBE requests

The Call Session Control Functions implemented in OpenIMSCore are based on IPTEL's SIP Express Router,a wonderful SIP proxy I would recommend to anyone building a VoIP system. 

Surely, you would want your Application Server to track the user status via SIP SUBSCRIBE command, right ? 

According to this draft specification , all you need to do is specify Event header to value  debug, and Accept header to value  "application/debuginfo+xml" , and if all the security settings are in place, your Application Server should be processing incoming NOTIFY messages in no time , right ?  Well , not quite .

Caveat : I have not done any verifications on other platforms , but it will certainly not work for OpenIMSCore, source code revision 608, and here is why. 

I went along the way I envisaged my application (remember,  I was going to use SUBSCRIBE request to receive NOTIFY messages on user status in the IMS network) , however it just did't work . SCSCF kept crashing every time after receiving a perfectly formatted SUBSCRIBE from my AS application through ISC interface ! 

WT..Hell?! 

Some scscf.cfg fiddling and a couple of Wireshark sessions later, I've decided to look into the C code of the actual SCSCF implementation. I am not going to post the code here even though it is released under one of those GPL licences,(and you can get it freely from svn repositories of berlios.de) but it will suffice to say that the only SUBSCRIBE Event headers  that are accepted are "reg" (for registration status), which is of no practical use to me as I can get user registation status via either UDR or PNR through the  Sh interface . To further support my case, and to paraphrase  a dear professor of mine from undergrad studies - if you don't trust me, take a look at the code and see for yourself :)

 

But wait, there's more !  Not only does this implementation not allow "debug" Event headers, it also limits the acceptable senders to the Proxy Call Session Control Function and the registered UE itself.

So there you go , if you are not going to modify the OpenIMSCore code yourself, with the release source code release revision 608 that I am using, you won't get much of ISC functionality, unless of course you are developing something other than an Application Server. 

I would like to close this piece with a remark that I am in no way bashing/critizing the OpenIMSCore development team  -  I highly admire and value the work that people at Fraunhofer FOKUS  have completed thus far, and respect the fact that they were kind to share this platform with the rest of us to play around. Their efforts to help everyone on their mailing lists are commendable as well.  

If anyone else has had similar experiences on this or any other IMS platform, I would love to hear them, particularly the stories of the "dreaded" ISC interface.

Nice,short and sweet one

I'll be posting a comprehensive entry on topic of AS development on OpenIMSCore platform during the next 24 hours. Been quite busy with prototyping a new product so I had very little time left for that.

If anyone's interested in what about the new product is - e-mail me  and I'll enable you with access to peek preview . Make sure you state your position and interests .

A quick poll

I am thinking about a possible new app and need some feedback.

For your convenience I have created a LinkedIn poll (takes 2 secs to complete, you've got just one question to answer) .

I will highly value your responses.

Oh,and if anyone is interested in tracking how my M.Sc. app development is going forward in realtime, you can take a look at it on twitter

Good night America, where ever you are .

Trouble deploying Java apps on different machines?

Ok here is my story .

I am completing my M.Sc. thesis on IP Multimedia Subsystem at University of Tuzla, and have been working on an application that fits inside OpenIMSCore , a core implementation of an IMS network kindly provided by folks at Fraunhofer FOKUS institute. 

So far so good, I have developed my core engine (more on that in my next post) to interact with SCSCF and HSS , and everything worked like a charm  on my Linux testbed . My mentor okayed it , and we agreed that I should press forward with GUI design and writing the actual text of the thesis. 

So last night I fire up my all-time-all-languages favorite IDE, NetBeans (curr.version 6.5) and start designing the GUI . 

Add a checkbox here, add event handler there, wow that was really smooth (I can still remember the pains of developing GUI for Java 1.1 and 1.3 apps). Anyway, I pretty much completed the barebones stuff I wanted in about 30 mins, and have deployed it on a virtual Linux machine where my NGN OpenIMSCore is installed and configured to work with my Core Engine stuff. I start the app, and get one of those missing libraries errors :

Exception in thread "main" java.lang.NoClassDefFoundError: javax/swing/GroupLayout$Group

After attempting to recompile with additional set of libraries which didn't work as expected, I started digging into the GUIs code. It turns out the problem was a simple one .

You see when you design GUI in NetBeans, the layout mode selected by default is the one called "Free Design" . It adds the code to group your GUI components into GroupLayouts which will work perfectly if you are going to run the app from within NetBeans or on the same machine, as the dependencies will already have been properly set for you.

If you however want to make your GUI app portable, and do not have the time to mess with setting up library dependencies into your project, or on the other machine, just  right click on the frame and select a different layout option . 

I found it that AbsoluteLayout works best for me as it requires no extra GUI dependencies and is likely to work on most machines with standard Java 1.5 and above installed.

Caveat : This is a quick solution , and I am not suggesting it as absolutely correct and the only true way, so don't bash me because of that :) 

Let me know how you normally cope with that.

Up next : My core engine in OpenIMSCore, and it what does !