Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Most important ISSUE: Does not receive calls in sleep mode #26

Open
mlawtk opened this issue Oct 2, 2015 · 14 comments
Open

Most important ISSUE: Does not receive calls in sleep mode #26

mlawtk opened this issue Oct 2, 2015 · 14 comments

Comments

@mlawtk
Copy link

mlawtk commented Oct 2, 2015

Ive tried all the varioius workarounds and no joy(read all the issues with 'sleep').
no matter what I change, it always happens.

After 3 mins, or less csipsimple does not pick up calls but rather sends them straight to voicemail suggesting a problem with registration or program operation in sleep mode.

(3g works in sleep.
I use the 3g connection (shared wirelessly), in sleep mode.

Therefore its not 3g & it should be possible to get the program to work seamlessly like the wifi and and googletalk currently do. )

pasted this from the old google code page:
Issue 2959: App alwys goes inactive/to sleep preventing incoming calls. ‹ Prev 11 of 14 Next ›
1 person starred this issue and may be notified of changes. Back to list
Status: New
Owner: ----
Type-Defect
Priority-Medium

Reported by secondef...@gmail.com, Jul 23, 2015
What steps will reproduce the problem?

  1. The app constantly goes inactive

What is the expected output? What do you see instead?
N/A

What version of the product are you using? On what device / operating
system? 1.02.03 r2457 on Huawei Y550-L02 android version 4.4.4

Please provide any additional information below.

I only use the app on my android phone for incoming calls, however, after minimal time, I notice it's gone inactive which prevents people from calling me. This happens constantly.

@jungle-boogie
Copy link

I'm observing this same problem. I would be willing to try the nightly version if I knew it was being updated and what was changing in it.

@mlawtk
Copy link
Author

mlawtk commented Oct 6, 2015

Well. I know hangouts works. So if I was to guess the problem it would probably be that hangouts uses GCM while CSIPSIMPLE does NOT.

Perhaps someone more knowledgeable could confirm this.

If anyone knows how to implement GCM feel free to comment as Im not sure this project is still being maintained.

@mlawtk
Copy link
Author

mlawtk commented Oct 6, 2015

Here's the current state of play AFAIK:

Any plans to deploy Push Notifications for Incoming Calls
3 people starred this issue and may be notified of changes. Back to list
Status: Duplicate
Merged: issue 724
Owner: ----
Closed: Dec 2012
Type-Defect
Priority-Medium

