-
GEBIET DER
ERFINDUNG
-
Die
Erfindung bezieht sich auf das Gebiet von Mehrbenutzeranwendungen
in Systemen vernetzter Computer, und genauer auf ein Mehrbenutzer-Computersystem,
ein Verfahren und eine Anordnung, welche eine Multimedia-Rufsteuerung
verwenden, um Probleme eines Betriebes und einer Administration
von Mehrbenutzer- oder Echtzeit-Anwendungsprogrammen in Systemen
von vernetzten Computern zu verringern.
-
PROBLEMBEREICHE
-
In
Systemen mit vernetzten Computern ist es oft wünschenswert, es mehr als einem
Benutzer zu erlauben, mit einer einzelnen Anwendung zur selben Zeit
(gleichzeitig) zu interagieren. Solche Anwendungen werden oftmals
Mehrbenutzeranwendungen genannt. Bei jeder Mehrbenutzeranwendung
kann gesagt werden, dass sie zu einer der folgenden zwei Gruppen
gehört:
- 1) Mehrbenutzeranwendungen mit Echtzeit-Anforderungen; und
- 2) Mehrbenutzeranwendungen ohne Echtzeit-Anforderungen.
-
Typische
Beispiele von Anwendungen, welche zur ersten Gruppe gehören, sind
Multimediakonferenz-Anwendungen und Mehrspieler-Spiele, während ein Mehrbenutzer White
Boarding und Wortprozessoren mit Dokumenten-Mitbenutzung typische
Beispiele von Anwendungen sind, welche zur zweiten Gruppe gehören.
-
Wenn
es mehr als einem Benutzer ermöglicht
wird, mit derselben Anwendung zu interagieren, sind die Benutzer
typischerweise jeweils mit Teilen der Anwendung bereitgestellt,
welche im folgenden gesamt als Clients bezeichnet werden. Die Clients
kommunizieren dann mit den verbleibenden Teilen der Anwendung, welche
im folgenden insgesamt als Server bezeichnet werden. Der physikalische
Standort des Servers kann ein Computer sein, welcher mit einem der
teilnehmenden Clients gemeinsam benutzt wird, welches typischerweise
der Fall bei einer Wortprozessor-Mitbenutzung
und bei Spielen ist, oder er kann ein separater Computer sein, wie
beispielsweise ein zugewiesener Server-Computer. Eine Verwendung eines separaten
Computers ist allgemein üblich,
wenn die gemeinsam benutzte Anwendung mehr Ressourcen als am Standort
von jeglichen der Clients zur Verfügung steht benötigt.
-
Es
wird ein Protokoll zum Informationsaustausch zwischen Client und
Server verwendet. Obwohl mehrere Standardprotokolle vorliegen, werden
im allgemeinen maßgeschneiderte
Protokolle, welche für
jeden Typ von Anwendung optimiert sind, verwendet. Der Grund dafür ist, dass
jeder Typ von Anwendung seine eigenen, spezifischen Notwendigkeiten
hat. Eine typische, gemeinsam benutzte Echtzeit-Anwendung wird oftmals
eine Verwendung von kleinen Datenpaketen machen, um eine Übertragungsgeschwindigkeit
zu erhöhen,
während nicht-Echtzeit-Anwendungen
oftmals Verwendung von größeren Datenpaketen
machen, um die Nutzung einer Kommunikationskanal-Bandbreite für den Informationsaustausch
zu verringern.
-
Netzwerk-Spiele
können,
wie zuvor erwähnt,
typische Beispiele von Mehrbenutzeranwendungen mit Echtzeit-Anforderungen
sein. Bei Netzwerk-Spielen lässt
jeder Client einen Großteil
der Anwendung lokal laufen. Dies bedeutet, dass die Clients lediglich
eine Information an den Server über
die Positionen im Spiel und den derzeitigen Status ihrer jeweiligen
Spieler (der Informationstyp, wie nämlich gesendet und empfangen,
ist natürlich
vom Spieltyp abhängig)
senden. Der Server koordiniert und kombiniert dann die von allen
Clients empfangene Information und sendet eine koordinierte und
kombinierte Information zurück
an die jeweiligen Clients. Wenn lediglich eine geringe Anzahl von
Benutzern, beispielsweise weniger als 10, unterstützt wird,
dann ist der Server oftmals bei einem der Clients lokalisiert. Wenn
andererseits eine hohe Anzahl von gleichzeitigen Benutzern erlaubt
ist, dann wird die Notwendigkeit nach Computer-Ressourcen größer, und
die Server sind in solchen Fällen
oftmals einer separaten Hardware zugeteilt.
-
Wenn
in einem vernetzten System jede einer solchen Mitbenutzeranwendung
ihr eigenes Protokoll verwendet, stellt dies für den Administrator dieser
Protokolle ein wesentliches Problem dar, da es schwierig und manchmal
sogar unmöglich
für den
Administrator ist, eine gemeinsame Administration der unterstützten Mehrbenutzeranwendungen
durchzuführen.
In diesem Zusammenhang wird eine Administration bestimmt als:
- – Verfahren
zur Zugriffssteuerung darüber,
wem es erlaubt ist mit dem Server zu kommunizieren
- – Benutzungs-Spurprotokolle
- – Fehlerhandhabung
- – Administration
von Adressen und Benutzern
- – Jegliche
benötigte
Logik um eine Benutzer-Verrechnung (engl. user billing) der Verwendung
des Servers durchzuführen
- – Weitere
Administrationstypen
-
Ein
weiteres Problem, welches bei solchen Situationen anzutreffen ist,
liegt darin, es den unterschiedlichen Mehrbenutzeranwendungs-Protokollen
zu ermöglichen,
durch eine Firewall zu passieren. Dies ist besonders schwierig bei
Mehrbenutzeranwendungen mit Echtzeit-Anforderungen, weil solche
Anwendungen oftmals das User Datagram Protocol (UDP) als ein Transportprotokoll
verwenden. Aufgrund der verbindungslosen Natur von UDP ist es schwierig,
einem UDP basierten Verkehr ein Passieren durch eine Firewall zu
erlauben, und gleichzeitig einen guten Schutz durch die Firewall
zu erlangen.
-
Ein
weiteres Problem bezüglich
der Verwendung eines der standardisierten Rufsteuerungs-Protokolle bei
einer Mehrbenutzer-Serverkommunikation liegt darin, dass die vorliegenden
Mittel zum Transportieren von einer Information, obwohl sie keine
Sitzungseinleitende Information ist, bei aktuellen Lösungen auf
Codec's basieren,
welche für
Sprache, Video oder eine weitere nicht-Echtzeit Datenübertragung
optimiert sind. Zum Transport von Echtzeit-Daten sind diese Codec's nicht geeignet.
-
Ferner
wäre es
vorteilhaft, wenn alle Mehrbenutzeranwendungen, welche in einer
Domain arbeiten, das gleiche Kommunikationsprotokoll verwenden können. Wenn
sie alle eine Verwendung des gleichen Kommunikationsprotokolls machen,
können
Administrationsprobleme (beispielsweise Zugriffssteuerung, Spurprotokolle,
usw.) und Kommunikationsprobleme (beispielsweise das Ermöglichen
einer Kommunikation durch eine Firewall) beim gemeinsamen Protokoll
gelöst
werden, und somit durch alle Mehrbenutzeranwendungs-Server verwendet
werden.
-
BEKANNTE LÖSUNGEN UND
DEREN PROBLEME
-
Eine
vorgeschlagene Lösung
bezüglich
des Problems der Administration liegt in der Implementierung einer
separaten Administrations-Unterstützung von jedem Applikationstyp.
Das Hauptproblem bei diesem Verfahren ist erstens, dass die Administration
für jede
neu unterstützte
Mehrbenutzeranwendung einen neuen Satz von Administrations-Mechanismen
zu implementieren hat, und zweitens, dass der Administrator den
neuen Satz von Administrations-Mechanismen mit einer vorliegenden
Administration für
weitere Mehrbenutzeranwendungen zu integrieren hat.
-
Eine
weitere vorgeschlagene Lösung
bezüglich
des gleichen Problems liegt in der Unterstützung lediglich von Mehrbenutzeranwendungen,
welche ein standardisiertes Protokoll verwenden, wie beispielsweise das
Hyper-Text Transfer Protocol (HTTP). Dies führt jedoch zu weiteren Problemen,
da es eine Verwendung eines einzelnen Protokolls sehr schwierig
gestalten wird, Mehrbenutzeranwendungen im Netzwerk arbeiten zu lassen,
und zwar aufgrund ihrer unterschiedlichen Natur und ihrer unterschiedlichen
Ressourcen-Anforderungen.
-
AUFGABEN DER
ERFINDUNG
-
Es
ist daher eine Aufgabe der Erfindung, eine Lösung bezüglich der oben umrissenen Probleme
bereitzustellen, und welche die Probleme der bekannten Lösungen bewältigt.
-
KURZE BESCHREIBUNG
DER ERFINDUNG
-
Die
vorliegende Erfindung stellt ein System gemäss dem begleitenden unabhängigen Anspruch
1, ein Verfahren gemäss
dem begleitenden unabhängigen
Anspruch 9 und eine Anordnung gemäss dem begleitenden unabhängigen Anspruch
16 bereit. Weitere vorteilhafte Merkmale der Erfindung sind in den
begleitenden abhängigen
Ansprüchen
angegeben.
-
Die
vorliegende Erfindung schlägt
eine Lösung
vor, um das Problem bezüglich
einer Administration von unterschiedlichen Mehrbenutzeranwendungen
mittels dem H.323 Standard gemäss
der ITU-T Recommendation H.323, 02/98"Packet-based multimedia communications
system" zu lösen, welcher
der Standard ist, welcher zur Zeit am häufigsten bei Systemen verwendet
wird, welche einen Multimedia-Verkehr bereitstellen. Ein Aufbau
und eine Administration von Verbindungen zwischen Clients und ihren
jeweiligen Servern mittels H.323, stellen gemäß der Erfindung den Vorteil
bereit, dass ein System erlaubt wird, welches Applikationsspezifische
Protokolle, als auch ein allgemeines Standard Protokoll, nämlich das
H.323, enthält.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
1 ist
eine Blockdiagramm-Darstellung eines vereinfachten H.323 Netzwerk-Beispiels,
welche eine Client-Registrierung und -Autorisierung darstellt.
-
2 ist
eine Blockdiagramm-Darstellung eines vereinfachten H.323 Netzwerkes,
welche einen Setup eines H.323 Client-zu-Server Netzwerkrufs und erweiterte Funktionen
darstellt.
-
3 ist
eine Blockdiagramm-Darstellung eines vereinfachten H.323 Netzwerkes,
welche einen Client-Server Informationsaustausch gemäss der Erfindung
durch eine Firewall darstellt.
-
4 ist
eine schematische Darstellung von einer Ausführungsform einer Benutzerdaten-Paketstruktur
der Erfindung.
-
5 ist
eine schematische Darstellung von einer Ausführungsform einer Steuerdaten-Paketstruktur der
Erfindung.
-
6 ist
ein Sequenzdiagramm, welches ein Beispiel eines Informationsaustausches
zwischen einem Server und einem Client in einer beispielhaften Ausführungsform
von einer Lösung
gemäß der Erfindung
darstellt.
-
7 ist
ein Sequenzdiagramm, welches ein Beispiel eines Informationsaustausches
zwischen einem Server und einem Client in einer weiteren beispielhaften
Ausführungsform
von einer Lösung
gemäss
der Erfindung darstellt.
-
GENAUE BESCHREIBUNG
DER AUSFÜHRUNGSFORMEN
-
Im
folgenden wird die vorliegende Erfindung mittels Beispiel und mit
Bezug auf die begleitenden Zeichnungen beschrieben.
-
Bezugnehmend
auf 1 wird, wenn der Client gestartet wird, dieser
zunächst
einen bekannten Registrierungsprozess von einer H.323 Version 2
verwenden, welche im Netzwerk zu registrieren und autorisieren ist.
Es sollte ebenfalls erwähnt
werden, dass der Server in der in 1 dargestellten
Situation bereits im H.323 Netzwerk registriert ist. Wenn H.323
verwendet wird, müssen
die Client-Seite der Anwendung und die Server-Seite der Anwendung
beide den H.323 Stapel unterstützen.
Ferner, um einen vollständigen
Service zu haben, muss der Server die gesamte Zeit laufen. Durch
den Registrierungsprozess wird der Benutzer autorisiert (eine Autorisierung
ist in der Version 2 von H.323 neu). Dies bedeutet, dass der Bediener
entscheiden kann, wem ein Kontakt zum Server erlaubt ist. Bis zu
diesem Punkt sind Vereinbarungen und Interaktionen im Netzwerk gemäss den bekannten
Schritten des H.323 Version 2.
-
Nun
wird, bezugnehmend auf 2, wenn der Client einen Ruf
mit dem Spiele-Server als Ziel einleitet, der Gatekeeper das Benutzer-Profil überprüfen, welches
von einer User Handling Database (UHD) empfangen wird, um zu sehen,
ob es dem Benutzer erlaubt ist den Spiele-Server zu benutzen, welches
in 1 durch Spiele-Server Info gekennzeichnet ist.
Um diese Daten zu ergreifen und die Auswertung durchzuführen, wird einem
normalen H.323 Gatekeeper eine neue Funktionalität hinzugefügt. Wenn herausgefunden wird,
dass es dem Benutzer erlaubt ist den Spiele-Server zu "rufen", informiert der
Gatekeeper dann den Client, dass es ihm erlaubt ist, den Ruf-Aufbau vorzunehmen,
wie dies typischerweise gemäss
H.323 vorgenommen wird.
-
Dann
startet der Client den Datenkanal von H.323 zum Server. Dies ist
gemäss
H.323 erlaubt, obwohl dies für
gewöhnlich
nicht auf diese Weise vorgenommen wird, da die Prozedur, welche
für gewöhnlich verwendet
wird, beim Starten von Sprach- und
Video-Kanälen
liegt. Gemäss
der Erfindung wird das H.323 Protokoll erweitert, um einen neuen
Codec zu unterstützen.
Dies wird im folgenden gezeigt:
Aus Gründen der Vereinfachung der
Erläuterung
von der Lösung
der Erfindung mittel Beispiel, werden im folgenden H.323 und H.323
Namen und Bezeichnungen umfassend verwendet. Ein Codec, welcher
auf eine Echtzeit-Datenübertragung
spezialisiert ist, muss entwickelt werden. In H.323 muss der neue
Codec in der ASN.1 Syntax wie im folgenden beschrieben identifiziert
werden:
-
Diese
Basis für
den ASN.1 Code, wie oben gezeigt, ist in ITU-T Recommendation H.245,
02/98"Control Protocol
for Multimedia Communication" beschrieben.
Der obige Code, welcher ein geänderter
Code ist, welcher auf Lösungen
gemäss
H.245 anwendbar ist, zeigt an, wie das Daten-Anwendungsfeld des H.245
Protokolls erweitert wird, um die Erfindung unterzubringen. Bei
einem System, welches gemäss
der Erfindung arbeitet, ist eine solche Adaption von H.245 in allen
Clients, Servern und Gatekeepern enthalten, welche dazu registrierte
Spiele-Server haben (wenn der Gatekeeper H.245 weiterleitet). In
diesem Zusammenhang ist der bestimmte Name des neuen Codec nicht
relevant, lediglich dass es ein neuer ist. Jegliche Anforderungen
für mehr
als einen neuen Codec in einem bestimmten System werden von den
Anforderungen abhängen,
welche für
die Kommunikation zwischen dem Client und den unterschiedlichen
Typen von Spiele-Servern bestimmt sind. Was daher wichtig ist, ist,
dass ein Spiele-Server und alle seine verbundenen Clients eine Unterstützung für denselben
Codec-Typ bereitstellen müssen.
-
Der
neue Codec ist auf eine einfache Weise entworfen, was bedeutet,
dass er einen geringen Overhead erfordert.
-
Im
folgenden werden einige der Eigenschaften des neuen Codec angegeben:
- – Der
Codec verwendet RTP (Real-time transport Protocol) über UDP
(User Datagram Protocol), um einen Echtzeit-Transport zu erlangen.
- – Der
Codec enthält
hauptsächlich
zwei Typen von Meldungen: a) eine Daten-Meldung, und b) eine Steuer-Meldung.
- – Die
Daten-Meldung kann vom Client oder vom Server ausgesendet werden.
Die Steuer-Meldung wird lediglich vom Server ausgesendet.
-
Bezugnehmend
auf 4 wird nun ein Beispiel eines Datenpakets des
neuen Codec's erläutert:
- – Im
Typ-Feld ist eine Kennung, welche den Typ von Meldung bestimmt (beispielsweise
1 = Daten-Meldung, 2 = Steuer-Meldung),
welche in diesem Fall eine Daten-Meldung ist.
- – Im
Protokoll-Feld ist eine Kennung, welche bestimmt, wie die Daten
im Rest der Meldung interpretiert werden sollen. Es ist hier zu
bemerken, dass ein allgemeines Verständnis des Daten-Formats unter dem
Client und Server vorliegt.
- – Im
Daten-Feld sind die Daten enthalten, welche vom Client oder vom
Server gesendet werden.
-
Bezugnehmend
nun auf 5 wird ein Beispiel eines Steuer-Pakets des neuen
Codec's erläutert:
- – Im
Typ-Feld ist eine Kennung, welche den Typ von Meldung bestimmt (beispielsweise
1 = Daten-Meldung, 2 = Steuer-Meldung),
welche in diesem Fall eine Steuer-Meldung ist.
- – Im
Protokoll-Feld ist eine Kennung, welche bestimmt, wie die Steuer-Information
im Rest der Meldung interpretiert werden soll. Es ist hier zu bemerken,
dass ein allgemeines Verständnis
des Steuer-Formats unter dem Client und dem Server vorliegt.
- – Im
Daten-Feld ist die Steuer-Information enthalten, welche vom Server
an die Clients gesendet wird. Beispiele von einer Steuer-Information
sind, wie oft Daten-Meldungen vom Client zum Server gesendet werden sollen,
und wie oft der Server Daten-Meldungen zum Client senden wird.
-
Es
ist zu bemerken, dass Zeitstempel und Sequenznummern nicht Teil
der Codec-Meldungen sind, weil diese Information typischerweise
vom RTP Header erlangt werden kann.
-
Nun
wird mit Bezug auf die begleitenden 6 und 7 und
mittels Beispiel ein Informationsaustausch in einem Client-Server Aufbau in
einer Ausführungsform
der Erfindung erläutert.
Die bezüglichen 6 und 7 zeigen
im allgemeinen Beispiele der Kommunikationssequenz zwischen einem
Client und einem Server. In den gezeigten Sequenzbeispielen gibt
es einige allgemeine Schritte. Der Client leitet die Kommunikation
ein, indem er eine "Setup" Meldung gemäss dem Standard
Rufsteuerungs-Protokoll, welches ausgewählt wurde, sendet, d.h., im
allgemeinen H.323 oder SIP. Dann signalisiert der Server eine Akzeptanz
des eingehenden "Setup", indem eine Akzeptanz-Meldung
gemäss
dem ausgewählten
Rufsteuerungs-Protokoll gesendet
wird. Der Rufsteuerungs-Teil des Client sendet dann einen vorgeschlagenen
Mediensatz und eine Adresse, welche den neuen Codec enthält. Ferner,
wie im Beispiel gezeigt, wird der vorgeschlagene Mediensatz durch
den Server akzeptiert, und zwar durch eine Meldung, welche ebenfalls
die Medien-Zieladresse enthält,
an welche der Client die Medien zu senden hat. An diesem Punkt der
Sequenz stehen zwei Möglichkeiten zur
Verfügung.
Eine Möglichkeit
ist, dass die Aderesse von der Rufsteuerung zum Anwendungs-Teil,
sowohl im Server als auch im Client, gesendet wird, wobei es in
diesem Fall die Anwendung am Client ist, welche die Medien unter
Verwendung des neuen Codec direkt an die Anwendung am Server sendet.
Diese erste Möglichkeit
ist durch die weiteren Teile der in 6 gezeigten
Sequenz dargestellt. Die weitere Möglichkeit ist, dass die Rufsteuerung
sowohl am Server als auch am Client eine "Start" Meldung oder eine ähnliche Art von Information
sendet, welche anzeigt, dass eine Kommunikation nun zwischen dem
Server und dem Client aufgebaut ist. In diesem letzten Fall, werden
Medien, welche im neuen Codec gesendet werden, zunächst von
der Anwendung zur Rufsteuerung und dann von der Rufsteuerung an
einer Seite über
die weitere Rufsteuerung und dann zur Anwendung übertragen. Diese weitere Möglichkeit
ist durch die weiteren Teile der in 6 gezeigten Sequenz
dargestellt. Am Abschluss von einer Sitzung sendet der Client eine "Beenden" Meldung. Jedoch
kann eine Beendigung ebenfalls durch den Server eingeleitet werden.
Die Dateneinheit, welche die "Beenden" Meldung empfängt, informiert
die Anwendung darüber,
dass die Sitzung vorbei ist, und antwortet auf die "Beenden" Meldung, indem eine "Akzeptieren" Meldung zurückgesendet
wird.
-
Nun
werden mit Bezug auf 4, 5, 6 und 7 die
Meldungs-Typen und
ihre Verwendung mittels Beispiel erläutert. Gemäss einer wie oben beschriebenen
Sequenz kann der Server zunächst
eine Steuer-Meldung senden, welche eine Information, welche die
Rate spezifiziert, bei welcher Daten vom Client zum Server zu senden
sind, und möglicherweise
ebenfalls eine Information über
den Datentyp enthält.
Wiederum sendet der Client Daten an den Server bei der spezifizierten
Rate und vom spezifizierten Typ, und zwar gemäss dem in der Steuer-Meldung
spezifizierten Schema. Solche Steuer-Meldungen können jederzeit während einer
Sitzung gesendet werden, damit der Server unterschiedliche Datenraten
und Datentypen gemäss den
Notwendigkeiten der mit der Sitzung in Zusammenhang stehenden Anwendung
spezifizieren kann.
-
Mit
Bezug auf die oben erläuterten
Sequenzen, sollte erwähnt
werden, dass die in 6 und 7 dargestellten
unterschiedlichen Möglichkeiten
ebenfalls gemischt oder zusammengefasst werden können, und zwar auf eine solche
Weise, dass entweder die Server-Partei oder die Client-Partei einer
der Sequenzen folgt, während
die weitere Partei der weiteren Sequenz folgt.
-
In
H.323 Netzwerken mit Gatekeepern muss jegliche Signalisierung durch
den Gatekeeper gehen. Wenn der Gatekeeper einen Setup und einen
Betrieb eines Rufes erlaubt, kann er gemäss der bekannten H.323 Architektur
und Implementierungen das normale Verrechnungssystem über die
begonnene Verwendung informieren. Ein Verrechnungssystem kann einem
System, wie beispielsweise dass in 1 dargestellte System,
auf eine Anzahl von unterschiedlichen Weisen hinzugefügt werden.
Eine einfache und wirksame Weise darüber, eine Verrechnung unterzubringen,
ist, dass der Gatekeeper eine Information bezüglich einem Ruf-Setup und einer
Beendigung an eine ASCII-Datei
schreibt. Ein Programm kann diese Datei auf manuelle oder automatische
Weise an einer späteren
Zeitstufe verarbeiten. Eine weiter fortgeschrittene Lösung liegt
darin, Call Detail Records (CDR) an ein externes System zu senden.
CDRs können
eine Information über
eine Ruf-Startzeit, eine Ruf-Stoppzeit, eine Aktivität, verwendete
Ressourcen, usw. enthalten. Das externe System kann dann derart
erstellt sein, dass es automatisch jene Aufzeichnungen interpretiert
und Benutzungskosten (Abrechnung) direkt für den Endbenutzer erzeugt.
-
Ferner,
wie in 6 und 7 dargestellt, und zwar in Zusammenhang
mit den mit Bezug auf 4 und 5 beschriebenen
Meldungen gesehen, informiert der Client beim Aufbau des Datenkanals
den Server darüber,
welches Protokoll für
die Datenkommunikation zu verwendet ist. Bei einem System gemäss der Erfindung,
hat dies der wie oben beschriebene neue Codec zu sein. Dies bedeutet,
dass die Anwendungen selber, welches Protokoll auch immer sie wünschen,
verwenden können,
solange es im neuen Codec-Typ abgebildet ist. Während der H.323 Setup-Phase,
informieren sowohl der Client als auch der Server sich gegeneinander über Anschlüsse, auf
welchen sie Daten zu empfangen wünschen,
und darüber,
welches Transport-Protokoll zu
verwenden ist, beispielsweise ob sie TCP (Transmission Control Protocol)
oder UDP (User Datagram Protocol) verwenden. Diese Information kann
ferner durch einen H.323 Proxy verwendet werden, um zu erlauben, dass
das ausgewählte
Daten-Protokoll durch eine Firewall übertragen wird, wie in 3 dargestellt.
Wenn ein H.323 Proxy verwendet wird, wird er ebenfalls mit dem verbesserten
H.323 Protokoll aktualisiert.
-
Bezugnehmend
auf 3 ist ein Beispiel gezeigt, bei welchem zwei Clients
mit dem Server kommunizieren. Sie verwenden beide direkt das H.323
Protokoll, welches über
den Gatekeeper gesendet wird, und das ausgewählte Daten-Protokoll. Wenn
der Datenkanal aufgebaut ist, informiert der Client den Server darüber, welches
Protokoll für
die Datenkommunikation zu verwenden ist. Dies bedeutet, dass die
Anwendungen jegliches bevorzugtes Protokoll verwenden können. In 3 ist
eine Firewall ebenfalls zusammen mit einem H.323 Proxy gezeigt.
Die Veranlassung dafür,
die Proxy-Funktionalität
einzuschließen,
hat zwei Gründe.
Zunächst
ist es recht üblich,
bei jedem Unternehmen eine Firewall und ein ISP zu haben, um seinen
jeweiligen Bereich zu schützen.
Zweitens wird oftmals NAT (Network Address Translation) von Unternehmen
verwendet, um eine einzelne IP-Adresse gemeinsam zu nutzen, und
um keine Information über
eine IP-Adresse für
Knoten preiszugeben, welche sich innerhalb der Domain des Unternehmens
befinden. Der H.323 enthält
keine Unterstützung
für NAT
und Proxys in sich selber, jedoch erleichtert die IPT Lösung unter
Verwendung des H.323 Proxys die Beschränkungen des H.323 v2 Standards
bezüglich
der Kommunikation mit Endpunkten, welche sich hinter Firewalls befinden.
-
Gemäss dem obigen,
enthält
der H.323 Proxy die folgenden Funktionen:
- – Das H.323
vertritt (engl. proxies) die RAS Signalisierung (Registrierung und
Durchlass) und ersetzt die internen IP-Adressen des Unternehmens in den RAS
Meldungen durch öffentliche
IP-Adressen (NAT-Network Address Translation).
- – Das
H.323 vertritt die Q.931 Signalisierung (Ruf-Setup) und ersetzt
die internen IP-Adressen des Unternehmens in der Q.931 Meldung durch öffentliche
IP-Adressen.
- – Das
H.323 vertritt die H.245 Signalisierung (Medienkanal-Setup) und ersetzt
die interne IP-Adresse des Unternehmens in den H.245 Meldungen durch öffentliche
IP-Adressen. Wenn der Endpunkt das H.245 in einem separaten Kanal
verwendet, wandelt der H.323 Proxy dies zu einem getunnelten H.245
um, da das IPT System stets ein getunneltes H.245 verwendet.
- – Der
H.323 Proxy steuert die Medienströme, welche resultierend aus
der H.245 Signalisierung aufgebaut sind, und vertritt die Medienströme (Medienstrom
NAT).
-
Anhand
des oben beschriebenen Beispiels, und wie in 3 dargestellt,
sollte erwähnt
werden, dass das ausgewählte
Datenprotokoll durch eine Firewall gesendet werden kann, wenn ein
H.323 Proxy verwendet wird.
-
Der
Ablauf einer Authentifizierung eines H.323 Endnutzers in H.323 Systemen
ist in H.323 spezifiziert. Jedoch ist es lediglich spezifiziert,
wie der Nutzername und das Passwort von einem Endnutzer zum Gatekeeper
gesendet werden können.
Um eine wahre Authentifizierung zu erlangen, muss ein Mittel zur
Gegenüberprüfung des
Nutzernamens mit dem Passwort zum System hinzugefügt werden.
Eine Art und Weise, wie eine Durchführung dieser Überprüfung erlaubt
wird, ist, wie in den begleitenden 1, 2 und 3 dargestellt, eine
Hinzufügung
einer Datenbank zum Gatekeeper. Diese Datenbank wird zumindest eine
Aufzeichnung für jeden
Nutzer enthalten, welche einen Nutzernamen und ein Passwort enthält. Der
Gatekeeper wird dann überprüfen, ob
der Endnutzer in der Datenbank vorliegt. Wenn der Endnutzer in der
Datenbank vorliegt, erlangt der Gatekeeper dann das Passwort des
Nutzers und überprüft, ob es mit
dem Passwort übereinstimmt,
welches durch den Endnutzer empfangen ist. Die Datenbank und ihre
zugehörige
Logik werden bei dieser Lösung
als Nutzer-Handhabung (User-Handling) bezeichnet. Die Daten, welche
bestimmen, ob es dem Nutzer erlaubt ist einen Ruf zu tätigen, können der
Nutzer-Aufzeichnung
hinzugefügt
werden, welche für
jeden Nutzer in der oben beschriebenen Datenbank gespeichert ist.
-
Während der
H.323 Setup-Phase informieren sich der Client und der Server ebenfalls
beide untereinander darüber,
auf welchen Anschlüssen
sie einen Empfang von Daten erwünschen,
und ob sie das Transmission Control Protocol (TCP) oder das UDP
verwenden. Diese Information kann durch einen H.323 Proxy verwendet
werden, um es zu ermöglichen,
dass das ausgewählte
Datenprotokoll durch eine Firewall übertragen wird.
-
Wenn
die Setup-Phase vorüber
ist, verwenden der jeweilige Client und Server das ausgewählte Protokoll,
welches für
ihre Notwendigkeiten optimiert ist, um Daten zueinander zu übertragen.
-
Wenn
die Sitzung vorüber
ist, beendet der Client die Verbindungen und informiert den Gatekeeper.
Der Gatekeeper informiert dann das Verrechnungssystem darüber, dass
die Benutzung des Servers beendet wurde. Wenn ein Client außer Funktion
kommen sollte oder ein Netzwerkfehler auftreten sollte, kann das
System dies dann ebenfalls erfassen, weil das H.323 regelmäßige Aktualisierungen
des Status vom "Ruf" erfordert. Eine
korrekte Aufzeichnung einer Benutzungszeit wird daher garantiert.
-
Obwohl
lediglich ein einfaches H.323 Netzwerk in den 1, 2 und 3 gezeigt
ist, um die Zeichnungen aus Gründen
der Erläuterung
der Erfindung zu vereinfachen, wird die durch die vorliegende Erfindung
bereitgestellte Lösung
ebenfalls in H.323 Netzwerken im großem Umfang oder in Netzwerken
arbeiten, welche eine Architektur und/oder einen Betrieb gemäss ähnlichen
Rufsteuerungs-Protokollen haben, wie beispielsweise das SIP Protokoll.
-
VORTEILE
-
Unter
Verwendung von H.323 können
die Anwendungen einfach durch Sprache und Video integriert werden,
wenn sie nicht bereits diese Unterstützung haben. Dies wird einer
bestimmten Anwendung eine neue Dimension bereitstellen, und zwar
ohne die Notwendigkeit große Änderungen
vorzunehmen, welche die Anwendung ansonsten erfordert.
-
Wenn
das H.323 verwendet wird, braucht der Client nicht die IP (Internet
Protocol)-Adresse des Servers zu kennen, da das H.323 mehrere fortgeschrittene
Adress-Schemata unterstützt,
wie E-164 Nummern, e-mail Adressen oder Pseudonyme.
-
ABKÜRZUNGEN,
DEFINITIONEN UND AKRONYME
-
-
