OMTP handset VoIP settings requirements - pretty sensible

The OMTP have issued their requirements document for VoIP settings on subsidised mobile phones. I talked through it the other day with them - in general, it seems to make a good amount of sense.

In general, I have sympathy with the notion that if a phone is subsidised, then within reason the company offering the subsidy has some authority to tell the user how they can use it. In a truly competitive market, the user should be able to choose between various subsidised-but restricted combinations, or standalone unsubsidised-but-flexible ones.

The general thrust of the OMTP's recommendations is around those phones which are (a) subsidised, and (b) come with a pre-installed 'native' VoIP client.

Basically, if the phone comes with native VoIP, it should be able to have the operator's own VoIP service settings installed and 'locked'. It should also be unlockable after the contract expires, and critically, it should also be possible to load in 3rd party VoIP clients & settings, as long as they work alongside the operator's.

At present, 3rd-party VoIP vendors have 2 main options:

• Use the native VoIP app (which is usually well-integrated with phonebook, messaging etc) and use it with new settings and a new "upper layer" (eg Truphone)
• Ignore the native VoIP app and do everything from scratch (eg Fring)

With OMTP's stipulations, Option 1 becomes more difficult for a subsidised phone in-contract. That said, there's nothing to stop the handset vendor pre-loading two identical VoIP clients, or having one added on a memory card or downloadable when connected to a PC. Then VoIP#1 can have operator settings locked, but VoIP#2 could be open to all.

Other good stuff in the document:

• Basically, the settings-lock is similar to SIM-locking. It's intended to combat the risk of 100 operators locking phones in 100 different ways. Instead the idea is that they're all locked in a consistent fashion - which helps everyone. With this, there's absolutely no question of locking down the SIP stack outright, for instance.
• An enterprise should (in theory) be able to install its own VoIP applications and have them locked - essentially acting like an operator. So if Acme Inc goes out and installs dual-mode VoWLAN clients from Cisco, Avaya, Divitas or whoever, then John the Salesman shouldn't be able to muck around with the settings if he wants to play around with Skype or whatever on his company phone. Mind you, exactly how this is done is another matter - I was with Cisco's VoIP guys yesterday, and nobody had bothered to tell them that this type of option was going to be enabled, or how it might be achieved....