-
Technisches Gebiet
-
Diese
Erfindung betrifft Telekommunikation.
-
Hintergrund der Erfindung
-
Die
Client/Server-Architektur wird in Nachrichtenaustausch-Verarbeitungssystemen,
einschließlich
Telekommunikationssystemen vorherrschend. In der Client/Server-Architektur
verwendet eine als "Client" bezeichnete Endpunkt-Berechnungsvorrichtung
oder Software die Ressourcen, die von einer anderen als "Server" bezeichneten Berechnungsvorrichtung
oder Software gesteuert oder verwaltet wird, die mit dem Client über eine
Netzstruktur (z.B. ein lokales Netz (LAN), ein Stadtnetz (MAN) oder
ein Weitbereichsnetz (WAN) oder sogar über ein übliches Telefonvermittlungsnetz)
verbunden ist. Der Client fordert Information, Dienste und/oder
Nutzung physikalischer Ressourcen von dem Server an und erhält diese.
-
Typischerweise
haben in Telekommunikationssystemen Rufsteuerungs-Server eine direkte Steuerung über die
Verbindungsimplementierungs-(z.B. Vermittlungs)-Struktur des Telekommunikationsnetzes.
Wenn Client-Endpunkte Rufanforderungen an den Rufsteuerungs-Server
stellen, spezifizieren sie ihre Anforderungen an den Server und
der Server führt
die erforderlichen Netzverbindungen über die Netzstruktur aus. Um
dieses zu tun, muss der Rufsteuerungs-Server auf die Netzstruktur zugeschnitten
werden, die er steuert. Somit müssen
unterschiedliche Server auf unterschiedliche Netzstrukturen ausgelegt
werden. Ferner arbeiten die meisten LANs, MANs und WANs in einer
verteilten Weise, wobei jede Einheit, die mit dem Netz verbunden
ist, im Wesentlichen eine gleichwertige Kontrolle über die
Netzstruktur für
jede andere Einheit hat. Demzufolge widerspricht die Steuerung des
Netzes mittels eines Servers (d.h., eine zentralisierte Steuerung) nicht
nur der Auslegungsphilosophie der Netze, sondern ist oft auch schwierig
zu implementieren.
-
Es
wurden bereits Versuche unternommen, die Verbindungssteuerfunktion
aus einer zentralen Netzsteuerung zu entfernen und sie über Netzendpunkte
zu verteilen. Ein veranschaulichendes Beispiel dafür ist in
dem U.S. Patent Nr. 4,631,534 offenbart. Dieses Patent offenbart
ein verteiltes Paket-Vermittlungssystem, in welchem eine Paket-Vermittlungssteuerung
als ein Adressenserver für
Endpunktstations-Clients dient. Wenn eine (rufende) Station wünscht, mit
einer anderen (gerufenen) Station zu kommunizieren, sendet der Netzanschluss
der rufenden Station die Kennungen der rufenden und der gerufenen
Station an die Paket-Vermittlungssteuerung. Die Steuerung übersetzt
die Kennung der gerufenen Station in eine Paketvermittlungs-Netzadresse der gerufenen
Station und sendet die Netzadresse an den Anschluss der rufenden
Station. Der Anschluss der rufenden Station speichert die Netzadresse
und verwendet sie zum Senden von Paketen an die gerufene Station über das
Paket-Vermittlungsnetz.
-
Eine
bedauerliche Einschränkung
von Anordnungen wie dieser besteht darin, dass sie eine direkte
Zwischenverbindung der rufenden und gerufenen Endpunkte durch die
Netzstruktur ohne die Zwischenschaltung irgendwelcher Server, Ressourcen, Netzübergänge (Gateways)
oder anderer Strukturen usw. erfordern, die effektiv als ein Zwischenendpunkt funktionieren.
Demzufolge haben derartige Anordnungen erhebliche Einschränkungen
bezüglich
der Umgebungen, in welchen sie eingesetzt werden können.
-
EP-A-0
483 547 offenbart einen Netzübergang
(Gateway), der die Adressierung mobiler Einheiten über Internetprotokoll-(IP)-Adressen in
einem drahtlosen Kommunikationsnetz zulässt. Ein Pool von IP-Adressen
ist dem Gateway zugeordnet, welches dynamisch diese IP-Adressen
an anfordernde mobile Einheiten auf einer temporären oder semi-permanenten Basis
zuteilt. Wenn ein entfernt angeordneter Benutzer ein Gespräch mit einer
Mobileinheit initialisiert, fragt er einen Netznamenserver ab, der
die IP-Adresse der mobilen Einheit zurückgibt. Der entfernte Nutzer
adressiert dann das Paket an diese IP-Adresse und sendet es an die
mobile Einheit, indem das Paket zu dem Netzübergang oder Gateway geleitet
wird. Das Gateway leitet das Paket über eine Basisstation zu der
Mobileinheit weiter.
-
US-A-5,509,000
offenbart eine Anordnung, die das Senden einer an einen Empfänger (Teilnehmer)
zu sendenden Kommunikation (Meldung) an eines von einer Vielzahl
von Kommunikationsgeräten und über eines
von einer Vielzahl von Kommunikationsnetzen ermöglicht. Eine von dem Quellengerät an den
Empfänger
gesendete Kommunikation enthält eine
Liste von Attributen der Kommunikation. Ein Server nutzt die Attribute,
um ein Gerät
des Empfängers
auszuwählen,
das den Attributen entspricht. Der Server nutzt dann die Attribute
und die Geräte-ID
des ausgewählten
Gerätes,
um eines von den Netzen auszuwählen,
das mit den Attributen und der Geräte-ID übereinstimmt. Der Server sendet
dann die Kommunikation über
das ausgewählte
Netz an das ausgewählte
Gerät.
-
WO9424803
offenbart ein Kommunikationsnetz, das Kommunikationsgeräte enthält, die
zueinander inkompatibel sein können,
und einen Steuerkomplex, der hybride Medien-Brücken
enthält, über welche
der Steuerkomplex inkompatible Formen von Kommunikation umwandeln
und somit kommunikativ die inkompatiblen Geräte verbinden kann.
-
EP 0 559 979 offenbart ein
Kommunikationsnetz, in welchem Kommunikationsverbindungen zwischen
Endpunkten durch Server (SCP) innerhalb des Netzes auf der Basis
von Leitweginformation aufgebaut werden, die von einem Teilnehmer-AIN-Prozessor
mittels Anfragen und Antworten, die zwischen dem SCP und dem Prozessor
hin und her fließen,
geliefert werden.
-
Zusammenfassung der Erfindung
-
Diese
Erfindung ist auf die Lösung
dieser und weiterer Probleme und Nachteile des Stands der Technik
ausgerichtet. Beispielsweise machen gemäß der Erfindung in einem Client/Server-Typ
eines Kommunikationssystems die Client-Endpunkte ihre Anfragen und
Annahmen an den Rufsteuerungs-Server wie zuvor für Kommunikationsverbindungen
mit den gewünschten
Attributen, aber statt die Kommunikationsverbindungen über das
Netz aufzubauen, sendet der Server Rückinstruktionen an die Endpunkte,
um diesen zu ermöglichen,
selbst das Netz zum Aufbau der erforderlichen Verbindungen zu veranlassen.
Zusätzlich
ordnet und weist der Server der Verbindung alle Kommunikationsressourcen
zu, die zur Ausführung
der Verbindung durch das Netz erforderlich sind zu (d.h., er stellt
diese zusammen). Eine Rufverbindungsverwaltung kann somit durch
den Rufsteuerungs-Server im Wesentlichen über jede Art von Netz ausgedehnt
werden, und der Server kann das Netz allgemein wie jedes andere
Netz betreiben. Außerdem
kann gleichzeitig die Rufverbindungsverwaltung in dem Server zentralisiert
werden, statt dass diese in jedem Netzsteuerelement (z.B. Endpunkt,
Ressource oder Vermittlung) eingebettet sein muss. Weitere Vorteile
bestehen darin, dass getrennte Rufsteuerungs-Server miteinander
im Wesentlichen über
jedes zugrunde liegende Transportnetz verbunden werden können und
zusammenarbeiten, um ein Netz von Rufsteuerungen auszubilden, dass
telefonartige, große
und merkmalreiche Netze als eine transparente Überschicht über weniger komplizierte Netze,
wie z.B. das Internet aufgebaut werden können, und dass Merkmale entwickelt
werden können,
welche transparent zwischen unterschiedlichen Arten von Netzen arbeiten
können.
-
Im
Allgemeinen wird gemäß der Erfindung ein
Kommunikationsverbindungsmanager für ein Telekommunikationssystem
bereitgestellt, das eine Vielzahl von Kommunikationsgeräten, die
in der Lage sind, Kommunikationen aufzubauen, einen Satz von Kommunikationsressourcen
und ein Kommunikation smedium enthält, das die Endpunkte und die
Ressourcen miteinander verbindet. Der Manager führt die Verbindungsverwaltung
wie folgt durch. Unter Ansprechen auf den Empfang eines Angebots
einer Kommunikation zwischen einem ersten und zweiten Endpunkt von
einem ersten Endpunkt plus Attributen der von dem ersten Endpunkt
gewünschten
Kommunikation, sendet der Manager das Angebot an den zweiten Endpunkt.
Unter Ansprechen auf den Empfang einer Annahme des Angebotes plus
Attributen der von dem zweiten Endpunkt gewünschten Kommunikation vom zweiten
Endpunkt bestimmt der Manager jede Ressource, die erforderlich ist,
um alle Unterschiede zwischen den Attributen des Angebotes und den
Attributen der Annahme zu überbrücken und
um die Kommunikation durchzuführen.
Der Manager stellt dann jede bestimmte Ressource für die Kommunikation
zusammen und sendet entweder an den ersten Endpunkt oder an den
zweiten Punkt Instruktionen für
diesen Endpunkt, um die Kommunikation zwischen den Endpunkten auf
dem Medium über jede
zusammengestellte Ressource aufzubauen. Beispielsweise sendet der
Manager an den ersten Endpunkt eine Annahme des Angebotes, das die
Instruktionen erhält,
wobei die Instruktionen entweder eine Adresse einer zusammengestellten
Ressource oder eine Adresse des zweiten Endpunktes bei Fehlen jeder
zusammengestellten Ressource enthalten. Beispielsweise sendet der
Manager auch an die zusammengestellte Ressource Anweisungen für den Aufbau
der Kommunikation zwischen der zusammengestellten Ressource und
dem zweiten Endpunkt, und die Instruktionen weisen die Daten des zweiten
Endpunktes auf. Es ist dann Sache des Endpunktes und jeder zusammengestellten
Ressource, die die Instruktionen empfängt, die Kommunikation auf
dem Medium zwischen den ersten und zweiten Endpunkten über jede
zusammengestellte Ressource gemäß den empfangenen
Instruktionen aufzubauen.
-
Vorteilhafterweise
bildet das vorstehend charakterisierte Telekommunikationssystem
nur eine Zone eines größeren Telekommunikationssystems, das
eine Vielzahl von Zonen enthält.
Unter den Ressourcen der einen Zone ist wenigstens eine Ressource
zur Verbindung des Mediums mit einem zweiten Kommunikationsmedium
einer zweiten Zone enthalten, das wenigstens einen Kommunikationsendpunkt aufweist,
der mit dem zweiten Medium verbunden ist, und ein zweiter Kommunikationsverbindungsmanager
zum Verwalten von Kommunikationsverbindungen auf dem zweiten Medium,
wodurch eine Vielzahl von Zonen und Kommunikationsverbindungsmanagern
vernetzt werden können,
um ein ausgedehntes Telekommunikationssystem zu bilden.
-
Diese
und weitere Vorteile und Merkmale der vorliegenden Erfindung werden
deutlicher aus der nachstehenden Beschreibung einer veranschaulichenden
Ausführungsform
der Erfindung in Verbindung mit den Zeichnungen ersichtlich.
-
Kurzbeschreibung der Zeichnungen
-
1 ist
eine Blockdarstellung eines Telekommunikationssystems, das eine
veranschaulichende Ausführungsform
der Erfindung enthält;
und
-
2–4 sind
Funktionsflussdiagramme von Operationen von Endpunkten und Servern
des Telekommunikationssystems nach 1 bei der
Implementierung der veranschaulichenden Ausführungsform der Erfindung.
-
Detaillierte Beschreibung
-
1 stellt
ein gemäß der Erfindung
konfiguriertes Telekommunikationssystem dar. Das System enthält ein oder
mehrere Kommunikations-Subsysteme oder Zonen 8–9.
Die Zone 8 enthält
ein erstes Kommunikationsnetz 12, das eine Vielzahl erster Kommunikationsendpunkte 14–15 miteinander
mit einem ersten Rufsteuerungs-Server 10, und mit ersten
Kommunikationsressourcen 19–20 verbindet. Die Zone 9 enthält ein zweites
Kommunikationsnetz 13, das eine Vielzahl von zweiten Kommunikationsendpunkten 16–17 miteinander,
mit einem zweiten Rufsteuerungs-Server 11 und mit zweiten
Kommunikationsressourcen 22–23 verbindet. Das
Telekommunikationssystem enthält
auch ein drittes Netz 18, das die Netze 12 und 13 miteinander
verbindet, um eine Zwischenzonenkommunikation zwischen den Zonen 8 und 9 bereitzustellen.
Obwohl zur Vereinfachung nur zwei Zonen 8–9 durch
das Netz 18 miteinander verbunden dargestellt sind, kann
das System von 1 eine beliebige Anzahl miteinander
verbundener Zonen aufweisen. Ports 27 und 28 von
Ressourcen 20 bzw. 23 verknüpfen und verbinden die Netze 12 bzw. 13 mit
dem Netz 18. Server 10 und 11 stellen Kommunikationsdienste,
wie z.B. Mediamanager 21 bzw. 24 für Kommunikationsmedien
(Audio, Video, verteilte Daten und gemeinsam genutzte Daten) bereit.
Beide Endpunkte 14–17 und
Server 10–11 sind speicherprogrammierte
Geräte,
welche herkömmlicherweise
Schnittstellen zur Außenwelt,
einen Speicher zum Speichern von Steuerprogrammen und Prozessoren
zur Ausführung
der im Speicher gesteuerten Steuerprogramme und zur Steuerung der Schnittstellen
enthalten. Beispielsweise sind die Endpunkte 14–17 Multimediaworkstations,
wie z.B. Sun- oder Hewlett-Packard-Workstations,
die Netze 12–13 sind
LANs, MANs, WANs oder irgendeine andere netzartige Verbindungsstruktur,
die Server 10–11 sind
Lucent Technologies MMCX Multimedia-Kommunikationsvermittlungsanlagen, die
Ressourcen 19–20 und 22–23 sind
Kommunikationsressourcen- und Kommunikationsfunktions-Provider,
wie z.B. Protokollwandler, Konferenzschaltungen, Netzüberbrückungen
zu anderen Netzen, usw., und das Netz 18 ist ein dazwischen
arbeitendes Transportmedium, wie z.B. das Internet. Alternativ ist
das Netz 18 ein Äquivalent
der Netze 12 und 13 mit seinem eigenen (nicht
dargestellten) Server, wobei die Ressourcen 20 und 23 als
Endpunkte des Netzes 18 funktionieren. Die Ressourcen 20 und 23 sind
Netzübergänge von
den Netzen 12 bzw. 13 zu dem Netz 18,
mit welchen sie über
die Zwischennetz-Kommunikationsports 27 bzw. 28 verbunden
sind.
-
Weitere
Details über
die beispielhafte Implementation der Server 10 und 11 in
der Form von Lucent Technologies MMCX-Vermittlungsstellen kann man in der
Patentanmeldung von F.J. Boyle III et al., mit dem Titel "Arrangement for Facilitating
Plug and Play Call Features",
U.S. Patent Nr. 5,717,747 finden.
-
Beispielsweise
können
der Server 10 und entweder die Ressourcen 19 oder 20 oder
der Server 11 und entweder die Ressourcen 22 oder 23 in
einem einzigen programmierbaren System zusammen angeordnet sein.
-
In
dem Falle, dass jeder Server (10–11) eine MMCX-Vermittlungsstelle
ist, liegen die Ports 27 und 28 zusammen mit den
Mediamanagern 21 und 24 auf den Servern 10 bzw. 11.
Der Mediamanager 21 und 24 jedes Servers 10 und 11 kennt
alle aktiven Ressourcen 19–20 bzw. 22–23 in
seinem Netz 12 bzw. 13: Jede Ressource registriert
sich bei ihrem Server- Mediamanager,
wenn die Ressource aktiv wird. Jeder Server 10–11 stellt
eine Infrastruktur bereit, um Parteien und Multimediadienste in
Kommunikations-"Kontexte" zu bringen, welche
eine Basis für
die Verhandlung von Serviceparametern bereitstellen. Ein. Kontext
ist eine Datendarstellung eines virtuellen Konferenzraums (cyberspace-meeting
room). Jede Kommunikationssitzung (z.B. ein Multimediaruf) wird durch
ihren eigenen Kontext repräsentiert,
wovon eine Kopie 25–26 im
Server 10–11 jedes
Netzes 12–13 existiert,
das in die Sitzung mit einbezogen ist. Jede Kommunikation findet
innerhalb eines Kontextes statt, und Parteien (Benutzer und deren
Endpunkte) und Dienste (Dienstmanager wie z.B. Mediamanager 21 und 24)
sind miteinander als Mitglieder innerhalb des Kontextes durch die
Server verbunden. Ein entferntes Netz wird in einem Kontext durch
einen Port 27, 28 repräsentiert, der die Sitzung mit
dem entfernten Netz verbindet. Der Kontextdienst ist in etwa analog
zu dem WindowsTM-System von Microsoft Corporation.
Genauso wie das Windows-System Ereignisse, die eine Änderung
in der Präsentationsumgebung
der Anwendung reflektieren, an alle in der Umgebung laufenden Anwendungen
verteilt, verteilt der Kontext Ereignisse, welche eine Änderung
in dem Kommunikationskontext reflektieren, an alle Mitglieder des
Kontextes. Als Teil des Ereignis-Meldungsmechanismus unterstützt der
Kontext auch eine Verhandlung zwischen Kontextelementen, um ein
gemeinsames Arbeiten von Endpunkten und Servicemanagern mit möglicherweise
unterschiedlichen Fähigkeiten
zu ermöglichen.
-
Gemäß der Erfindung
wird ein netzunabhängiges
Verbindungsmanagement durch die Endpunkte 14–17,
Server 10–11 und
Ressourcen 19–20 und 22–23 in
dem System nach 1 durch einen Austausch von
Verbindungsangeboten und Annahmen implementiert. Jedes Angebot und
jede Annahme kann eine oder mehrere getrennte Meldungen enthalten.
Jedes Angebot und jede Annahme enthält Adressen und Attribute.
In dem Falle eines Angebotes enthalten die Adressen eine Kennung
des Anbieters (des Urhebers des Angebotes) und eine Kennung des
Angebotsempfängers
(des gewünschten Empfängers des
Angebotes). Die Kennung des Angebotsempfängers kann eine Kennung eines
Kontextes sein, von dem der Anbieter ein Mitglied ist. Alternativ
kann der Anbieter eine oder mehrere Kennungen nur bestimmter Mitglieder
des Kontextes als Anbieter enthalten. In dem Falle einer Annahme
enthalten die Adressen eine Kennung des Anbieters, dessen Angebot
angenommen wird, und zu Beginn eine Kennung des annehmenden (des
das Angebot annehmenden Empfängers).
Angebots- und Annahme-Attribute können einige oder alle Attribute
der vorgeschlagenen Verbindung, wie z.B. den Medientyp (z.B. Audio,
Video, verteilte Daten, gemeinsame Daten), Klasse oder Qualität des Dienstes,
Bandbreite, usw. enthalten. (Einige Attribute können angenommen werden, und
müssen
somit nicht transportiert werden.) Die Attribute können durch
Meldungen transportiert werden, die von den Meldungen getrennt sind,
die die Adressen transportieren, oder Attribute und Adressen können mittels
derselben Meldungen transportiert werden. Der Austausch von Angeboten
und Annahmen kann im Wesentlichen durch jedes gewünschte Kommunikationsprotokoll über die Netze 12 und 13 oder
sogar über
ein getrenntes Signalisierungsnetz durchgeführt werden. Ein derartiges geeignetes
Protokoll ist das Übertragungssteuerprotokoll
(TCP). Ein weiteres geeignetes Protokoll ist das RSVP-Protokoll,
das modifiziert ist, um die von dem Protokoll transportierte Information über die Bandbreitenzuweisungsinformation
hinaus auf die Information zu erweitern, die für die Kommunikationsattribut-Verhandlung erforderlich
ist. Eine Beschreibung des RSVP-Protokolls
kann in "Ressource
ReSerVation Protocol (RSVP)-Version
1 Functional Specification" einem
Internet-Draft of the Internet Engeneering Task (IETF), mit Datum
vom 22. November 1995 gefunden werden.
-
Nachdem
ein Endpunkt einer Partei Mitglied eines Kontextes 25 wurde,
hat er die Möglichkeit,
Angebote für
Kommunikationsverbindungen an Endpunkte einer anderen Partei zu
machen. Angebote über
Verbindungen unterschiedlicher Medien werden auf einer Bedarfsbasis,
z.B. auf Anforderung von einer Partei, die ein Kontextelement ist,
an seinen bzw. ihren Endpunkt gemacht. Ein Angebot wird gemacht, indem
eine Meldung an einen Mediamanager des lokalen Netzservers gesendet
wird. Nachdem er in Schritt 200 veranlasst wird, ein Angebot
zu machen, erzeugt ein Endpunkt (der Endpunkt 14 werde
angenommen) in Schritt 202 eine Angebotsmeldung und füllt seine
Adressen- und Attributfelder mit Werten aus, die definieren, mit
wem eine Verbindung aufzubauen ist (angenommen werde der Endpunkt 14 mit den
Endpunkten 15 und 16) und welche Art von Verbindung
aufzubauen ist. Der Endpunkt sendet dann in Schritt 204 die
Angebotsmeldung an den Mediamanager 21, welcher ein Element
des Kontextes 25 ist, an den Endpunkt 19, dass
der Endpunkt 14 ebenfalls ein Mitglied davon in seinem
lokalen Server 10 ist.
-
Nach
dem Empfang der Angebotsmeldung in Schritt 206 registriert
der Mediamanager 21 das Angebot für eine zukünftige Nutzung in Schritt 208 und leitet
dann in Schritt 210 die Angebotsmeldung an andere Einheiten
weiter, die in die Kommunikationssitzung eingebunden sind, d.h.,
an andere Mitglieder des Kontextes 25 (angenommen werde
der Endpunkt 15 und der Port 27 zugunsten des
Endpunktes 16 des Netzes 13). Wenn das Angebot
nur an bestimmte Kontextelemente adressiert ist, leitet der Mediamanager 21 die
Angebotsmeldung nur an die adressierten Mitglieder weiter; wenn
das Angebot an die Kommunikationssitzung insgesamt adressiert ist, leitet
der Mediamanager 21 die Angebotsmeldung an alle Kontextelemente
mit Ausnahme des einen weiter, von dem er die Angebotsmeldung empfangen hat.
-
Wenn
eines oder mehrere der Kontextelemente, an welche die Angebotsmeldung
weiterzuleiten ist, ein entfernter Angebotsempfänger ist – einer der in dem entfernten
Netz 13 angeordnet ist –, empfängt, wie es in Schritt 211 angezeigt
ist, der Mediamanager 24 des Servers 11 das Angebot über das Netz 18 und
die Ports 27 und 28 und verarbeitet das Angebot
in derselben Weise, wie es der Mediamanager 21 des Servers 10 tat.
Das heißt,
nach dem Empfang der Angebotsmeldung in Schritt 206 registriert der
Mediamanager 24 in Schritt 208 das Angebot und leitet
die Angebotsempfängermeldung
an andere Elemente des Kontextes 26 (Endpunkt 16)
außer dem
einen weiter, von welchem er die Angebotsmeldung (Port 28)
in Schritt 210 empfangen hatte.
-
Nach
dem Empfang der Angebotsmeldung in Schritt 212 verarbeitet
jeder Endpunktangebotsempfänger
(Endpunkte 15 und 16) das Angebot gemäß seinen
eigenen Prozeduren und Parametern in Schritt 219. Dieses
kann die Nachricht eines Benutzers des Endpunktes 15 oder 16 beinhalten,
dass das Angebot empfangen worden ist. Falls und wenn die Verarbeitung
des Angebotes zu einer Annahme des Angebotes (beispielsweise zeigt
der Benutzer des Endpunktes eine Annahme an) bei dem Endpunkt führt, wie
es in Schritt 216 ermittelt ist, erzeugt der Angebotsempfänger (d.h.,
der annehmende Angebotsempfänger) 15, 16 in
Schritt 218 eine Annahmemeldung, und füllt seine Adressen und Attributfelder
mit Werten aus, die definieren, wer der Anbieter und der Annehmer
sind, und welche Art einer Verbindung der Annehmer akzeptieren möchte. Die
Attribute der akzeptierten Verbindung können oder können nicht dieselben Attribute
wie der angebotenen Verbindung sein. Der Angebotsempfänger 15, 16 kann dann
die Annahmemeldung an den Mediamanager 21, 24 in
seinem lokalen Server 10 bzw. 11 in Schritt 220 senden.
Die Einbeziehung des Angebotsempfängers in die Angebots-Annahmeprozedur
endet dann in Schritt 222.
-
Nach
dem Empfang der Annahmemeldung in Schritt 224 analysiert
dann der Mediamanager bei dem lokalen Server (Mediamanager 21 des
Servers 10 in Bezug auf den Endpunkt 15 und der
Mediamanager 29 des Servers 11 in Bezug auf den
Endpunkt 16) das Angebot in Schritt 226, um in
Schritt 302 zu ermitteln, welche Dienste und Ressourcen
des lokalen Netzes 12, 13 die akzeptierte Verbindung
erfordert. Der Mediamanager 21, 24 vergleicht
auch in Schritt 300 die Annahme mit dem ursprünglichen
Angebot, um aufzudecken, ob irgendwelche Unterschiede zwischen dem
Angebot und der Annahme vorliegen und was diese sind, um zu ermitteln,
welche Ressourcen 19–20, 22–23 erforderlich
sind, um irgendwelche Differenzen zwischen dem Angebot und der Annahme
zu überbrücken. Der
Mediamanager 21, 24 ermittelt dann auf der Basis
der Ressourcen, die mit diesem Mediamanager 21, 24 registriert sind,
ob er alle benötigten
Ressourcen bereitstellen kann. Falls nicht, prüft der Mediamanager 21, 24 in Schritt 306 die
Adresse des Anbieters, um zu ermitteln, ob er sich in dem lokalen
Server des Anbieters befindet. Wenn er ermittelt, dass er sich in
dem lokalen Server des Anbieters befindet (d.h., in dem Server 10 in
dem angenommenen Falle des Anbieters 14) geht er zur 4 über, um
die geplante Verbindung abzubrechen.
-
Wenn
der Mediamanager 21, 24 entweder in Schritt 304 ermittelt,
dass er alle benötigten
Ressourcen zur Verfügung
stellen kann, oder wenn er in Schritt 306 ermittelt, dass
er nicht der lokale Server des Anbieters ist, geht der Mediamanager 21, 24 zu dem
Schritt 308 über,
um die benötigten
Ressourcen zusammenzustellen, d.h., um sie der vorgeschlagenen Verbindung
zuzuordnen und zuzuweisen. Beispielsweise weist, wenn die Verbindung über ein
anderes Netz auszuführen
ist, der Mediamanager die Bandbreite zu, die durch die Verbindung
zu dem lokalen Port 27 oder 28 erforderlich ist,
die das lokale Netz mit dem entfernten Netz verbindet; wenn das Angebot
eine Audioverbindung gemäß der A-Kodierregel spezifiziert,
während
die Annahme eine Audioverbindung gemäß der μ-Kodierregel spezifiziert, weist
der Manager einen Protokoll-Wandler von den Ressourcen 19–20, 22–23 der
Verbindung zu; und wenn die Verbindung mehr als zwei Einheiten auf dem
Netz des Mediamanagers beinhaltet, weist der Mediamanager der Verbindung
eine Konferenzbrücke
von den Ressourcen 19–20, 22–23 zu.
Der Mediamanager 21, 24 erzeugt dann in Schritt 310 eine Version
der empfangenen Annahme für
jede Ressource in seinem Netz, die in Schritt 308 zusammengestellt
wurde. Für
jede Ressource hat deren Annahmeversion eine Adresse der Einheit,
die der Empfänger
der Ausgabenachricht der Ressource als die Angebotsempfängeradresse
ist, und hat die Attribute, die für die Ausgabenachricht der
Ressource als die Attribute erforderlich sind. Unter Fortsetzung
des vorstehenden Beispiels ändert,
wenn der Mediamanager 74 einen Port 28 der erforderlichen
Bandbreite der Verbindung zuweist, der Mediamanager 24 die Kennung
des Angebotsempfängers
des zugeordneten Ports 28; wenn der Mediamanager 21 oder 24 einen
A-Kodierregel/μ-Kodierregel-Protokollwandler der
Verbindung zuweist, dann ändert
der Mediamanager 21 oder 24 die Kennung des Angebotsempfängers auf
die des zugewiesenen Protokollwandlers der Ressourcen 19–20 bzw. 22–23,
sowie ändert
die Annahmeattribute von der μ-Kodierregel
zu der A-Kodierregel;
und wenn der Mediamanager 21 eine Konferenzbrücke der
Verbindung zuweist, ändert
er die Kennung des Angebotsempfängers
auf die zugewiesene Konferenzbrücke
der Ressourcen 19–20. Der
Mediamanager 21, 24 sendet dann in Schritt 312 die
angepassten Annahmen an die zusammengestellten Ressourcen.
-
Nach
dem Empfang der angepassten Annahme in Schritt 320, verarbeitet
jede empfangende Ressource die Annahme in Schritt 322 unter
Verwendung der Attribute der Annahme, um sich selbst so einzustellen,
dass sie die erforderliche Ausgabe liefert. Jede empfangende Ressource
verwendet auch die Adresse des Angebotsempfängers in seiner empfangenen
Annahme, um einen Rufpfad zu dieser Adresse in Schritt 324 aufzubauen.
-
Nach
dem Schritt 312 sendet der Mediamanager 21, 24 auch
in Schritt 314 eine angepasste Annahme an den Anbieter.
Dessen Einbeziehung in die Angebotsannahmeprozedur endet dann in
Schritt 316. Wie in Schritt 318 dargestellt, sendet
der Mediamanager 21 des lokalen Servers 10 des
Anbieters die angepasste Annahme an den Anbieterendpunkt 14,
während
der Mediamanager 24 des entfernten Servers 11 die
angepasste Annahme an den Port 28 sendet, der die vorliegende
Kommunikationssitzung über
das Netz 18 mit dem Netz 12 verbindet. Der Port 27,
der die Annahme aus dem Port 28 empfängt, gibt diese an den Mediamanager 21 des
Servers 10 weiter, welcher wie dies in den Schritten 224 und
folgenden dargestellt und beschrieben wurde.
-
Nach
dem Empfang der Annahme vom Mediamanager 21 in Schritt 330 verarbeitet
der Anbieterendpunkt 14 die Annahme in Schritt 332,
um sich selbst für
die vorgeschlagene Verbindung fertig zu machen. Der Endpunkt 14 interagiert
dann mit dem lokalen Netz in beliebiger durch das Netz 12 vorgeschriebenen
Art, um das Netz 12 zu veranlassen, eine Verbindung zwischen
dem Endpunkt 14 und einer beliebigen Einheit (z.B. dem
Endpunkt 15, der Ressource 19, oder einem Port 27),
die als der Angebotsempfänger
in der Annahme angegeben ist, in Schritt 334 aufzubauen.
Die Einbeziehung des Endpunktes 14 in die Anbieter-Annahme-Prozedur
endet dann in Schritt 336.
-
Zurückkehrend
zu dem Schritt 306 kann, wenn der Mediamanager 21 ermittelt,
dass er sich in dem lokalen Server des Anbieters befindet und nicht alle
erforderlichen Ressourcen durch die vorgeschlagene Verbindung bereitstellen
kann, die vorgeschlagene Verbindung nicht durchgeführt werden,
und der Mediamanager 21 geht zur 4 über, um
diese abzubrechen. Der Mediamanager 21 sendet dann in Schritt 400 eine
Rückweisung
an den Annehmer, der in der Meldung angegeben ist, und auch an den
Anbieter – den
Endpunkt 14 – in
Schritt 402. Dessen Einbeziehung in den Anbieter-Annahme-Prozeduren endet
dann in Schritt 404.
-
Unter
Ansprechen auf den Empfang der Rückweisung
in Schritt 420 verarbeitet der Anbieterendpunkt 14 die
Rückweisung
in Schritt 422 (d.h., er meldet seinem Benutzer, dass die
gewünschte
Verbindung nicht hergestellt werden kann) und beendet in Schritt 424 die
Anbieter-Annahme-Prozedur.
-
Wenn
der Angebotsempfänger
lokal, d.h. der Endpunkt 15 gemäß Darstellung in Schritt 401 ist, empfängt er die
Rückweisung
in Schritt 410 direkt aus dem Mediamanager 21.
Wenn der Angebotsempfänger
entfernt ist, empfängt
zuerst der Mediamanager 24 des entfernten Servers 11 die
Rückweisung
aus dem Mediamanager 21 des lokalen Servers 10 über den
Port 28 in Schritt 430. Darauf ansprechend sendet
der Mediamanager 24 in Schritt 432 die Rückweisung
zu dem Angebotsempfänger.
Wenn der Angebotsempfänger
lokal ist – der
Endpunkt 16 in diesem Beispiel –, wie es in Schritt 433 dargestellt
ist, empfängt
er die Rückweisung
direkt in Schritt 410. Wenn der Angebotsempfänger entfernt
wäre, würde er die
Rückweisung
indirekt über
seinen eigenen Mediamanager in Schritt 430 und in den folgenden Schritten
empfangen. Nach dem Empfang der Rückweisung in Schritt 410 verarbeitet
der Angebotsempfänger
die Rückweisung
in Schritt 412 und beendet dann seine Einbeziehung in die
vorgeschlagene Verbindung in Schritt 414. Ferner sendet
der Mediamanager 24 des entfernten Servers 11 unter
Ansprechen auf den Empfang der Rückweisung
die Rückweisung
in Schritt 434 an die Ressourcen, die er in Schritt 308 zusammengestellt
hatte, gibt in Schritt 436 die zusammengestellten Ressourcen
aus der Zuweisung zu der vorliegenden Verbindung zur Verwendung
durch andere Verbindung frei und beendet seine Einbeziehung in den
Angebots-Annahme-Prozess in Schritt 438. Nach dem Empfang
der Rückweisung
in Schritt 440 baut die Ressource in Schritt 442 das
Rufpfadsegment ab, das sie in Schritt 324 aufgebaut hatte,
und beendet in Schritt 444 ihre Einbeziehung in die vorgeschlagene
Verbindung.
-
Natürlich sind
für den
Fachmann auf diesem Gebiet verschiedene Änderungen und Modifikationen
an der vorstehend beschriebenen Beispielausführungsform ersichtlich. Beispielsweise
kann anstelle davon, dass die Annahme die Adresse enthält, an welche
der Anbieter anknüpfen
muss, der Anbieter die Adresse enthalten, an welche der Angebotsempfänger anknüpfen muss,
wodurch der Rufpfad in der Rückwärtsrichtung
gegenüber
dem vorstehend offenbarten aufgebaut wird. Oder es können Angebotsattribute
und Annahmeattribute den Servern in Meldungen mitgeteilt werden,
die von den Meldungen getrennt sind, die die Adressen zusammen mit
dem Rufpfad transportieren, und die Attributmeldungen müssen nicht
dem Rufpfad folgen – sie
können
an die Server beispielsweise über
ein getrenntes Signalisierungsnetz übertragen werden. Ferner kann
anstelle der Verwendung des Kontextes der MMCX-Vermittlung als Nachrichtenübermittlungsmechanismus
für Angebote
und Annahmen jeder andere gewünschte Nachrichtenübermittlungsmechanismus
verwendet werden. Ein geeigneter alternativer Mechanismus ist das
Mehrpunktkommunikationsdienste-(MCS)-Protokoll, welches in der ITU
T.120-Protokollserie beschrieben wird. Derartige Änderungen
und Modifikationen können
innerhalb des Schutzumfangs der Erfindung und ohne Minderung dessen
begleitender Vorteile ausgeführt
werden.