BigBlueButton (webRTC) Error 1007 - ICE negotiation failed

UCS@school
, ,
#1

Moin Elias mein Name :wave:
Da ich als “neuer” User keine Dateien hochladen darf und auch nicht mehr als 2 URLs posten darf bitte ich um Verständnis das einige URL ein bisschen zerstört wurden.

Hier die Problembeschreibung:

Ein Client der sich im UCS Netzwerk befindet versucht https:// test. bigbluebutton. org/ einer webRTC Session beizutreten.
Beim anklicken von “Wie möchten Sie der Konferenz beitreten?” > “Mit Mikrofon” kriegt der User den “Verbindungsfehler (1007)” welcher hier https:// docs. bigbluebutton .org/2.2/troubleshooting.html so definiert wird

1007: ICE negotiation failed - The browser and FreeSWITCH try to negotiate ports to use to stream the media and that negotiation failed. Possible Causes:
NAT is blocking the connection
Firewall is blocking the UDP connection/ports

Hier auch gerne das about:webRTC Logfile (Sorry darf als neuer User kein Datei hochladen)

Also auf zur Fehlersuche, aber dafür werden natürlich erst mal Informationen benötigt.

System Informationen

Hardware

HP ProLiant DL380p Gen8

  • 2 TB Festplatten
  • 220 GB RAM

UCS Version 4.4-3 errata455 (Ja update auf 4.4-4 wird noch gemacht :wink: )

App Center

  • UCS@school: Version 4.4 v4 kann auf 4.4 v5 aktualisiert werden
  • Rocket.Chat: Version 2.2.0 kann auf 3.0.2 aktualisiert werden
  • Nextcloud: Version 16.0.6-0 kann auf 17.0.2-0 aktualisiert werden

Kein Kommentar zu den Versionen bitte :slight_smile: Wird alles noch updated.

Netzwerk

Ganz grob:

WAN <=> pfSense <=> Intranet/UCS <=> UCS/Network DHCP <=> Client

pfSense

  • Schulnetz - 192.168.2.0 / 24
  • LAN_Managed_onBoard - 192.168.3.0 / 24
  • WAN_Telekom
  • WAN_Vodafone

UCS Netzwerk-Einstellungen

Domäne Netzwerk / DHCP

10.10.0.0 / 16

17 Pools a / 24 Maske

z.B. 10.10.101.1 - 10.10.101.254 (Unknown Clients)

Firewall Rules

Anhand von http://docs.bigbluebutton.org/2.2/configure-firewall.html#Configure_Firewall_

When BigBlueButton is protected behind a firewall, you need to configure the firewall to forward the following incoming connections to BigBlueButton:

TCP/IP port 22 (for SSH)
TCP/IP ports 80/443 (for HTTP/HTTPS)
UDP ports in the range 16384 - 32768 (for FreeSWITCH/HTML5 RTP streams)

Habe ich für mich abgeleitet das die Portrange 16384:32768 UDP auch in UCS erlaubt werden muss.

ucr set security/packetfilter/udp/16384:32768/all="ACCEPT"
service univention-firewall restart

$ iptables -L | grep -i "16384"
ACCEPT     udp  --  anywhere             anywhere             udp dpts:16384:32768

Die pfSense hat folgende NAT Outbound Rules:

Ich weiß also gerade echt nicht mehr weiter und hoffe das mir hier einer der vielen schlauen Köpfe weiterhelfen kann.

Cheers und danke für die Aufmerksamkeit,
Elias :beers:

ps: Sollten weitere Informationen benötigt werden stelle ich diese gerne zur Verfügung.

#2

Should I translate it all to englisch?

Bump

#3

Guten Morgen,

aus meiner Sicht kann das eigentlich nichts mit UCS zu tun haben.
Das hat wahrscheinlich etwas mit den Regeln auf der pfSense zu tun.
Da bin ich aber leider überfragt.
Ich glaube wir müssen dazu auf jemanden warten, der etwas mehr Wissen über die pfSense hat oder vielleicht solltest du dort nochmal nachfragen?

VG
Michel

1 Like
#4

Vielen dank für deine Antwort.

Vermute ich auch.
Werde heute den Traffic genauer analysieren.

Wenn ich etwas gefunden habe - oder die Lösung finde werde ich dies natürlich hier melden :slight_smile:

#5

Hi,

vielleicht probierst du einmal den Abschnitt “Testing the firewall” in der von dir verlinkten BBB-Doku.
Das netcat kannst du mit univention-install netcat auf dem UCS-Server installieren.
Wenn du das von dort testest kannst du ggf. auch verifizieren, dass es mit der Firewall zu tun hat.

VG
Michel

1 Like
#6

