Battery consumption
Brought to you by:
krunalhire
Menu
▾
▴
#81 Battery consumption
Accepted
nobody
None
Medium
Task
2013-08-23
2010-07-10
Anonymous
No
Originally created by: egcros...@gmail.com
Originally owned by: r3gis...@gmail.com
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.
Related
Tickets: #1136
Tickets: #204
Tickets: #326
Tickets: #522
Tickets: #67
Tickets: #676
Tickets: #724
Tickets: #744
Tickets: #832
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: Markus.H...@gmail.com
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?
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: stanisla...@gmail.com
#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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: jbr...@gmail.com
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: can.oezd...@gmail.com
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 https://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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: can.oezd...@gmail.com
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
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
@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).
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: can.oezd...@gmail.com
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: can.oezd...@gmail.com
is the high number of alarms because of STUN? Would ICE make a difference?
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: can.oezd...@gmail.com
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
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: cyberan...@gmail.com
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: can.oezd...@gmail.com
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?
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: ajpearc...@gmail.com
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
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 ;)
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: can.oezd...@gmail.com
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?
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: can.oezd...@gmail.com
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.