DE60116341T3 - Kommunikationsverwaltungsystem für computernetzbasierte telefone - Google Patents

Kommunikationsverwaltungsystem für computernetzbasierte telefone Download PDF

Info

Publication number
DE60116341T3
DE60116341T3 DE60116341.9T DE60116341T DE60116341T3 DE 60116341 T3 DE60116341 T3 DE 60116341T3 DE 60116341 T DE60116341 T DE 60116341T DE 60116341 T3 DE60116341 T3 DE 60116341T3
Authority
DE
Germany
Prior art keywords
data packets
unit
data
packets
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60116341.9T
Other languages
English (en)
Other versions
DE60116341T2 (de
DE60116341D1 (de
Inventor
Mordechai Nisani
Danny Shporer
Ilan Yosef
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nice Systems Ltd
Original Assignee
Nice Systems Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=24667311&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE60116341(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Nice Systems Ltd filed Critical Nice Systems Ltd
Application granted granted Critical
Publication of DE60116341D1 publication Critical patent/DE60116341D1/de
Publication of DE60116341T2 publication Critical patent/DE60116341T2/de
Publication of DE60116341T3 publication Critical patent/DE60116341T3/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/42221Conversation recording systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1106Call signalling protocols; H.323 and related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Description

  • GEBIET UND HINTERGRUND
  • Die vorliegende Erfindung betrifft ein Verfahren und ein System zur Verwaltung von Kommunikationsverbindungen zur Telefonkommunikation über ein Computernetzwerk, und insbesondere zur Identifikation von Paketen, die Audio- und/oder Videodaten enthalten, zur Speicherung dieser Pakete, und zur Rekonstruktion ausgewählter Kommunikationsverbindungen für Audio- und/oder Videodarstellung, nach Bedarf.
  • Die Integration des Computers in Bürokommunikationssysteme hat das Kombinieren vieler zuvor von separaten Geräten durchgeführter Funktionen zu einem einzigen, durch einen Computer bedienten Verwaltungssystem ermöglicht. Beispielsweise ermöglichen computerbasierte Sprachloggingsysteme es einem Computer, Sprachkommunikation durch eine Hardwareverbindung mit dem normalen Telefonnetzwerk zu empfangen, entweder eine Unterhaltung, worin zumindest zwei Teilnehmer sich unterhalten, oder eine Mitteilung von zumindest einem Teilnehmer an einen oder mehrere Teilnehmer aufzuzeichnen und diese aufgenommenem Unterhaltungen oder Mitteilungen auf Anfrage abzuspielen. Diese Sprachloggingsysteme können mechanische Telefonanrufbeantworter ersetzen.
  • Die Computerloggingsysteme haben viele Vorteile gegenüber den mechanischen Anrufbeantwortern. Beispielsweise können die Sprachmitteilungen in einem computerbasierten Speichermedium, wie etwa einer DAT-Kassette, gespeichert werden, das eine größere Speicherkapazität als normale Audiokassetten hat. Weiterhin können die gespeicherten Sprachmitteilungen in einer Datenbank organisiert werden, sodass die Mitteilungen beispielsweise gemäß Zeit, Datum, Kanal, gewählter Nummer oder Anruferidentifikation abgerufen werden können. Eine solche Organisation ist bei einem mechanischen Telefonanrufbeantworter nicht möglich. Somit haben Computerloggingsysteme für Sprachmitteilungen viele Vorteile gegenüber mechanischen Anrufbeantwortern.
  • Leider haben derzeit verfügbare Computerloggingsysteme den Nachteil, nicht in der Lage zu sein, Telefonkommunikationsverbindungen, ob dies nun Unterhaltungen oder Mitteilungen sind, für durch ein LAN (lokales Netzwerk) oder ein WAN (Weitbereichsnetzwerk) durchgeführte Sprachkommunikation aufzuzeichnen. Obwohl diese Loggingsysteme beispielsweise Sprachmitteilungen für einen Fernbenutzer durch ein LAN abspielen können, können sie eine solche Mitteilung nicht aufnehmen, wenn sie von einem LAN-basierten Telefon übertragen wird. Solche LAN und WAN-basierte Telefonkommunikation ist in der letzten Zeit populärer geworden, da sie die Durchführung von Telefonkommunikation zwischen verschiedenen Teilnehmern an physisch getrennten Orten ohne Bezahlen für örtliche normale Telefonnetzwerkdienste gestattet, wodurch Geld gespart wird.
  • Weiterhin erleichtert LAN- und WAN-basierte Telefonkommunikation auch die Übertragung von Video- sowie Audioinformation. Videoinformation kann sicherlich nicht durch derzeit verfügbare Computerloggingsysteme aufgezeichnet werden. Somit ist die Unfähigkeit von Computerloggingsystemen, Telefonkommunikationsverbindungen für durch ein LAN oder ein WAN durchgeführte Telefonkommunikation, sowohl Video- als auch Audiodaten, aufzuzeichnen, ein signifikanter Nachteil dieser Systeme.
  • Es besteht daher ein Bedarf an einem System und einem Verfahren, und es wäre höchst vorteilhaft, diese zu haben, zum Aufzeichnen von über ein Computernetzwerk, wie etwa ein LAN oder ein WAN, durchgeführten Telefonkommunikationsverbindungen, welche sowohl Audio- als auch Videoinformation aufzeichnen, solche Information organisieren und dann solche Information auf Anfrage darstellen würde.
  • Die Schalttechnikindustrie bewegt sich zur IP-Welt hin. Diese Bewegung hat eine große Auswirkung auf die Telekommunikationsindustrie. Es ist noch zu früh, um die gesamte Auswirkung dieser Bewegung zu verstehen.
  • Die IP-Multimedieninitiative erhielt ihren Impuls, als die International Telecommunications Union die H.323-Norm veröffentlichte, welche die Kompatibilität zwischen Schaltprodukten von verschiedenen Anbietern sicherstellte. Die H.323-Norm verschafft eine Grundlage für Audio-, Video- und Datenkommunikation über IP-basierte Netzwerke einschließlich des Internets.
  • Die meisten der Haupt-Schalttechnikanbieter, wie etwa Lucent, Siemens, Nortel und Alcatel haben beschlossen, IP in ihre derzeitigen Schaltplattformen zu integrieren. Diese Anbieter werden sehr bald dem Markt neue, auf IP-Technologie basierte Schaltplattformen vorlegen.
  • Alle derzeitigen Aufzeichnungslösungen sind auf der Tatsache basiert, dass ein PBX oder ein zentrales Büro ein zentrales Koppelfeld nutzt, wobei alle Anrufe über dieses zentrale Feld geleitet werden. Integration mit diesem Feld stellt sicher, dass alle von dem PBX oder zentralen Büro geleiteten Anrufe von einem digitalen Aufzeichnungssystem aufgezeichnet werden könnten, das eine Verbindung zu dem Koppelfeld hat. Dies ist jedoch nicht auf einer Linie mit dem IP-Milieu, das inhärent dezentralisiert ist.
  • Es besteht daher ein Bedarf an einem System und einem Verfahren, und es wäre höchst vorteilhaft, diese zu haben, zum Aufzeichnen von über ein Computernetzwerk, wie etwa ein LAN oder ein WAN, durchgeführten Telefonkommunikationsverbindungen, die von einem zentralen Koppelfeld unabhängig wären.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es ist ein Gegenstand der vorliegenden Erfindung, ein System und ein Verfahren zum Aufzeichnen von über ein Computernetzwerk durchgeführten Telefonkommunikationsverbindungen zu verschaffen.
  • Es ist ein anderer Gegenstand der vorliegenden Erfindung, ein solches System und Verfahren zum Analysieren von über das Computernetzwerk übertragenen Daten zu verschaffen, um Audio- und Videodaten zwecks Aufzeichnung zu erfassen.
  • Es ist noch ein anderer Gegenstand der vorliegenden Erfindung, ein solches System und Verfahren zum auf Anfrage Darstellen von aufgezeichneten Video- und Audiodaten zu verschaffen.
  • Es ist wiederum ein anderer Gegenstand der vorliegenden Erfindung, ein solches System zum Analysieren, Aufzeichnen und Darstellen von mit einem LAN-basierten Telefonsystem geführten Kommunikationsverbindungen zu verschaffen.
  • Diese und andere Gegenstände der vorliegenden Erfindung werden detaillierter in Hinsicht auf die nachstehend vorgesehenen Zeichnungen, Beschreibung und Ansprüche erläutert.
  • Die vorliegende Erfindung verschafft ein System und ein Verfahren zum Analysieren von Datenpaketen auf einem Computernetzwerk, zum selektiven Aufzeichnen von Audio- und Videodatenpaketen, zum Organisieren dieser gespeicherten Information und zum auf Anfrage Darstellen der gespeicherten Information, sodass Kommunikationsverbindungen mit computernetzwerkbasierten ”Telefon”-Systemen protokolliert werden können.
  • Gemäß den Lehren der vorliegenden Erfindung wird ein System zur Verwaltung einer Kommunikationsverbindung über ein Computernetzwerk, das einen Gatekeeper umfasst, verschafft, wobei das System folgendes umfasst: (a) ein Netzwerkverbindungselement zum Anschließen an das Computernetzwerk und zum Empfangen von Datenpaketen von dem Computernetzwerk; (b) eine Filtereinheit zum Filtern der Datenpakete und zum Akzeptieren der Datenpakete nur dann, wenn die Datenpakete Daten enthalten, die aus der aus Audiodaten und Videodaten bestehenden Gruppe gewählt sind, sodass die Datenpakete zumindest einen Teil der Kommunikationsverbindung bilden und sodass die Datenpakete ausgewählte Datenpakete sind; (c) eine Verwaltungseinheit zum Empfangen der ausgewählten Datenpakete und zum Speichern der ausgewählten Datenpakete, sodass die ausgewählten Datenpakete gespeicherte Datenpakete sind; (d) ein Speichermedium zum Empfangen und zum Speichern der gespeicherten Datenpakete von der Verwaltungseinheit, sodass der zumindest eine Teil der Kommunikationsverbindung gespeichert wird; und (e) ein Verbindungsglied zwischen dem Gatekeeper und der Verwaltungseinheit, zum Übertragen von die besagten Datenpakete betreffender Information von dem Gatekeeper zu der Verwaltungseinheit.
  • Vorzugsweise umfasst das System weiter (f) eine Datenwiederherstellungseinheit zum Wiedergewinnen und Anzeigen besagten zumindest einen Teils der Kommunikationsverbindung, wobei die Datenwiederherstellungseinheit die Datenpakete von dem Speichermedium durch die Verwaltungseinheit anfordert, und wobei die Datenwiederherstellungseinheit die Datenpakete rekonstruiert, um den zumindest einen Teil der Kommunikationsverbindung anzuzeigen.
  • Bevorzugter umfasst die Datenwiederherstellungseinheit weiter eine Kommunikationsverbindungs-Anzeigeeinheit zum Anzeigen des zumindest einen Teils der Kommunikationsverbindung. Meistbevorzugt ist die Kommunikationsverbindungs-Anzeigeeinheit aus der aus einer Videoeinheit und einer Audioeinheit bestehenden Gruppe gewählt.
  • Gemäß bevorzugten Ausführungen der vorliegenden Erfindung umfasst das System weiter (g) eine mit der Filtereinheit verbundene Datenbank zum Speichern von Filterinformation, wobei die Filterinformation zumindest eine IP-Adresse eines Teilnehmers enthält, dessen Kommunikationsverbindungen überwacht werden; wobei die Filtereinheit die Datenpakete gemäß der Filterinformation akzeptiert, sodass die Filtereinheit die Datenpakete im Wesentlichen nur akzeptiert, wenn die Datenpakete die Filterinformation erfüllen.
  • Vorzugsweise umfasst das System weiter (h) einen Benutzercomputer zum Empfangen zumindest eines Befehls eines Benutzers und dem Benutzer Anzeigen von Information, sodass der Benutzer die Filterinformation gemäß dem zumindest einen Befehl des Benutzers bestimmt.
  • Bevorzugter ist das Computernetzwerk aus der aus einem LAN (lokales Netzwerk) und einem WAN (Weitbereichsnetzwerk) bestehenden Gruppe gewählt. Meistbevorzugt ist das Computernetzwerk ein LAN (lokales Netzwerk).
  • Gemäß weiteren bevorzugten Ausführungen der vorliegenden Erfindung ist das LAN in zumindest zwei Segmente unterteilt, wobei das System weiterhin folgendes umfasst: (i) eine lokale Verwaltungseinheit für jedes Segment, wobei die lokale Verwaltungseinheit die Filtereinheit und die Verwaltungseinheit umfasst; und (j) eine zentrale Verwaltungseinheit zum Steuern der lokalen Verwaltungseinheiten, wobei die zentrale Verwaltungseinheit das Speichern in dem Speichermedium steuert.
  • Vorzugsweise ist das Netzwerkverbindungselement eine Netzwerkkarte.
  • Hierin nachstehend umfasst der Begriff ”Kommunikationsverbindung” sowohl eine Unterhaltung, wobei zumindest zwei Teilnehmer sich durch Austausch von Audio- und/oder Videoinformation in ”Echtzeit” unterhalten, als auch eine Mitteilung, wobei zumindest ein Teilnehmer solche Audio- und/oder Videoinformation zum Empfang durch zumindest einen anderen Teilnehmer zu einem späteren Zeitpunkt aufzeichnet.
  • Hierin nachstehend wird der Begriff ”Internet” zur allgemeinen Bezeichnung des globalen, vernetzten Verbunds von Tausenden von Netzwerken verwendet, das zur Verbindung von Computern in der ganzen Welt genutzt wird. Wie hierin verwendet, umfasst der Begriff ”Intranet” andere Typen von Computernetzwerken, wie etwa LAN (lokale Netzwerke) oder WAN (Weitbereichsnetzwerke). Der Begriff ”Computernetzwerk” umfasst jede Verbindung zwischen zumindest zwei Computern, welche die Übertragung von Daten gestattet, unter Einbeziehung von sowohl Internet als auch Intranet. Der Begriff ”normales Telefonnetzwerk” umfasst POTS (”Plain old telephone system” – einfaches altes Telefonsystem) und im Wesentlichen jeden anderen Typ von Telefonnetzwerk, das Dienste durch einen normalen Telefondiensteanbieter zur Verfügung stellt, was jedoch spezifisch durch jeden Typ von Computernetzwerk durchgeführte Audio- und/oder Videokommunikation ausschließt.
  • Hierin nachstehend umfasst der Begriff ”Computer”, ist jedoch nicht beschränkt auf, Personal Computer (PC) mit einem Betriebssystem wie etwa DOS, WindowsTM, OS/2TM oder Linux; MackintoshTM-Computer; Computer mit JAVATM-OS als Betriebssystem; und graphische Arbeitsstationen, wie etwa die Computer von Sun MicrosystemsTM und Silicon GraphicsTM, und andere Computer mit einer Version des UNIX-Betriebssystems, wie etwa AIX oder SOLARISTM von Sun Microsystems, oder jedes andere bekannte und verfügbare Betriebssystem. Hierin nachstehend umfasst der Begriff ”WindowsTM”, ist jedoch nicht beschränkt auf, Windows95TM, Windows 3.xPM, wobei das ”x” eine ganze Zahl wie etwa ”1” ist, Windows NTTM, Windows98TM, Windows CETM und jedwede aufgerüstete Versionen dieser Betriebssysteme von Microsoft Inc. (Seattle, Washington, USA).
  • Hierin nachstehend bezieht der Begriff ”Logging” sich auf den Prozess des Analysierens von Datenpaketen auf einem Netzwerk, um Audio- und/oder Videodaten zu lokalisieren, und auf das Aufzeichnen solcher Daten in einem organisierten System. Hierin nachstehend umfasst der Begriff ”Anzeige” sowohl die visuelle Darstellung von Videodaten, als auch die Produktion von Ton für Audiodaten.
  • Die PCT-Anmeldung WO 00/28425 lehrt ein Multimedien-Anrufzentrum, das einen Verwaltungsserver 77 umfasst. Ein Unterschied zwischen dem Multimedien-Callcenter von WO 00/28425 und dem System der vorliegenden Erfindung ist, dass der Verwaltungsserver 77 von WO 00/28425 selektiv alle Arten eintreffender Pakete, nicht nur Audiodatenpakete und Videodatenpakete, zwecks Speicherung zu einem Multimedienserver 79 weiterleitet. Ein anderer Unterschied zwischen dem Multimedien-Callcenter von WO 00/28425 und dem System der vorliegenden Erfindung ist, dass es dem Multimedien-Callcenter von WO 00/28425 an einem Verbindungsglied zwischen dem Verwaltungsserver 77 und einem Gatekeeper fehlt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird hierin nur als Beispiel beschrieben, unter Verweis auf die begleitenden Zeichnungen, worin:
  • 1 ein schematisches Blockdiagramm eines beispielhaften Kommunikationsverbindungs-Überwachungssystems gemäß der vorliegenden Erfindung ist;
  • 2 ein schematisches Blockdiagramm der zum Betreiben des Systems von 1 erforderlichen Softwaremodule ist; die
  • 3A3D Ablaufdiagramme beispielhafter Filter- und Aufzeichnungsverfahren gemäß der vorliegenden Erfindung sind; die
  • 4A4D schematische Blockdiagramme sind, die die Header von Paketen von H.225 (4A), H.245 (4B), RTP (4C) und RTCP (4D) zeigen, wie sie die vorliegende Erfindung betreffen;
  • 5 ein Ablaufdiagramm eines beispielhaften Kommunikationsverbindungs-Wiedergabeverfahrens gemäß der vorliegenden Erfindung ist;
  • 6 ein schematisches Blockdiagramm einer beispielhaften ersten Ausführung eines Basissystems ist, das das Kommunikationsverbindungs-Überwachungssystem der 1 und 2 gemäß der vorliegenden Erfindung anwendet; und
  • 7 ein schematisches Blockdiagramm einer beispielhaften zweiten Ausführung eines Zonensystems gemäß der vorliegenden Erfindung ist;
  • 8 ein schematisches Blockdiagramm eines beispielhaften passiven Aufzeichnungssystems gemäß einer anderen Ausführung der vorliegenden Erfindung ist.
  • BESCHREIBUNG DER ZUGRUNDELIEGENDEN TECHNIK
  • Die folgende Beschreibung ist dazu gedacht, eine Beschreibung gewisser zugrundliegender Verfahren und Technologien zu verschaffen, die gegebenenfalls in dem Verfahren und System der vorliegenden Erfindung verwendet werden. Die vorliegende Erfindung ist spezifisch nicht auf allein diese Verfahren und Technologien zugeschnitten. Vielmehr werden sie als Werkzeuge benutzt, um das Ziel der vorliegenden Erfindung zu erreichen, welches ein System und ein Verfahren zum Analysieren von Datenpaketen auf einem Computernetzwerk, zum selektiven Aufnehmen von Audio- und Videodatenpaketen, zum Organisieren dieser gespeicherten Information und zum auf Anfrage Anzeigen der gespeicherten Information ist, sodass Kommunikationsverbindungen mit computernetzwerkbasierten ”Telefon”-Systemen protokolliert werden können.
  • Das System und Verfahren der vorliegenden Erfindung ist insbesondere zum Betrieb mit Computernetzwerken gedacht, die gemäß der ITU-T-Empfehlung H.323 für visuelle Telefonsysteme und Ausrüstung für lokale Netzwerke, die eine nicht-garantierte Dienstqualität verschaffen, konstruiert sind. Die Empfehlung H.323 wird hierin als Referenz aufgenommen, um die Hardwareanforderungen und Betriebsprotokolle für solche Computernetzwerke weiter zu beschreiben, und wird hierin nachstehend als ”H.323” bezeichnet.
  • H.323 beschreibt Endgeräte, Ausrüstung und Dienste für Multimedienkommunikation über lokale Netzwerke (LAN), die keine garantierte Dienstqualität verschaffen. Computerterminals und Ausrüstung, die H.323 erfüllen, können Echtzeitsprache, Daten und Video, oder jede Kombination, einschließlich Videotelefonie, tragen.
  • Das LAN, über das solche Endgeräte kommunizieren, kann ein einzelnes Segment oder Ring sein, oder kann gegebenenfalls mehrfache Segmente mit komplexen Topologien umfassen. Diese Endgeräte sind gegebenenfalls in Computer integriert oder sind alternativ in unabhängigen Geräten, wie etwa Bildtelefonen, verwirklicht. Unterstützung für Sprachdaten ist erforderlich, während Unterstützung für allgemeine Daten und Videodaten optionsweise ist, wenn jedoch unterstützt, so ist die Fähigkeit zur Verwendung eines spezifizierten gemeinsamen Betriebsmodus erforderlich, sodass alle Endgeräte, die diesen bestimmten Medientyp unterstützen, kommunizieren können. Die H.323-Empfehlung gestattet, dass mehr als ein Kanal jedes Typs in Gebrauch ist. Andere Empfehlungen in der H.323-Serie, die ebenfalls als Referenz aufgenommen sind, umfassen das H.225.0 Paket und Synchronisation, H.245 Steuerung, H.261 und H.263 Video-Codecs, G.711, G.722, G.728, G.729 und G.723 Audio-Codecs, und die T.120-Serie von Multimedien-Kommunikationsprotokollen.
  • Die ITU-T-Empfehlung H.245.0 deckt die Definition von Medienstrompaketeinteilung und Synchronisation für visuelle Telefonsysteme ab. Die ITU-T-Empfehlung H.245.0 definiert das Steuerprotokoll für Multimedienkommunikationen und wird hierin nachstehend als ”H.245” bezeichnet. H.245 wird hierin als Referenz aufgenommen, wie es vollständig hier ausgeführt ist.
  • Die Logikkanal-Signalisierungsprozeduren von H.245 beschreiben den Inhalt jedes Logikkanals, wenn der Kanal geöffnet ist. Es werden Vorgehensweisen für die Kommunikation der funktionellen Leistungsfähigkeiten von Empfängern und Sendern vorgesehen, sodass Übertragungen auf Information beschränkt werden, die von den Empfängern dekodiert werden kann, und sodass Empfänger eine bestimmte gewünschte Betriebsart von Sendern anfragen können.
  • H.245-Signalisieren wird zwischen zwei Endpunkten erstellt: einem Endpunkt und einem Mehrpunktsteuergerät, oder einem Endpunkt und einem Gatekeeper. Der Endpunkt erstellt exakt einen H.245-Steuerkanal für jeden Anruf, worin der Endpunkt partizipiert. Der Kanal muss dann gemäß H.245 arbeiten. Unterstützung für Mehrfachanrufe und von daher für mehrfache H.245-Steuerkanäle ist möglich.
  • Die RAS-Signalisierfunktion verwendet H.225.0-Mitteilungen, um Registration, Zulassungen, Bandbreitenwechsel, Status- und Abkoppelprozeduren zwischen Endpunkten und Gatekeepern durchzuführen. In LAN-Umgebungen, die keinen Gatekeeper haben, wird der RAS-Signalisierkanal nicht verwendet. In LAN-Umgebungen, die einen Gatekeeper enthalten, sodass das LAN zumindest eine Zone umfasst, wird der RAS-Signalisierkanal zwischen dem Endpunkt und dem Gatekeeper geöffnet. Der RAS-Signalisierkanal wird vor dem Erstellen jedweder anderer Kanäle zwischen H.323-Endpunkten geöffnet.
  • Die Anrufsignalisierfunktion nutzt H.225.0-Anrufsignalisation zum Erstellen einer Verbindung zwischen zwei H.323-Endpunkten. Der Anrufsignalisierkanal ist unabhängig von dem RAS-Kanal und dem H.245-Steuerkanal. Der Anrufsignalisierkanal wird vor dem Erstellen des H.245-Kanals und jedweder anderer Logikkanäle zwischen H.323-Endpunkten geöffnet. In Systemen, die keinen Gatekeeper haben, wird der Anrufsignalisierkanal zwischen den zwei in den Anruf einbezogenen Endpunkten erstellt. In Systemen, die einen Gatekeeper enthalten, wird der Anrufsignalisierkanal zwischen dem Endpunkt und dem Gatekeeper, oder zwischen den Endpunkten selbst, wie vom Gatekeeper gewählt, geöffnet.
  • Den durch H.323 definierten verschiedenen Kanälen entsprechen entsprechende Protokolle, die kollektiv die H.323-Protokollsammlung bilden. Diese Protokolle umfassen die H.225- und H.245-Protokolle für Verbindungs-Setup und die RTP- und RTCP-Protokolle für den eigentlichen Datenaustausch.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGEN
  • Die vorliegende Erfindung verschafft ein System und ein Verfahren zum Analysieren von Datenpaketen auf einem Computernetzwerk, zum selektiven Aufzeichnen von Audio- und Videodatenpaketen, zum Organisieren dieser gespeicherten Information und zum auf Anfrage Darstellen der gespeicherten Information, sodass Kommunikationsverbindungen mit computernetzwerkbasierten ”Telefon”-Systemen protokolliert werden können.
  • Die Prinzipien und Arbeitsweise eines Verfahrens und eines Systems gemäß der vorliegenden Erfindung können unter Verweis auf die Zeichnungen und die begleitende Beschreibung besser verstanden werden.
  • Unter Bezugnahme auf die Zeichnungen ist 1 ein Blockdiagramm eines beispielhaften Systems zum Protokollieren und Darstellen von Audio- und/oder visuellen Daten von über ein Computernetzwerk durchgeführten Kommunikationsverbindungen. Ein Computerloggingsystem 10 weist einen Benutzercomputer 12 auf, der mit einer Kommunikationsverbindungs-Verwaltungseinheit 13 verbunden ist. Die Kommunikationsverbindungs-Verwaltungseinheit 13 ist ihrerseits durch eine Netzwerkkarte (NIC) 16 an ein Intranet 14 angeschlossen.
  • Der Benutzercomputer 12 umfasst eine Benutzeroberfläche 18, die vorzugsweise eine GUI (grafische Benutzeroberfläche) ist, die auf einer Displayeinheit 20 angezeigt wird. Die Benutzeroberfläche 18 ermöglicht es dem Benutzer vorzugsweise, solche Information wie etwa die Definition der Teilnehmer, deren Anrufe überwacht und/oder protokolliert werden sollten, einzugeben, und sie versetzt den Benutzer auch vorzugsweise in die Lage, zumindest einen Befehl zum Auffinden und Anzeigen einer Kommunikationsverbindung einzugeben.
  • Die Displayeinheit 20 ist vorzugsweise ein Computerbildschirm. Der Benutzer ist in der Lage, durch Eingeben von Daten und Befehlen durch eine Dateneingabevorrichtung 22 in Wechselwirkung mit dem Benutzercomputer 12 zu treten. Die Dateneingabevorrichtung 22 umfasst vorzugsweise zumindest eine Tastatur oder eine Zeigevorrichtung, wie etwa eine Maus, und umfasst bevorzugter sowohl eine Tastatur als auch eine Zeigevorrichtung. Gemäß einer bevorzugten Ausführung der vorliegenden Erfindung ist der Benutzercomputer 12 ein PC (Personal Computer). Alternativ und bevorzugt ist der Benutzercomputer 12 ein ”Thin Client”, d. h. ein Netzcomputer, der ein Computer ist, der fähig ist, auf einem IP-basierten Netzwerk zu kommunizieren. Ein Beispiel für einen solchen Netzcomputer ist die JavaStationTM (Sun Microsystems). Der Vorteil solcher Netzcomputer ist, dass sie es dem Benutzer gestatten, mit komplexen, ausgeklügelten Softwareprogrammen in eine Wechselwirkung zu treten, generell jedoch nicht alle kräftigen Rechnerfähigkeiten derzeit erhältlicher PC-Computer haben.
  • Das Intranet 14 könnte beispielsweise ein LAN oder ein WAN sein. Die Verbindung zwischen der Kommunikationsverbindungs-Verwaltungseinheit 13 und dem Intranet 14 findet durch die NIC 16 statt. Die NIC 16 ist vorzugsweise jedes standardgemäße, serienmäßig hergestellte kommerzielle Produkt, das die Kommunikationsverbindungs-Verwaltungseinheit 13 in die Lage versetzt, an ein beliebiges geeignetes Computernetzwerk angeschlossen zu werden (beispielsweise Etherlink II ISA/PCMCIA Adapter oder Etherlink III PCI Bus-Master Adapter (3c590) von 3-ComTM, oder NE2000 Adapter von NovellTM oder jedes andere geeignete Produkt). Beispiele für solche geeigneten Computernetzwerke umfassen, sind jedoch nicht beschränkt auf, jedes Standard-LAN, wie etwa Ethernet (IEEE-Norm 802.3), Fast Ethernet (IEEE-Norm 802.10), Token Ring (IEEE-Norm 802.5) und FDDI.
  • Der gesamte Datenpaketverkehr auf Intranet 14 wird durch die NIC 16 zu einem Filtermodul 24 geleitet. Wie detaillierter nachstehend in 3 gezeigt, überprüft das Filtermodul 24 die Datenpakete, um zu ermitteln, welche Datenpakete die folgenden Kriterien erfüllen. Kurzgesagt, die Datenpakete sollten IP-Pakete mit Headern gemäß den H.225- und H.245-Normen sein, welche Sprach- und/oder Videoverkehr andeuten. Wie zuvor angemerkt, definieren diese Normen Medienstrompaketkonstruktion und -synchronisation für visuelle Telefonsysteme und das Steuerprotokoll für Multimedienkommunikationen.
  • Das Filtermodul 24 leitet dann vorzugsweise nur diejenigen Datenpakete, die diesen Kriterien entsprechen, an ein Verwaltungsmodul 28 weiter. In der Zonenkonfiguration des Systems der vorliegenden Erfindung, nachstehend in 7 gezeigt, befördert das Filtermodul 24 vorzugsweise auch Mitteilungen von anderen Kommunikationsverbindungs-Verwaltungseinheiten.
  • Das Verwaltungsmodul 28 empfängt die von dem Filtermodul 24 weitergeleiteten Datenpakete und analysiert die empfangenen Datenpakete. Optionsweise und vorzugsweise speichert eine Datenbank 26 solche Information, wie etwa die IP-Adressen von Teilnehmern, deren Kommunikationsverbindungen protokolliert werden sollten, sowie die Umwandlungstabelle, die jedem Teilnehmer beispielsweise zumindest eine IP-Adresse zuordnet. Die gespeicherte Liste von IP-Adressen, die diejenigen Teilnehmer darstellt, deren Anrufe protokolliert werden sollten, ist vorzugsweise benutzerdefiniert. Wie hierin verwendet, bezieht der Begriff ”Teilnehmer” sich auf eine Person oder Personen, die durch ein computernetzwerkbasiertes Telefonsystem kommunizieren. Die letztere bevorzugte Anforderung verringert die Datenmenge beträchtlich, indem sie nur Daten einschließt, die für den Benutzer von Interesse sind. Das Verwaltungsmodul 28 analysiert und verwaltet Daten in Übereinstimmung mit den anwendbaren Spezifikationen H.225 und H.245, einschließlich der H.245-Kontrollfunktion, RAS-Signalisierungsfunktion und Anrufsignalisierungsfunktion, im Wesentlichen wie oben im Abschnitt ”Beschreibung der zugrundeliegenden Technik” beschrieben.
  • Das Verwaltungsmodul 28 analysiert die Pakete, um die spezifische Kommunikationsverbindung zu ermitteln, zu der die Datenpakete gehören, den verwendeten Datenkompressionstyp (falls vorhanden), und ob die Datenpakete von einer IP-Adresse geschickt wurden, die überwacht werden sollte. Das Verwaltungsmodul 28 muss diese Analyse durchführen, da das Filtermodul 24 einfach alle Datenpakete weiterleitet, die die vorangehend kurz beschriebenen Kriterien erfüllen (siehe 3A3D für mehr Einzelheiten). Da diese Pakete ohne Berücksichtigung jeglicher der in der Datenbank 26 gespeicherten Information weitergeleitet werden, muss das Verwaltungsmodul 28 die Regeln der Datenbank 26 mit der in dem Paketheader jedes Pakets vorhandenen Information vergleichen, um zu ermitteln, ob das empfangene Paket gespeichert werden sollte.
  • Diejenigen empfangenen Pakete, welche die Regeln der Datenbank 26 erfüllen, werden dann in einem Speichermedium 30 gespeichert, das vorzugsweise eine digitale Datenspeichervorrichtung mit hoher Kapazität, wie etwa eine Harddisk-Magnetspeichervorrichtung, eine optische Disk, eine CD-ROM, ein ZIP- oder DVD-Drive oder eine DAT-Kassette oder eine Kombination solcher Vorrichtungen gemäß den Betriebsbedürfnissen spezifischer Anwendungen, oder jede andere geeignete Speichermedien ist. Vorzugsweise wird auch die spezifische Kommunikationsverbindung oder ”Telefongespräch”, der bzw. dem jedes Datenpaket zugeordnet ist, gespeichert, um diese Verbindung zu einem späteren Zeitpunkt zu rekonstruieren und darzustellen.
  • Auf Anfrage durch den Benutzer kann das Verwaltungsmodul 28 dann ein oder mehrere Datenpakete von dem Speichermedium 30 abrufen, die einer oder mehreren Kommunikationsverbindungen zugeordnet sind. Das abgerufene Paket oder die Pakete werden dann zu einem Datenumspeichermodul 32 übertragen. Das Datenumspeichermodul 32 ist vorzugsweise in der Lage, diese abgerufenen Pakete zu manipulieren, um eine bestimmte Kommunikationsverbindung durch Anwendung des RTPs (Echtzeitprotokoll) wiederherzustellen. Wie nachstehend unter Bezug auf die 4C und 5 detaillierter beschrieben, werden die Datenpakete in denjenigen Systemen, die das RTP befolgen, mit einem Zeitstempel statt nur einer Abfolgenummer in den Header geschickt. Ein solcher Zeitstempel ist für Audio- und Videostromdaten notwendig, um die Datenpakete so wieder zusammenzusetzen, dass der gesamte Zeitablauf des Datenstroms aufrechterhalten wird. Ohne einen solchen Zeitstempel würde der richtige Zeitablauf nicht aufrechterhalten und könnten die Audio- oder Videoströme nicht präzise rekonstruiert werden.
  • Die Kommunikationsverbindungen werden unter Verwendung der anwendbaren Audio- und/oder Video-CODECs aus den rekonstruierten Datenpaketströmen wiederhergestellt. Ein CODEC ist ein nichtlineares Verfahren zur Umwandlung analoger und digitaler Daten. Somit ermöglicht beispielsweise ein Audio-CODEC die Umwandlung der digitalisierten Audiodaten in relevanten Datenpaketen zu analogen Audiodaten zur Darstellung für den Benutzer als hörbare Daten. Geeignete CODECs sind nachstehend in Bezug auf 5 detaillierter beschrieben.
  • Damit der Benutzer die Darstellung der rekonstruierten Kommunikationsverbindung empfangen kann, weist das System 10 vorzugsweise eine Audioeinheit 34 und eine Videoeinheit 36 auf, die kollektiv als ”Kommunikationsverbindungs-Anzeigeeinheit” bezeichnet werden. Bevorzugter sind sowohl die Audioeinheit 34 als auch die Videoeinheit 36 in der Lage, sowohl eine Audio- beziehungsweise Videoeingabe zu empfangen, als auch Audio- oder Videoausgabe darzustellen. Die Audioeinheit 34 und Videoeinheit 36 sollten zumindest in der Lage sein, eine Audio- beziehungsweise Videoausgabe darzustellen. Beispielsweise könnte die Audioeinheit 34 gegebenenfalls ein Mikrofon für die Eingabe und einen Lautsprecher oder Ohrhörer für die Ausgabe umfassen. Die Videoeinheit 36 könnte beispielsweise gegebenenfalls einen Videobildschirm oder Anzeigeschirm für die Ausgabe und eine Videokamera für die Eingabe umfassen.
  • 2 ist ein schematisches Blockdiagramm des Systems 10 von 1, das das Gesamtsystem von Softwaremodulen von System 10 detaillierter zeigt. Es wird auch, wo passend, auf Ablaufdiagramme verwiesen, die die Arbeitsweise dieser Softwaremodule detaillierter zeigen (3A3D und 5), sowie auf Beschreibungen der Header der verschiedenen Typen von Datenpaketen (4A4D).
  • Wie dargestellt, umfasst das System 10 wiederum eine Verbindung zum Intranet 14 durch die NIC 16. Beim Übertragen der Pakete durch das Intranet 14 fängt die NIC 16 diese Pakete ab und leitet sie zum Filtermodul 24 weiter.
  • Das Filtermodul 24 hat zwei Komponenten. Eine erste Filterkomponente 38 untersucht den Header des Datenpakets, das ein Paket vom IP-Typ mit dem korrekten Header sein sollte, wie nachstehend in 4A gezeigt. Als nächstes leitet die erste Filterkomponente 38 das Datenpaket zu einer zweiten Filterkomponente 40 weiter. Die zweite Filterkomponente 40 ermittelt dann den Typ von IP-Datenpaket, das gemäß den Normen von H.225, H.245, RTP oder RTCP konstruiert sein könnte.
  • Wie in Bezug auf 3A dargestellt, arbeiten die erste Filterkomponente 38 und zweite Filterkomponente 40 wie folgt. In Schritt eins wird ein Paket von dem Filtermodul 24 empfangen. Das Paket wird der ersten Filterkomponente 38 gegeben, welche dann in Schritt 2 ermittelt, ob das Paket ein Paket vom IP-Typ ist. Eine solche Ermittlung wird an der Struktur des Headers des Datenpakets durchgeführt, wovon ein Beispiel in 4A dargestellt ist. Ein Header 42 ist als eine Vielzahl von Fächern dargestellt, wovon jedes einen Anteil oder ein ”Feld” des Headers repräsentiert. Die von jedem Anteil eingenommene Anzahl von Bytes ist ebenfalls dargestellt, wobei es sich versteht, dass jede Schicht aus 32 Bit besteht. Der erste Anteil des Headers, ein ”VERS”-Anteil 44, ist die Protokollversionsnummer. Als nächstes deutet ein ”H.LEN”-Anteil 46 die Anzahl von 32-Bit-Quantitäten in dem Header an. Ein ”DIENSTTYP”-Anteil 48 deutet an, ob der Absender es vorzieht, dass das Datagramm über eine Route mit minimaler Verzögerung oder eine Route mit maximalem Durchsatz reist. Ein ”GESAMTLÄNGE”n-Anteil 50 deutet die Gesamtzahl von Acht-Bit-Bytes in sowohl dem Header als auch den Daten an.
  • In der nächsten Schicht identifiziert ein ”IDENTIFIKATION”s-Anteil 52 das Paket selbst. Ein ”MERKER”-Anteil 54 zeigt an, ob das Datagramm ein Fragment oder ein komplettes Datagramm ist. Ein ”FRAGMENT VERSETZT”-Anteil 56 spezifiziert den Standort dieses Fragments in dem Originaldatagramm, falls das Datagramm fragmentiert ist. In der nächsten Schicht enthält ein ”LEBENSZEIT”-Anteil 58 eine positive ganze Zahl zwischen 1 und 255, die bei jeder zurückgelegten Route progressiv vermindert wird. Wenn der Wert 0 wird, wird das Paket nicht mehr weitergeleitet und wird es zum Absender zurückgeschickt. Ein ”TYP”-Anteil 60 zeigt den Typ der weitergeleiteten Daten an. Ein ”HEADER-PRÜFSUMME”-Anteil 62 ermöglicht die Überprüfung der Integrität des Pakets durch Vergleichen der tatsächlichen Prüfsumme mit dem in Teil 62 aufgezeichneten Wert.
  • Die nächste Schicht von Header 42 enthält die Quellen-IP-Adresse 64, wonach die folgende Schicht die Bestimmungs-IP-Adresse 66 enthält. Ein optionsweiser IP-OPTIONEN-Anteil 68 ist vorhanden, wonach Fülldaten (falls nötig) vorhanden sind ein Datenanteil 70 des Pakets, das die Daten enthält, beginnt.
  • Die Struktur des Headers des Datenpakets wird durch die erste Filterkomponente 38 überprüft, um zu ermitteln, ob dieser Header die erforderlichen Datenfelder in der korrekten Reihenfolge aufweist, sodass der Header des Datenpakets eine Struktur gemäß Header 42 hat. Die erste Filterkomponente 38 lässt nur die Pakete mit der korrekten Headerstruktur passieren, wie in Schritt 3A gezeigt. Ansonsten werden die Pakete fallengelassen, wie in Schritt 3B gezeigt.
  • Die Pakete mit dem korrekten Header, oder ”IP-Pakete”, werden dann zu der zweiten Filterkomponente 40 weitergeleitet. Die zweite Filterkomponente 40 führt dann den Rest der Filterschritte durch. In Schritt 3A überprüft die zweite Filterkomponente 40 die IP-Pakete, um ihren Typ aus dem Datenanteil des Pakets zu ermitteln, wie in 4A gezeigt. Die Pakete könnten zu einer von vier Kategorien gehören: H.225, H.245, RTP und RTCP. Die Schritte des Verfahrens für H.225-Pakete sind in 3A gezeigt, während die Vorgehensweisen für die restlichen Pakettypen jeweils in den 3B3D dargestellt sind.
  • Sobald der Typ des Pakets ermittelt worden ist, werden sowohl das Paket selbst als auch die Information in Bezug auf den Typ von Paket beide zu dem Verwaltungsmodul 28 weitergeleitet, wie in 2 gezeigt. Das Paket wird dann zu der relevanten Komponente innerhalb des Verwaltungsmoduls 28 weitergeleitet, wie ebenfalls in 2 gezeigt, für den durchzuführenden Aufzeichnungsprozess. Die aufgezeichneten Pakete werden im Speichermodul 30 gespeichert, wie nachstehend in Bezug auf die 3C und 3D detaillierter beschrieben.
  • Wenn ermittelt wurde; dass das Paket ein H.225-Paket gemäß dem Header des Pakets ist (siehe 4B), so wird das Paket zu einem H.225-Anrufkontrollmodul 78 innerhalb des Verwaltungsmoduls 28 weitergeleitet, wie in 2 gezeigt. Die Schritte des Verwaltungsverfahrens sind wie folgt, unter Verweis auf 3A. In Schritt 4A von 3A, wird das H.225-Paket überprüft, um zu sehen, ob es ein Setup-Paket ist, was gemäß der Struktur der Daten in dem Paket ermittelt wird. Diese Struktur ist in der H.225.0-Empfehlung spezifiziert und umfasst zumindest die folgenden Informationstypen:
    ProtokollIdentifikator (die Version von H.225.0, die unterstützt wird);
    h245Adresse (spezifische Transportadresse, an der H.245-Signalisierung durch den Anrufendpunkt oder Gatekeeper zu erstellen ist);
    QuellenAdresse (die H.323-IDs für die Quelle);
    QuellenInfo (enthält einen EndpunktTyp, um den angerufenen Teilnehmer in die Lage zu versetzen, zu ermitteln, ob der Anruf einen Gatekeeper
    umfasst oder nicht);
    BestimmungsAdresse (das ist die Adresse, mit der der Endpunkt verbunden werden möchte).
  • Andere Typen von Daten sind ebenfalls erforderlich, wie in der H.225.0-Empfehlung spezifiziert. Diese Datenstruktur ermöglicht es dem H.225-Anrufkontrollmodul 78, zu ermitteln, ob das Paket ein Setup-Paket ist.
  • Wenn dieses Paket ein Setup-Paket ist, dann wird die erste Verzweigung des Verfahrens befolgt. Der Quellenport wird von einem Quellenportfeld 74 eines H.225-Headers 72 genommen, und der Bestimmungsport wird von einem Bestimmungsportfeld 76 genommen (siehe 4B). In Schritt 5A wird dann die Datenbank 26 von 1 überprüft, um zu ermitteln, ob eines der entsprechenden Endgeräte als aufzeichnendes Endgerät definiert ist; das heißt, ob von der IP-Adresse dieses Endgeräts initiierte. Kommunikationsverbindungen überwacht werden sollten. Wenn ja, dann wird in Schritt 6A der Endgerätstatus als Startverbindungsanfrage von dem dem Quellenport entsprechenden Endgerät eingestellt.
  • Alternativ wird das Paket in Schritt 4B überprüft, um zu sehen, ob es ein Schaltpaket ist, was gemäß der Struktur der Daten in dem Paket ermittelt wird. Diese Struktur ist in der H.225-Empfehlung spezifiziert und umfasst zumindest die folgenden Typen von Information:
    ProtokollIdentifikator (die Version von H.225.0, die unterstützt wird);
    h245Adresse (spezifische Transportadresse, an der H.245-Signalisierung durch den Anrufendpunkt oder Gatekeeper zu erstellen ist);
    Bestimmungsinfo (enthält einen EndpunktTyp, um den angerufenen Teilnehmer in die Lage zu versetzen, zu ermitteln, ob der Anruf einen Gatekeeper
    umfasst oder nicht); und
    KonferenzID (enthält eine eindeutige Identifikationsnummer, um die bestimmte Konferenz zu identifizieren).
  • Wenn das Paket ein Schaltpaket ist, dann wird die zweite Abzweigung des Verfahrens befolgt. In Schritt 5B wird der den Endgerätstatus andeutende Merker überprüft, um zu ermitteln, ob der Endgerätstatus als eine Startverbindungsanfrage eingestellt ist. In Schritt 6B werden die Einzelheiten des Anrufsignals in einer Anrufsablaufdatenbank 78 des Speichermediums 30 gespeichert (siehe 2). Diese Einzelheiten beinhalten vorzugsweise die Quellen- und Bestimmungs-IP-Adressen, die Quellen- und Bestimmungsports; die Zeit, zu der die Kommunikationsverbindung initiiert wurde, und jede andere relevante Information. In Schritt 7B wird der Status des Endgeräts auf ”Warten auf Logikkanal” gestellt.
  • Wenn von der zweiten Filterkomponente 40 festgestellt wurde, dass das Paket ein H.245-Paket ist, so wird das Paket zu einem H.245-Anrufkontrollmodul 82 innerhalb des Verwaltungsmoduls 28 weitergeleitet, wie in 2 gezeigt. Solche H.245-Pakete sind für die H.245-Signalisierung erforderlich. H.245-Signalisierung wird zwischen zwei Endpunkten erstellt: einem Endpunkt und einem Mehrpunktsteuergerät, oder einem Endpunkt und einem Gatekeeper (siehe nachstehend 6 und 7 für Beispiele und eine Beschreibung solcher Endpunkte). Jeder Endpunkt ist in der Lage, als Teil einer Kommunikationsverbindung anzurufen und angerufen zu werden. Das System der vorliegenden Erfindung überwacht jedoch solche Kommunikationsverbindungen nur, statt sie zu initiieren. Somit nutzt das System der vorliegenden Erfindung die H.245-Signalisierung dazu, zu ermitteln, wann die Kommunikationsverbindung begonnen hat, um effektiv die notwendigen Datenpakete zur Speicherung und späteren Rekonstruktion der Verbindung aufzuzeichnen.
  • Die Schritte des Verwaltungsverfahrens für H.245-Pakete sind wie folgt, unter Bezugnahme auf 3B. In Schritt 1A von 3B wird das H.245-Paket überprüft, um zu ermitteln, ob es ein Anfragepaket für einen offenen Logikkanal ist. Wenn es dies ist, dann wird in Schritt 2A der Endgerätstatus überprüft, um zu ermitteln, ob der Status ”Warten auf Logikkanal” ist. Wenn ja, dann wird in Schritt 3A der Endgerätstatus auf ”warten auf Bestätigung” eingestellt.
  • Alternativ wird das H.245-Paket überprüft, um zu ermitteln, ob es ein Bestätigungspaket für einen offenen Logikkanal ist, wie in Schritt 1B gezeigt. Wenn es das ist, so wird in Schritt 2B der Endgerätstatus überprüft, um zu ermitteln, ob der Status ”Warten auf Bestätigung” ist. Wenn ja, dann wird in Schritt 3B der Endgerätstatus auf ”Warten auf Endgerätefähigkeit” eingestellt. In Schritt 4B wird die Transportadresse des ”angerufenen” oder Bestimmungsendgeräts gespeichert. Diese Transportadresse wird aus dem Bestimmungsportfeld 76 des Headers 72 entnommen (siehe 4B). Es ist anzumerken, dass H.225- und H.245-Pakete identische Headerstrukturen haben.
  • Ebenfalls alternativ wird das H.245-Paket überprüft, um zu ermitteln, ob es ein Endgerätefähigkeitseingestelltes Paket ist, wie in Schritt 1C gezeigt. Wenn es das ist, dann wird in Schritt 2C die Endgerätefähigkeit in der Anrufablaufdatenbank 80 gespeichert (siehe 2). In Schritt 3C wird der Endgerätestatus auf ”im Anrufvorgang” eingestellt, sodass die Kommunikations-verbindung als eröffnet ermittelt wurde und dass das Verwaltungsmodul 28 jetzt RTP-Datenpakete empfangen kann.
  • Wenn von der zweiten Filterkomponente 40 ermittelt wurde, dass das Paket ein RTP-Paket ist, so wird das Paket zu einem RAS(Registrierung, Zulassungen und Status)-Kontrollmodul 84 innerhalb des Verwaltungsmoduls 40 weitergeleitet, wie in 2 gezeigt. Die Schritte des Verwaltungsverfahrens für RTP-Pakete sind, unter Bezugnahme auf 3C, wie folgt. In Schritt 1 von 3C wird der Endgerätestatus überprüft, um zu sehen, ob er ”in Anrufvorgang” ist. Wenn ja, dann werden in Schritt 2 die RTP-Pakete in einer RTP-Datenbank 86 innerhalb des Speichermediums 30 gespeichert (siehe 2). 4C zeigt die Struktur des RTP-Paketheaders, der zur Identifizierung der Kommunikationsverbindung, von der das Paket genommen wurde, verwendet werden kann.
  • Schließlich wird, wenn von der zweiten Filterkomponente 40 ermittelt wurde, dass das Paket ein RTCP-Paket ist, das Paket zu einem RTCP-Kontrollmodul 88 innerhalb des Verwaltungsmoduls 28 weitergeleitet, wie in 2 gezeigt. Die Schritte des Verwaltungsverfahrens für RTCP-Pakete sind, unter Bezugnahme auf 3D, wie folgt. In Schritt 1 von 3D wird der Endgerätestatus überprüft, um zu sehen, ob er ”in Anrufvorgang” ist. Wenn ja, dann werden in Schritt 2 die RTCP-Pakete in der Anrufablaufdatenbank 80 innerhalb des Speichermediums 30 gespeichert (siehe 2). 4D zeigt die Struktur des RTCP-Paketheaders, der zur Identifizierung der Kommunikationsverbindung, von der das Paket genommen wurde, verwendet werden kann.
  • Somit illustrieren die 3A3D das Verfahren der vorliegenden Erfindung in Hinsicht auf das Filtern und Speichern von Datenpaketen, die die aufgezeichnete Kommunikationsverbindung bilden, wie von dem System der vorliegenden Erfindung aufgezeichnet, wie in den 1 und 2 gezeigt. Natürlich ist, zusätzlich zur Aufzeichnung solcher Kommunikationsverbindungen, das System der vorliegenden Erfindung auch in der Lage, diese Kommunikationsverbindungen abzufragen und für den Benutzer wiederzugeben. Die aus Datenpaketen zusammengesetzte gespeicherte Kommunikationsverbindung kann durch die Datenumspeichereinheit 32 von 2 im Zusammenwirken mit der Audioeinheit 34 und Videoeinheit 36 abgefragt und dargestellt werden. Das Verfahren zum Abfragen und Abspielen von Verbindungen, die von Interesse sind, ist in 5 gezeigt, während gewisse andere relevante Teile des Systems der vorliegenden Erfindung in 2 gezeigt sind.
  • In Schritt 1 von 5 gibt der Benutzer die Information ein, welche die Kommunikationsverbindung betrifft, die abgefragt und abgespielt werden soll. Diese Information umfasst vorzugsweise die Endgerätenummer oder andere Bestimmungsinformation, die zumindest einen der Teilnehmer der Kommunikationsverbindung von Interesse betrifft; den Zeitpunkt, an dem die Verbindung anfing; und den Zeitpunkt, an dem die Verbindung endete. Jedoch könnte alternativ andere Information anstelle dieser Information enthalten sein, solange ausreichende Information zur Verfügung gestellt ist, um die Kommunikationsverbindung von Interesse zu identifizieren.
  • In Schritt 2 von 5 wird die Anrufablaufdatenbank 80 (siehe 2) von der Datenumspeichereinheit 32 durchsucht, um die Einzelheiten der Kommunikationsverbindung(en) in dem spezifizierten Zeitbereich zu finden. Diese Einzelheiten werden dann mit der vom Benutzer eingegebenen Information verglichen, um zumindest eine Kommunikationsverbindung von Interesse in dem Anrufbereich zu lokalisieren.
  • In Schritt 3 wird die RTP-Datenbank 86 des Speichermediums 30 (siehe 2) durchsucht, wieder von der Datenumspeichereinheit 32, um im Wesentlichen alle Datenpakete von der zumindest einen Kommunikationsverbindung in dem spezifizierten Anrufbereich zu finden. Optionsweise und vorzugsweise sind in Schritt 4, wenn der Audioanteil der Kommunikationsverbindung in Stereo aufgezeichnet wurde, die Datenpakete in unterschiedliche Audiokanäle unterteilt.
  • In Schritt 5 werden die Datenpakete von der Datenumspeichereinheit 32 von einem RTP(Echtzeitprotokoll)-Softwaremodul 91 innerhalb der Datenumspeichereinheit 32 umgespeichert. Das RTP-Softwaremodul 32 ordnet die Datenpakete innerhalb jedes Kanals entsprechend dem Zeitstempel jedes Pakets. Wie in 4C gezeigt, weist ein RTP-Paketheader 92 mehrere wichtige Felder auf: ein Zeitstempelfeld 94, ein Synchronisationsquellen(SSRC)-Identifikatorenfeld 96 und ein beitragendes Quellen(CSRC)-Identifikatorenfeld 98. Das SSRC-Feld 96 wird zur Ermittlung der Quelle der RTP-Pakete (des Absenders) verwendet, der eine eindeutige Identifikationsadresse hat (den SSRC-Identifikator). Der CSRC-Identifikator im CSRC-Feld 98 wird in einer Konferenz mit mehreren Teilnehmern verwendet und zeigt den SSRC-Identifikator aller Teilnehmer an. Das Zeitstempelfeld 94 wird von dem RTP-Softwaremodul 91 verwendet, um die relative Zeit zu ermitteln, zu der die Daten in jedem Paket angezeigt werden sollten.
  • Beispielsweise sind die Audiostromdaten der Audiosprache einer Person zu den Lippenbewegungen dieser Person, wie in dem Videostrom gezeigt, synchronisiert, ein als ”Lippensynchronisation” bekannter Vorgang. Solche Synchronisation erfordert mehr als das einfache Abspielen von Audio- und Videodaten zu gewissen relativen Zeitpunkten, da die Audio- und Videodatenpakete eventuell nicht zur selben Zeit ankommen und daher geringfügig unterschiedliche Zeitstempel haben können.
  • Sobald das Datenpaket korrekt synchronisiert worden ist, wird dann die Steuerung der Darstellung der Audiodaten von einer Audiokomponente 102 der Datenumspeichereinheit 32 gemäß einem oder mehreren Audio-CODECs durchgeführt (siehe 2). Die Steuerung der Darstellung der Videodaten wird dann durch eine Videokomponente 100 der Datenumspeichereinheit 32 gemäß einem oder mehreren Video-CODECs durchgeführt (siehe 2).
  • Geeignete CODECs umfassen, sind jedoch nicht beschränkt auf, ein Audiocodec, das die CCITT-Empfehlung G.711 (1988), Pulscodemodulation (PCM) von Sprachfrequenzen verwendet; ein Audiocodec, das die CCITT-Empfehlung G.722 (1988), 7 kHz Audiocodierung innerhalb von 64 kbit/s verwendet; ein Audiocodec, das die ITU-T-Empfehlung G.723.1 (1996), Sprachcodierer: Auf 5,3 und 6,3 Kbps übertragender Dualgeschwindigkeitssprachcodierer für Multimedienkommunikationen verwendet; ein Audiocodec, das die CCITT-Empfehlung G.728 (1992), Codierung von Sprache auf 16 Kbps unter Anwendung von niedrigverzögernder codeerregter linearer Vorhersage verwendet; ein Audiocodec, das die ITU-T-Empfehlung G. 729 (1996), Codierung von Sprache auf 8 Kbps unter Verwendung konjugierter Struktur-Algebracode-erregter linearer Vorhersage (CS-ACELP) verwendet; ein Videocodec, das die ITU-T-Empfehlung H.261 (1993), Videocodec für audiovisuelle Dienste auf p × 64 kbit/s verwendet; ein Videocodec, das die ITU-T-Empfehlung H.263 (1996), Videocodierung für. Niedrigbitratenkommunikation verwendet; und im Wesentlichen jede andere gleichartige Codiernorm.
  • Wie in 2 gezeigt, werden die Audiodaten von der Audioeinheit 34 dargestellt, die beispielsweise einen Lautsprecher umfassen könnte. Die Videodaten werden von der Videoeinheit 36 dargestellt, die beispielsweise einen Anzeigebildschirm umfassen könnte. Schritt 5 von 5 wird dann vorzugsweise wiederholt, sodass im Wesentlichen die Gesamtheit der Kommunikationsverbindung dargestellt wird. Wie in Schritt 6 gezeigt, wird jedes Datenpaket der Kommunikationsverbindung überprüft, um zu sehen, ob die Anrufzeit um ist. Wenn die individuelle Verbindung noch nicht abgeschlossen ist, wird vorzugsweise Schritt 5 wiederholt. Alternativ und bevorzugt wird, wenn die Anrufzeit um ist, dann die Anrufablaufdatenbank 80 durchsucht, um zu sehen, ob andere Kommunikationsverbindungen innerhalb der gegebenen Zeitspanne aufgezeichnet wurden, wie in Schritt 7 gezeigt. Wenn es zumindest eine andere solche Kommunikationsverbindung gibt, dann wird vorzugsweise das Verfahren von 5 wiederholt, beginnend ab Schritt 2.
  • Gemäß bevorzugten Ausführungen der vorliegenden Erfindung sind mehrere Konfigurationen des Computerloggingsystems möglich, wovon Beispiele in den 6 und 7 dargestellt sind.
  • Gemäß einer ersten Ausführung des Systems der vorliegenden Erfindung, gezeigt in 6, umfasst ein typisches Basiskonfigurationssystem 104 eine einzige Kommunikationsverbindungs-Verwaltungseinheit 13, im Wesentlichen wie in den 1 und 2 gezeigt, gemäß der vorliegenden Erfindung. Die Kommunikationsverbindungs-Verwaltungseinheit 13 verwaltet die Kommunikation in einem unabhängigen Intranet, wie etwa einem LAN 106. Das LAN 106 ist sowohl an die Kommunikationsverbindungs-Verwaltungseinheit 13, als auch an eine Vielzahl von Endgeräten 108, als ”T1”, ”T2” und so weiter bezeichnet, angeschlossen, die das H.323-Protokoll befolgen. Jedes Endgerät 108 ist ein Endpunkt an dem LAN 106, das Echtzeit-Zweiwegekommunikationen mit einem anderen Endgerät 108, einem Gateway 110 oder einer Mehrpunktkontrolleinheit (MCU) 112 vorsieht. Diese Kommunikation besteht aus Steuerung, Anzeigen, Audioströmen, Videoströmen, und/oder Daten. Das Endgerät 108 ist gegebenenfalls nur in der Lage, solche Kommunikation für nur Audio, Audio und Daten, Audio und Video, oder Audio, Daten und Video zu verschaffen. Wie vorangehend im Abschnitt ”Beschreibung der zugrundeliegenden Technik” beschrieben, könnte die H.323-Entität ein Endgerät sein, das in der Lage ist, Audio- und/oder Videokommunikation als ”LAN-Telefon” zu verschaffen, könnte jedoch auch ein unabhängiges Audio- oder Videotelefon sein.
  • Der Gateway 110 (GW) ist gemäß H.323 konstruiert und ist ein Endpunkt an dem LAN 106, das Echtzeit-Zweiwegekommunikationen zwischen Endgeräten 108 an dem LAN 106 und anderen geeigneten Endgeräten an einem WAN (nicht dargestellt), oder zu einem anderen solchen Gateway (nicht dargestellt), vorsieht. Andere geeignete Endgeräte umfassen diejenigen, welche den Empfehlungen H.310 (H.320 auf B-ISDN), H.320 (ISDN), H.321 (ATM), H.322 (GQOS-LAN), H.324 (GSTN), H.324M (Mobile) und V.70 (DSVD) entsprechen. MCU 112 ist ein Endpunkt an LAN 106, der die Teilnahme von drei oder mehr Endgeräten 108 und Gateways 110 an einer Mehrpunktkonferenz ermöglicht.
  • Vorzugsweise weist das System 104 auch einen Gatekeeper (GK) 114 auf, der eine H.323-Entität auf LAN 106 ist, der dem LAN 106 Adressenübersetzung und Steuerungszugang für Endgeräte 108, Gateways 110 und MCUs 112 zur Verfügung stellt. Der Gatekeeper 114 kann Endgeräten 108, Gateways 110 und MCUs 112 auch andere Dienste zur Verfügung stellen, wie etwa Bandbreitenverwaltung und Lokalisierung von Gateways 110. Vorzugsweise ermöglicht der Gatekeeper 114 die Ermittlung von IP-Adressen von Endgeräten 108 auf dem LAN 106, sodass die korrekte IP-Adresse ”im Flug” ermittelt werden kann.
  • Zusätzlich kann das LAN 106 nicht-audiovisuelle Geräte für normale T.120-Datenanwendungen, wie etwa elektronische Whiteboards, Einzelabbildungsübertragung, Dateienaustausch, Datenbankzugang usw. unterstützen.
  • Im Basissystem 104 wird eine einzige, unabhängige Kommunikationsverbindungs-Verwaltungseinheit 13 zum Überwachen, Logging und Abfragen aller Audio- und/oder visuellen Anrufe entweder zwischen zwei beliebigen oder mehr an das LAN 106 angehängten Endgeräten 108 oder für jeden beliebigen Anruf, wovon eines oder mehr dieser Endgeräte 108 ein Teilnehmer ist, verwendet.
  • Für die bevorzugte Ausführung des Systems von 6 jedoch, das den Gatekeeper 114 umfasst, sowie für das System von 7, führt, sobald die Kommunikationsverbindung geöffnet wurde, vorzugsweise das RAS-Kontrollmodul 84 auch die RAS-Signalisierung zwischen dem Managementsteuermodul und der NIC 16 durch, wo dies zur Konfiguration des Systems nötig ist. Solches Signalisieren verwendet H.225.0-Mitteilungen zur Durchführung von Registrierung, Zulassungen, Bandbreitenwechseln, Status- und Abkoppelvorgängen zwischen Endpunkten und Gatekeepern. Diese Mitteilungen werden auf einem RAS-Signalisierkanal weitergeleitet, der von dem Anrufsignalisierkanal und dem H.245-Steuerkanal unabhängig ist. H.245-offene Logikkanalprozeduren werden nicht verwendet, um den RAS-Signalisierkanal zu erstellen. In LAN-Umgebungen, die einen Gatekeeper (eine Zone) enthalten, wird der RAS-Signalisierkanal zwischen dem Endpunkt und dem Gatekeeper geöffnet. Der RAS-Signalisierkanal wird vor dem Erstellen jedweder anderer Kanäle zwischen H.323-Endpunkten geöffnet.
  • 7 zeigt eine zweite Ausführung des Systems der vorliegenden Erfindung als ein Zonenkonfigurationssystem 116. Eine Zone 118 ist die Sammlung aller Endgeräte (Tx) 108, Gateways (GW) 110 und Mehrpunktkontrolleinheiten (MCUs) 112, verwaltet von einem einzigen Gatekeeper (GK) 114. Die Zone 118 enthält zumindest ein Endgerät 108, enthält jedoch nicht unbedingt einen oder mehrere Gateways 110 oder MCUs 112. Die Zone 118 hat nur einen Gatekeeper 114, wie dargestellt. In der gezeigten bevorzugten Ausführung ist die Zone 118 jedoch vorzugsweise unabhängig von der LAN-Topologie und enthält vorzugsweise mehrfache LAN-Segmente 120, die unter Verwendung von Routern (R) 122, wie dargestellt, oder anderer gleichartiger Vorrichtungen, verbunden sind.
  • Jedes überwachte LAN-Segment 120 hat eine örtliche Kommunikationsverwaltungseinheit 124 gemäß der vorliegenden Erfindung, wovon zwei dargestellt sind. Eine zentrale Verwaltungseinheit 126 gemäß der vorliegenden Erfindung steuert alle örtlichen Kommunikationsverwaltungseinheiten 124. Zusätzlich zu zentralisierten Datenbank- und Steuerdiensten kann die zentrale Verwaltungseinheit 125 zur Echtzeitüberwachung und Offline-Umspeicherung von Audio- und/oder Videokommunikationsverbindungen von einem einzigen Punkt aus verwendet werden. Die zentrale Verwaltungseinheit 126 ist optionsweise und bevorzugt entweder eine dedizierte Einheit von gleichartiger Struktur wie örtliche Kommunikationsverwaltungseinheiten 124, jedoch ohne die Speicherkapazität, oder die zentrale Verwaltungseinheit 126 ist alternativ und vorzugsweise bei den örtlichen Kommunikationsverwaltungseinheiten 124 integriert, um die Funktionalität von sowohl der örtlichen Kommunikationsverwaltungseinheit 124 als auch der zentralen Verwaltungseinheit 126 in einer einzigen Station zu verschaffen. Örtliche Kommunikationsverwaltungseinheiten 124 sind vorzugsweise entweder Kommunikationsverbindungs-Verwaltungseinheiten 13, im Wesentlichen wie in den 1 und 2 beschrieben, oder sind alternativ und bevorzugt einfachere Einheiten, denen die Fähigkeit fehlt, eine Kommunikationsverbindung örtlich abzufragen und darzustellen.
  • In noch einer anderen bevorzugten Ausführung der vorliegenden Erfindung (nicht dargestellt) wird vorzugsweise ein Mehrfachbenutzerbetrieb auf Basis von Client-/Serverarchitektur für das Basissystem 104 und Zonensystem 116 unterstützt. Eine unbegrenzte Anzahl von ”Client”-Stationen kann an beliebiger Stelle an dem LAN angeschlossen werden, wodurch Benutzer mit Verwaltungs- und Überwachungs-/Abfragekapazitäten versehen werden, die von dem Authorisationsniveau jedes spezifischen Benutzers bestimmt werden.
  • Noch eine andere, in 8 illustrierte, bevorzugte Ausführung der vorliegenden Erfindung spricht die Anforderungen einer Internet-Protokoll(IP)-verteilten Schaltumgebung an.
  • Aufzeichnungssysteme erfahren die folgenden Anforderungen, wenn sie mit einer IP-Umgebung verbunden werden:
    Da kein zentrales Koppelfeld vorhanden ist, können Sprachströme zwischen jedem Anschluss A und B über das WAN weitergeleitet werden, ohne ein Mittel vorzusehen, um die Anrufe an der Stelle, wo sich die Aufzeichnungssysteme befinden, abzufangen. Da das IP-Netzwerk aus Schaltkästen, Routers und Überbrückungen besteht, kann die Netzwerktopologie einen negativen Einfluss auf das Aufzeichnen haben. Nur wenige Multimedien-IP-Protokollsammlungen umfassen Verschlüsselung. Insbesondere fehlt es der H.323-Protokollsammlung an Verschlüsselung. Damit das Aufzeichnungssystem das Signal entschlüsseln kann, muss das Aufzeichnungssystem als ”legaler” Teilnehmer bei dem aufgezeichneten Anruf agieren. Die einzige Möglichkeit, zu einem ”legalen” Teilnehmer bei dem aufgezeichneten Anruf zu werden, ist, den Anruf in ein Konferenzgespräch umzuwandeln, wobei das Aufzeichnungssystem ein Mitglied der Konferenz ist. Multimedien-IP-Protokolle definieren mehrere Typen von Audio- und Video-CODECs (G.711, G.722, G.728, G.723, G.729, II.261 und II.263). Somit sollte das Aufzeichnungssystem während des Aufzeichnen- und Abspielbetriebs die Fähigkeit haben, von einem CODECS zum anderen zu wechseln, je nach Fähigkeit des Endpunkts, wenn die Sprache oder das Video unter Verwendung eines unterschiedlichen CODECS aufgezeichnet und gespeichert wurde.
  • Das System 104 von 6 ist zur Verwendung in einer Norm H.323-Umgebung gedacht. Die Endgeräte 108 führen Telefongespräche untereinander, oder alternativ mit POTS-Telefonen mittels des Gateways 110. Um diese Anrufe zu machen, kommunizieren die Endgeräte 108 mit dem Gatekeeper 114, um das Bestimmungs-Endgerät oder den Gateway auf dem LAN zu finden, unter Verwendung des RAS-Protokolls, um den Anruf-Setup unter dem H.225-Protokoll durchzuführen und um über die RTP-Strommerkmale unter dem H.245-Protokoll zu verhandeln. Es ist anzumerken, dass diese Protokolle alle zu der H.323-Protokollsammlung gehören. Die Kommunikation mit dem Gatekeeper 114, unter den RAS-, H.225- und H.245-Protokollen, ist der Signalisationsteil des Anrufs und wird verwendet, um die RTP- oder RTCP-Ströme des Anrufs zu erstellen, die dazu verwendet werden, die eigentlichen Sprach- oder Videodaten zu tragen. Die MCU 112 verschafft die Fähigkeit, das Konferieren zwischen drei oder mehr Teilnehmern durchzuführen. Alle obengenannten Kommunikationen werden über das LAN 106 durchgeführt.
  • Die Kommunikationsverbindungs-Verwaltungseinheit 13 ist derart an das LAN 106 angeschlossen, dass die Kommunikationsverbindungs-Verwaltungseinheit 13 in der Lage ist, alle Pakete einer Unterhaltung aufzuspüren, sowohl die Signalisierpakete als auch RTP- oder RTCP-Pakete. Verbindungsverfahren des Standes der Technik umfassen:
    • 1. Verwendung eines Hubs, in welchem Fall alle Pakete zu allen Ports in dem Hub weitergeleitet werden; und
    • 2. Überwachen strategischer Ports eines geschalteten Hubs durch andere Ports an dem geschalteten Hub.
  • Wahrscheinliche strategische Ports unter der zweiten Alternative sind die Ports des geschalteten Hubs, an die ein oder mehr Gateways 110 angeschlossen sind, in welchem Fall alle ausgehenden Anrufe aufgezeichnet werden können. In diesem Beispiel ist der Gateway 110 an den überwachten Port des Schalthubs angeschlossen, und die Kommunikationsverbindungs-Verwaltungseinheit 13 ist an den Überwachungsport des Schalthubs angeschlossen.
  • Die Kommunikationsverbindungs-Verwaltungseinheit 13 spürt die RTP- und RTCP-Pakete der Unterhaltung auf und extrahiert die Sprach- oder Videodaten aus diesen Paketen. Um diese Daten einer Telefonanschlussnummer oder dem Namen der Person an dem Anschluss zuzuordnen,
    muss die H.323-Signalisierung analysiert werden. Diese Lösung funktioniert nicht in Voice over IP-Systemen, worin die Signalisierungsprotokolle nicht innerhalb der H.323-Protokollsammlung sind. Solche Signalisierungsprotokolle umfassen SIP, MGCP und das proprietäre Skinny-Protokoll von Cisco.
  • Eine dritte Ausführung 150 des Systems der vorliegenden Erfindung, die nicht von dem Signalisierungsprotokoll abhängt, ist in 8 illustriert. In dem System 150 werden die Sprach- oder Videodaten aufgezeichnet, wie in dem System 104 von 6, indem man die Kommunikationsverbindungs-Verwaltungseinheit 13 die RTP- und RTCP-Pakete aufspüren lässt. Die Innovation von System 150 ist die Hinzufügung eines Gliedes 160 zwischen der Kommunikationsverbindungs-Verwaltungseinheit 13 und dem Gatekeeper 114. Spezifisch verbindet das Glied 160 das Verwaltungsmodul 28 der Kommunikationsverbindungs-Verwaltungseinheit 13 mit dem Gatekeeper 114. Das Glied 160 stellt der Kommunikationsverbindungs-Verwaltungseinheit 13 CTI(Computer-Telefonintegration)s-Daten oder CDR(Anrufdatenaufzeichnung)s-Daten zur Verfügung. Diese Daten ersetzen die Daten, die durch Analysieren der H.323-Protokolle im System 104 von 6 abgefragt werden. Diese Daten umfassen die IP-Adresse des Anrufers und an dere Identifikationsinformation, wie etwa Anschlussnummer, Name des Anrufers, oder jede andere Information, die über das Glied 160 eintrifft. Optionsweise kann die IP-Adresse des Anrufers aus der anderen Identifikationsinformation erschlossen werden. Diese Daten werden von der Kommunikationsverbindungs-Verwaltungseinheit 13 verwendet, um Anrufen Anschlussnummern, Namen von Anrufern oder jede andere Information, die über das Glied 160 eintrifft, zuzuordnen.
  • Glied 160 ist ein Logikglied, das auf mehrere Arten eingesetzt werden kann, einschließlich:
    • 1. In demselben LAN, das für Voice over IP-Anrufe verwendet wird. Auf diese Weise wird an der Kommunikationsverbindungs-Verwaltungseinheit 13 keine zusätzliche Hardware benötigt.
    • 2. In einem separaten LAN von dem für Voice over IP-Anrufe verwendeten LAN. Unter dieser Alternative enthält die Kommunikationsverbindungs-Verwaltungseinheit 13 einen zusätzlichen Netzwerkadapter, gleichartig zu NIC 16, der spezifisch für das Glied 160 verwendet wird.
    • 3. In einer seriellen Verbindung unter Verwendung eines der seriellen Ports der Kommunikationsverbindungs-Verwaltungseinheit 13.
  • Da das Glied 160 ein Logikglied ist, dient 8 dazu, alle drei dieser Einsatzmöglichkeiten zu illustrieren.
  • Das System 150 von 8 hat die folgenden Vorteile:
    • 1. Es besteht keine Abhängigkeit von dem in dem Voice over IP-System verwendeten Typ von Signalisierung. System 150 arbeitet mit allen Signalisiertypen.
    • 2. Das Glied 160 kann mehr Information übertragen, als von den H.323-Signalisierprotokollen abgefragt werden kann. Diese Information kann beispielsweise anwendungsspezifische Information, wie etwa eine Versicherungspolicenummer, sein, in dem Fall, dass das System 150 eine Komponente des Callcenters einer Versicherungsfirma ist.
    • 3. Da weniger Mitteilungen an der Kommunikationsverbindungs-Verwaltungseinheit 13 eintreffen, vermindert das System 150 die Belastung des Prozessors der Kommunikationsverbindungs-Verwaltungseinheit 13, was zu einer Steigung der Anzahl von Kanälen, die gleichzeitig aufgezeichnet werden können, führt.
  • Das System 150 von 8 kann unter Verwendung der folgenden kommerziell erhältlichen Komponenten auf die Praxis reduziert werden:
    Gatekeeper 114: Call Manager 3.0TM von Cisco Systems, Inc., San Jose, Kalifornien
    Glied 160: eine JTAPITM-Verbindung des Call Managers 3.0TM
    Endgeräte 108: VIP 30TM oder SP 12+TM, beide von Cisco Systems, Inc., San Jose, Kalifornien
    Gateway 110: Catalyst 3640 von Cisco Systems, Inc., San Jose, Kalifornien
    MCU 112: Conference Plug-In auf dem Call Manager 3.0TM Kommunikationsverbindungs-
    Verwaltungseinheit 13: NicelogTM, von Nice Systems Ltd., Ra'anana, Israel
    LAN 106: Switch Hub Catalyst 2924 von Cisco Systems, Inc., San Jose, Kalifornien

Claims (10)

  1. Ein System (10) zur Verwaltung einer Kommunikationsverbindung über ein Computernetzwerk (14), das einen Pförtner (114) umfasst, wobei das System (10) folgendes umfasst: (a) ein Netzwerkverbindungselement (16) zum Anschließen an das Computernetzwerk (14) und zum Empfangen von Datenpaketen von dem Computernetzwerk (14); (b) eine Filtereinheit (24) zum Filtern besagter Datenpakete, sodass besagte Datenpakete zumindest einen Teil der Kommunikationsverbindung bilden und sodass besagte Datenpakete ausgewählte Datenpakete sind; (c) eine Verwaltungseinheit (28) zum Empfangen besagter ausgewählter Datenpakete und zum Speichern besagter ausgewählter Datenpakete, sodass besagte ausgewählte Datenpakete gespeicherte Datenpakete sind; und (d) ein Speichermedium (30) zum Empfangen und zum Speichern besagter gespeicherter Datenpakete von besagter Verwaltungseinheit (28), sodass zumindest ein Teil der Kommunikationsverbindung gespeichert wird; dadurch gekennzeichnet, dass besagte Filtereinheit (24) besagte Datenpakete im Wesentlichen nur dann akzeptiert, wenn besagte Datenpakete Daten enthalten, die aus der aus Audiodaten und Videodaten bestehenden Gruppe gewählt sind, und dadurch, dass das System weiterhin folgendes umfasst: (e) ein logisches Verbindungsglied (160) zwischen dem Pförtner (114) und besagter Verwaltungseinheit (28), zum übertragen von die besagten Datenpakete betreffender Information von dem Pförtner (114) zu besagter Verwaltungseinheit (28).
  2. Das System von Anspruch 1, weiterhin umfassend: (f) eine Datenwiederherstellungseinheit (32) zum Wiedergewinnen und Anzeigen besagten zumindest einen Teils der Kommunikationsverbindung, wobei besagte Datenwiederherstellungseinheit (32) besagte Datenpakete von besagtem Speichermedium (30) durch besagte Verwaltungseinheit (28) anfordert, und wobei besagte Datenwiederherstellungseinheit (32) besagte Datenpakete rekonstruiert, um besagten zumindest einen Teil der Kommunikationsverbindung anzuzeigen.
  3. Das System (10) von Anspruch 2, wobei besagte Datenwiederherstellungseinheit (32) weiter eine Kommunikationsverbindungs-Anzeigeeinheit (34, 36) zum Anzeigen zumindest einen Teils der Kommunikationsverbindung umfasst.
  4. Das System (10) von Anspruch 3, wobei besagte Kommunikationsverbindungs-Anzeigeeinheit (34, 36) aus der aus einer Videoeinheit (36) und einer Audioeinheit (34) bestehenden Gruppe gewählt ist.
  5. Das System (10) von Anspruch 2, weiterhin umfassend: (g) eine mit besagter Filtereinheit (24) verbundene Datenbank (26) zum Speichern von Filterinformation, wobei besagte Filterinformation zumindest eine IP-Adresse eines Teilnehmers enthält, dessen Kommunikationsverbindungen überwacht werden; wobei besagte Filtereinheit (24) besagte Datenpakete gemäß besagter Filterinformation akzeptiert, sodass besagte Filtereinheit (24) besagte Datenpakete im Wesentlichen nur akzeptiert, wenn besagte Datenpakete besagte Filterinformation erfüllen.
  6. Das System (10) von Anspruch 5, weiter umfassend: (h) einen Benutzercomputer (12) zum Empfangen zumindest eines Befehls eines Benutzers und dem besagtem Benutzer Anzeigen von Information, sodass besagter Benutzer besagte Filterinformation gemäß besagtem zumindest einem Befehl besagten Benutzers bestimmt.
  7. Das System (10) von Anspruch 6, wobei das Computernetzwerk (14) aus der aus einem LAN (lokales Netzwerk) (106) und einem WAN (Weitbereichsnetzwerk) bestehenden Gruppe gewählt ist.
  8. Das System (10) von Anspruch 7, wobei das Computernetzwerk ein LAN (lokales Netzwerk) (106) ist.
  9. Das System (10) von Anspruch 8, wobei besagtes LAN (106) in zumindest zwei Segmente (120) unterteilt ist, wobei das System (10) weiterhin folgendes umfasst: (i) eine lokale Verwaltungseinheit (124) fuer jedes Segment (120), wobei besagte lokale Verwaltungseinheit (124) besagte Filtereinheit (24) und besagte Verwaltungseinheit (28) umfasst; und (j) eine zentrale Verwaltungseinheit (126) zum Steuern besagter lokaler Verwaltungseinheiten (124), wobei besagte zentrale Verwaltungseinheit (126) das Speichern in besagtem Speichermedium (30) steuert.
  10. Das System (10) von Anspruch 1, wobei besagtes Netzwerkverbindungselement (16) eine Netzwerkkarte (16) ist.
DE60116341.9T 2000-09-19 2001-09-16 Kommunikationsverwaltungsystem für computernetzbasierte telefone Expired - Lifetime DE60116341T3 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US66475500A 2000-09-19 2000-09-19
US664755 2000-09-19
PCT/IL2001/000874 WO2002025889A2 (en) 2000-09-19 2001-09-16 Communication management system for computer network based telephones
EP01972435.0A EP1319299B2 (de) 2000-09-19 2001-09-16 Kommunikationsverwaltungsystem für computernetzbasierte telefone

Publications (3)

Publication Number Publication Date
DE60116341D1 DE60116341D1 (de) 2006-02-02
DE60116341T2 DE60116341T2 (de) 2006-08-03
DE60116341T3 true DE60116341T3 (de) 2017-04-06

Family

ID=24667311

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60116341.9T Expired - Lifetime DE60116341T3 (de) 2000-09-19 2001-09-16 Kommunikationsverwaltungsystem für computernetzbasierte telefone
DE60133949T Expired - Lifetime DE60133949D1 (de) 2000-09-19 2001-09-16 Kommunikationsmanagementsystem zum zumindest teilweisen Aufzeichnen der Kommunikation

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE60133949T Expired - Lifetime DE60133949D1 (de) 2000-09-19 2001-09-16 Kommunikationsmanagementsystem zum zumindest teilweisen Aufzeichnen der Kommunikation

Country Status (8)

Country Link
EP (3) EP1635534B1 (de)
JP (1) JP2004509563A (de)
AT (2) ATE394865T1 (de)
AU (1) AU781291B2 (de)
DE (2) DE60116341T3 (de)
HK (2) HK1058267A1 (de)
WO (1) WO2002025889A2 (de)
ZA (1) ZA200202928B (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9620082D0 (en) 1996-09-26 1996-11-13 Eyretel Ltd Signal monitoring apparatus
US6865604B2 (en) 1998-08-26 2005-03-08 Sts Software Systems Ltd. Method for extracting a computer network-based telephone session performed through a computer network
EP1634225A4 (de) * 2004-03-10 2008-01-16 Nice Systems Ltd Vorrichtung und verfahren zum erzeugen eines follow-up auf inhaltsbasis
US8094790B2 (en) 2005-05-18 2012-01-10 Mattersight Corporation Method and software for training a customer service representative by analysis of a telephonic interaction between a customer and a contact center
US8094803B2 (en) 2005-05-18 2012-01-10 Mattersight Corporation Method and system for analyzing separated voice data of a telephonic communication between a customer and a contact center by applying a psychological behavioral model thereto
US7995717B2 (en) 2005-05-18 2011-08-09 Mattersight Corporation Method and system for analyzing separated voice data of a telephonic communication between a customer and a contact center by applying a psychological behavioral model thereto
US7903568B2 (en) 2006-06-29 2011-03-08 Verint Americas Inc. Systems and methods for providing recording as a network service
EP2036264A4 (de) * 2006-06-29 2010-10-06 Verint Americas Inc Systeme und verfahren zur bereitstellung von aufzeichnung als einen netzwerkdienst
US8718262B2 (en) 2007-03-30 2014-05-06 Mattersight Corporation Method and system for automatically routing a telephonic communication base on analytic attributes associated with prior telephonic communication
US8023639B2 (en) 2007-03-30 2011-09-20 Mattersight Corporation Method and system determining the complexity of a telephonic communication received by a contact center
US7869586B2 (en) 2007-03-30 2011-01-11 Eloyalty Corporation Method and system for aggregating and analyzing data relating to a plurality of interactions between a customer and a contact center and generating business process analytics
US10419611B2 (en) 2007-09-28 2019-09-17 Mattersight Corporation System and methods for determining trends in electronic communications
US9258337B2 (en) * 2008-03-18 2016-02-09 Avaya Inc. Inclusion of web content in a virtual environment
WO2010012090A2 (en) 2008-07-28 2010-02-04 Digifonica (International) Limited Mobile gateway
EP2164232B1 (de) * 2008-09-10 2016-01-13 Axis AB Netzverbindungsvorrichtung
US8098851B2 (en) 2009-05-29 2012-01-17 Mathias Stieler Von Heydekampf User interface for network audio mixers
US8385566B2 (en) * 2009-05-29 2013-02-26 Mathias Stieler Von Heydekampf Decentralized audio mixing and recording
US8443075B2 (en) 2009-10-29 2013-05-14 Fluke Corporation Transaction storage determination via pattern matching
US9191510B2 (en) 2013-03-14 2015-11-17 Mattersight Corporation Methods and system for analyzing multichannel electronic communication data
CN109005466B (zh) * 2018-09-03 2020-07-10 视联动力信息技术股份有限公司 一种字幕显示方法和装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5136655A (en) * 1990-03-26 1992-08-04 Hewlett-Pacard Company Method and apparatus for indexing and retrieving audio-video data
CA2173355A1 (en) * 1993-06-09 1994-12-22 Andreas Richter Method and apparatus for multiple media digital communication system
US5664226A (en) * 1994-09-08 1997-09-02 International Business Machines Corporation System for merging plurality of atomic data elements into single synchronized file by assigning ouput rate to each channel in response to presentation time duration
WO1997041674A2 (en) * 1996-04-30 1997-11-06 3Com Corporation Packet filtering based on socket or application identification
US6170011B1 (en) * 1998-09-11 2001-01-02 Genesys Telecommunications Laboratories, Inc. Method and apparatus for determining and initiating interaction directionality within a multimedia communication center
WO1999044363A1 (en) * 1998-02-27 1999-09-02 Ridgeway Systems And Software Ltd. Audio-video packet synchronisation at network gateway
US6760748B1 (en) * 1999-01-20 2004-07-06 Accenture Llp Instructional system grouping student terminals
WO2000052916A1 (en) * 1999-03-05 2000-09-08 Gric Communications, Inc. Method and system for internet telephony using gateway
US6535920B1 (en) * 1999-04-06 2003-03-18 Microsoft Corporation Analyzing, indexing and seeking of streaming information

Also Published As

Publication number Publication date
EP1635534A2 (de) 2006-03-15
ATE314780T1 (de) 2006-01-15
EP1635535A2 (de) 2006-03-15
AU9220001A (en) 2002-04-02
ATE394865T1 (de) 2008-05-15
DE60133949D1 (de) 2008-06-19
WO2002025889A3 (en) 2002-08-15
EP1635534A3 (de) 2006-06-07
AU781291B2 (en) 2005-05-12
EP1635534B1 (de) 2008-05-07
HK1091620A1 (en) 2007-01-19
EP1635535A3 (de) 2006-06-07
DE60116341T2 (de) 2006-08-03
HK1058267A1 (en) 2004-05-07
JP2004509563A (ja) 2004-03-25
EP1319299A2 (de) 2003-06-18
EP1319299B2 (de) 2016-11-09
EP1319299B1 (de) 2005-12-28
WO2002025889A2 (en) 2002-03-28
ZA200202928B (en) 2002-12-18
DE60116341D1 (de) 2006-02-02

Similar Documents

Publication Publication Date Title
DE69925004T2 (de) Kommunikationsverwaltungssystem für computernetzwerkgestützte telefone
DE60116341T3 (de) Kommunikationsverwaltungsystem für computernetzbasierte telefone
US7581001B2 (en) Communication management system for computer network-based telephones
US7113992B1 (en) Decomposition architecture for an MCU
US7286652B1 (en) Four channel audio recording in a packet based network
DE69835762T2 (de) Netz für leitungsvermittelte Breitband-Mehrpunkt-Multimedia-Kommunikation
EP2036293B1 (de) Erweiterung des CSTA Protokolls zum vollständigen VoIP Protokoll
DE60314628T2 (de) Datenserver
DE60225457T2 (de) Aufgeteilter vermittlungsknoten und verfahren zu dessen betrieb
EP1949682A1 (de) Verfahren zum gatekeeper-streaming
DE10144356A1 (de) Verfahren zur Leitweglenkung von Datenpaketen
Lawson Cisco AVVID and IP Telephony Design and Implementation
DE102004003609B4 (de) Verfahren zum Mischen von Datenströmen
DE19741770C1 (de) Kommunikationssystem und entsprechendes Verfahren
Dumestre et al. Current and Future Capabilities of Desktop Videoconferencing (DVC)

Legal Events

Date Code Title Description
8363 Opposition against the patent