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

[Brian J. Murrell]

On Sun, 2019-03-31 at 08:17 -0400, Greg Troxel wrote:
> 
>   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).

And only works so long as the phone continues to maintain a fully
functional network.

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

Registration period can be set quite long.  Longer than the phone is
ever expected to sleep.

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

Correct.

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

Seems pretty accurate.

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

There is a fourth option where the SIP server has push fully integrated
and sends the INVITE as the data payload with the push.  So when the
PBX sends INVITEs to potentially multiple devices, they go in
traditional SIP packets for traditionally always-connected-and-awake
devices but for devices that sleep and need to be woken, the INVITE
payload is included in the push message.  The sleeping device wakes up,
processes the INVITE and responds to the SIP server as a traditional
device would with SIP Trying/Ringing/etc. packets including the SDP.

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

Right.  That has proven quite workable, even with a phone that sleeps
it's network, but only if using UDP.

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

From my experience as a user, it receives the push and immediately
REGISTERs in anticipation of an INVITE coming really soon.

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

That I don't know anything about.

Cheers,
b.

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