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

[Brian J. Murrell]

On Sat, 2019-03-30 at 13:21 -0400, Greg Troxel wrote:
> 
> And you are sure that this FCM packet is arriving over wifi, because
> you
> see it with tcpdump on the AP side,

Yes.  Sent to the phone and ACKed by the phone.

> So if the phone is awake, why is there a problem?

Phone wakes up, but because while it was sleeping, the PBX tried to
send data on the TCP session, that data is now in the retry queue with
some (relatively) long timeout until the next retransmission attempt
due to it potentially having been in the queue for a (relatively) long
time.

The INVITE then gets added to the end of that queue, which is still
waiting for it's retry timer to expire so that it can send the pending
data plus the new INVITE.  But by the time the timer does expire, the
SIP session is actually done, RNA or gone to voice-mail.

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

Yeah.  I think the evidence is that the packet does not get buffered by
the wifi chip, as I believe I was seeing that it took another
retransmission from the PBX to get things moving again.

> I see - but in this case, if the SIP server sends anything at all
> over
> the TCP connection it should be sending a wakeup.

The push/wakeup is tied to the PBX sending an INVITE, not tied to the
TCP stack retransmitting frames that were in the queue before the
INVITE got there.

I.e. the push is being done at the application layer, not the transport
layer (in the OSI stack).

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

Indeed.

> but so can many
> other things.

Yes, like all parties being honest about what they are doing and all
parties being able to handle those states that have been disclosed
honestly.  But as we have said, we are not there yet.

Or as Juha suggests, but employing TCP keep-alives to basically tear
down those queues that could get stuck in long retry waits.  But that
does still leave a window of failure, granted much smaller, and maybe
for practical purposes non-existent since it will probably tear down
before any timeout gets extended long enough to be a problem.  Or just
use UDP.  :-)

Cheers,
b.

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