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]

io queue is not used anymore. Don't hesitate to join developer google group for 
these questions, I think it valuable questions for all developers making work 
on the top csipsimple ;).
http://www.pjsip.org/docs/latest/pjsip/docs/html/structpjsua__media__config.htm#
ab1ddd57bc94ed7f5a64c819414cb9f96

Maybe it would be interesting to discuss again about that, if in pjsip-2.x the 
thread are now started only on demand (I know that media transport are started 
on demand, maybe it also affects io_queue polling, and so will not be a problem 
to reactivate that without having high cpu usage in background mode)

Original comment by r3gis...@gmail.com on 25 Apr 2012 at 8:33

[GoogleCodeExporter]

Thanks for the quick response.

I posted my previous question at the developer group, so the discussion can 
continue there.

However I still don't understand. The link you provided relates to media, and 
pjsua ioqueue polling refers to signalling. My question is how SIP signalling 
continues to work?

Original comment by jerry.fi...@gmail.com on 25 Apr 2012 at 9:13

[GoogleCodeExporter]

I notice that many people in this thread are not completely sure how to test 
battery consumption. 

For reference can we print here how to measure:

- how much CPU a the cSIPsimple process is using over time
- a way to record when the cSIPsimple process wakes from a background process 
and consumes a little cpu

Because with version 0.03-01r1108 I noticed it coming out of sleep and wasting 
a little battery.

 "android put things in RAM memory and the app does absolutely nothing in background"

As a user that until it is fixed I suggest using an App Quarentine when not in 
use and unlock it with a widget when you need to use it. 

Original comment by ajpearc...@gmail.com on 29 Apr 2012 at 11:32

[GoogleCodeExporter]

For lack of better ticket: this happens from time to time, CPU usage jumps to 
100% and the device becomes warm, and of course the battery drains fast. The 
offending processes are mediaserver and csipsimple:

User 55%, System 44%, IOW 0%, IRQ 0%
User 175 + Nice 0 + Sys 143 + Idle 0 + IOW 0 + IRQ 0 + SIRQ 0 = 318

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
   88  50% S     8  27236K   3876K  fg media    /system/bin/mediaserver
25751  35% S    16 127452K  33760K  fg app_56   com.csipsimple:sipStack
  112  11% D    67 233968K  60132K  fg system   system_server
28591   1% R     1    940K    388K  fg root     top
    5   0% S     1      0K      0K  fg root     events/0

I've shared logcat taken while this was happening with r3gis in google docs.

Original comment by egcros...@gmail.com on 5 May 2012 at 7:09

[GoogleCodeExporter]

Happened again in a recent nightly build. There was an unanswered sip call, 
when I picked the device it was warm.

User 53%, System 46%, IOW 0%, IRQ 0%
User 168 + Nice 3 + Sys 148 + Idle 0 + IOW 0 + IRQ 0 + SIRQ 0 = 319

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
   88  50% S    10  29636K   3128K  fg media    /system/bin/mediaserver
 6502  36% S    28 140096K  34412K  fg app_56   com.csipsimple:sipStack
  112  10% S    67 248364K  58572K  fg system   system_server
14746   1% R     1    944K    392K  fg root     top
14708   0% S     8 109424K  27464K  fg app_33   com.android.packageinstaller

(packageinstaller is trying to install next nightly build and was unable to do 
it until I killed the process 6502.)

Shared the log with r3gis

Original comment by egcros...@gmail.com on 5 Jun 2012 at 4:44

[GoogleCodeExporter]

In the latest CSipSimple with pbxes, I'm getting double the battery drain of 
SipDroid. Is there a fix for this?

Original comment by donrhum...@gmail.com on 28 Jan 2013 at 12:00

[GoogleCodeExporter]

I changed it to TCP and keep-alive on wifi is 180, but it's still using about 
2% battery per hour. With SipDroid, I typically saw 1% per hour.

Original comment by donrhum...@gmail.com on 28 Jan 2013 at 2:38

[GoogleCodeExporter]

Background process seems to drain the battery under Android 4.2.2. This issue 
is new since I upgraded to 4.2.2. Under 4.2.1, it didn't even appear in the 
battery stats.

Original comment by jost.me...@gmail.com on 19 Feb 2013 at 8:27

[GoogleCodeExporter]

Works fine for me on 4.2.2 (cm10.1 alpha on HTC one x)

Original comment by egcros...@gmail.com on 19 Feb 2013 at 8:33

[GoogleCodeExporter]

The battery drain is extremely high under Android 3.2 on my Huawei Mediapad. 
The tablet is warm after sleeping for hour!
It is ok if csipsimple is not installed.

Original comment by AHTOH.C on 20 Feb 2013 at 6:32

[GoogleCodeExporter]

