-
Gebiet der Erfindung
-
Die
Erfindung bezieht sich auf Telekonferenzsysteme.
-
Erörterung des Standes der Technik
-
Telekonferenzsysteme
sind seit vielen Jahren erhältlich.
Typischerweise umfasst ein System eine Telefonleitungsvermittlungs-
oder -routingeinheit, die eine „Brücke" genannt wird. Es gibt typischerweise
auch eine Agentkonsole zum Planen von Anrufen und zur Abwicklung
anderer administrativer Funktionen. Sowohl lokale als auch ferne
Konferenzteilnehmer können
an einer Konferenz teilnehmen, indem sie sich in die designierte
Nummer einwählen und
einen erforderlichen Sicherheitscode eingeben.
-
Die
Anordnung hat unter vielen Umständen gut
funktioniert. Ein Beispiel ist ein System, das auf einer von Spectel-Multilink
unter dem Namen „C7000TM" vermarkteten
Brücke
basiert. Jedoch erlegen die vorhergehenden Systeme aufgrund ihrer
beschränkten
Kapazität
unter manchen Umständen
unzufriedenstellende Beschränkungen
auf. Zum Beispiel kann eine bestimmte multinationale Firma eine Situation
haben, bei der in Europa befindliche Systeme an einem Tag zu wenig
genutzt werden, an dem ihre Systeme in den USA nicht in der Lage
sind, den Bedarf zu bewältigen.
-
US5995608 beschreibt zum
Beispiel ein On-Demand-Telekonferenzsystem, das einen Brückenserver
aufweist. Blum et al, "A
development and runtime platform for teleconferencing applications", IEEE Journal on
Selected Areas in Communication, IEEE Inc. New York, US, Bd. 15
Nr. 3, 1. April 1997, S. 576–588
ff., beschreibt Peer-to-Peer-Kommunikation
zwischen Partnersystemen.
-
Die
Erfindung ist daher darauf gerichtet, für effizientere Nutzung von
Telekonferenzeinrichtungen und größere Flexibilität zu sorgen,
um den Bedarf zu Spitzenzeiten an jedem einer Anzahl ferner Orte
abzudecken.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Gemäß der Erfindung
wird ein Telekonferenzsystem bereitgestellt, wie es in Anspruch
1 dargelegt ist.
-
In
einer Ausführungsform
umfasst die Brücke
Mittel zum Herstellen der Verbindung als Linkleitung in einem Telekommunikationssprechnetz.
-
In
einer Ausführungsform
umfasst die Multi-site-Engine Mittel zum Kommunizieren mit der fernen
Multi-site-Engine mit einem Paketprotokoll.
-
In
einer Ausführungsform
ist das Paketprotokoll TCP/IP.
-
In
einer weiteren Ausführungsform
umfasst das System des weiteren eine lokale Maschine, die mit der
Brücke
assoziiert ist und sich zwischen der Brücke und der Multi-site-Engine befindet.
-
In
einer Ausführungsform
umfasst das System eine Mehrzahl von Brücken und eine lokale Maschine,
die mit jeder Brücke
assoziiert ist.
-
In
einer weiteren Ausführungsform
umfasst die Multi-site-Engine Mittel zum Übertragen von Steuersignalen
auf eine asynchrone eventgesteuerte Weise und zum Empfangen solcher
Steuersignale von einer fernen Multi-site-Engine.
-
In
einer Ausführungsform
umfasst das System Mittel zum Kategorisieren jedes Events mit einem
Eventtyp, und die Multi-site-Engine umfasst Mittel zum Aktualisieren
einer Konfigurationsdatei und zum Fällen einer Entscheidung über eine
Weiterleitung eines Signals zu der lokalen Maschine je nach dem
Eventtyp des Steuersignals.
-
In
einer Ausführungsform
umfasst die Multi-site-Engine Mittel zum Abfragen einer Multi-site-Engine
eines Fernsystems, wenn eine Zeitperiode ohne ein asynchrones Event
verstreicht.
-
In
einer Ausführungsform
umfasst die Agentkonsole Mittel zum Schreiben eines globalen Flag
an eine Brückendatenbank,
um die Planung einer örtlich verteilten
Konferenz anzuzeigen, und das System umfasst eine Brückenstatusfunktion,
die Mittel zum automatischen Übertragen
eines Steuersignals zu einer Multi-site-Engine eines Fernsystems
umfasst, das die Herstellung einer Linkleitung zwischen Brücken der
Systeme anfordert.
-
In
einer weiteren Ausführungsform
umfasst jede Datenbank Mittel zum Einleiten von Events vor und nach
einer Konferenz zur Synchronisation mit einer Brückendatenbank eines an einer
Konferenz teilnehmenden Fernsystems.
-
In
einer Ausführungsform
umfasst das System eine Local-Engine-Layer, eine Multi-site-Engine-Layer
und eine Bridge-Layer, wobei jede Layer Folgendes umfasst:
ein
Statuskommunikationsobjekt, das Mittel zum Horchen auf Statusänderungsevents
umfasst,
einen Statuscontainer, der Mittel zum Führen von
Listen von Zustandsobjekten umfasst, die den Status der Konferenz
definieren,
und ein Policy-Objekt, das Mittel zum Assistieren
bei der Schöpfung
und Zerstörung
anderer Objekte in dem System umfasst.
-
In
einer Ausführungsform
umfasst der Statuscontainer Mittel zum Assoziieren einer Sequenznummer
mit jedem Zustand.
-
Gemäß einem
weiteren Aspekt der Erfindung wird ein Telekonferenzverfahren zwischen
Konferenzteilnehmern an einer Mehrzahl von fernen Konferenzteilnehmerorten
durch ein Telekonferenzsystem bereitgestellt, das eine Telekonferenzbrücke zum
Handhaben von Kommunikationsleitungen und mit einer Brückendatenbank
und einer Multi-site-Engine umfasst, wobei das Verfahren die folgenden Schritte
umfasst:
Herstellen, mittels einer Agentkonsole, einer Schnittstelle
mit der Brücke
und der Brückendatenbank
zum Planen von Konferenzen;
Kommunizieren, mittels der Multi-site-Engine,
mit einer Multi-site-Engine eines fernen Telekonferenzsystems zum Übertragen
von Steuersignalen in Echtzeit für
einen gleichzeitigen Betrieb von wenigstens zwei Telekonferenzsystemen
zum Handhaben einer einzelnen Konferenz;
Herstellen einer Verbindung,
mittels der Brücke,
mit einer Brücke
eines ortsfernen Telekonferenzsystems für einen synchronen Betrieb
der Brücken,
so dass alle Telekonferenzsysteme als ein logisches System arbeiten.
-
DETAILLIERTE BESCHREIBUNG
DER ERFINDUNG
-
Kurze Beschreibung der
Zeichnungen
-
Man
wird die Erfindung deutlicher anhand der folgenden Beschreibung
einiger ihrer Ausführungsformen
verstehen, die nur beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen
angegeben werden, in denen:
-
1 ein
Diagramm ist, das die Architektur zweier Telekonferenzsysteme der
Erfindung illustriert.
-
Bezugnehmend
auf 1 sind zwei Telekonferenzsysteme 1 und 2 illustriert.
Jedes System 1 und 2 kann als ein Multi-site-Telekonferenzsystem bezeichnet
werden, da es in der Lage ist, mit einem anderen System an einem
fernen Ort eine Verbindung herzustellen, so dass Ressourcen effektiv
zusammengefasst und dynamisch in einer vielseitigen Weise konfiguriert
werden, um den Bedarf zu abzudecken.
-
Das
System 1 umfasst drei Brücken 5, 6 und 7,
wobei jede mit einer jeweils assoziierten Datenbank 8, 9 und 10 verbunden
ist. Die Brücken 5, 6 und 7 sind
an ein 10/100 EthernetTM LAN 15 angeschlossen.
Eine Agentkonsole 16 ist ebenfalls an das LAN 15 angeschlossen.
Schließlich
umfasst das System 1 ebenso einen Server 20, der
eine Multi-site-Engine 21 und
drei lokale Maschinen 22 aufweist, wobei jede mit einer
der Brücken 5, 6 und 7 assoziiert
ist.
-
Die
Brücken 5, 6 und 7 sind
durch Verkabelung 30 an ein öffentliches TK-Netz 31 angeschlossen.
Der Server 20 ist für
TCP/IP-Kommunikation über
ein Netzwerk 36 konfiguriert.
-
Das
System 2 weist dieselbe allgemeine Konfiguration wie das
System 1 auf, jedoch gibt es in diesem Fall nur eine Brücke. Ein
Server 40 weist eine Multi-site-Engine und eine einzelne
lokale Maschine, die mit der Brücke 41 assoziiert
ist, die eine Datenbank 42 aufweist, auf. Die Brücke 41 ist
durch Verkabelung 45 an das öffentliche TK-Netz 31 angeschlossen.
Schließlich
umfasst das System 2 eine Agentkonsole 46.
-
Diese
beiden Systeme werden nur beispielhaft angegeben. Allgemein kann
ein System der Erfindung jede Anzahl an Brücken, eine lokale Maschine,
die mit jeder Brücke
assoziiert ist und eine einzelne Multi-site-Engine aufweisen. Die
Maschinen können,
abhängig
von der notwendigen Verarbeitungskapazität, auf jeder geeigneten Anzahl
von Hardware-Computern gehostet sein.
-
Man
wird aus dem Obigen ersehen, das es zwei Arten der Kommunikation
zwischen Systemen gibt, nämlich:
- (a) das öffentliche
TK-Netz 31 für
Kommunikation von Brücke
zu Brücke
während
einer Konferenz, und
- (b) das TCP/IP-Netzwerk 36 (typischerweise das Internet)
für die
Steuersignalgebung zwischen den Multi-site-Engines in Echtzeit.
-
Um
eine Konferenz aufzubauen, werden die Agentkonsolen 16 und 46 verwendet,
um Schnittstellen mit den Brücken
und deren Datenbanken herzustellen, um die Konferenz zu planen.
Das Planen vergibt eine passende Anzahl von Konferenzen an jedes System 1 und 2,
je nach deren Kapazitäten.
Planen kann nur ein System für
eine Konferenz benötigen, und
in dem Fall läuft
die Konferenz in einer herkömmlichen
Art ab.
-
Wird
jedoch ein Befehl "Global" an einer Konsole 16 oder 46 eingegeben,
wird ein Flag an eine Brückendatenbank
geschrieben. Dieses Flag zeigt an, dass es eine Synchronisation
zwischen allen Datenbanken für
die beiden (oder mehr) beteiligten Systeme geben muss. Die Multi-site
Engine (MSE) des ersten Systems sendet einen TCP/IP-Befehl an die
MSE des anderen Systems. Als Reaktion weist jede lokale Maschine
des anderen System seine Brücke
an, eine Leitung zu den Brücken
des ersten Systems über
das öffentliche
TK-Netz 31 zu öffnen. Von
nun an wird diese Linkleitung dazu verwendet, die Kommunikationen
zwischen den Systemen 1 und 2 für Sprechverkehr
bei einem Konferenzanruf aufrecht zu erhalten.
-
Sobald
die Konferenz beginnt, führen
die lokale Maschine und die MSEs Echtzeitsteuersignalisierung durch,
um sicherzustellen, dass alle teilnehmenden Standorte synchronisiert
sind, um als ein logisches System zu funktionieren.
-
Die
Synchronisation wird sowohl asynchron eventgesteuert, wie auch durch
Abfragen synchron aufrechterhalten. Für das erstere veranlasst jedes auftretende
Event, wie etwa eine Eingabe eines Anfrage-MFV-Tons durch einen
Konferenzteilnehmer, die entsprechende Brücke ihre lokale Maschine zu
informieren, die wiederum ihre MSE informiert. Die MSE wiederum
sendet über
TCP/IP das Event an die ferne MSE, die die lokale Maschine informiert,
die ihre Brücke
informiert. Diese Signale werden durch die MSEs verwendet, um die
assoziierten Konfigurationsdateien zu aktualisieren. Die Aktualisierungssignale
werden in Echtzeit generiert, und somit werden die Konfigurationsdateien
synchron gehalten. Es gibt verschiedene Eventtypen. Manche Typen
benötigen, dass
das Aktualisierungssignal nicht weiter als bis zur empfangenden
MSE geht, andere benötigen,
das es bis zu den fernen Brücken
geht.
-
Die
synchronen Events treten nach dem Verstreichen einer Zeitperiod,
in der keine asynchronen Events auftreten, auf. Auf das Verstreichen
hin fragt eine der MSEs automatisch die andere MSE ab, um den Status
zu bestimmen und ihre Konfigurationsdatei mit diesem Status zu aktualisieren.
-
Die
gesamte Steuersignalisierung läuft
zwischen den MSEs ab und wird komplett über TCP/IP übertragen. Die Paketgrößen werden
so klein wie möglich
gehalten, um die Bandbreitenanforderungen zu minimieren.
-
Des
Weiteren hält
während
der Konferenz jede Brücke
Anrufdetaildaten in ihrer Datenbank fest. Am Ende der Konferenz überträgt jede
Brücke
Anrufdetailaufzeichnungen (call detail records, CDRs) an die anderen
Brücken,
so dass jede einzelne Datenbank alle CDRs für die Konferenz hat und die
Datenbanken komplett synchron sind. Somit kann jede einzelne Brücke zur
Erzeugung der notwendigen Abrechnungen und anderer Berichte verwendet
werden.
-
Genauer
unterstützt
eine Planfunktion einer Konsole die Planung auf multiplen Systemen
und versieht den Agenten mit der Fähigkeit, eine Konferenz auf
einer einzelnen Brücke
oder auf multiplen Brücken
zu planen. Die Planfunktion tätigt
Anrufe an eine Planschnittstelle, um Konferenzen zu erzeugen, zu
modifizieren und zu löschen.
Es gibt ein globales Konferenz-ID – ein eindeutiges Schlüsselfeld,
das die Konferenzen, die auf multiplen und geografisch verteilten
Brücken
stattfinden sollen, referenziert. Die Planungsfunktion stellt sicher,
dass die globale Konferenz-ID auf allen Brücken, die Teil einer geplanten Konferenz
sind, eindeutig ist. Sie stellt ebenso sicher, dass derselbe Sicherheitscode
eines Teilnehmers auf jeder Brücke
verwendet werden kann, und dass dieser Sicherheitscode für das gegebene
Datum/die gegebene Zeit auf allen Brücken, die Teil der Konferenz
sind, eindeutig ist. Dieses Erfordernis gilt auch für einen
Moderatorsicherheitscode.
-
Das
Planen ist nicht relevant bei einem Single Point of Failure oder
einem Bauteil mit zuviel Abhängigkeit
des Gesamtsystems. Dies erlaubt es Endnutzern und Agenten, globale
Konferenzen zu planen, ohne die Planungsinfrastruktur zum Planen
lokaler Konferenzen zu ändern.
Dies wurde durch die verteilten Planungsdatenbanken 8, 9, 10 und 42,
die mit den Brücken
verbunden sind, erreicht.
-
Die
Planungsfunktion sammelt global die Schnittstellen zu jeder Brückendatenbank.
Jede Planungsschnittstelle wendet eine Reservierungs-/Festlegungstechnik
an, um eine globale Konferenz über alle
Knotenpunkte an dem Standort/den Standorten zu planen. Diese Reservierung/Festlegung
ist dergestalt wichtig, dass, wenn die Reservierung einen Konflikt
wegen ungenügender
Anzahl von Ports aufweist, oder einen Codekonflikt auf irgendeiner
der Brücken, der
Plan als ganzes mit der passenden Notifikation zurück kommt.
Nur, wenn die Konferenz über
alle Brücken
reserviert werden kann, wird die Reservierung festgelegt und tatsächlich geplant.
-
Jede
MSE verwendet eine Konfigurationsdatei, und diese Datei ist allen
Systemen gemein. Die MSE nimmt an, dass die Konfigurationsdatei
auf jedem System alle Brücken
für das
System in Reihenfolge der Wichtigkeit jeder Brücke auflistet. Die Konfigurationsdatei
listet auch die IP-Adresse, den UDP-Port, durch den verbunden wird,
und die Telefonnummer für
jede Brücke
auf. Die MSE verwendet die Reihenfolge der Wichtigkeit, um die am
wenigsten teuren Leitungen zwischen den verschiedenen Brücken für das Routen
auf dem kostengünstigsten Weg
zu bestimmen. Die MSE nutzt diese Information, um die Verbindungen
aufzubauen, sobald eine Multi-Brücken-Konferenz
beginnt.
-
Eine
Globale Konferenz wird durch ein System 1 oder 2 mit
einem Master-Konferenz-Status
für die
Konferenz gesteuert. Dieses Steuersystem entscheidet, wie Linkleitungen
hergestellt werden, wie verteilte Konferenzbefehle (wie etwa secure
und lecture) behandelt werden, und wann die Konferenz beendet werden
soll. Jede Golbale Konferenz hat eine Master-Konferenz-Status-Aufzeichnung.
-
Die
Server 20 und 40 sind in drei "Layern" organisiert:
- • eine Bridge-Status-Layer
- • die
Multi-site-Engine-Layer, und
- • die
Local-Machine-Layer
-
Jede
Layer ist in drei Hauptobjekte unterteilt:
- • ein Statuskommunikationsobjekt,
- • einen
Statuscontainer, und
- • ein
Policy-Objekt.
-
Allgemein
horcht das Statuskommunikationsobjekt nach Statusänderungsevents
und kommuniziert diese Änderungen
an andere Layer und kann die Statuscontainerinformation aktualisieren.
-
Der
Statuscontainer enthält
Listen von Zustandsobjekten, die den gegenwärtigen Zustand der Aktivitäten, die
in dem System von Interesse sind, zusammenfassen. Er feuert ebenso
Statusverändert-Events,
um andere Objekte davon zu unterrichten, das irgendein Zustand sich
verändert
hat. Jedes Zustandsobjekt weist in sich eine Sequenznummer auf.
Wann immer ein Zustandsobjekt geändert
wird, wird seine Sequenznummer ebenso inkrementiert. Wenn eine Zustandsänderungsnachricht
durch ein empfangendes Objekt in einem anderen Teil des Systems
oder in einem anderen System bestätigt wird, wird die Sequenznummer
des gesendeten Objektes in die Nachricht mit eingeschlossen, so
die Lieferung bekannt wird. Das Policy-Objekt fällt Entscheidungen und assistiert
bei der Schöpfung
und Zerstörung
anderer Objekte in dem System.
-
Bridge-Status-Layer
-
Die
Bridge-Layer ist verantwortlich für das Herstellen und die Aufrecherhaltung
der Kommunikation mit anderen Systemen und zu verfolgen, welches System
die Globale- Konferenz-Status-Aufzeichnung für jede gegenwärtig aktive
Globale Konferenz aufweist. Sie ist im Wesentlichen auf einer höheren Ebene
als die MSE.
-
Initialisierung
-
Wenn
die Bridge-Layer startet, liest ein BridgePolicy-Objekt die lokale
Konfigurationsdatei und lädt
die gesamte statische Brückeninformation
in ein BridgeStatusContainer-Objekt. Sie initialisiert ebenfalls
ein MasterConferenceContainer, wo es Master-Konferenzaufzeichnungen
halten wird. Dann fertigt es ein BridgeStatus-Objekt für sich selbst
an und veranlasst es, ein BridgeStatusChanged-Event an das BridgeStatusCommunication-Objekt
zu senden.
-
Das
BridgeStatusCommunication-Objekt versucht, zu bestimmen, wer seine „nächsten" aktiven Nachbarn
sind, indem es versucht, einen TCP/IP-Socket mit ihnen zu öffnen, wobei
es die Information in dem BridgeStatusContainer verwendet. Sobald
es Kommunikation herstellt, sendet es die BridgeStatus-Information
zu ihnen hinüber.
-
Die
empfangenden BridgeStatusCommunication-Objekte auf den anderen Systemen
versuchen erst, die Information für das System in dem BridgeStatusContainer
zu aktualisieren. Da die Brücke
als erstes kommt, gibt die empfangende Brücke den BridgeStatus an ihre
Nachbarn weiter, so dass schließlich
jede aktive Brücke
in den System wissen wird, dass die neue Brücke verfügbar ist. Des Weiteren sendet
die empfangende Brücke
die gesamte Information, die sie über aktive Brücken hat,
und ihre gesamten MasterConference-Aufzeichnungen zurück an die ursprüngliche
Brücke.
Eine MasterConference-Aufzeichnung enthält den GlobalConferenceID und
die IP-Adresse der Brücke,
die der Konferenz-Master für
diese globale Konferenz ist.
-
Wenn
eine neue Globale Konferenz auf einem System beginnt, ruft die LocalStatusPolicy
die BridgePolicy:NewGlobalConference auf. Die BridgePolicy sieht
in den MasterConferenceContainer. Wenn sie einen passenden GlobalConferenceID
findet, dann existiert die Konferenz bereits und hat einen Globalen
Konferenz-Master. Wenn sie sie nicht findet, dann nimmt sie an,
dass dies eine vollkommen neue Globale Konferenz ist. Sie erzeugt
eine neue MasterConference-Aufzeichnung und fügt sie zu dem Container zu
(was ein Event auslöst,
das veranlasst, das diese MasterConference-Aufzeichnung im System
umhergegeben wird, so dass alle Brücken davon hören).
-
Es
schafft ebenso eine neue GlobalConferenceStatus-Aufzeichnung und
fügt es
dem GlobalConferenceStatus-Container hinzu.
-
Unter
Verwendung eines Zeitgebers inkrementiert das BridgePolicy-Objekt
die Sequenznummer in seinem lokalen BridgeStatus-Objekt. Dies löst einen
BridgeStatusChanged-Event aus, der von den „Nachbarn" des Systems empfangen wird. Wenn ein System
nichts von einem Nachbarn über
eine längere
Zeitperiode hört,
entscheidet es, dass entweder es oder der Nachbar nicht mehr länger kommunizieren. Es
löscht
seine bekannte Nachbarinformation und wiederholt den Prozess des
Bestimmens, wer seine Nachbarn sind.
-
Lokale Layer
-
Die
lokale Layer ist verantwortlich für die Herstellung und Aufrechterhaltung
der Kommunikation mit einer assoziierten lokalen Brücke, wobei
sie die Brücke
auf Anraten von der globalen Layer steuert, und eine Lokale-Konferenz-Status-Aufzeichnung für jede gegenwärtig aktive
Globale Konferenz verfolgt.
-
Wenn
die lokale Layer beginnt, loggt sich eine LocalPolicy in das BridgeInterface
ein, um Kommunikation mit der assoziierten Brücke herzustellen. Dann sendet
sie einen GetConferenceStatus-Befehl an das BridgeInterface, mit
einem GlobalConferenceID von 0. Dies veranlasst das BridgeInterface
für jede
GlobalConferenceID (über
den ConferenceStatusChange-Horcher) ConferenceStatusChanged-Auzeichnungen
zu senden.
-
Dies
stellt der LocalPolicy eine Liste aller auf der Brücke aktiven
globalen Konferenzen zur Verfügung.
Dann gibt es eine GetStaticConferenceInfo-Anfrage für jede globale
Konferenz heraus. Das BridgeInterface gibt eine StaticConferenceInfo-Auzeichnung
(GlobalConferenceID, Konferenzname, Moderatorsicherheitscode, und
ob die Konferenz auf einen Moderator warten muss.) zurück. Mit
diesen Daten erstellt die LocalPolicy eine LocalConferenceStatus-Aufzeichnung.
Sie ruft BridgePolicy.NewGlobalConference auf (siehe den Abschnitt
Bridge Layer/Neue Globale Konferenz). Die LocalPolicy fügt dann
die LocalConferenceStatus-Aufzeichnung dem LocalConferenceStatusContainer
hinzu.
-
Das Ändern des
LocalConferenceStatusContainer löst
einen LocalConferenceStatusChanged-Event aus, der das LocalStatusComm-Objekt aufweckt.
Es fragt bei der Bridge-Layer nach der IP-Adresse des Konferenz-Masters
für diese
Globale Konferenz an und sendet die LocalConferenceStatus-Aufzeichnung
an die Globale Layer.
-
Wenn
ein Anruf bei der Brücke
ankommt, die eine neue Globale Konferenz beginnt, sendet das BridgeInterface
eine ConferenceStatusChanged-Aufzeichnung an den Horcher, die LocalPolicy. Das
Verhalten des Systems von dort ist dasselbe, wie für die Initialisierung.
Die LocalPolicy gibt eine GetStaticConferenceInfo-Anfrage für diese
Konferenz heraus. Es erstellt eine LocalConferenceStatus-Aufzeichnung
und ruft die BridgePolicy.NewGlobnlConference auf (siehe den Abschnitt
Bridge Layer/Neue Globale Konferenz). Die LocalPolicy fügt dann
die LocalConferenceStatus-Aufzeichnung dem LocalConferenceStatusContainer
hinzu.
-
Wenn
ein Event auftritt, das bewirkt, dass sich eine Globale Konferenz
auf der Brücke ändert, feuert
das BridgeInterface eine ConferenceStatusChanged-Aufzeichnung. Diese
Veränderung
kann sein, dass ein Anwesender ankommt oder weggeht, dass eine Linkleitung
ankommt oder weggeht, oder sich der Lecture- oder Secure-Zustand
der Konferenz ändert.
Auf jeden Fall aktualisiert die LocalPolicy einfach den LocalConferenceStatusContainer,
und das LocalStatusComm-Objekt informiert in Folge die GlobalStatus
Layer über
die Änderung.
-
Globale Layer
-
Die
Globale Layer ist verantwortlich für das Aufrechterhalten des
Zustands von Globalen Konferenzen, und für deren Verwaltung. In mancher
Hinsicht hat sie am wenigsten zu tun, ist aber auch das wichtigste.
-
Die
BridgePolicy schafft als Teil ihres NewGlobalConference-Verfahrens
eine neue GlobalConferenceStatus-Aufzeichnung und fügt sie dem
GlobalConferenceStatus-Container hinzu. Wiederum gibt es nichts
weiteres zu tun. Eine GlobalConferenceStatus-Aufzeichnung enthält Information über den
globalen Zustand der Konferenz und einen Menge von LocalConferenceStatus-Segmenten,
die den gegenwärtigen
Zustand jeder mit ihr assoziierten LocalConference widerspiegelt.
-
Schließlich sendet
das LocalStatusComm-Objekt eine LocalConferenceStatus-Aufzeichnung an die
Globale Layer. Das GlobalStatusComm-Objekt liest die Information
und aktualisiert GlobalConferenceStatus-Aufzeichnung, wobei es das
LocalConference-Segment
für diese
Brücke
hinzufügt.
Der GlobalPolicy-Horcher wird durch diese Änderung benachrichtigt, muß aber keine
Handlung durchführen.
Dieser Zustand bleibt wahr, bis eine zweite Brücke der Konferenz beitritt.
-
Wenn
eine andere Brücke
der Konferenz beitritt, agiert das GlobalStatusComm-Objekt so, wie
es dies für
die erste Brücke
tat. Andererseits muss nun der GlobalPolicy-Horcher handeln. GlobalPolicy
ruft ParseStatusChangeEvent auf, und dann, wenn irgendeine Änderung
im Zustand der globalen Konferenz benötigt wird, sendet sie Befehle
an die entsprechenden Brücken,
um diese Änderungen
zu bewirken. Mögliche Änderungen
sind: füge
Linkleitung hinzu, entferne Linkleitung, beende die Konferenz, und sichere
die Konferenz oder trage ihr vor.
-
Da
Systeme miteinander unter Verwendung von TCP/IP kommunizieren, wird
darüber
ein Schema gelegt, um Verlässlichkeit
zu gewährleisten.
Das Basisobjekt für
die Kommunikationsobjekte (SsStatusComm) bildet ein Modell, dem
von den (meisten) Kommunikationsobjekten gefolgt wird. Der Zustand der
Objekte, die gesendet werden, wird durch die Verwendung der Sequenznummern
synchronisiert.
-
Jedes
Objekt, das mit einem Event assoziiert werden kann, weist eine Sequenznummer
auf. Wann immer das System sich ändert,
stößt es die
Sequenznummer an. Die Änderung
löst ein
StatusChanged-Event aus, und SsStatusComm ist ein Status-geändert-Horcher.
Das Event wird in der ChangedEventQueue eingereiht. Ein Event bezieht
sich auf ein einzelnes Objekt. Wenn einem Objekt ein Event passiert,
wird die gegenwärtige
Sequenznummer des Objektes in dem Event gespeichert.
-
Ein
sekundärer
Faden behandelt das Senden von Nachrichten. Der Faden entfernt Objekte
aus der ChangedEventQueue, tut aber nichts mit ihnen, falls die
Eventsequenznummer nicht mit der Objektsequenznummer übereinstimmt
(wenn multiple Events demselben Objekt passieren, wird nur das letzte
Event verarbeitet). Wenn die Sequenznummer passt, dann muss das
Event gesendet werden. Auch jede Nachricht weist eine Sequenznummer
auf. Wenn er die Nachricht sendet, schreibt er die Sequenznummer
der Nachricht und einen Zeitstempel in das Eventobjekt und (wenn
das Event Resend Boolean wahr ist) fügt es der ResendEventQueue
zu. Es gibt keine Notwendigkeit, die Nachrichten in eine Warteschlange
einzureihen. Wenn die Nachricht bestätigt wird, durchläuft er die
ResendEventQueue auf der Suche nach Events, die die passende Nachrichtensequenznummer
aufweisen, und entfernt das Event aus der Warteschlange. Wenn das
Event länger
in der ResendEventQueue ist als die Rücksendeschwelle, wird es zurück zu der
ChangedEventQueue bewegt (indem es zurück in die ChangedEventQueue
getan wird, wird es nur erneut gesendet, wenn es passend ist. Falls
das Objekt sich in der Zwischenzeit geändert hat, dann würde das
wieder in der Warteschlange eingereihte Objekt ignoriert werden.
-
Brückenabhängige Maschine APS
-
In
dieser APS benötigte
Funktionen: Alle Brücken,
die Teil des Systems sind, müssen
alle Funktionen in dieser APS unterstützen.
-
Status
-
- • GetConferenceStatus(GlobalConferenceID)
Frage
den Zustand von globalen Konferenzen ab, wenn die Globale Konferenz
ID gegeben ist. Die Reaktion schließt das Folgende ein:
- • Globale
Konferenz ID (Schlüssel)
- • Konferenzplanungsinformation
- • Moderator-Beendigungs-Flag
(Die Konferenz wird beendet, wenn der letzte Moderator existiert)
- • Konferenzstatusinformation
- • Vortragen
- • Sichern
- • Gegenwärtig benutzte
Ressourcen
- • Anzahl
der Nutzerleitungen
- • Anzahl
der Moderatorleitungen
- • Aktive
Linkleitungen: LinkA und LinkB (maximal 2 Verbindungen pro Konferenz
pro Brücke)
- • Brücken-ID,
GlobalConferenceID, ModeratorSecurityCode, LineID
- • GetStaticConferenceInfo(GlobalConferenceID)
Frage
die statische Information globaler Konferenzen ab, wenn die Globale
Konferenz ID gegeben ist. Die Reaktion schließt das Folgernde ein:
- • Globale
Konferenz ID (Schlüssel)
- • Statische
Konferenz Information:
- • Konferenzname
- • Konferenzmoderator
Passiercode (notwendig zum Verbinden)
- • Moderator-Start-Flag
(Teilnehmer hören
Musik bis der erste Moderator beitritt)
- • AddConferenceStatusChangedListener()
Horche
nach Konferenzzustand-Geändert-Events
- • RemoveConferenceStatusChangedListener()
Beende
das Horchen nach Konferenzzustand-Geändert-Events
- • FireConferenceStatusChanged(event)
Sende
Mitteilung über
eine Statusänderung
an eine Globale Konferenz. Die Daten sind dieselben wie die Reaktion
auf die GetConferenceStatus Nachricht
-
Befehle
-
- • AddLink(bridgerID,
securityCode, startingLine, Phone)
Stelle Zugang zu einer Leitung
her (beginnend mit startingLine), wähle die Telefonnummer der anderen
Brücke.
Wenn sie antwortet, spiele die VLL-Waiteschlange und den securityCode.
Markiere die Leitung als ein VLL und als ein Moderator.
- • HangupLink(LineID)
Linkleitung
aufhängen – wenn Leitungs-ID
gegeben
- • Hangup(GlobalConferenceID)
Konferenz
aufhängen – wenn Globale
Konferenz ID gegeben
- • SecureConference(GlobalConferenceID)
Stelle
Conference Secure ein
- • LectureConference(GlobalConferenceID)
Stelle
Conference Lecture ein
-
Die
Erfindung ist nicht auf die beschriebenen Ausführungsformen beschränkt, sondern
kann im Aufbau und im Detail variiert werden.