DE102015104863A1

DE102015104863A1 - Client-Server-Kommunikationsauswertungs- und -diagnosetool

Info

Publication number: DE102015104863A1
Application number: DE102015104863.9A
Authority: DE
Inventors: Paul Roller Michaelis
Original assignee: Avaya Inc
Current assignee: Avaya Inc
Priority date: 2014-09-09
Filing date: 2015-03-30
Publication date: 2016-03-10
Also published as: GB2530125A; GB201505285D0; GB2530125B; US20160072693A1

Abstract

Ein Diagnosesystem wird beschrieben für die Nutzung beim Analysieren von Client-Server-Kommunikationen und vor allem Kommunikationsanwendungen, die Client-Server-Interaktionen gebrauchen. Das Diagnosesystem beinhaltet ein clientseitiges Diagnosetool und ein serverseitiges Diagnosetool, die zusammenarbeiten, um beide Seiten der Client-Server-Interaktion auf potenzielle Probleme mit den Kommunikationsanwendungen zu analysieren.

Description

GEBIET DER OFFENBARUNG
Die vorliegende Offenbarung betrifft allgemein die Kommunikationstechnik und vor allem Diagnosetools für Kommunikationssysteme, die ein Client-Server-Modell gebrauchen.
ALLGEMEINER STAND DER TECHNIK
Derzeit zeichnet sich ein Trend dahingehend ab, dass mehr Komponenten eines Kommunikationssystems, etwa eines Unternehmenskommunikationssystems, in der Cloud zur Verfügung gestellt werden, wo Gruppen entfernter, redundanter und hochverfügbarer Server zum Durchführen der Funktionen aktiviert werden, die zuvor von Servern an einem Standort durchgeführt wurden. Der Hauptvorteil beim Implementieren von Kommunikationssystemen in der Cloud ist, dass der Kunde nicht direkt seine eigenen Server erwerben und/oder warten muss. Leider geht diese Umstellung auf die Cloud mit vielen Hindernissen einher.
Ein solches Problem ist die potenzielle Einführung von Bugs/Problemen an mehreren Stellen auf einem Kommunikationsweg. Vor allem kann ein Benutzer mit einem Problem mit seinem Kommunikationssystem konfrontiert sein, und weil einige der Komponenten lokal sind und andere Komponenten in der Cloud gehostet werden, wird es für den Benutzer zunehmend schwierig, das Problem zu behandeln.
In einem spezifischeren Beispiel sei angenommen, dass eine Kommunikation ein Client-Server-Modell implementiert, bei dem ein Server eingesetzt wird, um mindestens einige Kommunikationsfeatures im Auftrag des Clients zu unterstützen. Wenn bei einem solchen System ein Problem auftritt, ist ein Benutzer (oder ein Systemadministrator) vor die schwierige Aufgabe gestellt, die Quelle des Problems auszumachen. Insbesondere involviert die Diagnose des Problems nicht nur, dass identifiziert werden muss, wo im System das Problem besteht, sondern auch wer verantwortlich für die Komponente ist, die die Quelle des Problems ist. Anders gesagt, die cloudbasierten Lösungen setzen in der Regel mehrere Komponenten ein und die meisten Komponenten haben gewöhnlich unterschiedliche Administratoren und Kundendienstbetreuer.
Das Problem wird insofern noch komplexer, als cloudbasierte Kommunikationsanwendungen vielfältige Internetprotokoll-Pakettypen einsetzen. Einige Pakete, etwa diejenigen, die mit Datenübertragungen assoziiert werden, werden in der Regel über Transmission-Control-Protocol(TCP)-Mechanismen übertragen. Andere Pakete, etwa diejenigen, die mit Sprachübertragungen assoziiert werden, werden in der Regel über User-Datagram-Protocol(UDP)-Mechanismen übertragen. Es ist nicht unüblich, dass die unterschiedlichen Pakettypen zwischen Client und Server über unterschiedliche Router und unterschiedliche Firewalls geleitet werden. Zudem ist zu berücksichtigen, dass es üblich ist, bestimmte Pakettypen nur für die Kommunikation vom Client an den Server oder die Kommunikation vom Server an den Client zu nutzen. In einem simplen Ausführungsbeispiel muss ein Kommunikationsclient die zum Wählen eingesetzten Pakettypen (z. B. RFC-2833-Pakete) an den Server senden können, doch der Server braucht diese Pakettypen nie an den Client zu senden.
Es liegt auf der Hand, dass ein Bedarf daran besteht, die Auswertung und die Diagnose von cloudbasierten Kommunikationssystemen zu vereinfachen.
KURZE DARSTELLUNG DER ERFINDUNG
Ein Aspekt der vorliegenden Offenbarung besteht deshalb in der Bereitstellung eines Diagnosetools, das von Benutzern bedienbar und fähig zum Identifizieren der Fehlerstelle(n) in einem Kommunikationssystem ist, wenn alle Pakettypen, die der Kommunikationsanwendungsserver an den Client senden muss, nicht durch den Client empfangen oder akzeptiert werden oder wenn alle Pakettypen, die der Client an den Server senden muss, nicht durch den Server empfangen oder akzeptiert werden. Mit einem solchen Diagnosetool kann der Benutzer Probleme in einem cloudbasierten Kommunikationssystem schnell diagnostizieren und gegen sie vorgehen, nicht nur durch Identifizieren der Quelle des Problems, sondern auch der Entität, die verantwortlich für die Komponente ist, die die Quelle des Problems ist.
In einigen Ausführungsformen wird das Diagnosetool der vorliegenden Offenbarung aktiviert, um mehrere Aspekte eines Kommunikationssystems zu analysieren und dabei zu versuchen, die Quelle eines Problems und die mit der Quelle des Problems assoziierte Entität zu identifizieren. In einigen Ausführungsformen ist das Diagnosetool fähig, Folgendes zu detektieren und darüber zu berichten:

(1) Die erforderliche Lizenz ist auf dem Server/den Servern, der/die den Dienst für die Clienteinrichtung bereitstellt/bereitstellen, nicht vorhanden; und/oder
(2) die erforderliche Lizenz ist auf dem Server/den Servern vorhanden, doch die Clienteinrichtung ist nicht für die Nutzung der erforderlichen Lizenz aktiviert worden; und/oder
(3) die erforderlichen Ports sind auf dem Server/den Servern nicht offen; und/oder
(4) die erforderlichen Ports sind auf der Clienteinrichtung nicht offen; und/oder
(5) einer oder mehrere der Pakettypen, die vom Client zum Server übergehen müssen, werden gerade von einer Firewall oder einem Gateway blockiert (oft aufgrund von Sicherheitsbedenken); und/oder
(6) einer oder mehrere der Pakettypen, die vom Server zum Client übergehen müssen, werden gerade von einer Firewall oder einem Gateway blockiert (auch oft aufgrund von Sicherheitsbedenken).

Eine einfache Portüberwachungssoftware kann eine Anforderung einer Verbindung mit einem Zielcomputer versenden und ermitteln, welche Ports offen sind und reagieren. Ping ist ein IP-Netztool, das genutzt wird, um zu ermitteln, ob ein Host erreichbar ist. Es gibt auch unzählige Porttesttools, die ermitteln können, welche Ports verfügbar sind. Diese werden üblicherweise für Anwendungs-/Entwicklungstests genutzt. Leider tragen diese Tools den spezifischen Port- und Kommunikationserfordernissen für konkrete Anwendungen nicht Rechnung. Wegen dieser Beschränkungen ist eine einfache Portüberwachungssoftware kein geeignetes Diagnosetool, zumindest nicht für sich allein.
Antivirentools bieten ebenfalls eine gewisse Fähigkeit zum Suchen nach verfügbaren Einrichtungen und verfügbaren Ports in diesen Einrichtungen, was auf der Überlegung beruht, dass diese Ports „Hintertüren“ für bösartigen Code sein können. Wenngleich diese Antivirentools nach offenen Ports suchen können, sind sie nicht konfiguriert, um die Pakettransportierbarkeit und die Lizenzverfügbarkeit zu analysieren. Ferner können diese Antivirentools nicht prüfen, ob Ports auf der Clienteinrichtung offen sind. Wegen dieser Nachteile sind einfache Abwandlungen von Antivirentools nicht hinreichend für das Diagnostizieren von Problemen in einem cloudbasierten Kommunikationssystem.
Ausführungsformen der vorliegenden Offenbarung stellen ein weitaus nützlicheres Diagnosetool bereit. In einigen Ausführungsformen umfasst das Tool eine Komponente, die auf der Clientseite arbeitet, sowie eine Komponente, die auf der Serverseite arbeitet. Für Client-Server-Anwendungen, die ausgewertet/analysiert werden sollen (z. B. Avaya one-X Agent^®, Avaya Communicator^®, nicht von Avaya stammende Messagingdienste etc.), würde die clientbasierte Komponente des Diagnosetools über Informationen in Bezug auf Folgendes verfügen, bevor Konnektivitätstests initiiert werden:

(1) Die Server, die die Anwendungen unterstützen,
(2) die Ports, die auf dem Client offen sein müssen,
(3) die Lizenzen, die auf dem Client verfügbar sein und für den Benutzer, der das Tool ablaufen lässt, verfügbar sein müssen,
(4) die Pakettypen, die der Client erfolgreich an den Server senden können muss, und
(5) die Pakettypen, die der Client vom Server empfangen können muss.

Solche Informationen könnten der clientbasierten Komponente des Diagnosetools entweder programmgesteuert oder über eine Datenbanksuche bekannt gemacht werden.
Analog würde die serverbasierte Komponente des Diagnosetools für Client-Server-Anwendungen von Interesse über Informationen in Bezug auf Folgendes verfügen:

(1) Die Ports, die auf dem Server offen sein müssen,
(2) die Lizenzen, die auf dem Server verfügbar sein und für den Benutzer, der das Tool ablaufen lässt, verfügbar sein müssen,
(3) die Pakettypen, die der Server erfolgreich an den Client senden können muss, und
(4) die Pakettypen, die der Server vom Client empfangen können muss.

Diese Informationen können programmgesteuert, über eine Suchtabelle oder Ähnliches für die serverbasierte Komponente des Diagnosetools verfügbar gemacht werden. In einigen Ausführungsformen könnten die Konnektivitätstests vom Benutzer initiiert werden (z. B. als Antwort darauf, dass der Benutzer mit Problemen mit dem Kommunikationssystem konfrontiert ist). Idealerweise würde das Starten des Tools auf der Clienteinrichtung des Benutzers (z. B. auf einem PC, einem Tablet, einem Telefon, einem SIP-Benutzeragenten etc.) auslösen, dass sowohl die Client- als auch die Serverkomponenten mit der angemessenen Abfolge von Diagnosevorgängen begönnen. Falls in einigen Ausführungsformen eine Local-Area-Network(LAN)-basierte Verbindung zwischen einem Client und einem Server nicht zulässt, dass die „Start“-Anweisung des Clients durch den Server empfangen wird, könnte ein alternativer Kommunikationsmechanismus, etwa eine telefonbasierte Interactive-Voice-Response(IVR)-Anwendung, genutzt werden. Anders gesagt, falls das paketbasierte Netz für die Übermittlung der „Start“-Anweisung vom Client an den Server nicht verfügbar ist, könnte die „Start“-Anweisung über ein anderes Netz (z. B. das öffentliche Fernsprechwählnetz (PSTN) oder Ähnliches) umgeleitet werden.
Sowohl auf dem Client als auch auf dem Server kann die Verfügbarkeit der erforderlichen Ports und Lizenzen ausgewertet werden. Der Auswertung können sich Testübertragungen für alle erforderlichen Pakettypen anschließen, deren Ports als offen ermittelt wurden. Der Server kann konfiguriert sein, um während dieser Auswertung eine erste Menge von Testpaketen zu senden, während der Client konfiguriert sein kann, um während dieser Auswertung eine zweite Menge von Testpaketen zu senden. Einige Testpakete in der ersten und der zweiten Menge von Paketen können gleich sein, müssen sich jedoch nicht zwangsläufig decken. Mit anderen Worten, einige Elemente der ersten Menge von Testpaketen gehören möglicherweise nicht zur zweiten Menge von Testpaketen oder umgekehrt. Der/die Server würde(n) Rückmeldungen an das Client-Tool in Bezug auf die Lizenz- und die Portverfügbarkeit liefern, nebst Informationen in Bezug darauf, welche der erwarteten Pakete, die durch die Clienteinrichtung übertragen worden waren, empfangen wurden und welche nicht.
Weil das Diagnosetool alle Informationen „kennt“, die zuvor für alle Client-Server-Anwendungen von Interesse aufgelistet wurden, kann das Diagnosetool dem Benutzer viele verschiedene Informationen mitteilen. Beispielsweise könnte das Diagnosetool dem Benutzer einen Bericht etwa mit folgendem Inhalt zukommen lassen:

