Battery consumption

[GoogleCodeExporter]

Maybe this issue is too vague to register as a "defect" but as there is no 
discussion forum for CSipSimple, here goes:

I was using Sipdroid for a while, but I strongly dislike their UI decisions so 
I am trying alternative SIP agents. I actually talk very little, maybe a few 
minutes per day but I have SIP agent registered at all times when under WiFi 
coverage. When I run Sipdroid, by the end of the day I have battery indicator 
at about 50%. When I run CSipSimple instead, with all other activities 
basically the same, by the end of the day the battery indicator is yellow or 
even red (< 20% I think).

This issue and loosing registration (issue #67 comment #4) are two things that 
makes this program less acceptable to me than Sipdroid. Otherwise, I am happy 
with the UI and satisfied with stability.

HTC Desire, Android 2.1, CSipSimple pre5.

Original issue reported on code.google.com by egcros...@gmail.com on 10 Jul 2010 at 10:13

[GoogleCodeExporter]

You're right, for now absolutely no optimization has be done to reduce battery 
consumption. (The app is still in alpha phase).

But there is things you can already modify in settings that will reduce battery 
usage:

* In the account settings (using expert wizard), change the keep alive interval 
to 40 for example instead of 15. This is the default value in 0.00-12, so if 
you are using 0.00-12 nothing has to be done on this point. It will reduce by 3 
the amount of packets sent to the sip server.
* In global settings > network settings, you can disable the Lock Wifi option. 
This option ensure wifi is always on, if you want to be sure to receive your 
calls. This option is probably turned off by default in SipDroid for example. 
Activating this option drain the battery but ensure you will receive all your 
calls if you are not authorized to use your 3G connection to receive/make calls.
* If you don't matter receiving your SIP calls and want to use it only for 
outgoing calls, CSipSimple provide a good option for that. In global settings > 
network settings, you can uncheck both wifi and 3G for incoming calls.
In this case, CSipSimple will launch itself ONLY when you want to place a call 
and you will save a lot of battery (highly better than sipdroid that frequently 
try to register or check if no registration is possible).

I've in my mind some improvements that will allow to save a lot of battery.

For issue #67 comment 2, 3 and 4, it's probably a display issue, I will work on 
it soon.

Original comment by r3gis...@gmail.com on 14 Jul 2010 at 9:40

• Changed state: Accepted
• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

For me personally, it is important to have it registered at all times (under 
WiFi). I have "register when on WiFi", and "outgoing/incoming calls when on 
WiFi", and I do _not_ have "Lock WiFi". The latter does _not_ impede incoming 
calls, and in fact I think I am not seeing diverted incoming calls since 0.12.

I have a feeling that battery use became a little better in 0.12 but it's 
within the margin of error, and may be just false impression.

I'll comment on #67 there.

Original comment by egcros...@gmail.com on 14 Jul 2010 at 10:34

[GoogleCodeExporter]

I (idly) wonder if it would be possible to get away *without* holding 
PARTIAL_WAKE_LOCK. For re-registrations, be waken up by timed events, for 
answering calls, rely on being woken up by incoming unicast packet. I am not 
sure if the latter needs any special setup to work.

Original comment by egcros...@gmail.com on 26 Jul 2010 at 4:57

[GoogleCodeExporter]

I don't think so.
For re-registration, it's possible yes. You can use timed events (known as 
"alarm" events in android -- see 
http://developer.android.com/intl/fr/reference/android/app/AlarmManager.html). 
Theses events are raised even if the phone is in the deep sleep mode (CPU off).

*But* for answering calls I think it is not possible :
In fact when CPU is in deep sleep mode, application can't treat network packets 
:
The CPU scheduler never give the token to android applications in this mode. 
Some application (especially IM ones) pool (using alarms) to be sure there is 
no new message to treat, but this method doesn't match what we want with a 
telephony application. (Can be tested but not sure will be really good).

I know that iphone has such a feature with their new "multitask" os... (Note 
the quotes ;) ). I mean, the API enable to declare "multitask" sockets and when 
there is activities on theses sockets, there is a wake up of the system. Btw, 
that's really complicated to implement (all the more so as you try to use a 
cross plateform sip stack). Maybe one day such a feature will be allowed in the 
android sdk. 

Original comment by r3gis...@gmail.com on 26 Jul 2010 at 4:21

[GoogleCodeExporter]

