I was on a business trip last week, visiting some prospective clients in Asia. If there is anything that I learned there is that the Android OS is about to get a real boost from the Asian vendors, a lot bigger than the one we see now. This is quite big in its own right – there is good reason why Android sales have surpassed the iPhone – it’s a simple matter of scale.
But there was something that came up in each and every meeting I had where the potential prospect was looking for a 3G-324M mobile video telephony solution for Android, and that’s the question of where the risks lie – what kind of challenges will the developers have in the process? So as I tend to do in such cases, I provided the vendor with what I believe to be the best possible answer and came back here to share my thoughts with you, my readers, as well.
So here are what I believe to be the 3 main challenges that developers will have to overcome when integrating mobile video telephony into Android:
In the “good old days” of Windows Mobile, some 2 or 3 years ago, most of our customers were more worried about integrating the 3G-324M protocol stack into the OS. For some reason, interoperability came later. If anything, they had a lot of questions around the issues of call setup time.
In this round, where customers come and ask about Android, their focus has shifted from call setup time to interoperability. It is also where I see the most important aspect of their planning.
3G-324M is deployed in a large number of handsets – old and new. Operators test new handsets in their own test labs. GCF validation processes are required from video telephony for new handsets. All this means that interoperability is a real headache, and one that vendors face only when they have finished developing their product and are ready to release it commercially with an operator. If they don’t plan well for this procedure, vendors can find themselves mucking around at a test lab working on things they could have done a lot earlier in the process.
2. Mapping 3G-324M to the Android Architecture
A mobile handset is a complex beast, and Android is a modern operating system with a clean architecture. That said, there are a lot of layers to Android. For video telephony to play well in Android, it needs to interact and interface with most of the Android layers.
Where will the changes required for 3G video telephony be?
- The 3G-324M protocol stack resides better on the side of the libraries, as native C/C++ code. It requires real-time access to both codecs and the baseband, so having it in the upper layer simply doesn’t make sense.
- There should be a JNI layer for the video telephony solution that will be accessible by the Application Framework layer, where Java code resides and where the GUI is managed. Without it, there is no way to display the video, control the call setup process or integrate it into the Contacts module.
- The RIL (Radio Interface Layer) provided by Android is great for telephony, but doesn’t really take care of video telephony – there’s no readily available interface there that allows for opening up a 64kbps circuit switched connection. It means that this layer will need to be modified by the vendor to add such support.
- The peripheral drivers – camera, audio and display – need to interface with the video telephony solution. You might even need to tweak them a bit to fit the real-time demands of 3G-324M.
3. Dealing with the Baseband and Codecs
This is one that any handset vendor needs to deal with, be it Android or any other operating system.
While the baseband vendor supports 64kbps circuit switching mode, Android does not – at least not out of the box. Adding such support requires deep understanding of the inner workings of 3G-324M and modem implementations. The reason is again the real-time nature of 3G-324M. So while the initial implementation of this part for proof of concept purpose may be quite rapid, it needs to be optimized and stabilized for a real commercial solution.
Codecs are another story. While Android comes with a solid multimedia framework that handles audio and video, it doesn’t do a good job of supporting real-time video, where special care needs to be taken: aspects like the inability to retransmit data, the need to lower latencies to the extreme and interact more closely with the video codec are just not handled properly. This requires additional attention from vendors to make sure they get this implementation right.
What Does a Vendor Need to Do?
If there is one takeaway I’d like vendors to have from this post, it is that the Android OS “out of the box” solution for 3G-324M doesn’t work. It won’t address any of the challenges I’ve stated above. And believe me – I have the scars, from multiple handset vendors and operating systems, to prove it – these will be real show stoppers for the release of a commercial product.
I’d say that vendors have two options to address these issues:
- License a leading, proven, commercial 3G-324M protocol stack, like the one we offer. You will still need to take care of these issues, but the stack vendor should be able to support you. If you choose this path, you need to make sure you have the resources lined up for such an operation.
- “Outsource” the video telephony project within your handset to a 3rd party. We have such an offer readily available as well. This will keep your mind at ease and allow you to deal with other aspects of your handset.
Both options will get you to your destination, and in both we have what is required to assist you along the way. So choose the strategy that best fits you and contact us.