Reported by iprad...@gmail.com, Dec 30, 2012
I have tested www.acrobits (http://www.acrobits.cz) fot IPhone -planed deployment for Android 1st querter 2013- and they are using Push Notifications for Incoming Calls. Please read: http://en.wikipedia.org/wiki/Acrobits_Softphone.

The battery savings are dramatic.

Is there any chance to add said functionally on C Sip Simple for Android via the Google Cloud Messaging.

Thanks

Dec 30, 2012 Project Member #1 r3gis...@gmail.com
No never inside CSipSimple.
It's possible using csipsimple with the API of csipsimple to create such a third party plugin however ! So as an external app. CSipSimple is designed to be extensible and it's opensource !

Why will never be inside csipsimple :
This is bad for users as it introduces a server in the middle users are not supposed to trust. CSipSimple is pure opensource software and transparent with users ! Only server it will contact are your server you setup !
With Acrobits which is proprietary, who knows what they do with your private datas? There is maybe a end user agreement... what if you decide to not trust them !
I will never go this proprietary way inside CSipSimple and will never provide a service. I leave that to those that wants to make business with service providing (even if I recommand them to try to have their service mobile friendly with TCP, compact sip support etc instead).

Besides, other point, the Push notification is not reliable !!! Google explicitly tell that it's NOT something developers should rely on to receive events !

Besides, it's ABSOLUTELY WRONG to tell it saves battery. Those that tell that doesn't understand anything on how things works.
The push notification keep a tcp socket alive.... just as csipsimple could do !!!

So if your sip provider support TCP, if you correctly tweak the app settings to have keep alives values that matches your network , you'll get better battery usage than what you can have with push notif.

And last point, this is duplicate of issue 724

Status: Duplicate
Mergedinto: 724
Dec 30, 2012 #2 iprad...@gmail.com
Hi:

Thanks for the info, we are actually the ITSP and we dont support TCP.

We did tested Acrobits for IPhone, latest version and we found dramatic
battery life increase.

Based on your feedback we will do further investigation and try set our
service to TCP and see how it goes regarding battery life.

So far we being using C SIP on Android with more than satisfactory results
(only some issues with BT).
Jan 1, 2013 #3 dch...@gmail.com
You wrote:

Besides, it's ABSOLUTELY WRONG to tell it saves battery. Those that tell that doesn't understand anything on how things works.
The push notification keep a tcp socket alive.... just as csipsimple could do !!!

Be that as it may, GCM is already running in android phones so there's no additional battery consumption. Specifically, if an app uses GCM, it's piggybacking GCM instead of creating another live TCP connection. This is why consumers prefer push notifications.

But I 100% agree that it's a major security risk.

Jan 2, 2013 Project Member #4 r3gis...@gmail.com
First point, I would like also to remind that some android distribution (not linked to google) doesn't have by default link to google servers. Users with no google accounts will not be able to use it. And despite the fact the app is for android it's for all users, including those not trusting google and not having google accounts.

Else, that's indeed one possible argument (BTW, I evoked that on the issue 724 and in google's docs : http://developer.android.com/training/efficient-downloads/regular_updates.html#GCM).
As said by google docs it can be implemented by our own (and in our case using a standard which is not the case of GCM)... and also keep in mind google try to handcuff users to a service !

If we also have a tcp/ip socket, using GCM is just about minimization for on thing that can be negligible.

To understand well, the first thing to understand is what consumes battery : it is not the tcp/ip connection by itself.

In our case, it's CPU cycle of the processor and it's network chipset consumption.

  • For CPU, the important is to leave it going in sleep mode. Leaving time to goes in sleep mode is more important than anything else. As soon as the keep alive value is high enough whatever the other app does it will be fine.
  • For the network chipset, having 1 or 2 sockets has no impact on battery consumption. You could have 100 it would be the same. What consume battery is radio stuff which is linked to bandwidth. And this is independent of number of socket.
    The diag here explains how radio chipset goes to sleep mode (in wifi there is similar PSP mode):
    http://developer.android.com/training/efficient-downloads/efficient-network-access.html
    And it's also basically same thing that happens to CPU.

So an additional socket is not a big deal if doesn't have a lot of frequent data on it and is dedicated for events (which is normally our case unless the sip server sends INFO packets regularly).
The only remaining thing is the cpu cycle/radio wake up when the app needs to send the keep alive. What GCM allows is to have this synchronized between all sockets (and so wake up the cpu only once instead of twice). However, regarding other services running on the device and the keep alive value necessary for most cases, this synchronization stuff actually have no real noticeable impact.

Some not directly related paper but interesting to read : http://static.usenix.org/event/usenix10/tech/full_papers/Carroll.pdf
It explains where battery consumption goes. It also enlight on some preconceived ideas about keeping wifi on vs GPRS fallback.
Aug 29, 2013 #5 shi...@extracelestial.com
Thank you so much to the developer for your clear explanation!! I love csipsimple!

Jan 11, 2014 #6 prasd....@gmail.com
What is the best power saving (i.e. least power consuming) option for csipsimple but without loosing any incoming calls. Can you please comment on the power lost due to this relatively to just a push notification based wakeup ? I mean the app has to run not just keep socket alive I assume?

Mar 13, 2015 #7 vahin...@gmail.com
gcm still conssume less power than leaving socket open and pinging to leave it opend for this reason:
Google use a heartbeat system tuned for each provider so the provider doesn't close the tcp session. Heartbeat is only received by the radio circuit of the phone, which conssume almost nothing (like hearing a radio brodcast on a radio set). What conssume a lot is emmiting packet to the near gsm radio tower, wich you need to do if you do not use gcm and use ping to leave the tcp session opened!

@mlawtk
Copy link
Author

mlawtk commented Oct 6, 2015

So if anyone knows how to get incoming calls when in deep sleep let us know. thanks!

@jungle-boogie
Copy link

Hi @mlawtk,

Knowing this may be a problem with csipsimple, I will probably move to another more maintained and likely closed source app. There's many things I like about csipsimple, but I'd like the option to receive phone calls when the phone is sleeping. Of couse if csipsimple is maintained and updated, I'll definitely try it out and give feedback.

Have you used any sip app that works well with deep sleep?

@mlawtk
Copy link
Author

mlawtk commented Oct 6, 2015

try lumicall, but i dont know yet

@mlawtk
Copy link
Author

mlawtk commented Oct 6, 2015

zoiper works, but aiint very good

@jungle-boogie
Copy link

I have observed the if the phone is connected via wifi, csipsimple can receive calls, but if the wifi radio is not involved at all (disabled, out of range, not connected), the mobile app will sleep after about 3 minutes.

I don't know if this is ONLY a csipsimple problem or a greater android problem with apps not be able to keep connections alive.

@oneacl
Copy link

oneacl commented Oct 24, 2015

To receive calls you must use tcp or even better tls. Due to the nature of udp the connection will break within a minute or so. Tcp/tls connections are long lived, I have keepalive set at 900 seconds and I never missed a call (I even monitored registrations on my asterisk server and there are none apart from the expected ones).

Please try using tcp/tls and report back.

@jungle-boogie
Copy link

Hi @tcpdump1,

I think you're right and the registration stays active when using tcp and/or tls. Still testing to ensure it works.

@russelltrafford
Copy link

Just as an FYI, I'm still getting this issue. So its still a problem even in 2018.
It's strange that csipsimple is still coming up as the most recommended app, even though its not been maintained for years? Having said that, there still seem to be nightly builds for some reason, just no updated versions on the app stores?

Quite confusing

@jungle-boogie
Copy link

Having said that, there still seem to be nightly builds for some reason

How are there nightly builds if the src on github hasn't been updated since Oct 205? Is the src code now elsewhere?

@russelltrafford
Copy link

How are there nightly builds if the src on github hasn't been updated since Oct 205? Is the src code now elsewhere?

No idea, check out the datestamps on: http://nightlies.csipsimple.com/trunk/

My guess is that there's a build script just building the same old code over and over again every night? The nightly code will probably be slightly newer than whats in the App Stores, but probably still several years old... Total guess though on my part

@jungle-boogie
Copy link

but probably still several years old

yeah, unfortunately, I think you're right. That link is on google code archives, which is a few months older than what's on this github repo.

Sadly, it's probably time to move away from this app. :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants