Comments (143)
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 [email protected]
on 14 Jul 2010 at 9:40
- Changed state: Accepted
- Added labels: Type-Task
- Removed labels: Type-Defect
from csipsimple.
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 [email protected]
on 14 Jul 2010 at 10:34
from csipsimple.
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 [email protected]
on 26 Jul 2010 at 4:57
from csipsimple.
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 [email protected]
on 26 Jul 2010 at 4:21
from csipsimple.
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 [email protected]
on 28 Jul 2010 at 9:06
from csipsimple.
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 [email protected]
on 28 Jul 2010 at 9:32
from csipsimple.
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 [email protected]
on 28 Jul 2010 at 9:49
from csipsimple.
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 [email protected]
on 28 Jul 2010 at 10:02
from csipsimple.
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 [email protected]
on 28 Jul 2010 at 10:25
from csipsimple.
+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 [email protected]
on 29 Jul 2010 at 6:02
from csipsimple.
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 [email protected]
on 29 Jul 2010 at 7:47
from csipsimple.
> 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 [email protected]
on 29 Jul 2010 at 7:56
from csipsimple.
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 [email protected]
on 29 Jul 2010 at 8:17
from csipsimple.
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 [email protected]
on 14 Aug 2010 at 9:11
from csipsimple.
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 [email protected]
on 14 Aug 2010 at 10:27
from csipsimple.
> 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 [email protected]
on 14 Aug 2010 at 12:50
from csipsimple.
Original comment by [email protected]
on 8 Sep 2010 at 6:55
- Changed title: Battery consumption
from csipsimple.
Issue 204 has been merged into this issue.
Original comment by [email protected]
on 8 Sep 2010 at 7:00
from csipsimple.
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 [email protected]
on 13 Sep 2010 at 5:38
from csipsimple.
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 [email protected]
on 13 Sep 2010 at 5:43
from csipsimple.
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 [email protected]
on 13 Sep 2010 at 6:00
from csipsimple.
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 [email protected]
on 23 Sep 2010 at 11:37
from csipsimple.
@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 [email protected]
on 27 Oct 2010 at 2:09
from csipsimple.
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 [email protected]
on 27 Oct 2010 at 2:48
from csipsimple.
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 [email protected]
on 30 Oct 2010 at 9:15
from csipsimple.
@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 [email protected]
on 3 Nov 2010 at 7:10
from csipsimple.
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 [email protected]
on 4 Nov 2010 at 12:30
from csipsimple.
I noticed that if my SIP server is down and the phone can't connect, battery
comsumption goes through the roof. Otherwise it seems fine to me.
Original comment by [email protected]
on 8 Nov 2010 at 8:16
from csipsimple.
Here's something interesting: I noticed that my airplane mode is a lot more
power-hungry and I suspect cSipSimple, as it's the only new bit of software
since this started happening. Funny thing is, in the Market version, I have
"use partial wakelock" unchecked, and Lock WiFi unchecked already.
One thing I'm experimenting with now: I disabled Incoming WiFi so that the
client doesn't try to register outside of periods I manually launch it, until I
later quit it. (Works great, that's the setting I was looking for!) Even if I
use System Panel to kill it after I quit it, I notice it reappears in my
process list shortly after (like the annoying Amazon MP3). I would've expected
it not to be restarted at all when configured that way. Is this normal or am I
missing an extra setting to disable that?
Original comment by [email protected]
on 28 Nov 2010 at 4:45
from csipsimple.
Yes it's normal that it appear in application list. Most of users are afraid
about apps that appear in application list.
But actually that's harmless :
Android manage its own memory by it's own way. As CSipSimple potentially listen
for network changes event (even if it actually does nothing if your
configuration is set too), android put things in RAM memory and the app does
absolutely nothing in background.
Those "auto-kill apps" are a really useless thing for android 2.0 and upper.
And even worse sometimes if set to auto-kill these apps can drain the battery
cause just try to umount things in memory and then android automatically
restart the apps and it loop infinitely...
I'm not alone to say that great android gurus (the ones that code the android
OS), try to explain this ... but unfortunately users still use this task
manager apps in auto-kill mode.
You should for example read that :
http://blog.radioactiveyak.com/2010/05/when-to-include-exit-button-in-android.ht
ml
http://androidspin.com/2010/05/25/why-you-dont-need-a-task-killer-app-with-andro
id/
http://android-developers.blogspot.com/2010/04/multitasking-android-way.html
And so on...
Besides I'd like to add that in development version there is a more user
friendly way to quit the app.
However it doesn't mean that it will disappear from task list. Just that it
will do nothing. But appearing in the task list doesn't mean that it consume
resources... even better sometimes it means that the application will consume
less resources when waked up back.
You can compare that to the "suspend/hibernate" mode of a PC. It just freeze
everything in memory to be able to wake up things quickly. And here in our
case, it's managed by the Android OS system. it's not up to the developer to
deal with that.
Original comment by [email protected]
on 28 Nov 2010 at 5:18
from csipsimple.
I'm not a developer nor an expert so maybe i'm going to say a very stupid
thing! :)
To save battery and also receive incoming calls can you use google's push
tecnology (C2DM) introduced with froyo? I noticed that application that use it
don't waste battery at all, but are able to provide notifications very quickly.
Examples of them are google's gmail app, google calendar, Chrome to phone,
WhatsApp (it works great!), K9 mail client (not sure but i think so), BeeJive
IM, ...
It's just a suggestion based on what i've seen until now, i don't know if it is
really possible
Original comment by [email protected]
on 2 Dec 2010 at 3:27
from csipsimple.
To comment 31:
1. To "notice" C2DM events the handset needs to be connected to Internet at all
times, this is not substantially different from being registered directly with
a SIP server. There is no magic here that could dramatically decrease the power
consumption.
2. To "notice" incoming INVITEs, some sort of proxy will need to run somewhere
"in the cloud", registered with the SIP provider, and producing C2DM notices
when it receives an INVITE. This would make the system prohibitively
complicated, compared to the device directly talking to the service provider as
it normally does.
3. The delay of C2DM delivery is at times much longer than an average person is
prepared to wait for her call to be answered.
Original comment by [email protected]
on 2 Dec 2010 at 4:00
from csipsimple.
A follow-up on my comment #29 above. Now that I disabled Incoming WiFi, I can
confirm that my Airplane Mode battery consumption is back to its normal
4-5%/day, so that seems to have been the cause for me. (Nexus One, by the
way.) Luckily I prefer to manually activate my SIP client during periods when
I make myself available, so I want Incoming WiFi to be off anyway. Problem
solved for me. :)
Bottom line, whatever monitoring Incoming WiFi incurs, is consuming a bit of
battery power during Airplane Mode; perhaps Airplane Mode itself could be
detected to further reduce the amount of work cSipSimple does during that time?
Just a thought, I'm already quite happy with how things are now that I found
this tweak.
Original comment by [email protected]
on 2 Dec 2010 at 5:29
from csipsimple.
To r3gis.3R and egcrosser regarding PARTIAL_WAKE_LOCK usage:
My understanding is that receipt of a network packet over an active interface
(e.g. non-sleeping wifi) while the phone is sleeping will generate a CPU
interrupt which will wake the CPU for a fixed small period of time (fraction of
a second). If the processing triggered by the packet requires more time to
complete, the application should obtain a partial wake lock when processing
starts and release it when processing finishes. This explains why pinging the
phone works when it's sleeping, and also implies that SIP applications should
be obtaining and releasing wake locks dynamically, not holding them forever.
I'd expect this change to result in much lower battery consumption without
sacrificing incoming call reliability.
Original comment by [email protected]
on 5 Dec 2010 at 2:03
from csipsimple.
fanderay4, every I/O event generates an interrupt. The point is, when the CPU
is switched off, it cannot process interrupts. However, when the network chip
receives a unicast packet it generates a special signal (in addition to the
interrupt) that switches the CPU on. Then the CPU handles the interrupt, and
the kernel dispatches any application that might be waiting for this packet.
The OS gives this application fixed time (10 seconds if I remember correctly)
to run, and then switches the CPU off again. If the application decides that it
needs to run longer to do its job, it must obtain any of WAKE_LOCKs before the
10 second interval expires. And this is how csipsimple works (unless you check
the "Use partial wake lock" checkbox in the settings, in which case it will
keep the lock all the time).
Original comment by [email protected]
on 5 Dec 2010 at 8:51
from csipsimple.
Thanks for the clarification egcrosser. If that's true then I don't see why
the "Use partial wake lock" setting should ever be needed, and yet when I
disable it, I permanently lose registration...
Original comment by [email protected]
on 5 Dec 2010 at 9:14
from csipsimple.
fanderay4, some combinations of hardware/OS version are known to have a bug:
the radio chip it programmed improperly and does not wake up the CPU on
incoming packets. I don't remember the number off the top of my head, you might
try to look it up in android bugs section. If this is indeed your problem then
you need to either upgrade the OS or "Use partial wake lock".
Original comment by [email protected]
on 5 Dec 2010 at 9:26
from csipsimple.
I use wifi only (sleep policy set to Never) with an HTC Wildfire running
CyanogenMod 6.1-RC. The only problem I'm aware of is
<http://code.google.com/p/cyanogenmod/issues/detail?id=2403> which I knew to be
responsible for having to set the "Stay awake during call" workaround option.
I guess that's the culprit in this case too.
Original comment by [email protected]
on 5 Dec 2010 at 9:54
from csipsimple.
+1 for egcrosser comment.
However there is still something that is still open and has to be explored :
Actually, for incoming packet CSipSimple works the way you explained (if there
is an incoming INVITE, csipsimple took a wake lock (however could be done more
lower in pjsip sip stack but would be not easy to maintain (and probably not
needed at all).
On the other side, CSipSimple tries to keep the UDP (or TCP) connection alive.
To do so, it send (actually pjsip sends) packets every 'keep-alive interval'
time. This is done inside the native library and no wake lock is done on this
part. So if your sip server is not talkative, and supposing CPU is turned off
by the OS, nothing will wake up pjsip threads to send the keep alive. (-- but
that's not clear, as the thread is not registered by the dalvik JVM, I'm not
sure at all of that --).
This is needed only if your carrier routers (or IP provider) cuts a connection
without any traffic.
A solution could be to use Alarms from android SDK (
http://developer.android.com/reference/android/app/AlarmManager.html ). But
problem is to get that synchronized with the pjsip native stack on which we
rely. In a first time could be an awful hack available as an option
(intermediate to Lock CPU and no lock CPU).
This is a really tricky point to handle, all the more so as all devices doesn't
manage things the same way, that all routers equipments doesn't behaves
identically and that some sip servers are more talkative than others (some send
frequent Notify which could be a solution). So to get something that works
perfectly in all case and consume the optimal battery is really hard and should
be thought as a background task (that I actually keep in mind but not top most
priority for now) (reason why this issue is marked as task. If anybody wants to
have a really close look to the issue and propose patches it will be welcome.
;).
Original comment by [email protected]
on 5 Dec 2010 at 9:58
from csipsimple.
Question: Which is better on battery life for the Android phone: A server that
is talkative and sends keep alive packets every X seconds, or for the phone to
send the keep alive packets every x seconds?
Or are they equal? Thanks
Original comment by [email protected]
on 6 Dec 2010 at 6:58
from csipsimple.
r3gis,
regarding re-registration from inside pjsip, do you happen to know how they are
woken up to do the job at particular time? If they use Android's alarm manager,
maybe getting and releasing the lock could be done in the "outer" Java part of
the event handler?
If they are using unix alarm(2), then theoretically, it should be pjsip's job
to obtain the lock for the duration of the registration process. As pjsip code
would not want to deal with Java interfaces directly, maybe they could be
persuaded to invoke caller-supplied callbacks before and after re-registration.
Then csipsimple could provide such callbacks, in which the lock will be
obtained and released.
Or maybe my speculation is completely off the point. In that case, just
disregard it.
Also, I must tell that for me, the app works very stable recently.
"Unexplained" loss of registration happens sometimes, but very seldom. I would
not even be able to test a possible solution because problem is so rare.
Original comment by [email protected]
on 6 Dec 2010 at 7:34
from csipsimple.
@mark : it depends on implementation on the phone. For now csipsimple is most
friendly with the talkative server approach (but server should send it with a
not so high frequency to not drain the battery. However in the absolute the
best approach is to let the client to be talkative : it may allow the client to
detect it's own network type and adapt frequency of it's ka packets to the
network type. On the other side, if we assume a alarm implementation, I'm not
enough an expert to say whether alarm or waiting network socket is the best
approach in term of battery usage.
What I can say is that if both server and client try to send keep alive packets
one of the two are useless. (Most of the time in this case we'd like client to
be silent). And also that if server send keep alive most of the time it's
through a NOTIFY so it's a little bit heavier to process that a client packet
(just a \r\n).
@egcrosser : Yes indeed could be integrated with pjsip. I've to check that but
maybe could be done in the os_android.c port : it's the implementation some
stuff for android regarding threading and scheduling, so could be managed
safely and cleanly here, even if we need to talk to the java part. (That's
already the case for the audio driver which is a separate source file).
So worth to explore this approach. But I'll have to really focus on that and
only that when I'll do this work :) For now too much other side things to do ;).
Original comment by [email protected]
on 6 Dec 2010 at 8:04
from csipsimple.
I am also experiencing high battery drain with cSipSimple on a custom Androd on
HTC HD2. This is probably unsupported but the drain is normal (5-10mA) without
cSipSimple registered. I use Battery Monitor Widget to monitor the devices
battery usage.
Currently I have cSipSimple configured with a PBXes account over TCP with
keep-alive set at 100 and register interval set at 1800. As long as cSipSimple
is registered, battery drain is in the ~150mA vicinity. This translates to
about 12%/hour with the screen off and me not using the phone.
Original comment by [email protected]
on 26 Dec 2010 at 6:42
from csipsimple.
Update to comment 43: I disabled all incoming data for cSipSimple (WIFI, 3G,
etc) and disconnected. After letting it settle down to 5mA draw for a few
minutes, I re-enabled the incoming data from easy settings and so far it is
still at 5mA draw. Going to keep monitoring this.
Original comment by [email protected]
on 26 Dec 2010 at 7:05
from csipsimple.
@nlm : are you configured to be "always available" over wifi only?
If so be aware of the fact that in this mode CSipSimple try to ensure that wifi
is running which drain the battery (but if you want to be always available and
use only wifi for that, that's the only solution, no miracle can be done ;) ).
I think that if you go in android device infos (android settings > about phone
> battery usage) and have a look to what is consuming battery, you'll not find
csipsimple but wifi as first entry.
A good compromise is to choose "available on wifi" (which keep your wifi policy
- I assume when screen is on). Or if you don't mind to receive calls, "only for
outgoing".
You can also try latest trunk version in which I've a little bit improves
things regarding cpu consumption, but I don't think that it will help a lot,
12%/hour is really really high (I never have that on my phone except on the
galaxy S when there were a wifi bug on the ROM I used).
Usually on my phones when 1%/hour is without csipsimple always running and
activated I get 3-4%/hour when activated and locking wifi.
However if the wifi driver of your phone doesn't behaves correctly (which
happened once on a ROM on my GalaxyS) it can increase a lot when wifi is locked
by the app.
Just FYI, pbxes.org doesn't actually support very well TCP : they do not
respect SIP RFC, which break pjsip (the SIP stack on which csipsimple rely), so
you should disable it if you don't want to see unpredicatable latency when
hanging up.
Original comment by [email protected]
on 26 Dec 2010 at 7:18
from csipsimple.
I have been observing another strange behaviour related to idle CPU usage that
has a significant impact on battery as well as phone performance:
I'm using an HTC Wildfire (528MHz ARM11 CPU) running Android 2.2.1 (csipsimple
r502), and my SIP provider requires re-registration every 60 seconds. The "Use
partial wake lock" and "Stay awake while on call" settings are required for me.
What I observe, by running "top" from a shell, is that when csipsimple is
started from cold, its idle/background CPU usage is very low: <1%, except that
about once a minute it rises to 5-7% for a couple of seconds, which I assume is
due to re-registration processing.
However, after csipsimple has been running for a while (several hours) I find,
again looking at top output, that the periodic CPU usage during the regular
"spikes" starts to increase considerably. csipsimple's usage itself may rise
to 10-15% for a couple of seconds, but much more significantly, the
system_server process becomes active at the same time and runs at 80-90% for as
long as 10-15 seconds.
At first I didn't know what was triggering the system_server spikes and was
prompted to troubleshoot because the phone had slowed to a crawl. In doing so
I found that killing csipsimple solved the problem, and also that restarting it
solved the problem for some time, until hours later the excess system_server
consumption would start coming back.
It would be interesting to hear from others what CPU usage patterns you see
while csipsimple is registered but idle. Also any insight as to what
system_server could be doing that would cause it to start churning the CPU this
way and how it could be related to csipsimple would be very helpful.
Original comment by [email protected]
on 28 Dec 2010 at 2:46
from csipsimple.
Here we are.
Revision 590 ship a big improvement (I hope so) in the way it manage keep alive.
It's now totally different approach from the previous one so that it ~should~
allow you to disable "Use partial wake lock" if you previously needed it.
It should also improve battery lifetime cause now :
* The keep awake management is integrated with android OS approach of keep alives.
* Keep alive is done synchronized for all accounts.
As consequence keep alive setting is not anymore related to account settings
but to global settings. BTW, there is two keep alive settings. One for Wifi and
one for mobile. By default I set wifi keep alive to 100s and mobile to 40s. Any
feedback on these values is welcome :).
Now what is missing thing to have the lower battery consumption : activating
STUN feature only when needed. This is planned in pjsip project for next
release (in one or two week). So we can hope to have that soon :).
I've already decreased STUN timer from 20s to 90s which should leads to better
perfs too. But I think that we will reach the best when pjsip will have the
STUN feature only on calls establishment.
Original comment by [email protected]
on 23 Jan 2011 at 9:45
from csipsimple.
Initial testing of r590 confirms this is a major improvement! I can now
disable "Use partial wake lock" in the settings without losing registration,
and battery consumption seems much lower. Great work! (I set keepalive to 50
sec as provider's re-registration interval is 60 sec anyway)
[One very strange thing: my first test call with r590 brought the phone to a
standstill immediately. Investigating this I found calls were using G.729 even
though I had not activated it! This was causing csipsimple to peg the CPU.
After going into settings and activating/deactivating it, this quirk seems to
be resolved...]
Original comment by [email protected]
on 24 Jan 2011 at 11:17
from csipsimple.
Yes, as for codec problem, that's cause new version now differentiate codecs
priorities (between wideband and narrowband).
However I have some piece of code that should reset codec priorities for
working with that and that should not activate g729. But I've just noticed that
it was done only if previous installed version were < 584. And I guess you were
using 585 before.
I fix that, thanks for the info.
As for your provider re-registration interval you should ask them to allow
higher re-registration interval. Cause for mobile that's worse to have
re-registration to 60s. By default CSipSimple tries to ask with 300s (5min
which is already very frequent and could be optimized I think).
All the more so as with new method, keep alive have not a deep impact on
battery it's interesting to use it instead of re-registration.
Original comment by [email protected]
on 24 Jan 2011 at 12:18
from csipsimple.
I notice a high battery usage after making a call. Even if I turn off data,
disable my sip account, and put the phone to sleep (it shows that it's been
asleep the whole night), after only 10 hours or so the battery is nearly
drained.
Then if I shutdown and turn the phone on again, all is well and the battery can
last for 7 days or so in sleep mode. Something about making a call must stay on
even after it is finished..
Original comment by [email protected]
on 15 Feb 2011 at 2:15
from csipsimple.
I have Nexus S btw, and I set csipsimple to make outgoing calls only.
Original comment by [email protected]
on 15 Feb 2011 at 2:17
from csipsimple.
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 [email protected]
on 15 Feb 2011 at 8:31
from csipsimple.
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 [email protected]
on 16 Feb 2011 at 9:41
from csipsimple.
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 [email protected]
on 21 Feb 2011 at 11:08
from csipsimple.
Issue 744 has been merged into this issue.
Original comment by [email protected]
on 24 Feb 2011 at 3:30
from csipsimple.
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 [email protected]
on 26 Feb 2011 at 11:53
from csipsimple.
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 [email protected]
on 28 Feb 2011 at 12:19
from csipsimple.
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 [email protected]
on 28 Feb 2011 at 9:36
from csipsimple.
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 [email protected]
on 12 Mar 2011 at 3:02
from csipsimple.
Issue 832 has been merged into this issue.
Original comment by [email protected]
on 25 Mar 2011 at 10:48
from csipsimple.
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 [email protected]
on 25 Mar 2011 at 11:08
from csipsimple.
I'm using CSipSimple on a Droid Pro and have no issues whatsoever related to
battery life. It's stellar!
Original comment by [email protected]
on 25 Mar 2011 at 11:13
from csipsimple.
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 [email protected]
on 29 Mar 2011 at 7:06
from csipsimple.
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 [email protected]
on 29 Mar 2011 at 7:43
from csipsimple.
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 [email protected]
on 31 Mar 2011 at 6:37
from csipsimple.
@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 [email protected]
on 31 Mar 2011 at 10:33
from csipsimple.
@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 [email protected]
on 31 Mar 2011 at 10:42
from csipsimple.
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 [email protected]
on 31 Mar 2011 at 7:49
from csipsimple.
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 [email protected]
on 31 Mar 2011 at 9:55
from csipsimple.
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 [email protected]
on 31 Mar 2011 at 10:03
from csipsimple.
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 [email protected]
on 31 Mar 2011 at 10:16
from csipsimple.
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 [email protected]
on 31 Mar 2011 at 10:37
from csipsimple.
@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 [email protected]
on 1 Apr 2011 at 6:22
from csipsimple.
Just send the csipsimple logs like asked.
Original comment by [email protected]
on 1 Apr 2011 at 6:34
from csipsimple.
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 [email protected]
on 23 Apr 2011 at 10:28
from csipsimple.
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 [email protected]
on 26 Apr 2011 at 9:10
from csipsimple.
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 [email protected]
on 3 May 2011 at 10:20
from csipsimple.
@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 [email protected]
on 3 May 2011 at 10:49
from csipsimple.
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 [email protected]
on 3 May 2011 at 11:48
from csipsimple.
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 [email protected]
on 4 May 2011 at 9:38
from csipsimple.
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 [email protected]
on 8 May 2011 at 12:21
from csipsimple.
@dutyan : this one is fixed in nightly build version that will land soon on the
android market.
Original comment by [email protected]
on 8 May 2011 at 1:14
from csipsimple.
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 [email protected]
on 9 May 2011 at 2:04
from csipsimple.
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 [email protected]
on 9 May 2011 at 8:23
from csipsimple.
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 [email protected]
on 9 May 2011 at 8:57
from csipsimple.
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 [email protected]
on 9 May 2011 at 10:13
from csipsimple.
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 [email protected]
on 14 Jun 2011 at 9:08
from csipsimple.
@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 [email protected]
on 14 Jun 2011 at 9:14
from csipsimple.
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 [email protected]
on 14 Jun 2011 at 9:29
from csipsimple.
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 [email protected]
on 14 Jun 2011 at 8:38
from csipsimple.
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 [email protected]
on 15 Jun 2011 at 8:33
from csipsimple.
We should move this to a new bug.
I have always available, wifi and 3G, incoming and outgoing
Original comment by [email protected]
on 15 Jun 2011 at 8:37
from csipsimple.
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 [email protected]
on 15 Jun 2011 at 9:17
from csipsimple.
932 trunk exits normally
Original comment by [email protected]
on 15 Jun 2011 at 9:24
from csipsimple.
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 [email protected]
on 15 Jun 2011 at 9:56
from csipsimple.
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 [email protected]
on 16 Jun 2011 at 9:36
from csipsimple.
#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 [email protected]
on 23 Jun 2011 at 12:10
from csipsimple.
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 [email protected]
on 2 Jul 2011 at 9:07
from csipsimple.
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 [email protected]
on 2 Jul 2011 at 2:05
from csipsimple.
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 [email protected]
on 3 Jul 2011 at 10:48
from csipsimple.
Related Issues (20)
- PSP Wifi mode : Sound becomes choppy/garbled when the phone goes to sleep in mid-call HOT 22
- After SIP call, next GSM call starts in "Loudspeaker" mode HOT 4
- sip outgoing only - result crash when dialing HOT 2
- Ability to put call on HOLD HOT 3
- Register timeout always reverts to 15 sec (Expert account wizard) HOT 15
- Keep-Alive Interval always reverts to blank (0) HOT 1
- Expert wizard: Data Type not initialized with account DB value HOT 12
- pre5 - Cannot disable or change Keep-Alive HOT 8
- Cannot erase Proxy URI field once it has been filled in HOT 2
- Enhancement: Account wizard for Callcentric HOT 5
- Micro / Speaker booster option HOT 1
- Cannot dial USSD codes while CSipSimple installed HOT 19
- new account HOT 2
- Phone calls do not pause media HOT 30
- No audio / Poor audio on Nexus One HOT 15
- Account Status Labels - More Descriptive and Localizable HOT 3
- Account name not shown on X10 Mini HOT 9
- [Manufacturer driver] Echo on Xperia X10 HOT 16
- Connect to SIP provider only on specific WiFi network
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csipsimple.