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

[Brian J. Murrell]

On Sat, 2019-03-30 at 10:41 -0400, Greg Troxel wrote:
> 
> 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.

> 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.

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

Nope.

> 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.

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.

Cheers,
b.

signature.asc
Description: This is a digitally signed message part