Home > How to, iPhone, Mobile Communications, Saving money, Telephony > A working Mobile VoIP solution for the iPhone – Acrobits Groundwire and Flowroute

A working Mobile VoIP solution for the iPhone – Acrobits Groundwire and Flowroute

October 8, 2012

A few weeks ago, as I was reaching the end of my two year ATT contract, I started wondering whether I should buy a new smartphone and sign for two more years of big carrier abuse, or explore alternatives. I considered MVNOs, tested IP messaging solutions such as Viber or Skype, and finally decided to go one step further and build my own mobile voice over IP (VoIP) solution.

Acrobits Groundwire - the keypad

Acrobits Groundwire – the keypad

A mobile VoiP solution requires three components: a mobile carrier providing the 3G data service, a Voice over IP service provider playing the role of a gateway between the public telephony network and the world of IP communications, and an application (“a client”) on the iPhone. At first glance, a VoIP app looks like the iPhone “Phone” app, but is using the SIP protocol to manage the connection to the VoIP provider (that’s why we will call the application a “SIP client”, and why VoIP service providers are often called “SIP Poviders”).

After testing various VoIP service providers and iPhone SIP clients, I’ve finally identified the combination that works best for me. It does not mean it would work for everybody, though, or that I would trust it if my life (or a job, or anything important) depended on it. I still have my reservations about the practicality and the reliability of the solution. But it brings the flexibility of VoIP to mobile phones at a very low cost, in particular when calling or traveling abroad.

The cost of a mobile VoIP solution

A consequence of the increased use of Text Messages and IP messaging applications, conventional voice traffic is reported to have decreased, and mobile  carriers  now have excess capacity on their conventional (GSM or CDMA) voice networks. That’s why they’re now proposing unlimited voice plans. On the other hand, data bandwidth is still a “hot” commodity, and they’re trying to sell it at a premium. So, does it make sense to switch to VoIP?

As discussed earlier, there are 3 components in a mobile VoIP solution:

– the Data Plan (such as ATT’s for the iPad):  3GB/Month: $30.00. VoIP does not need much bandwidth: with a G729 Codec, approx. 70 MB per hour. And the data plan will only be used when a WiFi connection is not available.

– a Voice over IP service from a provider such as Flowroute.com:  $0.012 /min or $6.95 /month (unlimited) to receive calls, approx $0.01 /min for outbound calls in the US. Minutes to foreign countries are more expensive, but still 10 to 50 times cheaper than with a conventional voice plan. Add $1.39 /month for a DID number.

–  a SIP client (a one time cost) : Acrobits Groundwire application: $9.99 on the Apple App Store; G729A CODEC available as an in-app purchase ($9.99)

If you consider that you will need a data plan in any case, the real cost of the VoIP solution is the cost of the minutes. 900 minutes of voice (to or from the US) will cost approximately $10. Plus the DID number.  Total: $12 per month.

The nitty-gritty details

Settings of Acrobits - how the iPhone receives incoming calls

Acrobits Groundwire – The different options proposed for managing incoming calls. With a VoIP provider using TCP, “background always” is the best option

For the software engineers working on SIP clients, smartphones present a few extra difficulties: in order to preserve the battery, the SIP application has to be placed in a dormant state when no phone conversation is going on, leaving the responsibility of staying in touch with the VoIP service provider to a keep-alive mechanism managed by the operating system.

Because of the way Apple has implemented multitasking in iOS, only TCP keep-alives can be managed transparently by the operating system, and only TCP flows can wake up an application in a dormant state. Unfortunately, most VoIP providers only work with UDP.

It leaves the software engineers with 3 options:

1 – use UDP, prevent the application from hibernating, and manage the keep-alive in the app itself – which impacts battery life and is not endorsed by Apple,

2 – implement a proxy server somewhere in the cloud, which receives the call in UDP, connects to Apple’s notification system to wake up the phone, and finally converts the UDP flow into a TCP flow that can be forwarded to the iPhone. The whole process is convoluted, and raises all sorts of concerns regarding reliability and security.

