Re: [Linphone-users] Linphone does not work out of the box (for me)

[Stuart Gathman]

On 07/29/2017 03:31 AM, jeff stern wrote:

Calling/talking/voice, however, is useless.  We either cannot hear each other, or if we do, it is 15-20 seconds later, and only even then, just fragments/shards.  Nothing usable.

(I really want Linphone to work. Believe me, I do.  But every few years I have checked in on Linphone.  Always it is the same thing, regardless of what devices used. New interface, crappy or unusable sound.  So disappointing.)

I normally would just abandon any software that does not work "out of the box", and move on.  But, because I am desperate to find *something* to replace Skype (and Tox has also failed miserably, and Signal IS great, but only works on phones -- even their alpha Chromium plug-in requires a phone number: deal-breaker).

By the way, our internet connection is fiber optic, with 150MBit/sec.  And, in this case, both the Linux box and the phone are in the same house, with the phone using wifi, not mobile data.

Is it a problem with sip.linphone.org, and we should use a faster sip provider?  Or is it still a problem with one or other of the apps?

Please let me know if there are any other details I can provide. Thank you

I use linphone everyday, and recipients are amazed at the clarity compared to cell phones.  But I've also experienced the problem you describe and can give some pointers.

This is not a problem with linphone, but with RTP packet delivery.  As with any internet performance issue, there are many hops twixt machineA and machineB - any one of which could be the bottleneck.  Here are some useful troubleshooting ideas I have used:

o First of all - you NEED IP6.  A lot of the following issues are related to working around the 20 years obsolete IP4.  Don't wait for your ISP - get tunnels to he.net, vpn to a vps (which generally all have IP6 - and sometimes come without IP4 for a few dollars less a month), cjdns global IP6 mesh vpn, or whatever it takes.

o You can eliminate any SIP provider by connecting directly to the other SIP device.  You will need either a public IP4 or IP6 or a VPN on each device to do so.  My favorite is cjdns - an IP6 mesh vpn that gives a permanent IP6 to each device, which you can use as its "phone number" - I call this mode of operation the "batphone" since it is also end to end encrypted.  Note that most SIP services are IP4 only - because you DON'T NEED them with IP6!

o You can verify the devices individually by signing up with a SIP to telco provider and calling a land line phone.  This is a useful capability to have anyway.  I use diamondcard.us.  They charge pennies a minute.

o You can try other free SIP providers, e.g. ekiga.net

o You can test each device individually  by connecting to an echo test service.  For example, sip:address@hidden or sip:address@hidden.  This is also a good way to get volumes adjusted before calling someone with a new mic and/or headset.

o SIP over mobile data is iffy, as their network quite naturally prioritizes phone traffic - mobile data is second fiddle.  Your phone should be connected to wifi for SIP.  Some people aren't aware of when their smartphone is using wifi vs mobile data.  That said, when the network isn't busy, RTP over mobile data has worked fine for me.

o Some ISPs "throttle" foreign RTP packets to protect their own VOIP offerings.  (No, "net neutrality" won't help - this is a problem created by "unlimited"/unmetered pricing plans.  If you pay for bandwidth used, the last thing the ISP wants to do is slow you down.)  Using a VPN generally obscures this from them.  In fact, I found that simply using a cleartext 6in4 tunnel to he.net avoided this for my ISP - their traffic shaping only handles IP4!

Conclusion - your time is better spent getting up to speed on IP6 than on debugging throttling/NAT issues with IP4.