[Spreed.ME] Unreliable long distance connection buildup via TURN server

MichaIng · February 6, 2017, 11:57pm

Hey there,

since I want to have video calls with my wife in indonesia without relying on external organisations like Skype or WhatsApp/Facebook, we are using Spreed.ME.

I am hosting an up-to-date nextcloud with Spreed.ME app, spreed server and coturn. Everything is configured as reported here and generally working fine. Test calls with phone via mobile internet and so on are working as expected since I use the TURN server.

But since the beginning the video connection with my wife in indonesia builds up really unreliable. Chat works and also the call requests appear directly on both sides. But sometimes we both do not have the video of each other, sometimes also no sound, sometimes just no video in one random direction while the other one has video. Most of the time actually I do not have video and sound of her, while she sees and hears me. Instead of the video, the grey background with an eye on it shows up, as if video was disabled by the other one.

We already tried to play around with video quality and all the other settings, switched who initiates the call and I was trying to find any hint in spreed and coturn log. Actually the spreed log does not show any log beneath room creation and user joins, the coturn log does more or less show the same things, whether it’s working or not. In between there shows up some

realm <example.org> user <>: incoming packet message processed, error 401: Unauthorised

No idea if this has to do something with it and why this shows up. As said, sometimes the video connection works fine for both of us, but it has nothing to do with the general internet connection quality of my wife there.

I have to mention that my wife uses her phone as mobile internet hotspot for her laptop to have internet. No cable internet usual there ;).

Does anyone have an idea where the problem could be sitting?

leon · February 7, 2017, 10:31am

Hi @MichaIng,

please try if disabling TURN via UDP helps to fix the issue.
Simply remove turn:<host>:<port>?transport=udp from the turnURIs directive in the Spreed WebRTC config. Make sure turn:<host>:<port>?transport=tcp (for TCP) stays enabled. Restart the server afterwards.

If establishing connections to Indonesia then work better, it’s most likely that UDP is just too unreliable.

MichaIng · February 8, 2017, 1:48pm

Sadly switching to only tcp connection didn’t help so far. Old issue appeared again, that I was not able to hear and see my wife, while she was able to.

I was going trough the turnserver.conf and found alt-listening-port setting. By default this is set to one port higher than listening-port, but I did not understand well what it is for. The important question about it is, if I need to establish some port forwarding for this? On the other hand, why should spreed send some request to it, as it should not know about it’s existence ;).

It’s about NAT behaviour discovery, used by UDP, but TCP at least is “listening to that endpoint only for "symmetry"”:

> # Alternative listening port for UDP and TCP listeners;
> # default (or zero) value means "listening port plus one".
> # This is needed for RFC 5780 support
> # (STUN extension specs, NAT behavior discovery). The TURN Server
> # supports RFC 5780 only if it is started with more than one
> # listening IP address of the same family (IPv4 or IPv6).
> # RFC 5780 is supported only by UDP protocol, other protocols
> # are listening to that endpoint only for "symmetry".
> #
> #alt-listening-port=3478

leon · February 8, 2017, 4:29pm

Have you checked if the traffic really goes through the TURN server?

MichaIng · February 8, 2017, 7:19pm

Yes definitely. Without TURN no video connection is possible at all from outside the local server network and at the moment both users are connecting from outside of it.

By testing with two browser instances, one using browser internal VPN (Opera), in coturn log I see:

IPv4. tcp or tls connected to: my.ip:port    //3 times

incoming packet message processed, error 401: Unauthorised    //4 times, error as mentioned above, but also if video works fine in both directions

new, realm=<example.org>, username=<example>, lifetime=600
incoming packet ALLOCATE processed, success
   //both 3 times for one user, maybe the one who initiates the call

incoming packet CREATE_PERMISSION processed, success
incoming packet CHANNEL_BIND processed, success
   //each for both users

usage: realm=<example.org>, username=<example>, rp=1021, rb=382781, sp=1027, sb=387968
...
   //ongoing for both users

incoming packet REFRESH processed, success    //in between while video is up for both users

I just put coturn into strong “Verbose” mode for further log details. Will extract the log exactly related the failing video connection with my wife later.

€: So, here is the “Verbose” log, actually no additions compared to the “moderate” verbose mode Oo… Maybe it does not work together with “simplelog”? Anyway…

