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

[Greg Troxel]

Juha Heinanen <address@hidden> writes:

> Greg Troxel writes:
>
>> 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.
>
> How does the SIP Proxy know where (IP address/port/transport) to send
> the INVITE?  Or does it include the INVITE in the payload of the push
> notification?  If not, it needs to wait for the phone to register
> itself.

Sorry, this got a bit jumbled.  I see three cases of handling sending
INVITE, and I was trying to talk about the first one here.

  User has registered and stays registered.  Phone is working (meaning
  that when a packet arrives it will get it within a second or so, and
  timers for reregistration are firing adequately timely).    server
  sends INVITE, and it arrives and works.  This is what you are doing
  and favor (me too).

  User has registered and stays registered.  Phone is doing extreme
  power saving and is not really working.  Somehow, it is able to
  reregister often enough.  Packets that arrive for the phone are either
  queued indefinitely or dropped or both.  A call arrives at the
  server. The phone has somehow told the server a push service token,
  and the server sends a wakeup, and then sends INVITE.  There is some
  messy resolution, maybe timely, maybe not, to retransmit lost packets
  and get back to a working state.   This is what Brian is describing, I
  think.

  User has registered.  User obtains a push service token, and sends
  that to the server with a "I am going to stay logically registered,
  but close the TCP connection."  Then, when a call comes in, the server
  does a push service wakeup.  Phone opens a TCP connection and does a
  resume, much like "tmux attach" on a new ssh connection to get back to
  your shell.  Then server sends INVITE over that.  This is the IETF
  approach.  Yes, it's more complicated, and has more delay, and exposes
  a wakeup to the push service, but it isn't unsound.  The i-d says that
  there are not yet implementations.

The second case is probably workable if the server is aware that this is
happening and declines to send anything over the connection unless it
has sent a wakeup very recently and at least a few seconds ago.  And if
it has no OS-level TCP keepalives.   This precludes sending presence
updates without a push wakeup.


Can anybody describe what linphone is doing, precisely, with push
services?

This is a question about the f-droid build as well, because that isn't
linked against google play services.