Closed GoogleCodeExporter closed 9 years ago
If settings are not saved, by default CSipSimple is configured to be started
when connection comes up.
So if the app can't save its settings, you'll indeed observe that it will
constantly restart as soon as a wifi hotspot notify it is running.
I think that solving the problem with settings will solve the problem with
constant restarts.
In fact, when you press disconnect, it add a flag somewhere about the fact you
don't want the app to start again when a connection intent is received from
android OS. So without any settings saved but with a correct account database,
what you observe is somehow normal.
Original comment by r3gis...@gmail.com
on 3 Jul 2011 at 8:32
regis, you were right. settings can now be saved and the abnormal battery drain
is gone - yepee :)
sorry for trying to make your excellent csipsimple responsible for a bug
samsung introduced into froyo (2.2.1) on the galaxy s.
thank you very much for your help and patience ... (feel free to delete my
comments regarding this issue if you think they are worthless for others).
Original comment by ber...@gmail.com
on 6 Jul 2011 at 10:47
No problem, that's fine.
Hopefully it will help other users :).
There is never bad questions and I really prefer when an issue is raised than
having frustrated users (or worse frustrated users that leave bad comments on
the android market where I can't help them :) ).
Original comment by r3gis...@gmail.com
on 6 Jul 2011 at 11:31
Got this today, unprovoked. When I killed the offending process from adb shell,
this did not prevent the app from working. Attaching log and top output.
(is this the right ticket? or do you have a special one for busyloop?)
Original comment by egcros...@gmail.com
on 8 Jul 2011 at 1:44
Attachments:
the above is for r886 ginger on oxygen 2.1.6
Original comment by egcros...@gmail.com
on 8 Jul 2011 at 1:47
Issue 1195 has been merged into this issue.
Original comment by r3gis...@gmail.com
on 25 Sep 2011 at 8:59
I would like to know if this is normal or not. I have gotten rid of my stock
2.1 rom for my X8 and install a custom ROM gingerdx on it. Everything seems to
be fine. I re-installed my csipsimple application. Since this is a ginger rom
so I take advantage of the latest nightly trunk for gingerbread. I installed
the application and reloaded my previous account info. All was fine. The call
quality is much better than before BUT i notice my battery usage is a lot
higher. Upon examining the details, I seem to find out that during my 40 min
call my partial wake lock had been on for exactly the same time. Even though
the screen was off, the CPU had been chugging along for the full call. After
the call, my battery level was 15% lower. I have since checked the setting.
Nothing in it seem to indicate that I turn on partial wake lock at all. Is
this normal? Could csipsimple request partial wake lock even though it is not
explicitly set to have that? In my previous market version for non-ginger
edition I was not aware that this situation had happened. What gives?
Original comment by chin.bil...@gmail.com
on 16 Nov 2011 at 8:49
It's normal that the app take a wake lock during call. It did that from the
beggining and all voip apps should take a wake lock when you are in call.
The reason is that the actually really need the CPU to be available to
encode/decode the call codec. If CPU goes off... you'll obviously got no sound
anymore.
About the fact it take more battery now, it could be about the codec in use.
Not all codecs use the same CPU. It could also be due to the fact you tried the
"gingerbread" version. This one is more close to the hardware and so frame rate
is higher. The bright side is that call quality is better, the dark side is
that the battery usage may be higher if the opensl-es driver (the one used in
gingerbread) is not implemented to ensure that battery usage remains low. If
you are using a custom ROM, this driver is probably re-implemented by ROM
makers and may not be totally robust about that.
It could explain what you observe and unfortunately there's nothing that could
be done on csipsimple to get rid of that. I can only advise you to use the
normal trunk version instead of the gingerbread one if the gingerbread
implementation introduce some too much annoying battery usage.
Original comment by r3gis...@gmail.com
on 16 Nov 2011 at 9:23
I think the power consumption could be the problem of PJSIP lib. If you read
their code, e.g. pjsua_core.c, you can find they are polling for timers and
socket events every 10ms.
Polling is good choice for servers or desktops, but not for mobile phones. See
http://www.lesswatts.org/projects/applications-power-management/device-ios.php
However on the symbian system, the PJSIP claims "zero polling", see
http://www.pjsip.org/sip_symbian.htm
and
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009-March/006814.html
Maybe they should also do this for android.
Original comment by phtr...@gmail.com
on 17 Nov 2011 at 4:07
One of big changes of latest version is to remove this polling approach and to
use the Android way for timers. Not only it will reduce CPU usage but will
also ensure that CPU is running when timer has to be fired. So this point is
fixed in CSipSimple thx to my port of the timers for android :) (as pjsip
already do for symbian)
Original comment by r3gis...@gmail.com
on 17 Nov 2011 at 5:37
just wondering has gingerbread version been removed now from nightlies? Has it
been merged? what happens to the native driver usage specific to gingerbread
rom?
Original comment by chin.bil...@gmail.com
on 24 Nov 2011 at 11:06
It will be reintegrated soon as either a plugin or an option in the app
(probably more likely to be inside the app and that could be enabled by
setting).
Depending on result we can obtain with this mode it could be set as the default
driver for future release (on 2.3 and upper devices) too. The big threat for
now on this topic remains battery usage. I have to look what was done on
google's project webRTC. When I implemented this device glue I was the first to
do so and was a little bit blind on how it could work and I may have missed a
couple of things about CPU consumption ;). Now that google also did something
with this API, I can compare and see how they do things (they probably do that
better than me).
Also, SILK, G7221, G726 and Codec2 are also now about to be re-introduced as
plugin apps. A video plugin should be added too once the feature will be ok on
my side.
Actually in order to integrate latest pjsip-2.0 I had to change a lot of things
in code, and in build process. We are currently in the transition time. Things
are landing step by step. ZRTP and TLS feature are now part of nightlies and
the alternate gingerbread device implementation will follow, be patient ;).
The only feature that should be dropped will be : the armv4t support and the
android 1.5 support. For these two cases, the old builds of the 0.03-xx branch
will be maintained as longer as possible with lower priority for me.
Original comment by r3gis...@gmail.com
on 24 Nov 2011 at 11:35
As I understand, a new timer was introduced for android in order to make a
better usage of the device power.
As part of the change, no worker threads are used in pjsua.
However I don't understand where ioqueue polling is done in order to handle the
network events.
Can someone please help? What am I missing?
Original comment by jerry.fi...@gmail.com
on 25 Apr 2012 at 7:29
io queue is not used anymore. Don't hesitate to join developer google group for
these questions, I think it valuable questions for all developers making work
on the top csipsimple ;).
http://www.pjsip.org/docs/latest/pjsip/docs/html/structpjsua__media__config.htm#
ab1ddd57bc94ed7f5a64c819414cb9f96
Maybe it would be interesting to discuss again about that, if in pjsip-2.x the
thread are now started only on demand (I know that media transport are started
on demand, maybe it also affects io_queue polling, and so will not be a problem
to reactivate that without having high cpu usage in background mode)
Original comment by r3gis...@gmail.com
on 25 Apr 2012 at 8:33
Thanks for the quick response.
I posted my previous question at the developer group, so the discussion can
continue there.
However I still don't understand. The link you provided relates to media, and
pjsua ioqueue polling refers to signalling. My question is how SIP signalling
continues to work?
Original comment by jerry.fi...@gmail.com
on 25 Apr 2012 at 9:13
I notice that many people in this thread are not completely sure how to test
battery consumption.
For reference can we print here how to measure:
- how much CPU a the cSIPsimple process is using over time
- a way to record when the cSIPsimple process wakes from a background process
and consumes a little cpu
Because with version 0.03-01r1108 I noticed it coming out of sleep and wasting
a little battery.
"android put things in RAM memory and the app does absolutely nothing in background"
As a user that until it is fixed I suggest using an App Quarentine when not in
use and unlock it with a widget when you need to use it.
Original comment by ajpearc...@gmail.com
on 29 Apr 2012 at 11:32
For lack of better ticket: this happens from time to time, CPU usage jumps to
100% and the device becomes warm, and of course the battery drains fast. The
offending processes are mediaserver and csipsimple:
User 55%, System 44%, IOW 0%, IRQ 0%
User 175 + Nice 0 + Sys 143 + Idle 0 + IOW 0 + IRQ 0 + SIRQ 0 = 318
PID CPU% S #THR VSS RSS PCY UID Name
88 50% S 8 27236K 3876K fg media /system/bin/mediaserver
25751 35% S 16 127452K 33760K fg app_56 com.csipsimple:sipStack
112 11% D 67 233968K 60132K fg system system_server
28591 1% R 1 940K 388K fg root top
5 0% S 1 0K 0K fg root events/0
I've shared logcat taken while this was happening with r3gis in google docs.
Original comment by egcros...@gmail.com
on 5 May 2012 at 7:09
Happened again in a recent nightly build. There was an unanswered sip call,
when I picked the device it was warm.
User 53%, System 46%, IOW 0%, IRQ 0%
User 168 + Nice 3 + Sys 148 + Idle 0 + IOW 0 + IRQ 0 + SIRQ 0 = 319
PID CPU% S #THR VSS RSS PCY UID Name
88 50% S 10 29636K 3128K fg media /system/bin/mediaserver
6502 36% S 28 140096K 34412K fg app_56 com.csipsimple:sipStack
112 10% S 67 248364K 58572K fg system system_server
14746 1% R 1 944K 392K fg root top
14708 0% S 8 109424K 27464K fg app_33 com.android.packageinstaller
(packageinstaller is trying to install next nightly build and was unable to do
it until I killed the process 6502.)
Shared the log with r3gis
Original comment by egcros...@gmail.com
on 5 Jun 2012 at 4:44
In the latest CSipSimple with pbxes, I'm getting double the battery drain of
SipDroid. Is there a fix for this?
Original comment by donrhum...@gmail.com
on 28 Jan 2013 at 12:00
I changed it to TCP and keep-alive on wifi is 180, but it's still using about
2% battery per hour. With SipDroid, I typically saw 1% per hour.
Original comment by donrhum...@gmail.com
on 28 Jan 2013 at 2:38
Background process seems to drain the battery under Android 4.2.2. This issue
is new since I upgraded to 4.2.2. Under 4.2.1, it didn't even appear in the
battery stats.
Original comment by jost.me...@gmail.com
on 19 Feb 2013 at 8:27
Works fine for me on 4.2.2 (cm10.1 alpha on HTC one x)
Original comment by egcros...@gmail.com
on 19 Feb 2013 at 8:33
The battery drain is extremely high under Android 3.2 on my Huawei Mediapad.
The tablet is warm after sleeping for hour!
It is ok if csipsimple is not installed.
Original comment by AHTOH.C
on 20 Feb 2013 at 6:32
Using the latest CSipSimple, is it possible to prevent the app from starting
automatically whenever there's a WiFi network? I only want to use the client at
work, I want to manually start and close it and not have it start by itself.
Original comment by dpa...@gmail.com
on 26 Feb 2013 at 9:05
Galaxy note 2, android 4.1.2. Csip nightly build. I click register with sip
provider then unregister, go to network setting, uncheck all incoming and
outgoing call, goto user interface then uncheck all phone integration, pull up
menu then disconnect to home screen. After all these, Csipsimple process still
stays and takes about 5% unless I have to manually kill the process.
Original comment by webmas...@kitti.ac.th
on 24 Apr 2013 at 12:54
As soons as I enable my Sip-Account (sipgate.de, udp) I can see on my Router
that a 50byte packet is transmitted about every 10s.
I can not see where this traffic is coming from since I set the re-register to
1800s and the keep alives to 9999s.
Also I did not enable STUN or other 'extras' since I (hopefully) have enabled
proper port forwarding.
When I disable the account a few more packets (about 20) are sent after which
the router reports no more traffic.
I am guessing this behaviour is draining the battery.
How can set csipsimple to just register every 30min and generate additional
traffic only for calls?
Original comment by Markus.H...@gmail.com
on 24 May 2013 at 7:59
#126: Maybe it is a setting of the NAT keep-alive. If your phone has no
dedicated public IP address (and it probably does not), you need these packets
with frequency defined by the "fastest forgetting" NAT router. 120 seconds may
work for you, but I know a WiFi network, where packets must be sent every 40
seconds, otherwise the connection is lost.
Note that keep-alive packets may be initiated by the SIP server as well.
Original comment by stanisla...@gmail.com
on 18 Jun 2013 at 6:13
Note that if you can use TCP, you will likely find you can significantly
increase the NAT keep-alive interval. This is because routers and the like
usually time out UDP NAT info *much* sooner than TCP NAT info. In the past,
I've found 15 minutes for keep-alives viable for TCP - both for home wireless
and cell service provider - YMMV, though.
Unfortunately, most SIP providers do not offer TCP as an option, so this info
may be of no real use.
Original comment by jbr...@gmail.com
on 18 Jun 2013 at 6:20
Quote:
"For re-registration, it's possible yes. You can use timed events (known as
"alarm" events in android -- see
http://developer.android.com/intl/fr/reference/android/app/AlarmManager.html).
Theses events are raised even if the phone is in the deep sleep mode (CPU off).
*But* for answering calls I think it is not possible :
In fact when CPU is in deep sleep mode, application can't treat network
packets."
****************************************************************
I think CSipSimple is taking the wrong approach here.
Let's compare K9Mail vs. CSipSimple.
CSipSimple consumes 3 times as much battery power on 3G networks on my Galaxy
S2 Plus as K9Mail (IMAP) does. Reregistration timeout in CSipSimple is 900
seconds (and it seems to be respected by server/client). Keep alive is set to
600 seconds (using TCP/TLS).
The problem seems to be the high count of "alarms". Within 2 hours I had a few
hundred alarms caused by CSipSimple but only about 10-20 in K9Mail. Still I
instantly get emails via K9Mail with no delay.
So theoretically it should be possible for CSipSimple to notify me about calls
WITHOUT the use of alarms.
You can have a look at the ImapConnection class in
http://code.google.com/p/k9mail/source/browse/k9mail/trunk/src/com/fsck/k9/mail/
store/ImapStore.java to see the implmentation used in K9Mail.
Is there a way in CSipSimple to use a similar approach?
By the way I'm not sure, why exactly CSipSimple consumes more battery power
than K9Mail. The alarm thing is just a guess.
Original comment by can.oezd...@gmail.com
on 19 Aug 2013 at 9:45
[deleted comment]
Here a few stats:
3G / CSIPSIMPLE OFF / ANDROID SYNC OFF 0,6% / h
3G / CSIPSIMPLE ON / ANDROID SYNC OFF 1,7% / h
WLAN / CSIPSIMPLE ON / ANDROID SYNC OFF 0,8% / h
Original comment by can.oezd...@gmail.com
on 19 Aug 2013 at 10:26
@oezdemir : is stun enabled in your configuration?
It's weird that you see few hundred alarms for csipsimple *if you configured
your account on tcp* and if TCP keep alive is 600 sec. (it should produce
normally only 12 in 2hours with this setting).
Also, be careful that configure the account for tcp means that you modified
your account setting using advanced or expert wizard and choose tcp transport
(the option in global setting is just about enabling or not the transport
globally).
Also take care that there is no other account enabled using UDP (which would
obviously make the big tcp keep alive value useless).
Original comment by r3gis...@gmail.com
on 19 Aug 2013 at 11:28
yes STUN is enabled.
I had transport set to "automatic" (in expert mode), now I'll set it to "TLS".
But I don't think this will make any difference because my server has always
been showing that I'm connected via TLS connection anyway.
SIP Scheme is set to "sips"
URL registry is set to "sips:..."
I have no other account setup.
Original comment by can.oezd...@gmail.com
on 19 Aug 2013 at 11:33
is the high number of alarms because of STUN? Would ICE make a difference?
Original comment by can.oezd...@gmail.com
on 19 Aug 2013 at 11:34
Some stats I see:
Awake time 35minutes (in the last 5 1/2 hours) although I had no phone calls
and haven't used the phone.
CSipSimple AlarmManager: 749 wakelocks that took 5 seconds
CSipSimple SipWakeLock: 397 wakelocks (9 seconds)
Network Usage (CSipSimple): 252 kiloBytes
Original comment by can.oezd...@gmail.com
on 19 Aug 2013 at 11:42
I also observe very high battery drain when using CSipSimple over 3G (almost
10%/h). When checking the battery details, Android OS is consuming most of the
battery and the "Keep awake" is very high. When I turn off CSipSimple account
registration or using it over wifi, things get much much better.
Original comment by cyberan...@gmail.com
on 20 Aug 2013 at 8:23
[deleted comment]
I found out my server is sending an OPTIONS packet every 30 seconds to keep NAT
routing alive. Now I switched that off...
Still I can see on the (Freeswitch) server side that, be it WLAN or 3G, the
socket has a keepalive value of 30 seconds.
Could it be that due to this TCP keepalive value the alarm count is so high?
Original comment by can.oezd...@gmail.com
on 20 Aug 2013 at 2:33
Yes, indeed it's good point I forgot to mention. Obviously if server is very
talkative, it will wake up the app as frequently as the server talks. And the
big problem is that if it's too frequent the device never goes in deep sleep
mode (when CPU is turned off). So it's very important to setup the sip server
so that it's "mobile sip client friendly". Unfortunately there's nothing in sip
protocol to prevent a remote side from being talkative and sending options or
keep alive packets frequently. Only the remote decide that and must be
configured to minimize this.
Usually for sip server connected to end user sip client a good idea is to let
the sip client lead the keep alive (it's the one that is at the best place to
decide of the quality of the network it uses because the server is supposed to
be hosted on reliable network).
I'm not expert in FS configuration so I can't tell where are these settings on
server side. But I'm pretty sure there is a way to configure that on server
side.
BTW, if you have full control on sip server, in order to ensure what part is
talking frequently, a simple way is to run a tcpdump and see what is the part
talking.
If it's csipsimple talking the keep alive settings are probably not set
properly (or maybe there's a bug, it's not to exclude but this part was studied
closely); If it's the server talking, you have to find the options to configure
the server to avoid frequent packets sent to sip clients.
Original comment by r3gis...@gmail.com
on 20 Aug 2013 at 10:22
It would be nice to at least have the ability to do outgoing calls for the
moment. At the moment because of this I actually use a closed source app which
I then disable when not in use... not the best.
Original comment by ajpearc...@gmail.com
on 20 Aug 2013 at 10:35
Well, when you close csipsimple and *configured it only for outgoing*, it will
not stay alive in background. (And by close I mean press the *back button*
because on android if you press the home button you suspend the application,
you do not close it).
This is expected to work from long time ago and I personally use it this way
most of the time. If a bug were there, I would have noticed that ;)
Original comment by r3gis...@gmail.com
on 20 Aug 2013 at 10:55
Thank you for the advice.
Ok, I change the source code in Freeswitch now and disabled keepalives,
recompiled everything, and when I look at netstat --timers I can see now:
keepalive is off!
When I do a "tcpdump -i eth0 -s 0 port 5061" I see messages when the CSipSimple
client registers, but apart from there seems to be no communication at all
which is good (I've been watching this for 5 minutes now...).
But the problem with the high alarm count still exists. There are several
hundred alarms within hours. I'm using BetterBatteryStats...
So I guess the alarm count is not network related?
Do you have any clue where it could have its origin?
Original comment by can.oezd...@gmail.com
on 23 Aug 2013 at 4:08
After the first registration I've seen no communication in tcpdump for 10
minutes (which is the keepalive interval configured in CSipSimple).
Then approx. 5 minutes later I saw a reregistration (Reregistration interval is
set to 15 minutes).
So communication is at a minimal level now.
The high alarm count must have a different reason.
Original comment by can.oezd...@gmail.com
on 23 Aug 2013 at 4:17
Original comment by r3gis...@gmail.com
on 22 Jun 2015 at 11:30
Original issue reported on code.google.com by
egcros...@gmail.com
on 10 Jul 2010 at 10:13