linphone-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-users] Why Android (Oreo) phones, are actually less reliab


From: Juha Heinanen
Subject: Re: [Linphone-users] Why Android (Oreo) phones, are actually less reliable with TCP vs. UDP
Date: Sat, 30 Mar 2019 16:54:33 +0200

Brian J. Murrell writes:

> Can you ping it?
> 
> $ ping <hostname|ip-address>
> 
> > but it responds to SIP OPTIONS
> > request when the screen is off
> 
> So the network stack is probably not sleeping the way it does in my
> phone.
> 
> > If foreground process is not running, baresip does not respond to any
> > SIP request.
> 
> Of course not.  But does it remain pingable (see above) for long after
> the phone's screen goes off?

I cannot tell, since my phones as behind NATs.  All I care is that they
respond to SIP requests as long as the foreground service is running
even when the activities have been killed. 

> > But as I mentioned, based on my experience with Android
> > 7-9 devices, foreground process stays alive until phone goes to power
> > saving mode.
> 
> Sure, but does the network stack stay alive?  That's the issue here.

Must stay alive.  Otherwise they would not be able to respond to SIP
requests.

> > Mostly I have been using mobile data in my tests, but last night I
> > had
> > an Android 7 device on and both wifi and baresip were still alive in
> > the
> > morning.
> 
> So, wifi being turned off when the phone sleeps does not mean that it's
> not on when you wake the device up, such that you have to turn it back
> on manually.  I'm referring to the phone putting wifi to sleep when it
> sleeps and waking it up when it wakes up.

Again I don't care what the phone does with its wifi as long as my phone
responds to SIP requests and (if necessary) shows me a notification of
incoming request.

> 15% is a lot.  You really want in the small single digits.

Currently baresip registers its account about every 12 minutes.  It
would be possible to increase that and thus reduce battery consumption.

> > As long as you cannot run your own push notification server, you can
> > say
> > goodbye to privacy and security.
> 
> What's insecure about push?  And yeah, I guess if I didn't want Google
> to know when some service wants to wake up my phone, I guess.  But I
> don't see any value in that piece of data that is simply "wake up".

Is it really "wake up" of "wake up Linphone"?  Also, Google knows where
the wakeup request came from.

> Which is great, I guess if you are always sitting right beside a plug.

Not always, but often enough.

> > I cannot use UDP, because I need TLS for security.
> 
> TLS does not require TCP.  https://tools.ietf.org/html/rfc6347

Which open source SIP proxy supports SIP over DTLS?  I'm using Kamailio,
and last time I checked, it does not have that.

> > With TCP or TLS, SIP proxy learns it
> > immediately.
> 
> I guess that depends on what you mean by "network connection is lost". 
> If you simply mean that the network dropped out from between the phone
> and sip proxy, they no, the sip proxy wouldn't know.  It would simply
> queue TCP packets for the remote as I described in my original
> message.

I mean the situation when baresip receives CONNECTIVITY_ACTION, which is
not isConnectedOrConnecting.  At that point Android closes TCP and TLS
connections and my SIP Proxy becomes aware of it.

> If some device on the path tells your sip proxy (i.e. through an ICMP
> message) that the network has been lost, then yes it will know.  But
> it's not actually normal or desirable for devices to return ICMP
> messages for what should be a temporary outage.  It should rely on
> TCP's reliability to allow TCP sessions to resume once the outage has
> been restored.

When baresip then later receives isConnectedOrConnecting action, it
re-registers its accounts.

-- Juha



reply via email to

[Prev in Thread] Current Thread [Next in Thread]