WebRTC kein Audio und Video (onsite)

flashtec · June 19, 2020, 8:05am

Hallo allesamt,

mal wieder ein Problem meinerseits.
Der Zugríff von Außerhalb via webRTC funktioniert noch nicht.
Alle Ports (laut Dokumentation) wurden zur Pascom weitergeleitet und ein Zugriff auf die Anlage ist generell möglich. Nach außen gibt es seitens der Firewall keine Einschränkungen. Jedoch bekomme ich die Meldungen, dass Audio und Video nicht zum Server übertragen werden können…

gnome-shell-screenshot-UBDKM0

Die Pascom teilt mit wärenddessen folgendes mit:

Hat jemand eine Idee, wie es ich das in den Griff gekommen kann?

rapha · June 19, 2020, 8:10am

Habe das selbe Problem, allerdings habe ich einen HAproxy vorgeschaltet.
Bin noch nicht dazu gekommen Ursachenforschung zu betreiben.

Gruß,
Rapha

flashtec · June 22, 2020, 1:39pm

Hallo Rapha,

Ich würde mich über eine Rückmeldung freuen falls du was neues heraus bekommen hast.
Bei mir geht es leider nicht weiter.

tweber · June 23, 2020, 8:07am

Hallo,

@flashtec:

hast möglicherweise ein Split-DNS Setup?
Funktioniert das Video denn intern?
Funktioniert Video übers Internet via pascom Client anstatt Webclient?

Gruß,

Thomas

flashtec · June 24, 2020, 7:10am

Hallo Thomas,

die Situation beim Kunden ist wie folgt:

Der Kunde hat 2 Gateways, eines bei Unitymedia und eines bei der Deutschen Telekom. Die Schnittstellen der PBX (eine für extern und eine für intern) sind per Firewall an das Gateway der Telekom gebunden. Es wird für den Verkehr nach außen ausschließlich der Telekomanschluss verwendet.

Die Anlage:
Schnittstelle 1:
IP= x.x.x.50
FQDN=interne Adresse

Schnittstelle 2
IP=x.x.x.51
FQDN=tel.kunde.de.

Die Subdomain zeigt auf die feste IP des Telekomanschlusses.

XMPP auf beiden Interfaces aktiviert, Mobile Pairing nur auf dem mit IP 51

Somit ist nach meinem Empfinden Split-DNS ausgeschlossen.

Das Video und Audio intern funktioniert einwandfrei, keinerlei Störungen.

Client zu Client via Internet funktioniert nur per Audio, keine Videoübertragung möglich.

croeser · June 25, 2020, 7:05am

Moin moin,

ich habe das gleiche Problem. Wir wollen von der 17er auf 19er umsteigen, dafür habe ich die Anlage neu aufgesetzt.

Nachdem wir Probleme mit der Audioübertragung hatten haben wir das Netzwerk nach Howto eingerichtet, der Aufbau ist identisch mit dem von Flashtec. Intern funktioniert zwischen den Clients Audio und Video, sobald jedoch ein Client extern ist funktioniert nur noch Audio. Video über den Browser schlägt mit der Meldung wie von Flashtec gepostet fehl.

Firewall ist eine pfsense, es werden die TCP Ports 80, 443, 636, 5061, 5222, 19302 (inklusive UDP) und die UDP Ports 3478, 30000-35000 weitergeleitet.

Gruß
Christian

Edit: wir haben es gestern mit der 19.08 getestet

Linuxuser · June 25, 2020, 12:56pm

@croeser

Wir schaffen mit pascom 19.06-08 und OPNSense Video Übertragung von extern mit Safari, Edge und Chrome. Aber beim FF wird kein Bild übertragen.

Intern geht es und mit einer Endian FW klappt es auch, nur bei der OPNSense nicht.

Vielleicht sollten wir mal alle unsere Einstellungen vergleichen…

rapha · June 25, 2020, 1:28pm

Dann fange ich mal an, vielleicht fällt ja sofort etwas auf.

Firewall: pfsense 2.4.5-RELEASE

Mir fällt schonmal auf habe Ports 35001…35500/udp für RTP offen. Da der Webclient aber 19302 nutzt ist das wohl in diesem Fall uninteressant.

