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: Brian J. Murrell
Subject: Re: [Linphone-users] Why Android (Oreo) phones, are actually less reliable with TCP vs. UDP
Date: Sat, 30 Mar 2019 09:55:24 -0400
User-agent: Evolution 3.30.5 (3.30.5-1.fc29)

On Sat, 2019-03-30 at 09:40 -0400, Greg Troxel wrote:
> 
> The FCM way is, I think, for the client to reconnect and query, with
> the
> server not having pushed anything.

I'm not sure I'm completely understanding what you are saying.

The FCM way is that information server/services that want to send
something to an app -- this can be instant messaging, etc. -- send it
to the app via an FCM push.  This is done by the server sending an API
query to the FCM service identifying the phone that it wants to send
the payload to and the payload it wants to send.  In the case of IM
type applications, this message from FCM can have what the service
wants to send, or it can simply be a "hey, come to me and get your
message".  The latter is how linphone is using it.

> I agree that UDP ought to be workable, and with your comments on
> retransmission being handled differently but also acceptably.

Right.  It's not really any different except that all of the error
handling that TCP does for an application, an application has to do for
itself.  That is what QUIC does.

> But in
> this case I think it's about working around a system that isn't
> processing packets correctly in a way that none of this was designed
> to
> handle.

That's not an unfair statement.  Even though TCP was invented so long
ago that networks were inherently unreliable, I doubt it was imagined
that endpoints would be so transient as phones are getting to be today.

It's mostly workable though.  Most things don't need the kind of timely
delivery that SIP does and so a bit of TCP-retry-delay backlog goes
unnoticed.  But some protocols like SIP really do need timely delivery
and so the guarantees that TCP provides actually hinders it.

> I see the TCP/UDP connection issue as having two larger points:
> 
>   TCP can and should use TLS, to hide the username and password in
>   register messages

TLS does not require TCP.  DTLS is TLS over UDP.

> 
>   TCP seems more likely to traverse possibly multiple layers of
> perhaps
>   broken firewall and NAT devices.

Yes, this is true.  But fortunately, becoming yesterday's problems. 
IPv6 is coming, and arriving.  I have 3 IPv6 connections to the
Internet on my consumer services.  Two are with ISPs and one is an IPv6
tunnel.  My mobile provider gives me IPv6 addresses.  It also gives me
IPv4 with broken NAT so I actually prefer IPv6.

But all of the brokenness of NAT goes away with IPv6.


>   Yes, UDP ought to work, but I think
>   it's more likely to lose with broken devices, and that's part of
> the
>   source of the notion

I'm not sure I buy a prevalence of broken UDP devices either though. 
Surely not saying they don't exist, but I don't think they exist to the
level of FUD about UDP that seems to float around here.

Cheers,
b.

  

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


reply via email to

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