#81 Battery consumption

[Anonymous]

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.

[Anonymous]

Originally posted by: zveda2000@gmail.com

I have Nexus S btw, and I set csipsimple to make outgoing calls only.

[Anonymous]

Originally posted by: DeepBhar...@gmail.com

Samsung Galaxy S I9000, Froyo 2.2: it really drains the battery very fast. I used both incoming and outgoing calls via it and end of the day battery is gone completely.

Then I set to outgoing only with increased keep alive polling time and made 2-3 calls, of 4 mins total and same results, end of the day, I am out of battery power, didn't understand it as it was on 'outgoing only' mode, then it should register only when needed but that seems not correct. Just to make sure I have had no other app when using it.

Its a good app, works fine with few minor issues but battery consumption made me uninstall it, with due respect to developers.

Going to install it again now, as I flashed official 2.2.1, which is surprisingly giving me 2.5 days battery at the moment, with 3g use and all the time wifi on. Shall post results again, if I notice something different.

But please look into this, its leading sip client at the moment, don't let battery consumption issue eat it. I am sure, you great developers will address it soon.

Regards,
SSA

[Anonymous]

Originally posted by: DeepBhar...@gmail.com

Tested with 2.2.1 on SGS 'only outgoing on wifi', made only 1 call of 1 min, from full charge to ~30% in < 8 hours. Sorry but uninstall. Please look into this issue.

Thanks

Regards,
SSA

[Anonymous]

Originally posted by: michael....@gmail.com

I have also experienced very high battery consumption on my Nexus S after making a call. Even if I disable the account () after making a call the battery seems to drain very quickly. On my Nexus One I have never seen this problem. This is also the first time I am trying the G.729 which I never tried using on the Nexus One.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Issue 744 has been merged into this issue.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Just found something that was wrong with proximity sensor that was possibly leaking depending on devices/configuration after a call...
Fixed and will be available in next build.

However, a strange thing is that Android keep an sensor thread even if I actually unregister the sensor listener... weird... I'll investigate a little bit more, but at least should be more clean now

[Anonymous]

Originally posted by: adan...@gmail.com

Running build 678 (feb 28). Seem to have some issues with CPU not going to sleep, but they tend to happen only after a while, and then it's permanent. I'm not sure exactly what triggers it, but I believe it's starting to happen in roughly the following scenario:
1. I'm at home, WIFI is connected, CSipSimple is connected - cpu is asleep, battery drain is minimal
2. I leave home, WIFI disconnects, CSipSimple disconnects (it's not set to connect over 3G)
3. I reach the office, WIFI connects, CSipSimple connects.
4. Cpu stays awake, battery drain gets high.

Phone: HTC Desire Z running CyanogenMod 7 (Gingerbread)
CSipSimple configuration:
- set to connect to an asterisk server over UDP
- all values are default, only use wifi for calls
- dialer and call logs integration is on, partial wake lock is off, keep awake while on call is off as it's not needed, log level is 0

Been having this issue at least since the last version in the Market.

Thanks for looking into it, great work btw :)

[Anonymous]

Originally posted by: adan...@gmail.com

Correction, seems to happen as well after leaving my office (where I was connected) when getting out of WIFI range and connecting on 3G. SIP is inactive, but battery drain happens, CPU is awake. Until then had no drain whatsoever.

[Anonymous]

Originally posted by: fander...@gmail.com

Note: The fix for issue 676 (present in [r690] and newer) may significantly reduce battery consumption for some. The reduction will be more noticeable the shorter the re-registration interval and the longer the csipsimple uptime.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Issue 832 has been merged into this issue.

[Anonymous]

Originally posted by: egcros...@gmail.com

Here's a kind of FYI report:
I was watching the battery applet output. As you may know, on Gingerbread it has a nice display with the discharge graph and a number of stripes showing when various elements of the system where active. One stripe is for "CPU Awake" status. I noticed that much of the time this stripe looks like a comb - the CPU is idle most of the time, but often wakes briefly to do some little job (like re-registration, or things unrelated to SIP). This is just as expected. However, for a long spans, like many hours at a time, the stripe is solid, i.e. the CPU is awake. Which should not be the case.