(1) Sie können die Kommunikationsanwendung ABC nutzen.
(2) Sie können die Kommunikationsanwendung XYZ nicht nutzen, weil Ihnen keine Lizenz zugewiesen worden ist.
(3) Falls Sie die Kommunikationsanwendung ABC nutzen, werden die Sprachfunktionen richtig funktionieren. Außerdem können Sie TTY-Kommunikationen empfangen, können sie jedoch nicht senden, weil die RFC-4103-Pakete, die der Server von Ihrem Gerät erwartet hat, nicht durch das Netz zugestellt wurden.

In einigen Ausführungsformen würde das Diagnosetool Ratschläge und empfohlene Lösungen bereitstellen, falls bestimmte Anwendungen als nicht nutzbar ermittelt werden. Zum Beispiel: „Sie dürfen zwar die TTY-Erweiterung der Kommunikationsanwendung ABC aufgrund der momentanen Netzkonfiguration nicht nutzen, wenn Sie die Anwendung in einem ersten Modus betreiben, jedoch würde die TTY-Kommunikation unterstützt, wenn Sie die Kommunikationsanwendung ABC in einem zweiten Modus betreiben.“
In einer anderen Ausführungsform könnte ein Benutzer, der auf eine spezifische Anwendung, die nicht korrekt kommuniziert, zugreifen muss, das Diagnosetool auffordern, (z. B. automatisch) einen Diagnosebericht und eine Reparaturanforderung an den zuständigen Systemadministrator/die zuständigen Systemadministratoren zu senden. Falls zum Beispiel eine gehörlose Person die TTY-Erweiterung in der Kommunikationsanwendung MNO nicht nutzen kann, weil keine Lizenz verfügbar ist, da eine Netzfirewall den Durchgang der spezialisierten RFC-4103-Pakete nicht zulässt, könnte das Diagnosetool eine Nachricht an den Administrator eines ersten Anwendungsservers mit dem Inhalt „Benutzer John Smith benötigt eine Lizenz für die Kommunikationsanwendung MNO“ und eine getrennte Nachricht an den Netzadministrator mit dem Inhalt „das Netz zwischen dem von John Smith genutzten PC und dem ersten Anwendungsserver muss den Durchgang von spezialisierten RFC-4103-Paketen zulassen“ senden.
In einigen Ausführungsformen wird ein Diagnosesystem bereitgestellt, das allgemein Folgendes umfasst:
ein clientseitiges Diagnosetool, das konfiguriert ist, um einen clientseitigen Diagnoseprozess auszuführen, der Folgendes beinhaltet:
Erzeugen eines ersten Testpakets;
Ermitteln eines Zielservers für das erste Testpaket;
Übertragen des ersten Testpakets an den Zielserver;
Warten auf eine Antwort auf das erste Testpaket; und
basierend darauf, ob eine Antwort auf das erste Testpaket empfangen wird oder nicht, Ermitteln von Folgendem:

a. falls keine Antwort auf das erste Testpaket empfangen wird, Ermitteln, dass eine Firewall zwischen der Clienteinrichtung und dem Server eine potenzielle Quelle eines Kommunikationsproblems zwischen einer Clienteinrichtung und dem Server ist; und/oder
b. falls keine Antwort auf das erste Testpaket empfangen wird, Ermitteln, dass ein Port des Servers, der mit dem ersten Testpaket assoziiert ist, eine potenzielle Quelle eines Kommunikationsproblems zwischen der Clienteinrichtung und dem Server ist; und/oder
c. falls eine Antwort auf das erste Testpaket empfangen wird, Ermitteln, dass weder der Port noch die Firewall mit einer potenziellen Quelle eines Kommunikationsproblems zwischen der Clienteinrichtung und dem Server korrespondiert; und

In einigen Ausführungsformen würde sich der obige Prozess so lange wiederholen, bis alle Pakettypen der Kommunikationsanwendung, die vom Client an den Server übertragbar sein müssen, und alle Pakettypen, die vom Server an den Client übertragbar sein müssen, getestet sind.
Der Begriff „automatisch“ und Varianten davon, wie hierin genutzt, bezieht sich auf beliebige Prozesse oder Vorgänge, die ohne wesentliche menschliche Eingabe erfolgen, wenn der Prozess oder Vorgang durchgeführt wird. Jedoch kann ein Prozess oder Vorgang auch dann automatisch sein, obwohl bei der Durchführung des Prozesses oder Vorgangs eine wesentliche oder unwesentliche menschliche Eingabe erfolgt, falls die Eingabe vor der Durchführung des Prozesses oder Vorgangs empfangen wird. Eine menschliche Eingabe gilt als wesentlich, wenn diese Eingabe beeinflusst, wie der Prozess oder Vorgang durchgeführt wird. Eine menschliche Eingabe, welche die Durchführung des Prozesses oder Vorgangs gestattet, gilt nicht als „wesentlich“.
Der Begriff „computerlesbares Medium“, wie hierin genutzt, bezieht sich auf einen beliebigen physischen Speicher, der daran beteiligt ist, wenn an einen Prozessor Befehle zur Ausführung geliefert werden. Ein solches Medium kann viele Formen annehmen, die unter anderem nicht flüchtige Medien, flüchtige Medien und Übertragungsmedien beinhalten. Nicht flüchtige Medien beinhalten zum Beispiel NVRAMs oder Magnet- oder Bildplatten. Flüchtige Medien beinhalten dynamische Speicherbausteine wie Arbeitsspeicher. Häufige Formen computerlesbarer Medien beinhalten zum Beispiel eine Floppy-Disk, eine Diskette, eine Festplatte, ein Magnetband oder ein beliebiges anderes magnetisches Medium, ein magnetooptisches Medium, eine CD-ROM, ein beliebiges anderes optisches Medium, Lochkarten, Lochstreifen, ein beliebiges anderes physisches Medium mit Lochmustern, ein RAM, ein PROM und ein EPROM, ein FLASH-EPROM, ein Festkörpermedium wie eine Speicherkarte, einen beliebigen anderen Speicherchip oder eine beliebige andere Speicherkassette oder ein beliebiges anderes Medium, das ein Computer lesen kann. Wenn die computerlesbaren Medien als Datenbank konfiguriert sind, versteht es sich, dass die Datenbank eine Graphdatenbank, wie hierin beschrieben, sein kann. Demgemäß wird davon ausgegangen, dass die Offenbarung ein physisches Speichermedium und als Stand der Technik anerkannte Äquivalente und Nachfolgemedien beinhaltet, in denen die Software-Implementierungen der vorliegenden Offenbarung gespeichert sind.
Die Begriffe „ermitteln“, „kalkulieren“ und „berechnen“ sowie Varianten davon, wie hierin genutzt, werden synonym genutzt und umfassen beliebige Typen von Methodiken, Prozessen, mathematischen Operationen oder Techniken.
Der Begriff „Modul“, wie hierin genutzt, bezieht sich auf eine beliebige bekannte oder später noch entwickelte Hardware, Software, Firmware, künstliche Intelligenz, Fuzzylogik oder Kombination von Hardware und Software, die zur Durchführung der mit diesem Element assoziierten Funktionalität fähig ist. Wenngleich die Offenbarung in Form von Ausführungsbeispielen beschrieben ist, versteht es sich auch, dass einzelne Aspekte der Offenbarung getrennt beansprucht werden können.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Offenbarung wird in Verbindung mit den beigefügten Figuren beschrieben:
1 ist ein Blockdiagramm, das ein Kommunikationssystem gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
2 ist ein Blockdiagramm, das Details eines zweiten Kommunikationssystems gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
3 ist ein Blockdiagramm, das einen Server und Komponenten davon gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
4 ist ein Flussdiagramm, das einen ausführbaren Prozess abbildet, der durch eine Clienteinrichtung und (einen) Server in Verbindung mit dem Ablaufenlassen eines Diagnoseprozesses gemäß Ausführungsformen der vorliegenden Offenbarung durchgeführt wird;
5 ist ein Flussdiagramm, das ein Verfahren zum Ablaufenlassen eines Diagnoseprozesses gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
6 ist ein Flussdiagramm, das ein Verfahren zum Abschließen eines Diagnoseprozesses gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
7 ist ein Flussdiagramm, das ein Verfahren zum Analysieren von Lizenzinformationen in einem Kommunikationssystem gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
8 ist ein Flussdiagramm eines Verfahrens zum Testen von Ports gemäß Ausführungsformen der vorliegenden Offenbarung; und
9 ist ein Flussdiagramm, das ein Verfahren zum Senden von Testpaketen im Rahmen eines Diagnoseprozesses gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung abbildet.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende Beschreibung legt nur Ausführungsformen dar und soll nicht den Schutzbereich, die Anwendbarkeit oder die Konfiguration der Ansprüche beschränken. Vielmehr gibt die folgende Beschreibung der Fachperson eine Beschreibung an die Hand, die sie dazu befähigt, die Ausführungsformen zu implementieren. Dabei versteht es sich, dass verschiedene Änderungen hinsichtlich der Funktion und der Anordnung von Elementen vorgenommen werden können, ohne vom Gedanken und vom Schutzbereich der beigefügten Ansprüche abzuweichen.
Es versteht sich, dass Ausführungsformen der vorliegenden Offenbarung in zahlreichen Umgebungen einsetzbar sind, in denen es für Clients schwierig ist, eine zweiseitig gerichtete Kommunikation mit Servern herzustellen. Denn die Typen der hierin beschriebenen Probleme können immer dann auftreten, wenn dedizierte, manchmal proprietäre Clients in einem Local Area Network (LAN)/Wide Area Network (WAN) installiert sind und mit einem Server, spezialisierten Client-Server-Anwendungen, z. B. Multimediaanwendungen, Zusammenarbeitstools, Kommunikationstools/-anwendungen etc. und Ähnlichem kommunizieren. Beispielsweise könnte mit dem Auftreten eines nicht mit der Telekommunikation zusammenhängenden Konnektivitätsproblems gerechnet werden, wenn ein mit einem LAN verbundenes Fotokopiergerät dedizierte Ports und proprietäre Protokolle zum Kommunizieren mit einem Server für Abbildungen/optische Zeichenerkennung (OCR) erfordert. Mit dem Diagnosetool der vorliegenden Offenbarung könnten Endbenutzer die angemessenen Diagnosen durchführen.
Für eine Vielzahl von Client-Server-Anwendungen, mit bekannten Client-Server-Konnektivitätserfordernissen, könnte das vorgeschlagene Diagnosetool:

(1) die Portverfügbarkeit auf dem Client und auf dem Server ermitteln;
(2) die Lizenzverfügbarkeit auf dem Client und auf dem Server ermitteln; und/oder
(3) die Pakettypen, die weitergegeben werden, und die Typen, die von Firewalls und Gateways blockiert werden, ermitteln.

Außer für die Ermittlung der obigen Informationen könnte das Diagnosetool der vorliegenden Offenbarung konfiguriert sein, um:

