BigBlueButton und Fehler 1020

101

Hi @All,
habe mir meine turn-stun-servers.xml angeschaut und gesehen das jeweils die gleichen Ports eingetragen sind.
Vom Anbieter habe ich folgende Daten erhalten:
listening-port…: 3478
tls-listening-port.: 5349

Müsste nicht statt 5349 der Port 3478 bei value="turns:cortun.blabla.de:5349?transport=tcp stehen?

Ich poste mal meine turn-stun-servers.xml:

<?xml version="1.0" encoding="UTF-8"?> 
<bean id="stun0" class="org.bigbluebutton.web.services.turn.StunServer">
    <constructor-arg index="0" value="stun:cortun.elearning-moodle.de:443"/>
</bean>


<bean id="turn0" class="org.bigbluebutton.web.services.turn.TurnServer">
    <constructor-arg index="0" value="xxxxxxxxx"/>
    <constructor-arg index="1" value="turns:cortun.blabla.de:5349?transport=tcp"/>
    <constructor-arg index="2" value="86400"/>
</bean>

<bean id="turn1" class="org.bigbluebutton.web.services.turn.TurnServer">
    <constructor-arg index="0" value="xxxxxxxxx"/>
    <constructor-arg index="1" value="turn:cortun.blabla.de:5349?transport=tcp"/>
    <constructor-arg index="2" value="86400"/>
</bean>

<bean id="stunTurnService"
        class="org.bigbluebutton.web.services.turn.StunTurnService">
    <property name="stunServers">
        <set>
            <ref bean="stun0"/>
        </set>
    </property>
    <property name="turnServers">
        <set>
            <ref bean="turn0"/>
            <ref bean="turn1"/>
        </set>
    </property>
</bean>
102

Hallo Harald,

ich hab bei der turns-Konfiguration in beiden Füllen 443 stehen. Also
<constructor-arg index=„1" value=turns:coturn.blabla.de:443?transport=tcp“/>

Und zwar in beiden turn-Konfigurationen (turn0 und turn1).

Vielleicht gehts mit der Portumbenennung?

Herzliche Grüße
Marcus

103

Hallo Marcus,
danke für deinen Hinweis, was steht bei den anderen Coturn-Admins in deren turn-stun-servers.xml?

Kurze Rückmeldung wäre super.
VG Andre

104

Aber gleiches Ursachenproblem, der turn Schlund lauscht auf nur auf ipv4 und nicht auf ipv6.

105

Ein Hund, der Schlund, …

106

Hallo Marcus,
du meintest Andre, oder?
Also bei mir steht auch bei beiden 443 drin, sowohl bei turn als auch bei turns.
Liebe Grüße
Harald

107

Hallo Harald,

jepp, ich meinte Andre.

Sorry. Waren wohl zu viele Posts dieses WE.

Grüße
Marcus

108

Hallo Harald, hallo Marcus,
dachte mir gestern auch schon dass gemeint bin :wink:

VG Andre

109

Von dem Fehler 1020 berichten nun auch mehr und mehr User ohne Apple Geräte… Ein Kollegin berichtet bspw., seit sie einen neuen Router hat, tritt der Fehler auf.

110

Hallo,
ich habe vereinzelt auch Schüler, die das Problem mit anderen Geräten betrifft. Meistens hilft eine dieser drei Lösungen:

  • an der Firewall die entsprechenden UDP-Ports (16384-32768) öffnen
  • am Router DualStack ausschalten
  • am Rechner IPv6 zu deaktivieren

Viele Grüße
Harald

PS: an iPads / iPhones kann man IPv6 nicht deaktivieren, das ist Teil des Problems…

111

Welcher Turn Server wird benutzt? Generell bentuzen IOS Geräte immer den Turn Server, andere immer nur dann wenn beispielsweise die Firewall die Verbindung blockiert. Dann wird durch den Port des Turn Servers getunnelt, bei Linuxmuster wird der 443 genutzt. Optimalerweise ist in der beans.xml auf dem BBB noch eingestellt, das tcp benutzt wird, dann kann die Firewall, wenn sie keine DeepPacketInspection betreibt, die Packete nicht von anderen https Paketen unterscheiden und lässt sie durch.

Dann wäre noch interessant, an was für einen Zugang die Personen haben. DS Lite, DS oder IPv4 only. Taucht derezeit alles auf. Ich persönlich kann sagen, dass der Linuxmuster Turn mit einem DS zugang ohne Probleme funktioniert. Ich habe heute den Linusmuster Turn im EInsatz gehbt und heute keine negative Rückmeldung bekommen.

LG Sebastian

