WebApi Tester

Übersicht

Werbe- und Skriptblocker deaktivieren und XHR-Requests zulassen!
Zusätzliche Logausgaben mit F12 Developer-Konsole!

Wofür ist der WebApi-Tester gut? Er soll dabei helfen, Verbindungsprobleme zu identifizieren, die beim Mobile Client auftreten können - insbesondere beim Einsatz von Softphone. Ab XPhone Version 9.x!

Stellt euch im folgenden Ausschnitt aus der Port-Übersicht den WebApi-Tester an der Stelle des Mobile Clients vor - also ganz rechts.

Es werden die Verbindungen 9, 10 und 17 getestet:

Der WebApi-Tester läuft ohne Installation im Browser. Er ist über eine öffentliche URL erreichbar und muss nicht installiert werden. Man kann ihn also bequem auf jedem beliebigen Netzwerk-Knoten aufrufen, auf dem ein Browser installiert ist. So können Netzwerkprobleme an jedem Punkt im Netzwerk untersucht werden.

Die Prüfungen bauen aufeinander auf. Öffnen Sie am besten gleich mit F12 die Developer Konsole. Beginnen Sie dann damit, den Server-Namen einzutragen und die Befehle "GetVersionInfo" und "XirsysCheck" auszuführen. Anschließend tragen Sie gültige User-Credentials ein und melden sich am Server an. Daraufhin werden die weiteren Tests aktiviert. Beobachten Sie dabei immer den Output im "Console"-Tab der Developer-Konsole.

Verbindung und Anmeldung

Als Server trägt man das Protokoll (http,https) und den FQDN ein, unter dem der XPhone Connect Server von extern erreichbar ist. Es wird automatisch "/xphoneconnect/webclientapi" ergänzt, so dass die Basis-URL "https://FQDN/xphoneconnect/webclientapi" entsteht. Alles, was nach der FQDN eingetippt wird, wird automatisch wieder entfernt!

Der Befehl [GetVersionInfo] kann ohne Anmeldung ausgeführt werden. Im Erfolgsfall wird als Ergebnis die aktuelle XPhone Server Version zurückgegeben.

Der Befehl [Stun-/Turn Server] braucht auch keine Anmeldung. Er kann aus Sicherheitsgründen nur alle 30sec ausgeführt werden. Im Erfolgsfall erfährt man die im XPhone Server konfigurierten STUN- und TURN Server. Die STUN Server werden als Hyperlink angeboten, so dass die Erreichbarkeit mit einem einfachen Klick getestet werden kann.

Der Befehl [Mobile App Access (Lade XPhone Logo)] braucht ebenfalls keine Anmeldung. Mit diesem Befehl wird die Erreichbarkeit der Mobile-Webseite überprüft. Der Test besteht darin, eine Grafik-Datei mit dem XPhone-Logo zu laden und direkt im WebApi-Tester anzuzeigen. Wird das XPhone-Logo nicht angezeigt, erscheint stattdessen ein Fehlerhinweis. In diesem Fall ist die Mobile-Webseite von außen nicht erreichbar, vermutlich wegen Beschränkungen in der Firewall bzw. im Reverse-Proxy.

Der Befehl [Profile] öffnet einen Bereich mit den zuletzt erfolgreich(!) verwendeten Anmeldungen. Mit einem Klick auf einen Profil-Hyperlink werden diese Profildaten wieder in den WebApi-Tester geladen. Mit einem Klick auf das Löschen-Symbol am Anfang jeder Zeile kann man gezielt einzelne Profile löschen.

Der Befehl [Alle löschen] löscht alle Profildaten aus dem lokalen Browser-Speicher. Der Befehl [Copy] kopiert alle Profildaten ins Clipboard. Mit dem Befehl [Paste (Ctrl-V)] holt sich der WebApi-Tester die Profile aus dem Clipboard. Auf diese Weise kann man Profile von einem Device auf ein anderes übertragen. Die Profile werden zu den schon vorhandenen dazu gemischt! Außerdem kann man so ein neues Profil einfügen: dazu muss der Clipboard-Inhalt das Format "https://Server||Benutzer||Kennwort" haben. Benutzer und Kennwort können auch fehlen.

