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]

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

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

[GoogleCodeExporter]

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

Original comment by DeepBhar...@gmail.com on 15 Feb 2011 at 8:31

[GoogleCodeExporter]

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 

Original comment by DeepBhar...@gmail.com on 16 Feb 2011 at 9:41

[GoogleCodeExporter]

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.

Original comment by michael....@gmail.com on 21 Feb 2011 at 11:08

[GoogleCodeExporter]

Issue 744 has been merged into this issue.

Original comment by r3gis...@gmail.com on 24 Feb 2011 at 3:30

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 26 Feb 2011 at 11:53

[GoogleCodeExporter]

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 :)

Original comment by adan...@gmail.com on 28 Feb 2011 at 12:19

[GoogleCodeExporter]

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.

Original comment by adan...@gmail.com on 28 Feb 2011 at 9:36

[GoogleCodeExporter]

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.

Original comment by fander...@gmail.com on 12 Mar 2011 at 3:02

[GoogleCodeExporter]

Issue 832 has been merged into this issue.

Original comment by r3gis...@gmail.com on 25 Mar 2011 at 10:48

[GoogleCodeExporter]

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.

Original comment by egcros...@gmail.com on 25 Mar 2011 at 11:08

[GoogleCodeExporter]

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

Original comment by huan...@gmail.com on 25 Mar 2011 at 11:13

[GoogleCodeExporter]

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...

Original comment by yok...@gmail.com on 29 Mar 2011 at 7:06

[GoogleCodeExporter]

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

Original comment by vale...@gmail.com on 29 Mar 2011 at 7:43

[GoogleCodeExporter]

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!

Original comment by yok...@gmail.com on 31 Mar 2011 at 6:37

[GoogleCodeExporter]

@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.

Original comment by r3gis...@gmail.com on 31 Mar 2011 at 10:33

[GoogleCodeExporter]

@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...

Original comment by r3gis...@gmail.com on 31 Mar 2011 at 10:42

[GoogleCodeExporter]

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...

Original comment by yok...@gmail.com on 31 Mar 2011 at 7:49

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 31 Mar 2011 at 9:55

[GoogleCodeExporter]

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

Original comment by ferna...@bugabundo.net on 31 Mar 2011 at 10:03

[GoogleCodeExporter]

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.

Original comment by huan...@gmail.com on 31 Mar 2011 at 10:16

[GoogleCodeExporter]

battery on some phones.

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

Original comment by ferna...@bugabundo.net on 31 Mar 2011 at 10:37

[GoogleCodeExporter]

@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)...

Original comment by yok...@gmail.com on 1 Apr 2011 at 6:22

[GoogleCodeExporter]

Just send the csipsimple logs like asked.

Original comment by stephen....@gmail.com on 1 Apr 2011 at 6:34

[GoogleCodeExporter]

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 ? 

Original comment by edesk.pr...@gmail.com on 23 Apr 2011 at 10:28

[GoogleCodeExporter]

No problem for me more. Samsung Spica, Froyo 2.2.
I have disabled STUN, ICE (temporarily I think) and enabled "Use mode Audio 
API" in extended mode (helps release Spica's speaker after call).
But recently was CSIPSimple busyloop after 5 days of running (night build of 11 
April). Battery was hot, in CPU I just updated CSIPSimple, will see if this 
repeats.

Original comment by 304...@gmail.com on 26 Apr 2011 at 9:10

[GoogleCodeExporter]

I'm using PowerTutor app and it's showing that the radio is pulsing very 
frequently even when the I disabled all network answer & callout forms (GPRS, 
EDGE, 3G, Wifi...). Also closed the app via 'disconnect' option, and verified 
the service shut down in Settings > Applications > Running Services. The only 
way I could get the pulsing to stop was to toggle off/on the Data connection in 
Android Settings. There seems to be a bug somewhere.

Original comment by jayz...@gmail.com on 3 May 2011 at 10:20

[GoogleCodeExporter]

@jayz : are you using the market version or the nightly build? The market 
version has known imperfections regarding battery usage that are fixed in 
nightly build.

Original comment by r3gis...@gmail.com on 3 May 2011 at 10:49

[GoogleCodeExporter]

