Fehlerbericht User

Audio- oder Videoverbindung über fairmeeting/Jitsi meet funktioniert nicht:

• aktuellster Firefox, alle Add-ons (uBlock, uMatrix etc.) deaktiviert.
• Auch auf niedrigster Qualitätseinstellung. Dabei sitzen beide Rechner an einem guten LAN.
• talky.io funktioniert hingegen alles
• ich denk immer es liegt an meinen codecs unter linux mit firefox. aber nachdem talky.io funktioniert hat, bin ich mir da nicht mehr so sicher.
• Problem: Ich seh mich immer nur selbst, meine Gesprächspartnerin sieht immer nur sich selbst. Wenn wir was in den Chat schreiben, können wir die eigenen Nachrichten nicht sehen und auch nicht die es anderen. Und es wird ständig von Connectivity Issues geschrieben und die Verbindung bleibt schwarz. Probleme bei reinem Audio als auch Video
• Zeit: 11.3.2019 ab 11Uhr eine halbe - 3/4h
• User verwendet Systeme fast komplett freie Software/ Hardware
• Jitsi meet https://meet.jit.si/ hat auch nicht funktioniert, app wurde nicht getestet

changed the description

assigned to @roland.alton

Sind beide Rechner im selben LAN? Dann ist es ein Firewall Issue, welche die WebRTC Media Streams bündelt.

Auf jeden Fall sollten die Ports UDP 10000-20000 offen sein.

Sind beide Rechner im selben LAN? Dann ist es ein Firewall Issue, welche die WebRTC Media Streams bündelt.

->> nein, sind sie nicht. völlig unabhängige anschlüsse. mit einer zweiten verbindung mit einer anderen person: gleiches problem. keine verbindung.

Auf jeden Fall sollten die Ports UDP 10000-20000 offen sein.

->> wo genau kann ich das checken? warum sollten sie standardmäßig nicht offen sein?

In manchen Büros oder bei manchen Routern sind nicht alle Ports offen.

Das lässt sich von einem Linux Rechner zB mit netcat so testen

nc -vuz fairmeeting.net 10000
Connection to fairmeeting.net 10000 port [udp/*] succeeded!

Zusätzlich steht nun der immer offene Port 443 für fairmeeting Konferenzverbindungen zur Verfügung #31 (closed) - die Übertragungsqualität ist gegenüber UDP Ports jedoch mitunter eingeschränkt. Bitte testen.

Bin @home nicht im Büro. An einer aktuellen FRITZ!Box 7590.

nc -vuz fairmeeting.net 10000

gibt bei mir kein Ergebnis unter Ubuntu 18.04. Einfach nur eine leere neue Zeile mit Prompt im Terminal.

Wie und wo kann ich das mit UDP testen?

Wir haben seit gestern eine zusätzliche IP Adresse für Media Streams. Damit gehen nun auch Konferenzen wenn nur Port 443 offen ist.

UDP Test nun mit:

nc -vuz media.fairmeeting.net 10000
Connection to media.fairmeeting.net 10000 port [udp/*] succeeded!

Hi, nc -vuz media.fairmeeting.net 10000 gibt plötzlich folgendes aus: "Connection to media.fairmeeting.net 10000 port [udp/*] succeeded!" ebenso bei Port 80. Aber bei Port 443 erhalte ich wieder kein Ergebnis.

Besteht eine Möglichkeit mit dir kurz zu testen? Und inwiefern kann die FRITZ!Box für den Fehler verantwortlich sein?

TCP Ports (wie 443) testet man anders -> man nc

Wir sind bis Ende nächster Woche ausgebucht, können da jetzt keine Tests mehr einschieben.

sorry, bin user kein techniker. man nc sagt mir also nichts. habe ja auch nur gefragt, ob es die möglichkeit gibt. nicht gesagt wann. frage mich nun, ob eure änderung was bewirkt hat. und immer noch: ob der router einen einfluss haben kann und welchen und wie ich das herausfinde.

nc -vz media.fairmeeting.net 443
Connection to media.fairmeeting.net 443 port [tcp/https] succeeded!

(ohne u, das steht für UDP Protokoll, ws bei media streams bevorzugt wird)

also UDP scheint ja ohnehin zu klappen, dann sollte fairmeeting auf deiner seite auch funktionieren.

ich bin jetzt mal kurz im raum https://fairmeeting.net/fairkom falls du eben gerade testen möchtest

@roland.alton

nc -vz media.fairmeeting.net 443 Connection to media.fairmeeting.net 443 port [tcp/https] succeeded!

auch bei mir. Habe gerade den Weg in den Raum gefunden. Hatte wohl leider keine Benachrichtigung eingestellt. Wäre ja wunderbar wenns klappt, frage mich jedoch, was sich dann in den letzten zwei Wochen entscheidend verändert hat. Von meiner Seite aus nur der Wechsel von FRITZ!Box 7390 zu FRITZ!Box 7590. Hatten immer Verbindungsabbrüche beim VOIP Anschluss. Allerdings hat ein anderer Rechner im gleichen Haushalt bereits zuvor mit altem Router fairmeeting nutzen können. Deswegen hatte ich gedacht es liegt an meinem Gerät bzw. dessen Einstellungen.

Test mit User war erfolglos. Bis auf chatten via fairmeeting kam vom User nichts an. Verbindungsstatus des Users: Verloren. Fairmeeting mit weiteren Test-user (S.K) über App funktionierte einwandfrei. Auch der Test mit dem User in einen Jitsi Raum funktioniert (!)

Das ist wohl ein sehr spezifisches Problem mit dem Router und dem DSL Anschluss. Wie viele Pakete gehen verloren? Bitte am Terminal eingeben:

ping board.net
Ctrl-C

Funktioniert es alternativ mit der Jitsi Meet Smartphone App? Im selben Wlan? Und per 3G Verbindung? Wenn ja, liegt es möglicherweise am LAN Kabel oder einem Stecker.

--- board.net ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 16.913/17.551/18.991/0.707 ms

(wlan)

--- board.net ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 15.565/16.380/18.207/0.852 ms

(lan)

ich habe kein smartphone zum testen.

zum kabel: das problem existiert ja auch gleichermaßen beim wlan. oder meinst du das dsl kabel des routers bzw. dessen stecker? das lan kabel ist nämlich ein brandneues. ebenso wie der router frisch ausgepackt ist.

test mit zwei desktop-geräten im eigenen wlan: ich sehe, dass noch ein anderer fairchatter im raum ist, die kleinen balken sind grün und sagen gute verbindung, aber es wir keine video verbindung aufgebaut.

JVB 2019-03-29 19:31:48.776 WARNING: [87] org.jitsi.videobridge.EndpointMessageTransport.log() SCTP connection with cc049023 not ready yet.
JVB 2019-03-29 19:31:48.777 WARNING: [87] org.jitsi.videobridge.EndpointMessageTransport.log() No available transport channel, can't send a message

dann blockiert euer router wohl udp media pakete im WebRTC Modus oder der Router ist kaskadiert sodass wegen der maskierung keine routing aufgebaut werden kann. das ginge vielleicht mit einem zusätzlichen turn server.

WebRTC wird nur bei Zweier Verbindungen aktiviert und haben wir jetzt mal deaktiviert.

bitte nochmal testen.

https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publication/show/57_Sicherheitsfunktionen-Firewall-der-FRITZ-Box/

auf der ebene fremder router könnten wir weiteren support nur kostenpflichtig anbieten. wir bräuchten dazu vollen zugang, das ginge vermutlich auch nur vor ort.