Mobile VoIP applications are exploding. Analysts predict that by 2015 there will be one billion mobile VoIP users, which ought to be plenty of incentive to add VoIP functionality to your mobile apps. But VoIP isn’t like regular phone service. And while a lot of tools can add VoIP to your apps, there are also some special considerations. Here’s what to know before you get started.
With millions of people using VoIP, including millions of mobile device users, adding telephony features to mobile apps is becoming an increasingly critical goal for mobile developers. But making VoIP work over mobile apps raises a number of issues, ranging from voice quality and integration considerations to social issues. It takes some thought to decide how to add VoIP to mobile – if you decide to do it at all.
The actual technical installation is anything from dead easy to medium difficult, depending on the platform and whether it has an API for VoIP built in. However, implementing a VoIP channel is only one of the considerations software developers face. There are other issues, both technical and social, which may prevent effective use of VoIP over mobile devices.
One major consideration is bandwidth. In any use, VoIP requires a good deal of bandwidth to work successfully; just how much is required depends on the modulation scheme you choose. In general, developers say, the bandwidth problem is in the server, not in the VoIP system itself.
In mobile VoIP, the situation is made worse by the shifting quality of the connection as the user moves around. This is especially true in situations where the user moves from a Wi-Fi to a 3G connection. In that case, the VoIP connection usually gets dropped. (Let’s guess: Will the user blame the telephony connection or the lousy software?)
Acceptable voice quality is another consideration. Mobile VoIP is subject to all the ills of VoIP quality – in expanded form. Dropped packets, noise on the connection, and dropped calls are all more likely to occur on a mobile VoIP connection.
Also, developers need to think about what they aim to do with the VOIP connection. In some cases, it’s not a problem. For example, if you want to use mobile VoIP to lower the cost of the call, you should be okay if you know your users stay in a fairly stable environment. (Say, it’s a manufacturing plant, and most employees stay on the company campus.) In that case, mobile VoIP works better than if you're using the device's main channel to transmit data and the VoIP connection to annotate it.
“It depends on what platform you're using,” says Vithya Tith, senior mobile developer for Speek, a maker of conference call technology for mobile devices, who mostly works on Android. “You need your own voice account. We have our own voice account and server. On Android the built-in library is already there, and it just works. But if you were to use another platform, you might have to buy a third-party library.”
For this and other reasons, Tith says, Speek decided not to offer VoIP on its iOS platform, although the company does feature it on the Android platform.
Connecting the iOS platform for VoIP is one of the more difficult connections, says Tith. Apple doesn't provide VoIP hooks for iOS, so developers have to use a third-party API to connect. Unlike with Android, Apple doesn't provide a native VoIP API.
“A popular solution on iOS is the Twilio SDK, says Tith. “Open source SIP SDKs include Sofia-SIP and Linphone.”
Twillo’s SDK allows an app’s users to communicate in real time between Web browsers, mobile devices, and land lines with a single click. Using the SDK, developers can create apps that enable users to make phone calls through any iOS device that has a data connection. Apps can also deploy mobile agents, equipped with nothing but an iPad and a headset.
But this isn't the whole story, according to Long Le, founder of the game studio Startled Monocle, of Mission Viejo, Ca. “Apple has released a game-centric framework that allows two players to connect using VoIP,” Long says. “Part of that framework includes VoIP. It boils down to seven lines of code.”
In addition to two-way communication over VOIP, the game framework (called Game Kit) includes a number of subroutines to help control the environment. “You can integrate voice and have it behave in the way you want it to,” Long says.
One example is a subroutine that disables the microphone. “Some other applications design integrated voice but don't give you any way to disable the mic,” Long says.
This is particularly important because many people are not comfortable using voice on top of a data or video stream. In the gaming world, Long says, many users aren't comfortable using voice unless they feel they know the other person. As a result, game companies use things like player avatars as a way to break the ice and ease players into using voice. “[Users] will not use voice willy-nilly,” Long says. “Voice will be used only after developing rapport with certain users.”
The same dynamic applies to non-game uses of VoIP where the mobile device is also transmitting document files, spreadsheets, or video. Even if a voice channel is present, some users don't like to employ it.
“Voice is so much better than typing on a screen,” Long says. “Especially when the keyboard takes up half the screen.”
That puts things squarely back in the developer's court. “The social aspect is still up to the designer to make it easy for users to use voice,” Long says.