Re: [Linphone-users] Why Android (Oreo) phones, are actually less reliable with TCP vs. UDP

[Greg Troxel]

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

>> 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?
>
> That's what it appears to be doing.  Very shortly after the screen goes
> off, it stops responding to pings, yet can response to an FCM packet.

And you are sure that this FCM packet is arriving over wifi, because you
see it with tcpdump on the AP side, or in the log on the phone, or
something?

>> 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
>
> Yeah, that could be a more accurate description of what's happening. 
> The effect is the same though.

Yes, but it doesn't get the power savings from powering down the wifi
chip.  However, wifi has power saving where it can wake up periodically
and the AP defers packets until the wakeup slot.

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

interesting.

>> 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.
>
> Well, in fact the phone is supposed to and does wake up *before* the
> SIP server sends the INVITE in a TCP packet.  If you do the reverse,
> you are going to get an unACKed TCP packet with the INVITE in it that
> will need to be retransmitted at least once and start backing off it's
> retransmission delay.

So if the phone is awake, why is there a problem?  I am not following
the sequence that you say is not working right.

And if the packet is before the wakeup, it should just be queued in the
phone's wifi chip buffer until the main processor wakes up.  Perhaps
this scheme chooses not to do this.  Which in my view imposes a duty on
applications to avoid packets arriving during sleep.

> But even with that, I'd guess the INVITE would still make it "in time".
> What fouls it all up is if the SIP server sends any other data between
> the time that the phone sleeps and sending the INVITE because it's that
> other data that is sitting in the retry queue cranking up the
> retransmission timer to the point that when the phone finally does wake
> up, the delay is too great for the INVITE to make it in time to
> complete the call.

I see - but in this case, if the SIP server sends anything at all over
the TCP connection it should be sending a wakeup.  Going to sleep and
having data sent to you while asleep is a plan that does not work.  I
see your point that having a recovery strategy that sends the INVITE and
doesn't retransmit the others can work around that, but so can many
other things.