PS: Ich habe auch den 1020er mal bekommen, als ich per Edge ne sehr miese Anbindung hatte. Auch bei viel PacketLoss tritt der 1020er auf.

112

Welcher Turn nutzt du und wie sieht deine config auf dem BBB diesbezüglich aus?

113

Hallo Bellm,

ich habe zwei mit dem bbb-Skript selbstinstallierte Turn-Server, die ich bei BBB eingetragen habe.
Dabei habe ich mehrere Optionen getestet: Ich habe einen Turnserver mit IPv6 und einen, der keinen IPv6-Record hat. Ich habe wechselweise beide (bei denen sowohl der stuntman-client-Test und der Test hier funkioniert) eingetragen, aber auch jeweils nur einen von beiden.

Mit netstat -antp | grep 443 bzw. netstat -antp | grep 80 bekomme ich eine Meldung, die darauf schließen lässt, dass bei den Turnservern auf beiden Ports gelauscht wird, bbb-conf --check am BBB-Server bekomme ich keine Fehler gemeldet.

In Firefox habe ich beim WebRTC-Text aber unterschiedliche Nachrichten, im günstigsten Fall habe ich bei ICE-Status vier- bis sechsmal "„succeeded“ und zwei- bis viermal „cancelled“.

Irgendetwas anderes muss da schief laufen, aber ich habe keine Ahnung mehr, was es sein könnte.

Liebe Grüße

Harald

114

Hallo Harald,
bbb–conf prüft meines Wissens nicht auf funktionierende Turn server. Wie sieht deine xml beans auf dem BBB aus?
Warum lauscht turn bei dir auf 80? KAnn der Turn auch intern auf die Zertifikate zugreifen?

LG Sebastian

115

Hallo Sebastian,
nein, bbb-conf sieht nur nach, ob korrekte Werte eingetragen sind, nehme ich an.
Übrigens kommt da auch eine Fehlermeldung, wenn die in /usr/share/bbb-web/WEB-INF/classes/spring/turn-stun-servers.xml ein Fehler ist (also irgendein Syntax-Error). Du meinst diese Datei mit xml beans, oder? Sie sieht so aus:

<?xml version="1.0" encoding="UTF-8"?> 
<bean id="stun0" class="org.bigbluebutton.web.services.turn.StunServer">
    <constructor-arg index="0" value="stun:turn-server1.de"/>
</bean>

<bean id="stun1" class="org.bigbluebutton.web.services.turn.StunServer">
    <constructor-arg index="0" value="stun:turn-server2.de.de"/>
</bean>

<bean id="turn0" class="org.bigbluebutton.web.services.turn.TurnServer">
    <constructor-arg index="0" value="secretServer1"/>
    <constructor-arg index="1" value="turns:turn-server1.de:443?transport=tcp"/>
    <constructor-arg index="2" value="86400"/>
</bean>

<bean id="turn1" class="org.bigbluebutton.web.services.turn.TurnServer">
    <constructor-arg index="0" value="secretServer1"/>
    <constructor-arg index="1" value="turn:turn-server1.de:443?transport=tcp"/>
    <constructor-arg index="2" value="86400"/>
</bean>

<bean id="turn2" class="org.bigbluebutton.web.services.turn.TurnServer">
    <constructor-arg index="0" value="secretServer2"/>
    <constructor-arg index="1" value="turns:turn-server2.de.de:443?transport=tcp"/>
    <constructor-arg index="2" value="86400"/>
</bean>

<bean id="turn3" class="org.bigbluebutton.web.services.turn.TurnServer">
    <constructor-arg index="0" value="secretServer2"/>
    <constructor-arg index="1" value="turn:turn-server2.de.de:443?transport=tcp"/>
    <constructor-arg index="2" value="86400"/>
</bean>

<bean id="stunTurnService"
        class="org.bigbluebutton.web.services.turn.StunTurnService">
    <property name="stunServers">
        <set>
            <ref bean="stun0"/>
            <ref bean="stun1"/>
        </set>
    </property>
    <property name="turnServers">
        <set>
            <ref bean="turn0"/>
            <ref bean="turn1"/>
            <ref bean="turn2"/>
            <ref bean="turn3"/>
        </set>
    </property>
</bean>

Übrigens hat ein testweises Eintragen des Schlund-Stun-Servers keine Änderung gebracht.

Vielen Dank für deine Hilfe!

Liebe Grüße

Harald

116

Ach und das Lauschen auf Port 80 des Stun-/Turn-Servers wurde durch das Skript automatisch veranlasst, das habe ich nicht geändert…

117

Komisch… port 80 wird ja eignetlich gar nicht gebraucht, ich habe es per Hand von hier gemacht…