Interesting. I did this experiment: I stopped cSipSimple, (and anything that 
might use PARTIAL_WAKE_LOCK), verified that mPartialCount=0, unplugged it from 
USB, ran ping against it and turned it off by power button. By all reasons, the 
CPU must have been turned off. However, it continued to respond to ping 
(although with bigger delay due to PSP mode). This means that CPU did run 
"enough" to respond to ICMP echo requests. It is the kernel IP stack that sends 
echo reply packets, CPU must run to have them sent. This apparently supports my 
theory that when a packet is received by the WiFi adapter it wakes up the CPU.

What I did not check in this test is whether userspace processes will be 
dispatched, but from what I did observe, it seems worth a try to check if the 
app will work without constantly holding PARTIAL_WAKE_LOCK, does it?

I would try it myself but I have trouble building the package from source 
("[exec] /export/src/csipsimple/CSipSimple/AndroidManifest.xml:2: error: No 
resource identifier found for attribute 'installLocation' in package 'android'" 
when I try "ant debug")

Original comment by egcros...@gmail.com on 28 Jul 2010 at 9:06

[GoogleCodeExporter]

OK, I was able to check my theory. I commented out the lines that create and 
acquire PARTIAL_WAKE_LOCK (in SipService.java around the line 780), rebuilt the 
package, ran it, verified that mPartialCount was still zero while the app was 
running, unplugged USB, turned it off via power button, and made a call to the 
device.

And it worked!

Now, *maybe* it's still a good idea to get the lock for the duration of 
re-registration process, but for the rest of the time, it seems unneeded. And 
by not holding it all the time we maybe can save some battery juice. Do you 
think you should try?

Original comment by egcros...@gmail.com on 28 Jul 2010 at 9:32

[GoogleCodeExporter]

just want to share that I made the same experience as egcrosser, battery life 
seems to be greater on sipdroid. I know it's alpha and am looking forward for 
changes.

bear in mind that sipdroid claims battery life is improved when using a PBX 
service like sipdroid's own PBXES.org. Now I don't know, but I use two sip 
accounts (one incoming, one outgoing) which are handled by PBX. With CsipSimple 
I just added both accounts. this could decrease battery life...

(sure, I could use PBX with CsipSimple... just fruit for thought)

Original comment by alessand...@gmail.com on 28 Jul 2010 at 9:49

[GoogleCodeExporter]

Well the case for using pbxes to save battery life is to use a TCP connection 
to pbxes with a high keep-alive time since most NATs keep TCP connections open 
for a lot longer then UDP connections. This means the radio does not need to 
transmit data as often and thus saving battery life.

So if you have a provider or a server that supports TCP then you can use this 
directly with CSipSimple if not then unfortunately pbxes does not seem to work 
using TCP with the pjsip stack (or at least I have not gotten the combination 
to work as expected - see comments in bug 50). There are other options such as 
sipsorcery which work though.

But the PARTIAL_WAKE_LOCK is very interesting as this in connection with TCP 
might lead to improvements. Personally I think battery life is one of the most 
important issues that still needs to be solved.

Original comment by michael....@gmail.com on 28 Jul 2010 at 10:02

[GoogleCodeExporter]

Yes really interesting test egcrosser !

Really worth to be tried. At least in a first time as an option. 
Since, we are still in the alpha phase it's probably worth to test to disable 
the partial wake lock by default, we'll get more feedback on it.
I take the point to integrate this one in the next build.

This point can be dependant from the device. In fact my assumption (that 
partial wake lock was necessary) was based on test on a Archos 5IT. But this 
device has some special sleep policies : for example it can goes in an 
"hibernate" mode. 
So probably the final choice , as for other tweaky params, will be to find out 
at the first run what is the device we are running on, and setting the best 
configuration for this device.

Original comment by r3gis...@gmail.com on 28 Jul 2010 at 10:25

[GoogleCodeExporter]

+1 for a build without partial wake lock. Any thoughts on getting some 
"creative inspiration" from a certain other open source SIP project as to how 
they're avoiding this?

Original comment by nnsl...@gmail.com on 29 Jul 2010 at 6:02

[GoogleCodeExporter]

Sipdroid use a partial wake lock as far as I know (not read all the code but 
sounds there is somewhere in registration process where a partial wake lock is 
put down). Not read how Linphone manage this point.

