linphone-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-users] Why Android (Oreo) phones, are actually less reliab


From: Greg Troxel
Subject: Re: [Linphone-users] Why Android (Oreo) phones, are actually less reliable with TCP vs. UDP
Date: Sat, 30 Mar 2019 10:41:13 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix)

"Brian J. Murrell" <address@hidden> writes:

>> I certainly see your point about wanting to use the full-on FCM sleep
>> method for extreme battery saving.  But when doing that, I think
>> network
>> use has to be integrated with the FCM wakeup notion a bit more
>> deeply.
>
> How so?  It seems to me to be working sufficiently.  When the phone
> sleeps, wifi stops working *except* for FCM packets.  I imagine there
> must be something in the wifi hardware that allows it to go into deep
> power saving mode where only FCM (TCP port 5228, 5229 and 5230, AFAIU)
> wakes it back up into power-gobbling mode.

I wonder what is really going on.   Are you saying that the phone is
still associated with the local AP over wifi?  And that somehow it is
able to wake up for packets that arrive that are from the FCM server,
but not packets that arrive from someplace else?    If so, then I would
not call thath turning off wifi, but having the main processor not wake
up for packets other than ones that the wifi subsystem flags as FCM

I would expect that when shutting off wifi, the phone might be on cell
data, since it has to register with the cell network anyway for actual
phone calls and actual SMS (which I hear rumors some people still use!).


> But as soon as my phone gets that FCM message, it's wifi is alive and
> well.

Does it need to reassociate?  Does it need to get an IP address via DHCP
again?

By "integrated with FCM wakeup", I mean that the application layer
protocol that is operating with the phone that goes to sleep has to
understand that sending data (over TCP or UDP; that's not really the
point) does not reliably lead to that data arriving soon, and thus the
server needs to send a FCM wakeup and either hear from the phone or make
assumptions about wakeup latency.  Having retransmission timers run
async relative to wakeups is using a recovery mechanism for a situation
that isn't really a recovery situation.

Plus, if an INVITE is sent once over TCP, then I'd expect that is one
TCP segment in one IP packet, and it's queued, and when the phone wakes
up from the FCM notification it will receive it.  If not, I'd say that's
a bug in the scheme, unless it is documented that you shouldn't do this.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]