I decided to check if this behavior is related to CSipSimple, and turned it off for two days, activating native SIP instead. Result - there are still combs and solid spans. I don't think that there is visible difference. I'd say it's not likely that CSipSimple is causing the spans with the CPU awake. It might be useful to also try to live without any SIP agent active at all, but I did not do that.

Another result: after a day with CSipSimple I usually have above 50% juice left, in the two days with native SIP I had noticeably less than 50% by the nighttime.

[Anonymous]

Originally posted by: huan...@gmail.com

I'm using CSipSimple on a Droid Pro and have no issues whatsoever related to battery life. It's stellar!

[Anonymous]

Originally posted by: yok...@gmail.com

Running the latest version from market - 0.01-01 [r615].

Two main (critical) problems:

1. Time-to-time CSipSimpole looses its registration (meaning I can't receive calls at these times). Very bad thing... Tried to change "WiFi keep alive" setting - no improvement.

2. Battery consumption is terrible.
HTC Aria, 100% charged, overnight (less then 10h in completely idle mode) it looses 50% of battery charge. Network stats in Android Task Manager show: received ~ 190KiB, sent ~ 430KiB, total ~ 620KiB (values are all average). The network traffic is almost the same with "WiFi keep alive" setting either 80sec or 300sec.

For comparison: under the same conditions Sipdroid v.2.2b takes about 6-7% of battery charge overnight (ending at 94%) and I do not see it loosing registration...

[Anonymous]

Originally posted by: vale...@gmail.com

I have disabled unoptimized STUN. But, still my phone realy fast loosing charge.
CSipSimple CPU usage 2% always! No any network traffic, what it doing in background, works in boinc project?

  PID CPU% S  #THR     VSS     RSS PCY UID      Name

3569   9% R     1    928K    416K  fg root     top
2440   2% S    18 182468K  17624K  bg app_89   com.csipsimple

[Anonymous]

Originally posted by: yok...@gmail.com

Here is explanation why CSipSimple time-to-time looses its registration (see p.1 in my post #63 above) - you don't use a proper timer.

Below are time stamps collected from log generated by FreeSWITCH when CSipSimple has this setting: "Register timeout (sec)" = "60"

2011-03-30 22:24:43.416445
2011-03-30 22:28:08.347467  <- registration is lost
2011-03-30 22:34:17.157207  <- registration is lost
2011-03-30 22:38:20.516552  <- registration is lost
2011-03-30 22:39:43.442408
2011-03-30 22:53:34.310673  <- registration is lost
2011-03-30 22:54:42.946209
2011-03-30 22:58:35.493782  <- registration is lost
2011-03-30 23:03:35.384904  <- registration is lost
2011-03-30 23:04:00.703835
2011-03-30 23:08:19.001001  <- registration is lost
2011-03-30 23:08:51.070312  <-   and why it's here?
2011-03-30 23:12:31.769667  <- registration is lost
2011-03-30 23:14:15.509180 
2011-03-30 23:14:15.829673  <-   why it's here again?
2011-03-30 23:16:43.406592  <- registration is lost
2011-03-30 23:19:15.780887  <- registration is lost
2011-03-30 23:21:52.441774  <- registration is lost
2011-03-30 23:22:49.058830

Of cause it will loose its registration, even if FreeSWITCH adds extra 1 minute over the  registration time sent by CSipSimple to it... :(

Please fix the bug!

[Anonymous]

Originally posted by: r3gis...@gmail.com

@yok : can you produce CSipSimple logs. It's possible that 60 seconds proposed by CSipSimple are not accepted by the server and provide the client an higher value for re-registration timeout.

Regarding logs you get from the server CSipSimple re-register each 15 minutes. That's an exact value so I think this is due to the fact the client and the server agreed on this value.
If you send me logs with the HowToCollectLogs methods I'll be able to say whether :
1 - CSipSimple does not take into account your 60 s in re-registration timeout in expert wizard
2 - OR (more probable cause I tested the first one and still works) - Cause the SIP server actually say the sip client that the re-registration timeout will be 900s. The value sent by the client is *just* a proposal. Then what the client should do is get the value from the registration response and re-register when this value expires.

Just one other point about that : "why it's here again?". Read the FAQ about "I receive calls twice / Registration is done on the sip server twice". That's a normal behavior.

[Anonymous]

Originally posted by: r3gis...@gmail.com

@yok : just to be sure, once you save the account under expert mode, you do not then re-change wizard and save it to basic wizard mode?
Cause if you do so, the basic wizard default settings will apply and the default 900 sec of re-registration timeout will apply...

[Anonymous]

Originally posted by: yok...@gmail.com

Server (FreeSWITCH in this case) takes proposed time from CSipSimple seriously (it accepts whatever I set) and politely (it adds extra 60 sec, just to make sure that there is no problems with network traffic delays). I can see it on server's side checking the expiration time in its console. If in CSipSimple I set it to 60 sec, the server will wait for next 120 sec. If I set it to 3600, server will wait for next 3660 sec.

Tonight I've made a test and set "Register timeout (sec)" to 3600. Here is the log from server:
2011-03-31 00:22:58.596538
2011-03-31 01:23:12.238238
2011-03-31 02:26:41.855029  <- unregistered
2011-03-31 03:27:55.752253  <- unregistered
2011-03-31 04:28:00.569197
2011-03-31 05:31:40.218729  <- unregistered
2011-03-31 06:32:59.341218  <- unregistered
2011-03-31 07:37:56.104157  <- unregistered
2011-03-31 08:38:00.200000
2011-03-31 09:37:55.292088  <- unregistered
2011-03-31 09:42:24.363138  <- why ???
2011-03-31 09:42:24.643566  <- why ???
2011-03-31 10:42:21.475206
2011-03-31 11:42:33.336551

The phone was idle all the time... The total time when phone was unregistered is small, compared to the total measured time, but anyway - it's unacceptable.

As you can see sometimes it's sending its request, delayed 1 minute more then promised and sometimes it even sends several completely unnecessary requests in a row (in this test it was 3 times in a row)... The timer triggering registration is definitely not stable!

BTW, Sipdroid uses 3600 by default. And when I set CSipSimple to have registration time 3600 sec and then checked battery charge today morning - the charge was 95%. It's pretty much what I'm getting with Sipdroid.

Bottom line - I see the problem with timer that triggers register requests (it's not stable). It should be fixed, so CSipSimple is never late at sending register messages to server in time frame it promises.

----------------
I do all my tests in expert mode. And, BTW, if I set account back to "basic wizard" mode, I'd not expect my settings back to default 900 sec of registration timeout... :( Why is that? It may create unnecessary confusion. If I need to set everything to default values - I should be able to do so explicitly by some "Restore Defaults" action and not by simply changing the wizard. Wizard is just a way to simplify configuration (in cases if it's possible), but not the tool to reset my settings when I did not ask for it...

[Anonymous]

Originally posted by: r3gis...@gmail.com

Can you send me logs from CSipSimple?
With your logs I'm absolutely unable to understand what's actually happening.

There is many things that are done by pjsip that can be understood only with SIP packets under the eyes. Read the wiki page about multiple registration, you'll maybe have clues about why it may do multiple registrations.

CSipSimple relies on pjsip stack. This stack is widely used on other targets and is much much more complex than the sipdroid one. Also this re-registration thing take care of much more things than the sipdroid ones. There is mechanism to automatically detect NAT and things like that. It may introduce additional registrations (but can be configured).

I do test on sip servers and never get lost of registration. So as I'm not able to reproduce on my side *I really needs your csipsimple logs* else I'm really sorry but how do you want me to fix?

Besides, another things : CSipSimple is opensource and GPL... do you know that can have a look to the code too?
I develop it on my own time; If you really want to have it fix for you and improve the software, why not just diving in the code ;)? In opensource projects it's users that make the software. If nobody helps and rely on the main contributor, crying without helping, he will be tired one day ;).
You say me : the app is crappy, "it's unacceptable"...
Hey guy, it's not a professional app. Do you pay something for the app? Do I ask you for something when using the app? If you want support you have two choices :
You can choose the opensource way, accept to spend time to help the community to debug and provide more infos than just "Fix this bug".
Or you can choose a commercial app. Just cry against the support of this company that provide crappy thing. And they'll pay full time guys to just try to reproduce your issue on a lab and to understand what's going wrong and provide you a patch (one day).

Keep in mind, CSipSimple is a young project. It relies entirely on the community and on constructive feedback.

---
As for your last remark. Well, I hesitated long time before choosing this behavior.
You are thinking just about a switch from expert to basic but I have to think about switch from a sip provider to a generic. Also a wizard must be consistant. I think that it can be equally confusing to have a wizard applying different hidden settings regarding to what you did previously. If you want to change a setting, you must have access to it in the wizard you are editing it.
I think that your remark is just a point of view. And that in the absolute both approach could be equally confusing for an user. The thing that make me choose this approach is to be able to have a consistent way to edit a wizard.
For example you setup a sipgate account, then transform it to expert, change the registrar, and then re-transform it to sipgate account. What do you expect? Keeping the registrar you changed?? I think that's a bad idea. You want it to be a sipgate account, it just apply sipgate settings.

[Anonymous]

Originally posted by: ferna...@bugabundo.net

Both of you, to each corner for a break, :-P

About the reset settings (that should be documented in another bug /wiki) i
was going to agree with the other user, but your explanation makes sense.
I'll stick with it

[Anonymous]

Originally posted by: huan...@gmail.com

I think chances are Android tend to disconnect from time to time to save battery on some phones. It happens a lot and is observable on a couple of Android phones I have. If that's the case there is nothing cSipSimple can do.

FYI with my phone, CSipSimple consumes less battery than... Facebook.

[Anonymous]

Originally posted by: ferna...@bugabundo.net

battery on some phones.

Some ROMs do that! stock 2.3 in NS and 2.2 from HTC will kill data after 30
min

[Anonymous]

Originally posted by: yok...@gmail.com

@r3gis:
> With your logs I'm absolutely unable to understand what's actually happening.

REGISTER request, which SIP client sends to SIP server, has "Expires" attribute. That attribute tells to the server for how long to keep client registered. For example, if "Expires: 300", then server should keep the client registered for the next 300 sec (5 min). If server will not receive next REGISTER request during that time - it will un-register the client.

Now, if we look at the log provided in Comment #68, we can see that client makes promises to send requests every hour (3600 sec). But time-to-time it fails to do so. For example, it sends request at 2011-03-31 01:23:12.238238. The next such request should be sent no later, then in 1 h, and particularly, at the 2011-03-31 02:23:12.238238. But CSipSimple fails to send it at that time. Instead, it sends its next request at 2011-03-31 02:26:41.855029. It's more then 3 min late. During these 3 minutes server considers the client unregistered (as it should, accordingly to SIP specs).

Log of timestamps, provided in my previous post, shows that loosing registered status happened several times during that session. In all such cases CSipSimple did not send its next REGISTER request as it promises to SIP server.

But there is yet another problem - suddenly CSipSimple may send several REGISTER requests in a row during very short period of time. Here is example from the log above:
2011-03-31 09:37:55.292088
2011-03-31 09:42:24.363138  <- why ???
2011-03-31 09:42:24.643566  <- why ???

The question is - why it sends request at 09:42:24, when the previous request was send just about 5 min ago? And, after that it sends a third request in just about 300 msec. Why is that? It doesn't interrupt or brake registered status on server side (server will just restart its expiration time from the last request). But because it's unnecessary - it's a simple waste of battery charge (and bandwidth).

I hope that the long explanation provided above makes my point more clear. The problem is with timer, that triggers sending REGISTER requests. It is not properly implemented, otherwise CSipSimple would send REGISTER requests exactly at expiration time (no later or earlier)...

[Anonymous]

Originally posted by: stephen....@gmail.com

Just send the csipsimple logs like asked.

[Anonymous]

Originally posted by: edesk.pr...@gmail.com

I just upgraded Android version from 2.1 to 2.2 (Froyo) on my Motorola Milestone. I always use latest nightly build of Csipsimple. I am using this phone only for making SIP calls. In earlier version, I never noticed fast drainage of battery because of CSipsimple but here in 2.2 ver., I feel that CSipsimple is consuming more battery. Any Solution please ?