3 – or ask the end user to find a VoIP provider using TCP.

I tested the 3 options, and came to the conclusion that configuring the SIP client to receive TCP calls directly from the VoIP Service provider yielded the best results.

Acrobits and Flowroute over TCP

When receiving a call, the iPhone is waken up almost instantaneously, and the Acrobits Groundwire app  is promoted to the foreground in a few seconds. The reactivity of the direct TCP connection – while not as good as what you would experience with a conventional voice call – is much higher than what proxy based solutions deliver, and does not require a total reeducation of the end users – at both ends of the line. And the impact on the battery life remains limited, at least with WiFi connections.

Acrobits Groundwire - the call is established

Acrobits Groundwire – the call is established

Flowroute, the service provider I selected, supports VoIP over TCP. It also has the advantage of supporting G729 (the efficient voice compression mechanism used in the GSM standard). Groundwire, the SIP client from Acrobits, proved very configurable, reliable,  and easy to use at the same time.

In my opinion, the G729 Codec is a must: VoIP does not need a lot of bandwidth, but it needs it consistently. We’re using public networks (WiFi hot spots, the Internet) which do not “protect” the VoIP traffic. The smaller the bandwidth required (G729 only requires 10 kbps), the better the chances for the call to go through with an acceptable quality.

I did not notice that enabling VoiP had any visible impact on my data usage, but the autonomy of the phone suffered.  Even with the optimized TCP solution. The impact on battery life remains very acceptable as long as the phone can connect to the Internet over WiFi, but if you are on the move with only 3G data available, the autonomy shrinks dramatically (down to a few hours).

Before I settled on Flowroute and Acrobits, I used Bria, from Counterpath, with Callcentric, a provider delivering the calls on UDP. Because iOS does not permit a UDP flow to wake up a dormant application, Bria had to stay awake in the background, which impacted the battery life significantly. It worked until I upgraded my phone to iOS 6. iOS 6 seems to manage UDP flows differently, breaking Bria’s ability to reliably receive calls over UDP. On their support forum, Counterpath blame a bug in iOS 6, and promise a work around on their next release.

Even if the SIP client application is well designed, it can not totally hide that the iPhone was not designed for VoIP. Its firmware and its OS expect voice conversations to use the GSM network: accepting a VoIP call requires at least one more step (unlock the home screen) than accepting a GSM call, and if you receive a conventional phone call over GSM while already engaged in a VoIP conversation, GSM will take precedence and will terminate the VoIP conversation.

A conclusion

Acrobits Groundwire - the locked home screen when a call is received

Acrobits Groundwire – the message on the home screen alerts about the incoming call. The user will have to enter the unlock password to take the call.

Mobile VoiP? If you stay in your home country and never travel abroad or place call to family or friends overseas, I’m not sure it makes economical sense. VoIP minutes are cheap, but the cost of conventional voice minutes is going down rapidly (with an MVNO, you can get unlimited voice and text for $40.00 /month). If you travel to foreign countries, or place long calls overseas, VoIP is much more interesting. The minutes stay at the same price no matter where you are. But you have to live with the hassle of buying local 3G SIM cards and fiddling with APN settings.

I have my reservations regarding the reliability of the whole solution. Ultimately VoIP is dependent on the availability of 3G data networks (which are less prevalent than GSM or CDMA networks), and can be complex to set up (configuring a new 3G data carrier requires a change of the APN parameters in the “settings” application of the iPhone).

On a smartphone, a SIP client is just a third party app like any other third party app, which creates all sorts of issues (did you relaunch the app after you restarted the phone, has the application frozen in the background?).