Hi, du könntest mit tcpdump beim Browser und beim BBB-Server überprüfen, ob die IP-Adressen stimmen. Bei NAT muss normalerweise via ICE eine geeignete IP-Adresse ermittelt werden, über die dann der WebRTC-Traffic erfolgt. Manchmal kann man irgendwo eine Übersetzung von interner zu externer IP-Adresse angeben, manchmal ist die Benutzung eines STUN-Servers erforderlich. Da du zwei Outbound Rules hast, liegt die Vermutung nahe, dass da irgendwas durcheinander kommt.

1 Like
#7

Ich habe jetzt auch mal mit diesen Tool mal getestet ob man überhaupt eine Verbindung zu TURN/STUN bekommt.

TURN / STUN Server

turn:turn.zitronenblau.de:443?transport=tcp
stun:turn.zitronenblau.de:443?transport=tcp

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

Mit diesen Ergebnis

Time 	Component 	Type 	Foundation 	Protocol 	Address 	Port 	Priority
0.007	1	host	0	udp	10.10.25.198	56195	126 | 32512 | 255
0.008	1	host	1	tcp	10.10.25.198	9	125 | 32704 | 255
0.008	2	host	0	udp	10.10.25.198	56196	126 | 32512 | 254
0.008	2	host	1	tcp	10.10.25.198	9	125 | 32704 | 254
12.830	Done
#8

Nach vielen weiteren testen…

Neue vermutung das der Proxy / Squid (Habe ich wohl nicht oben erwähnt das der mit dabei ist) das Problem ist.

Habe auch die URLs jetzt schon “whitelisted”

ucr set squid/acl/test_bigbluebutton_org/allow/dstdomain-i/regex="test\.bigbluebutton\.org"

Gleiches auch für die stun und turn server.

#9

Die Fehlermeldung ist auch in der Dokumentation von BBB aufgeführt:

1007: ICE negotiation failed - The browser and FreeSWITCH try to negotiate ports to use to stream the media and that negotiation failed. Possible Causes:

NAT is blocking the connection
Firewall is blocking the UDP connection/ports

https://docs.bigbluebutton.org/2.2/troubleshooting.html

Nötige Ports und weitere Infos/Hilfen stehen ebenfalls in der Doku:
http://docs.bigbluebutton.org/2.2/configure-firewall

Dort gibt es außerdem noch folgende Info bzgl. des Fehlers 1007:

For Error 1007, it means that the web socket connect was successful (FreeSWITCH is running and received the request from the browser to setup a media path), but none of the IP/Port combinations returned by FreeSWITCH enabled the browser to connect and start transmitting media. To diagnose this error, open about:webrtc in FireFox and click ‘show details’ for the most recent connection. Look under the column Remote Candidate and check if you see the internal IP address of the BigBlueButton server. If so, you probably have a misconfiguration in the FreeSWITCH settings. Re-check against the examples shown above.

VG

#10

Habe das Problem gelöst nach mehreren sehr langen Session mit Wireshark und debugging von allen verwendeten Tools.

Der coturn Server war das Problem. Er soll eigentlich genau in solchen Netzwerken helfen hat aber genau das gegenteil gebracht.

Was ist passiert.

Der Coturn Server war so Konfiguriert das er sich an das Interface eth0 mit IPv4 und IPv6 binded hat.
Der DNS Record für den Coturn hatte auch IPv4 und IPv6 und rDNS für beide.
Gut oder? Nein!

BigBlueButton mag IPv6 nämlich überhaupt nicht.

BigBlueButton merkt das er nicht weiter kommt und versucht den Turnserver zu verwenden.
Startet eine UDP Verbindung mit turn.domain.tld mit IPv4 dieser bekommt die Anfrage und Antwortet aber mit UDP IPv6.

Da steigt BigBlueButton einfach aus und macht nicht weiter.

TL;DR - Englisch

Problem was that the coturn was binding to IPv6 and IPv4.
Since BigBlueButton dislikes IPv6 edit the coturn config to only bind the IPv4

#11

ich habe v6 und v4 eingerichtet und bei mir geht es ohne Probleme. Allerdings muss ich zugeben, nicht wirklich alles verstanden zu haben. Ich erinnere mich, dass die Probleme, die ich vorher mit webRTC hatte erst dann weggingen, nachdem ich v6 nachträglcih als AAAA im DNS hinterlegt hatte, eben weil BBB auch einen v6 Eintrag hatte. Ich hatte Probleme an anderer Stelle verortet, nämlich den Clients bzw. Anschlüssen, die schon auf v6 laufen und nach v6 übersetzt werden (z.B. im Vodafone Netz). Aber wie gesagt, ich habe einfach durch Probieren gelöst.

Mastodon