DE69828230T2

DE69828230T2 - Verfahren und Vorrichtung zum Zugriff auf eine Internetprotokoll-Mehrfachsendesitzung für einen Einfachsende-Endpunktklient

Info

Publication number: DE69828230T2
Application number: DE69828230T
Authority: DE
Inventors: David Hilton Middletown Shur; Alexandr Matawan Zelezniak
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1997-09-11
Filing date: 1998-09-01
Publication date: 2005-12-08
Anticipated expiration: 2018-09-02
Also published as: CA2245979A1; US6259701B1; DE69828230D1; EP0902569B1; EP0902569A1; HK1020463A1; CA2245979C

Description

Technisches Gebiet
Diese Erfindung betrifft Datenübertragung und insbesondere die Bereitstellung eines Unicast-Endpunkt-Clients in einem Unicast-Netzwerk mit der Fähigkeit zum Zugriff auf eine Multicast-Sitzung in einem Multicast-Netzwerk.
Hintergrund der Erfindung
In herkömmlichen Paket-, Rahmen- oder Zell-basierten Systemen gibt es typischerweise zwei Übertragungsarten: Punkt-zu-Punkt (auch als Unicasting bekannt) und Punkt-zu-Multipunkt (auch als Multicasting bekannt). Multicast-Adressen unterscheiden sich normalerweise darin von Unicast-Adressen, dass sie sich auf eine intermediäre Abstraktion beziehen, die als Gruppe bezeichnet wird. Alle Sender adressieren ihre gesendeten Informationen an diese Gruppe, und alle Empfänger sind "darauf abgestimmt", diese Adresse "abzuhören", damit sie die von den Sendern an diese Gruppe gesendeten Informationen empfangen. Die Sender einer Information werden solchermaßen effektiv von der Gruppe von Empfängern entkoppelt. Die Sender brauchen nicht zu wissen, wer die Empfänger sind – sie senden einfach Pakete, die an die Gruppe adressiert sind. Ähnlich brauchen die Empfänger nicht zu wissen, wer die Sender sind – sie senden einfach eine Anfrage an das Netz (die Router), um einer bestimmten Gruppe von Interesse beizutreten.
Multimedia-Distributions- und Konferenz/Zusammenarbeits-Systeme werden von Multicast-Übertragungsverfahren vorteilhaft und wirksam unterstützt. Wie hierin verwendet, wird eine spezifische Multicast-Übertragung als Sitzung bezeichnet. Im Stand der Technik ist es für Unicast-Endpunkte infolge der Unterschiede bei den Adressierungsarten und Empfangsarten nicht möglich, auf Multicast-Sitzungen zuzugreifen. Dies schränkt nachteilig die Möglichkeit eines Benutzers an einem Unicast-Endpunkt-Client ein, an Sitzungen teilzunehmen, an denen er interessiert ist und bei denen er ein aktiver Teilnehmer sein könnte.
Djahandari, K., und Sterne, D. E., "An MBone proxy for an application gateway firewall", Proc. 1997 IEEE Symposium on Security and Privacy, Mai 1997, S. 72-81, beschreibt ein verbessertes Sicherheitssystem, das eine Firewall/Proxy-Anordnung zwischen einem Internet-Multicast-Router und Netzwerk-Hosts bereitstellt, die über identifizierte Unicast-IP-Adressen verfügen. In der Firewall/im Proxy wird dafür gesorgt, dass der Zugriff durch die Hosts auf die MBone-Multicasts eingeschränkt wird, indem eine Reihe von Sicherheitsmaßnahmen bereitgestellt wird, und dass die Multicast-Adressen in die Unicast-Adressen von zugelassenen Hosts konvertiert werden.
Holfelder, W, "Interactive remote recording and playback of multicast videoconferences," Proc. 4th International Workshop on m and Telecommunications Services, (IDMS '97), 10. Sept. 1997, S. 450-463, beschreibt ein Fern-Aufzeichnungs- und -Playback-System zur Verwendung über ein Multicast-Netzwerk wie beispielsweise MBone.
Ein Multicast-Client schließt eine graphische Benutzeroberfläche zur Interaktion mit einem Netzwerk-Server ein, der MBone-Multicast-Sitzungen abwickelt.
Zusammenfassung der Erfindung
In Übereinstimmung mit der vorliegenden Erfindung wird es Unicast-Endpunkt-Clients ermöglicht, auf Multicast-Sitzungen zuzugreifen. Darüber hinaus wird es Unicast-Endpunkt-Clients in Übereinstimmung mit den vorliegenden Erfindungen ermöglicht anzufordern, dass netzwerkbasierte Aufzeichnungsysteme Aufzeichnungen der Multicast-Sitzung für die Clients durchführen. Außerdem wird es, zusätzlich zu mit dem LAN verknüpften Endpunkten, Analogeinwahl- (z. B. 28,8 kbps) sowie ISDN-Unicast-Endpunkten ermöglicht, auf korrekt bandbreitenreduzierte Versionen von Sitzungen mit nominell hoher Bandbreite zuzugreifen.
Die Interkonnektivität zwischen einem Unicast-Client, der mit einem Unicast-Netzwerk verbunden ist, und einem oder mehreren Multicas-Clients, die mit einem Multicast-Netzwerk verbunden sind, wird in Übereinstimmung mit der vorliegenden Erfindung mittels eines Multicast-Unicast-Servers (MUS). erzielt. Ein solcher Server erhält Informationen über Sitzungen in dem Multicast-Netzwerk und macht diese Informationen auf Anfrage des Clients hin für den Unicast-Client im Unicast-Netzwerk verfügbar. Nachdem dem Benutzer eine Liste vorgelegt wurde, die das Thema einer jeden Sitzung beschreibt, wählt er oder sie am Unicast-Client die Sitzung, mit der er (sie) sich verbinden will, was bewirkt, dass sich der Multicast-Unicast-Server namens des anfragenden Clients für jede Medienart, an der der sich verbindende Client teilnehmen will, mit der entsprechenden Sitzung verbindet. Dann setzt der Server zwischen sich und den Client einen bidirektionalen Unicast-Benutzer-Datagram-Protokoll-(UDP)-Strom. Alle danach durch den Server vom Unicast-Client empfangenen Pakete werden auf die entsprechende Multicast-Sitzungsadresse adressenumgesetzt. Zusätzlich werden alle Pakete, die vom Server unter der Multicast-Sitzungsadresse empfangen werden, adressenumgesetzt und an den Unicast-Client gesendet. Der Unicast-Client ist dann in der Lage, sowohl als Sender als auch als Empfänger von Paketen an andere und von anderen Unicast- und Multicast-Clients, die während der Sitzung aktiv sind, an der Multicast-Sitzung teilzunehmen. Weiterhin ist ein solcher Unicast-Client, falls er authentifiziert ist, in der Lage, eine neue Sitzung zu erzeugen und eine Sitzung im Netzwerk für späteres Abrufen und Playback aufzuzeichnen. Darüber hinaus werden im Multicast-Netz Codewandler- und Geschwindigkeitsanpassung-Gateways bereitgestellt, die bestehende Sitzungen auf Versionen mit geringer Bandbreite abbilden. Wenn der Unicast-Client ein Einwahl-Benutzer ist, der über Analog- oder ISDN-Einrichtungen mit dem Unicast-Netzwerk verbunden ist, kann auf diese Geschwindigkeit-gesteuerten Sitzungen dann von den Einwahl-Benutzern zugegriffen werden. Gemäß den Aspekten der vorliegenden Erfindung werden ein Verfahren, wie in den Ansprüchen 1-22 bestimmt, und ein Multicast-Unicast-Server, wie in den Ansprüchen 23-28 bestimmt, bereitgestellt.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm, das an ein Unicast-Internet-Protocol (IP)-Netzwerk angeschlossene Unicast-Clients zeigt, die mittels Multicast-Unicast-Servern (MUS) auf ein IP-Multicast-Netzwerk zugreifen;
2 ist ein Blockdiagramm eines MUS;
3 zeigt die Softwarekomponenten eines Client-Endgeräts, die es dem Client ermöglichen, auf eine Multicast-Sitzung zuzugreifen;
4 ist ein Flußdiagramm, das detailliert die Schritte darstellt, die mit der Teilnahme eines Unicast-Clients an einer Multicast-Sitzung im Multicast-Netzwerk verbunden sind;
5 ist ein Flußdiagramm, das detailliert die Schritte der Erstellung einer Multicast-Sitzung durch einen Unicast-Client darstellt;
6 ist ein Flußdiagramm, das detailliert die Schritte der Aufzeichnung einer Multicast-Sitzung durch einen Unicast-Client darstellt; und
7A und 7B zusammen stellen detailliert die Schritte der Geschwindigkeitsanpassung/Codewandler einer Multicast-Sitzung durch einen Unicast-Client dar.
Detaillierte Beschreibung
Mit Bezug auf 1 wird ein IP-Multicast-Netzwerk 101 gezeigt, das zur Veranschaulichung drei miteinander verbundene Multicast-Router (MR) 102-1, 102-2 und 102-3 einschließt. Ein gut bekanntes, aktuell eingesetztes IP-Multicast-Netzwerk ist das sogenannte MBONE (Multicast Backbone), das ein öffentliches geteiltes IP-Multicast-Netzwerk ist, das viele Länder umspannt und Tausende von IP-Teilnetzen abdeckt. Zusätzlich zu MBONE verwenden auch zahlreiche private Intranets das Multicast-IP für firmeninterne Kommunikation. Eine Mehrzahl von Multimedia-Client-Endgeräten sind mit dem IP-Multicast-Netzwerk 101, z. B. MBONE, verbunden. Nur zur Veranschaulichung sind in 1 zwei Client-Endgeräte 103 und 104 dargestellt, die jeweils mittels entsprechender lokaler Netze (Local Area Networks, LANs) 105 und 106 mit dem Netz 101 verbunden gezeigt werden. Jedes LAN wird mittels eines Kunden-Standortrouters (nicht gezeigt) über z. B. eine T1-Leitung, ein Frame-Relay (FR), ATM oder einen X.25-Anschluß verbunden. In Übereinstimmung mit der Multicast-Übertragung überträgt ein Sender von Informationen einer bestimmten Medienart die Informationspakete an eine bestimmte Adresse, wo sie dann automatisch an alle Mitglieder einer Gruppe verteilt werden, die den Empfang von dieser Adresse angefordert haben. Vorteilhafterweise führt das Netz die notwendigen Replizierungsfunktionen durch, so dass jeder Empfänger-Client der Gruppe die Pakete empfangen kann, die von einem Sender oder von den Sendern an die Adresse gesendet werden.
In Übereinstimmung mit der vorliegenden Erfindung sind die mit einem Unicast-IP-Netzwerk verbundenen Unicast-Client-Endgeräte in der Lage, sich einer Multicast-Sitzung in einem IP-Multicast-Netzwerk anzuschließen und daran teilzunehmen. 1 zeigt zwei Unicast-IP-Netzwerke 107 und 108. Die veranschaulichenden Unicast-Client-Endgeräte 110 und 111 werden mittels herkömmlicher Unicast-Router (URs) 112 bzw. 113 mit dem Netz 107 verbunden. Das Unicast-Client-Endgerät 115 wird mit dem UR 116 im Netz 108 verbunden. Das UR 116 wird wiederum mit einem anderen UR, z. B. UR 117, verbunden dargestellt, der wiederum mit UR 118 verbunden wird. Die Netze 107 und 108 werden als über die UR 112 und 118 miteinander verbunden gezeigt, womit Unicast-IP-Kommunikation zwischen einem mit dem Unicast-IP-Netzwerk 107 verbundenen Client-Endgerät und einem mit dem Unicast-IP-Netzwerk 108 verbundenen Client-Endgerät ermöglicht wird. Die Unicast-Client-Endgeräte 110, 111 und 115 z. B. können über einen Plain Old Telephone Service (POTS = herkömmlichen Telefondiesnt)-Einwahlanschluss, einen ISDN-Anschluss oder einen Asynchronous Digital Subscriber Loop (ADSL)-Anschluß jeweils mit einem Ortsnetzbetreiber (Local Exchange Carrier, LEC) (nicht gezeigt) und von dort mit einem Internet-Dienstprovider (Internet Service Provider, ISP) (nicht gezeigt), der wiederum mittels eines Unicast-Routers mit dem Unicast-IP-Netzwerk verbunden ist, mit den Netzen 107 oder 108 verbunden werden.
Alternativ kann ein Client-Endgerät mittels eines Kabelmodems über Kabeleinrichtungen mittels eines Kabelfernsehen-Providers mit einem ISP verbunden werden. Darüber hinaus könnte das Unicast-Client-Endgerät beispielsweise über ein weiträumiges Netz (Wide Area Network, WAN), T1-Einrichtungen, Frame Relay, ATM oder X.25 mit einem LAN und einem Kunden-Standort-Router mit einem UR verbunden werden. In Übereinstimmung mit dieser Erfindung können Unicast-Client-Endgeräte 110, 111, 115 beispielsweise an Unicast-IP-Netzwerken 107 und 108 an einer Multicast-IP-Sitzung im IP-Multicast-Netzwerk 101 teilnehmen. Speziell wird eine solche Funktionalität mittels Multicast-Unicast-Servern (MUSs) wie beispielsweise des MUS 120 im Netz 107 und des MUS 121 im Netz 108 ermöglicht, die jeweils ihre jeweiligen Unicast-IP-Netzwerke 107 und 108 mit dem IP-Multicast-Netzwerk 101 verbinden.
Die Multicast-Unicast-Server 120 und 121 arbeiten als Gateways, die es den Unicast-verbundenen Clients in ihren jeweiligen Unicast-IP-Netzwerken ermöglichen, auf das IP-Multicast-Netzwerk 101 zuzugreifen. Speziell ermöglicht es jeder MUS mittels Interaktion mit der Client-Software im Unicast-Client im Unicast-IP-Netzwerk diesem Client, sich einer Gruppe im IP-Multicast-Netzwerk anzuschließen, indem Informationen darüber bereitgestellt werden, welche Sitzungen gerade im Netz 101 ablaufen oder geplant sind. Der MUS empfängt und sendet dann Daten über diese Gruppen innerhalb einer vom Client ausgewählten Sitzung für den Client. So dient der MUS dazu, die Adresse der Multicast-IP-Pakete einer angeforderten Gruppe in die Unicast-IP-Endpunkt-Adresse des anfordernden Clients zu konvertieren. Außerdem dient der MUS dazu, Pakete, die er vom Unicast-Endpunkt-Client empfängt, an eine Liste aller anderen Unicast-Endpunkt-Empfänger für die angeforderte Multicast-Gruppe in demselben Unicast-IP-Netzwerk oder einem verbundenen Unicast-IP-Netzwerk (107 oder 108) sowie an die Multicast-Gruppenadresse selbst im IP-Multicast-Netzwerk 101 zu gesendet, um es z. B. den mit diesem Netz verbundenen Multicast-Endpunkten 103 und 104 zu ermöglichen, Pakete zu empfangen, die vom Unicast-Client stammen.
Die 2 und 3 sind Blockdiagramme eines MUS 201 bzw. eines Client-Endgeräts 301, die ihre Funktionen darstellen, die es ihnen ermöglichen, in Übereinstimmung mit der vorliegenden Erfindung zu arbeiten. In 2 hört ein Sitzung-Beschreibung-Protokoll (SDP)-Mithörprozess 202, der mit dem IP-Multicast-Netzwerk 101 verbunden ist, Sitzungsankündigungen ab, die im Multicast-Netzwerk 101 gesendet werden. Solche Verzeichnisansagen werden wiederholt über das IP-Multicast-Netzwerk 101 gesendet. Diese "bekanntgegebenen" Sitzungen werden vom benachrichtigten SDP/SAP-Prozess 203 empfangen und in einer Sitzungsdatenbank 204 gespeichert. Andere Sitzungen, die nicht angesagt und somit nicht vom SDP-Lauscher-Prozess 202 empfangen werden, werden mittels eines statischen Sitzungsprozesses 205 von einem Systemadministrator eingegeben und ebenfalls in der Sitzungsdatenbank 204 gespeichert. Ein Beispiel für letzteres könnte ein Wetterkanal sein, der immer an einem vordefinierten Socket vorhanden ist und nicht wiederholt über das IP-Multicast-Netzwerk 101 angesagt wird.
Ein HTTP-Server 206 kann die Sitzungsdatenbank 204 lesen, so dass der Client, wenn er eine Verbindung zum Server herstellt, in der Lage ist, eine Liste der zur Zeit im IP-Multicast-Netzwerk 101 vorhandenen Multicast-Sitzungen zu empfangen. Wenn der Client eine Verbindung zum Server 206 herstellt, führt der Server namens des Clients CGI-(Common Gateway Interface)-Skripts 207 innerhalb des HTTP-Servers 206 aus, um dem Client die Informationen vorzulegen, die die Sitzungen betreffen. Diese Informationen werden mittels des Web-Browserprogramms 302 (in 3) des Clients 301 an diesen zurückübermittelt (3). Der Client startet eine Anfrage zur Teilnahme an einer Sitzung, indem er eine URL auf einer HTML-Webseite auswählt, die ihm vom HTTP-Server 206 präsentiert wird. Eine Nachricht wird solchermaßen durch den Web-Browser 302 vom Client 301 gesendet, die, wenn sie vom Server HTTP 206 empfangen wird, bewirkt, dass dieser bestimmte Aktionen aufruft. Im speziellen sendet der HTTP-Server 206 eine Antwort zurück an den Client, die eine Steuermeldung umfasst, die Informationen enthält, die anzeigen, welches Werkzeug verwendet werden muss, um an der ausgewählten Sitzung teilzunehmen. Solche Werkzeuge sind im Stand der Technik gut bekannt und können beispielsweise das Visual Audio Tool (VAT), das Visual Conference Tool (VIC) oder das Internet Protocol Television Tool (IPTV) einschließen. Darüber hinaus zeigt die Nachricht an, wo die Werkzeuge angeschlossen werden sollten, d. h. speziell, an welchem Socket am MUS das Werkzeug angeschlossen werden sollte. Auf der Clientseite gibt der Client 301 dann vom Startprogramm 303 das angegebene Werkzeug vom Werkzeug-Programm 304 an die angegebene Sockets am MUS 201 aus. Das CGI-Skriptprogramm 207 stößt dann den Wandler-/Paket-Weiterleitungsserver 208 innerhalb des MUS 201 an, der/n angeforderten Multicast-Gruppe/n (eine Gruppe je ausgewählte Medienart) beizutreten, die mit der ausgewählten Sitzung verknüpft ist/sind. Die CGI-Skripts 207, die diese Beitrittsaktion einleiteten, fügen dann die Unicast-Adresse des Clients zu einer Liste von Empfängern für die angeforderte/n Multicast-Gruppe/n hinzu. Der Server 208 leitet dann die vom Client erhaltenen Multicast-Pakete an die Liste der Empfänger für jede Gruppe weiter, der er beigetreten ist, und übersetzt die Multicast-Adresse der von der jeweiligen Gruppe erhaltenen Pakete in die Unicast-Adresse des beitretenden Clients.
Die Schritte, die damit verknüpft sind, dass ein Client einer Sitzung beitritt, werden detailliert in Bezug auf das Flußdiagramm in 4 auseinandergesetzt. Im Schritt 401 akkumuliert der SDP-Lauscher-Prozess Verzeichnisansagen des IP-Multicast-Netzwerkes 101 in der Datenbank 204. Die Datenbank wird gefiltert und in eine Standard-HTML-Seite konvertiert, worin jeder URL auf Informationen zeigt, die sich auf jede Multicast-Sitzung in der gefilterten Datenbank beziehen. Im Schritt 402 lauscht der HTTP-Server 206 auf Anfragen nach Multicast-Sitzungen/URLs auf der HTML-Seite, die eine Liste der URLs enthält, die die Sitzungen beschreibt. Im Schritt 403 wird eine Anfrage eines Clients nach einer Kopie der Seite, die die Multicast-Sitzungen enthält, empfangen. Im Schritt 404 sendet der HTTP-Server 206 eine Nachricht zurück an den Client, die den Benutzer auffordert, zu Authentifizierungszwecken eine Anmelde-ID und ein Kennwort einzugeben. Wenn der Benutzer sich im Schritt 405 erfolgreich authentifiziert hat, liefert der Server 206 im Schritt 406 eine Seite an den Client zurück, die eine Liste der Sitzungen enthält. Wenn der Benutzer des Clients im Schritt 407 die Seite überprüft und eine von einem URL angezeigte Sitzung anfordert, liefert der Server 206 im Schritt 408 eine Seite zurück, die Details der Sitzung und Schaltflächen enthält, die es dem Client ermöglichen, den Beginn der Sitzung sowie weitere hierin später beschriebene Funktionen anzufordern. Im Schritt 409 startet der Client eine ausgewählte Sitzung (oder spezifische Medien in der Sitzung), indem er eine Schaltfläche auf der HTML-Seite "anklickt". Der Server 206 startet dann ein Steuerskript 207. Im Schritt 410 sendet das Steuerskript 207 eine Antwort an den Client, die Informationen darüber enthält, welches Multimedia-Werkzeug ablaufen soll und welche UDP-Sockets (die Unicast-IP-Adresse auf dem MUS und die verknüpften Ports) er abhören und ihnen die Informationen senden soll, die der angeforderten Gruppe entsprechen. Es kann davon ausgegangen werden, dass mindestens ein Socket verwendet wird. Ein zweites Socket kann verwendet werden, um von jedem Mitglied der Multicast-Gruppe Steuer-/Statusinformationen zu senden. Im Schritt 411 bewirkt dasselbe Steuerskript 207 des Servers 206, dass das Multicast-zu-Unicast-Gateway der gewünschten Multicast-Gruppe beitritt, und fügt den anfordernden Client zu der Liste von Empfängern für die angeforderte Multicast-Gruppe hinzu. Für jeden anfordernden Client konvertiert der Server 206 auch die Adresse der Multicast-IP-Pakete der angeforderten Gruppe in die Unicast-IP-Adresse des anfordernden Clients und sendet die Unicast-IP-Pakete mittels des gut bekannten Protokolls für Benutzerdatagramme (Benutzer Datagram Protokoll, UDP) an den anfordernden Client. Der Server 206 überträgt auch alle Pakete, die er vom Client empfängt, an jeden weiteren Unicast-Client in dieser Multicast-Gruppe sowie an die Multicast-Gruppenadresse im IP-Multicast-Netzwerk 101 selber. Wenn der Client das Multimedia-Werkzeug verlässt, erfasst der Server 206 im Schritt 412, dass die Statusmeldungen vom Client nicht mehr gesendet werden, und entfernt den Client aus der Liste von Zielen für die jeweilige Multicast-Gruppe.
Die Schritte, die mit der Erstellung einer neuen Sitzung durch einen Client verknüpft sind, werden detailliert in 5 auseinandergesetzt. Wie zuvor in Verbindung mit den Schritten in 4 beschrieben, die mit dem Beitritt eines Clients zu einer Sitzung verknüpft sind, akkumuliert der SDP-Lauscher-Prozess 202 im Schritt 501 die Verzeichnisansagen des IP-Multicast-Netzwerkes 101 in der Datenbank 204. Die Datenbank wird gefiltert. und in eine Standard-HTML-Seite konvertiert, worin jeder URL auf Informationen zeigt, die sich auf jede Multicast-Sitzung in der gefilterten Datenbank beziehen. Im Schritt 502 lauscht der HTTP-Server 206 auf Anfragen nach Multicast-Sitzungen/URLs auf der HTML-Seite, die eine Liste der URLs enthält, die die Sitzungen beschreibt. Wenn ein Benutzer eines Clients im Schritt 503 eine Kopie der Seite anfordert, die die Multicast-Sitzungen enthält, sendet der Server 206 im Schritt 504 eine Nachricht zurück an den Client, die für Authentifizierungszwecke eine Anmelde-ID und ein Kennwort anfordert. Wenn die Authentifizierung im Schritt 505 erfolgreich ist, liefert der Server 206 eine Seite an den Client zurück, die eine Liste der Sitzungen enthält. Wenn der Benutzer diese Seite durchsucht und einen spezifischen URL anfordert, liefert der Server 206 im Schritt 507 eine Seite zurück, die Details zu der Sitzung und Schaltflächen enthält, die es dem Client ermöglichen anzufordern, dass eine Sitzung gestartet wird, eine neue Sitzung zu erstellen, eine bestehende Sitzung zu bearbeiten oder zu löschen und die aktuelle Sitzung aufzuzeichnen, wobei die letztere Funktion hiernach beschrieben wird. Wenn der Benutzer im Schritt 508 eine Schaltfläche "anklickt", um eine neue Sitzung zu erzeugen, liefert der Server 206 im Schritt 509 ein Formular an den Client zurück, das den Client auffordert, eine Anmelde-ID und ein Kennwort einzugeben, die zum Erstellen einer neuen Sitzung geeignet sind und die identisch mit oder anders als die Anmelde-ID und das Kennwort sein können, die mit dem ursprünglichen Authentifizierungsvorgang verknüpft waren. Wenn der Client im Schritt 51b zur Erzeugung der Sitzung authentifiziert wird, liefert der Server 206 im Schritt 511 dem Client ein Formular mit Feldern zurück, die vom Benutzer auszufüllen sind im Hinblick auf den Sitzungsnamen, die Sitzungsbeschreibung, eine URL-Adresse für detail liertere oder verknüpfte Informationen, ein Feld zur Einstellung des Multicast-Paket-Time-to-Live-Werts (TTL), Auswahlfelder für verschiedene Media-Werkzeuge und verknüpfte Codierungsformate, zu verwendende Multicast-Adressen und Ports, den Namen und die Telefonnummer einer zuständigen Person und die Dauer der Sitzungsansage. Wenn der Benutzer die Felder ausfüllt und eine Create-Schaltfläche anklickt, wird das ausgefüllte Formular an den Server 206 zurückgeschickt. Der Server 206 überprüft, ob bestimmte Schlüsselfelder richtig und ausgefüllt sind. Falls nicht, wird eine Fehlermeldung an den Client zurückgegeben; anderenfalls speichert der Server 206 die Daten in einer Datei, die für die Anmelde-ID indiziert ist, die für den Zugriff auf das Formular verwendet wird. Die Daten werden dann im Schritt 512 einem Sitzung-Anmeldung-Protokoll-(SAP)-Prozess 210 auf dem MUS 201 zur Verfügung gestellt. Im Schritt 513 kündigt der SAP-Prozess 210 periodisch die Sitzung auf einer/m gut bekannten Multicast-IP-Adresse und Port an, die über einen Zeitraum, der dem im Formular eingetragenen Feld für die Dauer gleicht, für diese Ansagen reserviert sind. Wenn dieser Zeitraum verstreicht, hört der SAP-Prozess 210 auf, die Sitzung anzukündigen.
In Übereinstimmung mit der vorliegenden Erfindung kann ein Unicast-Endpunkt auch verlangen, dass eine Sitzung zum späteren neuerlichen Senden oder Abrufen auf Anfrage aufgezeichnet wird. Um diese Aufzeichnung durchzuführen, wird in 1 ein Rekorder 125 über das LAN 126 mit dem IP-Multicast-Netzwerk 101 verbunden. Das Flußdiagramm in 6 stellt detailliert die Schritte dar, die mit der Anfrage eines Benutzers an einem Client-Endgerät nach Aufzeichnung einer Sitzung verbunden sind. Wie zuvor beschrieben, muss dem Client eine Anmelde-ID und ein Kennwort gegeben werden, um den Zugriff auf den HTTP-Server 206 zu ermöglichen, der eine Liste der IP-Multicast-Sitzungen hat. Im Schritt 601 akkumuliert der SDP-Lauscher-Prozess 202 Verzeichnisansagen des IP-Multicast-Netzwerkes 101 in der Datenbank 204. Die Datenbank wird gefiltert und in eine Standard-HTML-Seite konvertiert, worin jeder URL auf Informationen zeigt, die sich auf jede Multicast-Sitzung in der gefilterten Datenbank beziehen. Im Schritt 602 lauscht der Server 206 auf Anfragen nach Multicast-Sitzungen/URLs auf der HTML-Seite, die eine Liste von URLs enthält, die die Sitzungen beschreiben. Wenn ein Benutzer im Schritt 603 eine Kopie der Seite anfordert, die die Multicast-Sitzungen enthält, sendet der Server 206 im Schritt 604 eine Nachricht zurück an den Client, die für Authentifizierungszwecke seine oder ihre Anmelde-ID und das Kennwort anfordert. Wenn im Schritt 605 die Authentifizierung erfolgreich ist, liefert der Server 206 im Schritt 606 eine Seite an den Client zurück, die eine Liste der Sitzungen enthält. Wenn ein Benutzer diese Seite durchsucht und einen URL aufruft, liefert der Server 206 im Schritt 607 eine Seite, die Details zur Sitzung enthält, und Schaltflächen zurück, die es dem Client ermöglichen, eine Sitzung anzufordern, die existierende Sitzung zu starten, eine neue Sitzung zu erzeugen, eine bestehende Sitzung zu bearbeiten oder zu löschen oder die aktuelle Sitzung aufzuzeichnen. Im Schritt 608 "klickt" der Benutzer eine Schaltfläche an, um eine Sitzung aufzuzeichnen, und im Schritt 609 liefert der Server 206 ein Formular an den Client zurück, das den Benutzer auffordert, zu Aufzeichnungszwecken eine Anmelde-ID und ein Kennwort einzugeben, die identisch mit oder anders als die in einem vorherigen Schritt verwendeten Anmelde-ID und Kennwort sein können. Wenn der Client im Schritt 610 für die Sitzungsaufzeichnung authentifiziert wird, liefert der Server 206 ein Formular mit Feldern, die auszufüllen sind, oder Optionen zum Auswählen zurück. Das Formular enthält Auswahlfelder für die verschiedenen Medien der Sitzung und Anfangs- und Enddaten und Zeitfelder sowie eine Schaltfläche "Start", die "anzuklicken" ist, wenn das Formular ausgefüllt ist. Wenn der Benutzer die Felder ausfüllt und das Startformular wählt, wird das ausgefüllte Formular an den Server 206 zurückgeschickt. Der Server 206 prüft, ob bestimmte Schlüsselfelder richtig und ausgefüllt sind. Falls nicht, wird eine Fehlermeldung an den Client zurückgesandt; anderenfalls speichert der Server die Daten in einer Datei, die für die Anmelde-ID indiziert ist, die verwendet wurde, um auf das Formular zuzugreifen. Im Schritt 611 sendet der Server 206 eine Nachricht an den aufzeichnenden Server 125, zu dem angegebenen Datum und Zeitpunkt mit der Aufzeichnung zu beginnen.
Der aufzeichnende. Server 125 zeichnet dann im Schritt 612 zum passenden Zeitpunkt mittels eines gut bekannten Programms zum Lesen der IP-Multicast-Pakete im RTP-Format die Sitzung auf. Im Schritt 613 wird die gespeicherte Sitzung auf Verlangen des Benutzers abgerufen.
Um die Einwahl-Unicast-Endpunkt-Benutzer zu unterstützen, werden innerhalb des IP-Multicast-Netzwerkes 101 Codewandler- und Geschwindigkeitsanpassung-Gateways im Stand der Technik wie z. B. der Codewandler/Adapter 127 in 1 bereitgestellt. Wie in 1 gezeigt, wird das Codewandler/Geschwindigkeitsanpassung-Gateway 127 mit Hilfe des LAN 128 mit dem IP-Multicast-Netzwerk 101 verbunden. Alternativ kann das Codewandler/Geschwindigkeitsanpassungs-Gateway 127 entweder mit dem MUS 120 oder 121 koresident sein. Das Gateway bildet mit Hilfe von Algorithmen zum Verwerfen von Rahmen existierende Sitzungen hoher Bandbreite auf Versionen niedriger Bandbreite derselben Sitzung ab, die für Modems mit 28,8 kbps oder ISDN-Adapter geeignet sind. Ansagen zu diesen Geschwindigkeit-gesteuerten Sitzungen werden dann in die Datenbank von Sitzungen des IP-Multicast-Netzwerks 101 gestellt.
Ein alternativer Mechanismus zum Aufrufen der Codewandlung-/Geschwindigkeitsanpassung-Gateways könnte auf einer Benutzer/Client-Aktion basieren. Die Schritte, die damit verknüpft sind, dass ein Client angefragt, dass der Code einer Sitzung automatisch umgesetzt bzw. die Rate angepasst wird, werden detailliert in den 7A und 7B dargestellt. Wie zuvor beschrieben, muss dem Benutzer des Clients eine Anmelde-ID und ein Kennwort gegeben werden, um den Zugriff auf den HTTP-Server 206 zu ermöglichen. Wie zuvor beschrieben, akkumuliert der SDP-Lauscher-Prozess 202 im Schritt 701 Verzeichnisansagen des IP-Multicast-Netzwerkes 101 in der Datenbank 204g. Die Datenbank wird gefiltert und in eine Standard-HTML-Seite konvertiert, worin jeder URL auf Informationen zeigt, die sich auf jede Multicast-Sitzung in der gefilterten Datenbank beziehen. Es wird angenommen, dass jeder Sitzung ein erforderlicher Bandbreitenparameter und ein maximaler Paketverlustparameter zugeordnet sind. Für Sitzungen, die ein Formular verwenden wie zuvor beschrieben, wird dies durch die Verwendung von zusätzlichen Feldern erreicht, die diesen Parametern im oben beschriebenen Formular der "neuen Sitzung" entsprechen. Im Schritt 702 lauscht der HTTP-Server 206 auf Anfragen nach Multicast-Sitzungen/URLs auf der HTML-Seite, die eine Liste der URLs enthält, die die Sitzungen beschreibt. Wenn im Schritt 703 von einem Client eine Anfrage nach einer Kopie der Seite empfangen wird, die die Multicast-Sitzungen enthält, sendet der Server 206 eine Nachricht zurück an den Client, die für Authentifizierungszwecke eine Anmelde-ID und ein Kennwort anfordert. Wenn im Schritt 705 die Authentifizierung erfolgreich ist, liefert der Server 206 im Schritt 706 eine Seite zurück an den Client, die eine Liste der Sitzungen enthält. Wenn danach der Benutzer die Seite durchsucht und im Schritt 707 eine Sitzung und eine Gruppe (Gruppen) in einer Sitzung auswählt, liefert der Server 206 im Schritt 708 eine Seite zurück, die Details zur Sitzung und Schaltflächen enthält, die ermöglichen, dass der Client den Beginn einer Sitzung anfordert, eine neue Sitzung erstellt, eine bestehende Sitzung bearbeitet oder löscht oder die aktuelle Sitzung aufzeichnet. Im Schritt 709 klickt der Benutzer eine Schaltfläche an, um anzufordern, dass die Sitzung oder bestimmte Medien in der Sitzung starten. Als Reaktion darauf startet der Server 206 im Schritt 710 ein Steuerskript, das eine Reihe von Testpaketen an den Client sendet. Im Schritt 711 führt der Client dieselben Pakete zurück zum Server 206. Im Schritt 712 berechnet der Server einen Schätzwert der verfügbaren Bandbreite und des Paketverlusts auf dem Weg zwischen Server und Client, indem er die gesendeten Testpakete mit den empfangenen Testpaketen vergleicht. Wenn im Entscheidungsschritt 713 die Leistungserfordernisse der Sitzung über denen des Wegs liegen, wird im Schritt 714 die Geschwindigkeitsanpassung oder Codewandler benötigt. Falls nicht, fährt der Prozess wie zuvor für einen einer bestehenden Sitzung beitretenden Client beschrieben fort. Wenn die Geschwindigkeitsanpassung oder Codewandler benötigt wird, wird im Schritt 715 auf der Grundlage der gemessenen Eigenschaften des Wegs eine von einer Mehrzahl von Codierungen niedriger Rate ausgewählt. Es ist anzunehmen, dass der Server 206 eine endliche Menge an Geschwindigkeit-anpassten Sitzungen gestattet. Wenn beispielsweise die ursprüngliche Sitzung 128 kbps war, kann die Geschwindigkeitsanpassung auf 56 kbps, 28,8 kbps und 20 kbps gestattet werden. Im Schritt 716 sendet der HTTP-Server 206 eine Nachricht an das Codewandler-/Geschwindigkeitsanpassung-Gateway 127, die anzeigt, welcher Multicast-Gruppe beigetreten werden soll, auf welche Bandbreite die Rate der Medienart angepasst werden sollte, welche alternative Codierung gegebenenfalls angewandt werden muss und welche neue Multicast-Adresse und Portnummer die Code-gewandelte Sitzung verwenden sollte. Im Schritt 717 wird ermittelt, ob die Rate dieser Gruppe bereits angepasst bzw. der Code umgesetzt wurde. Falls ja, werden im Schritt 718 die Multicast-Adresse und die Port-Nummer verwendet, die der bereits Geschwindigkeit-angepassten/Code-gewandelten Gruppe entsprechen, und der Prozess rückt auf den Schritt 719 vor. Falls nicht, wird im Schritt 720 das Codewandler-/Geschwindigkeitsanpassung-Gateway 127 aufgerufen, um den Code der Sitzung mit den passenden Bandbreitenparametern umzusetzen und die daraus hervorgehende Sitzung niedrigerer Bandbreite unter Verwendung einer anderen Multicast-Adresse und Port-Nummer erneut mehrfach zu senden. Im Schritt 719 sendet der Server 206 eine Nachricht an den Client, die Informationen darüber enthält, welches Multimedia-Werkzeug gestartet werden soll und an welchen UDP-Sockets (der Unicast-IP-Adresse auf dem MUS und den verknüpften Ports) gelauscht werden soll und ihnen Informationen bezüglich der angeforderten Sitzung zugesendet werden sollen. Im Schritt 721 bewirkt das Steuerskript, dass das MUS-Gateway eine Verbindung zur angeforderten Multicast-Gruppe herstellt und den anfordernden Client zu der Liste von Empfängern für die angeforderte Multicast-Gruppe hinzufügt. Für jeden anfordernden Client konvertiert der Server die Adresse der Multicast-IP-Pakete der angeforderten Gruppe in die Unicast-IP-Adresse des anfordernden Clients und sendet die Unicast-IP-Pakete mittels des gut bekannten Benutzer Datagram Protokolls an den anfordernden Client. Der Server überträgt auch alle Pakete, die er vom Client empfängt, an die Liste der Empfänger für diese Multicast-Gruppe sowie an die Multicast-Gruppenadresse selbst. Wenn der Client im Schritt 722 das Multimedia-Werkzeug verlässt, erkennt der HTTP-Server 206, dass keine Statusmeldungen mehr vom Client gesendet werden, und entfernt den Client aus der Liste der Bestimmungsorte für die betreffende Multicast-Gruppe.
Das oben beschriebene System ist insofern in hohem Maße skalierbar, als der MUS und andere Server im Multicastfähigen Abschnitt des Netzes verteilt sein können. Wenn die Zahl dieser Endpunkte wahrscheinlich groß ist, wird es um der Effizienz willen bevorzugt, dass sich die Server nahe an den Unicast-Client-Endpunkten befinden. Für eine kleine Konferenzgruppe ist der Standort oder die Verteilung der MUS nicht wichtig. Vorteilhafterweise ermöglicht es die vorliegende Erfindung jedem Dienst, dem das IP-Multicasting zugrundeliegt, graduell eingeführt und in kleinem Maßstab angewandt zu werden, bevor alle Clients zum IP-Multicasting befähigt werden. Während Clients IP-Multicastingfähig werden, könnte es einen Übergang zu einer Hybrid-IP-Multicast-Betriebsart geben, worin einige Clients IP-Multicast-verbunden sind und andere nicht.
Obwohl die vorliegende Erfindung im Hinblick auf Unicast-IP-Endpunkten beschrieben wird, die mit einem IP-Multicast-Netzwerk 101 wie beispielsweise MBONE verbunden werden, könnte sie in Verbindung mit jedem beliebigen IP-Multicast-Netzwerk verwendet werden. Weiterhin könnte die vorliegende Erfindung mit jedem beliebigen Multicast-Netzwerk und Unicast-Netzwerk verwendet werden, das ähnlich wie die IP-Multicast- und Unicast-Netzwerke arbeitet.
Die oben beschriebenen Ausführungsformen stellen die Grundsätze der vorliegenden Erfindung dar. Weitere Ausführungsformen könnten von Fachleuten ersonnen werden, ohne sich vom Schutzumfang der vorliegenden Erfindung zu lösen.
Wenn technische Merkmale in den Ansprüchen mit Bezugszeichen versehen sind, so sind diese Bezugszeichen lediglich zum besseren Verständnis der Ansprüche vorhanden und dementsprechend stellen solche Bezugszeichen keine Einschränkungen des Schutzumfangs solcher Elemente dar, die nur exemplarisch durch solche Bezugszeichen gekennzeichnet sind.

Claims

Ein Verfahren, das einem Unicast-Client (110, 111, 115) in einem Unicast-Netzwerk (107, 108) einen Zugriff auf eine Multicast-Sitzung und ein Erzeugen einer Multicast-Sitzung in einem Multicast-Netzwerk (101) bereitstellt, das folgendes umfasst: das Akkumulieren an einem Gateway-Server (120, 121), der das Multicast-Netzwerk (101) und das Unicast-Netzwerk (107, 108) miteinander verbindet, von Verzeichnisinformation, die die Multicast-Sitzungen in dem Multicast-Netzwerk (101) betrifft; das Versorgen des Unicast-Clients (110, 111, 115) mit der Verzeichnisinformation, die vom Gateway-Server (120, 121) akkumuliert wird; das Empfangen am Gateway-Server (120, 121) vom Unicast-Client (110, 111, 115) einer Anfrage zum Beitreten an eine oder zum Erzeugen einer Multicast-Sitzung; das Reagieren auf die Anfrage, indem (i) der angefragten Multicast-Sitzung am Gateway-Server (120, 121) namens des Unicast-Clients (110, 111, 115) beigetreten wird, wenn die Anfrage lautet, einer von der Verzeichnisinformation ausgewählten Multicast-Sitzung beizutreten; oder (ii) indem am Gateway-Server (120, 121) die Information über die Multicast-Sitzung empfangen und gespeichert wird und die Multicast-Sitzung durch den Gateway-Server (120, 121) in das Multicast-Netzwerk (101) auf eine vorbestimmte Multicast-Adresse für solche Ansagen angesagt wird, wenn die Anfrage lautet, eine neue Multicast-Sitzung zu erzeugen; wobei das Verfahren weiterhin folgendes umfasst: das Konvertieren am Gateway-Server (120, 121) einer Adresse von Multicast-Paketen, die an einer Multicast-Adresse empfangen werden, die mit der angefragten Sitzung verknüpft ist, in eine Unicast-Adresse des Unicast-Clients (110, 111, 115) und das Senden der Multicast-Pakete, die durch den Gateway-Server (120, 121) an der Multicast-Adresse empfangenen werden, an den Uni cast-Client (110, 111, 115); und das Senden der Pakete, die am Gateway-Server (120, 121) vom Unicast-Client (110, 111, 115) empfangenen werden, an die Multicast-Adresse, die mit der angefragten Sitzung verknüpft ist.
Das Verfahren nach Anspruch 1, worin die Anfrage eine Anfrage zum Beitreten von mindestens einer Gruppe einer Mehrzahl von Gruppen ist, die mit der Multicast-Sitzung verknüpft ist, wobei jede der Mehrzahl von Gruppen eine verknüpfte Multicast-Adresse hat.
Das Verfahren nach Anspruch 2, worin jede der mindestens einen Gruppe mit einer unterschiedlichen Medienart verknüpft ist.
Das Verfahren nach Anspruch 1, das weiterhin vor der Versorgung des Unicast-Clients (110, 111, 115) mit der Verzeichnisinformation die Authentifizierung des Unicast-Clients (110, 111, 115) umfasst.
Das Verfahren nach Anspruch 4, worin die Authentifizierung das Empfangen am Gateway-Server (120, 121) einer Anmelde-Identität und eines Kennworts vom Unicast-Client (110, 111, 115) umfasst.
Das Verfahren nach Anspruch 1, worin die Unicast- und Multicast-Netzwerke (107, 108, 101) jeweils IP-(Internetprotokoll)-Unicast- und IP-Multicast-Netzwerke sind.
Das Verfahren nach Anspruch 6, worin die Pakete zwischen dem Gateway-Server (120, 121) und dem Unicast-Client (110, 111, 115) mittels Verwendung des Benutzer-Datagramm-Protokolls gesendet werden.
Das Verfahren nach Anspruch 6, worin die Verzeichnisinformation eine HTML-Seite umfasst, die eine Mehrzahl von URLs hat, wobei jede auf Information zeigt, die mit einer Multicast- Sitzung in dem IP-Multicast-Netzwerk (101) verknüpft ist.
Das Verfahren nach Anspruch 6, worin das IP-Multicast-Netzwerk (101) MBONE ist.
Das Verfahren nach Anspruch 1, worin die Sitzung periodisch in dem Multicast-Netzwerk (101) angesagt wird.
Das Verfahren nach Anspruch 1, das weiterhin, nach dem Empfang einer Anfrage vom Unicast-Client (110, 111, 115) am Gateway-Server (120, 121) zum Erzeugen einer Sitzung, die Authentifizierung des Unicast-Clients (110, 111, 115) für das Erzeugen einer Sitzung umfasst.
Das Verfahren nach Anspruch 1, das weiterhin folgendes umfasst: das Empfangen einer Anfrage am Gateway-Server (120, 121) vom Unicast-Client (110, 111, 115) zum Aufzeichnen einer ausgewählten Multicast-Sitzung, die von der Verzeichnisinformation ausgewählt wird; und das Senden einer Nachricht, die eine Information über die ausgewählte Sitzung vom Gateway-Server (120, 121) enthält, an einen mit dem Multicast-Netzwerk (101) verbundenen aufzeichnenden Server (125), um die ausgewählte Sitzung aufzuzeichnen.
Das Verfahren nach Anspruch 12, worin das Unicast-Netzwerk (107, 108) und das Multicast-Netzwerk (101) jeweils IP-(Internetprotokoll)-Unicast- und IP-Multicast-Netzwerke sind.
Das Verfahren nach Anspruch 12, das weiterhin das Empfangen am Gateway-Server (120, 121) vom Unicast-Client (110, 111, 115) von Information über die ausgewählte Multicast-Sitzung umfasst, die Information darüber einschließt, wann die Aufzeichnung gestartet und gestoppt wird.
Das Verfahren nach Anspruch 14, worin die am Gateway-Server (120, 121) vom Unicast-Client (110, 111, 115) empfangene Information weiterhin eine Identifizierung der speziellen Medien für die Aufzeichnung der ausgewählten Multicast-Sitzung einschließt.
Das Verfahren nach Anspruch 12, das weiterhin, nach dem Empfang einer Anfrage am Gateway-Server (120, 121) vom Unicast-Client (110, 111, 115) zur Aufzeichnung einer Sitzung, die Authentifizierung des Unicast-Clients (110, 111, 115) zum Aufzeichnen einer Sitzung umfasst.
Das Verfahren nach Anspruch 12, das weiterhin folgendes umfasst: das Empfangen einer Anfrage am Gateway-Server (120, 121) vom Unicast-Client (110, 111, 115) zum Zugriff auf die aufgezeichnete Sitzung; das Senden einer Nachricht an den aufzeichnenden Server (125) vom Gateway-Server (120, 121), damit der aufzeichnende Server (125) die aufgezeichnete Sitzung wiedergewinnt; das Empfangen der aufgezeichneten Sitzung am Gateway-Server (120, 121); und das Senden der aufgezeichneten Sitzung vom Gateway-Server (120, 121) an den Unicast-Client (110, 111, 115).
Das Verfahren nach Anspruch 1, das weiterhin folgendes umfasst: das Bestimmen eines Schätzwerts der verfügbaren Bandbreite zwischen dem Gateway-Server (120, 121) und dem Unicast-Client (110, 111, 115); das Auswählen einer Codiergeschwindigkeit, die geringer ist als eine mit der ausgewählten Sitzung verknüpfte Codiergeschwindigkeit, wenn der Schätzwert der verfügbaren Bandbreite kleiner ist als die erforderliche Bandbreite für die ausgewählte Sitzung; das Senden einer Nachricht vom Gateway-Server (120, 121) an einen mit dem Multicast-Netzwerk (101) verbundenen Codewandler-Server (127), um die mit der ausgewählten Sitzung verknüpfte Codiergeschwindigkeit an die ausgewählte geringere Codiergeschwin digkeit der Geschwindigkeit nach anzupassen; das Empfangen am Gateway-Server (120, 121) vom Codewandler-Server (127) einer Anzeige der Multicast-Adresse, an die die Geschwindigkeit-angepasste ausgewählte Sitzung gesendet wird; und worin das Beitreten in die angefragte Multicast-Sitzung das Beitreten in die Geschwindigkeit-angepassten Sitzung namens des Unicast-Clients (110, 111, 115) am Gateway-Server (120, 121) an der angezeigten Multicast-Adresse umfasst, an die die Geschwindigkeit-angepasste ausgewählte Sitzung gesendet wird; und das Konvertieren das Konvertieren der Adresse der an der Multicast-Adresse empfangenen Multicast-Pakete, an die die Geschwindigkeit-angepasste ausgewählte Sitzung gesendet wird, in die Unicast-Adresse des Unicast-Clients (110, 111, 115) umfasst, und das Senden der vom Gateway-Server (120, 121) an dieser Multicast-Adresse empfangenen Multicast-Pakete an den Unicast-Client (110, 111, 115).
Das Verfahren nach Anspruch 18, worin das Unicast- und das Multicast-Netzwerk (107, 108, 101) jeweils IP-(Internetprotokoll)-Unicast-Netzwerke und IP-Multicast-Netzwerke sind.
Das Verfahren nach Anspruch 18, worin die Anfrage zum Beitreten in eine Multicast-Sitzung eine Anfrage zum Beitreten von mindestens einer Gruppe einer Mehrzahl von Gruppen ist, die mit der Multicast-Sitzung verknüpft ist, wobei jede der Mehrzahl von Gruppen eine verknüpfte Multicast-Adresse hat.
Das Verfahren nach Anspruch 20, worin jede der Mehrzahl von Gruppen mit einer unterschiedlichen Medienart verknüpft ist.
Das Verfahren nach Anspruch 18, worin die Bestimmung eines Schätzwerts der verfügbaren Bandbreite folgendes umfasst: das Senden einer Reihe an Testpaketen an den Unicast-Client (110, 111, 115); das Empfangen eines Echos dieser Testpakete zurück vom Unicast-Client (110, 111, 115); und das Vergleichen der gesendeten Reihe an Testpaketen mit dem empfangenen Echo dieser Testpakete.
Ein Multicast-Unicast-Server (120, 121), der folgendes umfasst: ein Mittel (202, 204), um von einem damit verbundenen Multicast-Netzwerk (101) Verzeichnisinformation zu akkumulieren, die Multicast-Sitzungen in dem Multicast-Netzwerk (101) betrifft; ein Mittel (206), um von einem Unicast-Client (110, 111, 115) in einem mit dem Server (120, 121) verbundenen Unicast-Netzwerk (107, 108) eine Anfrage zum Beitreten einer Multicast-Sitzung unter den in der Verzeichnisinformation akkumulierten Sitzungen zu empfangen; ein Mittel (207) zum Beitreten der angefragten Multicast-Sitzung namens des Clients (110, 111, 115); und ein Mittel (208) zum Konvertieren der Multicast-Adresse der Multicast-Pakete an der angefragten Multicast-Sitzung in eine mit dem Unicast-Client (110, 111, 115) verknüpfte Unicast-Adresse, und zum Senden der Multicast-Pakete an der angefragten Multicast-Sitzung an den Unicast-Client (110, 111, 115) an jener Unicast-Adresse und zum Senden von Paketen, die vom Unicast-Client (110, 111, 115) empfangen werden, an die mit der ausgewählten Sitzung verknüpfte Multicast-Adresse.
Der Server (120, 121) nach Anspruch 23, worin das Multicast-Netzwerk (101) und das Unicast-Netzwerk (107, 108), an das der Server (120, 121) verbunden ist, jeweils ein IP-(Internetprotokoll)-Multicast-Netzwerk und ein IP-Unicast-Netzwerk ist.
Der Server (120, 121) nach Anspruch 24, worin die Pakete mittels Verwendung des Benutzer-Datagramm-Protokolls zwischen dem Server (120, 121) und dem Unicast-Client (110, 111, 115) gesendet werden.
Der Server (120, 121) nach Anspruch 23, worin die Anfrage zum Beitreten einer Multicast-Sitzung eine Anfrage zum Beitreten von mindestens einer Gruppe aus einer Mehrzahl von Gruppen ist, die mit der Multicast-Sitzung verknüpft ist, wobei jede der Mehrzahl von Gruppen eine verknüpfte Multicast-Adresse hat.
Der Server (120, 121) nach Anspruch 26, worin jede der Mehrzahl von Gruppen mit einer unterschiedlichen Medienart verknüpft ist.
Der Server (120, 121) nach Anspruch 23, worin das Mittel (208) zum Konvertieren auch die vom Unicast-Client (110, 111, 115) empfangenen Pakete an einen anderen mit dem Server (120, 121) verknüpften Unicast-Client (110, 111, 115) sendet, wobei der andere Client (110, 111, 115) ebenfalls mit der Sitzung verknüpft ist.