I was using the market version, but just installed nightly build 822 and still 
the same issue.

Some other notes about the latest nightly build during my brief testing to a 
landline:

Noticed where double incoming calls would show up, and I can't answer either, 
or if I "throw away" one, it disconnects the call. I think I have to back out 
of the app completely instead of using the home key to escape to get rid of 
this problem. On the bright side the ringtone sound plays when the double 
incoming appears, but when single incoming call appears, ringtone is silent.

My Acer Liquid (android 2.2) has weak speakers for some reason and if I set the 
audio amplification to anything higher than 1.0, I get no audio at all. the mic 
gain I have to turn down to 0.5, otherwise if at 1.0 it gets staticky if my 
voice gets high.

Original comment by jayz...@gmail.com on 3 May 2011 at 11:48

[GoogleCodeExporter]

About the double call : did you activate (or have the option active) Settings > 
Call settings > allow multiple calls? 
In fact when you are registered twice on a sip provider (which may occur if 
your sip provider does not fully respect sip standard or if the sip connection 
was not 'disconnected' by csipsimple (connection lost or app uninstall).
In this case your provider may call you twice. You should be able to answer by 
drag and droping one of the two calls on the upper part of the screen. (you'll 
have a missed call log in this case, but nothing hurting).

That's why I've introduced the allow multiple calls option, it's in order to 
prevent regression for users that already receive two calls from their sip 
provider but are saved thanks to the fact csipsimple did support only one call 
in previous releases.
Now the allow multiple calls should be disabled by default, and guys that 
enable it must be aware about the fact their sip provider has to support rfc 
correctly (or if not, csipsimple has to have the corresponding account 
configured to rewrite contact in legacy mode), and that in case of connection 
lost they can have this weird behavior.

Original comment by r3gis...@gmail.com on 4 May 2011 at 9:38

[GoogleCodeExporter]

HTC Desire HD, stock Android, CSipsimple version from Market.

Configured strictly for outgoing calls, all Android integration disabled (as 
it's certainly inconvenient to select transport every time when you make a 
call).

After a SIP call, the device lost ~50% of battery charge overnight, with 
partial wake usage 100%, due to CSipCall lock (judging by battery statistics).

Too bad there is no certain way just to switch everything off, completely stop 
the CSipSimple and forget about any potential issues (except for uninstalling, 
but install/uninstall every time to make a SIP call seems a bit impractical :) 
).

Original comment by dutyan...@gmail.com on 8 May 2011 at 12:21

[GoogleCodeExporter]

@dutyan : this one is fixed in nightly build version that will land soon on the 
android market.

Original comment by r3gis...@gmail.com on 8 May 2011 at 1:14

[GoogleCodeExporter]