Dann Sonderfall: Verwende den HAproxy der pfsense. Zertifikat ist von der pascom kopiert und im HAproxy hinterlegt (wenigestens Testweise). Der Browser meckert auch nicht und das Zertifikat ist jenes der pascom und gültig.

Diese Options werden zusätzlich vom HAproxy an pascom übergeben, andere Web-Apps funktionieren problemlos:

http-response set-header X-Xss-Protection 1;\ mode=block
http-response set-header X-Robots-Tag noindex
http-response set-header X-Frame-Options SAMEORIGIN
http-response set-header Referrer-Policy same-origin

Gruß,
Rapha

croeser · June 26, 2020, 9:14am

Hallo,

ich habe die Anlage heute hinter einen Lancom Router “gehängt”, leider zeigt sich hier das gleiche Fehlerbild. Meine Einstellungen scheinen, bis auf die RTP Ports, identisch zu sein. Vielleicht machen wir den gleichen Fehler?

Gruß
Christian

rapha · June 26, 2020, 12:44pm

Das sieht schon sehr ähnlich aus, werde den WebClient morgen mal “auseinandernehmen”

Gruß,
Rapha

Linuxuser · June 26, 2020, 3:29pm

So und hier mal meine Einstellungen

Die Nat-Regeln sind alle “NAT Reflection = Use default”. Wir glauben, dass es vielleicht hier mit dem FF zu Problemen kommt, haben aber noch keine konkrete Idee.

Wir haben aktuell 2 Interfaces aktiv, da wir intern noch alte SNOMs ohne “D” benutzen, diese arbeiten ohne SRTP.

@rapha
Da bin ich mal gespannt.

Gruß

PascomNewbie · June 27, 2020, 4:35am

Braucht es hier nicht vielleicht auch einen externen STUN/TURN Server? Wegen der NAT Thematik?

rapha · June 27, 2020, 11:06am

Moin zusammen,
mal ein Zwischenbericht.

STUN/TURN wird für den Webclient genutzt (Audio und Video, Port 3478/udp), die Streams werden als ChannelData TURN message übertragen.

Folgenden Ablauf habe ich beobachtet:

Webclient baut Verbindung zum Server auf (HTTPS@pascom) und lädt die App
Webclient öffnen einen Websocket (auf /api); Es werden Session-Daten übertragen (IPs usw.)
Webclient baut STUN-Session auf, es werden Audio und Video übertragen

Soweit so gut.

Nach 30 Sekunden wird die Verbindung vom Webclient geschlossen (STUN Refresh Request lifetime:0), pascom antwortet mit Success. Dies ist also kein Timeout auf STUN/TURN-Seite (evtl. mein HAproxy).
HAproxy “client timeout = 120000” (120s) eingestellt; Verbindung wird nach ~60 Sekunden sauber geschlossen (wie oben). Also eher client-seitiger Timeout (Webclient App?)

Was habe ich bis dahin gemacht?
- NAT-Regel der Firewall geändert: 443/tcp -> IP der pascom vom 1. Interface (war 2. Interface)
- NAT-Regel der Firewall geändert: 3478/udp -> IP der pascom vom 1. Interface (war 2. Interface)

@pascom
Ich wünsche mir ein Ping-Pong zwischen Webclient und pascom (evtl. im WebSocket, habe dies schon öfter so gesehen) um gewissen Server- und Client-Timeouts zu unterbinden. Wäre soetwas möglich?

Edit: Auf 19302/tcp oder /udp habe ich keine Daten gesehen (nur pascom Client?)

Edit: Im internen Netzwerk bleibt die Verbindung stabil (ohne NAT/Routing)

Edit: Im Gast-Netzwerk (via NAT-Reflection der pfsense) wird die Verbindung nach 60s abgebaut (ohne STUN/TURN timeout, wie oben)

Gruß,
Rapha

dboehm · June 27, 2020, 11:34am

Ich habe auch zwei Onsite Anlagen die das selbe Problem aufweisen.

Beide nutzen eine Kerio Firewall. Kein Proxy dazwischen. Genau das gleiche. Verbindung wird aufgebaut und nach ca. 30 Sekunden kommt die Fehlermeldung. Intern läuft alles auch über VPN.
Beide haben zwei Interfaces. 1 für intern (alte Snom Telefone) und eine für extern.