(1) einen Endbenutzer darüber zu informieren, welche der Client-Server-Anwendungen, die durch das Diagnosetool ausgewertet wurden, unterstützt werden und betreibbar sind, wenn dabei außer dem Endbenutzer keine anderen Menschen eingreifen (z. B. Systemadministratoren, Netzadministratoren, Firewall-Administratoren und Gateway-Administratoren); und/oder,
(2) wenn ermittelt wird, dass eine ausgewertete Anwendung nicht betreibbar ist (z. B. falls die erforderliche Lizenz nicht verfügbar ist) oder nur teilweise betreibbar ist (z. B. falls einige Medientypen, wenn auch nicht alle, von einer Firewall blockiert werden), (a) Diagnose-Informationen und Vorschläge für den Benutzer bereitzustellen und/oder (b) automatisch eine Nachricht an den oder die Menschen mit der Möglichkeit zur Steuerung der identifizierten Fehlerstelle zu senden (z. B. Systemadministratoren, Netzadministratoren, Firewall-Administratoren und Gateway-Administratoren).

Zusätzliche Features und Funktionen des vorgeschlagenen Diagnosetools werden mit Bezug auf die beigefügten Figuren besser verständlich.
1 zeigt ein Ausführungsbeispiel für ein erstes Kommunikationssystem 100 gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung. Das Kommunikationssystem 100 kann ein verteiltes System sein und umfasst in einigen Ausführungsformen ein Kommunikationsnetz 104, das Komponenten eines cloudbasierten Kommunikationssystems verbindet. In einigen Ausführungsformen umfasst das Kommunikationssystem 100 eine oder mehrere Clienteinrichtungen 108, die über das Kommunikationsnetz mit einem oder mehreren Servern 132 verbunden sind oder verbunden werden können.
Gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung kann das Kommunikationsnetz 104 beliebige Typen von bekannten Kommunikationsmedien oder Gruppierungen von Kommunikationsmedien umfassen und kann beliebige Typen von Protokollen zum Transportieren von Nachrichten zwischen Endpunkten nutzen. Das Kommunikationsnetz 104 kann drahtgebundene und/oder drahtlose Kommunikationstechnologien beinhalten. Das Internet ist ein Beispiel für das Kommunikationsnetz 104, das ein Internetprotokoll(IP)-Netz bildet, das aus vielen Computern, Computernetzen und anderen Kommunikationseinrichtungen besteht, die sich an verschiedenen Orten weltweit befinden, die durch viele Telefonsysteme und andere Mittel verbunden sind. Zu anderen Beispielen für das Kommunikationsnetz 104 zählen unter anderem ein herkömmliches analoges Telefonsystem (POTS), ein diensteintegriertes Digitalnetz (ISDN), das öffentliche Fernsprechwählnetz (PSTN), ein LAN, ein WAN, ein Session-Initiation-Protocol(SIP)-Netz, ein Voice-over-IP(VoIP)-Netz, ein Mobilfunknetz und beliebige andere Typen von paketvermittelten oder leitungsvermittelten Netzen, die aus dem Stand der Technik bekannt sind. Des Weiteren ist erkennbar, dass das Kommunikationsnetz 104 nicht auf irgendeinen bestimmten Netztyp beschränkt sein muss und stattdessen aus einer Anzahl unterschiedlicher Netze und/oder Netztypen bestehen kann. Ferner kann das Kommunikationsnetz 104 eine Anzahl unterschiedlicher Kommunikationsmedien wie ein Koaxialkabel, ein Kupferkabel/einen Kupferdraht, ein Glasfaserkabel, Antennen zum Senden/Empfangen drahtloser Nachrichten und Kombinationen davon umfassen.
Die Clienteinrichtungen 108 können mit Kommunikationsendpunkten oder Benutzereinrichtungen korrespondieren und können für die Nutzung durch einen oder mehrere Benutzer konfiguriert sein. Clienteinrichtungen 108, die für die Nutzung durch mehrere Benutzer konfiguriert sind, werden möglicherweise als gemeinsam benutzte Clienteinrichtungen bezeichnet.
Eine Clienteinrichtung 108 kann mit einem oder mehreren Kommunikationsendpunkten korrespondieren, die von einem Benutzer eingesetzt werden, um Kommunikationen mit dem Server 132 und/oder anderen Clienteinrichtungen 108 zu ermöglichen. In einigen Ausführungsformen beinhaltet eine Clienteinrichtung 108 möglicherweise unter anderem ein Telefon, ein Softphone, ein mobiles Telefon, eine Einrichtung für Kommunikationen zwischen mehreren Sprechern (z. B. ein Konferenztelefon), ein Videotelefon, einen PC, einen Laptop, ein Tablet, einen PDA, ein Smartphone, einen Thin Client oder Ähnliches. Es versteht sich, dass eine Clienteinrichtung 108 konfiguriert sein kann, um Interaktionen eines einzelnen Benutzers oder von mehreren Benutzern mit anderen Clienteinrichtungen 108 innerhalb eines Unternehmenskommunikationsnetzes und/oder über mehrere Kommunikationsnetze zu unterstützen.
Wie in 1 abgebildet, kann die Clienteinrichtung 108 eine oder mehrere Kommunikationsanwendungen 112, eine oder mehrere Netzschnittstellen 116, ein Diagnosetool 120 (z. B. eine clientseitige Komponente eines Diagnosetools), ein oder mehrere Betriebssysteme 124 und Lizenzinformationen 128 umfassen. Die Kommunikationsanwendung(en) 112 kann/können die Clienteinrichtung 108 zur Teilnahme an Kommunikationssitzungen mit anderen Clienteinrichtungen 108 befähigen. Zu Beispielen für Kommunikationsanwendungen 112 zählen unter anderem Sprachanwendungen, Videoanwendungen, SMS-Anwendungen, E-Mail-Anwendungen, Erweiterungen, Multimediakommunikationsanwendungen, Zusammenarbeitsanwendungen, Webbrowser und Ähnliches. Die Kommunikationsanwendung(en) 112 kann/können mit dedizierten Anwendungen korrespondieren oder sie können in das Betriebssystem 124 der Clienteinrichtung 108 integriert sein.
Die Netzschnittstelle(n) 116 der Clienteinrichtung 116 kann/können mit der Hardware und/oder den Treibern korrespondieren, die von der Clienteinrichtung 108 für Verbindungen zum Kommunikationsnetz 104 und die Kommunikation darüber genutzt wird/werden. Zu Beispielen für Netzschnittstellen 116 zählen unter anderem Wi-Fi-Ports, Ethernet-Ports, Antennen, Netzschnittstellenkarten (NICs), Treiber dafür und Ähnliches. Die Netzschnittstelle(n) 116 kann/können von Treibern betrieben werden, die vom Betriebssystem 124 gesteuert werden.
Das Diagnosetool 120 kann mit der clientseitigen Komponente des Diagnosetools korrespondieren, die zum Auswerten von Kommunikationsfähigkeiten der Clienteinrichtung 108 genutzt wird. Ferner, wie hierin erörtert werden wird, kann das Diagnosetool 120 den Mechanismus zum Erzeugen von Berichten, zum Anzeigen einer Rückmeldung für einen Benutzer der Clienteinrichtung 108 und für Ähnliches bereitstellen. Das Diagnosetool 120 kann auch konfiguriert sein, um einen umfassenden Diagnoseprozess als Antwort auf das Empfangen einer Anforderung von der Clienteinrichtung 108 zu initiieren. Vor allem kann ein Benutzer der Clienteinrichtung 108 eine Eingabe in die Clienteinrichtung 108 vornehmen, die initiiert, dass das Diagnosetool 120 mit einem Diagnoseprozess auf der Clienteinrichtung 108 und auf jeglichen Servern 132 beginnt, die gerade genutzt werden, um die Kommunikationsanwendung(en) 112 oder Kommunikationsfeatures während einer Kommunikationssitzung zu unterstützen. In einem spezifischeren Beispiel kann das Diagnosetool 120 einen Befehl an ein Diagnosetool 144 auf einem Server 132 liefern, der dafür ausgelegt ist, um Kommunikationen für die Kommunikationsanwendung(en) 112 auf der Clienteinrichtung 108 zu unterstützen, oder der momentan Kommunikationsfeatures für die Clienteinrichtung 108 während einer Kommunikationssitzung bereitstellt.
Das Betriebssystem 124 kann mit einem herkömmlichen Betriebssystem, das auf einem PC oder Ähnlichem ausgeführt wird, oder einem mobilen Betriebssystem korrespondieren. Das Betriebssystem 124 kann durch einen oder mehrere Mikroprozessoren der Clienteinrichtung 108 ausgeführt werden oder es kann in einer virtuellen Maschine ausgeführt werden. Zu Beispielen für ein Betriebssystem 124 zählen unter anderem Android, BSD, iOS, Linux, OS X, QNX, Microsoft Windows, Windows Phone und IBM z/OS. Das Betriebssystem 124 ist eine Mehrzweckanwendung, aufgrund derer der Zugriff auf und der Einsatz von mehreren anderen Anwendungen auf der Clienteinrichtung 108 möglich ist. Ferner kann das Betriebssystem 124 die Schnittstelle zwischen Hardware der Clienteinrichtung 108 (z. B. einem Benutzereingabeelement, einem Benutzerausgabeelement, Prozessoren, einem Speicherbaustein, (einer) Netzschnittstelle(n) 116 etc.) und den verschiedenen auf der Clienteinrichtung 108 gespeicherten Anwendungen 112 bereitstellen.
Die Lizenzinformationen 128 korrespondieren möglicherweise mit Lizenzen oder Informationen, die Lizenzen für die Nutzung des Betriebssystem 124 und/oder der Kommunikationsanwendungen 112 auf der Clienteinrichtung 108 beschreiben. In einigen Ausführungsformen können die Lizenzinformationen 128 praktisch innerhalb der Anwendung 112, 124, für die sie eine Nutzungslizenz gewähren, gespeichert sein. In anderen Ausführungsformen können die Lizenzinformationen 128 getrennt von der Anwendung, für die sie eine Nutzungslizenz gewähren, gespeichert sein. Die Lizenzinformationen 128 können in verschlüsselter oder unverschlüsselter Form gespeichert sein.
Die Clienteinrichtung 108 kann die Ressourcen des/der Server(s) 132 vor, während und/oder nach einer Kommunikationssitzung mit anderen Clienteinrichtungen einsetzen. Vor allem wenn eine Clienteinrichtung 108 in einer Kommunikationssitzung mit mindestens einer anderen Clienteinrichtung 108 involviert ist, können eine oder beide Clienteinrichtungen 108 eine oder mehrere Ressourcen von dem/den Server(n) 132 einsetzen, um verbesserte Features für die Kommunikationssitzung zu erhalten. In einem nicht ausschließlichen Beispiel kann/können der/die Server 132 (eine) Kommunikationsanwendung(en) 136 beinhalten, die ein oder mehrere Features für die Clienteinrichtung(en) 108 vor, während oder nach einer Kommunikationssitzung bereitstellt/bereitstellen. Zu Beispielen für Kommunikationsanwendungen 136 zählen unter anderem eine EC-500(Extension to Cellular)-Anwendung, eine Rufaufbauanwendung, eine Rufaufzeichnungsanwendung, eine Anrufer-ID-Anwendung, eine Anwendung für dynamische Gerätekopplung, eine Voicemail-Anwendung, eine E-Mail-Anwendung, eine Sprachanwendung, eine Videoanwendung, eine Textanwendung, eine Konferenzanwendung, eine Kommunikationsprotokollanwendung, eine Sicherheitsanwendung, eine Verschlüsselungsanwendung, eine Zusammenarbeitsanwendung, eine Whiteboard-Anwendung, Mobilitätsanwendungen, Präsenzanwendungen, Medienanwendungen, Messaging-Anwendungen, Bridging-Anwendungen, eine Text-zu-Sprache-Anwendung, eine Sprache-zu-Text-Anwendung, eine TTY-Anwendung und Anwendungen von beliebigen anderen Typen, die Kommunikationen zwischen Clienteinrichtungen 108 ergänzen oder verbessern können.
In einigen Ausführungsformen kann/können der/die Server 132 mit einem oder mehreren Servern (z. B. einem Servercluster) korrespondieren, die beim Herstellen von Kommunikationssitzungen, Sequenzieren von Anwendungen, Aktivieren von Kommunikationseinstellungen für Benutzer, Erzwingen von Kommunikationseinschränkungen für Benutzer etc. eingesetzt werden. Vor allem kann/können der/die Server 132 eine Nebenstellenanlage (PBX), einen Enterprise Switch, einen Enterprise Server, Kombinationen davon oder einen Switch oder Server eines Telekommunikationssystems von einem beliebigen anderen Typ beinhalten. Der/die Server 132 kann/können in einigen Ausführungsformen konfiguriert sein, um Telekommunikationsfunktionen auszuführen, etwa die Suite von Avaya-Aura^TM-Anwendungen von Avaya, Inc., einschließlich Communication Manager^TM, Avaya Aura Communication Manager^TM, Avaya IP Office^TM, Communication Manager Branch^TM, Session Manager^TM, System Manager^TM, MultiVantage Express^TM und Kombinationen davon.
1 zeigt auch den Server 132, wenn er eine oder mehrere Netzschnittstellen 140 und ein Diagnosetool 144 (z. B. eine serverseitige Komponente des Diagnosetools) umfasst. Die Netzschnittstelle(n) 140 des Servers 132 kann/können einen oder mehrere Ethernet-Ports, Datenports, Treiber dafür oder Ähnliches beinhalten. In einigen Ausführungsformen kann die Netzschnittstelle 140 mehrere registrierte Ports oder kurzlebige Ports umfassen. Der Server 132 umfasst zum Beispiel möglicherweise einen oder mehrere Ports mit einer Portnummer im Bereich von 0 bis 1023, welche mit den bekannten Ports oder Systemports korrespondieren, denen von der Internet Assigned Numbers Authority (IANA) eine spezifische Funktion zugewiesen werden kann oder nicht. In einem anderen Beispiel ist einem oder mehreren der Ports möglicherweise eine Zahl im Bereich zwischen 49152–65535 (über den registrierten Ports) zugewiesen, wobei sie in diesem Fall mit dynamischen oder privaten Ports korrespondieren, die nicht bei der IANA registriert werden können.
Das Diagnosetool 144 auf dem Server 132 kann mit einer komplementären Komponente des Diagnosetools 120 auf der Clienteinrichtung 108 korrespondieren. Zusammen können die Komponenten 120, 144 mit einem Diagnosetool korrespondieren, das fähig ist zum Analysieren des Gesamtverhaltens der Clienteinrichtung 108 und des/der Server(s) 132, um Probleme hinsichtlich Kommunikationsfähigkeiten oder deren Nichtvorhandensein zu behandeln. Vor allem können die Diagnosetools 120, 144 fähig sein zum Auswerten von Betriebsbedingungen des Geräts, in dem sie gespeichert sind, von Lizenzinformationen, der Portverfügbarkeit, der Paketübertragung, der Konnektivität und von Ähnlichem, um (eine) Quelle(n) und/oder Entitäten zu ermitteln, die mit (einer) Quelle(n) von Geräten assoziiert sind, die gerade eine Client-Server-Beziehung und von der Client-Server-Beziehung gewünschte Kommunikationsfähigkeiten beeinträchtigen.
Nunmehr werden mit Bezug auf 2 zusätzliche Details eines zweiten Kommunikationssystems 200, das mit einer spezifischen Version des ersten Kommunikationssystems 100 korrespondieren kann, gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Kommunikationssystem 200 bildet eine oder mehrere in einem gehosteten Netz 204 befindliche Clienteinrichtungen 108 sowie eine oder mehrere in einem entfernten Netz 108 befindliche Clienteinrichtungen 108 ab. Das gehostete Netz 204 kann mit einem Unternehmensnetz, einem vertrauenswürdigen Netz oder Ähnlichem korrespondieren, welches auch einen oder mehrere Server 132 enthält. Die Clienteinrichtungen 108 und der Server 132 im gehosteten Netz 204 können über ein vertrauenswürdiges Netz 156 in Form eines LAN, eines WAN, eines Virtual Private Network (VPN) oder von Ähnlichem verbunden sein. Das gehostete Netz 204 kann auch ein Randelement 208, einen Switch 216 und eine Interactive-Voice-Response(IVR)-Einheit 220 umfassen.
In einigen Ausführungsformen umfasst das Randelement 208 möglicherweise eine Firewall 212 oder eine ähnliche Komponente, die zur Aufrechterhaltung der Sicherheit und der Vertrauenswürdigkeit innerhalb des gehosteten Netzes 204 beiträgt. Vor allem umfasst das Randelement 208 möglicherweise einen Session Border Controller (SBC), ein Gateway, ein Network-Address-Translator(NAT)-Gerät oder irgendein anderes Netzelement, das zwischen dem vertrauenswürdigen Netz 156 und einem ersten nicht vertrauenswürdigen Kommunikationsnetz 104a (z. B. dem Internet oder irgendeinem anderen paketbasierten Kommunikationsnetz) angeordnet ist.
Der Switch 216 kann mit einem zweiten Gerät im gehosteten Netz 204 korrespondieren, welches das vertrauenswürdige Netz 156 von einem externen Netz trennt, etwa einem zweiten Kommunikationsnetz 104b (z. B. dem PSTN oder irgendeinem anderen leitungsvermittelten Netz). Der Switch 216 kann mit einem einzelnen Switch oder einer Vielzahl von Switches korrespondieren. Der Switch 216 kann auch Protokollumwandlungen zwischen dem zweiten Kommunikationsnetz 104b und dem vertrauenswürdigen Netz 156 bereitstellen.
Das entfernte Netz 224 wird als entferntes Netz bezeichnet, da das entfernte Netz 224 über keinen lokal gehosteten Server 132 verfügt. Es versteht sich, dass eine Clienteinrichtung 108 nicht zwangsläufig zu einem (gehosteten, entfernten oder anderen) Netz gehören muss. Vielmehr kann eine Clienteinrichtung 108 auch über ein Modem, einen Netzzugangspunkt (z. B. einen kabelgebundenen oder drahtlosen Zugangspunkt) oder Ähnliches direkt mit einem Kommunikationsnetz 104 verbunden sein.
Ähnlich wie das gehostete Netz 204 kann das entfernte Netz 224 ebenfalls ein Randelement 208 mit einer Firewall 212, einen Switch 216 und Ähnliches umfassen. In einigen Ausführungsformen ist kein vertrauenswürdiges Netz 156 vorhanden, sondern das entfernte Netz 224 umfasst möglicherweise einen Zugangspunkt 228 wie einen (kabelgebundenen oder drahtlosen) Router oder eine ähnliche Komponente, die Konnektivität zwischen dem Randelement 208 des entfernten Netzes 224 und den Clienteinrichtungen 108 bereitstellt. Auch versteht es sich, dass die Funktionalität des Randelements 208 und des Switches 216 in einem einzigen Gerät implementiert sein kann.
3 bildet zusätzliche Details eines beispielhaften Servers 132 ab. Es versteht sich, dass ein Server 132 einige oder alle der im Server 132 von 3 abgebildeten Komponenten umfassen kann. In der abgebildeten Ausführungsform umfasst der Server 132 einen oder mehrere Prozessoren (z. B. Mikroprozessoren, Parallelprozessoren, Chips einer integrierten Schaltung (IC) etc.), einen Speicherbaustein 308, eine Stromquelle 312 und einen oder mehrere Ports 316a-N.
In einigen Ausführungsformen kann der Speicherbaustein 308 ein beliebiges nicht transientes computerlesbares Medium oder eine Gruppierung von computerlesbaren Medien von einem beliebigen Typ beinhalten. Der Speicherbaustein 308 kann flüchtig, nicht flüchtig oder virtuell sein. Zu Beispielen für Speicherbausteine 308 zählen unter anderem Flashspeicher, ROM/PROM/EPROM/EEPROM-Speicherbausteine, Firmware, RAMs, DRAMs, SRAMs, Cachespeicher, Pufferspeicher, Kombinationen davon oder Ähnliches. In der abgebildeten Ausführungsform speichert der Speicherbaustein 308 Befehle, die von dem/den Prozessor(en) 304 ausführbar sind. Zu Beispielen für die Befehle oder Daten, die im Speicherbaustein 308 gespeichert werden können, zählen die Kommunikationsanwendung 136 und das Diagnosetool 144.
Wie oben erwähnt, können die Lizenzinformationen 128 in die Kommunikationsanwendung 136 aufgenommen werden. Das Diagnosetool 144 kann ein Berichtstool 320 beinhalten, das genutzt wird, um einen Diagnosebericht im Auftrag des Diagnosetools 144 zu erzeugen und für einen Benutzer und/oder einen Systemadministrator bereitzustellen. Das Diagnosetool 144 kann auch eine Testpakettabelle 324 oder irgendeine andere Datenstruktur beinhalten, über die es möglich ist, dass das Diagnosetool 144a-priori-Wissen (z. B. Wissen vor der Initiierung eines Diagnoseprozesses) zu den Typen der Testpakete hat, die übertragen werden sollen, wenn ein Befehl zum Beginnen mit einem Diagnoseprozess am Server 132 empfangen wird. Mit anderen Worten, die Testpakettabelle 324 kann das Diagnosetool 144 mit den Informationen ausstatten, die zum Erzeugen einer Menge von Testpaketen benötigt werden, wobei jedes Paket in der Menge von Testpaketen von einem bestimmten Typ ist und zum Testen eines konkreten Ports 316a-N genutzt wird. Es versteht sich, dass die Informationen aus der Testpakettabelle 324 programmgesteuert für das Diagnosetool 144 verfügbar gemacht werden können, statt in einer Struktur einer Tabelle 324 enthalten zu sein.
Auch wenn nur das Diagnosetool 144 auf dem Server 132 derart abgebildet ist, dass es ein Berichtstool 320 und eine Testpakettabelle 324 aufweist, versteht es sich, dass das Diagnosetool 120 auf der Clienteinrichtung 108 ebenfalls oder alternativ ein Berichtstool 320 und/oder eine Testpakettabelle 324 aufweisen kann. Das Berichtstool 320 kann einen oder mehrere Diagnoseberichte erzeugen, die eine Quelle eines Fehlers während einer Kommunikationssitzung, Kommunikationsfähigkeiten einer Clienteinrichtung 108 vor einer Kommunikationssitzung und/oder eine Quelle eines Fehlers, nachdem eine Kommunikationssitzung geendet hat, identifizieren. Das Berichtstool 320 kann den Bericht oder Teile davon für interessierte Parteien (z. B. Teilnehmer an einer Kommunikationssitzung, einen Systemadministrator, einen Administrator einer konkreten Komponente, die in der Client-Server-Beziehung involviert ist, etc.) in Form einer E-Mail, eines Anhangs zu einer E-Mail, einer SMS-Nachricht, einer Textnachricht, eines gedruckten Berichts, einer Benachrichtigung, eines Blinksignals, einer Warnmeldung oder von Ähnlichem bereitstellen.
Die Stromquelle 312 korrespondiert möglicherweise mit einer internen Stromquelle (z. B. einer Batterie oder einer Gruppierung von Batterien) und/oder mit einem Energieumwandlungsgerät (z. B. einem Transformator, einem Stromadapter, einem Energieaufbereiter etc.). Die Stromquelle 312 kann den Server 132 mit Strom versorgen, der hinreichend ist für die Aktivierung der Funktionalität des Prozessors/der Prozessoren 304 und der anderen Komponenten im Server 132, für deren Betrieb Strom erforderlich ist.
Die Ports 316a-N korrespondieren mit spezifischen Beispielen für die Netzschnittstelle 140, die in einem Server 132 beinhaltet sein kann. Wenngleich drei Ports abgebildet sind, versteht es sich, dass ein Server 132 auch mehr oder weniger Ports umfassen kann. Jeder Port kann mit einem tatsächlichen physischen Port (z. B. mit Hardwareadaptern und Treibern) oder mit einem virtuellen Port korrespondieren. Überdies kann jedem Port 316 eine konkrete Funktion zugewiesen sein und er kann deshalb dafür eingesetzt werden, um Pakete von einem bestimmten Typ zu empfangen. Das Diagnosetool 144 kann auf die verschiedenen Ports 316a-N im Server und die Funktion der Ports 316a-N hingewiesen werden. Die Kenntnis solcher Informationen kann im Diagnosetool 144 beim Identifizieren potenzieller Quellen von Problemen in einer Client-Server-Beziehung förderlich sein und kann in einigen Ausführungsformen dazu beitragen, dass das Diagnosetool 144 erkennt, welche Typen von Testpaketen an den Client 108 zu senden sind (z. B. weil der Server 132 einen korrespondierenden Port hat) und welche Typen von Testpaketen nicht für Diagnosezwecke benötigt werden (z. B. weil der Server 132 keinen korrespondierenden Port hat).
Nunmehr wird mit Bezug auf 4 ein Diagnoseprozess gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Der Diagnoseprozess beginnt damit, dass die Clienteinrichtung 108 eine Benutzereingabe empfängt, die den Diagnoseprozess initiiert (Schritt 404). In einer anderen Ausführungsform kann der Diagnoseprozess automatisch als Antwort darauf initiiert werden, dass ein Zeitgeber abläuft (z. B. weil ein routinemäßiger Diagnoseprozess gewünscht wird), ein zuvor ermitteltes Ereignis eintritt oder ein beliebiges anderes Ereignis eintritt, welches die Initiierung des Diagnoseprozesses automatisch auslösen kann. Die manuelle Initiierung des Diagnoseprozesses kann an der Clienteinrichtung 108 und vor allem dem Diagnosetool 120 auf der Clienteinrichtung 108 empfangen werden, während die automatische Initiierung des Diagnoseprozesses an jedem der zwei Diagnosetools 120, 144 erfolgen kann. Falls der anfängliche Befehl vom Diagnosetool 120 an das Diagnosetool 144 als unzustellbar (z. B. aufgrund eines Netzfehlers, eines Verbindungsfehlers etc.) an die Clienteinrichtung 108 zurückgegeben wird, kann das Diagnosetool 120 ermitteln, dass das erste Kommunikationsnetz 104a nicht verfügbar ist, und kann versuchen, einen zweiten Initiierungsbefehl über das zweite Kommunikationsnetz 104b an das Diagnosetool 144 zu übertragen. Vor allem, falls der Benutzer der Clienteinrichtung 108 über Sprachfähigkeiten verfügt und eine Verbindung zu einem IVR 220 des gehosteten Netzes 204 aufbauen kann, kann dann vermutet werden, dass das zweite Kommunikationsnetz 104b mindestens zum Übermitteln von Daten von der Clienteinrichtung 108 in das gehostete Netz 204 fähig ist. Hierdurch können auch Informationen für das Diagnosetool 120 dahingehend bereitgestellt werden, dass die Quelle von Kommunikationsproblemen entweder im ersten Kommunikationsnetz 104a oder an einem der Randelemente 208 in den Netzen 204, 224 zu finden ist.
Der Diagnoseprozess wird fortgesetzt, indem die Clienteinrichtung 108 einen Befehl zum Beginnen mit der serverseitigen Diagnose an den/die in der Client-Server-Kommunikation involvierten Server 132 sendet (Schritt 440). Auf der Clientseite beginnt das Diagnosetool 120 mit seinem Teil des Diagnoseprozesses, indem es identifiziert, welche Typen von Paketen zu senden sind und zu welchen Servern die Pakete zu senden sind (Schritt 408). Vor allem kann das Diagnosetool 120 den/die Server 132 ermitteln, mit dem/denen es kommunizieren muss, um gewünschte Kommunikationsfeatures zu erhalten. Diese Informationen können im Diagnosetool 120 vorprogrammiert sein oder das Diagnosetool 120 kann eine Routine ablaufen lassen, durch die ein Benutzer der Clienteinrichtung 108 zu den Typen der Kommunikationsfähigkeiten befragt wird, die für eine Kommunikationssitzung oder mehrere Kommunikationssitzungen gewünscht werden. Pakettypen sind auch definierbar anhand der Typen von Medien, die von einer Kommunikationsanwendung 112, 136 eingesetzt werden, der Typen von Anruffeatures, die von solchen Kommunikationsanwendungen 112, 136 verfügbar gemacht werden, der Typen von Daten, die zum Unterstützen von Anruffeatures, die von den Kommunikationsanwendungen 112, 136 verfügbar gemacht werden, erforderlich sind, etc.
Außer, dass das Diagnosetool 120 die Typen von an den/die Server 132 zu sendenden Testpaketen ermittelt, ermittelt es auch auf der Clienteinrichtung 108 verfügbare Lizenzinformationen 128. Vor allem kann das Diagnosetool 120 ermitteln, ob bestimmte Kommunikationsanwendungen 112 über eine korrespondierende Lizenz verfügen und, falls nein, welche Typen von Lizenzen erforderlich sind, um solche Kommunikationsanwendungen 112 zu aktivieren.
Das Diagnosetool 120 setzt den Diagnoseprozess fort, indem es die Portverfügbarkeit für den/die Server 132 ermittelt, den/die es bei Schritt 408 identifiziert hat (Schritt 412), und seine umfassende Diagnoseroutine ausführt (Schritt 420). Vor allem kann das Diagnosetool 120 das/die Testpaket(e) an den/die ermittelten Server 132 übertragen und auf eine Antwort warten. Ein solcher Prozess ist bekannt als „Anpingen“ des/der Server(s) mit den ermittelten Testpaketen. Wenn bestätigt wird, dass alle der übertragenen Testpakete durch den/die Server 132 empfangen wurden, kann das Diagnosetool 120 ermitteln, dass die nötigen Ports 316a-N für den/die Server 132 verfügbar sind. Wenn hingegen nicht bestätigt wird, dass ein oder mehrere der Testpakete durch den/die Zielserver 132 empfangen wurden, kann das Diagnosetool 120 ermitteln, dass der Port, der mit dem fehlenden Testpaket korrespondiert, nicht verfügbar ist, geschlossen ist, für eine andere Kommunikationssitzung vorgesehen ist etc. Falls bestätigt wird, dass keines der Testpakete durch den/die Zielserver 132 empfangen wurde, kann das Diagnosetool 120 ermitteln, dass entweder im ersten Kommunikationsnetz 104a oder an irgendeiner zwischen der Clienteinrichtung 108 und dem Server 132 angeordneten Kommunikationskomponente ein Konnektivitätsproblem besteht. Beispielsweise blockiert eine Firewall 212 entweder am gehosteten Netz 204, am entfernten Netz 224 oder an irgendeinem anderen dazwischen liegenden Netz möglicherweise gerade einige oder alle der Pakete (einschließlich Testpaketen), die zwischen der Clienteinrichtung 108 und dem/den Zielserver(n) 132 übertragen werden.
Das Diagnosetool 120 kann basierend auf den Informationen, die infolge der Ausführung der Diagnoseroutine bei Schritt 420 erhalten werden, Diagnoseergebnisse hinsichtlich der Clientseite des Systems erhalten (Schritt 424). Für einen vollständigen Diagnosebericht sind jedoch auch serverseitige Diagnosen dienlich, die durch das Diagnosetool 144 durchgeführt werden.
Demgemäß kann die serverseitige Diagnose seriell oder sequenziell hinsichtlich der clientseitigen Diagnose durchgeführt werden. Wenn das Diagnosetool 144 des Servers 132 den auslösenden Befehl vom Diagnosetool 120 der Clienteinrichtung 108 empfängt, ermittelt das Diagnosetool 144, welche Typen von Testpaketen an die Clienteinrichtung 108 zu senden sind (Schritt 444). Ganz ähnlich wie bei Schritt 408 kann dieser Schritt involvieren, dass das Diagnosetool 144 die Typen der gewünschten Kommunikationsfeatures, der gewünschten Medien etc. identifiziert. In einigen Ausführungsformen kann das Diagnosetool 144 diese Informationen unabhängig vom Diagnosetool 120 ermitteln. In einigen Ausführungsformen kann das Diagnosetool 120 das Diagnosetool 144 bezüglich der Typen der Testpakete anweisen, die für den Diagnoseprozess erforderlich sind.
Außer, dass das Diagnosetool 144 die Typen von an die Clienteinrichtung 108 zu sendenden Testpaketen ermittelt, bestimmt es auch Lizenzinformationen 128, die auf dem Server 132 verfügbar sind (Schritt 448). Dieser konkrete Schritt kann involvieren, dass die verschiedenen im Speicherbaustein 308 gespeicherten Lizenzen 128 analysiert werden, dass bestimmte in einer Kommunikationsanwendung 136 gespeicherte Lizenzen 128 analysiert werden und/oder dass die sonst für die Kommunikationsanwendungen 136 des Servers 132 erteilten Lizenzen analysiert werden.
Das Diagnosetool 144 setzt den Diagnoseprozess fort, indem es die Portverfügbarkeit aus seiner eigenen Perspektive ermittelt (Schritt 452) und seine umfassende Diagnoseroutine ausführt (Schritt 456). Insbesondere kann das Diagnosetool 144 versuchen, sein(e) Testpaket(e) über jeden der zugewiesenen Ports 316a-N, abhängig vom Typ des gerade übertragenen Testpakets, an die Clienteinrichtung 108 zu übertragen. Falls der Port selbst berichtet, dass er nicht verfügbar ist, oder keine Antwort auf ein konkretes Testpaket vorliegt, kann ermittelt werden, dass der korrespondierende Port 316a-N eine potenzielle Quelle des Kommunikationsproblems ist.
Die Ergebnisse der umfassenden Diagnoseroutine werden dann am Diagnosetool 144 erfasst (Schritt 460) und ein serverseitiger Bericht wird basierend auf diesen Informationen erzeugt (Schritt 464). Das Diagnosetool 144 kann dann seinen serverseitigen Diagnosebericht an das Diagnosetool 120 auf dem Client 108 übertragen (Schritte 468, 428), sodass das Diagnosetool 120 über sowohl die clientseitigen als auch die serverseitigen Informationen zum Diagnosebericht verfügt. In einigen Ausführungsformen ist es möglicherweise wünschenswert, den clientseitigen Bericht und den serverseitigen Bericht am Diagnosetool 144 des Servers 132 statt der Clienteinrichtung 108 zu erfassen. Mit anderen Worten, Ausführungsformen der vorliegenden Offenbarung sind nicht derart auszulegen, dass sie die Erfindung auf das Ausführungsbeispiel von 4 beschränken. Der Server kann am Ende seines Diagnoseprozesses für eine Problembehandlung optional einen Kontakt erzeugen und an einen zuständigen Administrator übertragen (Schritt 472). Dieser Schritt ist möglicherweise nur erforderlich, falls der Server 132 ermittelt hat, dass eine oder mehrere potenzielle Quellen eines Problems mit dem Server 132 assoziiert waren. Mit anderen Worten, falls der Server 132 ermittelt, dass er mindestens eine Quelle eines Kommunikationsproblems ist (z. B. aufgrund von Port-Unzulänglichkeiten, Lizenz-Unzulänglichkeiten etc.), kann der Server 132 einen Systemadministrator für diesen Server 132 direkt kontaktieren, um das Problem zu behandeln.
Das Diagnosetool 120 am Client 108 kann diesen Bericht auch an einen Systemadministrator für den/die als potenzielle Problemquelle(n) identifizierten Server 132 senden. Weil das Diagnosetool 120 in einigen Ausführungsformen sowohl clientseitige als auch serverseitige Informationen erfasst, kann das Diagnosetool 120 einen vollständigen Diagnosebericht erzeugen (Schritt 432) und ihn an die Entitäten übertragen, die die potenzielle Quelle eines Problems verwalten oder ihre Eigentümer sind. Alternativ oder zusätzlich kann das Diagnosetool 120 dem Benutzer der Clienteinrichtung 108 über ein Benutzerausgabeelement (z. B. einen Bildschirm) der Clienteinrichtung 108 oder durch Drucken eines physischen Berichts mit einem Drucker oder Ähnlichem den vollständigen Diagnosebericht teilweise oder ganz anzeigen (Schritt 436). Mithin erhalten der Benutzer und/oder die zuständigen Systemadministratoren sofort Zugriff auf denselben Diagnosebericht, der sowohl die clientseitige Diagnose als auch die serverseitige Diagnose beinhaltet.
Nunmehr werden mit Bezug auf 5 zusätzliche Details zum Ablaufenlassen einer Diagnoseroutine am Diagnosetool 120 der Clienteinrichtung 108 gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren beginnt bei Schritt 504 und wird fortgesetzt, indem das Diagnosetool 120 versucht, Befehle zum Initiieren einer Diagnoseroutine an einen oder mehrere Server 132 zu senden (Schritt 508). In einigen Ausführungsformen versucht das Diagnosetool 120 zunächst, die Befehle über das erste Kommunikationsnetz 104a (z. B. ein paketbasiertes Netz wie das Internet) zu senden.
Das Diagnosetool 120 wartet dann, um festzustellen, ob der/die Server 132 den Empfang des Befehls/der Befehle quittiert/quittieren (Schritt 512). Falls der/die Zielserver 132 den Empfang des Befehls/der Befehle quittiert/quittieren, lässt das Diagnosetool 120 seine Diagnoseroutine über das erste Kommunikationsnetz 104a weiter ablaufen (Schritt 516).
Falls hingegen keine Meldung dahingehend vorliegt, dass der/die Server 132 den Befehl vom Diagnosetool 120 empfangen hat/haben, versucht das Diagnosetool 120, die Befehle erneut an den/die Server 132 zu senden, diesmal jedoch über ein zweites Kommunikationsnetz 104b (z. B. ein leitungsvermitteltes Netz) (Schritt 520). Nach der Übertragung dieses zweiten Befehls kann das Diagnosetool 120 seine clientseitige Diagnoseroutine weiter ablaufen lassen. Zusätzlich überwacht das Diagnosetool 120 seine Netzschnittstelle 116 auf Testpakete, die durch den/die Server 132 übertragen werden, der/die auch eigene Diagnoseroutinen ablaufen lässt/lassen (Schritt 524). Falls das Diagnosetool 120 keine Testpakete empfängt, kann das Diagnosetool 120 berücksichtigen, dass der Server eine potenzielle Problemquelle ist (Schritt 532). Falls die Clienteinrichtung 108 hingegen ein oder mehrere Testpakete empfängt, kann das Diagnosetool 120 eine Firewall 212 und/oder Routing-Unzulänglichkeiten als mindestens eine potenzielle Problemquelle berücksichtigen (Schritt 528). Es ist für das Diagnosetool 120 möglicherweise schwierig zu ermitteln, ob die Problemquelle die Firewall 212 am gehosteten Netz 208 oder eine Firewall an irgendeinem anderen dazwischen liegenden Netz ist. Jedoch kann das Diagnosetool 120 konfiguriert sein, um zusätzliche Diagnoseprozesse ablaufen zu lassen, um zu ermitteln, ob die Firewall 212 gerade ein oder mehrere Pakete am Erreichen des Zielservers 132 hindert, zum Beispiel durch Senden von zusätzlichen Paketen von unterschiedlichen Typen und/oder von Paketen, die unterschiedliche Nutzdaten enthalten, um zu ermitteln, ob solche Pakete den Zielserver 132 erreichen. Es versteht sich, dass, falls die Clienteinrichtung 108 innerhalb desselben gehosteten Netzes 204 wie der Zielserver 132 ist, es möglich sein kann, die Firewall 212 bei Schritt 528 als eine Quelle des potenziellen Problems zu eliminieren.
Nunmehr werden mit Bezug auf 6 zusätzliche Details des Abschließens eines Diagnoseprozesses gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Es versteht sich, dass dieser Abschluss am Diagnosetool 120, am Diagnosetool 144 oder an einer Kombination davon erfolgen kann. Das Verfahren beginnt bei Schritt 604, wenn das Diagnosetool 120, 144 die nötigen Berichte sowohl aus den clientseitigen als auch aus den serverseitigen Diagnoseprozessen erhalten hat. Danach ermittelt das Diagnosetool 120, 144 die eine oder die mehreren Quellen des potenziellen Problems basierend auf den in den Diagnoseberichten enthaltenen Informationen (Schritt 608).
Das Diagnosetool 120, 144 ordnet dann die potenzielle(n) Problemquelle(n) einer oder mehreren Entitäten zu, die verantwortlich für die Verwaltung der potenziellen Problemquelle(n) ist/sind und/oder über eine eindeutige Fähigkeit verfügt/verfügen, entweder Probleme zu behandeln, Problembehandlungsinformationen bereitzustellen oder die potenzielle(n) Problemquelle(n) zu steuern (Schritt 612). In einigen Ausführungsformen können diese Informationen in einer Tabelle geführt werden, die Komponenten, die in einer Client-Server-Kommunikation involviert sind, verschiedenen Entitäten zuordnet. In anderen Ausführungsformen kann eine Frage an einen Systemadministrator auf einer hohen Ebene gesendet werden, um eine Entität zu ermitteln, die mit einer konkreten potenziellen Problemquelle assoziiert ist.
Nachdem die eine oder die mehreren Entitäten ermittelt worden sind, wird das Verfahren fortgesetzt, indem Kontaktinformationen für die eine oder die mehreren Entitäten ermittelt werden (Schritt 616). Die Kontaktinformationen können die Form einer E-Mail-Adresse, einer Telefonnummer, einer Hotline, einer IM-Adresse, einer Website etc. haben. Das Diagnosetool 120, 144 kann den Diagnosebericht (oder für die Entität relevante Teile) dann über die Kontaktinformationen an die Entität senden (Schritt 620). Ein zusätzlicher und optionaler Schritt kann durchgeführt werden, indem ein Kontakt zwischen einem Benutzer der Clienteinrichtung 108 und der einen oder den mehreren bei Schritt 612 identifizierten Entitäten automatisch eskaliert wird (Schritt 624). Falls beispielsweise ein Benutzer der Clienteinrichtung 108 Probleme mit einer Kommunikationsanwendung 112 hat und die potenzielle Quelle des Problems als Firewall-Unzulänglichkeit 212 und Unzulänglichkeit des Servers 132 ermittelt wird, können zwei getrennte Kontakte zwischen dem Benutzer der Clienteinrichtung 108 und jeder für die potenzielle Quelle des Problems verantwortlichen Entität automatisch initiiert werden. Einer der automatischen Kontakte kann ein Echtzeitkontakt sein (z. B. ein Sprachanruf), während ein anderer der automatischen Kontakte ein Nichtechtzeitkontakt sein kann (z. B. eine E-Mail, ein Chat etc.). Mithin kann der Benutzer leicht und effizient anfangen, gegen sein Problem vorzugehen, ohne die mit den potenziellen Problemen assoziierten Entitäten unabhängig identifizieren oder Kontaktinformationen für die Entitäten identifizieren zu müssen.
Nunmehr werden mit Bezug auf 7 Details eines Verfahrens zum Analysieren von Lizenzinformationen gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Ganz ähnlich wie in 6 können das Diagnosetool 120 auf dem Client 108, das Diagnosetool 144 auf dem Server 132 oder eine Kombination davon einige oder alle der in 7 beschriebenen Schritte durchführen.
Das Verfahren beginnt damit, dass das Diagnosetool 120, 144 mit der Analyse von Lizenzinformationen beginnt (Schritt 704). Diese Analyse kann lokal erfolgen (z. B. für die Lizenzinformationen im selben Gerät wie das Analyse-Diagnosetool 120, 144) oder entfernt (z. B. an einer Stelle, an der eines der Diagnosetools 120, 144 Lizenzinformationen von einem anderen entfernten Gerät anfordert).
Im Rahmen der Analyse der Lizenzinformationen wird/werden die Kommunikationsanwendung(en) 112 ermittelt, die für die Clienteinrichtung 108 verfügbar ist/sind und/oder von der Clienteinrichtung 108 für konkrete Typen von Kommunikationssitzungen eingesetzt wird/werden (Schritt 708). Für jede bei Schritt 708 identifizierte Anwendung wird ermittelt, welche(r) Server 132 zum Unterstützen von Kommunikationen über die Kommunikationsanwendung 112 eingesetzt wird/werden (Schritt 712). Vorher, nachher oder gleichzeitig damit kann das Diagnosetool 120, 144 die Lizenzinformationen für jede Anwendung 112 auf der Clienteinrichtung 108 kontrollieren (Schritt 716). In anderen Ausführungsformen kann das Diagnosetool 120, 144 andere Geräte kontrollieren, um zu ermitteln, ob die Lizenzen für die Kommunikationsanwendungen 112 statt auf der Clienteinrichtung 108 an irgendeiner anderen Stelle gespeichert sind. Das Diagnosetool 120, 144 kann die Lizenzinformationen 18 auch an dem/den bei Schritt 712 identifizierten Server(n) 132 kontrollieren (Schritt 720). In einigen Ausführungsformen werden die Lizenzinformationen 128 für jede Kommunikationsanwendung 136 auf dem zum Unterstützen einer Kommunikationsanwendung 112 auf der Clienteinrichtung 108 genutzten Server 132 analysiert.
Das Verfahren wird basierend auf der Analyse der Lizenzinformationen 128 an der Clientseite und der Serverseite fortgesetzt, indem ermittelt wird, welche Anwendungen 112, 136 lizenziert und/oder unlizenziert sind (Schritt 724). Das Nichtvorhandensein einer Lizenz kann als Antwort darauf ermittelt werden, dass eine Anwendung über keine Lizenz, eine abgelaufene Lizenz oder eine ungültige (z. B. doppelte) Lizenz verfügt. Falls jede einzelne analysierte Anwendung 112, 136 über eine korrespondierende gültige Lizenz verfügt, ist der Prozess beendet. Demnach wird der Prozess fortgesetzt, indem ermittelt wird, ob zusätzliche Lizenzen gewünscht werden (Schritt 728). Wird diese Frage mit nein beantwortet, werden keine zusätzlichen Lizenzen benötigt und der Prozess wird fortgesetzt, indem die Diagnosetools 120, 144 zusätzliche Diagnosen zu den lizenzierten Anwendungen ablaufen lassen (z. B. mit Blick auf andere Unzulänglichkeiten als Lizenz-Unzulänglichkeiten) (Schritt 736). Falls hingegen mindestens ein Problem im Zusammenhang mit einer Lizenz entweder auf der Clienteinrichtung 108 oder auf dem Server 132 identifiziert wurde, wird der Prozess fortgesetzt, indem versucht wird, die zusätzlichen Lizenzen zu erhalten (Schritt 732). Hierbei handelt es sich um einen optionalen Schritt, der sich durchführen lässt, indem der Benutzer der Clienteinrichtung 108 oder ein Systemadministrator gefragt wird, ob zusätzliche Lizenzen gewünscht werden. In anderen Ausführungsformen kann das Nichtvorhandensein der einschlägigen Lizenz(en) einem Benutzer und/oder einem Systemadministrator ohne Weiteres gemeldet werden, ohne dass zwangsläufig die Notwendigkeit des Erwerbs zusätzlicher Lizenzen nahegelegt wird. Das Verfahren wird dann bis zu Schritt 736 fortgesetzt.
Nunmehr werden mit Bezug auf 8 zusätzliche Details eines Verfahrens zum Testen der Verfügbarkeit des Ports 316 gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Wieder können wie in den 6 und 7 das Diagnosetool 120 auf dem Client 108, das Diagnosetool 144 auf dem Server 132 oder eine Kombination davon einige oder alle der in 8 beschriebenen Schritte durchführen.
Das Verfahren beginnt damit, dass das Diagnosetool 120, 144 Porttests initiiert (Schritt 804) und für jeden zu testenden Port 316 ein angemessenes Testpaket erzeugt (Schritt 808). Weil der Server 132 möglicherweise für konkrete Funktionen oder Pakettypen vorgesehene Ports 316 aufweist, kann eine Analyse eines konkreten Ports 316 (abhängig von der zugewiesenen Funktionalität des Ports 316) die Nutzung eines spezifischen Testpakets erfordern. Das Verfahren wird fortgesetzt, indem das Diagnosetool 120, 144 sein Gerät (z. B. die Clienteinrichtung 108 oder den Server 132) anweist zu versuchen, die Testpakete über jeden Port (z. B. in den assoziierten Port 316 hinein oder aus ihm heraus) zu senden (Schritt 812). Das Diagnosetool 120, 144 wartet dann, um festzustellen, ob eine Antwort auf das Testpaket (z. B. eine Bestätigung des Empfangs) für das Testpaket/die Testpakete, das/die bei Schritt 812 übertragen wurde(n), empfangen wird (Schritt 816). Das Diagnosetool 120, 144 kann eine zuvor ermittelte Zeit lang darauf warten, ob eine solche Antwort empfangen wird (Schritt 820).
Falls der Zeitgeber nicht abgelaufen ist, jedoch keine Antwort auf das Testpaket empfangen wurde, wartet das Diagnosetool 120, 144 noch weiter. Sobald der Zeitgeber abgelaufen ist, ermittelt das Diagnosetool 120, 144, ob in Verbindung mit jedem übertragenen Testpaket Antworten empfangen wurden (Schritt 824). Für diejenigen Testpakete, die keine Antwort empfangen haben, kann das Diagnosetool 120, 144 ermitteln, dass der/die mit den Testpaketen assoziierte(n) Port(s) 316 mit einer potenziellen Problemquelle korrespondiert/korrespondieren (Schritt 828). Es kann auch möglich sein, Probleme hinsichtlich des/der bei Schritt 828 identifizierten Ports 316 weiter zu behandeln, indem versucht wird, unterschiedliche Pakettypen über den/die Port(s) 316 zu senden, und/oder indem die Portaktivität für die Nutzung durch andere Anwendungen überwacht wird.
Nunmehr wird mit Bezug auf 9 noch ein anderer Diagnoseprozess gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Der Prozess beginnt damit, dass das eines der Diagnosetools 120, 144 den Diagnoseprozess initiiert (Schritt 904). In einigen Ausführungsformen initiiert das Diagnosetool 120 den Prozess als Antwort darauf, dass eine Anforderung von einem Benutzer der Clienteinrichtung 108 empfangen und dann ein Befehl zum Beginnen mit dem Prozess an den Server 132 übertragen wird.
Der Prozess wird fortgesetzt, indem der Server 132 eine erste Menge von Testpaketen zu einer ersten Zeit oder ungefähr zu einer ersten Zeit erzeugt (Schritt 908). Die erste Menge von Testpaketen lässt sich, mindestens teilweise, basierend auf in der Testpakettabelle 324 enthaltenen Informationen ermitteln. Zusätzlich kann die erste Zeit mit einer Zeit korrespondieren, die sich unmittelbar dem Empfang und der Verarbeitung eines Befehls von der Clienteinrichtung 108 zum Beginnen mit dem Diagnoseprozess anschließt. Mit anderen Worten, die erste Zeit kann mit einer leicht verzögerten Zeit relativ zur anfänglichen Übertragung des Befehls durch die Clienteinrichtung 108 korrespondieren.
Der Prozess bewirkt auch, dass die Clienteinrichtung 108 eine zweite Menge von Testpaketen zu derselben Zeit oder ungefähr zu derselben Zeit erzeugt, zu der der Server 132 seine Testpakete erzeugt hat (Schritt 912). In einigen Ausführungsformen kann die Clienteinrichtung 108 mit dem Erzeugen ihrer Menge von Testpaketen unmittelbar nach der Übertragung des Initiierungsbefehls an den Server 132 beginnen. In einigen Ausführungsformen kann die Clienteinrichtung 108 so lange warten, bis der Empfang des Befehls durch den Server 132 bestätigt wird (oder indem sie so lange wartet, bis an der Clienteinrichtung 108 eine Empfangsantwort empfangen wird). In einigen Ausführungsformen kann die Clienteinrichtung 108 eine zuvor ermittelte Zeit lang entweder nach der Übertragung des Initiierungsbefehls oder nach dem Empfang einer Antwort vom Server 132 warten. Mit anderen Worten, es ist vorteilhaft, wenn die Clienteinrichtung 108 und der Server 132 hinsichtlich der Erzeugung und der zum Schluss erfolgenden Übertragung ihrer jeweiligen Testpakete halbwegs synchronisiert sind. Es muss jedoch nicht an einer absoluten Synchronisierung festgehalten werden. Eine Toleranz von Sekunden, mehreren Zehn-Sekunden-Intervallen oder sogar Hunderten von Sekunden zwischen der Erzeugung und der Übertragung durch die Clienteinrichtung 108 und den Server 132 ist tolerierbar. Es ist allerdings allgemein nicht wünschenswert, wenn eine Komponente (z. B. die Clienteinrichtung 108) ihre Testpakete zu einer bestimmten Zeit erzeugt und sendet und die andere Komponente (z. B. der Server 132) ihre Testpakete dann zu einer im Wesentlichen späteren Zeit erzeugt und sendet, denn es ist vorteilhaft, die Beschaffenheit des Problems sowohl von der Clienteinrichtung 108 als auch vom Server 132 ungefähr zur selben Zeit zu ermitteln, damit das Problem aufgrund der instabilen Beschaffenheit derartiger Netzprobleme nicht verschwinden oder sich verändern kann.
In einigen Ausführungsformen ist der Server 132 konfiguriert, um mindestens einen Typ eines Testpakets, das nicht durch die Clienteinrichtung 108 gesendet wird, zu senden, oder umgekehrt. Mit anderen Worten, die Typen der Pakete, die in der ersten Menge von Paketen beinhaltet sind, sollten mit den Typen der Pakete, die in der zweiten Menge von Paketen beinhaltet sind, nicht vollumfänglich übereinstimmen. Mithin kann der Server 132 einen oder mehrere Ports 316a-N testen, die nicht zwangsläufig durch die Clienteinrichtung 108 getestet werden, oder umgekehrt. Dies ist auch repräsentativer für das eigentliche Verhalten eines Kommunikationssystems 100, insofern als die Clienteinrichtung 108 gewöhnlich einige Pakete sendet, die der Server 132 nicht sendet (z. B. Pakete für die Tonwahlsignalisierung), oder umgekehrt (z. B. RFC-2833-Pakete). Es ist nützlich, wenn die Typen der Pakete, die normalerweise durch jede Komponente während der Vorgänge gesendet werden, erzeugt und gesendet werden.
Der Prozess wird fortgesetzt, indem sowohl die Clienteinrichtung 108 als auch der Server 132 ihre jeweiligen Testpakete aneinander senden (Schritt 916). Wiederum wird bevorzugt, dass die Übertragung der Testpakete ungefähr (wenn auch nicht zwangsläufig genau) zur selben Zeit erfolgt.
Die jeweiligen Geräte warten dann auf Antworten auf ihre Testpakete (Schritt 920). Falls die Wartezeit noch ablaufen muss, warten die Geräte noch weiter (Schritt 924). Nachdem eine zuvor ermittelte Wartezeit abgelaufen oder irgendein anderes Ereignis eingetreten ist, wird der Prozess fortgesetzt, indem jedes Gerät identifiziert, ob Antworten auf seine Testpakete empfangen worden sind (Schritt 928). Die potenziellen Problemquellen (z. B. die problematischen Ports 316a-N) lassen sich basierend auf den an beiden Seiten des Systems erhaltenen Informationen durch die Diagnosetools 120, 144 identifizieren (Schritt 932).
In der vorangehenden Beschreibung wurden Verfahren zu Zwecken der Veranschaulichung in einer bestimmten Reihenfolge beschrieben. Es versteht sich, dass die Verfahren in alternativen Ausführungsformen auch in einer anderen als der beschriebenen Reihenfolge durchgeführt werden können. Es versteht sich auch, dass die oben beschriebenen Verfahren durch Hardware-Komponenten durchgeführt werden oder in Abfolgen maschinenausführbarer Befehle ausgebildet sein können, die sich nutzen lassen, um eine Maschine wie einen Mehrzweck- oder einen Spezialprozessor (GPU oder CPU) oder mit den Befehlen programmierte Logikschaltungen (FPGA) zum Durchführen der Verfahren zu veranlassen. Diese maschinenausführbaren Befehle können auf einem oder mehreren maschinenlesbaren Medien gespeichert sein, etwa CD-ROMs oder anderen Typen von Bildplatten, Disketten, ROMs, RAMs, EPROMs, EEPROMs, magnetischen oder optischen Karten, Flash-Speichern oder maschinenlesbaren Medien von einem anderen Typ, die zum Speichern elektronischer Befehle geeignet sind. Alternativ sind die Verfahren durch eine Kombination von Hard- und Software durchführbar.
In der Beschreibung wurden spezifische Details angeführt, um ein eingehendes Verständnis der Ausführungsformen zu ermöglichen. Es versteht sich jedoch für die Durchschnittsfachperson, dass sich die Ausführungsformen auch ohne diese spezifischen Details praktisch umsetzen lassen. Zum Beispiel werden Schaltungen möglicherweise in Blockdiagrammen gezeigt, um die Verständlichkeit der Ausführungsformen nicht durch unnötige Details zu erschweren. In anderen Fällen werden bekannte Schaltungen, Prozesse, Algorithmen, Strukturen und Techniken möglicherweise ohne unnötige Details gezeigt, um die Verständlichkeit der Ausführungsformen nicht zu erschweren.
Es sei auch angemerkt, dass die Ausführungsformen als Prozess beschrieben wurden, der als Ablaufschema, Flussdiagramm, Datenflussdiagramm, Strukturdiagramm oder Blockdiagramm abgebildet ist. Selbst wenn ein Ablaufschema die Vorgänge möglicherweise als sequenziellen Prozess beschreibt, können viele der Vorgänge auch parallel oder gleichzeitig durchgeführt werden. Des Weiteren kann die Reihenfolge der Vorgänge auch verändert werden. Ein Prozess ist beendet, wenn dessen Vorgänge abgeschlossen sind, könnte allerdings auch zusätzliche Schritte aufweisen, die in der Figur nicht beinhaltet sind. Ein Prozess kann mit einer Methode, einer Funktion, einer Prozedur, einer Unterroutine, einem Unterprogramm etc. korrespondieren. Wenn ein Prozess mit einer Funktion korrespondiert, korrespondiert seine Beendigung mit einer Rückkehr der Funktion zur aufrufenden Funktion oder zur Hauptfunktion.
Überdies können Ausführungsformen durch Hardware, Software, Firmware, Middleware, Mikrocode, Hardware-Beschreibungssprachen oder eine beliebige Kombination davon implementiert werden. Bei einer Implementierung in Software, Firmware, Middleware oder Mikrocode können der Programmcode oder die Programmcodesegmente zur Durchführung der nötigen Aufgaben in einem maschinenlesbaren Medium wie einem Speichermedium gespeichert sein. Ein Prozessor/Prozessoren kann/können die nötigen Aufgaben durchführen. Ein Codesegment kann eine Prozedur, eine Funktion, ein Unterprogramm, ein Programm, eine Routine, eine Unterroutine, ein Modul, ein Softwarepaket, eine Klasse oder eine beliebige Kombination von Befehlen, Datenstrukturen oder Programmanweisungen darstellen. Ein Codesegment kann durch eine Weitergabe und/oder das Empfangen von Informationen, Daten, Argumenten, Parametern oder Speicherinhalten an ein anderes Codesegment oder eine Hardware-Schaltung gekoppelt sein. Informationen, Argumente, Parameter, Daten etc. können über beliebige geeignete Mittel, einschließlich gemeinsamer Speicherbenutzung, Nachrichtenweitergabe, Tokenweitergabe, Netzübertragung etc., weitergegeben, weitergeleitet oder übertragen werden.
Auch wenn Ausführungsbeispiele der Offenbarung hierin detailliert beschrieben wurden, versteht es sich, dass die Erfindungsgedanken ansonsten auch anders ausgeführt und gebraucht werden können und dass die beigefügten Ansprüche so auszulegen sind, dass sie solche Varianten ebenfalls beinhalten, sofern sie vom Stand der Technik nicht beschränkt werden.

