Skip to main content

The Connection Between ICS, Battery Life Issues, and VOIP


Most of the smartphone owning population doesn't know or care about VOIP, or Voice Over IP.  They get phone calls through their cell provider (not to mention the phone itself), solely over cell tower signals, and that's that.  But as some know, there is another dimension to calling, and that is the world of VOIP.

VOIP allows a phone or computer user to make and receive phone calls over any medium that can carry IP.  This includes not only your 3G/4G data plan, but via a Wi-Fi signal at home, work, or in many public places.  It also means that you can make and receive these phone calls without necessarily being tied to a certain company or contract.  You can even use your own hardware to host these calls, and connect these calls to the outside world in a variety of ways in an openly-competitive market (in contrast to the world of cell carriers).  In short, VOIP is most likely the future of all calling, though the cell carriers will do their damnedest to delay this inevitability as long as possible.

As an Android user and VOIP fanatic, intrigued by the possibilities of combining cell and VOIP for the ultimate voice connectivity, I am constantly fiddling with my phone settings, and trying what most would consider to be "experimental" configurations.  Besides my usual cell phone number and contract, I have had at least the following VOIP connections configured on my phone in one form or another, since I got my first Android phone 2 years ago:
  • SIP connection to a cloud hosted PBX (PBXes.org)
  • Google Voice via Groove IP app (VOIP over Google Talk/Jabber/XMPP protocol)
  • SIP connection to my home Asterisk box server 
  • SIP connection to various other Asterisk boxes, such as those built for clients, test and demo units, etc.
  • Maybe some other stuff that I am forgetting
On Froyo and earlier, I used to use a third party SIP client (namely Sipdroid), as that was the only option.  I remember when Gingerbread came out and had native SIP support.  I was rather excited about that, since it meant two things:

  • As a memory starved OG Moto Droid owner, I was hopeful that this might offer a way to support my SIP habit without having to keep a 3rd party app running background all the time.  It also would be a little more elegant/less clunky.
  • Obviously this was a step forward for the VOIP world, if Google felt it was worthy enough to build it into the OS.
So since Gingerbread came out, I have been using the native SIP client on some level.  It's always worked pretty well, albeit with some reduced functionality and configurability (without getting into too many specifics right now), but simpler is sometimes better anyway.   All of this worked pretty well, on my OG Moto Droid running Gingerbread.  My phone would connect automatically to my home asterisk box when I got home, so I could use my phone like a cordless extension.  When I was away, the local IP address would be unreachable, and it would automatically disconnect.  I also had my work number through PBXes.org, and I had configured SIPdroid to connect to that.

Over the last few months, some things have changed.
  1. I switched to GrooveIP exclusively for my work number
  2. I decided to stop using a 3rd party SIP clients
  3. I moved our home number to the PBXes.org cloud PBX
  4. I got a Galaxy Nexus running Ice Cream Sandwich
I'm not sure about the exact order in which all of this stuff happened.  I had about a month or so of good time with my new GNex, but at some point, this is what I started having:


That's my phone chewing through over half the battery life in under 4 hours.  The only information I could get from the phone about why this was happening:


"Android OS".   Not very helpful.  After searching, searching, searching, online, I only found that other people were complaining about the same exact thing, and that this appears to be referred to in the singular as "the ICS battery bug/issue".  So that's what I had to work with.  With many different apps that are part of my regular Android setup, finding the culprit was like looking for a needle in a haystack.  The only other clue I had was this:


On Wi-Fi, the battery consumption was much BETTER, even normal(-ish).  At least what I would consider normal for a modern, powerful phone.

I spent the next month or more trucking around my charger and 2 spare batteries just to keep my phone running while I was traveling.  The phone would get extremely hot in my pocket, to the point where it was uncomfortable to even keep it there!

I decided that I wanted to unlock & root my phone, and install Codename Android (a highly customizable ROM for the Galaxy Nexus).  My reasoning was varied, but mainly I got tired of waiting around for updates. To my knowledge, Verizon still hasn't issue an update from 4.0.2, which has an NFC tag formatting bug, and some other known problems.  Having a custom ROM that is updated often gave me occasion to format my phone on a fairly regular basis.  I noticed the problem came back after I formatted and installed the latest version of ICS (4.0.3).  After a couple more tries, I eventually broke up the initial setup of all my config and apps into 3 or 4 parts.  Between each part, I would give it a rest and see if it had the issue. By process of elimination, I found out that it wasn't any of my apps at all that triggered this problem, it was my configuration of the native SIP client in ICS.  Furthermore, it was the native SIP client's connection to PBXes.org, which is maintained regardless of whether I am at home or away, connected to Wi-Fi or not (cloud connection).

Before I go any further, I should point out that I DID check the box that reads "receive incoming calls (reduces battery life)", so I suppose I asked for it on some level.  Also, I guess someone could also point out that it really was "Android OS" that was consuming all this battery life, so the chart wasn't lying.  However, I'll point out that this is not the first time I have configured my Android phone this way, and I never witnessed this issue when I was running 3rd party SIP clients.

