What is your client strategy?
March 26, 2007
Whenever I visit customers in Asia Pacific, it always amazes me how different companies that are developing the same product can go about it in so many different ways. OK, maybe not exactly the same product. One handset weighs in at 170 grams and their competitor’s handset at 164 grams. One handset could also have a metallic color, and the other shiny gray. Go figure.
In trying to understand this phenomenon, I came to the conclusion that all these different approaches are a result of a fundamental difference in R&D philosophy.
Let’s assume you are a developer, and you have been given the daunting task of developing a mobile handset. And YES; it should be an IMS handset. The applications you need to support promise you a major headache:
- VoIP calls (audio and video)
- Presence
- IM (Instant Messaging)
- VS (Video Sharing)
- VCC (Voice Call Continuity)
By the time you’re finished, you assume the whole world speaks in “acronym”…
And now for the 50 million dollar question: How would you approach this development task?
Rest assured I won’t let you think too much while reading this post. Take it from me… I’ve seen primarily two kinds of companies – the “top down” kind and the “bottom up” kind.
Essentially, if you need to build an IMS client (that’s a mobile phone that does IP), first and foremost you need a solid SIP IMS implementation. Not your average-Joe “IMS-ready” or “IMS-lite” one. You also need engines for all those fun applications that will enable you to do VoIP calls, presence, etc. And to top it off, you need a user interface that can be stitched into Windows Mobile, Symbian or whatever operating system you’re using.
Illustrating it in a diagram, you get the following result. 
If you are one of those “bottom up” companies, then you believe that infrastructure is the key. You search for the right SIP stack, with all those nasty IMS extensions. You make sure your RTP implementation can handle all those necessary bandwidth and retransmissions for IMS. And you select a good codec vendor that can deliver on the promise of encoding H.264 in CIF resolution using only 80 MIPS (I wish…). Once you have that part figured out, the next step is to look for the engines you need to build your applications!
If you are one of those “top down” companies, you believe that the world is a set of applications you can mix and match… and all is well in the land of computing. You see SIP, RTP and those codecs as commodities. And for you, IMS is just another one of those things that you’ll figure out in the future. So out you go to seek your fortune in the market. You find a slick brochure of engines and applications, and choose what looks nicest. Presto! You have a really cool demo application running that really works. Until you look under the hood or try to plug it into a real network with other users.
In case you haven’t figured it out, I tend to side with the “bottom up” guys. I’ve seen too many projects leave the gate and start out running too fast… just to find out (pretty soon) that they were heading in the wrong direction. And now they are left with a lot of catching up to do.
What kind of company do you work for?
You’ve probably already heard about IMS (and no, I am not referring to the Institute of Mathematical Statistics), and if you haven’t it’s about time!
In a way, IMS is all we ever wanted out of a communication system but were always afraid to ask for. It can handle services – intelligent ones, which traverse through several, different application servers. It can do billing. It is flexible. But it is also complex. Very complex. And at the heart of it there’s SIP – the text-based VoIP signaling protocol.
In its present state, IMS requires a large set of protocols. For SIP alone you will need SigComp, and Offer-Answer model, and Preconditions and P-headers, and new authentication and authorization mechanisms. And that’s not all. Since this requires a huge amount of work, the industry has come up with a new term for “wannabe IMS” companies that are currently deploying SIP and want to migrate to IMS: “IMS-ready.” By calling their products “IMS-ready,” what are they really trying to tell us? “Well, I have SIP, and I really want to do IMS… and since SIP is part of IMS, I am ‘IMS-ready.’” This means that sometime in the future they will get around to developing all those nasty IMS components that are missing.
If you think that this is all there is to it, then you’re quite wrong! If you have an IMS-compliant (NOT “IMS-ready”) solution on a SIP IMS User Agent (that’s a client), you also have a lot of applications running there. These can be VoIP, Video over IP, PoC (Push-to-X), Presence, Instant Messaging and maybe more. Each one of these is a world of its own, with a set of rules that are specifically tied to large number of standards – some of which are not even finalized! So your world as a client developer is a rather challenging one indeed!
How can a frazzled client developer possibly stay on top of all this? You can join the IMTC IMS Activity Group – a new “home away from home” especially for IMS client developers.
For years, the IMTC has been working on interoperability of multimedia technologies. I have been a part of this myself, as a co-chairman of the 3G-324M AG (Activity Group) for several years – in the good old days when video on 3G handsets was only in its infancy. Our 3G-324M AG has done some great things, and we still are, making sure that new handsets can talk to one another with video over circuit switched connections.
Now the IMTC has decided to open a new Activity Group to deal specifically with IMS interoperability issues on the client side – to help all those mobile handsets, wireless PDAs and wireline phones that want to be IMS clients. Not “IMS-ready” – IMS-compliant.
The bottom line: If you are doing IMS, and you are developing clients, the IMS AG, is the place for you. I’m the co-chairman and I can tell you that companies like Ericsson, Nokia, Sony Ericsson and Samsung are already there. So come and join us!