Now that I got the echo thing resolved (issue 119), I am focusing on battery 
performance.  I use mostly over 3g.  From reading this thread, it seems that 
the main two parameters (since I'm mostly not using wifi) is the keep alive and 
the re-registration.  If I want to eliminate the keep alive for mobile, can I 
just set it to -1?

While the purpose of the keep alive is clear to me, what does register timeout 
and register delay before refresh (which is currently set to -1) do?  When the 
register timeout expires, does the client un-register, then re-register?  What 
is the purpose? 

Original comment by k...@laberteaux.org on 9 May 2011 at 2:04

[GoogleCodeExporter]

About the keep alive thing : in fact no -1 will not disable it. There is no way 
to disable this in fact. An equivalent to disable it would be to set it to the 
time of registration timeout of you sip provider.
In fact the re-registration is done by pjsip (in C layer). Previously keep 
alive was also done in C layer. The problem is that C layer has no way to tell 
the CPU to wake up at regular interval. Only android java API allow that. 
In consequence I did hacks in pjsip code to disable their keep alive mechanism 
(which was per account), and replace by one managed in java part of the app.
As consquence the keep alive mechanism will not only be useful to send blank 
packets to the stream but also to wake up the cpu at regular interval. As 
consequence in worse case keep alive should be at least the value of the 
registration timeout.

About the "register delay before refresh". This is something that has been 
introduced by pjsip really recently. In fact it represent the time just before 
the renewal of the registration.
I'll take an example :
CSipSimple config : register timeout : 3000 sec & register delay before refresh 
: 10s
 * pjsip send register timeout when registering (say 3000 sec)
 * the server register the client and tell that finally this registration will be valid for 1800 sec
 * => pjsip will try to re-register in 1800 s - 10 s

In register delay before refresh -1 means to keep the default value of pjsip 
(it's 5s if I do not mistake).

Original comment by r3gis...@gmail.com on 9 May 2011 at 8:23

[GoogleCodeExporter]

Thanks, your example makes it very clear!

r3gis, I am sure that if I sent you a log file, you could determine the optimal 
(or at least reasonable) values to set for keep alive and register time out.  
But could you give a quick tutorial here (where everyone can see) of what to 
look for in the log file?  If it is too complicated, I will just send you a log 
file.

Original comment by k...@laberteaux.org on 9 May 2011 at 8:57

[GoogleCodeExporter]

Running the latest v.0.02-00 from the market. 

I suppose that registration process should happen on a regular basis (and no 
more then it's being required). But here is example what I see in FreeSWITCH 
log:
2011-05-09 11:08:04.133718
2011-05-09 11:10:22.477473
2011-05-09 11:16:59.028847
2011-05-09 11:31:55.939492
2011-05-09 11:46:56.775483
2011-05-09 12:02:23.756731
2011-05-09 12:03:43.732958
2011-05-09 12:04:58.482242
2011-05-09 12:11:29.832046
2011-05-09 12:26:50.424808
2011-05-09 12:42:52.693418
2011-05-09 12:58:54.839573
2011-05-09 13:14:41.931381
2011-05-09 13:16:02.722050
2011-05-09 13:17:22.370872
2011-05-09 13:18:36.841319
2011-05-09 13:19:17.116459
2011-05-09 13:29:56.650829
2011-05-09 13:46:16.195421
2011-05-09 14:02:03.438599
2011-05-09 14:18:05.042140
2011-05-09 14:19:25.315967
2011-05-09 14:19:57.551677
2011-05-09 14:25:40.658197
2011-05-09 14:26:21.806545
2011-05-09 14:27:21.821645

Cell phone and SIP server was completely idle at the time of the test. All 
settings are default. Registration supposed to happen every 15 min (900 sec). 
But log above shows it's not the case...

Why registration is so irregular?

Obviously it leads to two problems:
1. drain move power (unnecessary frequent communications with server)
2. potential of loosing registration for a while (and it can't get incoming 
calls at that time)

Original comment by yok...@gmail.com on 9 May 2011 at 10:13

[GoogleCodeExporter]

Samsung Galaxy S, Froyo (2.2.1), no custom rom, csipsimple from android market,

Thank you very much for this little addon to android - very appreciated! It 
even works through an OpenVPN tunnel to my home router (unlike sipdroid).

But the battery drain is a big issue, even when all sip accounts are 
disconnected. Usually my phone looses 2% per ~8 hour night with all data 
connections disabled. With csipsimple running in background (no sip accounts 
connected) i lost ~30% power one night.

I use the app for outgoing calls only. So i would also prefer to have an option 
to shutdown csipsimple completely because i dont need an running background 
service for incoming calls/etc.

Workaround: for the time being i use "Bloat Freezer - Root" to 'freeze' 
csipsimple. 

Original comment by ber...@gmail.com on 14 Jun 2011 at 9:08

[GoogleCodeExporter]

@ber... : 
* did you try the 0.02-02? it should fix the crazy mode that drained battery.
* The option to shut down csipsimple is already available, press menu and 
disconnect... that's it :)

Original comment by r3gis...@gmail.com on 14 Jun 2011 at 9:14

[GoogleCodeExporter]

r3gis actually i've been meaning to talk to you about that: the Disconnect 
option stop working a few nightlies ago. it used to close the app, now it keeps 
running 

Original comment by ferna...@bugabundo.net on 14 Jun 2011 at 9:29

[GoogleCodeExporter]

i installed the 0202 two(?) days ago. didnt have time to gather some 
'statistically reliable' data about the runtime til now ...
but i can confirm, the way ->menu ->disconnect didnt work for me - even with 
build 0202. battery loosing power much faster than without csip. and killing 
the service with a taskmanager is no solution: csipsimple restarts itself after 
a few minutes.

Original comment by ber...@gmail.com on 14 Jun 2011 at 8:38

[GoogleCodeExporter]

About menu > disconnect problem, that's strange I do not reproduce. What are 
your global setting on availability of csipsimple ? (always available? on wifi? 
for outgoing? and is the allowed over 3g activated?).

Original comment by r3gis...@gmail.com on 15 Jun 2011 at 8:33

[GoogleCodeExporter]

We should move this to a new bug.
I have always available, wifi and 3G, incoming and outgoing

Original comment by ferna...@bugabundo.net on 15 Jun 2011 at 8:37

[GoogleCodeExporter]

I did a new build on nightly build website can you try and let me know if it 
helps with disconnect option?

Original comment by r3gis...@gmail.com on 15 Jun 2011 at 9:17

[GoogleCodeExporter]

932 trunk exits normally

Original comment by ferna...@bugabundo.net on 15 Jun 2011 at 9:24

[GoogleCodeExporter]

for your information: integration into android dialer NO, outgoing connections 
only,3G allowed.

923 is installed and i'll monitor what happens after "disconnect" ...

thanks!

Original comment by ber...@gmail.com on 15 Jun 2011 at 9:56

[GoogleCodeExporter]

Unfortunately the fix of r932 has really bad side effects. So I reverted 
things. I open a new issue to track a clean fix for that point (issue 1066)

Original comment by r3gis...@gmail.com on 16 Jun 2011 at 9:36

[GoogleCodeExporter]

#88
> option to shut down csipsimple is already available, press menu and disconnect

Consider option to integrate with tasker (application) to allow it to kill 
CsipSimple by matching criteria like time of day or battery %

http://tasker.dinglisch.net/

Original comment by bacon.li...@live.com on 23 Jun 2011 at 12:10

[GoogleCodeExporter]

there is still some unwanted activity in backround going on after 'disconnect'.
i am using the same config as before: NO integration into android dialer, 
outgoing only, 3G YES.
tonight i lost ~25% battery, while the expected drain without csipsimple was 
around 5-10% in that period.
later i looked into a taskmanager after using the phone a bit and csipsimple 
disappeared - ok ... then i came back to the phone after a while and when i got 
the unlock-screen to enter my pin (not my sim-card pin, phone did not restart 
in between), i saw "(s?)ip registered" coming up in the status bar.
i accessed csipsimple via status bar and had to re-enter the global settings on 
availability - my settings were lost!

Original comment by ber...@gmail.com on 2 Jul 2011 at 9:07

[GoogleCodeExporter]

About tasker integration, tasker just like locale, is not opensource software. 
I don't want to give an advantage to an non opensource software. As consquence 
I planned to do something for this stuff. Both locale and tasker use the same 
API. As consequence I'll soon create a new project that is an opensource 
alternative to this closed source application. Then it will be possible to use 
my new project or tasker or locale with a new plugin for CSipSimple. But it 
took time because I have to create this new alternative to these closed source 
programs.

About the loose of settings, another users had this problem too. 
It was cause he used a buggy alternative ROM (and when he migrated settings of 
apps before migration was duplicated in two places). You should search on the 
issue list (even on closed issue), he explained how to solve the problem. Could 
also be linked to how and where the app is installed on your android system. 
Actually CSipSimple use very basic feature of android system on settings so if 
you loose settings that's more likely cause android os do something weird with 
preference database.
(Could also be linked to the backup/restore feature, did you use it?) If you 
want to follow up, maybe worth to open an new issue about this point.

Original comment by r3gis...@gmail.com on 2 Jul 2011 at 2:05

[GoogleCodeExporter]

the disappearing settings can be related to a known bug on samsungs 2.2.1, 
where some apps cannot save their values. thanks for that hint. i did use the 
restore feature - but thats not the topic here and not so important for me now.

csipsimple got unloaded from androids memory after disconnect (no csip in 
taskmanager anymore), but why does it restart itself later on? i guess there is 
a runnning service which causes the battery drain and restarts the app.
i would really like to have an option to shut down csipsimple completely. or am 
i the only one with this wish?

Original comment by ber...@gmail.com on 3 Jul 2011 at 10:48