Package: coturn
Version: 4.5.1.1-1.1
Severity: important
Dear Maintainer,
we run a webrtc-based WEB-conferencing application (BigBlueButton) and
a bunch of coturn STUN/TURN servers. After rare complaints of users
not beeing able to connect, we discovered that coturn silently looses
the TURN functionality after some time/randomly. As the STUN
functionality is still working fine, the issue is noticed only if a
user tries to connect from very restricted networks, were relaying is
needed.
In cases of failure, no 'relay' ICE candidates are received as it is
the case for a working TURN:
a=candidate:17 2 UDP 8200190 1.2.3.4 59679 typ relay raddr 1.2.3.4 rport
59679
^^^^^
Only 'host' and 'srflx' candidates show up (browser console).
We tried to find a simpler way to detect the misfunction which can be
scripted and found the following: If we use turnutils_uclient for a
working TURN server we immediately get (IP-addresses changed):
$ turnutils_uclient -v -t turn1.DOMAIN.TLD
0: IPv4. Connected from: 16.8.43.16:49146
0: IPv4. Connected to: 1.2.3.4:3478
0: allocate sent
0: allocate response received:
[…]
0: allocate sent
0: allocate response received:
0: Cannot complete Allocation
0: ERROR: Cannot complete Allocation
For a failing TURN server, the call takes several seconds and then
returns:
$ turnutils_uclient -v -t turn2.DOMAIN.TDL
0: IPv4. Connected from: 16.8.43.16:59848
0: IPv4. Connected to: 1.2.3.4:3478
0: allocate sent
0: allocate response received:
0: allocate sent
recv: Connection reset by peer
For the time being, we want to use this behavior to detect
misfuntioning TURN servers. The log shows no indication of something
going wrong. Any help to further debug and solve this issue is
appreciated.
Best regards, stay healthy
Andi
-- System Information:
coturn on debian stable
# grep -Ev "^(#|$)" /etc/turnserver.conf
syslog
listening-port=3478
tls-listening-port=443
fingerprint
lt-cred-mech
static-auth-secret=REMOVED
realm=DOMAIN.TLD
cert=/etc/letsencrypt/live/turn1.DOMAIN.TLD/fullchain.pem
pkey=/etc/letsencrypt/live/turn1.DOMAIN.TLD/privkey.pem
dh2066
no-tlsv1
no-tlsv1_1