Tipp: Man kann die Profile auch über die URL als angefügen Hashtag einfügen (z.B. https://wonderful-wave-0fef5e603.2.azurestaticapps.net/#https://Server||Benutzer||Kennwort)

Die weiteren Befehle erfordern eine [Anmeldung] am XPhone Connect Server mit einem gültigen Benutzer und Kennwort, ganz analog zur Anmeldung im Mobile Client.

Der Befehl [QR Code anzeigen] blendet einen QR Code ein, der mit der XPhone Mobile App - und nur mit der! - gescanned werden kann. Der QR Code zeigt im Tooltip die spezielle URL für die Mobile App an. Braucht man den Code nicht mehr, kann er auch wieder ausgeblendet werden.

Nach erfolgreicher Anmeldung werden die weiteren Befehle freigeschaltet.

Der Befehl Telefon Geräte listet alle Geräte des angemeldeten Benutzers und meldet zusätzlich das gerade aktive Gerät.

SignalR

Ganz wichtig ist der Test der SignalR Verbindung. Im Idealfall führt der Befehl [Start SignalR] sofort zum Erfolg. Wenn das nicht der Fall sein sollte, könnte es daran liegen, dass die Verbindung über "WebSockets" durch eine Firewall oder einen ReverseProxy blockiert wird.

Um das zu prüfen, beendet man zunächst die aktive SignalR Verbindung mit dem Befehl [Stop SignalR]. Nun setzt man den Haken bei Nur LongPolling und startet die SignalR-Verbindung erneut. Bei solch einem SignalR-Versuch wird nur das Protokoll "LongPolling" aktiviert. "WebSockets" und "ServerSentEvents" sind abgeschaltet.

Details des Verbindungsaufbaus sieht man in der F12 Developer Konsole. Insbesondere erkennt man, welche Transport-Art von SignalR ausgewählt wurde:

STUN

Die Methode [Stun Server prüfen] verwendet das WebRTC API, um die Erreichbarkeit und Funktionsfähigkeit des angegebenen Stun-Servers zu testen. Neben FQDN und Port des Stun Servers kann auch das Protokoll (udp, tcp) in der Abfrage eingegeben werden.

Derzeit wird Verbindung (19) getestet. Die TURN Prüfung (18) kommt erst in einer zukünftigen Version.

Port Test

Hier überprüft man die Erreichbarkeit eines TCP oder UDP Ports im Firmennetzwerk aus dem Internet. Der Aufruf erfolgt aus der Azure Cloud ("serverless function") zum eingegebenen Hostnamen bzw. IP-Adresse. Der Hostname wird im öffentlichen DNS aufgelöst.

Mit den Buttons [TCP] oder [UDP] entscheidet man, ob die Verbindung über das TCP- oder UDP-Protokoll hergestellt werden soll.

TCP Ports sind i.d.R. bereits von der Applikation geöffnet und können direkt angesprochen werden.

Für UDP Ports gilt das aber nicht! Diese werden nur bei Bedarf (sprich: während einer laufenden Konversation) geöffnet. Sie müssen also zunächst auf dem zu testenden Netzwerk-Knoten (das ist i.d.R. der XPhone Server bzw. der XCC) einen UDP Listener starten. Auf einem Windows-System erreichen Sie das mit Hilfe der UDP Tools im Download-Bereich.

Auf einem Linux-System wie dem ausgelagerte XCC dient dazu der Befehl:
nc -l -u -n -p UDP_PORT -v -v

Hinweis: Sowohl der TCP- als auch der UDP-Server versenden beim Öffnen des Sockets noch keine Pakete. Diese Server senden erst dann Pakete, wenn der jeweilige Listener zuvor ein Paket vom Client erhalten hat. Somit kann es passieren, dass dieses eingehende Paket des TCP-/UDP-Clients (WebAPI Tester) von einem Firewall NAT blockiert wird. (Meist muss zuerst eine ausgehende Verbindung bestehen, damit eingehende Verbindungen erlaubt sind.) Wie genau Sie die zu testenden Ports von außen "öffnen" steht Ihnen frei, allerdings empfehlen wir, wenn auch nur temporär, ein Port-Forwarding zu konfigurieren. Dieses sorgt dafür, dass die eingehenden UDP-Pakete an die gewünschte Maschine (auf welcher der UDP-Server/UDP-Listener läuft) geleitet wird.