Using the latest CSipSimple, is it possible to prevent the app from starting 
automatically whenever there's a WiFi network? I only want to use the client at 
work, I want to manually start and close it and not have it start by itself.

Original comment by dpa...@gmail.com on 26 Feb 2013 at 9:05

[GoogleCodeExporter]

Galaxy note 2, android 4.1.2.  Csip nightly build.  I click register with sip 
provider then unregister, go to network setting, uncheck all incoming and 
outgoing call, goto user interface then uncheck all phone integration, pull up 
menu then disconnect to home screen.  After all these, Csipsimple process still 
stays and takes about 5% unless I have to manually kill the process.

Original comment by webmas...@kitti.ac.th on 24 Apr 2013 at 12:54

[GoogleCodeExporter]

As soons as I enable my Sip-Account (sipgate.de, udp) I can see on my Router 
that a 50byte packet is transmitted about every 10s.
I can not see where this traffic is coming from since I set the re-register to 
1800s and the keep alives to 9999s.
Also I did not enable STUN or other 'extras' since I (hopefully) have enabled 
proper port forwarding.
When I disable the account a few more packets (about 20) are sent after which 
the router reports no more traffic.

I am guessing this behaviour is draining the battery.
How can set csipsimple to just register every 30min and generate additional 
traffic only for calls? 

Original comment by Markus.H...@gmail.com on 24 May 2013 at 7:59

[GoogleCodeExporter]

#126: Maybe it is a setting of the NAT keep-alive. If your phone has no 
dedicated public IP address (and it probably does not), you need these packets 
with frequency defined by the "fastest forgetting" NAT router. 120 seconds may 
work for you, but I know a WiFi network, where packets must be sent every 40 
seconds, otherwise the connection is lost.

Note that keep-alive packets may be initiated by the SIP server as well.

Original comment by stanisla...@gmail.com on 18 Jun 2013 at 6:13

[GoogleCodeExporter]

Note that if you can use TCP, you will likely find you can significantly 
increase the NAT keep-alive interval. This is because routers and the like 
usually time out UDP NAT info *much* sooner than TCP NAT info. In the past, 
I've found 15 minutes for keep-alives viable for TCP - both for home wireless 
and cell service provider - YMMV, though.

Unfortunately, most SIP providers do not offer TCP as an option, so this info 
may be of no real use.

Original comment by jbr...@gmail.com on 18 Jun 2013 at 6:20

[GoogleCodeExporter]

Quote:
"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."
****************************************************************
I think CSipSimple is taking the wrong approach here.
Let's compare K9Mail vs. CSipSimple.
CSipSimple consumes 3 times as much battery power on 3G networks on my Galaxy 
S2 Plus as K9Mail (IMAP) does. Reregistration timeout in CSipSimple is 900 
seconds (and it seems to be respected by server/client). Keep alive is set to 
600 seconds (using TCP/TLS).

The problem seems to be the high count of "alarms". Within 2 hours I had a few 
hundred alarms caused by CSipSimple but only about 10-20 in K9Mail. Still I 
instantly get emails via K9Mail with no delay.
So theoretically it should be possible for CSipSimple to notify me about calls 
WITHOUT the use of alarms.
You can have a look at the ImapConnection class in 
http://code.google.com/p/k9mail/source/browse/k9mail/trunk/src/com/fsck/k9/mail/
store/ImapStore.java to see the implmentation used in K9Mail.

Is there a way in CSipSimple to use a similar approach?
By the way I'm not sure, why exactly CSipSimple consumes more battery power 
than K9Mail. The alarm thing is just a guess.

Original comment by can.oezd...@gmail.com on 19 Aug 2013 at 9:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here a few stats:
3G / CSIPSIMPLE OFF / ANDROID SYNC OFF      0,6% / h
3G / CSIPSIMPLE ON / ANDROID SYNC OFF       1,7% / h

WLAN / CSIPSIMPLE ON / ANDROID SYNC OFF     0,8% / h

Original comment by can.oezd...@gmail.com on 19 Aug 2013 at 10:26

[GoogleCodeExporter]

@oezdemir : is stun enabled in your configuration? 
It's weird that you see few hundred alarms for csipsimple *if you configured 
your account on tcp* and if TCP keep alive is 600 sec. (it should produce 
normally only 12 in 2hours with this setting).

Also, be careful that configure the account for tcp means that you modified 
your account setting using advanced or expert wizard and choose tcp transport 
(the option in global setting is just about enabling or not the transport 
globally). 
Also take care that there is no other account enabled using UDP (which would 
obviously make the big tcp keep alive value useless).

Original comment by r3gis...@gmail.com on 19 Aug 2013 at 11:28

[GoogleCodeExporter]

yes STUN is enabled.