But to be sure, we should test it ourself. Since csipsimple runs as a native 
library, maybe behavior is different regarding cpu policy. And there is things 
really strange in Sipdroid (such as alarms that launch portion of code to check 
if network is present instead of relying only on network events... maybe there 
is a reason for that but as I don't know why...)

Original comment by r3gis...@gmail.com on 29 Jul 2010 at 7:47

[GoogleCodeExporter]

> alarms that launch portion of code to check if network
> is present instead of relying only on network events...

I don't know if this is related, but there is a problem in an XMPP client 
(Beem) when it, for unknown reason, miss some of connection/disconnection 
events.

That said, cSipSimple always disconnects and reconnects reliably for me.

Original comment by egcros...@gmail.com on 29 Jul 2010 at 7:56

[GoogleCodeExporter]

Another thought how to minimize energy consumption: there is no need to 
re-register so often. SIP protocol suggests that you register as often as the 
registrar tell it. I think the typical value is several minutes.

Now, when the device is behind NAT (almost always), it is necessary to 
periodically refresh the relation, usually you need to do it more frequently. 
For that, you can use "empty" SIP messages, i.e. just a single CRLF, without 
headers and body. They are just ignored by the server, no answer is sent, so 
they are in every aspect cheaper than re-registrations.

I once owned a hardware SIP phone that used this approach.

Original comment by egcros...@gmail.com on 29 Jul 2010 at 8:17

[GoogleCodeExporter]

Reporting success :-)

Since the app has an option to disable PARTIAL_WAKE_LOCK, I am running in this 
mode and battery usage has noticeably improved. I think it is now in line with 
or better than what I had when I ran Sipdroid.

However, it feels(!) like the device is not registered (or not responding to 
calls) more often then before, and sometimes I see the "Sip registered" notice 
the instant I turn it on. This is not conclusive, as I also upgraded to FroYo 
at the same time, and the the difference is not very significant even if it 
exists.

Anyway, I have a theory why this *might* happen: when you re-register in the 
background, you are not obtaining PARTIAL_WAKE_LOCK for the duration of this 
process. So, if registration cannot complete in 10 seconds (due to packet loss 
in the network or whatever), the system shuts down the CPU and registration 
retries no longer happen until CPU is woken up for some unrelated reason. Then 
retry (usually) succeeds and things are all right. But while it was sleeping, 
the server thinks that the device is not registered and do not send invites to 
it.

I am not sure if my theory has merit. But even if not, it seems a Right Thing 
to obtain PARTIAL_WAKE_LOCK at the moment when you are woken for 
re-registration and release it at the moment when re-registration succeeds or 
you decide to give up and fail. What do you think?

Thanks!

Original comment by egcros...@gmail.com on 14 Aug 2010 at 9:11

[GoogleCodeExporter]

Re-registration is done by the native library. So it doesn't acquire any lock 
on the android system. But my think is that it's not linked to CPU if it 
automatically re-register when you turn on the screen. If when you turn on the 
screen it re-register, it means that network comes up (and this made csipsimple 
re-register).