Habe bei einer Installation die ganze UDP Port Range aufgemacht. Seltsamerweise ging es dann mal kurz. Vermutlich ein Zufall . Hatte dann abgebrochen aus Zeitmangel.

Wollte mal nächste Woche das genauer prüfen.

croeser · June 29, 2020, 1:31pm

Hallo,

ich habe heute das zweite Interface entfernt und die Anlage wieder auf die pfsense umgestellt. Seitdem funktioniert die Videotelefonie intern<->extern mittels pascom Client von Mobiltelefon und Notebook, den Webclient konnte ich noch nicht testen.

Gruß
Christian

Edit: mit dem neuen Edge erfolgreich getestet. Mit Firefox 68.9.0esr hatten wir kurz ein Bild, allerdings im späteren Testverlauf wurde der Gesprächspartner oder Desktop nicht mehr angezeigt sondern es war nur noch ein schwarzes Bild zu sehen.

rapha · June 29, 2020, 2:14pm

Das kann ich soweit bestätigen, funktioniert hier auch.

Der Webclient gibt nach 60s auf; Es kommt vom Server (pascom) ein “Encrypted Alert” und daraufhin werden die HTTP- und STUN-Session abgebaut.

Hier mal der relevante Abschnitt aus Wireshark, vielleicht hat jemand eine Idee.
pascom: 185.55.x.x
Webclient im Chrome: 192.168.8.101

Gruß,
Rapha

Linuxuser · July 21, 2020, 12:24pm

Also seit dem Update auf 19.08 hat es bei unserer eigenen Pascom mit OPNSense keine Probleme mehr gegeben, nun geht auch FF als WEBRTC Browser.

Jedoch bei einem Kunden mit OPNSense und Pascom 19.08 Onsite klappt intern und extern mit dem Pascom Client (Video + Audio) aber von extern klappt WEBRTC nicht!

Wenn ich mich mit FF oder Chrome verbinde, sehe ich zwar das Video des Pascom Benutzers aber nach 10 Sekunden wird der Stream abgebrochen mit der Info, dass Audio nicht übertragen werden konnte. Was wir noch nicht verstehen, warum Video geht und Audio nicht?!

Randinfo:
Wenn wir uns mit WEBRTC verbinden und noch kein Pascom User hat die Session gestartet, hören wir auch nicht die Willkommensinfo sondern nur eine Rückkopplung.

Alle UDP und TCP Ports sind per DNAT offen und nach draußen blocken wir nix. Wir haben nur eine Schnitstelle.

Hier mal ein Vergleich
Blick auf dem Cluster wo die Pascom als VM läuft