Until a manufacturer decides to bring Mobile VoIp to the mainstream and designs an IP-only smartphone specifically for VoIP applications, it will remain a complex solution that can be broken by an operating system upgrade.

  1. sip_03
    October 12, 2012 at 6:16 pm

    Did you try Bria with TCP? (with the Run in BG OFF?)

    • October 15, 2012 at 9:05 am

      I’ll need a few days of testing to have a definite opinion about the usability but it seems to work fine. The key factor seems to be TCP, not the client. I’ll keep you posted.

    • October 20, 2012 at 9:43 am

      Hi Bogdan. I’ve been using Bria all this week. It’s a nice product and it can do things that the other product I was using can’t do (such as sending DTMF signals for voice mail or audio conferences). I experienced the issue described in the support forum (cannot place or receive a call because the native phone has a call in progress). I would be unfair for me to write a test report now considering it’s a documented bug and Counterpath’s working on a fix. I’ll review it when the new release is available and the iOS 6 related bugs are fixed.

  2. sip_03
    October 20, 2012 at 12:56 pm

    Thank you Xavier!

  3. January 16, 2013 at 11:47 pm

    The correct way to implement mobile VoIP is to use push service for incoming call notification to wait up the VoIP app.

    • January 18, 2013 at 9:08 am

      Hi Wai Wu, my real life experiments with mobile VoIP lead me to believe that the issue is not so much the architecture of the solution, but the sorry state of mobile data services around the world.
      Mobile data coverage being as miserable as it is, Mobile VoIP is not reliable if you want to be always reachable and receive calls. On the other hand, it works fine if you’re on a network you control (WiFi) or if you want to place non urgent calls.
      More about this in a few days (I’m preparing a post to summarize my experience).
      Thank you for the input.

  4. Chris
    March 3, 2013 at 7:07 am

    Very interesting article. Could you elaborate even more of the performance difference between VOIP TCP en VOIP UDP? (battery, speed) As Wai Wu also mentioned push is the standard for incoming notifications.

    Additionally I’m also wondering what the bandwith usage is for the G729 Codec and how that for instance difference compared to for example Skype and Talkatone / Google Voice.

    • March 3, 2013 at 12:55 pm


      Same disclaimer as for the previous answer. I’m not a professional blogger or a journalist. So son’t crucify me if the answer is not technical enough for you.
      Second disclaimer – at least with the two products I bought and tested (Bria and Acrobits): the two apps are being updated very regularly – almost every other week – and what was true when I tested the products may be different now.
      Third disclaimer – with the wireless major carriers (MetroPCS being the first) migrating the voice traffic from their old 2G networks to their new (IP only) LTE networks using VoIP technologies, a lot of attention is going to be given in the coming months and years to wireless VoIP, both on the network side (support of QoS) and on the handset side (VoIP calls will have the same level of priority as conventional TDM calls at the operating system level).

      Now, the answer to your question: on an iPhone, only a TCP flow can wake up an app from its dormant state. Or take advantage of the notification system. If your VoIP implementation uses UDP, you have either to leave the VoIP application active all the time, or rely on an external service, whose gateway will generate a TCP notification that will wake up the VoIP app so that it’s ready to accept the incoming UDP call.

      When I tested Bria and Acrobit’s Groundwire with Flowroute and CallCentric, I decided to use Flowroute with TCP/IP, precisely because it did not have to rely on an external notification system and could work with any of the two VoIP applications.

      With UDP VoIP, there are two options – leave the application active in the back-end – but it impacts battery life, or rely on a notification mechanism such as the one implemented by Acrobit: you redirect your VoIP UDP calls to a third party gateway (Acrobit’s), the gateway generates a TCP notification request to Apple, Apple forwards the notification to the OS of your iPhone, the OS wakes up the VoIP application, which is ready to take the UDP call. It’s convoluted, requires many moving parts to stay in sync, and adds a few seconds to the call establishment process. That gateway becomes a single point of failure, managed by a software vendor who’s not in the business of offering telecommunication services. I did not like the idea.

      G729a has a fixed bit rate of 8kbits. http://en.wikipedia.org/wiki/G.729

      In my experience, the Voice component of proprietary messaging applications such as Skype or Viber is pretty efficient. My biggest issue with Skype is that the Skype client on the iPhone is so bloated it takes forever to start when you receive a call.

  1. January 20, 2013 at 9:02 pm
Comments are closed.

Get every new post delivered to your Inbox.

%d bloggers like this: