End2End Webex

Diese Seite beschreibt, wie Sie als Webex-Benutzer auch die Performance von ihrem Desktop bis zum Webex Service kontinuierlich überwachen können. Das PowerShell-Skript ist ein PoC ohne grafische Auswertung. Für eine professionelles Monitoring vieler Clients mit zentraler Konfiguration und Auswertung können Sie mich gerne zu dem Rimscout (https://www.rimscout.com) ansprechen.

Diese Seite hat nicht viel mit Microsoft 365 oder Exchange zu tun aber soll generell das Verständnis zum Monitoring von Audio/Video-Diensten in der Cloud verbessern.

Die hier beschrieben Tests können Sie auch mit Rimscout (https://www.rimscout.com) auf vielen Clients ausführen und zentral auswerten lassen.

Einführung

Ich zwar kein häufiger Webex-Nutzer aber Kunden von mir nutzen noch Webex und auch hier wird immer mal wieder über "Probleme" berichtet, die sich primär auf Audio und Video beziehen. Webex funktioniert ist ähnlich zu Microsoft Teams und allen anderen Konferenzlösungen. Der Client sende und bekommt seine Pakete dem Konferenzservice und versucht verschiedene Wege und Protokolle zu nutzen. Diese hat Cisco auch dokumentiert, z.B. 80/443 per HTTPS oder präferiert 9000/UDP für RTP. Teams nutzt hier 3478-3481. Auch bei Webex gilt, dass die Kommunikation mit diesen Gegenstellen möglichst schnell und verlustfrei erfolgen sollte und wer UDP über den Zielport 9000 zu den Webex Gegenstellen blockiert, wird eher Probleme bekommen. Webex tunnelt nämlich Audio/Video dann über TCP oder sogar HTTPS und Sie wissen ja schon: Audio/Video über TCP ist schlecht da bei Paketverlusten der IP-Stack des Empfänger die schon empfangenen Pakete erst weiterleiten kann, wenn das fehlende Paket nachgeliefert wurde. Solange ist eben "Standbild" und "Stille" angesagt und wenn dann das verlorene Paket nachgeliefert wurde, verwirft Webex die Flut der dann zugelieferten Pakete, da sie eh "zu alt" sind. Konferenzen ist "Realtime" und ein Paket mit z.B. 200ms altem Audio/Video-Inhalt braucht keiner mehr.

Daher überwacht ich mit End2End-UDP3478 und Rimscout (https://www.rimscout.com) bei Microsoft Teams auch kontinuierlich die Verbindung und berichte entsprechende Fehler. Genau das wollte ich Auch für Webex bereitstellen.

Webex Analyse

Ich habe mich daher mit Wireshark und Fiddler auf die Suche gemacht, um etwas Licht in die Kommunikation von Webex zu bringen. Cisco hat auch die entsprechenden Verbindungen und Ports veröffentlicht:

• How Do I Allow Webex Meetings Traffic on My Network? - Ports used by Webex Meeting Clients
  https://help.Webex.com/en-us/article/WBX264/How-Do-I-Allow-Webex-Meetings-Traffic-on-My-Network?#id_135400
• How Do I Allow Webex Meetings Traffic on My Network? List of IP address ranges used by Cisco Webex Meeting Services
  https://help.Webex.com/en-us/article/WBX264/How-Do-I-Allow-Webex-Meetings-Traffic-on-My-Network?#id_135011

Insofern musste ich auch nicht lange suchen. In meinem Fall war Port 9000/UDP natürlich offen und während einer laufenden Konferenz konnte hier die Pakete einsehen. Ich musste Wireshark natürlich noch mitteilen, dass er Port 9000 als "RTP" decodiert:

Danach hat Wireshark aber schön die unterschiedlichen Formate aufgeschlüsselt:

Beachten Sie, dass diese Pakete alle innerhalb von ca. 200ms gesendet wurden. Sie sehen am Anfang den klassischen "Binding Request", damit der Client vom STUN/TURN-Server einen Kandidaten bekommt:

Die Gegenstelle ist die Adresse 170.72.12.122. Sie sehen parallel aber auch einen "DTLS1.2"-SSL-Handshake über UDP mit Client-Hello und Server-Hello samt Zertifikat:

Und dann natürlich die RTP-Pakete mit dem Codec 111 und ab und an einen "Receiver Report" per SRTCP.

• RTP payload formats
  https://en.wikipedia.org/wiki/RTP_payload_formats

Das sind natürlich sehr viele Ansatzpunkte, um eine Dauerüberwachung zu starten. Ich könnte ja sehr engmaschig einen ClientHello senden und anhand der Antwort die Rundtriptime messen und sogar das gelieferte Zertifikat prüfen.

Es gibt aber noch einen zweiten Ansatzpunkt, denn der Teilneher spricht zum Beitritt in das Meeting eine URL in der Form "https://<kundenname>.Webex.com" an. Also habe ich mal etwas geraten und mit NSLOOKUP gespielt:

Das ist nur eine willkürliche Stichprobe und ich weiß nicht, wie Webex den Firmenname in <firma>.Webex.com festlegt. Es scheint naheliegend, dass man so eine Nutzung von Webex annehmen kann aber sicher ist es nicht. Ein Zugriff auf https://bsi.Webex.com liefert ein "Branding", welches nicht auf das BSI in Deutschland sondern die Firma "BrainStom Inc" in Utah USA hinweist.

Die Server stehen auch alle in der jeweiligen Region. Ein PING zeigt schon die unterschiedliche Laufzeit und der Server für "bsi" ist vermutlich wirklich in den USA aber ob "Siemens" auch einen Service nutzt, der 166ms von Deutschland weg ist, kann ich nicht weiter untersuchen. Allerdings nutzt Webex anscheinend hinter den vielen Systemen immer das identische Wildcard-Zertifikat. Damit kann ich so z.B. prüfen, ob ein HTTP-Proxy vielleicht eine Deep Inspection macht.

Aber wir haben auch gesehen, dass die individuellen Portal-Adressen der Kunden auf unterschiedliche Aliasse und IP-Adressen verweisen. Über einen Reverse-DNS-Lookup zur IP-Adresse bekomme ich noch einen anderen Namen:

PS C:\> (resolve-dnsname (Resolve-DnsName -Type A eon.Webex.com).IPAddress).namehost
fra01-nebulabg.Webex.com

Die Rückwärtsauflösung liefert anscheinend den Flughafencode, der den geografischen Standort des Server darstellen dürfte.

fra01-nebulabg.Webex.com  = Frankfurt, DE
sjc02-nebulaie.Webex.com  = San Jose, Kalifornien, USA
lhr03-nebulaai.Webex.com  = London Heathrow, UK

Leider lösen aber nicht alle von mir geprüften Systeme auch auf einen solchen geografischen Namen auf

Cisco ist vorbildlich, was die ICMP-Prüfungen betrifft, denn ich kann mit einer Ausnahme sogar einen Traceroute durchführen

C:\> tracert global-nebulabg.Webex.com

Routenverfolgung zu global-nebulabg.Webex.com [170.72.18.43] über maximal 30 Hops:

1   1 ms  1 ms  1 ms  fritz.box [192.168.178.1]
2   9 ms  6 ms  6 ms  100.124.1.57
3   6 ms  6 ms  6 ms  100.127.1.132
4   7 ms  6 ms  6 ms  100.127.1.131
5   7 ms  6 ms  7 ms  185.22.46.129
6   5 ms  5 ms  7 ms  ddf-b2-link.ip.twelve99.net [62.115.38.12]
7   9 ms 11 ms 10 ms  ffm-bb1-link.ip.twelve99.net [62.115.135.150]
8  11 ms 10 ms  9 ms  ffm-b5-link.ip.twelve99.net [62.115.114.89]
9  10 ms 13 ms 10 ms  cisco-svc076600-ic365707.ip.twelve99-cust.net [62.115.56.179]
10 *     *     *      Zeitüberschreitung der Anforderung.
11 13 ms 10 ms 10 ms  fra01-wxbb-crt02-bu60.Webex.com [62.109.192.70]
12  9 ms 11 ms 10 ms  62.109.193.27
13 11 ms  9 ms  9 ms  170.72.0.13
14 *     10 ms  9 ms  170.72.0.51
15 11 ms 10 ms 10 ms  170.72.0.27
16 12 ms  9 ms 11 ms  170.72.18.1
17 10 ms  9 ms  9 ms  fra01-nebulabg.Webex.com [170.72.18.43]

Mein Home-Office-Client hat zwar eine native IPv6-Anbindung aber Webex bietet das End März 2023 nicht an. Über IPv4 gibt es wohl kein direktes Peering zwischen meinem Provider (Deutsch Glasfaser) und Webex, so dass hier "Twelve99.net" vermittelt. Allerdings ist das hier kein Nachteil, denn die Laufzeit der Pakete ist dennoch sehr schnell.

Die IP-Adressen helfen mir aber auch den Provider zu finden. Cisco ist allerdings kein kleiner Anbieter, sondern hat ein eigenes autonomes Netzwerk, wie auch Microsoft, Google etc. Aus dem Wireshark-Trace habe ich die "170.72.12.122" als ein TURN-Server auslesen können. Die umgekehrte Namensauflösung liefert dazu:

170.72.12.122 -> Name: mfg3mcs321.Webex.com

Der Name ist wohl nicht der Webserver des Portals sondern einer der vielen TURN-Server. Welchen TURN-Server mein Client aber nutzt, dürfte wohl über die Signalisierung erfolgen, denn ich habe keine generische Geo-DNS-Anfrage analog zu dem Microsoft Teams Server "worldaz.tr.teams.microsoft.com" gefunden. Die IP-Adresse verweis aber eindeutig in das AS13445

• AS13445 Cisco Webex LLC · webex.com
  https://ipinfo.io/AS13445
  https://ipinfo.io/AS13445/170.72.0.0/20-170.72.12.0/25

Das AS13445 ist auch in Peeringdb.com gelistet.

• Webex Communications
  https://www.peeringdb.com/net/1517

Leider habe ich noch keinen Weg gefunden, wie Cisco Webex den "nächsten STUN/TURN-Server" an den Client übermittelt. Ich habe natürlich die in meinem Call genutzte IP-Adresse 170.72.12.122 per UDP und TCP angesprochen und habe sogar eine Antwort bekommen. Für eine kontinuierliche "Laufzeitmessung" würde dies schon ausreichen. Allerdings kann ich so nicht sicher sein, dass mein Skript wirklich den nächsten und optimalen STUN/TURN-Server nutzt. Die Messung wäre also nur bedingt valide und wenn Cisco den Server zur Wartung außer Betrieb nimmt, würde die Prüfung sogar einen Fehlalarm auslösen.

Prüfen und Messen

Solange Webex keine bessere Gegenstelle anbietet, sind UDP/RTP-Tests nicht möglich. Aber ich kann durchaus folgende Tests durchführen

• DNS-Prüfung
  Wenn ich den Kundenname in Webex habe, dann kann ich per DNS einfach die IP-Adresse zum Namen und über die IP-Adresse dann den realen Hostnamen und damit den Standort des Service ermitteln. Leider macht Webex hier wohl kein Geo-DNS oder Anycast-DNS, denn aus Deutschland erreiche ich eine US-Firma über den Server in den USA. DAs gilt dann auch für US-Mitarbeiter, die temporär in Europa weilen. Hier ist Teams hinsichtlich des Webservice unter https://teams.microsoft.com und des Transport-Relays anders aufgestellt.
• Traceroute
  Vom Client kann ich per ICMP den Weg und die Latenzzeit regelmäßig ermitteln und Unterbrechungen und Verzögerungen erkennen. Dazu kann die dem zum Kunden geordneten Portalserver nutzen. Diese stehen zumindest im gleichen autonomen BGB-Netzwerks und Probleme auf dem Weg bis zum Übergabepunkt bei Cisco sind so ermittelbar. Nur die letzten Hop könnten sich unterscheiden und sind daher eine Ungenauigkeit
• PING
  Genauso kann ich einfach einen PING auf den Webservice machen.
• HTTP-Request
  Wenn ich den WebService genauer testen möchte, kann ich natürlich auch einen HTTP-Request ausführen. Vorsicht bei Invoke-Webrequest, der natürlich dem 302 Redirect folgt und damit die gemessen Zeit durch nachfolgende Requests im gleichen Aufruf länger wird.
• UDP-Prüfung
  Wenn Sie einen TURN-Server kennen, dann können Sie entsprechend formatierte UDP-Pakete über Port 9000 an den Servre senden und die Antwortzeit messen.

UDP 3478 = Port 9000 Messung

Mit Rimscout (https://www.rimscout.com) und meinem End2End-UDP3478-Skript kann ich kompatible STUN/TURN-Server prüfen. Das Skript sendet dazu einen anonymen STUN/TURN-Request an den Service welcher darauf mit einem "Access denied" antworten sollte und mir die Möglichkeiten einer Authentifizierung mitteilt. Webex nutzt zwar nicht den Standard-Port 3478 sondern 9000 aber dennoch reagiert er auf die STUN/TURN-Anfragen meines Skripts:

Natürlich bekomme ich einen 401-Fehler (erwartet)

Mein PowerShell-Script protokolliert auch brav mit 50 Paketen/Sek die Verbindung meines Clients zu diesem TURN-Server:

Wenn Sie die Zahlen interpretieren, dann sehen wir ca 16-20ms Mittelwert bei ca. 1149-1275 Pakete/Minute, also ca. 18-20Pakete/Sekunde mit ca. 0,2% Paketverlust und selbst das P95 Perzentil ist 26 oder weniger Millisekunden und damit ein sehr guter Wert. Die IP-Adresse 170.72.12.122 habe ich aus einem Mitschnitt eines anderen Webex-Meeting, in dem ich einige Tage zuvor Teilnehmer war, ausgelesen.

Leider habe ich bislang noch keinen Weg gefunden, wie ich die Webex TURN-Server für einen Client ermitteln kann. Microsoft Teams nutzt dazu einfach DNS aber Webex scheint die Konfiguration nach dem Start des Client oder der WebApp über HTTP an den Client zu liefern, der sich dann direkt mit der IP-Adresse verbindet. Ein Versuch einfach einen TURN-Request an den Host in der Meeting-URL (<instanz>.webex.com) zu senden, funktioniert erwartungsgemäß nicht. Damit kann ich das Skript leider nicht "automatisieren", damit es sich z.B. Minute einen Server holt.

Die hier beschrieben Tests können Sie auch mit Rimscout auf vielen Clients ausführen und zentral auswerten lassen.

Bitte nutzen sie diese Information nicht zu einer Dauerüberwachung ihrer Verbindung zu Webex. Meine Gegenstelle ist nicht automatisch für ihren Provider optimiert.

Weitere Links

• Ende zu Ende Monitoring
• End2End-UDP3478
• https://www.rimscout.com
• How Do I Allow Webex Meetings Traffic on My Network? - Ports used by Webex Meeting Clients
  https://help.Webex.com/en-us/article/WBX264/How-Do-I-Allow-Webex-Meetings-Traffic-on-My-Network?#id_135400
• How Do I Allow Webex Meetings Traffic on My Network? List of IP address ranges used by Cisco Webex Meeting Services
  https://help.Webex.com/en-us/article/WBX264/How-Do-I-Allow-Webex-Meetings-Traffic-on-My-Network?#id_135011
• Webex Calling Media Optimization with Interactive Connectivity Establishment (ICE)
  https://help.Webex.com/en-us/article/nt6eyxb/Webex-Calling-Media-Optimization-with-Interactive-Connectivity-Establishment(ICE)
• How Do I Allow Webex Meetings Traffic on My Network?
  https://help.Webex.com/en-us/article/WBX264/How-Do-I-Allow-Webex-Meetings-Traffic-on-My-Network?#id_135400
• Troubleshoot Webex Calling Media Quality in Control Hub
  https://help.Webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub
  Webex hat wie Teams ein Monitoring Dashboard, in dem aber auch nur die vergangenen Calls aufgeführt werden können. Dies ersetzt keine Dauerüberwachung ihres Netzwerk
• Google Meet: Netzwerk-, Audio- und Videoprobleme in Meet als Administrator beheben
  https://support.google.com/a/answer/7582554#zippy=%2Clatenz-messen