I had transport set to "automatic" (in expert mode), now I'll set it to "TLS". 
But I don't think this will make any difference because my server has always 
been showing that I'm connected via TLS connection anyway.
SIP Scheme is set to "sips"
URL registry is set to "sips:..."

I have no other account setup.

Original comment by can.oezd...@gmail.com on 19 Aug 2013 at 11:33

[GoogleCodeExporter]

is the high number of alarms because of STUN? Would ICE make a difference?

Original comment by can.oezd...@gmail.com on 19 Aug 2013 at 11:34

[GoogleCodeExporter]

Some stats I see:
Awake time 35minutes (in the last 5 1/2 hours) although I had no phone calls 
and haven't used the phone.

CSipSimple AlarmManager: 749 wakelocks that took 5 seconds
CSipSimple SipWakeLock: 397 wakelocks (9 seconds)
Network Usage (CSipSimple): 252 kiloBytes

Original comment by can.oezd...@gmail.com on 19 Aug 2013 at 11:42

[GoogleCodeExporter]

I also observe very high battery drain when using CSipSimple over 3G (almost 
10%/h). When checking the battery details, Android OS is consuming most of the 
battery and the "Keep awake" is very high. When I turn off CSipSimple account 
registration or using it over wifi, things get much much better.

Original comment by cyberan...@gmail.com on 20 Aug 2013 at 8:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I found out my server is sending an OPTIONS packet every 30 seconds to keep NAT 
routing alive. Now I switched that off...

Still I can see on the (Freeswitch) server side that, be it WLAN or 3G, the 
socket has a keepalive value of 30 seconds.
Could it be that due to this TCP keepalive value the alarm count is so high?

Original comment by can.oezd...@gmail.com on 20 Aug 2013 at 2:33

[GoogleCodeExporter]

Yes, indeed it's good point I forgot to mention. Obviously if server is very 
talkative, it will wake up the app as frequently as the server talks. And the 
big problem is that if it's too frequent the device never goes in deep sleep 
mode (when CPU is turned off). So it's very important to setup the sip server 
so that it's "mobile sip client friendly". Unfortunately there's nothing in sip 
protocol to prevent a remote side from being talkative and sending options or 
keep alive packets frequently. Only the remote decide that and must be 
configured to minimize this.
Usually for sip server connected to end user sip client a good idea is to let 
the sip client lead the keep alive (it's the one that is at the best place to 
decide of the quality of the network it uses because the server is supposed to 
be hosted on reliable network).
I'm not expert in FS configuration so I can't tell where are these settings on 
server side. But I'm pretty sure there is a way to configure that on server 
side.

BTW, if you have full control on sip server, in order to ensure what part is 
talking frequently, a simple way is to run a tcpdump and see what is the part 
talking. 
If it's csipsimple talking the keep alive settings are probably not set 
properly (or maybe there's a bug, it's not to exclude but this part was studied 
closely); If it's the server talking, you have to find the options to configure 
the server to avoid frequent packets sent to sip clients.

Original comment by r3gis...@gmail.com on 20 Aug 2013 at 10:22

[GoogleCodeExporter]

It would be nice to at least have the ability to do outgoing calls for the 
moment. At the moment because of this I actually use a closed source app which 
I then disable when not in use... not the best. 

Original comment by ajpearc...@gmail.com on 20 Aug 2013 at 10:35

[GoogleCodeExporter]

Well, when you close csipsimple and *configured it only for outgoing*, it will 
not stay alive in background. (And by close I mean press the *back button* 
because on android if you press the home button you suspend the application, 
you do not close it). 
This is expected to work from long time ago and I personally use it this way 
most of the time. If a bug were there, I would have noticed that ;)

Original comment by r3gis...@gmail.com on 20 Aug 2013 at 10:55

[GoogleCodeExporter]

Thank you for the advice.

Ok, I change the source code in Freeswitch now and disabled keepalives, 
recompiled everything, and when I look at netstat --timers I can see now: 
keepalive is off!

When I do a "tcpdump -i eth0 -s 0 port 5061" I see messages when the CSipSimple 
client registers, but apart from there seems to be no communication at all 
which is good (I've been watching this for 5 minutes now...).

But the problem with the high alarm count still exists. There are several 
hundred alarms within hours. I'm using BetterBatteryStats...
So I guess the alarm count is not network related?

Do you have any clue where it could have its origin?

Original comment by can.oezd...@gmail.com on 23 Aug 2013 at 4:08

[GoogleCodeExporter]

After the first registration I've seen no communication in tcpdump for 10 
minutes (which is the keepalive interval configured in CSipSimple).
Then approx. 5 minutes later I saw a reregistration (Reregistration interval is 
set to 15 minutes).

So communication is at a minimal level now.
The high alarm count must have a different reason.

Original comment by can.oezd...@gmail.com on 23 Aug 2013 at 4:17