So to wrap it up, I have reached the following conclusions:

  • Something about ICS uses a ton of power (at least as compared to 3rd party SIP clients) when the native SIP client is maintaining a connection over 3G/4G, but not when using Wi-Fi.  
  • Google really needs to break up the Android OS category in the battery usage report a little bit, so that users can see whether/which something that they have control over is consuming battery %.  There are lot of other people trying to figure out what the heck in this category is causing their problem, and it's causing a tough PR issue for ICS.
  • There really should be an option in the native SIP client config not to connect over 3G/4G
  • SIP was not designed to be used over 3G/4G data connections.  It is a busy protocol, sending keep-alive packets every 30 seconds or so, constantly using the radio and keeping the phone awake, even when there is no call going on.  The future of mobile VOIP will not necessarily be based on SIP/RTP (and probably won't be).


I am back to running a 3rd party SIP client, CSIPSimple, and excellent and highly configurable SIP client that allows me to better control when it connects to my cloud PBX.  Since then, my battery life is back to "normal".  On an average day, I use my phone 10-14 hours and I still have at least 25% battery left when I put it on charge for the night.



One more conclusion I reached: the world of mobile VOIP still seems to be in its infancy, as I could not find one other report of someone connecting the infamous "ICS battery bug" to this issue.  If a lot of people were using the native SIP client in Android, I would think this information would have been much more accessible.


Comments

Anonymous said…
SIP over TCP is significantly more battery friendly than over UDP. That's because the keep-alive interval over TCP can be increased to 15 minutes (yes, minutes) or more vs 30 seconds or less for UDP.

The reason for that is that keep-alives are used to keep NAT entries nailed up in the wifi router or the mobile network, and TCP NAT entry timeouts are usually much, much higher than for UDP. That's why sipdroid uses TCP to connect with pbxes.org. And why anyone who can use TCP (most VOIP providers do NOT support TCP) should.
John said…
I gave up on the VZW Galaxy Nexus for this problem but associated it to LTE. I have the exact same native sip setup on the GSM Gnex using T-Mobile's HSPA+ network without nearly the battery hit - except I just realized I never receive calls via their network it seems. This despite the "receive calls" box being checked. Is it likely transport via UDP is being blocked on their network? On Verizon this was definitely not a problem...
John said…
I gave up on the VZW Galaxy Nexus for this problem but associated it to LTE. I have the exact same native sip setup on the GSM Gnex using T-Mobile's HSPA+ network without nearly the battery hit - except I just realized I never receive calls via their network it seems. This despite the "receive calls" box being checked. Is it likely transport via UDP is being blocked on their network? On Verizon this was definitely not a problem...
Thomas said…
Wholeheartedly agree with this:

* There really should be an option in the native SIP client config not to connect over 3G/4G
Scott McGrath said…
Running Jelly Bean 4.1.2 and there is still no such option. I do see that I can set the transport to TCP. At some point I'll have to do a test and see if that reduces battery consumption.

In the meantime, running CSipSimple and loving it. Note that I did have to go into the Android settings for WiFi->Advanced and change "Keep Wi-Fi on during sleep" to "Always", or else I wouldn't get calls when the screen was off. I haven't noticed any significant additional battery drain with this setting enabled.
Anonymous said…
Excellent post and wonderful blog, I really like this type of interesting articles keep it up.
Phone System
Unknown said…
Most people turn to VOIP because of the savings available. Top VoIP Provider offers a great combination of features such as Caller ID, Call Waiting, 3-way Calling, free domestic calls and extremely inexpensive international calling rates. For all this you will normally be charged from $19.95 to $34.95. An additional charge, of course, is for your ISP which probably runs about $40 monthly for broadband access. Even ISP and VOIP together is still likely to be cheaper, however, than continuing with a conventional phone company. This may not be true, however, if you also change your cell phone to VOIP.

Popular posts from this blog

Reaper, Linux, and the Behringer X-Air - Complete Studio Solution, Part 1

Introduction and Rationale This is part one of a major effort to document my experiences with recreating my home studio, entirely using Linux.  Without getting into too many of the specifics, a few months ago I decided that I was unhappy with Windows' shenanigans - to the point that I was ready to make a serious attempt to leave it behind.  For most in this situation, the obvious choice is to switch to Mac OS.  With its proven track record, support, and options for multimedia production, it is naturally the first alternative to consider if your goal is to simply use something other than Windows. For me the choice was not so simple. I despise Mac OS and, in general, the goals and philosophies put forth by Apple in an effort to ostensibly provide users with an "easy" working environment.  It does not help that I have also failed to find any aspect of the Mac OS UI intuitive, but I realize that this is a subjective matter. With my IT background and user-control* f...

An Alternative Take on AI Doom and Gloom

 I've purposely held my tongue until now on commenting about "AI" (or, more specifically as has come to be known, GAN or Generative Adversarial Networks).  It seems like it is very in-style to complain about how it has made a real mess of things, it is displacing jobs, the product it creates lacks soul, it's going to get smart and kill us all, etc. etc.  But I'm not here to do any of that. Rather I am going to remind everyone of how amazing a phenomenon it is to watch a disruptive technology becoming democratized From the time of its (seeming) introduction to the public at large, around November of 2022, to late 2023, the growth and adoption rate has been nothing short of explosive. It features the fastest adoption rate of any new technology ever, by a broad margin.  To give a reference, the adoption rate for AI image and text generation, real-world uses, in just 12 months is comparable to all of that of the another disruptive technology, the World Wide Web, takin...

RANT TIME: Why do replies to a message I sent go to my spam folder?

Despite what one would think/hope, sending a message to a given address does not inherently give Google a high confidence that a reply from this address is expected (and, for example, that it should bypass spam checks). I have confirmed with Google's tech support that there is no way to automatically have this happen. The user can do the following: 1. Add the address to your contacts list in Gmail. 2. Check spam folder for replies, and mark it as "not spam" if something ends up there, which should influence the fate of future replies received. I can also approve an address at the domain level, i.e. if it is a big vendor or similar. I've had to do this with several of our Chinese vendors. I regularly ask engineering and purchasing to give me a list of the supplies we deal with, so I can approve them as a preventative measure. For what it's worth, all of the false positive instances of reply -> spam we have experienced have involved the sender's email server ...