Your message dated Thu, 23 Sep 2021 18:36:24 +0200 with message-id <20210923163624.kolgrrvknj235b2q@flashgordon> and subject line very rare or fixed by now has caused the Debian Bug report #961317, regarding coturn: TURN functunality silently fails after some time to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 961317: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961317 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---Hi, I am closing this report; the issue is either very rare or has been fixed by one of the updates. Regards, Andi
--- End Message ---
