Aswath Weblog

An Analysis of Viber, a New Voice App

Last week a new iPhone app called Viber was introduced. In this initial version, the app can establish voice calls between two Viber users using 3G data or wifi connection. These calls are free of “in application” charges. But the application is very basic in its feature set: Missed Call Notification is the only feature that is supported in the first release. Initial reviews have been positive with reviewers pointing out the simple setup process, claimed frugal use of battery and high voice quality. In the first three days, there has been 1M downloads. So it is worthwhile to have a better understanding of this app. But please realize that I have not used Viber. This is not a review of user experience, but an analysis of its architecture.

A Brief Description of Viber

Viber is like many other VoIP services with 2 very important twists. Firstly it uses iPhone’s phone number for id. Secondly it uses Contacts stored in iPhone as the buddy list. Once the app is installed, it copies the local Contact list and appends a special icon to all the contacts who are also Viber users. The iconized list is updated whenever a person in the Contact list joins the service. From now on, this new Contact list will be used for calls. The app will use Viber service to call other Viber users and for all others, the app will direct to the native phone application.

Observations:

1. Viber reminds me of PhoneGnome. It also uses landline number to derive the SIP URI it assigns to the device. Indeed they have patented this process. It is not clear to me whether Viber infringes on this patent or not. Apple’s FaceTime also uses the phone number as the id for its service.

2. This app is developed by the same team that had developed and operating iMesh, a P2P network. But Viber itself is not strict P2P. The devices talk to dedicated “proxy servers” (it is not clear whether the signaling protocol is a proprietary one or SIP). But as I had observed a long time back in the context of Skype, Viber is using iMesh technology to scale its infrastructure. Essentially they have integrated iMesh supernode and the required “proxy server” function. This way they can easily scale up and down as the number of active users vary.

3. If the app is running in the background or has been closed, the service will use Apple Push Notification Service to prompt the user of an incoming call. Once the user opts to take the call the app will be launched and the call will be answered. This has multiple benefits. First is this helps in extending the battery life. Secondly, this scheme reduces data consumption. Finally, this reduces load on the service’s infrastructure because only active devices will be maintaining signalling connection.

4. This use of APNS may introduce call setup delay, since the app may have to be launched, connected to the server before call can be answered. It is not known to me how long is the delay and whether some callers may prematurely abandon the call attempt. We have to wait for a while to hear anecdotal data.

5. An iPhone with Viber installed could potentially be involved in two calls one on Viber and another on the native app. It is not clear how and who handles the feature interaction. For example, if a user is on a Viber call and a call comes in on the native side. Will the phone ring or the user gets a call waiting tone? How does the user answer the call? Is UI different? PhoneGnome handles it beautifully. Again, we have to wait before we collect some empirical data.