Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Tuesday, August 07, 2007

VoIP and Java ME

About two years ago I first read about JSR-180, the mobile handset Java extension that supports SIP. Its emergence was one of the factors that I included in my report on SIP-capable mobile phones last year. To be honest, it's been a little bit slower in coming than I'd anticipated, although it's present in newer Symbian phones and SonyEricsson's latest handset Java platform.

This got me thinking..... I would have expected to have seen at least one Java ME (formerly J2ME) VoIP client for handsets by now. But I haven't come across a single one, and none of the VoIP software companies I talk to have mentioned it.

[Side note: I presume that Qualcomm is enhancing BREW to support VoIP for CDMA EV-DO Rev A deployments]

Now, to create a Java VoIP client, you don't just need access to SIP (or another proprietary protocol), but also to RTP, audio codec selection, realtime audio features and so forth. You'd also need ways to access & control either WiFi or 3G networks for the VoIP traffic. Lastly here's also a need for mult-tasking Java, so you could leave a VoIP client running 'in the background' for any incoming calls.

All told, I guess it's a pretty tall order. Unfortunately, I reckon that this is essential for any really widespread massmarket deployment of wireless VoIP, either by an operator or an independent provider, as I don't believe that the penetration of open OS smartphones (Symbian, Windows etc) will get much beyond perhaps 20-30% in most countries, Japan excepted.

Most average consumers don't like downloading applications onto mobile phones. Very few people put a smart OS in their top-5 criteria for handset choice. I'm no different - although I've got smartphones around for work and testing purposes, my main personal phone only has Java and that's not likely to change in the next couple of years. So I'm excluded from all the wVoIP activity when I'm outside of 'work' mode.

(For those that find this weird: when I'm off-duty I'm absolutely not an enthusiastic 'mobilist'. I want an ultra-fast UI, good voice, intuitive dialler & phonebook & SMS clients, an OK browser and a good camera. That's it. I'm really not bothered about an open OS or WiFi and I never, ever, download aftermarket applications. I'm quite curious about GPS though. In other words I behave like 99% of normal mobile users).

The bottom line is that Sun's Java Community & all the various Java enthusiasts really need to get on the case with this. Sure, the JSR-281 IMS API might help operators with SIP application, but I'm not clear that even that will sort all the audio-related issues needed for full VoIP. Aside from that, there's clearly a lot of potential for 3rd-party VoIP applications on Java devices - but there needs to be an explicit push to optimise for it. This needs to be sorted, as otherwise this is a huge gating factor on wireless VoIP.

5 comments:

Anonymous said...

No need for multitasking JVMs, the app just registers to say it wants to be woken up when a SIP call comes in (though actually I think all the handsets that do currently have SIP APIs also have multitasking JVMs).

The APIs do manage the SIP protocol but you would still need to write some quite complicated code to handle the actual sound for a VoIP call, if I understand it correctly, so a VoIP client is a non-trivial app to write and also it would use a lot of features that are likely to be buggy, making porting quite a challenge.

ben said...

One other key issue (pretty much a deal-breaker for commercial VoIP providers) is that end-users need to be able to make VoIP calls really, really easily, in the same way they make cellular calls. A really key use case for this is making VoIP calls from the built-in phonebook.
The Nokia S60 built-in VoIP client, for example, even allows you to set the default call type to "Internet Call" so that calls are always VoIP (assuming you're in WiFi coverage, and don't choose otherwise). Or you can choose the call type when you place a call.
Unless it's really easy, people just won't do it.

Javier Sanz said...

What about the gmail application (java based) for handsets? Why would users be "against" downloading this type of applications?

mandiram said...

Apart from the commercial voip client,has anyone had the experience of developing some voip applications based on JSR 180 for testing related purposes?

I am not sure whether it is possible using JSR 180. Can anyone please clarify me?
Thank you

Kirsty said...

@Ben I want voip for my Java phone because I can use my home wifi connection to make international calls on the cheap (or even free if I'm skyping). Sure if I'm at home I could boot up the PC but I'd rather use a phone to make a phone call! I don't care if I have to run a third-party app and have a separate phone book as the sort of calls I need to make are to transient numbers anyway. Pity Skype haven't made a java port of their client.