If you are only on wifi, you might try to activate the *lock wifi option* (in 
network settings). Maybe (that's just a though), since Partial wake lock is not 
activated anymore, wifi consider it can goes in sleeping mode (disconnect 
itself or psp mode ? ).
So maybe worth to test with lock wifi option activated.

I can also try to use alarms methods that temporarily lock cpu each time 
re-registration should be done. But obviously if re-registration fails, it 
means that incoming call should also fails and alarm will not solve issue for 
incoming calls.

Original comment by r3gis...@gmail.com on 14 Aug 2010 at 10:27

[GoogleCodeExporter]

> If when you turn on the screen it re-register, it means that network comes up 
(and this made csipsimple re-register).

No, I don't think so. I have wifi sleep policy set to "sleep never" in WiFi 
Settings -> Advanced. And it registers really fast when I press power, 
establishing WiFi connection takes much longer.

As I said, the situation happens rather rarely, and if your theory was right it 
would happen to me every time the device goes to sleep for more than 15 minutes.

I wonder if it would be possible to initiate re-registration "by hand" from an 
android alarm handler instead of relying on pjsip's internal mechanism... Just 
a thought.

> But obviously if re-registration fails, it means that incoming call should 
also fails and alarm will not solve issue for incoming calls.

Obviously. My point is, *maybe* sometimes retrying process gets "frozen" when 
it takes more than 10 seconds, and we have it "would have succeeded after a 
retry but did not have a chance".

As I said, it's all speculation and not a proven theory.

Original comment by egcros...@gmail.com on 14 Aug 2010 at 12:50

[GoogleCodeExporter]

Original comment by r3gis...@gmail.com on 8 Sep 2010 at 6:55

• Changed title: Battery consumption

[GoogleCodeExporter]

Issue 204 has been merged into this issue.

Original comment by r3gis...@gmail.com on 8 Sep 2010 at 7:00

[GoogleCodeExporter]

I'm also looking forward for having a version of CSipSimple with 
PARTIAL_WAKE_LOCK being disabled to save my battery life.

It's very important to me for having a battery friendly client.

Thank you very much for creating and maintaining a great client.

Original comment by huan...@gmail.com on 13 Sep 2010 at 5:38

[GoogleCodeExporter]

Commenter 19, you can enable or disable the use of PARTIAL_WAKE_LOCK under 
Settings -> User Interface (in the dev. versions from the website, not in the 
market version).

Original comment by egcros...@gmail.com on 13 Sep 2010 at 5:43

[GoogleCodeExporter]

Thank you egcrosser for letting me know. I'm using the dev version right now 
and I will report back the results.

Original comment by huan...@gmail.com on 13 Sep 2010 at 6:00

[GoogleCodeExporter]

I have found by setting the Reregister to 184 and Keep Alive to 100 (obtained 
by looking at SipDroid source), I can turn off Partial Wake Lock and not miss 
any calls on my Nexus 2.2 - 3g or wifi.

I am curious if others experience the same serendipity.

Original comment by kro...@gmail.com on 23 Sep 2010 at 11:37

[GoogleCodeExporter]

@krolaw, when you say "reregister" do you mean the "Register Timeout" setting? 
I've tried setting that to 184, and Keep Alive to 100 as you suggest, it still 
seems to only work intermittently.

Original comment by nnsl...@gmail.com on 27 Oct 2010 at 2:09

[GoogleCodeExporter]

Strange (works for me ;-) ).  Wifi or 3G?  If Wifi, make sure it is set to 
never sleep in system settings.  Are you using a Nexus?  Although it might be 
more network related as it works on a G1...

Original comment by kro...@gmail.com on 27 Oct 2010 at 2:48

[GoogleCodeExporter]

I am just starting to do some tests with CSIP and so far I configured a 
sipsorcery account with UDP connection and a timeout of 3600s and a keepalive 
interval of 120s and I receive calls and battery life seems to perform well. 

Original comment by tobias.p...@gmail.com on 30 Oct 2010 at 9:15

[GoogleCodeExporter]

@tobias, what network are you on? tmo, verizon, sprint? Who is the VOIP 
provider behind sipsorcery? Also, how is the call quality with sipsorcery?

@krolaw, I have an EVO on sprint, and the symptoms for me are the same on wifi 
(no sleep), and 3G (always available). The only way I can get calls 
consistently is to use partial wake lock.

I have a sipsorcery account, so I may try funneling my SIP traffic through 
them, and see what happens.

Original comment by nnsl...@gmail.com on 3 Nov 2010 at 7:10

[GoogleCodeExporter]

Wow, it works great with SipSorcery. Thanks @tobias for (a) reminding me I have 
a SipSorcery account, and (b) the great idea to use it. Works great now!

Original comment by nnsl...@gmail.com on 4 Nov 2010 at 12:30

[GoogleCodeExporter]

I noticed that if my SIP server is down and the phone can't connect, battery 
comsumption goes through the roof.  Otherwise it seems fine to me.

Original comment by presslab...@gmail.com on 8 Nov 2010 at 8:16

[GoogleCodeExporter]

Here's something interesting: I noticed that my airplane mode is a lot more 
power-hungry and I suspect cSipSimple, as it's the only new bit of software 
since this started happening.  Funny thing is, in the Market version, I have 
"use partial wakelock" unchecked, and Lock WiFi unchecked already.

