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

[Brian J. Murrell]

I have seen much of the FUD around here about not using UDP for SIP
because "it's unreliable".

Yes, UDP is not guaranteed delivery like TCP, but that doesn't
necessarily mean that a protocol running on it is unreliable. 
Protocols running on UDP, like SIP just need to understand that UDP
datagram delivery is lossy and they need to add their own reliability
to it.  And they do.

In reality, I don't believe, even on the Internet that UDP is as
anywhere even remotely close to as unreliable as it seems to get made
out to be in and around the linphone community (I frequently see
problem reports being answered with "use TCP").

If UDP were as unreliable as it's made out to be around here, then
protocols like QUIC would be a miserable failure.  And they are not.

In contrast, I find SIP call delivery (INVITE) over TCP with Android
(Oreo at least) phones to be far more unreliable than UDP, exactly
because TCP is a guaranteed delivery protocol.

What I am seeing is that the phone uses TCP to REGISTER to the PBX
successfully.  If a call is made to the phone before the phone has a
chance to go into sleep mode (i.e. right after the phone REGISTERs but
the screen isn't turned off) everything works great.

However, once the phone does go to sleep after the screen goes off, it
also stops responding to network packets (except seemingly Firebase
Cloud Messaging packets on port 5228 -- which wake the phone up,
including networking).  That means that if the PBX sends any more data
to the phone over TCP while it is sleeping, it will go unACKed and be
put into the TCP retry queue in the PBX's TCP stack for resend.  The
PBX continues to retry sending the TCP packet as it is supposed to per
the TCP protocol spec, and I believe, backing off the timeout each time
it goes unACKed.

What this means however is that when the PBX wants to send an INVITE to
the sleeping phone, that INVITE gets stuck behind (remember, part of
the reliability guarantee of TCP is also guaranteed ordering) the
packet that is in the TCP retry queue and won't make it to the phone
until the current retry-wait timeout expires and the packet ahead of it
is re-sent and ACKed.  This could be quite a long time if it's been
sitting in the queue for a long time having it's timeout backed off
each time it is re-sent and unACKed.

Push doesn't even help this situation, because even though a push will
wake the phone up before the PBX sends the INVITE, the TCP backlog (for
the phone) on the PBX has to be flushed before the INVITE will make it
to the phone.  The amount of time between the phone waking up from the
push and the TCP backlog getting flushed could be relatively long and
in fact what tends to happen is that the caller (to the PBX) has gotten
tired of waiting or has been sent to voicemail before this TCP queue is
flushed and the caller has hung up before the INVITE even makes it to
the phone.

Then a few (or more) seconds pass with the phone still awake from the
push, the retry timer on the TCP backlog expires and the queue is
flushed successfully to the phone including the INVITE, which the phone
finally receives and rings in response to.  The user answers, but by
that time the call on the PBX has terminated and the user has answered
a call that no longer exists.

Thoughts or comments?

Cheers,
b.

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