DE69634950T2

DE69634950T2 - Identifizierung von anwendungsfähigkeiten für telekonferenzverbindungen

Info

Publication number: DE69634950T2
Application number: DE69634950T
Authority: DE
Inventors: G. Guy RIDDLE
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 1995-02-24
Filing date: 1996-02-23
Publication date: 2006-04-20
Anticipated expiration: 2016-02-24
Also published as: EP2045960A2; EP1585284A3; WO1996026587A1; EP1816787A3; DE69638363D1; EP1816786A3; EP2045960B1; EP0811283B1; DE69634950D1; EP1816787A2; EP1816788A3; EP2045960A3; EP1816786A2; EP1816788A2; US5572582A; EP1816787B1; EP1585284A2; EP0811283A1; AU5355196A; EP1816786B1

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf Telekonferenzsysteme. Insbesondere bezieht sich die vorliegende Erfindung auf ein Nachrichtenaustauschprotokoll und -Verfahren zur Kennzeichnung der Leistungsmöglichkeiten einer Anwendung für Telekonferenzverbindungen.
2. Hintergrundinformationen
Die Durchführung von Telekonferenzen wird zunehmend eine weit verbreitete Anwendung in Personalcomputersystemen. Üblicherweise ermöglichen derartige Anwendungen die Übertragung von Audio- und Videodaten zwischen den Anwendern, so dass sie miteinander sprechen und anderweitig kommunizieren können. Derartige Anwendungen umfassen gelegentlich auch eine gemeinsame Nutzung von Daten. Dabei können verschiedene Arten von Daten, wie zum Beispiel Dokumente, Tabellenkalkulationen, graphische Daten oder andere Arten von Daten, von allen Teilnehmern der Telekonferenz gemeinsam benutzt und bearbeitet werden. Verschiedene, sich möglicherweise auf verschiedenen Hardwareplattformen befindende Telekonferenzanwendungen weisen verschiedene Leistungsmöglichkeiten auf. Darüber hinaus wurde eine große Vielfalt von Leistungsmerkmalen in verschiedenen Telekonferenzanwendungen ausgeführt und die Verbreitung verschiedener Arten von Computersystemen mit unterschiedlichen Leistungen und verschiedenen Netzwerkmedien hat schwierige Aufgabenstellungen für die Durchführung von Telekonferenzen bewirkt.
Für die meisten Telekonferenzanwendungen wird zum Beispiel angenommen, dass der Sender und der Empfänger bestimmte minimale Leistungsmöglichkeiten aufweisen. Durch die große Mannigfaltigkeit von Systemen, die unterschiedliche Rechenleistungen aufweisen, und zusätzlich durch die große Vielfalt von Netzwerkmedien, können jedoch diese bestimmten Systeme bestimmte Leistungsmöglichkeiten nicht aufweisen. Das erste System kann zum Beispiel eine mit einem Hochleistungskommunikationsmedium gekoppelte sehr leistungsfähige Workstation sein. wohingegen ein zweites System einen Prozessor einer früheren Generation einsetzen, bei einer wesentlich geringeren Taktrate arbeiten und/oder mit einem Kommunikationsmedium geringerer Leistung gekoppelt sein kann. In bestimmten Netzwerkmedien können bestimmte Netzwerkleistungsfähigkeiten nicht vorhanden sein, wie zum Beispiel Multicast [Gruppenruf, Mehrpunktverbindung] oder andere Optimierungsleistungsmerkmale. Folglich können zur Funktion einiger Telekonferenzanwendungen die Teilnehmer der Konferenz nur bei der schnellstmöglichen Konfiguration arbeiten, die durch irgendein, möglicherweise an der Telekonferenz teilnehmendes, minimales System bereitgestellt wird. Dies führt natürlich zu bestimmten Ineffizienzen, insbesondere wenn zwei der Teilnehmer zur Übertragung mit einer höheren Leistung als das System mit der geringstmöglichen Leistungsmöglichkeit imstande sind.
Ein weiteres Problem von Telekonferenzanwendungen ist die Fähigkeit bestimmter Stationen an mehr als einer Telekonferenz teilzunehmen. Tatsächlich kann unter bestimmten Umständen die Zusammenführung mehrerer einzelner Konferenzen durch einen Anwender entsprechend den Betriebsverhältnissen gewünscht sein. Auf Grund der verteilten Beschaffenheit bestimmter Netzwerke können sich während dieser Zusammenführungsoperation bestimmte Verhältnisse ändern. Das bedeutet, während eine einzelne Station mehr als eine Konferenz, an der sie teilnimmt, zusammenführt, können sich bei einer zweiten Station an einem entfernten Standort weitere Betriebsverhältnisse ändern (z.B. verlassen, betreten Teilnehmer eine laufende Konferenz oder schließen sich dieser anderweitig an). Folglich wird die Verwaltung derartiger Zusammenführungsoperationen unangemessen aufwendig.
Ein weiterer Mangel bestimmter Telekonferenzanwendungen des Standes der Technik ist die Fähigkeit der Zuordnung unabhängiger Datenströme zu einer laufenden Telekonferenz. Ein Absenderteilnehmer kann zum Beispiel die Bereitstellung eines zusätzlichen Datenstromes an andere Teilnehmer in einer Telekonferenz wünschen. Diese zusätzliche Quelle kann Video, Daten, Audio oder irgendeine andere, dem Absenderteilnehmer zur Verfügungen stehende Art von Daten umfassen, ist aber nicht auf diese begrenzt. Eine derartige zusätzliche Quelle kann zum Beispiel andere Audioinformationen für einen Empfänger umfassen. Es kann auch die Zuordnung anderer Arten von Daten zu einer laufenden Telekonferenz wünschenswert sein, die einem anderen Teilnehmer der Telekonferenz zugänglich sein kann. Bestimmten Telekonferenzanwendungen des Standes der Technik fehlen diese Fähigkeiten.
Ein Beispiel einer Anordnung des Standes der Technik ist in EP 0 279 232 (IBM) offenbart.
ZUSAMMENFASSUNG
Gemäß der vorliegenden Erfindung wird ein Verfahren zum Aufbau einer Kommunikation zwischen zwei Endpunkten bereitgestellt, wobei das Verfahren umfasst:
dass ein erster Endpunkt einem zweiten Endpunkt mittels einer ersten Nachricht Kommunikationsleistungsmöglichkeiten bezeichnet;
wobei das Verfahren durch die Schritte gekennzeichnet ist:
dass der erste Endpunkt den zweiten Endpunkt mittels einer zweiten Nachricht über den Verbindungswunsch benachrichtigt, wobei die zweite Nachricht einen Zeitablauf- bzw. Zeitüberschreitungswert enthält;
dass der zweite Endpunkt den Zeitüberschreitungswert in der zweiten Nachricht prüft und den ersten Endpunkt mittels einer dritten Nachricht über eine Verbindungsbestätigung benachrichtigt; und
dass der erste und der zweite Endpunkt entsprechend den Kommunikationsleistungsmöglichkeiten eine Kommunikation aufbauen.
Gemäß der vorliegenden Erfindung wird ebenfalls ein erster Endpunkt zur Kommunikation mit einem oder mehreren Endpunkten bereitgestellt, wobei der erste Endpunkt gekennzeichnet ist durch:
Mittel zum Senden wenigstens einer Nachricht an einen zweiten Endpunkt zum Anzeigen eines Verbindungswunsches, wobei diese wenigstens eine Nachricht umfasst:
Kommunikationsleistungsmöglichkeiten des ersten Endpunktes und
einen Zeitüberschreitungswert, gemäß welchem der zweite Endpunkt antworten soll; und
Mittel zum Empfangen einer von dem zweiten Endpunkt gesendeten Verbindungsbestätigungsnachricht.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird als Beispiel und nicht als Begrenzung in den Fig. der beigefügten Zeichnungen veranschaulicht, in denen gleiche Bezugszeichen gleiche Elemente anzeigen und in denen:
1 eine beispielhafte Konfiguration veranschaulicht, in der verschiedene Ausführungsbeispiele der vorliegenden Erfindung ausgeführt werden können.
2 zeigt eine typische Telekonferenzanzeige, die während des Verlaufs der Telekonferenz sowohl Medien- als auch Nichtmedienquellen anzeigt.
3 zeigt ein einzelnes System, in dem Ausführungsbeispiele der vorliegenden Erfindung ausgeführt werden können.
4 zeigt eine beispielhafte Architektur eines Systems, das verschiedene Ausführungsbeispiele der vorliegenden Erfindung einsetzt.
5 zeigt eine detailliertere Ansicht der in 4 veranschaulichten Konferenzkomponente.
6 zeigt eine Folge typischer Konferenzereignisse in einer Konferenzkomponente, die an eine Anwendung ausgegeben werden.
7 zeigt eine typische Folge von für eine Teilnehmerinitialisierung in der Konferenzkomponente ausgeführten Schritten.
8–10 zeigen einen typischen Austausch von Nachrichten für verschiedene Operationen.
11 zeigt ein Detail eines ersten Endpunktes, der eine Telekonferenz aufbaut.
12 zeigt eine Folge von in einem zweiten Endpunkt ausgeführten Schritten, der während des Aufbaus der Telekonferenz vom ersten Endpunkt gesendete Nachrichten empfängt.
13–25 zeigen Details der zwischen den Endpunkten während verschiedener Telekonferenzanwendungen übertragenen Nachrichten.
26a–26b zeigen die zur Ausführung der Zusammenführungsoperationen unternommenen Schritte.
27a und 27b zeigen die Konferenzen vor und nach der Zusammenführungsoperation zwischen Telekonferenzen.
28a–b zeigen die von der Konferenzkomponente während einer Zusammenführungsoperation ausgeführte Folge von Schritten.
29 zeigt ein Beispiel einer zusammengeführten Konferenztabelle innerhalb eines einzelnen Teilnehmers.
30a–30b zeigt eine zur Konvertierung von Punkt-zu-Punkt-Verbindungen in Multicast-Verbindungen für eine Telekonferenz ausgeführte Folge von Schritten.
31 und 32 zeigen das Hinzufügen einer zusätzlichen Quelle und die Nachrichten während des Hinzufügens der Quelle zu einer bestehenden Telekonferenz.
33–34 zeigen die Details einer innerhalb eines Teilnehmers für das Hinzufügen einer zusätzlichen Quelle ausgeführten Folge von Schritten.
35a–35b zeigen eine beispielhafte Folge von zwischen einem ersten Endpunkt und einer Mehrzahl von anderen Endpunkten in einem Netzwerksystem gesendeten Nachrichten und zeigen verschiedene, dazwischen übertragene Nachrichten.
DETAILLIERTE BESCHREIBUNG
Die vorliegende Erfindung bezieht sich auf Netzwerksysteme. Insbesondere beschreibt die vorliegende Erfindung ein Nachrichtenaustauschprotokoll zum Aufbau und zur Aufrechterhaltung von Telekonferenzverbindungen zwischen einer Mehrzahl von Teilnehmern in einem Netzwerksystem. Anwendungen dafür umfassen das Übertragen von Anwendungs- und/oder Systemleistungsmöglichkeiten zwischen Teilnehmern oder potentiellen Teilnehmern einer Telekonferenz, das Benachrichtigen der Teilnehmer einer Telekonferenz, dass mehr als eine Telekonferenz zusammengeführt werden soll und das Hinzufügen eines zusätzlichen Datenstromes zu einer laufenden Telekonferenz. Obwohl die vorliegende Erfindung mit Bezug auf bestimmte spezifische Aus führungsbeispiele beschrieben werden wird, insbesondere mit Bezug auf bestimmte Hardwarekonfigurationen, Datenstrukturen, Pakete, Verfahrensschritte und andere spezielle Details, sollte dies nicht als Begrenzung der vorliegenden Erfindung betrachtet werden. Durch den Fachmann können verschiedene Modifikationen und anderes vorgenommen werden, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
Ein Teil der Offenbarung dieses Patentdokuments enthält Material, das dem Urheberschutz unterliegt. Der Inhaber des Urheberrechts hat keinen Einwand gegen die Faksimilewiedergabe durch irgendjemanden der Patentoffenbarung, wie sie in den Patentakten oder Aufzeichnungen des Patent- und Markenamtes erscheint. Ansonsten aber sind wem auch immer alle Urheberrechte vorbehalten. Das Urheberrecht hat Apple Computer, Inc.
Eine typische Systemkonfiguration, in der eine Telekonferenz stattfinden kann, ist in 1 als 100 veranschaulicht. Zum Beispiel kann wie veranschaulicht eine erste Workstation 150 über eine Telekonferenz mit einer zweiten Workstation 155 kommunizieren. Das System 150 kann eine zentrale Verarbeitungseinheit 150c umfassen, die mit einer Anzeige 150d, einer Videoeingabeeinrichtung 150a und einer Schalleingabeeinrichtung 150b gekoppelt ist. Das System 150 kann durch das Netzwerkmedium 170 über ein Netzwerkverbindungsmodul 160 mit dem anderen System 155 kommunizieren. 160 kann irgendeine Anzahl handelsüblicher Netzwerkadapter umfassen, wie zum Beispiel unter Verwendung von Ethernet, Token-Ring oder irgendeinem anderen handelsüblichen Netzwerkstandard. Man beachte, dass der Netzwerkadapter 160 auch einen drahtlosen Netzwerkadapter umfassen kann, der die Übertragung von Daten zwischen den Komponenten ohne ein Medium 170 ermöglicht. Die Kommunikation wird folglich über den mit dem System 155 gekoppelten Netzwerkadapter 165 bereitgestellt. Zwischen beiden Systemen kann eine bidirektionale Kommunikation aufgebaut werden. Das System 150 weist ferner eine Tastatur 150e und eine Zeigereinrichtung 150f auf, wie zum Beispiel eine Maus, einen Trackball oder irgendeine andere Einrichtung, um eine Anwenderauswahl und Anwendereingaben zu ermöglichen.
Eine Telekonferenzanzeige ist bei 200 in 2 gezeigt. In den ausgeführten Ausführungsbeispielen der vorliegenden Erfindung gibt es ein Ursprungsfenster [Source-Window], wie zum Beispiel 201, das einen Überwachungsbildschirm der lokalen Medienquelle zeigt. Es gibt andere Medienfenster, wie zum Beispiel 202 oder 203 für jeden anderen Anwender, mit dem ein Teilnehmer kommuniziert. Im veranschaulichten Beispiel stellt jedes der Fenster 201–203 Medieninformationen bereit, das heißt Echtzeitaudio- und/oder Videoinformationen zur bidirektionalen Durchführung einer Telekonferenz. In alternativen Ausführungsbeispielen der vorliegenden Erfindung können auch Nichtmedieninformationen, wie zum Beispiel 204, in der Telekonferenzanzeige angezeigt werden. Wie aus der nachstehenden Beschreibung ersichtlich wird, können zusätzlich zu den Medien- und Nichtmedieninformationen auch Nachrichtenaustauschinformationen zwischen den Stationen übertragen werden. Zusätzlich kann bei einer festgelegten Konferenz eine zusätzliche Medienquelle (z.B. Audio- oder Videoinformationen) übertragen werden. Die diesbezüglichen Details werden weiter unten diskutiert werden.
In den ausgeführten Ausführungsbeispielen der vorliegenden Erfindung wird ein Mehrzweckcomputersystem zur Ausführung der Telekonferenzanwendungen und der hier zu beschreibenden zugeordneten Prozesse verwendet. Obwohl bestimmte der hier zu beschreibenden Konzepte anhand der Durchführung einer Telekonferenz behandelt werden, ist ersichtlich, dass die Verfahren und zugehörigen Einrichtungen für andere Anwendungen ausgeführt werden können, wie zum Beispiel eine gemeinsame Nutzung von Dateien, eine Echtzeitdatenerfassung oder andere Anwen dungsarten, die Daten von einem ersten Teilnehmer zu einem zweiten Teilnehmer oder eine Gruppe von Teilnehmern senden. Es wird jetzt ein Computersystem beschrieben, wie zum Beispiel das zur Ausführung der Ausführungsbeispiele der vorliegenden Erfindung verwendete.
Ein Computersystem, wie zum Beispiel eine Workstation, ein Personalcomputer oder eine andere Verarbeitungseinrichtung 150c oder 155c, wie in 1 gezeigt, ist in 3 detaillierter veranschaulicht. 150c weist einen Bus oder ein anderes Kommunikationsmittel 301 zur Kommunikation von Informationen und ein mit dem Bus 301 gekoppeltes Verarbeitungsmittel 302 zur Verarbeitung von Informationen auf. Das System 150c weist ferner einen Speicher mit wahlfreiem Zugriff (RAM) oder eine andere Einrichtung mit flüchtigem Speicher 304 (als Hauptspeicher bezeichnet) auf, die zur Speicherung von Informationen und von durch den Prozessor 302 auszuführenden Anweisungen mit dem Bus 301 gekoppelt ist. Der Hauptspeicher 304 kann auch zur Speicherung temporärer Variablen oder anderer Zwischeninformationen während der Ausführung von Anweisungen durch den Prozessor 302 verwendet werden. Während der Laufzeit kann im Speicher 304 das Konferenzkomponentenmodul enthalten sein, das gemäß dem nachstehend zu beschreibenden Kommunikationsprotokoll arbeitet. Das System 150c weist auch einen mit dem Bus 301 zur Speicherung statischer Informationen und Anweisungen für den Prozessor 302 gekoppelten Nur-Lese-Speicher (ROM) und/oder eine andere statische Speichereinrichtung 306 und eine Datenspeichereinrichtung 307 auf, wie zum Beispiel eine Magnetplatte oder eine optische Speicherplatte und ihr entsprechendes Plattenlaufwerk. Die Datenspeichereinrichtung 307 ist zur Speicherung von Informationen und Anweisungen mit Bus 301 gekoppelt.
Das System 150c kann ferner mit einem mit Bus 301 zur Anzeige von Informationen für einen Computeranwender gekoppel ten Anzeigeeinrichtungsadapter 321 gekoppelt sein, wie zum Beispiel eine Kathodenstrahlröhre (CRT) oder eine Flüssigkristallanzeige (LCD). Eine derartige Anzeige 321 kann ferner für den Empfang von Video- oder Bildinformationen mit dem Bus 301 gekoppelt sein. Eine alphanumerische und andere Tasten umfassende alphanumerische Eingabeeinrichtung 322 kann zur Übermittlung von Informationen und einer Anweisungsauswahl an den Prozessor 302 auch mit Bus 301 gekoppelt sein. Eine zusätzliche Anwendereingabeeinrichtung ist die Cursorsteuerung 323, wie zum Beispiel eine Maus, ein Trackball, ein Stylus [Griffel] oder Cursorrichtungstasten. Sie ist zur Übermittlung von Richtungsinformationen und einer Anweisungsauswahl an den Prozessor 302 und zur Steuerung von Cursorbewegungen auf der Anzeige 321 mit dem Bus 301 gekoppelt. Für Telekonferenzanwendungen kann das System 150c auch eine mit sich gekoppelte Schallausgabeeinrichtung 324, eine Videoeingabeeinrichtung 325 und eine Schalleingabeeinrichtung 326 zusammen mit den zugehörigen D/A(Digital-Analog)- und A/D(Analog-Digital)-Wandlern zur Eingabe oder Ausgabe von Mediensignal-Bitströmen aufweisen. Das System 150c kann ferner mit einer Kommunikationseinrichtung 327 gekoppelt sein, die zur Kommunikation mit anderen Telekonferenzstationen mit dem Netzwerkadapter 160 gekoppelt ist.
Man beachte auch, dass irgendeine oder alle Komponenten von System 150c und die zugehörige Hardware in den verschiedenen Ausführungsbeispielen verwendet werden können. Es sollte jedoch verstanden werden, dass irgendeine Konfiguration des Systems für verschiedene Zwecke gemäß der speziellen Ausführung verwendet werden kann.
In einem Ausführungsbeispiel ist das System 150c eines aus der Apple Computer^® Marken-Familie von Personalcomputern wie zum Beispiel der von Apple Computer, Inc. aus Cupertino, Kalifornien, hergestellte Personalcomputer der Marke Macintosh 8100. Der Prozessor 302 kann einer der von Motorola, Inc. aus Schaumburg, Illinois, hergestellten Mikroprozessoren der Marke PowerPC sein.
Man beachte, dass die folgende, hier behandelte Erörterung der verschiedenen Ausführungsbeispiele sich insbesondere auf eine Reihe von Routinen beziehen wird, die in einer höheren Programmiersprache (z.B. die C- oder C++-Programmiersprache) erzeugt und kompiliert, verbunden und dann im System 150c während der Laufzeit als Objektcode im Hauptspeicher 304 durch den Prozessor 302 ausgeführt werden. Der Objektcode kann zum Beispiel durch den von Symantec, Inc. aus Cupertino, Kalifornien, verfügbaren C++-Compiler erzeugt werden.
Obwohl ein Mehrzweckcomputersystem beschrieben wurde, sollte jedoch von einem Fachmann verstanden werden, dass die folgenden Verfahren und Einrichtungen in speziellen Hardwareeinrichtungen ausgeführt werden können, wie zum Beispiel diskrete Logikeinrichtungen, integrierte Großschaltungen (LSI's), anwendungsspezifische integrierte Schaltungen (ASIC's) oder andere Spezialhardware. Die Beschreibung weist hier eine gleiche Anwendung für gleichartige Funktionen aufweisende Einrichtungen auf.
4 veranschaulicht eine Mehrzahl von Verfahren und/oder Einrichtungen, die innerhalb des Systems 150c wirksam sein können. Auf der höchsten Schicht, zum Beispiel auf der höchsten Schicht im ISO/OSI-Netzwerkmodell, kommuniziert ein Anwendungsprogramm 401, wie zum Beispiel eine Telekonferenzanwendung, ein Audio-/Videoserver oder ein Datenserver, mit dem Konferenzkomponentenprozess 400 in Form von Anwendungsprogrammschnittstellen(API)-Aufrufen. Die Konferenzkomponente 400 ermöglicht der Anwendung den Aufbau von Kommunikationen zwischen zwei oder mehr Telekonferenzstationen. Zwischen dem ersten Teilnehmersystem und einem zweiten Teilnehmersystem können Steuerinformationen und Medieninformationen übertragen werden. Die Konferenzkomponente wird in 5 detaillierter gezeigt werden. Die Konferenzkomponente 400 kommuniziert mit der Transportkomponente 402 durch das Senden von MovieTalk-Nachrichten für andere Telekonferenzstationen. Diese werden gekapselt und in einer Form angeordnet, die die Transportkomponente 402, die Netzwerkkomponente 403 und die Systemnetzwerkkomponente 404 paketieren und über das Netzwerkmedium 170 übertragen können. Für die weitere Offenbarung werden bestimmte MovieTalk-API-Aufrufe und zwischen den Konferenzkomponenten in einem Telekonferenzsystem übertragene MovieTalk-Nachrichten detaillierter beschrieben werden.
Die Transportkomponente 402 und die Netzwerkkomponente 403 stellen die notwendigen Operationen zur Kommunikation über die jeweilige Art des Netzwerkadapters 160 und das Netzwerkmedium 170 gemäß der Ausführung bereit. Die Netzwerkkomponente 402 kann zum Beispiel die TCP- oder ADSP-Protokolle und -Paketierungen gemäß diesen entsprechenden Standards bereitstellen.
Eine detailliertere Ansicht der Konferenzkomponente 400 ist in 5 gezeigt. Speziell ist die Konferenzkomponente 400 in zwei Teilen 400a und 400b gezeigt, die die Eingangs- und Ausgangsteile der Konferenzkomponente zeigen. Obwohl sie als getrennte Sender und Empfänger veranschaulicht sind, weist jede Konferenzkomponente im System beide Leistungsmöglichkeiten auf, so dass eine vollständig bidirektionale Kommunikation zwischen den Konferenzkomponenten in den entsprechenden Teilnehmertelekonferenzsystemen in einem Netzwerk miteinander stattfinden kann. Wie veranschaulicht, empfängt der Eingabeteil der Konferenzkomponente 400a über die Medieneingabekanäle 510 und 520 Video- und Schallinformationen. Die Videokanalkomponente und die Schallkanalkomponente 504 präsentieren dem Sequence Grabber 502 in regelmäßigen Intervallen Mediendaten. Die Echtzeitschall- und -Videodaten (nachfolgend als „Medien daten" bezeichnet) werden von dem Sequence Grabber 502 einem Quellstrom-Director (source stream director) 500 bereitgestellt, der die Mediennachrichten dann der Transportkomponente 402 bereitstellt. Die Ablaufsteuereinrichtung 501 lässt dann die Video- und Schalldaten mit einer ausführungsabhängigen Häufigkeit durchlaufen. Die Videokanalkomponente 503, die Schallkanalkomponente 504 und der Sequence Grabber 502 sind alle unter Verwendung von Produkten des Standes der Technik ausgeführt, wie zum Beispiel den handelsüblichen (z.B. der von Apple Computer, Inc. aus Cupertino, Kalifornien, erhältliche QuickTime-Videokanal, den Schallkanalkomponenten und den Sequence Grabbern). Die Ablaufsteuereinrichtung 501 kann unter Verwendung bekannter, handelsüblicher Ablaufsteuereinrichtungen und/oder Verfahren ausgeführt werden, wie zum Beispiel diejenigen, die den Ablauf basierend auf der Bandbreite und anderer Beschränkungen im Absenderteilnehmersystem regeln. Die Konferenzkomponente weist ferner einen Senkenstrom-Director (sink stream director) 510 auf, der einen Teil der Komponente 400b der Konferenzkomponente zum Empfang von Mediendaten von der Transportkomponente 402 aufweist. Eine entsprechende Ablaufsteuereinrichtung 511, die Video- und Schallstrom-Wiedergabeeinrichtungen 512 und 513 und der Kompressions- und Schallmanager 514 und 515 für die Ausgabe der Videoströme 530 und 540 bilden auch einen Teil der Konferenzkomponente für vollständig bidirektionale Konferenzleistungsmöglichkeiten.
Die Hauptfunktion einer Konferenzkomponente ist der Aufbau und die Aufrechterhaltung einer bidirektionalen Verbindung zwischen allen Konferenzteilnehmern. Die Konferenzanwendungen verwenden zum Austausch von für die Konferenz relevanten Steuerdaten einen vorab aufgebauten Steuerkanal. Diese Daten können Anwenderidentifizierungsinformationen oder andere, den Betrieb der Anwendung betreffende Informationen umfassen. Die Konferenzanwendungen (z.B. 401) definieren durch den Aufbau ihrer eigenen Steuerprotokolle das Format und den Inhalt dieser Steuernachrichten. Ferner baut die Konferenzkomponente unter Verwendung der zu Grunde liegenden Transportkomponente 402 Kommunikationskanäle zwischen einem ersten Endpunkt und einem zweiten Endpunkt auf. Auf diese Weise verwendet die Konferenzkomponente den zur Übertragung von Medien- und Nichtmedieninformationen bereitgestellten Medienkanal der Transportkomponente 402, sobald ein Medienkanal aufgebaut wurde. Für den Rest dieser Anmeldung wird jedoch der Fokus auf dem Aufbau der Kommunikation zwischen einem ersten und einem zweiten Teilnehmer (als Endpunkte bezeichnet) oder einer Gruppe von Teilnehmern, die an einer Telekonferenz teilnehmen können, liegen.
ANWENDUNGSPROGRAMMSCHNITTSTELLE (API)
Das Anwendungsprogramm 401 steuert durch die Ausgabe von MovieTalk-Anwendungs-API-Aufrufen die Konferenzkomponente 400. Die Konferenzkomponente arbeitet unter Verwendung eines ereignisorientierten Modells, in dem Anwendungs-relevante Ereignisse an das Anwendungsprogramm ausgegeben werden. Das Anwendungsprogramm kann dann entweder durch eine innere Modifizierung der internen Datenstrukturen (Erzeugung einer Quelle oder Senke) und/oder eine Ausgabe geeigneter Nachrichten über das Netzwerk an andere verbundene Teilnehmer oder potentielle Teilnehmer eine geeignete Maßnahme ergreifen. Gemäß den von der Konferenzkomponente empfangenen Nachrichten, einem momentanen Kontext und den API-Aufrufen der Anwendung kann die Konferenzkomponente eine geeignete Maßnahme ergreifen. Ein vollständiges, die API für die Konferenzkomponente behandelndes Dokument ist in der Anlage als Anhang A beigefügt.
Eine typische Folge von Ereignissen, die nach dem Aufbau einer Telekonferenz durch die Konferenzkomponente in einer Anwendung auftreten, ist in 6 als 600 veranschaulicht. Zum Beispiel wird bei einem anfänglichen Wunsch einer Anwendung einer Konferenz beizutreten (ausgedrückt durch einen API-Aufruf) oder einem Anruf von einem anderen Teilnehmer ein Konferenz-Bereit-Ereignis 601 erzeugt. Die Anwendung erzeugt dann in der Konferenzkomponente (z.B. Teilnehmer A) eine Medienquelle, die die Konferenzinformationen bereitstellt. Im Anschluss daran können in Schritt 610 auch irgendwelche zusätzlichen Medienquellen als zweite Medienquelle an die Hauptkonferenz angeschlossen werden. Dann wird durch den Empfang von Teilnehmer-Bereit[MemberReady]-Ereignissen (z.B. 602 und 603 von 6) die Bereitschaft irgendwelcher neuen Konferenzteilnehmer erkannt. Dies baut die Mediensenken auf, wie zum Beispiel die in 6 veranschaulichten b und c. Während der Telekonferenzsitzung kann dann eine Vielfalt anderer Ereignisse 604 ausgegeben und von der Konferenzkomponente befolgt werden. Diese können Nachrichtenereignisse, Betriebsartereignisse, Ereignisse eingehender Anrufe, Datenübertragungsereignisse etc. umfassen. Die die Konferenz verlassenden Teilnehmer führen zur Ausgabe von Teilnehmer-Beendet[MemberTerminated]-Ereignissen an das Anwendungsprogramm, wie zum Beispiel 605 oder 606. Folglich gibt es für jedes Teilnehmer-Bereit-Ereignis für jeden an der Konferenz teilnehmenden Teilnehmer ein entsprechendes Teilnehmer-Beendet-Ereignis vor dem Ende der Konferenz. Zusätzlich werden die zusätzliche Quelle und die Konferenz selbst über das Zusatz-Beendet[Auxiliary Terminated]-Ereignis 611 und das Konferenz-Beendet-Ereignis 607 beendet, wie in 600 von 6 veranschaulicht. Dies benachrichtigt die Anwendung, dass die Konferenz beendet ist und die Telekonferenzdaten nicht länger übertragen werden sollten. Irgendwelche zusätzlichen Aufräumungsoperationen werden dann von der Anwendung ausgeführt und die Quelle kann entfernt werden.
Die Initialisierung einer typischen Anwendung ist als Verfahren 700 von 7 gezeigt. Das Anwendungsprogramm führt eine Reihe von API-Aufrufen aus, um verschiedene, dem Teilnehmer oder potentiellen Teilnehmer zugeordnete Parameter einzustellen. Zuerst kann eine Anwendung in Schritt 702 die Konferenzkomponente zum Einstellen ihrer Leistungsmöglichkeit veranlassen, wenn sie sich von der Standardeinstellung unterscheidet. Der Aufruf an „MTConferenceSetMessageCapabilities" [MTKonferenzEinstellungNachrichtLeistungsmöglichkeiten] veranlasst die Konferenzkomponente, aus einem Speicher die speziellen Anwendungsleistungsmöglichkeiten in die Konferenzkomponente für die spezielle Konferenz abzurufen. Diese werden später während der Übertragung von Nachrichten zur Warnung der Empfänger verwendet, dass die Senderanwendung bestimmte funktionale Leistungsmöglichkeiten vor dem Aufbau einer Verbindung zwischen dem Sender und dem Empfänger aufweist. Jeder Leistungsmöglichkeit ist ein Typ, eine Version und ein „Wunsch" der Leistungsmöglichkeit zugeordnet. Jeder Wunsch für jeden Leistungsmöglichkeitstyp kann markiert sein als:

1. optional;
2. gewünscht;
3. erforderlich; oder
4. eine Verhandlungsnachricht.

Diese Arten von Leistungsmöglichkeiten sind in einer Liste der Leistungsmöglichkeiten enthalten, die wie nachstehend beschrieben werden wird, zu den Endpunkten übertragen wird. Eine „optionale" Leistungsmöglichkeit ist eine Nachricht, deren Austausch vor der Einrichtung einer Konferenz nicht erforderlich ist. Eine „gewünschte" Leistungsmöglichkeit ist eine, deren Austausch vor der Einrichtung einer Konferenz nicht erforderlich ist, sie wird jedoch bevorzugt. Eine „erforderliche" Leistungsmöglichkeit ist eine, die den Austausch einer Nachricht vor der Einrichtung einer Konferenz erfordert. Dies kann eine Zugriffssteuerung oder andere, vor der Einrichtung einer Konferenz übertragene Nachrichten umfassen. Eine Zugriffssteuerungsleistungsmöglichkeit kann die Übertragung einer Kontonummer und eines Passwortes vor dem Beginn einer Telekonferenz umfassen. Eine „verhandelte Nachricht" ist eine Leistungsmöglichkeit, die anzeigt, dass die Anwendung eine Abfrage der empfangenden Anwendung unter der Verwendung von Nachrichten wünscht. Im Fall einer verhandelten Nachrichtenleistungsmöglichkeit ermöglicht das der Leistungsmöglichkeit zugeordnete Typenfeld die Anforderungen von Informationen über die Anwendungen vor dem Aufbau einer Konferenz. Irgendwelche anderen, verhandelte Informationen zwischen den Anwendungen erfordernden Austauscharten können eingestellt werden.
Sobald in Schritt 702 alle einzelnen Leistungsmöglichkeiten durch die Ausgabe von „Einstellung Leistungsmöglichkeiten"-API-Aufrufen an die Konferenzkomponente eingestellt wurden, kann ein Teilnehmer in Schritt 704 seine Betriebsart einstellen. Die Betriebsart wird im Betriebsartmaskenwert enthalten sein, der im API-Aufruf zur Konferenzkomponente gesendet wird. Darüber hinaus ist er in bestimmten, von der Konferenzkomponente im Sender zur Konferenzkomponente im Empfänger übertragenen Nachrichten enthalten. Die Betriebsartmaske spezifiziert die Eigenschaften einer Konferenz, die der Teilnehmer zur Verfügung stellt. Verschiedene Leistungsmöglichkeiten, Betriebsarten und andere, in 7 gezeigte Initialisierungswerte können für eine beliebige Anzahl von durch den Teilnehmer zur Verfügung gestellte Konferenzarten eingestellt werden. Auf jeden Fall umfasst die Standardbetriebsart die folgenden Werte:

1. Sende Medien;
2. Empfange Medien;
3. Gemeinsam nutzbar; und
4. Verbinder [Joiner];

Das „Sende Medien"-Betriebsartflag zeigt an, das der Teilnehmer in seinen Konferenzen die Sendung von Mediendaten beabsichtigt. Die meisten Teilnehmer werden Medien senden wollen. Es wird jedoch Umstände geben, in denen der Teilnehmer ein nur empfangender Teilnehmer sein wird. Folglich wird das Sende-Medien-Betriebsartflag nicht gesetzt sein. Das Empfange-Medien-Betriebsartflag zeigt an, dass der Teilnehmer in Konferenzen den Empfang von Medien beabsichtigt. Im Fall eines nur sendenden Teilnehmers (z.B. ein eine Echtzeitvideo- und/oder eine Audioquelle bereitstellender Server) wird das Empfange-Medien-Betriebsartflag auf „aus" (z.B. ein numerischer Wert ,0') gesetzt sein. Das „Gemeinsam Nutzbar"-Betriebsartflag zeigt an, dass der Teilnehmer zur gemeinsamen Nutzung der Konferenzdaten mit neuen Konferenzteilnehmern bereit ist. Folglich wird im Fall eines nur sendenden Medienservers das Gemeinsam-Nutzbar-Betriebsartflag gesetzt sein. Dies zeigt an, dass neue Teilnehmer die Konferenzdaten empfangen können.
Das „Verbinder"-Betriebsartflag zeigt an, dass allen Konferenzteilnehmern ein Interagieren möglich ist. Dies würde eine Zweiwegeübertragung zwischen allen Konferenzteilnehmern ermöglichen. Das Setzen dieses Flags auf „aus" (z.B. ein numerischer Wert ,0') führt jedoch zu Konferenzen vom Broadcast- bzw. Rundsendetyp, in denen ein Teilnehmer Mediendaten an andere Konferenzteilnehmern sendet, aber die einzelnen Konferenzteilnehmer nicht irgendwelche Mediendaten untereinander austauschen. Jedes dieser Betriebsartflags wird zu Beginn einer Verbindung (z.B. in der „Hallo"-Nachricht 1400 in 14 enthalten) übertragen.
Standardmäßig baut die Konferenzkomponente Konferenzen auf, die vollständig Zweiwege-mediendatenfähig, gemeinsam nutzbar und verbindbar sind. Wenn andere Eigenschaften gewünscht sind, muss die Anwendung in Schritt 704 zusammen mit den entsprechenden gesetzten Flag(s) „Setze Betriebsart" aufrufen. Die Konferenzbetriebsarteinstellungen werden gespeichert und einer speziellen Konferenz-ID in der Konferenzkomponente des Senders zugeordnet, so dass bei der Erzeugung von Nachrichten für diese Konferenz-ID, die entsprechenden Betriebsartflags zusammen mit der Initialisierung oder mit anderen, vor irgendeiner anderen Kommunikation gesendeten Nachrichten übertragen werden.
Zusätzlich zu den Leistungsmöglichkeiten und Betriebsarteinstellungen in Schritt 702 und 704 wird ein den vom Teilnehmer plazierten Anrufen zugeordneter Zeitüberschreitungswert eingestellt. Der Zeitüberschreitungswert wird dann am Anfang bestimmter, einer Konferenz vorausgehender Nachrichten eingefügt, um einem Empfänger zu ermöglichen, festzustellen, wann der Anrufer den Empfang von Antworten anhalten wird. Dies ermöglicht die Einbeziehung bestimmter Leistungsmerkmale in die Konferenzkomponenten der Teilnehmer, wie zum Beispiel die auf dem Kontext basierende, geschickte Auslösung (smart triggering) von Ereignissen. Wenn zum Beispiel der Empfänger einen Anruf empfängt, der Anwender aber zu diesem Zeitpunkt den Anruf nicht zu übernehmen wünscht, weiß die Konferenz des Empfängers, dass die Zeitüberschreitung auftritt und kann eine bestimmte kontextabhängige Maßnahme ergreifen (z.B. den Anruf weiterleiten, eine Nachricht senden etc.).
Die Anwendung kann dann einen API-Aufruf „Empfang eines Anrufs" aufrufen, der die Schritte 708 und 710 ausführt. In Schritt 708 wird unter Verwendung des zu Grunde liegenden Transportes, mit dem das System verbunden ist, eine Adresse der höheren Schicht registriert und veröffentlicht. Dies ermöglicht dann anderen potentiellen Teilnehmern im System den Anruf des Teilnehmers. Die Registrierung und Veröffentlichung der Adresse ist in Abhängigkeit vom Medium, mit dem das System verbunden ist, ausführungsabhängig. In Schritt 710 wartet dann die Konferenzkomponente auf eingehende Anrufe.
Die Konferenzkomponente im Teilnehmer tritt in einen Ruhezustand ein, in dem eingehende Nachrichten, Warnungen für die Transportkomponente, API und Anrufe erfasst und danach gehandelt wird. Man beachte, dass alle Leistungsmöglichkeiten und Betriebsartwerte optional sind und die Standardeinstellungen vom Teilnehmer verwendet werden können, wenn von der Anwendung keine dieser Funktionen erforderlich ist. Im Aufruf der Funktion MTConferenceListen [MTKonferenzEmpfangen] muss die Anwendung die Netzwerke spezifizieren, an denen der Teilnehmer zur Annahme von Anrufen bereit ist. Die Konferenzkomponente setzt mit der Registrierung des Teilnehmers an diesen Netzwerken fort, führt das in den verschiedenen Netzwerkkontexten Geeignete aus und sendet ein mtListenerStatus[mtEmpfängerStatus]Ereignis an die Anwendung zur Spezifizierung, ob der Registrierungsversuch erfolgreich war. Wenn eine andere Anwendung den Aufbau einer Kommunikation mit der Anwendung wünscht, nachdem die Empfänger betriebsbereit sind, wird ein mtIncomingCallEvent[mtEingehenderAnrufEreignis] an die Anwendung weitergeleitet.
Die 8–10 zeigen Beispiele der verschiedenen, zwischen zwei Endpunkten ausgetauschten Nachrichten. Die Nachrichten werden in Abhängigkeit vom Betriebskontext und den Anwendungsaufrufen von der Konferenzkomponente 400 erzeugt. 8 zeigt ein Beispiel einer Anruffolge zur Einrichtung einer Konferenz zwischen zwei Endpunkten. Zu Beginn eines Anrufes von einem ersten Endpunkt, wie zum Beispiel der in 8 gezeigte 810, und einem zweiten Endpunkt, wie zum Beispiel der in 8 gezeigte 820, wird eine „Leistungsmöglichkeiten"-Nachricht 802 vom Endpunkt 810 zum Endpunkt 820 übertragen, wenn sie vom Anrufer eingestellt wurden. Der Austausch der „Leistungsmöglichkeiten"-Nachrichten 802 und 812 zwischen dem Endpunkt 1 810 und dem Endpunkt 2 820 erfolgt, nachdem auf dem Übertragungsmedium zwischen den Teilnehmern ein Steuerkanal in einer ausführungsabhängigen Art und Weise eröffnet wurde. Dies kennzeichnet die Leistungsmöglichkeiten jedes Endpunktes, wenn die Übertragung der Leistungsmöglichkeiten der Anwendung gewünscht ist. Sobald die Leistungsmöglichkeiten von jedem Endpunkt übertragen wurden, überträgt jeder Endpunkt ferner zur Selbstidentifizierung die Hallo-Nachrichten 804 und 814. Die Details der in der Figur veranschaulichten Leistungsmöglichkeiten, Hallo-Nachrichten und anderer Nachrichten werden nachstehend behandelt. Die Hallo-Nachricht ist der erste Schritt beim Aufbau einer Konferenz und ermöglicht den Konferenzkomponenten in verschiedenen Systemen den Austausch grundlegender Kennzeichnungen und Betriebsartinformationen. Im Anschluss an den Austausch der Leistungsmöglichkeiten-Nachrichten (sofern vorhanden) und der Hallo-Nachrichten 804 und 814 sendet der die Konferenz einzurichten wünschende Endpunkt 1 810 eine Anruf-Nachricht 806 an den Endpunkt 2 820. Im Anschluss daran sendet der Endpunkt 820 eine Antwort-Nachricht 816 an den Endpunkt 1 810, wenn er in die Telekonferenz mit dem Endpunkt 1 810 eingreifen möchte. Bei der Übertragung der Anruf-Nachricht 806 und dem Empfang der Antwort-Nachricht 816 wird dann eine Telekonferenz zwischen dem Endpunkt 1 810 und dem Endpunkt 2 820 aufgebaut. Die Details der in jedem Endpunkt ausgeführten Verfahrensschritte werden mit Bezug auf die 11 und 12 ausgeführt.
9 veranschaulicht ein „Verbinden"-Protokollverfahren. Dies ist dem Anrufverfahren ähnlich. Es wird jedoch eine „Verbinden"-Nachricht 906 anstatt der „Anruf"-Nachricht 806 an den zweiten Endpunkt gesendet. Die Details eines Verbindens werden nachstehend mit Bezug auf die 26a–26c behandelt.
10 veranschaulicht die für eine Beenden-Nachricht ausgetauschten Nachrichten. Wie veranschaulicht ist, kann ein Endpunkt eine Beenden-Nachricht zum Beenden einer Telekonfe renz ausgeben. Es ist keine Antwort für irgendwelche Empfänger erforderlich.
11 zeigt die von einem, den Aufbau der Kommunikation mit einem zweiten Teilnehmersystem (z.B. Endpunkt 2 820) wünschenden, ersten Teilnehmer (z.B. Endpunkt 1 810) ausgeführten Verfahrensschritte. Zuerst greift der Anrufer in Schritt 1102 über ausführungsabhängige Mittel entweder durch einen Verweis auf einen internen Speicher, der auf einen Server verweist, oder eine andere ausführungsabhängige Art und Weise auf die Adresse des Teilnehmers zu, den er anzurufen wünscht. Sobald dies ausgeführt wurde, ruft die Anwendung in Schritt 1104 den API-Aufruf MTConferenceCall [MTKonferenzAnruf] zum Anruf des Teilnehmers auf. Als Reaktion darauf wird vom Anrufer entweder ein Misserfolgsereignis 1106 oder, wenn die Anrufnachricht zum zweiten Teilnehmer übertragen wurde, ein Klingelereignis 1108 empfangen. Im Falle eines Klingelereignisses kann dann der Endpunkt die Leistungsmöglichkeiten, die Betriebsart und den Namen des Endpunktes erhalten, beispielsweise durch eine Prüfung der in der Leistungsmöglichkeiten-Nachricht 812 und/oder der Hallo-Nachricht 814 enthaltenen Daten. Jede „erforderliche" Kommunikation zwischen dem Anrufer und dem Empfänger kann ebenfalls ausgeführt werden. Dann kann sich der erste Sender in geeigneter Weise für den zweiten Endpunkt konfigurieren. Sobald irgendein notwendiger Nachrichtenaustausch und/oder Konfigurationen im Anrufer ausgeführt wurden, wird der Anrufer entweder ein Teilnehmer-Bereit-Ereignis 1116 oder ein Teilnehmer-Abgelehnt[MemberRefused]-Ereignis 1112 empfangen, wenn zum Beispiel der anrufende Teilnehmer nicht die notwendige Zugriffssteuerung im Anschluss an die Anrufnachricht bereitstellt. Zu jedem Zeitpunkt kann auch ein von einem Teilnehmer-Beendet-Ereignis 1114 gefolgtes Misserfolgsereignis 1106 erfasst werden. Im Falle eines Teilnehmer-Abgelehnt-Ereignisses 1112 wird dann die Konferenzkomponente ein Teilnehmer- Beendet-Ereignis 1114 erzeugen und ein das Ende der Konferenz anzeigendes Konferenz-Beendet-Ereignis wird ausgegeben. Sobald die Leistungsmöglichkeiten erhalten wurden, werden in Schritt 1113 alle erforderlichen Leistungsmöglichkeiten überprüft. Im Anschluss daran kann ein Teilnehmer-Bereit-Ereignis 1116 von der Anwendung empfangen werden. Der Endpunkt kann sich dann an dem Austausch von während einer Konferenz üblichen Nachrichten beteiligen. Folglich wird in Schritt 1118 die Konferenz begonnen.
Die Folge der vom Empfänger ausgeführten Schritte wird, wie in 12 gezeigt, veranschaulicht. In Schritt 1202 wird zum Beispiel die Empfängeranwendung ein Eingehender-Anruf-Ereignis 1202 erfassen. Im Anschluss daran kann der Empfänger die Betriebsart, die Leistungsmöglichkeiten, den Namen des Anrufers, den Namen der Konferenz und/oder die Rückgabeadresse des Teilnehmers, der in die Konferenz eingreifen möchte, bestimmen. Die Betriebsart kann auch in Schritt 1206 überprüft werden. Sobald dies ausgeführt ist, kann dann, wenn überhaupt, bei 1208 eine Zeitüberschreitungsprüfung im Empfänger ausgeführt werden. Die Zeitüberschreitungsprüfung wird in Abhängigkeit von der Ausführung einer Anwendung durch die Prüfung des in 15 in Feld 1504 gezeigten Zeitüberschreitungsfeldes ausgeführt, das anzeigt, wie lange der Sender wartet, bevor er eine Zeitüberschreitung verursacht und zum Beenden des Anrufes ein AnrufFehlgeschlagen[CallFailed]-Ereignis erzeugt. In diesem Fall kann der Empfänger gemäß der Ausführung eine Vielfalt von Dingen ausführen, zum Beispiel die Ausgabe eines Besetzt-Signals an den Sender, die Ausgabe einer Nachricht an den Anrufer oder das Ergreifen einer Maßnahme, wie zum Beispiel die Weiterleitung des Anrufs zu einem anderen Teilnehmer. Folglich ermöglicht die Einbettung des Zeitüberschreitungsfeldes 1504 in die Anfangsverbindungsnachricht „Hallo" bestimmte intelligente Leistungsmerkmale der potentiellen Teilnehmer einer Telekonferenz. Sobald alle Zeitüberschreitungsprüfungen, wenn überhaupt, in Schritt 1206 ausgeführt wurden, dann folgt Schritt 1208. Irgendeine Anwenderinteraktion kann in Schritt 1209 stattfinden. Der Empfänger wird dann in Schritt 1210 eine Rückmeldung ausgeben. Die Rückmeldung kann entweder eine Ablehnung der Beantwortung des Anrufes (z.B. auf Grund der Zugriffssteuerung oder der Teilnehmer beteiligt sich bereits an einer anderen Konferenz) oder eine Auswahl einer den Anruf bestätigenden Beantwortung, die den möglichen Beginn der Telekonferenz anzeigt, anzeigen. Im Fall einer Ablehnung wird das Teilnehmer-Beendet-Ereignis 1220 an die Anwendung ausgegeben. Im Fall der Antwort des Teilnehmers wird das Teilnehmer-Bereit-Ereignis 1218 ausgegeben, das anzeigt, dass der Medienkanal geöffnet ist und die Konferenz begonnen werden kann.
Konferenznachrichten
Die Konferenzkomponenten tauschen zum Aufbau, zur Aufrechterhaltung und zum Beenden von Konferenzen eine Anzahl von Nachrichten aus. Die Konferenzkomponenten senden auch Nachrichten, die Anwenderdaten kapseln, das heißt die durch die, die Konferenz verwendenden Programme ausgetauschten Daten.
Nach dem Aufbau einer Transportverbindung, jedoch vor dem Aufbau eines Konferenzkanals mit einem entfernten System kann ein Konferenzteilnehmer entweder eine Nachricht der Leistungsmöglichkeiten 1300 oder eine Zusatz-Nachricht 1700 senden. Der Teilnehmer sendet dann zur Selbstidentifikation eine Hallo-Nachricht 1400, insbesondere seine Betriebsart (Medien senden, Medien empfangen, gemeinsam nutzbar oder Verbinder) gefolgt von einer Anruf-Nachricht 1500 (zur Einrichtung einer Konferenz) oder einer Verbinden-Nachricht 1800 (um sich mit einer laufenden Konferenz zu verbinden). Der entfernte Teilnehmer sendet eine Antwort-Nachricht 1600 als Antwort auf die Anruf- oder eine Verbinden-Nachricht 1800. Sobald eine Konferenz auf gebaut ist, kann ein Teilnehmer Anrufe oder Konferenzen durch das Senden einer Zusammenführ-Nachricht 1900 zusammenlegen. Die Konferenzteilnehmer können zum Beenden einer Konferenz eine Beenden-Nachricht 2300 senden oder empfangen. Die Verbindungen zwischen den Teilnehmern einer Konferenz sind zu Beginn Punkt-zu-Punkt-Verbindungen. Wenn das Transportmedium Multicast-Adressen unterstützt und mehr als ein Teilnehmer an einer Konferenz teilnimmt, kann das Senden an eine Multicast-Adresse zur Optimierung verwendet werden. Die Konferenzkomponente verwendet zur Verhandlung des Übergangs von Punkt-zu-Punkt- zu Mehrpunktverbindungen unter Verwendung von Multicast-Adressen die Rundsende-Anforderungs[BroadcastRequest] und Rundsende-Bestätigungs[BroadcastAck] – Nachrichten 2400 und 2500.
Allen im Konferenznachrichtenprotokoll unterstützten Nachrichten ist ein 2-Byte Zeichen vorangestellt, das die Art der Nachricht kennzeichnet. Zum Beispiel enthält das Feld 1302 einer in 13 gezeigten Nachricht der Leistungsmöglichkeiten ein 'K'. Alle Nachrichten werden ferner mit einer NULL beendet, wie zum Beispiel die im Feld 1308 von 13 gezeigte. Die Nachricht der Leistungsmöglichkeiten 1300 gestattet einem potentiellen Teilnehmer eine Mitteilung an andere potentielle Konferenzteilnehmer was er in einer Konferenz ausführen und nicht ausführen kann. Jeder Teilnehmer sendet diese Nachricht vor dem Senden der „Hallo"-Nachricht (1400 von 14), wenn andere Leistungsmöglichkeiten als die Standardeinstellung unterstützt werden.
Liste der Leistungsmöglichkeiten 1306
Die Leistungsmöglichkeiten eines Teilnehmers. Dieses Feld ist optional. Falls es angegeben ist, enthält es eine Liste der Leistungsmöglichkeiten des Teilnehmers. Eine Anwendung gibt ihre Leistungsmöglichkeiten durch den Aufruf der Funktion MTConferenceSetMessageCapabilities [MTKonferenzEinstellenNachrichtLeistungsmöglichkeiten] der Konferenzkomponente an.
Die in 13 gezeigte Nachricht der Leistungsmöglichkeiten 1300 informiert andere potentielle Konferenzteilnehmer über die Leistungsmöglichkeiten eines Teilnehmers. Diese Leistungsmöglichkeiten beziehen sich direkt auf Nachrichten, die der Teilnehmer entweder unterstützt oder anfordert, jeweils eine Leistungsmöglichkeit für jede von der Komponente unterstützte Konferenznachrichtenart. Die Nachrichten selbst sind durch die Art der vom Teilnehmer in Betrieb genommenen Anwendung definiert. Zum Beispiel liefern Bildtelefonanwendungen und Chat[Plaudern]-Leitungen verschiedene Dienste und verwenden dazu verschiedene Nachrichten. Folglich werden sich die von einem Teilnehmer unterstützten Leistungsmöglichkeiten angesichts der an der Konferenz teilnehmenden Anwendung ändern. Die Einträge im Feld Liste der Leistungsmöglichkeiten können Informationen vom entfernten System anfordern. Durch das Einstellen eines „Wünsche"-Feldes eines Eintrags (2010 von 20) mtNegotiateMessageCapability [mtVerhandlungNachricht-Leistungsmöglichkeit] ('N') kann ein Konferenzteilnehmer spezielle Informationen abfragen (z.B. über eine gegebene Komponentenart, wie zum Beispiel einen Codec, unterstützte Hardware-/Softwaremerkmale etc.). Das Typ-Feld kann den Wert des Komponententyps enthalten.
Als Reaktion auf eine verhandelte Nachricht der Leistungsmöglichkeiten formatiert der entfernte Teilnehmer eine Anwenderdatennachricht als Reaktion auf die Nachricht der Leistungsmöglichkeiten. Man beachte, dass diese Liste von Wünschen doppelte Einträge und Einträge mit einem Wert NULL enthalten kann. Zur Analyse dieses Arrays muss ein Teilnehmer die Größe des Arrays bestimmen. Nach dem Senden einer Nachricht der Leistungsmöglichkeiten 1300 sendet der Teilnehmer zum Aufbau einer Konferenz eine Hallo-Nachricht 1400.
Beim Start einer Konferenz wird von jedem Endpunkt eine Hallo-Nachricht (z.B. 1400 von 14) gesendet. Die Hallo-Nachricht kennzeichnet grundlegende Leistungsmöglichkeiten des Senders und die Betriebsart, in der er arbeiten wird. Sie enthält das Folgende:
Minimal-Version 1404
Die älteste durch die sendende Komponente unterstütze Version des Konferenzprotokolls
Maximal-Version 1408
Die neueste durch die sendende Komponente unterstütze Version des Konferenzprotokolls
Konferenz-Betriebsart 1412
Die gewünschte Konferenzbetriebsart. Dieses Feld enthält einen Wert, der der vom Sender für diese Konferenz gewünschten Betriebsart entspricht. Die Anwendungen spezifizieren ihre gewünschte Betriebsart durch einen Einstellen-Betriebsart[SetMode]-API-Aufruf (vorstehend behandelt).
Name 1416
Der Name des voraussichtlichen Konferenzteilnehmers. Dieser Name kennzeichnet die Funktionseinheit, die mit der Konferenz verbinden möchte, und kann entweder eine Zusatzdatenquelle oder einen neuen Anwender darstellen. Die Anwendungen spezifizieren durch den Aufruf des MTConferenceListen-API-Aufrufs einen Anwendernamen. Der zusätzliche Name wird in einem MTAttachAuxiliary [MTBeifügenZusatz]-API-Aufruf spezifiziert.
Die Hallo-Nachricht 1400 ist der erste Schritt beim Aufbau einer Konferenz. Diese Nachricht gestattet Konferenzkomponenten auf verschiedenen Systemen den Austausch grundlegender Informationen der Kennzeichnung und der Leistungsmöglichkeit. Vor dem Senden einer Hallo-Nachricht 1400 kann eine Konferenzkomponente entweder eine Nachricht der Leistungsmöglichkeiten 1300 oder eine Zusatz-Nachricht 1700 senden. Die Art der gesendeten Nachricht hängt von der Funktion ab, die der Teilnehmer in der Konferenz erwartet. Wenn der Teilnehmer erwartet, sich mit einer Konferenz zu verbinden oder eine Konferenz zu beginnen, sendet die Konferenzkomponente eine Nachricht der Leistungsmöglichkeiten. Wenn der Teilnehmer eine zusätzliche Mediendatenquelle einrichtet, sendet die Komponente eine Zusatz-Nachricht 1700. Dieser Nachricht folgend kann die Konferenzkomponente durch das Beenden der Anruf-Nachricht 1500 in die Anrufeinrichtungsphase eintreten. Wenn der Teilnehmer eine zusätzliche Datenquelle einer existierenden Konferenz bereitstellen möchte oder sich mit einer existierenden Konferenz verbinden möchte, sendet die Komponente die Verbinden-Nachricht 1800.
Die Anruf-Nachricht 1500 von 15 beginnt das Verfahren zum Aufbau einer Konferenzverbindung zwischen zwei möglichen Teilnehmern. Dies ist dem Wählen einer Nummer aus einem Telefonverzeichnis ähnlich.
Anruf-Zeitüberschreitung 1504
Die Zeit, die die anrufende Komponente auf eine Antwort zu warten bereit ist. Dieses Feld gibt die Anzahl der Ticks [Takte] an (1/60 einer Sekunde), die die anrufende Komponente warten wird, bevor sie entscheidet, dass der Anruf nicht beantwortet wurde. Die angerufenen Komponenten müssen innerhalb dieses Zeitrasters antworten. Dieser Wert kann von einem möglichen Antwortenden zum Ergreifen irgendeiner automatischen Maßnahme verwendet werden, wenn der Anwender nicht vor der Zeitüberschreitung antwortet.
Konferenz-Name 1508
Der Name der Konferenz. Wenn der Anrufer eine Konferenz aufbaut, ist dies der Name, den der Anrufer der Konferenz zugewiesen hat. Wenn sich der Anrufer mit einem Konferenzserver verbindet, ist dies der Name der Konferenz des Servers. Die Anwendungen stellen den Konferenznamen durch einen Aufruf der Funktion MTConferenceCall ein.
Anrufende-Konf-ID 1512
Die eindeutige Konferenzkennung des Anrufers. Dieses Feld kennzeichnet im Netzwerk eindeutig den Konferenzendpunkt des Anrufers. Die Konferenzkomponenten erzeugen im Auftrag der anrufenden Anwendungen Konferenzkennungen, die innerhalb einer Konferenzkomponente eindeutig sind. Anruf-ID's werden mit Bezug auf 2200 von 22 behandelt.
Die in 15 gezeigte Anruf-Nachricht 1500 beginnt das Verfahren zum Aufbau einer Konferenz zwischen zwei Teilnehmern. Diese Nachricht kann auf zwei Art und Weisen verwendet werden. Erstens kann diese Nachricht eine Konferenz zwischen zwei Teilnehmern erzeugen. In diesem Szenarium weist der Anrufer der Konferenz einen Namen zu, so dass sich andere mögliche Teilnehmer später verbinden können. Alternativ kann diese Nachricht das Verbinden mit einer Konferenz anfordern, die von einem Konferenzserver in einem Netzwerk verwaltet wird. Zum Beispiel wird der Server eingehende Anrufe zulassen. Die Funktion des Servers besteht jedoch in der Zusammenführung der neuen Konferenz aufgrund des Anrufs mit anderen laufenden Konferenzen. Mit anderen Worten handelt der Server ausschließlich als ein „Verbinder" und stellt keine Mediendaten bereit. Sobald der Anruf eingerichtet ist, kann der Anrufer den Austausch von Anwenderdaten mit anderen Konferenzteilnehmern beginnen.
Die Antwortnachricht 1600 von 16 wird als Reaktion auf Anruf- oder Verbinden-Nachrichten 1500 oder 1800 gesendet.
Anruf-Antwort 1604
Das Ergebnis. Dieses Feld zeigt das Ergebnis der vorhergehenden Anruf-Anforderung an. Dieses Feld wird auf '0' gesetzt, wenn die Anforderung erfolgreich war. Andernfalls enthält es einen geeigneten Ergebniscode.
Ziel-Konf-ID 1608
Die eindeutige Kennung des anderen Endpunktes. Dieses Feld kennzeichnet den anderen Teilnehmer der Konferenz.
Die Antwort-Nachricht 1600 gestattet dem Anrufer eine Bestimmung des Erfolgs einer Anruf- oder Verbinden-Anforderung. Die Antwort-Nachricht 1600 zeigt an, wie der Anwender am entfernten System auf den Anruf reagierte (zum Beispiel, ob der Anwender den Anruf beantwortete). Das Feld Anruf-Antwort 1604 enthält den Ergebniscode der Anforderung. Wenn er nicht Null ist, trat ein Fehler auf und die Anforderung war nicht erfolgreich. Andernfalls kennzeichnet das Feld Ziel-Konf-ID 1608 den Endpunkt, mit dem der Anrufer jetzt kommunizieren kann.
Die Zusatz-Nachricht 1700 gestattet einem Teilnehmer das Warnen der anderen Teilnehmer einer Konferenz, dass er im Begriff ist, eine zusätzliche Mediendatenquelle (eine einer laufenden Konferenz zugeordneten Quelle) bereitzustellen. Diese Nachricht kann an Stelle der Nachricht der Leistungsmöglichkeiten 1300 verwendet werden, wenn ein Teilnehmer über das Vorhandensein einer zusätzlichen Medienquelle gewarnt wird. Der Teilnehmer sendet diese Nachricht vor dem Senden der Hallo- und Verbinden-Nachrichten 1400 und 1800 und setzt dann mit dem Hinzufügen einer zusätzlichen Datenquelle zur Konferenz fort.
Vorgänger-Konf-ID 1704
Die Konferenzkennung des Teilnehmers. Dieses Feld kennzeichnet den existierenden Konferenzendpunkt des Teilnehmers (die Konferenzkennung, die der Teilnehmer beim ersten Verbinden mit der Konferenz in der Anruf-Nachricht bereitstellte). Dies gestattet anderen Konferenzteilnehmern die Identifizierung der Quelle der zusätzlichen Daten innerhalb jedes Teilnehmers.
Die Zusatz-Nachricht 1700 informiert andere Konferenzteilnehmer, dass ein Teilnehmer in Begriff ist, eine zusätzliche Konferenzdatenquelle bereitzustellen. Für zusätzliche Datenquellen ersetzt diese Nachricht die Nachricht der Leistungsmöglichkeiten bei frühzeitigen Interaktionen. Der Teilnehmer muss diese Nachricht an alle Konferenzteilnehmer senden. Der Teilnehmer sendet dann eine Hallo- 1400 und eine Verbinden- Nachricht 1800 an alle Teilnehmer. Durch das Aufnehmen der Verbinden-Anforderung nehmen die anderen Teilnehmer dann die neue Datenquelle an.
Eine Verbinden-Nachricht 1800 von 18 gestattet einem Teilnehmer das Verbinden mit einer existierenden Konferenz, wenn ihm die Kennung der Konferenz gegeben ist. Diese Nachricht ist für das Hinzufügen zusätzlicher Datenquellen zu einer existierenden Konferenz und für das Zusammenführen von zwei existierenden Konferenzen verwendbar.
Ziel-Konf-ID 1804
Die eindeutige Konferenzkennung des entfernten Endes. Dieses Feld kennzeichnet die Konferenz, mit der sich verbunden werden soll.
Anrufende-Konf-ID 1808
Eindeutige Konferenzkennung. Dieses Feld kennzeichnet eindeutig den Konferenzendpunkt des Anrufers im Netzwerk. Die Konferenzkomponenten erzeugen Konferenzkennungen im Auftrag anrufender Anwendungen. Wenn die Nachricht eine zusätzliche Mediendatenquelle hinzufügt, ist dies die Kennung des Zusatzes.
Teilnehmer-Liste 1812
Eine Liste von anderen Konferenzteilnehmern. Diese Liste kennzeichnet alle anderen bekannten Konferenzteilnehmer, die zum Austausch von Daten mit neuen Teil nehmern bereit sind (das heißt, sie haben in ihrer Konferenzbetriebsart die Verbinder-Betriebsartmaske eingestellt). Die Konferenzkomponente kann sich mit jedem Teilnehmer verbinden, mit dem sie noch nicht verbunden ist. Wenn die Nachricht einen Zusatz hinzufügt (über die Ausgabe einer Zusatz-Nachricht 1700), enthält diese Liste die Endpunkt-Kennung aller Teilnehmer, denen der Anrufer den Zusatz zur Verfügung stellt. Es hängt von jedem von ihnen ab zu antworten.
Dies ist eine Liste von Konferenzendpunktkennungen; jedem Element der Liste folgt ein Zeilenvorschubzeichen.
Die Verbinden-Nachricht 1800 gestattet einem Teilnehmer das Hinzufügen einer zusätzlichen Datenquelle zu einer existierenden Konferenz oder das Zusammenführen von zwei existierenden Konferenzen. Der Anrufer sendet diese Nachricht an jeden Teilnehmer der Konferenz als Antwort auf eine Zusammenführungs- oder Verbindungsanforderung.
Die Zusammenführ-Nachricht 1900 von 19 verbindet zwei Konferenzen. Die Empfänger dieser Nachricht verbinden sich mit den aufgelisteten Teilnehmern, mit denen sie noch nicht verbunden sind.
Konferenz-Name 1904
Der sich aus der Zusammenführung ergebende neue Konferenzname. Dies ist der Name, der der Konferenz beim Aufbau der Konferenz zugewiesen wurde. Durch den Aufruf der MTConferenceCall-API-Funktion spezifizieren die Anwendungen den Konferenznamen.
Meine-Konf-ID 1908
Eine eindeutige Konferenzkennung. Dieses Feld kennzeichnet eindeutig den Konferenzendpunkt des Anrufers in der Zielkonferenz. Die Konferenzkomponenten erzeugen im Auftrag der anrufenden Anwendungen die Konferenzkennungen.
Teilnehmer-Liste 1912
Eine Liste anderer Konferenzteilnehmer. Diese Liste kennzeichnet die anderen aktuellen Konferenzteilnehmer. Diese Liste enthält die Endpunktkennung jedes neuen Teilnehmers.
Dies ist eine Liste von Konferenzendpunktkennungen; jedem Element in der Liste folgt ein Zeilenvorschubzeichen.
Die Zusammenführ-Nachricht bewirkt den Zusammenschluss von zwei Konferenzen. Dies ist der Mechanismus zum Erzeugen von zwei Konferenzen mit mehr als zwei Teilnehmern. Der Anrufer sendet diese Nachricht an jeden existierenden Konferenzteilnehmer mit der Spezifizierung des Namens der Konferenz. Jeder Endpunkt baut Kommunikationen mit allen neuen Endpunkten auf. Laut Vereinbarung baut der Endpunkt mit dem höheren Wert der Konferenzkennung die Verbindung auf (um doppelte oder fehlende Verbindungen zu vermeiden). Die Teilnehmer der Konferenz empfangen bei einer Kontaktierung durch jeden neuen Teilnehmer eine Verbinden-Nachricht 1900 an Stelle einer Anruf-Nachricht 1500.
Eine Liste der Leistungsmöglichkeiten, wie sie in 20 gezeigt ist (z.B. Feld 1316), enthält Informationen über die von einer Konferenzanwendung unterstützte Nachricht. Die Liste besteht aus Null oder mehr Informationszeilen; jede Zeile spezifiziert eine einzelne Leistungsmöglichkeit und besteht aus den folgenden Feldern:
Typ 2002
Kennzeichnet eine Nachricht durch einen Verweis auf einen eindeutigen Typ-Wert.
Version 2006
Die Nachrichtenversionsnummer. Spezifiziert die jüngste, von der Anwendung unterstützte Version der Nachricht.
Wünsche 2010
Das Hilfestellungsniveau. Dieses Feld zeigt das Niveau der von der Anwendung angeforderten Hilfestellung an. Mögliche Werte sind:
mtMessageOptionalCapability [mtNachrichtOptional-Leistungsmöglichkeit]
Optional. Zeigt an, dass die Nachricht optional ist. Der dieser Option entsprechende Wert ist 'O'.
mtMessageDesiredCapability [mtNachrichtErwünscht-Leistungsmöglichkeit]
Erwünscht. Obwohl immer noch optional, zeigt dieser Wert an, dass die Anwendung den frühzeitigen Empfang dieser Nachricht im Anruf bevorzugt (z.B. kann ein Teilnehmer vor dem Aufbau eines Anrufs das Senden der Visitenkarte des Empfängers zur langfristigen Speicherung anfordern). Der dieser Option entsprechende Wert ist ,D'.
mtMessageRequiredCapability [mtNachrichtErforderlichLeistungsmöglichkeit]
Erforderlich. Die Anwendung muss diese Nachricht empfangen. Der dieser Option entsprechende Wert ist 'R'.
mtNegotiationMessageCapability [mtVerhandlungNachrichtLeistungsmöglichkeit]
Verhandeln. Die Anwendung möchte die Möglichkeiten des Empfängers erfahren. Der dieser Option entsprechende Wert ist 'D'.
Die Konferenzkennungen, wie die in 22 gezeigten 2200, kennzeichnen eindeutig einen Konferenzendpunkt. Jeder Endpunkt stellt eine Datenquelle oder eine -Senke für die Konferenz dar. Man beachte, dass ein einzelnes System mehr als einen Konferenzendpunkt (z.B. einen Zusatz) in einer gegebenen Konferenz und zu einem Zeitpunkt mehr als eine Konferenz aufweisen kann. Ein Konferenzendpunkt besteht aus den folgenden Feldern:
Eindeutige-ID 2202
Eine eindeutige numerische Kennung. Dieses Feld enthält eine eindeutige numerische Endpunktkennung. Jede Konferenzkomponente weist ihre eigenen Kennungen zu, um im Zusammenhang mit einem im Namenfeld 2206 spe zifizierten, gegebenen Namen eine Eindeutigkeit zu garantieren.
Name 2206
Ein eindeutiger Name. Kennzeichnet das System im Netzwerk. Der Name ist im Zusammenhang mit einer gegebenen Transportschnittstelle eindeutig. Er umfasst den Typ der ausgewählten Transport- und Netzwerkschnittstelle.
Eine Teilnehmerliste, wie zum Beispiel 1812 von 21, ist ein Array von Null oder mehr Konferenzkennungen 2102, 2110 etc. Jeder Eintrag im Array ist durch ein Zeilenvorschubzeichen begrenzt.
Die Beenden-Nachricht 2300 von 23 beendet eine Konferenz. Dabei wird die Kommunikation eines Teilnehmers mit den Teilnehmern beendet, zu denen er die Nachricht sendet.
Die Beenden-Nachricht 2300 ist der letzte Schritt beim Beenden der Konferenzteilnahme eines Teilnehmers. Diese Nachricht beendet die Konferenzkommunikation des Teilnehmers mit allen Teilnehmern, zu denen er die Nachricht sendet. Wenn ein Teilnehmer eine Konferenz ganz verlässt, muss er diese Nachricht an jeden Konferenzteilnehmer senden.
Die Rundsende-Anforderung[BroadcastRequest]-Nachricht 2400 gestattet es einem Teilnehmer herauszufinden, ob ein anderer Konferenzteilnehmer Rundsende(Multicast)-Nachrichten annehmen kann.
Untertyp 2406
Der Untertyp der Rundsende-Nachricht. Dieses Feld muss auf 'R' gestellt werden.
Multicast-Adresse 2410
Die vorgeschlagene Multicast-Adresse. Dieses Feld enthält die Multicast-Adresse, auf der der Teilnehmer das Senden von Rundsende-Nachrichten vorschlägt.
Die Rundsende-Anforderung-Nachricht 2400 gestattet es einem Teilnehmer eine Bestimmung, ob ein anderer Konferenzteilnehmer Rundsende-Nachrichten über eine gegebene Multicast-Netzwerkadresse annehmen kann. Der Empfänger zeigt durch das Senden einer Rundsende-Bestätigungs-Nachricht 2500 (nachstehend beschrieben) seine Fähigkeit zur Unterstützung der Rundsende-Nachrichten an. Wenn der Empfänger einen Rundsende-Nachrichtenaustausch nicht unterstützen oder auf diese spezielle Rundsende-Übertragung nicht zugreifen kann, sollte der anrufende Teilnehmer das Senden von Punkt-zu-Punkt-Nachrichten an den Empfänger fortsetzen.
Die Rundsende-Anforderungs-Nachricht 2400 wird üblicherweise als Teil des Verhandlungsverfahrens verwendet, das dem Zusammenführen von zwei Konferenzen oder dem Verbinden irgendwelcher neuen Teilnehmer mit einer Konferenz folgt. Zur Optimierung können Konferenzteilnehmer die Einrichtung von Rundsende-Leistungsmöglichkeiten als effizientere Alternative zur Aufrechterhaltung mehrerer verschiedener Punkt-zu-Punkt-Verbindungen wählen.
Die Rundsende-Bestätigungs-Nachricht 2500 gestattet es einem Teilnehmer, auf eine Rundsende-Anforderungs-Nachricht 2400 zu antworten.
Untertyp 2504
Der Untertyp der Rundsende-Nachricht. Dieses Feld muss auf 'A' gestellt werden.
Rundsende-Antwort 2508
Das Ergebnis. Dieses Feld zeigt an, ob der Teilnehmer die in der Rundsende-Anforderungs-Nachricht 2500 vorgeschlagene Multicast-Adresse unterstützen kann.
Die Rundsende-Bestätigungs-Nachricht 2500 gestattet einem Teilnehmer die Anzeige, ob er Nachrichten über die vorgeschlagene Multicast-Adresse empfangen kann. Ein anderer Konferenzteilnehmer schlägt durch das Senden einer Rundsende-Anforderungs-Nachricht 2408 eine Multicast-Adresse vor. Wenn der Empfänger diese Adresse unterstützen kann, stellt er das Rundsende-Antwort-Feld 2508 auf '0'. Andernfalls enthält das Feld Rundsende-Antwort 2580 einen geeigneten, von Null verschiedenen Ergebniscode. Diese Nachricht wird üblicherweise als Teil des Verhandlungsverfahrens verwendet, das der Zusammenführung von zwei Konferenzen folgt. Zur Optimierung können Konferenzteilnehmer die Einrichtung von Rundsende-Leistungsmöglichkeiten als eine effizientere Alternative zur Aufrechterhaltung mehrerer verschiedener Punkt-zu-Punkt-Verbindungen wählen.
Die Operationen des Verbindens weisen das in 9 veranschaulichte Protokoll auf. Die 26a–26c veranschaulichen die in einem Sender und einem Empfänger während der Operatio nen des Verbindens ausgeführten Verfahrensschritte. 26a zeigt ein Verfahren 2600, das die Verfahrensschritte eines Senders einer Verbinden-Nachricht umfasst. Dies kann zum Beispiel als Reaktion auf eine Zusatz- oder eine Zusammenführ-Nachricht auftreten. Zuerst erzeugt der Sender in Schritt 2602 eine Verbinden-Nachricht. Die Zielkonferenz-ID und die anrufenden Konferenz-ID's werden in Schritt 2603 der Nachricht hinzugefügt. Dann werden in Schritt 2604 alle die Teilnehmer an die Teilnehmerliste in der Verbinden-Nachricht angehängt, die die Verbinden-Nachricht empfangen sollen. Dies ist in 26b detaillierter gezeigt. Eine Transportschichtverbindung mit dem Teilnehmer, der das Verbinden empfangen soll, wird dann in Schritt 2605 ausgeführt. Im Anschluss daran wird die Nachricht in Schritt 2606 an alle Empfänger gesendet.
26b veranschaulicht die in 26a gezeigte „Teilnehmer anhängen"-Funktion 2604 zum Anhängen von Teilnehmern an eine Teilnehmerliste. Die Funktion beginnt in Schritt 2610, der bestimmt, ob der Teilnehmer ein „Verbinder" ist. In diesem Fall können dem Verbinder zusätzliche Teilnehmer angehängt werden. Wenn nicht, endet die Funktion und die Verbinden-Nachricht wird, wie in 26a gezeigt, mit dem einzigen Teilnehmer gesendet. In 2612 wird gemäß der Konferenz-ID der nächste Teilnehmer abgerufen. In Schritt 2614 wird bestimmt, ob es irgendwelche weiteren Teilnehmer in der spezifizierten Konferenz-ID gibt. Wenn nicht, ist das Verfahren abgeschlossen. Wenn es weitere Teilnehmer gibt und das Flag der Betriebsart der gemeinsamen Nutzung gesetzt ist, wie in Schritt 2616 erfasst wird, wird der Teilnehmer der Teilnehmerliste in Schritt 2618 hinzugefügt. Auf diese Art und Weise können während einer Zusammenführungsoperation andere, die Verbinden-Nachricht empfangende Teilnehmer bestimmen, ob sich die Konferenzzugehörigkeit geändert hat. Dies erfordert das Senden zusätzlicher Verbinden-Nachrichten durch die empfangenden Teilnehmer.
26c zeigt die von einem Empfänger einer Verbinden-Nachricht ausgeführten Schritte. Zuerst wird in Schritt 2652 die in der Verbinden-Nachricht enthaltene Ziel-Konferenz-ID vom Empfänger in einer lokal gespeicherten, aktuellen Konferenzverlaufstabelle (z.B. 2900 von 29) nachgeschlagen. Diese behält die Übersicht über die vorher verwendeten Konferenz-ID's für alle aktuell aktiven Konferenzen. Wenn sich die Konferenz-ID geändert hat, kann der Teilnehmer durch die Referenzierung einer alten Konferenz-ID und der aktuellen Konferenz-ID im Teilnehmer das Verbinden abschließen. Dies gestattet Konferenzzusammenführ- und Zusatz-Nachrichten von weit verteilten Teilnehmern in einem Netzwerk. Wenn die Konferenz-ID nicht gefunden werden kann, wie in Schritt 2654 erfasst wurde, wird die Verbindung in Schritt 2656 durch die Ausgabe einer geeigneten Antwortnachricht abgelehnt und das Verbinden schlägt fehl. Wenn die Konferenz-ID gefunden wurde, wird in Schritt 2660 die Verbindung zu der Liste von Teilnehmern der Konferenz hinzugefügt. In Schritt 2662 wird eine Antwort an den Sender des Verbindens gesendet, dass das Verbinden ausgeführt werden kann. Dann kann die Zugehörigkeit der in der Teilnehmerliste des Verbindens enthaltenen Teilnehmer wie in 26d gezeigt ausgeführt werden.
Die Zusammenführ-Zugehörigkeits-Funktion 2664 ist in 26d detaillierter gezeigt. Zuerst wird in Schritt 2678 bestimmt, ob die Teilnehmer zusammenführende Zugehörigkeit gemeinsam nutzbar ist. In diesem Fall wird in Schritt 2680 bestimmt, ob es noch weitere Teilnehmer in der Teilnehmerliste gibt. Wenn nicht, ist die Funktion abgeschlossen. In diesem Fall wird in Schritt 2682 der nächste Teilnehmer von der Zugehörigkeitsliste abgerufen. Wenn der Teilnehmer bereits verbunden ist, es der Teilnehmer oder die eigene Zusatzquelle des Teilnehmers ist, kehrt das Verfahren zu Schritt 2690 zurück. Es wird in Schritt 2686 bestimmt, ob der anrufende Beteiligte das Verbinden mit dem Empfänger ausführen wird. Dies verhindert den Empfang und das Ausführen sich widersprechender Verbinden-Nachrichten im Netzwerk. Dies wird durch eine Bestimmung ausgeführt, ob die Konferenz-ID des Empfängers größer als die Konferenz-ID des anrufenden Beteiligten ist. In diesem Fall ist dem anrufenden Beteiligten der Empfang der Verbinden-Nachricht gestattet und er wird beim Verbinden Maßnahmen ergreifen. Die zum Ausführen des Verbindens notwendigen Operationen finden dann beginnend in Schritt 2688 statt. In diesem Schritt werden Transportschichtverbindungen aufgebaut. Sobald sie aufgebaut sind, werden in Schritt 2690 Leistungsmöglichkeiten-, sofern vorhanden, (oder eine Zusatz-Nachricht im Fall einer zusätzlichen Quelle), Hallo- und Verbinden-Nachrichten gesendet. Der Teilnehmer wartet dann auf eine Antwort auf das Verbinden und wenn diese bestätigend empfangen wurde, gibt die Konferenzkomponente Teilnehmer-Bereit an die Anwendung aus. Dieses Verfahren setzt fort, bis alle Teilnehmer in der Teilnehmerliste verarbeitet worden sind.
Zusammenführungsoperationen
Zusammenführungsoperationen werden unter Verwendung einer „Zusammenführ"-Nachricht (z.B. die in 19 gezeigte 1900) ausgelöst. Sie zeigt einem Teilnehmer an, dass zwei existierende Konferenzen zusammengeführt werden sollen. Dies erfolgt gemäß der im Feld 1908 von Nachricht 1900 enthaltenen Konferenz-ID. Jede Zusammenführ-Nachricht enthält in sich eine Teilnehmer-Liste 1912, die den teilnehmenden Teilnehmern das Senden von Verbinden-Nachrichten an alle Teilnehmer, die in der Teilnehmer-Liste aufgelistet worden sind, gestattet. Dies gestattet ferner während des Verlaufs einer Zusammenführungsoperation das Ändern der Zugehörigkeit und der Konferenz-ID so zu verfolgen, dass die korrekten Konferenz-ID's und Konferenzzugehörigkeit bis nach der Zusammenführung aufrechterhalten werden können. Eine Zusammenführungsoperation ist mit Bezug auf die 26a und 26b graphisch veranschaulicht. In eine erste Zeitperiode 26a kann sich zum Beispiel Konferenzteilnehmer-ID in zwei als 1 und 2 bezeichnete Konferenzen mit verschiedenen anderen Teilnehmern A, B und C einschalten. In der das Format 1900 in 19 aufweisenden Zusammenführ-Nachricht enthalten, setzt der Teilnehmer dann die Ausgabe von Verbinden-Nachrichten an die Teilnehmer der Konferenzen fort. Das heißt, der Teilnehmer D gibt dann Verbinden-Nachrichten an die Teilnehmer B und C zum Verbinden mit der Konferenz 1 (B₁ und C₁ bezeichnet) aus. Am Ende der Operation weisen alle Teilnehmer A, B, C und D Punkt-zu-Punkt-Kommunikationskanäle auf und die neue Konferenz-ID wird mit 1 bezeichnet (A₁, B₁, C₁ beziehungsweise D₁ in jedem der Teilnehmer). Die Mechanismen dieser Operation werden mit Bezug auf 27 kurz beschrieben.
Die 28a–28b zeigen die während einer Zusammenführoperation durch die Konferenzkomponente im Sender und den Empfängern (sofern vorhanden) einer Zusammenführ-Nachricht ausgeführten Schritte. 28a zeigt die von einem Sender einer Zusammenführungsanforderung ausgeführten Verfahrensschritte. Der Teilnehmer kombiniert zuerst in Schritt 2802 die Konferenz-ID's der alten und neuen Konferenz in seinem internen Speicher. Dann erzeugt der Teilnehmer in Schritt 2804 die Zusammenführ-Nachricht und fügt jeden der Teilnehmer der Konferenz zur Teilnehmerliste in der Nachricht mittels der Routine zum Hinzufügen von Teilnehmern 2604 (vorstehend behandelt) hinzu, um eine vollständige Verbindungsfähigkeit zwischen allen Konferenzteilnehmern zu gewährleisten. In Schritt 2806 wird dann die Zusammenführ-Nachricht an alle Teilnehmer der Zusammenführung gesendet.
28b zeigt die in einem, eine Zusammenführ-Nachricht empfangenden Empfänger ausgeführten Verfahrensschritte. Sobald eine Zusammenführ-Nachricht erfasst wurde (Schritt 2812), ruft der Empfänger der Zusammenführung in Schritt 2814 aus einem lokalen Speicher den Konferenznamen und die Konferenz-ID ab. Wie vorstehend mit Bezug auf 26d behandelt, wird dann eine Verschmelzung der Zugehörigkeit ausgeführt und das Verfahren ist somit in Schritt 2816 abgeschlossen.
Zusätzlich zur Verwendung aktueller Konferenz-ID's zur Ausführung von Zusammenführungs- und nachfolgenden Verbindungsoperationen ist in jeder Zusammmenführ- und Verbinden-Nachricht eine Liste der Teilnehmer der zusammenzuführenden oder zu verbindenden Konferenzen enthalten. Diese sind in den Feldern Teilnehmer-Liste 1812 oder 1912 der Nachrichten 1800 oder 1900 enthalten. Zum Beispiel können auf Grund von Ausbreitungsverzögerungen in einem Netzwerksystem immer noch alte Konferenz-ID's in peripheren Teilnehmern existieren. Deshalb können während der Zusammenführungs- und oder Verbindungsoperationen Konferenz-ID's ungültig werden oder auf nicht mehr existierende Konferenz-ID's verweisen. Folglich ist in jeder Konferenzkomponente in einem Teilnehmer eine aktuelle Konferenztabelle enthalten, wie zum Beispiel die in 29 gezeigte 2900. Die aktuelle Konferenzverlaufstabelle gestattet einem Teilnehmer die Ausführung einer Zusammenführungs- oder Verbindungsoperation für eine Bestimmung, ob tatsächlich zusammenzuführende Konferenzen alte Konferenz-ID's verwenden. In diesem Fall kann die neue Konferenz-ID zur Übertragung an die die Verbinden-Nachrichten empfangenden Teilnehmer verwendet und/oder an die geeignete Konferenz-ID angepasst werden. Folglich kann der die Zusammenführungsoperation ausführende Teilnehmer durch die in der Tabelle der zusammengeführten Konferenzen enthaltenen, aktuellen Konferenz-ID 2901 oder andere Konferenz-ID-Werte 2902 referenzieren, die in einer Liste va riabler Länge von Konferenz-ID's enthaltenen sind, auf die sich die aktuelle Konferenz-ID bezieht. Konferenzeinträge werden am Ende einer Konferenz von der Konferenzkomponente gelöscht. Wenn eine Zusammenführung an einem peripheren Standort auftritt und eine Konferenz-ID ungültig wird, kann die Liste der Konferenz-ID's für eine existierende Konferenz-ID durch eine Referenzierung der Verlaufstabelle der zusammengeführten Konferenzen referenziert werden.
Multicast
Die 30a und 30b veranschaulichen ein Verfahren, das als eine Optimierung ausgeführt wird, wenn mehrere Teilnehmer einer Konferenz Multicast-Adressen-Rundsende-Leistungmöglichkeiten unterstützen. Zuerst wird in Schritt 3001 erfasst, ob es irgendwelche weiteren, zu prüfenden Transportmedien gibt. In diesem Fall wird in Schritt 3002 das Nächste abgerufen und in Schritt 3003 wird bestimmt, ob es zwei oder mehr Teilnehmer in der gleichen Konferenz und auf dem gleichen Transportmedium gibt. In diesem Fall und wenn das Transportmedium die gleichzeitige Ausführung mehrerer Arbeitsvorgänge [Multitask] in Schritt 3004 unterstützt, werden die Multitask-Leistungsmöglichkeiten des Transportes in Schritt 3006 aktiviert. In diesem Fall und bei Betriebsfähigkeit der Multicast-Leistungsmöglichkeiten in Schritt 3008, setzt Schritt 3008 zu Schritt 3012 fort. Wenn in Schritt 3008 erfasst wird, dass sie nicht betriebsfähig sind, wird in Schritt 3010 das Verfahren abgebrochen. In Schritt 3012 wird eine Multicast-Adresse in Schritt 3012 abgerufen, die für das Transportmedium verwendet werden kann. Dann werden bei 3014 Rundsende-Anforderungen im, im Wesentlichen dem in der Nachricht 2400 von 24 gezeigten Format an alle in Schritt 3002 erfassten Multicast unterstützenden Teilnehmer gesendet. Das Verfahren erwartet dann in Schritt 3016 Rundsende-Bestätigungen (in dem in 25 gezeigten Format 2500) für eine Bestimmung, ob die Multicast-Adresse für jeden verfügbar ist oder ob eine Zeitüberschreitungs-Zeitperiode auftritt. In diesem Fall wird in Schritt 3018 für jede Rundsende-Bestätigung bestimmt, ob sie empfangen wurde und es wird bestimmt, ob die Bestätigung positiv war (auf Grund des im Feld 2508 von 25 enthaltenen Antwortwertes). Wenn die Antwort positiv war, wird in Schritt 3022 die Punkt-zu-Punkt-Verbindung deaktiviert. Sobald alle Rundsende-Bestätigungen empfangen wurden (oder die Zeit überschritten haben), wird in Schritt 3024 bestimmt, ob für jede gesendete Rundsende-Anforderungsnachricht eine Rundsende-Bestätigung empfangen wurde. Wenn nicht, ist das Verfahren abgeschlossen. Wenn ja, bestimmt jedoch Schritt 3026, ob es irgendwelche positiven Bestätigungen für das Multicast gab. Wenn nicht, wird das Multicast deaktiviert und die Verwendung der Punk-zu-Punkt-Kommunikation für die Kommunikation mit den anderen Teilnehmern wird fortgesetzt (diese Optimierung kann nicht ausgeführt werden). Das Verfahren ist somit abgeschlossen.
Zusätzliche Operationen
Eine zusätzliche Medienquelle kann ein Teil einer laufenden Konferenz werden. Die Medienquelle wird einer laufenden Konferenz durch einen aufrufenden Bezug auf die in jeder Konferenzkomponente gespeicherte Hauptkonferenz zugeordnet. Sie wird jedoch bereits in jeder Konferenzkomponente als eine getrennte Konferenz behandelt. Zum Beispiel kann, wie mit Bezug auf 31 veranschaulicht ist, eine erste Konferenz, auf die hier mit der Konferenz-ID 23B in Teilnehmer B Bezug genommen wird, über eine zusätzliche, die Konferenz-ID 17A von Teilnehmer A aufweisende Quelle benachrichtigt werden. Man beachte, dass ähnlich dem vorstehend mit Bezug auf die Nachrichten der Leistungsmöglichkeiten und Hallo-Nachrichten in den 8 und 9 veranschaulichten Protokoll die Zusatznachricht an Stelle einer Nachricht der Leistungsmöglichkeiten zwischen einem ersten Endpunkt und einem zweiten Endpunkt wie in 32 veranschaulicht gesendet werden kann. Die zeitliche Abstimmung der Nachrichten wird mit Bezug auf 32 veranschaulicht. Ähnlich dem vorstehend mit Bezug auf 8 veranschaulichten Protokoll der Leistungsmöglichkeit und Anrufprotokoll wird die Zusatznachricht 3202 vom ersten Endpunkt 3210 zur Benachrichtigung des Endpunktes 2 3220 empfangen, dass eine zusätzliche Quelle von der Vorgängerkonferenz-ID verfügbar ist, wie im Feld Vorgänger-Konferenz-ID 1704 der Zusatz-Nachricht 1700 von 17 spezifiziert ist. Dann wird eine Hallo-Nachricht 3204 vom Endpunkt 1 3210 zum Endpunkt 2 3220 übertragen. Als Reaktion darauf überträgt der Endpunkt 2 3220 die Nachricht der Leistungsmöglichkeiten 3222 und die Hallo-Nachricht 3224. Im Anschluss daran wird eine Verbinden-Nachricht 3226 mit der Konferenz-ID = 23B vom Endpunkt mit der Konferenz-ID der Quelle an 3220 zur Anzeige ausgegeben, dass der Endpunkt 3220 die in 31 gezeigte zusätzliche Quelle AA zu empfangen wünscht. Im Anschluss daran verweisen alle Nachrichten von der Quelle a zum Empfänger b, wie in 31 veranschaulicht, auf die gleiche Konferenz-ID 23B für die laufende Konferenz zwischen a und b. wie in 31 veranschaulicht, wird das Betriebsart-Flag „Empfange Medien" auf nicht empfangen (!Receive) gesetzt und des Weiteren ist die Betriebsart der zusätzlichen Medienquelle kein Verbinder (!Verbinder), da sie eine Nur-Empfangen-Medienquelle ist. Im Anschluss daran sendet der erste Endpunkt 3210 eine Antwort-Nachricht 3206, die das erfolgreiche Verbinden der zusätzlichen Medienquelle mit der Konferenz 23B anzeigt. Im Anschluss daran werden durch die Anwendung beide Mediennachrichten für die Konferenz-ID 23B und die die Konferenz-ID 17A aufweisende, zusätzliche Quelle als von der gleichen Quelle (A) behandelt.
Die Details und Mechanismen eines, eine Zusätzliche-Quellen-Nachricht empfangenden Teilnehmers werden mit Bezug auf die 33 und 34 veranschaulicht.
33 zeigt die in einer Quelle einer zusätzlichen Quelle ausgeführten Verfahrensschritte. In Schritt 3302 wird der nächste Teilnehmer der Konferenz abgerufen, an welchen die zusätzliche Quelle angehängt werden wird. In Schritt 3304 wird bestimmt, ob es weitere Teilnehmer der Konferenz gibt, an die die zusätzliche Quelle angehängt werden wird. Wenn nicht, werden in Schritt 3308 Zusatz-, Hallo- und Verbinden-Nachrichten an den Teilnehmer gesendet. Wenn sie über eine positive Antwortnachricht angenommen werden (wie in 32 gezeigt), wird der Zusatz dem Teilnehmer für den Empfänger der Nachricht verfügbar. Das Verfahren setzt fort, bis Schritt 3304 bestimmt, dass sich keine zusätzlichen Teilnehmer der Konferenz an der Überwachung des Zusatzes beteiligen sollen.
34 zeigt die von einem Empfänger beim Empfang der anfänglichen Zusatznachricht ausgeführten Schritte. In Schritt 3402 werden Leistungsmöglichkeiten (sofern vorhanden) und Hallo gesendet. In Schritt 3404 beginnt der Empfang der zusätzlichen Medienquelle und in Schritt 3406 wird die Konferenz-ID der Vorgängerkonferenz in der Konferenzkomponente des Empfängers gespeichert. Dies gestattet der Anwendung eine Bestimmung, dass der Zusatz in Schritt 3408 durch eine Speicherung in der Konferenzkomponente für den späteren Abruf der Vorgängermedienquelle zugeordnet ist. Wenn der Zusatz vor dem Empfang einer Verbinden- oder Zusammenführ-Nachricht empfangen wird, gestattet die Zuordnung des Zusatzes zur Vorgänger-Konferenz-ID die spätere Zuordnung beider vom Standpunkt der Anwendung aus.
Eine Beispielsitzung (35a und 35b)
Eine die vorstehend beschriebenen Protokolle verwendende Beispielsitzung ist in den 35a und 35b gezeigt. Die Fig. veranschaulichen den Ablauf der Nachrichten aus der Sicht eines ersten Endpunktes. Nach dem Aufbau der Verbindung zwischen den Stationen unter Verwendung der Transportkomponente sendet die verursachende Station die Nachricht der Leistungsmöglichkeiten 3502 und die den Namen „James Watt" der anrufenden Station spezifizierende Hallo-Nachricht 3504 mit der auf 15 (alle Bits gesetzt – senden, empfangen, Verbinder, gemeinsam nutzbar) gesetzten Betriebsartmaske. Dann wird eine anrufende Nachricht zusammen mit dem Zeitüberschreitungswert = 19392 an den Empfänger gesendet. Gleichzeitig mit dem Aufbau der Verbindung werden entsprechende Leistungsmöglichkeiten, Hallo und Antwort von der die gleiche Betriebsart aufweisenden Station mit dem Titel „Hillary Rodham" gesendet, wie durch die Pakete 3508–3512 veranschaulicht ist.
Im Anschluss an den Austausch der Leistungsmöglichkeiten, Hallo und Anruf und Antwort wird vom ersten Endpunkt eine Zusammenführ-Nachricht 3514 empfangen, die den Konferenznamen „Irgendeine Konferenz", eine Konferenz-ID = 137 und eine Teilnehmerliste umfasst. Der Endpunkt verarbeitet dann das Zusammenführen, sendet Leistungsmöglichkeiten und Hallo an einen Teilnehmer der alten Konferenz und ein Verbinden zusammen mit der Teilnehmerliste, wie durch die Nachrichten 3516, 3518 und 3520 gezeigt ist. Sobald die Verbindung aufgebaut ist, werden die Nachricht der Leistungsmöglichkeiten und die Hallo-Nachricht 3524 und 3526 vom Empfänger empfangen. Als Antwort auf das Verbinden sendet der Empfänger die Antwort-Nachricht 3528 mit dem Ergebnis = 0 (Anforderung erfolgreich). Im Anschluss daran versucht der Endpunkt durch das Senden der Rundsende-Anforderungs-Nachrichten 3530 und 3532 eine Multicast-Adresse zu verwenden. Die anderen Teilnehmer antworten mit den Rundsende-Bestätigungen 3534 und 3536, die eine Verwendung von Multicast gestatten. Die Konferenz kann dann zu jedem Zeitpunkt durch irgendeinen Teilnehmer durch das Senden von Beenden-Nachrichten an alle Teilnehmer, wie zum Beispiel 3538 und 3540, beendet werden.
Folglich können durch die Verwendung des Vorstehenden Verbindungen zwischen Endpunkten, wie zum Beispiel für Telekonferenzen zwischen Telekonferenzsystemen, ermöglicht werden. Dies umfasst, ist aber nicht darauf begrenzt, den Austausch von Leistungsmöglichkeiten und die Benachrichtigung von Verbindungen zwischen Endpunkten, das Hinzufügen von zusätzlichen Datenströmen zu derartigen Verbindungen und das Zusammenführen existierender Verbindungen. Es wird verstanden werden, dass obwohl das Vorstehende besonders mit Bezug auf die 1–35b beschrieben wurde, durch einen Fachmann viele Modifikationen vorgenommen werden können, ohne vom Umfang der Erfindung, wie sie hier beschrieben ist, abzuweichen. Die Erfindung ist folglich nur als durch die nachfolgenden beigefügten Ansprüche begrenzt zu betrachten.

Claims

Ein Verfahren zum Aufbau einer Kommunikation zwischen zwei Endpunkten, wobei das Verfahren umfaßt: daß ein erster Endpunkt (810) einem zweiten Endpunkt (820) mittels einer ersten Nachricht Kommunikationsmöglichkeiten (802) bezeichnet; wobei das Verfahren durch die Schritte gekennzeichnet ist: daß der erste Endpunkt den zweiten Endpunkt mittels einer zweiten Nachricht (806) über den Verbindungswunsch benachrichtigt, wobei die zweite Nachricht einen Zeitablaufwert enthält; daß der zweite Endpunkt den Zeitablauf (1208)-Wert in der zweiten Nachricht prüft und den ersten Endpunkt mittels einer dritten Nachricht (816) über eine Verbindungsbestätigung benachrichtigt; und daß der erste und der zweite Endpunkt entsprechend den Kommunikationsmöglichkeiten eine Kommunikation aufbauen.
Das Verfahren nach Anspruch 1, ferner mit dem Schritt, daß der erste Endpunkt vor dem Schritt des Bezeichnens von Kommunikationsmöglichkeiten mittels einer vierten Nachricht dem zweiten Endpunkt Anwendungsmöglichkeiten bezeichnet.
Das Verfahren nach Anspruch 1, ferner mit dem Schritt, daß der zweite Endpunkt dem ersten Endpunkt entsprechend dem Zeitablaufwert und einem aktuellen Kontext dynamisch antwortet.
Das Verfahren nach Anspruch 1, wobei die zweite Nachricht und die erste Nachricht für die Übertragung über ein Medium gekapselt und paketiert sind.
Das Verfahren nach Anspruch 2, wobei die Anwendungsmöglichkeiten Verhandlungsmöglichkeiten umfassen, so daß der erste und der zweite Endpunkt verhandeln können, um Hardware- oder Softwareeigenschaften des ersten Endpunkts zu bezeichnen.
Das Verfahren nach Anspruch 1, wobei die Kommunikationsmöglichkeiten umfassen, ob der erste Endpunkt Mediendaten senden kann.
Das Verfahren nach Anspruch 1, wobei die Kommunikationsmöglichkeiten umfassen, ob der erste Endpunkt Mediendaten empfangen kann.
Das Verfahren nach Anspruch 1, wobei die Kommunikationsmöglichkeiten umfassen, ob zwischen dem ersten und dem zweiten Endpunkt übertragene Daten von einer Mehrzahl von Endpunkten gemeinsam genutzt werden können.
Das Verfahren nach Anspruch 1, wobei die Kommunikationsmöglichkeiten umfassen, ob mehrere Endpunkte miteinander kommunizieren können.
Das Verfahren nach Anspruch 1, wobei die Kommunikationsmöglichkeiten eine Versionsnummer eines von dem ersten Endpunkt unterstützten Nachrichtenaustauschprotokolls umfassen.
Das Verfahren nach Anspruch 1, wobei die Kommunikationsmöglichkeiten einen Bereich von Versionen eines von dem ersten Endpunkt unterstützten Nachrichtenaustauschprotokolls umfassen.
Das Verfahren nach Anspruch 1, wobei die Kommunikationsmöglichkeiten wenigstens einen Modus umfassen, in welchem der erste Endpunkt mit dem zweiten Endpunkt kommunizieren kann.
Das Verfahren nach Anspruch 12, wobei der zweite Endpunkt aus dem wenigstens einen Modus auswählt, um das Kommunizieren mit dem ersten Endpunkt zu initiieren.
Das Verfahren nach Anspruch 2, wobei die Anwendungsmöglichkeiten Verhandlungsmöglichkeiten umfassen, die dem zweiten Endpunkt die von dem ersten Endpunkt unterstützten Komponententypen spezifizieren.
Das Verfahren nach Anspruch 2, wobei die Anwendungsmöglichkeiten Nachrichten umfassen, deren Austausch zwischen dem ersten Endpunkt und dem zweiten Endpunkt von dem ersten Endpunkt benötigt wird, bevor die Kommunikation zwischen dem ersten Endpunkt und dem zweiten Endpunkt aufgebaut wird.
Das Verfahren nach Anspruch 15, wobei der erste Endpunkt und der zweite Endpunkt die Nachrichten austauschen, die vor dem Aufbau der Kommunikation zwischen dem ersten Endpunkt und dem zweiten Endpunkt benötigt werden.
Ein erster Endpunkt (810) zur Kommunikation mit einem oder mehreren Endpunkten, wobei der erste Endpunkt gekennzeichnet ist durch: Mittel zum Senden wenigstens einer Nachricht an einen zweiten Endpunkt (820) zum Anzeigen eines Verbindungswunsches, wobei die wenigstens eine Nachricht enthält: Kommunikationsmöglichkeiten (802) des ersten Endpunktes und einen Zeitablauf (1208)-Wert, gemäß welchem der zweite Endpunkt antworten soll; und Mittel zum Empfangen einer von dem zweiten Endpunkt gesendeten Verbindungsbestätigungsnachricht (816).
Der erste Endpunkt nach Anspruch 17, ferner mit: Mitteln zum Empfangen wenigstens einer einen Verbindungswunsch anzeigenden Nachricht aus dem zweiten Endpunkt, wobei die wenigstens eine Nachricht aus dem zweiten Endpunkt umfaßt: Kommunikationsmöglichkeiten des zweiten Endpunkts und einen Zeitablaufwert, gemäß welchem der erste Endpunkt antworten soll; Mittel zum Prüfen des Zeitablaufwerts, gemäß dem der erste Endpunkt antworten soll, und zum Benachrichtigen des zweiten Endpunkts über eine Verbindungsbestätigung; und Mittel zum Aufbau einer Kommunikation mit dem zweiten Endpunkt entsprechend den Kommunikationsmöglichkeiten des zweiten Endpunkts.
Der erste Endpunkt nach Anspruch 17, wobei die wenigstens eine Nachricht ferner Anwendungsmöglichkeiten umfaßt.
Der erste Endpunkt nach Anspruch 18, ferner mit: Mitteln, um dem zweiten Endpunkt entsprechend dem Zeitablaufwert für den ersten Endpunkt und einem aktuellen Kontext dynamisch zu antworten.
Der erste Endpunkt nach Anspruch 19, wobei die Anwendungsmöglichkeiten Verhandlungsmöglichkeiten umfassen.
Der erste Endpunkt nach Anspruch 19, wobei die Anwendungsmöglichkeiten Verhandlungsmöglichkeiten umfassen, so daß der erste und der zweite Endpunkt verhandeln können, um Hardware- oder Softwareeigenschaften des ersten Endpunkts zu bezeichnen.
Der erste Endpunkt nach Anspruch 17, wobei die Kommunikationsmöglichkeiten umfassen, ob der erste Endpunkt Mediendaten senden kann.
Der erste Endpunkt nach Anspruch 17, wobei die Kommunikationsmöglichkeiten umfassen, ob der erste Endpunkt Mediendaten empfangen kann.
Der erste Endpunkt nach Anspruch 17, wobei die Kommunikationsmöglichkeiten umfassen, ob die zwischen dem ersten und dem zweiten Endpunkt übertragenen Daten von einer Mehrzahl von Endpunkten gemeinsam genutzt werden können.
Der erste Endpunkt nach Anspruch 17, wobei die Kommunikationsmöglichkeiten umfassen, ob mehrere Endpunkte miteinander kommunizieren können.
Der erste Endpunkt nach Anspruch 17, wobei die Kommunikationsmöglichkeiten eine Versionsnummer eines von dem ersten Endpunkt unterstützten Nachrichtenaustauschprotokolls umfassen.
Der erste Endpunkt nach Anspruch 17, wobei die Kommunikationsmöglichkeiten einen Bereich von Versionen eines von dem ersten Endpunkt unterstützten Nachrichtenaustauschprotokolls umfassen.
Der erste Endpunkt nach Anspruch 17, wobei die Kommunikationsmöglichkeiten wenigstens einen Modus umfassen, in welchem der erste Endpunkt mit dem zweiten Endpunkt kommunizieren kann.
Der erste Endpunkt nach Anspruch 19, wobei die Anwendungsmöglichkeiten Verhandlungsmöglichkeiten umfassen, die dem zweiten Endpunkt die von dem ersten Endpunkt unterstützten Komponententypen spezifizieren.
Der erste Endpunkt nach Anspruch 19, wobei die Anwendungsmöglichkeiten Nachrichten umfassen, deren Austausch zwischen dem ersten Endpunkt und dem zweiten Endpunkt von dem ersten Endpunkt benötigt wird, bevor die Kommunikation zwischen dem ersten Endpunkt und dem zweiten Endpunkt aufgebaut wird.