One thing I'm experimenting with now: I disabled Incoming WiFi so that the 
client doesn't try to register outside of periods I manually launch it, until I 
later quit it.  (Works great, that's the setting I was looking for!)  Even if I 
use System Panel to kill it after I quit it, I notice it reappears in my 
process list shortly after (like the annoying Amazon MP3).  I would've expected 
it not to be restarted at all when configured that way.  Is this normal or am I 
missing an extra setting to disable that?

Original comment by vphan...@gmail.com on 28 Nov 2010 at 4:45

[GoogleCodeExporter]

Yes it's normal that it appear in application list. Most of users are afraid 
about apps that appear in application list.
But actually that's harmless :
Android manage its own memory by it's own way. As CSipSimple potentially listen 
for network changes event (even if it actually does nothing if your 
configuration is set too), android put things in RAM memory and the app does 
absolutely nothing in background.

Those "auto-kill apps" are a really useless thing for android 2.0 and upper. 
And even worse sometimes if set to auto-kill these apps can drain the battery 
cause just try to umount things in memory and then android automatically 
restart the apps and it loop infinitely...

I'm not alone to say that great android gurus (the ones that code the android 
OS), try to explain this ... but unfortunately users still use this task 
manager apps in auto-kill mode.
You should for example read that :
http://blog.radioactiveyak.com/2010/05/when-to-include-exit-button-in-android.ht
ml
http://androidspin.com/2010/05/25/why-you-dont-need-a-task-killer-app-with-andro
id/
http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

And so on...

Besides I'd like to add that in development version there is a more user 
friendly way to quit the app.
However it doesn't mean that it will disappear from task list. Just that it 
will do nothing. But appearing in the task list doesn't mean that it consume 
resources... even better sometimes it means that the application will consume 
less resources when waked up back.
You can compare that to the "suspend/hibernate" mode of a PC. It just freeze 
everything in memory to be able to wake up things quickly. And here in our 
case, it's managed by the Android OS system. it's not up to the developer to 
deal with that.

Original comment by r3gis...@gmail.com on 28 Nov 2010 at 5:18

[GoogleCodeExporter]

I'm not a developer nor an expert so maybe i'm going to say a very stupid 
thing! :)
To save battery and also receive incoming calls can you use google's push 
tecnology (C2DM) introduced with froyo? I noticed that application that use it 
don't waste battery at all, but are able to provide notifications very quickly. 
Examples of them are google's gmail app, google calendar, Chrome to phone, 
WhatsApp (it works great!), K9 mail client (not sure but i think so), BeeJive 
IM, ...
It's just a suggestion based on what i've seen until now, i don't know if it is 
really possible

Original comment by alekse...@gmail.com on 2 Dec 2010 at 3:27

[GoogleCodeExporter]

To comment 31:

1. To "notice" C2DM events the handset needs to be connected to Internet at all 
times, this is not substantially different from being registered directly with 
a SIP server. There is no magic here that could dramatically decrease the power 
consumption.

2. To "notice" incoming INVITEs, some sort of proxy will need to run somewhere 
"in the cloud", registered with the SIP provider, and producing C2DM notices 
when it receives an INVITE. This would make the system prohibitively 
complicated, compared to the device directly talking to the service provider as 
it normally does.

3. The delay of C2DM delivery is at times much longer than an average person is 
prepared to wait for her call to be answered.

Original comment by egcros...@gmail.com on 2 Dec 2010 at 4:00

[GoogleCodeExporter]

A follow-up on my comment #29 above.  Now that I disabled Incoming WiFi, I can 
confirm that my Airplane Mode battery consumption is back to its normal 
4-5%/day, so that seems to have been the cause for me.  (Nexus One, by the 
way.)  Luckily I prefer to manually activate my SIP client during periods when 
I make myself available, so I want Incoming WiFi to be off anyway. Problem 
solved for me. :)

Bottom line, whatever monitoring Incoming WiFi incurs, is consuming a bit of 
battery power during Airplane Mode; perhaps Airplane Mode itself could be 
detected to further reduce the amount of work cSipSimple does during that time? 
 Just a thought, I'm already quite happy with how things are now that I found 
this tweak.

Original comment by vphan...@gmail.com on 2 Dec 2010 at 5:29

[GoogleCodeExporter]

To r3gis.3R and egcrosser regarding PARTIAL_WAKE_LOCK usage:

My understanding is that receipt of a network packet over an active interface 
(e.g. non-sleeping wifi) while the phone is sleeping will generate a CPU 
interrupt which will wake the CPU for a fixed small period of time (fraction of 
a second).  If the processing triggered by the packet requires more time to 
complete, the application should obtain a partial wake lock when processing 
starts and release it when processing finishes.  This explains why pinging the 
phone works when it's sleeping, and also implies that SIP applications should 
be obtaining and releasing wake locks dynamically, not holding them forever.  
I'd expect this change to result in much lower battery consumption without 
sacrificing incoming call reliability.

Original comment by fander...@gmail.com on 5 Dec 2010 at 2:03