Funktioniert
,-------
| root@scratchy 7.0:~# tshark -lni br201 port 3478 | grep -v “TURN Message”
| Running as user “root” and group “root”. This could be dangerous.
| Capturing on ‘br201’
| 1 0.000000000 XX.XX.3.146 → 10.200.1.2 STUN 62 Binding Request
| 2 0.000414848 10.200.1.2 → XX.XX.3.146 STUN 138 Binding Success Response XOR-MAPPED-ADDRESS: XX.XX.3.146:18685 MAPPED-ADDRESS: XX.XX.3.146:18685 RESPONSE-ORIGIN: XX.XX.157.230:3478
| 3 0.040198494 XX.XX.3.146 → 10.200.1.2 STUN 70 Allocate Request UDP
| 4 0.040384416 10.200.1.2 → XX.XX.3.146 STUN 154 Allocate Error Response error-code: 401 (Unauthorized) Unauthorized with nonce realm: pascom
| 5 0.108630367 XX.XX.3.146 → 10.200.1.2 STUN 166 Allocate Request UDP user: 1595264828-client_contacts_guest-83 realm: pascom with nonce
| 6 0.109303959 10.200.1.2 → XX.XX.3.146 STUN 158 Allocate Success Response XOR-RELAYED-ADDRESS: XX.XX.157.230:34547 XOR-MAPPED-ADDRESS: XX.XX.3.146:18685 lifetime: 600
| 7 0.220292187 XX.XX.3.146 → 10.200.1.2 STUN 170 CreatePermission Request XOR-PEER-ADDRESS: 10.0.3.170:40593 user: 1595264828-client_contacts_guest-83 realm: pascom with nonce
| 8 0.220316779 XX.XX.3.146 → 10.200.1.2 STUN 170 CreatePermission Request XOR-PEER-ADDRESS: XX.XX.157.230:5780 user: 1595264828-client_contacts_guest-83 realm: pascom with nonce
| 9 0.220513251 10.200.1.2 → XX.XX.3.146 STUN 126 CreatePermission Success Response
| 10 0.220567635 10.200.1.2 → XX.XX.3.146 STUN 126 CreatePermission Success Response
| 11 0.431199820 XX.XX.3.146 → 10.200.1.2 STUN 178 Send Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 12 0.431720791 10.200.1.2 → XX.XX.3.146 STUN 198 Data Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 13 0.442896647 10.200.1.2 → XX.XX.3.146 STUN 206 Data Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 14 0.488779027 XX.XX.3.146 → 10.200.1.2 STUN 178 Send Indication XOR-PEER-ADDRESS: XX.XX.157.230:5780
| 15 0.520202990 XX.XX.3.146 → 10.200.1.2 STUN 142 Send Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 16 0.520660740 10.200.1.2 → XX.XX.3.146 STUN 146 Data Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 17 0.520832407 10.200.1.2 → XX.XX.3.146 STUN 414 Data Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 18 0.540231515 XX.XX.3.146 → 10.200.1.2 STUN 178 Send Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 19 0.540603497 10.200.1.2 → XX.XX.3.146 STUN 198 Data Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 20 0.590266788 XX.XX.3.146 → 10.200.1.2 STUN 178 Send Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 21 0.590678890 10.200.1.2 → XX.XX.3.146 STUN 198 Data Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 22 0.607303199 XX.XX.3.146 → 10.200.1.2 STUN 178 Channel-Bind Request ChannelNumber=0x4000 XOR-PEER-ADDRESS: 10.0.3.170:40593 user: 1595264828-client_contacts_guest-83 realm: pascom with nonce
| 23 0.607316634 XX.XX.3.146 → 10.200.1.2 STUN 726 Send Indication XOR-PEER-ADDRESS: 10.0.3.170:40593
| 24 0.607539987 10.200.1.2 → XX.XX.3.146 STUN 126 Channel-Bind Success Response
`-------

Geht nicht
Kunde zeigt keinen “CreatePermission Request”:
,-------
| root@serverrpe-z1 7.0:~# tshark -lni vnet7 port 3478 | grep -v “TURN Message”
| Running as user “root” and group “root”. This could be dangerous.
| Capturing on ‘vnet7’
| 1 0.000000000 XX.XX.3.146 → 192.168.18.1 STUN 62 Binding Request
| 2 0.000238948 192.168.18.1 → XX.XX.3.146 STUN 138 Binding Success Response XOR-MAPPED-ADDRESS: XX.XX.3.146:5823 MAPPED-ADDRESS: XX.XX.3.146:5823 RESPONSE-ORIGIN: XX.XX.166.150:3478
| 3 0.000466365 XX.XX.3.146 → 192.168.18.1 STUN 70 Allocate Request UDP
| 4 0.000570675 192.168.18.1 → XX.XX.3.146 STUN 154 Allocate Error Response error-code: 401 (Unauthorized) Unauthorized with nonce realm: pascom
| 5 0.089977829 XX.XX.3.146 → 192.168.18.1 STUN 166 Allocate Request UDP user: 1595264877-client_contacts_guest-15 realm: pascom with nonce
| 6 0.090313645 192.168.18.1 → XX.XX.3.146 STUN 158 Allocate Success Response XOR-RELAYED-ADDRESS: XX.XX.166.150:34383 XOR-MAPPED-ADDRESS: XX.XX.3.146:5823 lifetime: 600
`-------

flashtec · July 21, 2020, 2:52pm

Ich konnte das Problem mit einem DNS Eintrag auf dem lokalen Server lösen und arbeite somit nur noch mit einer Schnittstelle. Nach meiner Einschätzung wird der DNS-Name in der Konfiguration mit zwei Schnittstellen nicht sauber aufgelöst. Intern löst somit der interne DNS-Server auf, während extern bsw. Google-DNS verwendet wird. Seitdem gibt es bei mir keine Probleme mehr.