Pages

Pages

Friday, September 22, 2006

SIP-capable mobiles - minimising fragmentation

A couple of conversations I've had recently have warned me that SIP-capable mobile phones may already be starting to suffer from the interoperability & fragmentation problems that plague other handset software areas.

My understanding is that the implementation of SIP on phones at present is haphazard, with performance (and conformance) highly variable. While there are some moves to harmonise this, it seems likely that this will pose problems for developers in the short term. This may give some operators a respite from the threat of competitive 3rd party applications exploiting "Naked SIP" - but may also hamper their own efforts to deploy new applications in advance of "full IMS" becoming a reality.

It's also driving a number of the competitive mobile app guys to use their own proprietary protocols instead, rather than SIP. Obviously Skype is the most apparent, but I've met others in the Mobile VoIP space that are also going that route. (This also has the benefit of avoiding any nonsense with operators' SIP proxies or SBCs playing silly games with external SIP sessions, I guess). Some others use their own SIP stack within their applications, irrespective of whether there's another one in the OS.

Bottom line is that "it's not that easy" (is it ever?) to develop SIP-based applications or services that will work across a broad range of phones.

Now, the other market where this occurs is Java, where there has been huge fragmentation in the implementation of J2ME on phones - different extensions, different access to the underlying phone capabilities, different performance and so on. There's already a cottage industry of companies like Tira Wireless that offer porting solutions, taking a lot of the work out of customising device-specific variants of software. Others do testing, or other tools to help.

It strikes me that there are quite a few opportunities for doing the same with SIP. At the very least, a company with a database or a simulation tool of different phones' SIP implementation would be valuable. A porting tool would be more difficult given the range of OS's, but it ought to be possible to go part of the way.

Obviously, it would be best to get a standard way of doing handset SIP - but I suspect that this is likely to be operator-centric if and when it occurs. In the meantime, the best solution might be to assume fragmentation will occur, and look as soon as possible at creating ways of easing the pain.

3 comments:

  1. Anonymous12:43 pm

    > It strikes me that there are
    > quite a few opportunities for
    > doing the same with SIP.

    Probably too early.
    Those framework vendors came up for Java MIDP only after a few years of Java phones building up market penetration.
    Not sure what is the threshold for a framework vendor; maybe 100 M devices shipped ?

    ReplyDelete
  2. Anonymous4:03 pm

    Good article!

    We are repeating the nightmare of J2ME, and an excellent reason to stay away from the mainsteam.

    The innovation will come from the IP world, and not from the traditional Telco players. There are already, key non-telco players like Skype, that have a chance to bring the promise of open IP to the closed work of telcos.

    Don R

    ReplyDelete
  3. Anonymous11:36 pm

    That's a worry.. I hadn't realized these problems existed with SIP. Then there are the security issues such as spoofing etc. Voip has a long way to go before reaching the invisible reliability of traditional PSTN.

    ReplyDelete