Any plans to deploy Push Notifications for Incoming Calls
Brought to you by:
krunalhire
Originally created by: iprad...@gmail.com
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
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: 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
Mergedinto: 724
Status: Duplicate
Related
Tickets:
#724View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: 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).
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: 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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: 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.
Related
Tickets:
#724View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: shi...@extracelestial.com
Thank you so much to the developer for your clear explanation!! I love csipsimple!
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: 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?
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: 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!