Mit dem WebApiTester können Sie Verbindungsprobleme identifizieren, die beim Mobile Client auftreten können. Er läuft im Browser und ist über eine öffentliche URL erreichbar. Keine Installation notwendig. Die Prüfungen bauen aufeinander auf.

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

Version:
Wählen Sie hier die Version des XPhone Connect Servers aus. Je nach Version ändern sich die API-Endpunkte sowie die verfügbaren Funktionen.

Server:
Hier trägt man das Protokoll (http,https) und den FQDN ein, unter dem der XPhone Connect Server von extern erreichbar ist.

Basis-Url:
Es wird automatisch "/xphoneconnect/webclientapi" ergänzt, in der Regel muss hier nichts angepasst werden.

Button GetVersionInfo:
Kann ohne Anmeldung ausgeführt werden. Im Erfolgsfall wird als Ergebnis die aktuelle XPhone Server Version zurückgegeben.

Button Stun-/Turn Server:
Kann ohne Anmeldung alle 30 Sekunden ausgeführt werden. Im Erfolgsfall erfährt man die im XPhone Server konfigurierten STUN- und TURN Server. Die STUN-Server werden als Hyperlink angeboten, sodass die Erreichbarkeit mit einem einfachen Klick getestet werden kann.

Button Profile:
Kann ohne Anmeldung ausgeführt werden. Die zuletzt erfolgreich verwendeten Anmeldungen werden im lokalen Browser-Speicher hinterlegt und können direkt wieder verwendet werden. Profile können einzeln oder gesamt gelöscht werden.

Benutzer:
Entspricht dem Anmeldenamen im Connect Client > Konfiguration > Mobiler Client bzw. dem Anmeldenamen in der Mobile App.

Kennwort:
Tragen Sie hier das passende Kennwort zum Benutzer ein.

Button QR Code:
Credentials notwendig. Blendet einen QR-Code ein, der mit der XPhone Mobile App für die Anmeldung gescanned werden kann.

Button Telefon Geräte:
Vorherige Anmeldung notwendig. Listet alle Geräte des angemeldeten Benutzers auf und zeigt das aktive Gerät.

Auswahlliste Transportprotokoll:
Hier besteht die Möglichkeit gezielt die SignalR Verbindung für ein spezifisches Transportprotokoll zu testen. Wenn "Alle" ausgewählt ist, prüft der Mechanismus alle Möglichkeiten und beim ersten, erfolgreichen Protokoll verweilt er dann.

Button Start SignalR:
Führt im Idealfall sofort zum Erfolg, wenn nicht, wird die Verbindung ggf. über "WebSockets" durch eine Firewall oder einen ReverseProxy blockiert. Prüfen Sie in diesem Fall „Nur LongPolling“.

Button Stop SignalR:
Beendet den SignalR Test.

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

Auswahlliste Transportprotokoll:
Hier können Sie vorgeben für welches Transportprotokoll der Verbindungstest durchgeführt wird.

Button Test starten:
Startet den Verbindungstest, wie ihn auch die Mobile App unter "Einstellungen -> Diagnose" durchführt.

Stun:
Geben Sie hier den Stun Server ein, der geprüft werden soll.

Button Stun Server prüfen:
Diese Methode 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. Getestet wird die Verbindung zwischen STUN und Mobile Client bzw. Browser.

Port-Test:
Geben Sie hier Hostnamen bzw. IP-Adresse und Port des zu prüfenden Hosts an.

Button TCP:
Prüft, ob der Host via TCP erreichbar ist, TCP-Ports sind i.d.R. bereits von der Applikation geöffnet und können direkt angesprochen werden.

Button UDP:
Prüft, ob der Host via UDP erreichbar ist. Diese werden nur bei Bedarf (sprich: während einer laufenden Konversation) geöffnet. Sie müssen zunächst auf dem zu testenden Netzwerk-Knoten (das ist i.d.R. der XPhone Server bzw. der XCC) einen UDP Listener starten.

Anleitung:
Auf einem Windows-System erreichen Sie das mit Hilfe der TCP und 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: TCP- und 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.

CSM Webtools navigiert zu den Webtools. Dort finden Sie u.a. ein Tool, welches Sie bei der Erstellung der Firewallregeln unterstützt.

C4B Port Übersicht öffnet die jeweils aktuelle Port- und Verbindungsübersicht.

SSL Checker und SSL Shopper öffnen Seiten, auf denen man die SSL Zertifikatskette überprüfen kann.

UDP Tools enthält zwei Windows-Programme "UDP_Server" und "UDP_Client". Mit dem UDP_Server öffnet man einen UDP Listener auf einem frei wählbaren Port. Mit dem UDP_Client verbindet man sich dorthin und tauscht kurze Nachrichten aus.

TCP Tools enthält zwei Windows-Programme "TCP_Server" und "TCP_Client". Mit dem TCP_Server öffnet man einen TCP Listener auf einem frei wählbaren Port. Mit dem TCP_Client verbindet man sich dorthin (vergleichbar mit dem Programm "Telnet").

Die Tools sind dafür gedacht, auf verschiedenen Rechnern im Netzwerk zu laufen, um die Durchlässigkeit von Firewalls etc. zu verifizieren. UDP_Server bzw. TCP_Server können auch prima in Verbindung mit dem Port-Test eingesetzt werden: UPD oder TCP Port im Firmennetz aufmachen und mit dem Port-Test prüfen, ob der Port von außen erreichbar ist.