[GoogleCodeExporter]

fanderay4, every I/O event generates an interrupt. The point is, when the CPU 
is switched off, it cannot process interrupts. However, when the network chip 
receives a unicast packet it generates a special signal (in addition to the 
interrupt) that switches the CPU on. Then the CPU handles the interrupt, and 
the kernel dispatches any application that might be waiting for this packet. 
The OS gives this application fixed time (10 seconds if I remember correctly) 
to run, and then switches the CPU off again. If the application decides that it 
needs to run longer to do its job, it must obtain any of WAKE_LOCKs before the 
10 second interval expires. And this is how csipsimple works (unless you check 
the "Use partial wake lock" checkbox in the settings, in which case it will 
keep the lock all the time).

Original comment by egcros...@gmail.com on 5 Dec 2010 at 8:51

[GoogleCodeExporter]

Thanks for the clarification egcrosser.  If that's true then I don't see why 
the "Use partial wake lock" setting should ever be needed, and yet when I 
disable it, I permanently lose registration...

Original comment by fander...@gmail.com on 5 Dec 2010 at 9:14

[GoogleCodeExporter]

fanderay4, some combinations of hardware/OS version are known to have a bug: 
the radio chip it programmed improperly and does not wake up the CPU on 
incoming packets. I don't remember the number off the top of my head, you might 
try to look it up in android bugs section. If this is indeed your problem then 
you need to either upgrade the OS or "Use partial wake lock".

Original comment by egcros...@gmail.com on 5 Dec 2010 at 9:26

[GoogleCodeExporter]

I use wifi only (sleep policy set to Never) with an HTC Wildfire running 
CyanogenMod 6.1-RC.  The only problem I'm aware of is 
<http://code.google.com/p/cyanogenmod/issues/detail?id=2403> which I knew to be 
responsible for having to set the "Stay awake during call" workaround option.  
I guess that's the culprit in this case too.

Original comment by fander...@gmail.com on 5 Dec 2010 at 9:54

[GoogleCodeExporter]

+1 for egcrosser comment. 