10413: IPv4. tcp or tls connected to: XX.XX.XXX.XXX:27046
10413: IPv4. tcp or tls connected to: YY.YY.YYY.YYY:47483
10413: session 000000000000000001: realm <example.org> user <>: incoming packet message processed, error 401: Unauthorised
10413: session 003000000000000001: realm <example.org> user <>: incoming packet message processed, error 401: Unauthorised
10413: IPv4. tcp or tls connected to: YY.YY.YYY.YYY:46288
10413: session 000000000000000002: realm <example.org> user <>: incoming packet message processed, error 401: Unauthorised
10413: IPv4. Local relay addr: ZZZ.ZZZ.ZZZ.ZZ:64545
10413: session 003000000000000001: new, realm=<example.org>, username=<1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>, lifetime=600
10413: session 003000000000000001: realm <example.org> user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>: incoming packet ALLOCATE processed, success
10413: IPv4. Local relay addr: ZZZ.ZZZ.ZZZ.ZZ:57848
10413: session 000000000000000001: new, realm=<example.org>, username=<1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>, lifetime=600
10413: session 000000000000000001: realm <example.org> user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>: incoming packet ALLOCATE processed, success
10413: IPv4. Local relay addr: ZZZ.ZZZ.ZZZ.ZZ:53921
10413: session 000000000000000002: new, realm=<example.org>, username=<1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>, lifetime=600
10413: session 000000000000000002: realm <example.org> user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>: incoming packet ALLOCATE processed, success
10431: session 003000000000000001: refreshed, realm=<example.org>, username=<1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>, lifetime=0
10431: session 003000000000000001: realm <example.org> user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>: incoming packet REFRESH processed, success
10431: session 003000000000000001: TCP socket closed remotely YY.YY.YYY.YYY:47483
10431: session 000000000000000002: refreshed, realm=<example.org>, username=<1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>, lifetime=0
10431: session 003000000000000001: closed (2nd stage), user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=> realm <example.org> origin <>, local ZZZ.ZZZ.ZZZ.ZZ:8443, remote YY.YY.YYY.YYY:47483, reason: TCP connection clos$
10431: session 000000000000000002: realm <example.org> user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>: incoming packet REFRESH processed, success
10431: session 003000000000000001: delete: realm=<example.org>, username=<1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>
10431: session 000000000000000002: TCP socket closed remotely YY.YY.YYY.YYY:46288
10431: session 000000000000000002: closed (2nd stage), user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=> realm <example.org> origin <>, local ZZZ.ZZZ.ZZZ.ZZ:8443, remote YY.YY.YYY.YYY:46288, reason: TCP connection clos$
10431: session 000000000000000002: delete: realm=<example.org>, username=<1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>
10431: session 000000000000000001: realm <example.org> user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>: incoming packet CREATE_PERMISSION processed, success
10431: IPv4. tcp or tls connected to: VVV.VVV.VVV.VVV:49465
10431: session 003000000000000002: realm <example.org> user <>: incoming packet message processed, error 401: Unauthorised
10431: session 003000000000000002: realm <example.org> user <>: incoming packet message processed, error 401: Unauthorised
10431: session 003000000000000002: realm <example.org> user <>: incoming packet message processed, error 401: Unauthorised
10432: IPv4. Local relay addr: ZZZ.ZZZ.ZZZ.ZZ:56244
10432: session 003000000000000002: new, realm=<example.org>, username=<1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>, lifetime=600
10432: session 003000000000000002: realm <example.org> user <1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>: incoming packet ALLOCATE processed, success
10432: session 003000000000000002: realm <example.org> user <1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>: incoming packet ALLOCATE processed, success
10432: session 003000000000000002: realm <example.org> user <1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>: incoming packet ALLOCATE processed, success
10432: session 000000000000000001: realm <example.org> user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>: incoming packet CREATE_PERMISSION processed, success
10433: session 003000000000000002: realm <example.org> user <1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>: incoming packet CREATE_PERMISSION processed, success
10433: session 003000000000000002: realm <example.org> user <1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>: incoming packet CREATE_PERMISSION processed, success
10433: session 003000000000000002: realm <example.org> user <1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>: incoming packet CREATE_PERMISSION processed, success
10433: session 003000000000000002: realm <example.org> user <1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>: incoming packet CHANNEL_BIND processed, success
10433: session 000000000000000001: realm <example.org> user <1486595151:7RdpBVvLfsj9I7pIuGvZqCTtyGxlUkuTBWkKMkGUkeU=>: incoming packet CHANNEL_BIND processed, success
10433: session 003000000000000002: realm <example.org> user <1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>: incoming packet CHANNEL_BIND processed, success
10433: session 003000000000000002: realm <example.org> user <1486595439:3hpEUPu+ixZjraLtjUsfZulx8kta8FUJUz3s2ul0e1w=>: incoming packet CHANNEL_BIND processed, success

This was just one short try, where I started the call. This time both of us could not see or hear each other.

leon · February 9, 2017, 9:26am

TURN logs look fine. incoming packet message processed, error 401: Unauthorised is not an issue, as it is always tried to authenticate without credentials first.

There are some other logs which you should take a look at:

Your browser’s developer console. Open Spreed WebRTC and append ?debug to the URL, e.g. https://myserver.com/apps/spreedme/?debug#myroom. Then make video / audio calls fail somehow and take a look at the browser developer console.
Your browser’s webrtc-internals page. Make video / audio calls fail and check chrome://webrtc-internals/ (Chrome) / about:webrtc (Firefox).

One of these logs should include some FAIL / ERROR messages.

MichaIng · February 9, 2017, 12:25pm

Okay, thanks for the advice, will do that as soon as I can.