Claims

Kommunikationssystem, das Folgendes umfasst: mindestens einen Server, der Folgendes umfasst: eine Netzschnittstelle, die einen oder mehrere Ports beinhaltet, die Kommunikationen zwischen dem mindestens einen Server und einem Kommunikationsnetz ermöglichen; einen Prozessor; und einen Speicherbaustein, der eine oder mehrere Kommunikationsanwendungen umfasst, die durch den Prozessor ausführbar sind und den einen oder die mehreren Ports zum Kommunizieren mit einer Clienteinrichtung in Verbindung mit dem Ausführen der einen oder der mehreren Kommunikationsanwendungen einsetzen, wobei der Speicherbaustein weiter ein Diagnosetool umfasst, das auch durch den Prozessor ausführbar ist, wobei das Diagnosetool, wenn es durch den Prozessor ausgeführt wird, einen Diagnoseprozess als Antwort auf eine Anforderung von einer Clienteinrichtung durchführt, wobei der Diagnoseprozess Folgendes beinhaltet: Identifizieren einer ersten Kommunikationsanwendung von der einen oder den mehreren Kommunikationsanwendungen, um sie dem Diagnoseprozess zu unterziehen; Identifizieren einer ersten Menge von Testpaketen zum Übertragen vom Server an die Clienteinrichtung, wobei Testpakete in der ersten Menge von Testpaketen mit Paketen korrespondieren, die durch den Server an die Clienteinrichtung während der normalen Ausführung der ersten Kommunikationsanwendung übertragen werden; Ermitteln eines Ports von dem einen oder den mehreren Ports, der mit jedem Testpaket in der ersten Menge von Testpaketen assoziiert ist; Übertragen jedes Testpakets von der ersten Menge von Testpaketen zur Clienteinrichtung; Warten auf ein oder mehrere Testpakete von einer zweiten Menge von Testpaketen, die am Server von der Clienteinrichtung erwartet werden, wobei Testpakete in der zweiten Menge von Testpaketen mit Paketen korrespondieren, die durch die Clienteinrichtung an den Server während der normalen Ausführung der ersten Kommunikationsanwendung übertragen werden, und wobei die erste und die zweite Menge von Testpaketen sich nicht decken; und Erzeugen eines Berichts für die erste Kommunikationsanwendung basierend darauf, ob das eine oder die mehreren Pakete von der zweiten Menge von Testpaketen am Server empfangen werden oder nicht.
Kommunikationssystem nach Anspruch 1, wobei der Diagnoseprozess weiter Folgendes beinhaltet: Ermitteln, dass mindestens ein Paket von der zweiten Menge von Testpaketen nicht am Server empfangen wird; als Antwort auf das Ermitteln, dass das mindestens eine Paket von der zweiten Menge von Testpaketen nicht empfangen wird, Ermitteln, dass ein Port, der dem fehlenden, mindestens einem Paket zugewiesenen ist, mit einer potenziellen Quelle des Kommunikationsproblems zwischen dem Client und dem Server korrespondiert; und Erzeugen eines Diagnoseberichts, der den Port als potenzielle Quelle des Kommunikationsproblems zwischen dem Client und dem Server identifiziert.
Kommunikationssystem nach Anspruch 2, wobei das Diagnosetool automatisch versucht, eine Kommunikationssitzung zwischen einem Benutzer der Clienteinrichtung und der Entität herzustellen, und wobei der Diagnoseprozess weiter Folgendes beinhaltet: Zuordnen des Servers zu einer für die Verwaltung oder die Steuerung des Servers verantwortlichen Entität; Ermitteln von Kontaktinformationen für die Entität; und Aufnehmen der Kontaktinformationen in den Diagnosebericht.
Kommunikationssystem nach Anspruch 1, wobei der Speicherbaustein eine Testpakettabelle beinhaltet, die das Diagnosetool mit Informationen über die erste Menge von Paketen und die zweite Menge von Paketen ausstattet.
Kommunikationssystem nach Anspruch 1, wobei der Diagnoseprozess weiter Folgendes beinhaltet: Ermitteln, dass keine Antworten auf Testpakete, die durch den Server an die Clienteinrichtung übertragen wurden, am Server empfangen werden; und Ermitteln, dass eine Firewall zwischen dem Server und dem Client mit einer potenziellen Quelle des Kommunikationsproblems zwischen dem Client und dem Server korrespondiert.
Kommunikationssystem nach Anspruch 1, wobei der Diagnoseprozess weiter Folgendes beinhaltet: Analysieren mindestens einer mit der ersten Kommunikationsanwendung assoziierten Lizenz; Ermitteln, basierend auf der Analyse der mindestens einen Lizenz, ob die erste Kommunikationsanwendung für die Nutzung mit dem Client lizenziert ist; und Aufnehmen von Informationen in Bezug auf die mindestens eine Lizenz in den Diagnosebericht.
Kommunikationssystem, das Folgendes umfasst: eine Clienteinrichtung, die Folgendes umfasst: eine Netzschnittstelle, die Kommunikationen zwischen der Clienteinrichtung und einem Kommunikationsnetz ermöglicht; einen Prozessor; und einen Speicherbaustein, der eine Kommunikationsanwendung umfasst, wobei die Kommunikationsanwendung durch den Prozessor ausführbar ist und die Netzschnittstelle zum Kommunizieren mit einem Server in Verbindung mit dem Ausführen der Kommunikationsanwendung einsetzt, wobei der Speicherbaustein weiter ein Diagnosetool umfasst, das auch durch den Prozessor ausführbar ist, wobei das Diagnosetool, wenn es durch den Prozessor ausgeführt wird, einen Befehl zum Beginnen mit einem serverseitigen Diagnoseprozess an den Server überträgt, und wobei das Diagnosetool, wenn es durch den Prozessor ausgeführt wird, einen clientseitigen Diagnoseprozess durchführt, der Folgendes beinhaltet: Identifizieren einer ersten Menge von Testpaketen zum Übertragen von der Clienteinrichtung an den Server, wobei Testpakete in der ersten Menge von Testpaketen mit Paketen korrespondieren, die durch die Clienteinrichtung an den Server während der normalen Ausführung der Kommunikationsanwendung übertragen werden; Übertragen jedes Testpakets von der ersten Menge von Testpaketen zum Server; Warten auf ein oder mehrere Testpakete von einer zweiten Menge von Testpaketen, die an der Clienteinrichtung vom Server erwartet werden, wobei Testpakete in der zweiten Menge von Testpaketen mit Paketen korrespondieren, die durch den Server an die Clienteinrichtung während der normalen Ausführung der Kommunikationsanwendung übertragen werden, und wobei die erste und die zweite Menge von Testpaketen mindestens einen voneinander abweichenden Typ eines Testpakets umfassen; Empfangen von Informationen in Bezug darauf, ob jedes Paket in der ersten Menge von Testpaketen durch den Server empfangen wurde oder nicht; und Erzeugen eines Berichts für die Kommunikationsanwendung basierend darauf, ob jedes Paket in der zweiten Menge von Testpaketen an der Clienteinrichtung empfangen wird, und weiter basierend darauf, ob jedes Paket in der ersten Menge von Testpaketen am Server empfangen wird.
System nach Anspruch 7, wobei die erste und die zweite Menge von Testpaketen zu einer selben Zeit oder ungefähr zu einer selben Zeit übertragen werden und wobei die durch den Server zur Clienteinrichtung übertragenen Testpakete über einen zuvor ermittelten Port des Servers basierend auf einer dem zuvor ermittelten Port zugewiesenen Funktion übertragen werden, wobei das Diagnosetool weiter konfiguriert ist, um zu ermitteln, dass der an den Server übertragene Befehl zum Beginnen mit dem serverseitigen Diagnoseprozess nicht durch den Server empfangen wurde, und als Antwort darauf einen zweiten Befehl an den Server zu übertragen, wobei der zweite Befehl über ein alternatives Netz an den Server übertragen wird, wobei der Befehl zum Initiieren des serverseitigen Diagnoseprozesses als Antwort darauf übertragen wird, dass die Clienteinrichtung eine Benutzereingabe empfängt, die Probleme mit einer Kommunikationssitzung zwischen der Clienteinrichtung und dem Server meldet.
System nach Anspruch 7, wobei der Bericht Informationen beinhaltet, die basierend auf dem clientseitigen Diagnoseprozess und dem serverseitigen Diagnoseprozess erhalten wurden, und wobei der clientseitige Diagnoseprozess weiter Folgendes umfasst: Ermitteln, dass die Firewall mit einer potenziellen Quelle eines Kommunikationsproblems zwischen der Clienteinrichtung und dem Server korrespondiert; Zuordnen der Firewall zu einer für die Verwaltung oder die Steuerung der Firewall verantwortlichen Entität; Ermitteln von Kontaktinformationen für die Entität; und Aufnehmen der Kontaktinformationen in den Bericht; Aufnehmen von Informationen in Bezug auf die mindestens eine Lizenz in den Bericht.
Diagnosesystem, das Folgendes umfasst: ein clientseitiges Diagnosetool, das konfiguriert ist, um einen clientseitigen Diagnoseprozess auszuführen, der Folgendes beinhaltet: Identifizieren einer Kommunikationsanwendung von einer oder mehreren Kommunikationsanwendungen, um sie einem Diagnoseprozess zu unterziehen; Identifizieren einer ersten Menge von Testpaketen zum Übertragen von einer Clienteinrichtung an einen Server, wobei Testpakete in der ersten Menge von Testpaketen mit Paketen korrespondieren, die durch die Clienteinrichtung an den Server während der normalen Ausführung der Kommunikationsanwendung übertragen werden; Übertragen jedes Testpakets von der ersten Menge von Testpaketen zum Server; Warten auf ein oder mehrere Testpakete von einer zweiten Menge von Testpaketen, die an der Clienteinrichtung vom Server erwartet werden, wobei Testpakete in der zweiten Menge von Testpaketen mit Paketen korrespondieren, die durch den Server an die Clienteinrichtung während der normalen Ausführung der Kommunikationsanwendung übertragen werden, und wobei die erste und die zweite Menge von Testpaketen mindestens einen voneinander abweichenden Typ eines Testpakets umfassen; Empfangen von Informationen in Bezug darauf, ob jedes Paket in der ersten Menge von Testpaketen durch den Server empfangen wurde oder nicht; und Erzeugen eines clientseitigen Berichts für die Kommunikationsanwendung basierend darauf, ob jedes Paket in der zweiten Menge von Testpaketen an der Clienteinrichtung empfangen wird, und weiter basierend darauf, ob jedes Paket in der ersten Menge von Testpaketen am Server empfangen wird; und ein serverseitiges Diagnosetool, das konfiguriert ist, um einen serverseitigen Diagnoseprozess auszuführen, der Folgendes beinhaltet: Identifizieren der zweiten Menge von Testpaketen basierend auf einer Meldung der Kommunikationsanwendung; Ermitteln eines Ports von dem einen oder den mehreren Ports, der mit jedem Testpaket in der zweiten Menge von Testpaketen assoziiert ist; Übertragen jedes Testpakets von der zweiten Menge von Testpaketen zur Clienteinrichtung; Warten auf ein oder mehrere Testpakete von der ersten Menge von Testpaketen, die am Server von der Clienteinrichtung erwartet werden; und Erzeugen eines serverseitigen Berichts für die Kommunikationsanwendung basierend darauf, ob das eine oder die mehreren Pakete von der ersten Menge von Testpaketen am Server empfangen werden oder nicht.