However there is still something that is still open and has to be explored : 
Actually, for incoming packet CSipSimple works the way you explained (if there 
is an incoming INVITE, csipsimple took a wake lock (however could be done more 
lower in pjsip sip stack but would be not easy to maintain (and probably not 
needed at all).

On the other side, CSipSimple tries to keep the UDP (or TCP) connection alive. 
To do so, it send (actually pjsip sends) packets every 'keep-alive interval' 
time. This is done inside the native library and no wake lock is done on this 
part. So if your sip server is not talkative, and supposing CPU is turned off 
by the OS, nothing will wake up pjsip threads to send the keep alive. (-- but 
that's not clear, as the thread is not registered by the dalvik JVM, I'm not 
sure at all of that --).
This is needed only if your carrier routers (or IP provider) cuts a connection 
without any traffic. 

A solution could be to use Alarms from android SDK ( 
http://developer.android.com/reference/android/app/AlarmManager.html ). But 
problem is to get that synchronized with the pjsip native stack on which we 
rely. In a first time could be an awful hack available as an option 
(intermediate to Lock CPU and no lock CPU).

This is a really tricky point to handle, all the more so as all devices doesn't 
manage things the same way, that all routers equipments doesn't behaves 
identically and that some sip servers are more talkative than others (some send 
frequent Notify which could be a solution). So to get something that works 
perfectly in all case and consume the optimal battery is really hard and should 
be thought as a background task (that I actually keep in mind but not top most 
priority for now) (reason why this issue is marked as task. If anybody wants to 
have a really close look to the issue and propose patches it will be welcome. 
;).

Original comment by r3gis...@gmail.com on 5 Dec 2010 at 9:58

[GoogleCodeExporter]

Question: Which is better on battery life for the Android phone: A server that 
is talkative and sends keep alive packets every X seconds, or for the phone to 
send the keep alive packets every x seconds?

Or are they equal?  Thanks

Original comment by mcampbel...@gmail.com on 6 Dec 2010 at 6:58

[GoogleCodeExporter]

r3gis,
regarding re-registration from inside pjsip, do you happen to know how they are 
woken up to do the job at particular time? If they use Android's alarm manager, 
maybe getting and releasing the lock could be done in the "outer" Java part of 
the event handler?

If they are using unix alarm(2), then theoretically, it should be pjsip's job 
to obtain the lock for the duration of the registration process. As pjsip code 
would not want to deal with Java interfaces directly, maybe they could be 
persuaded to invoke caller-supplied callbacks before and after re-registration. 
Then csipsimple could provide such callbacks, in which the lock will be 
obtained and released.

Or maybe my speculation is completely off the point. In that case, just 
disregard it.

Also, I must tell that for me, the app works very stable recently. 
"Unexplained" loss of registration happens sometimes, but very seldom. I would 
not even be able to test a possible solution because problem is so rare.

Original comment by egcros...@gmail.com on 6 Dec 2010 at 7:34

[GoogleCodeExporter]

@mark : it depends on implementation on the phone. For now csipsimple is most 
friendly with the talkative server approach (but server should send it with a 
not so high frequency to not drain the battery. However in the absolute the 
best approach is to let the client to be talkative : it may allow the client to 
detect it's own network type and adapt frequency of it's ka packets to the 
network type. On the other side, if we assume a alarm implementation, I'm not 
enough an expert to say whether alarm or waiting network socket is the best 
approach in term of battery usage.
What I can say is that if both server and client try to send keep alive packets 
one of the two are useless. (Most of the time in this case we'd like client to 
be silent). And also that if server send keep alive most of the time it's 
through a NOTIFY so it's a little bit heavier to process that a client packet 
(just a \r\n).

@egcrosser : Yes indeed could be integrated with pjsip. I've to check that but 
maybe could be done in the os_android.c port : it's the implementation some 
stuff for android regarding threading and scheduling, so could be managed 
safely and cleanly here, even if we need to talk to the java part. (That's 
already the case for the audio driver which is a separate source file). 
So worth to explore this approach. But I'll have to really focus on that and 
only that when I'll do this work :) For now too much other side things to do ;).

Original comment by r3gis...@gmail.com on 6 Dec 2010 at 8:04

[GoogleCodeExporter]

I am also experiencing high battery drain with cSipSimple on a custom Androd on 
HTC HD2. This is probably unsupported but the drain is normal (5-10mA) without 
cSipSimple registered. I use Battery Monitor Widget to monitor the devices 
battery usage.

Currently I have cSipSimple configured with a PBXes account over TCP with 
keep-alive set at 100 and register interval set at 1800. As long as cSipSimple 
is registered, battery drain is in the ~150mA vicinity. This translates to 
about 12%/hour with the screen off and me not using the phone.

Original comment by m...@mykohsu.com on 26 Dec 2010 at 6:42

[GoogleCodeExporter]

Update to comment 43: I disabled all incoming data for cSipSimple (WIFI, 3G, 
etc) and disconnected. After letting it settle down to 5mA draw for a few 
minutes, I re-enabled the incoming data from easy settings and so far it is 
still at 5mA draw. Going to keep monitoring this.

Original comment by m...@mykohsu.com on 26 Dec 2010 at 7:05

[GoogleCodeExporter]

@nlm : are you configured to be "always available" over wifi only? 
If so be aware of the fact that in this mode CSipSimple try to ensure that wifi 
is running which drain the battery (but if you want to be always available and 
use only wifi for that, that's the only solution, no miracle can be done ;) ).

I think that if you go in android device infos (android settings > about phone 
> battery usage) and have a look to what is consuming battery, you'll not find 
csipsimple but wifi as first entry.

A good compromise is to choose "available on wifi" (which keep your wifi policy 
- I assume when screen is on). Or if you don't mind to receive calls, "only for 
outgoing".

You can also try latest trunk version in which I've a little bit improves 
things regarding cpu consumption, but I don't think that it will help a lot, 
12%/hour is really really high (I never have that on my phone except on the 
galaxy S when there were a wifi bug on the ROM I used). 

Usually on my phones when 1%/hour is without csipsimple always running and 
activated I get 3-4%/hour when activated and locking wifi.
However if the wifi driver of your phone doesn't behaves correctly (which 
happened once on a ROM on my GalaxyS) it can increase a lot when wifi is locked 
by the app.

Just FYI, pbxes.org doesn't actually support very well TCP : they do not 
respect SIP RFC, which break pjsip (the SIP stack on which csipsimple rely), so 
you should disable it if you don't want to see unpredicatable latency when 
hanging up.

Original comment by r3gis...@gmail.com on 26 Dec 2010 at 7:18

[GoogleCodeExporter]

I have been observing another strange behaviour related to idle CPU usage that 
has a significant impact on battery as well as phone performance:

I'm using an HTC Wildfire (528MHz ARM11 CPU) running Android 2.2.1 (csipsimple 
r502), and my SIP provider requires re-registration every 60 seconds.  The "Use 
partial wake lock" and "Stay awake while on call" settings are required for me. 
 What I observe, by running "top" from a shell, is that when csipsimple is 
started from cold, its idle/background CPU usage is very low: <1%, except that 
about once a minute it rises to 5-7% for a couple of seconds, which I assume is 
due to re-registration processing.

However, after csipsimple has been running for a while (several hours) I find, 
again looking at top output, that the periodic CPU usage during the regular 
"spikes" starts to increase considerably.  csipsimple's usage itself may rise 
to 10-15% for a couple of seconds, but much more significantly, the 
system_server process becomes active at the same time and runs at 80-90% for as 
long as 10-15 seconds.

At first I didn't know what was triggering the system_server spikes and was 
prompted to troubleshoot because the phone had slowed to a crawl.  In doing so 
I found that killing csipsimple solved the problem, and also that restarting it 
solved the problem for some time, until hours later the excess system_server 
consumption would start coming back.

It would be interesting to hear from others what CPU usage patterns you see 
while csipsimple is registered but idle.  Also any insight as to what 
system_server could be doing that would cause it to start churning the CPU this 
way and how it could be related to csipsimple would be very helpful.

Original comment by fander...@gmail.com on 28 Dec 2010 at 2:46

[GoogleCodeExporter]

Here we are.
Revision 590 ship a big improvement (I hope so) in the way it manage keep alive.
It's now totally different approach from the previous one so that it ~should~ 
allow you to disable "Use partial wake lock" if you previously needed it.
It should also improve battery lifetime cause now :
 * The keep awake management is integrated with android OS approach of keep alives.
 * Keep alive is done synchronized for all accounts.

As consequence keep alive setting is not anymore related to account settings 
but to global settings. BTW, there is two keep alive settings. One for Wifi and 
one for mobile. By default I set wifi keep alive to 100s and mobile to 40s. Any 
feedback on these values is welcome :).

Now what is missing thing to have the lower battery consumption : activating 
STUN feature only when needed. This is planned in pjsip project for next 
release (in one or two week). So we can hope to have that soon :).
I've already decreased STUN timer from 20s to 90s which should leads to better 
perfs too. But I think that we will reach the best when pjsip will have the 
STUN feature only on calls establishment.

Original comment by r3gis...@gmail.com on 23 Jan 2011 at 9:45

[GoogleCodeExporter]

Initial testing of r590 confirms this is a major improvement!  I can now 
disable "Use partial wake lock" in the settings without losing registration, 
and battery consumption seems much lower.  Great work!  (I set keepalive to 50 
sec as provider's re-registration interval is 60 sec anyway)

[One very strange thing: my first test call with r590 brought the phone to a 
standstill immediately.  Investigating this I found calls were using G.729 even 
though I had not activated it!  This was causing csipsimple to peg the CPU.  
After going into settings and activating/deactivating it, this quirk seems to 
be resolved...]

Original comment by fander...@gmail.com on 24 Jan 2011 at 11:17

[GoogleCodeExporter]

Yes, as for codec problem, that's cause new version now differentiate codecs 
priorities (between wideband and narrowband).
However I have some piece of code that should reset codec priorities for 
working with that and that should not activate g729. But I've just noticed that 
it was done only if previous installed version were < 584. And I guess you were 
using 585 before.

I fix that, thanks for the info.

As for your provider re-registration interval you should ask them to allow 
higher re-registration interval. Cause for mobile that's worse to have 
re-registration to 60s. By default CSipSimple tries to ask with 300s (5min 
which is already very frequent and could be optimized I think).
All the more so as with new method, keep alive have not a deep impact on 
battery it's interesting to use it instead of re-registration.

Original comment by r3gis...@gmail.com on 24 Jan 2011 at 12:18

[GoogleCodeExporter]

I notice a high battery usage after making a call. Even if I turn off data, 
disable my sip account, and put the phone to sleep (it shows that it's been 
asleep the whole night), after only 10 hours or so the battery is nearly 
drained.

Then if I shutdown and turn the phone on again, all is well and the battery can 
last for 7 days or so in sleep mode. Something about making a call must stay on 
even after it is finished..

Original comment by zveda2000@gmail.com on 15 Feb 2011 at 2:15