DE69927713T2

DE69927713T2 - Angekündigte Sitzungsbeschreibung

Info

Publication number: DE69927713T2
Application number: DE69927713T
Authority: DE
Inventors: Sarah Cottenham BELL; Sarom Ipswich ING; Steven Ipswich RUDKIN
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1998-11-27
Filing date: 1999-11-19
Publication date: 2006-08-10
Anticipated expiration: 2019-11-20
Also published as: EP1142267B1; JP2002533023A; WO2000036804A1; HK1043002A1; CA2352207A1; US7181526B1; EP1142267A1; DE69927713D1; GB9826158D0; AU1395900A; CA2352207C

Description

Die vorliegende Erfindung bezieht sich auf die Ankündigung von Verbindungen für Mediendatenströme über ein Kommunikationsnetz in einer Media-Sitzung.
Multicast-Übertragungen nehmen im Internet mehr und mehr zu. Im Gegensatz zu Punkt-zu-Punkt-Übertragungen (Unicast) nach dem standardmäßigen Internetprotokoll (IP) ermöglichen IP-Multicast-Verbindungen die gleichzeitige Übertragung von Information von einer Einzelquelle aus an eine Gruppe von Empfängern. Die Unterstützung der Weiterleitung bei IP-Multicast-Übertragungen wird durch MBone (IP Multicast Backbone) gewährleistet, wobei es sich um virtuelles Netz handelt, das dem Internet überlagert ist.
IP-Multicast ermöglicht Kommunikation über großflächige IP-Netze in Echtzeit, und typische Übertragungen beinhalten Video- und Audio-Konferenzen, Multimedia-Live-Unterricht, Vorlesungen einer Universität und Übertragung von Live-TV-Programmen.
Eine Multicast-Übertragung besteht üblicherweise aus einer Multimedia-Sitzung, die sich zusammensetzt aus mehreren individuellen Mediendatenströmen, die typischerweise Videosignale, Audiosignale, Leerflächen- oder Rohdaten einschließen. Einige Sitzungen sind dauerhaft, aber die Mehrheit wird nur für eine bestimmte Zeitdauer eingerichtet, die jedoch nicht zusammenhängend sein muss. Übertragungen auf der Basis von Multicast über MBone unterscheiden sich von Unicast-IP-Übertragungen darin, dass jeder Anwender, der die Übertragung empfängt, an der Sitzung teilnehmen kann (außer bei verschlüsselter Übertragung) und eine Übertragung empfangen kann, ein Anwender muss nur die entsprechende Übertragungsadresse und Zeitinformation kennen.
Vor einer Multicast-Übertragung wird eine entsprechende Ankündigung gemacht, die eine Sitzungsbeschreibung enthält, üblicherweise unter einer IP-Gruppe-Multicast-Adresse. Standardmäßige Sitzungsbeschreibungen werden erzeugt unter Verwendung eines Protokolls für die Sitzungsbeschreibung (Session Description Protocol, SDP), wie es definiert ist in dem Entwurf RFC 2327 der Internet Engineering Task Force. SDP ist ein einfacher ASCII-Text, der auf dem Protokoll basiert, das verwendet wird, um multimediale Sitzungen in Echtzeit und dazugehörige Abwicklungsinformation zu beschreiben. SPD-Nachrichten werden in einem Trägerprotokoll verpackt, das bekannt ist als Protokoll für die Sitzungsankündigung (Session Announcement Protocol, SAP), das die notwendige IP-Adressierung und Weiterleitungsinformation für die Übertragung über das Internet oder MBone enthält und es außerdem ermöglicht, dass die SDP-Nachricht verschlüsselt wird, signiert wird oder komprimiert wird. Eine Ankündigung kann dann in regelmäßigen Intervallen an die Ankündigungsgruppenadresse geschickt werden. Als Alternative zu SAP kann eine Sitzung angekündigt werden durch Veröffentlichen einer SDP-Nachricht auf einer World Wide Web-Site (WWW) oder durch Absenden per E-Mail oder als Unicast-Übertragung an Einzelpersonen, mit der sie zur Teilnahme eingeladen werden.
Eine SDP-Nachricht enthält Information über jeden Mediendatenstrom in der multimedialen Multicast-Sitzung, um es den Empfängern zu ermöglichen, an der Sitzung teilzunehmen. Eine typische SDP-Nachricht enthält den Sitzungsnamen und -zweck, die Zeit(en) und das Datum, zu dem die Sitzung aktiv ist, die Komponenten der Medienströme der Sitzung und Information, die die Voraussetzungen für die Teilnahme an jedem Mediendatenstrom enthält (IP-Multicast-Adresse, Port, Medienformat). Die SDP-Nachricht kann außerdem Einzelheiten in Bezug auf die Anforderungen der Bandbreite der Sit zung, einen Verschlüsselungsschlüssel, der dazu notwendig ist, um an einer sicheren Multicast-Übertragung unter Verwendung der Verschlüsselung mit öffentlichem Schlüssel teilnehmen zu können, Kontaktinformation in Bezug auf die Organisation der Multicast-Sitzung und einen eindeutigen Ressourcenindikatorwert (Unique Resource Indicator, URI) enthalten, der auf eine WWW- oder eine Intranet-Web-Seite hinweist, auf der weitere Information bezüglich der Sitzung abgerufen werden kann, beispielsweise Hintergrundinformation mit Bezug auf die Konferenz.
Der Grad, in dem der Anwender an einer Sitzung oder einem Austausch teilnehmen kann, hängt von dem gewünschten Zweck ab. Bei einer Multicast-Fernsehsitzung sind die Anwender in der Regel nur berechtigt, die Datenströme in der Sitzung zu empfangen, während bei einer Multicast-Konferenzsitzung die Kommunikation bidirektional ist und ein Zentral-Server (wie die Gruppenadresse 120) alle Übertragungen der Teilnehmer empfängt und sie an die übrigen Teilnehmer weiterleitet. Der Grad der Teilnahme, der von einem Anwender an einer Sitzung oder einem Datenstrom erwartet wird, kann in der Sitzungsbeschreibung explizit festgelegt werden, oder er kann inhärent aus der Sitzungsbeschreibung hervorgehen, beispielsweise wenn eine Anwendung mit ausschließlichem Empfang mit einem Mediendatenstromtyp in der Sitzungsbeschreibung in Zusammenhang gebracht wird.
Eine gemeinsame Eingangsschnittstelle, die von Multicast-Endteilnehmern verwendet wird, ist als Sitzungsverwaltung (Session Directory Rendezvous, SDR) bekannt. Diese Schnittstelle nimmt die empfangenen Ankündigungen entgegen, decodiert die SDP-Nachricht und zeigt die Namen derjenigen Sitzungen an, die in einer Liste noch vorhanden sind. Der Endteilnehmer kann dann unter den aufgeführten Ankündigungen eine auswählen, um sich über weitere technische und Anwender-orientierte Einzelheiten der angekündigten Sitzung zu informieren. Auf Grund der angezeigten Information kann der Endteilnehmer dann wählen, ob er in den individuellen Austausch der Sitzung eintritt oder in die gesamte Sitzung eintritt. Sobald die Datenaustauschvorgänge ausgewählt wurden, an denen eine Teilnahme gewünscht wird, wird durch SDR die notwendige Multicast-fähige Multimedia-Applikation auf dem Rechner des Endteilnehmers gestartet, wie zum Beispiel Vic und Vat, und die entsprechende Datenaustauschinformation (eine Port-Adresse für den Transport) wird von der Ankündigung zu der Applikation übertragen, wodurch es der Applikation ermöglicht wird, die Verbindung mit der dazugehörigen IP-Multicast-Adresse einzurichten und während der Übertragung an dem Datenaustausch teilzunehmen. Nachdem die Applikationen initiiert wurden und die relevante Port-Adresse für den Transport weitergeleitet wurde, spielt SDR in der Sitzung keine weitere Rolle.
Die in letzter Zeit steigende Nutzung und Nachfrage nach (Multi-)Media-Sitzungen hat eine Anzahl von Einschränkungen beim SDP aufgedeckt. SDP beschränkt die Sitzungsbeschreibungen auf das Definieren einer Sitzung mit einer bestimmten Menge von Zeitpunkten, die für alle darin vorhandenen Datenaustauschvorgänge gelten. Eine Sitzung, bei der ein Datenaustauschvorgang mitten in der Übertragung beginnt, kann unter Verwendung von SDP nicht so ohne weiteres beschrieben werden. Die Struktur einer Sitzungsbeschreibung, geschrieben in SDP, muss eine einfache, lineare Liste von Datenaustauschvorgängen sein, die nicht unbedingt der intuitiven Struktur einer komplexen Sitzung entspricht. SDP unterstützt eine beschränkte und vordefinierte Menge von Applikationen, die die Datenaustauschvorgänge empfangen können, sowie eine begrenzte und vordefinierte Menge von Transportmechanismen (z. B. Simple Layering, RTP und UDP). Da die Garantie der Dienstgüte (Quality of Service, QoS) für die Verbraucher und die Anbieter immer bedeutender wird, muss auch die Notwendigkeit erfüllt werden, QoS-Richtlinien für die gesamte Sitzung und individuelle Datenaustauschvorgänge in Bezug auf die erforderlichen System-Ressourcen, Anforderungen an die Bandbreite und unterstützte Applikationen zu definieren. Es kann darüber hinaus Anforderungen in Bezug auf die Reihenfolge von Datenaustauschvorgängen und Teilsitzungen oder kompliziertere Vereinbarungen über das Empfangen geben.
In "SDP: Session Description Protocol", RFC 2327, April 1998 (1998-04), Seite 1–42, XP002101463, ISSN: 0923-5965, wird beschrieben, wie eine Sitzungsbeschreibung aus einer Beschreibung der Sitzungsebenen, die Einzelheiten zu der gesamten Sitzung enthält sowie aus allen medialen Datenaustauschvorgängen besteht, und optional mehreren Beschreibungen der Medienebenen besteht, die jeweils Einzelheiten enthalten, die für einen einzelnen medialen Datenaustauschvorgang gelten. Eine Ankündigung besteht aus einer Beschreibung der Sitzungsebenen, der null oder mehr Medienebenenabschnitte folgen. In RFC 2327 wird beschrieben, wie viele SDP-Sitzungsbeschreibungen aneinandergehängt werden können, d.h. RFC 2327 beschreibt, wie jede Beschreibung der Sitzungsebenen und irgendeine der optionalen Beschreibungen der Medienebenen für eine Sitzung an andere Beschreibungen der Sitzungsebenen und entsprechende Beschreibungen der Medienebenen angehängt werden kann. Eine weitere Anforderung an die Anbieter ist die Notwendigkeit, Einrichtungen zu betreiben, die das Teilnehmen eines Endteilnehmers bei einer Multicast-Übertragung ermöglichen, für die er sich angemeldet hat, und zwar gemäß dem QoS und der Art der Datenaustauschvorgänge, die empfangen werden, etc. Es gibt wenig Spielraum, Information über die QoS-Richtlinien oder die Teilnahmen innerhalb der konventionellen Struktur einer SDP-Sitzungsbeschreibung oder irgendwelcher Metadaten über die Sitzung einzubauen.
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren angegeben zum Ankündigen der Beschreibung einer Media-Sitzung unter Verwendung eines modularen Beschreibungssystems, das dazu ausgelegt ist, eine verteilte Ankündigung mit Links, die einem Anwender zur Verfügung stehen, zu anderen Teilen der Ankündigung zu erzeugen, die noch nicht übertragen wurden, wobei das Verfahren die Schritte umfasst:
Erzeugen eines ersten Basismoduls mit einer ersten Datenstruktur mit Anwender-orientierten Daten, die bezüglich der Media-Sitzung relevant sind,
Erzeugen wenigstens eines Medienmoduls mit einer zweiten Datenstruktur mit Medien-orientierten Daten, die für einen Anwender notwendig sind, um einen entsprechenden Medienstrom von der Media-Sitzung zu empfangen,
Bereitstellen eines Links zwischen dem ersten Basismodul und dem wenigstens einem Medienmodul und
Ankündigen der Media-Sitzung, indem wenigstens das erste Basismodul potentiellen Empfängern der Media-Sitzung zur Verfügung gestellt wird,
wobei es der Link zwischen dem ersten Basismodul und dem wenigstens einen Medienmodul einem Anwender möglich macht, auf das wenigstens eine Medienmodul zuzugreifen und danach den Medienstrom zu empfangen.
Die vorliegende Erfindung schafft ein modulares Beschreibungssystem für eine Media-Sitzung, wobei Sitzungsbeschreibungen in hierarchischer Art und Weise aufgebaut werden, wobei mehrere Ebenen der Information vorgesehen werden, die die Bestandteile der beschriebenen Sitzung betreffen.
Ein Problem bei der gegenwärtigen Verteilung von Ankündigungen von der einzelnen Ankündigungsgruppenadresse ist es, dass es in Bezug auf die Größe von jeder Ankündigung und die Frequenz, mit der sie jeweils ausgesendet werden kann, eine Grenze gibt. Bei der vorliegenden Erfindung ist es möglich, ein modulares Beschreibungssystem zu schaffen, bei dem eine verteilte Ankündigung Links enthält, die dem Endteilnehmer zur Verfügung stehen und auf andere Abschnitte der Ankündigung verweisen, die nicht übertragen wurden.
Vorzugsweise umfasst das Verfahren die Schritte: Erzeugen eines zweiten Basismoduls, wobei das zweite Basismodul Anwender-orientierte Daten mit Bezug auf eine Teilsitzung der Media-Sitzung enthält, Verbinden des zweiten Basismoduls mit dem ersten Basismodul und Verbinden des wenigstens einen Medienmoduls mit dem zweiten Basismodul.
In bevorzugten Ausführungsformen umfasst das Verfahren außerdem die Schritte: Erzeugen wenigstens eines Optionsmoduls mit einer dritten Datenstruktur mit Daten mit Bezug auf Dienstebenenkriterien, die erforderlich sind, um an der Media-Sitzung teilzunehmen, und Verbinden des oder jedes Optionsmoduls mit einem jeweiligen Basismodul.
Die Daten in dem Optionsmodul können sich auf eine Dienstgüterichtlinie beziehen, die verwendet werden soll bei der Media-Sitzung oder einem Teil davon. Alternativ können sich die Daten in dem Optionsmodul auf ein Sicherheitssystem beziehen, das verwendet werden soll durch die Media-Sitzung oder einen Teil davon. Die Daten in dem Optionsmodul können sich außerdem auf ein Ladesystem beziehen, das anzuwenden ist für die Media-Sitzung oder einen Teil davon.
In bevorzugten Ausführungsformen umfassen ein oder mehrere Medienmodule Daten, die notwendig sind für einen Anwender, um einen geschichteten Medienstrom einer jeweiligen Media-Sitzung zu empfangen, und das Verfahren umfasst außerdem den Schritt Verbinden des oder jedes Medienmoduls mit einem oder mehreren jeweiligen Optionsmodulen mit Daten mit Bezug auf einen geschichteten Mechanismus des jeweiligen geschichteten Medienstroms, die für eine Partei notwendig sein, um an dem geschichteten Medienstrom teilzunehmen.
Die Media-Sitzung kann angekündigt werden durch Übertragen aller Modulbestandteile der Sitzungsbeschreibung. Alternativ kann die Media-Sitzung angekündigt werden durch Übertragen nur einiger der Modulbestandteile der Sitzungsbeschreibung, wobei die restlichen Module der Sitzungsbeschreibung anschließend dem Zugriff durch einen Anwender unter Verwendung eines oder mehrerer Links in den übertragenen Modulen zur Verfügung stehen. Die restlichen Module der Sitzungsbeschreibung können sich auf einem oder mehreren Servern befinden, und der eine oder mehrere Links zu den restlichen Modulen haben die Form von URI-Zeigern. Die Module der Sitzungsbeschreibung enthalten Links zu Modulen, die erzeugt werden anschließend an die Ankündigung.
Gemäß einem zweiten Aspekt der Erfindung wird ein von einem Computer lesbares Speichermedium geschaffen, auf dem Daten enthalten sind, die wenigstens einen Teil einer modularen Beschreibung einer Media-Sitzung in einem modularen Beschreibungssystem definieren, bei dem eine verteilte Ankündigung Links enthält, die einem Anwender zur Verfügung stehen, zu anderen Teilen der Ankündigung, die noch nicht übertragen wurden, wobei die modulare Sitzungsbeschreibung umfasst: ein erstes Basismodul mit einer ersten Datenstruktur mit Anwender-orientierten Daten, die für die Media-Sitzung relevant sind,
wenigstens ein Medienmodul mit einer zweiten Datenstruktur mit Medien-orientierten Daten, die notwendig sind für einen Anwender, um einen jeweiligen Medienstrom von der Media-Sitzung zu empfangen,
einen Link zwischen dem ersten Basismodul und dem wenigstens einem Medienmodul, wobei es der Link einem Anwender möglich macht, auf das wenigstens eine Medienmodul zuzugreifen und danach den Medienstrom zu empfangen.
Ein weiteres Problem, vor dem die Anbieter von heutigen (Multi-)Media-Sitzungen stehen, und dies betrifft auch die Entwickler von den dazugehörigen (Multi-)Media-Applikationen, ist die Verteilung des Wissens, um eine Applikation implementieren zu können, die eine Datenverbindung in Echtzeit initiieren und verwalten kann über ein Kommunikationsnetz und (Multi-)Media-Funktionen durchführen kann, die der Endteilnehmer erwartet. Beispielsweise benötigen Entwickler und Multimedia-Applikationen Teams mit der Fähigkeit der Audio- und Videocodierung, Kenntnissen von Netzwerktransportprotokollen, Echtzeitprogrammierung, Anwenderschnittstellenaufbauten und Integrationstechniken. Die Sitzungsbeschreibung der vorliegenden Erfindung vereinfacht diesen Prozess, indem die notwendigen Kommunikationskanäle und die Medienströme in der Sitzungsbeschreibung definiert werden können. Diese Information wird verwendet durch genetische Middleware in Form einer Sitzungssteuerung und Kommunikationsverwaltungen zur dynamischen Instantiierung der jeweiligen Datenströme und Kanäle für die laufenden Applikationen.
Bis jetzt bestand der einzige Weg eine QoS-Reglementierung zu implementieren darin, eine Sitzungsbeschreibung zu verarbeiten, um festzulegen, welche Datenströme bei einer Sitzung laufen könnten oder sollten, und dann die Applikationen zu initialisieren, so dass eine Verbindung mit den jeweiligen Datenströmen zustande kommt. Dies machte es erforderlich, dass der Kommunikationsmanager nicht nur über die Anforderungen der Sitzung und die verfügbaren Systemressourcen informiert war, sondern auch über die Fähigkeiten jeder Applikation.
Bei einem bevorzugten Beispiel der vorliegenden Erfindung werden die Medienmodule einer Sitzungsbeschreibung durch die jeweilige Multimedia-Client-Applikation vor dem QoS-Management geprüft, so dass dadurch die Arbeitsbelastung des Kommunikationsmanagers gesenkt wird, das heißt durch die jeweilige Client-Applikation bestimmt wird, ob die Medienmodule unterstützt werden können. Darüber hinaus brauchen die Applikationen nur Datenströme von dem Sitzungssteuersystem anzufordern, das mit dem Client zusammenhängt, da die Erzeugung und das Management der Datenströme nun von der Sitzungssteuerung in Echtzeit besorgt werden. Dieser Aspekt ist außerdem Gegenstand unserer ebenfalls anhängigen UK-Patentanmeldung 9826257.1.
Mit der vorliegenden Erfindung werden die Entwicklung von Applikationen und die Bereitstellung von Diensten vereinfacht. Ein weiteres Problem besteht darin, dass Applikationen in der Lage sein sollten, sich an das zur Verfügung stehende Netz und die Host-Ressourcen anzupassen. Dies ist besonders wichtig bei Mehrparteien-Applikationen, die in heterogenen Umgebungen arbeiten, wobei jede Partei unterschiedlich Ressourcen zur Verfügung haben kann. Darüber hinaus ist die Eigenschaft der Heterogenität über die Lebensdauer der Sitzung variabel, beispielsweise da sich die Auslastung des Netzes ändert oder da die Terminal-Ressourcen mit anderen Applikationen oder anderen Anwendern geteilt werden. Mit der vorliegenden Erfindung wird man in die Lage versetzt, eine QoS-Richtlinie zu nutzen, die innerhalb der Sitzungsbeschreibung inkorporiert ist, um die Zuweisung der Ressourcen in ihrer Reihenfolge zu regeln und festzulegen, ob die Teilnahme an der Sitzung möglich ist.
Ein weiteres Problem, vor dem der Anwender von Applikationen und der Dienstsanbieter stehen, besteht darin, dass sie sich um Sicherheit und Anforderungen an die Auslastung kümmern müssen. Die vorliegende Erfindung macht es möglich, dass die Sicherheits- und Auslastungsrichtlinien innerhalb der Sitzungsbeschreibung für die Anwendung in dem Sitzungssteuersystem inkorporiert werden, um die entsprechenden Auslastungs- und Sicherheitsprozeduren zu aktivieren. Anstatt dass Sicherheits- und Auslastungsfunktionen entwickelt werden müssen, müssen die Entwickler von Applikationen und die Dienstsanbieter nur die entsprechenden Richtlinien spezifizieren.
Bei der vorliegenden Erfindung wird die Entwicklung von Applikationen durch Verwendung von Sitzungsbeschreibungen vereinfacht, um die Dynamikverwaltung der Kommunikationskanäle zu füttern und an die zur Verfügung stehenden Ressourcen anzupassen. Auch das Problem der Bewältigung der Anforderungen an Auslastung und Sicherheit wird zu einer Sache der Spezifizierung der Auslastung und Sicherheitsrichtlinien innerhalb der Sitzungsbeschreibung reduziert.
Ein Beispiel der vorliegenden Erfindung wird im Folgenden im Einzelnen mit Bezug auf die beigefügten Zeichnungen beschrieben.
1 ist eine schematische Darstellung zur Erläuterung einer Multicast-Übertragung über MBone.
2 ist eine schematische Darstellung zur Erläuterung der Verteilung einer SDP-Ankündigung.
3 ist ein Blockdiagramm einer modularen Sitzungsbeschreibung einer einfachen Sitzung, die gemäß der vorliegenden Erfindung erzeugt wurde.
4 ist ein Blockdiagramm einer modularen Sitzungsbeschreibung einer komplexen Sitzung, die gemäß der vorliegenden Erfindung erzeugt wurde.
5 ist eine schematische Darstellung eines Systems zum Verwalten von Medienstromverbindungen.
6 ist ein Flussdiagramm zur Erläuterung der Schritte, die beim Verwalten einer Media-Sitzung gemäß dem System nach 5 abgearbeitet werden.
7 ist ein Flussdiagram, das darüber hinaus einen Analyseschritt in 6 erläutert.
Ein Beispiel für ein IP-Multicast-Übertragungssystem wird mit Bezug auf 1 beschrieben. Vor einer Multicast-Übertragung wird eine entsprechende Ankündigung mit einer Sitzungsbeschreibung als Inhalt erstellt, so dass dadurch die Endteilnehmer 110a–110e in die Lage versetzt werden, die Übertragung empfangen zu können. Jeder Endteilnehmer, der die Übertragung empfangen möchte, wird mit einer Gruppen-IP-Multicast-Adresse 120 verbunden, die zu der Übertragung gehört. Zum Zeitpunkt der Übertragung der Multicast-Sitzung werden die Sitzungsströme von einer Quelle 130 oder mehreren Quellen an die Gruppenadresse übertragen. Bei der Gruppenadresse wird die Übertragung über die Verbindungen 140 an diejenigen Endteilnehmer weiter verbreitet, die einen Empfang wünschen (in diesem Beispiel die Endteilnehmer 110a–110c).
Ein Beispiel für eine Ankündigung und ein Auswahlsystem wird mit Bezug auf 2 beschrieben. Die meisten öffentlichen Multicast-Sitzungen werden bei einer einzelnen Gruppen-IP-Multicast-Adresse 200 angekündigt, die für die Übertragung der Ankündigungen an Multicast-Endteilnehmer vorgesehen ist. Die Endteilnehmer 210a–220e, die die Ankündigungen empfangen wollen, sind mit der Ankündigungsgruppenadresse verbunden, und auf die gleiche Art wie bei einer tatsächlichen Sitzungsübertragung wird jede Ankündigung, die bei der Ankündigungsgruppenadresse ankommt, an die Endteilnehmer weiter verbreitet. Eine Eingangsschnittstelle 220 in dem Computer von jedem Endteilnehmer zeigt die Information an, die bei jeder Ankündigung in der dazugehörigen Sitzungsbeschreibung enthalten ist. Die minimale Information, die eine Sitzungsbeschreibung enthalten kann, besteht aus Zeit und Datum, wann die Sitzung aktiv sein wird, und der oder den Gruppen-IP-Multicast-Adressen, unter denen der Endteilnehmer wählen kann, um einen oder mehrere Medienströme zu empfangen, und wohin eigene Datenströme für die Sitzung geschickt werden können. Unter Verwendung der Eingangsschnittstelle kann ein Endteilnehmer die angekündigte Sitzung oder Sitzungen oder ihren Teilstrom bzw. ihre Teilströme auswählen, soweit Teilnahme erwünscht ist.
3 ist ein Blockdiagramm einer Sitzungsbeschreibung 300 für eine einfache Multicast-Fernsehsitzung. Die Sitzungsbeschreibung 300 umfasst ein Basismodul 310, das mit einem Medienmodul 320 verbunden ist.
Das Basismodul 310 enthält Anwender-orientierte Daten mit Bezug auf die Sitzung, einschließlich Titel und Zeitinformation. Das Basismodul 310 kann außerdem eine Beschreibung oder eine Zusammenfassung, Kontaktinformation über den Organisator und einen WWW- oder einen Intranet-URI-Zeiger auf eine Webseite mit weiterer Information enthalten. Idealerweise sollte das Basismodul 310 genügend Information für den Anwender enthalten, damit sich dieser entscheiden kann, ob er Interesse an einer Teilnahme an der Sitzung hat.
Das Medienmodul 320 enthält Ankündigungsdaten mit Bezug auf einen Videostrom der Sitzung. Das Medienmodul 320 enthält die technische Information (als Daten), die für den Anwender notwendig ist, damit er den dazugehörigen Medienstrom empfangen kann. Im Einzelnen sind Details bezüglich Verbindung, Zeitangabe und Medienformat vorgesehen.
Ein erstes Beispiel einer Sitzungsbeschreibung 300, die für die Übertragung an Endteilnehmer erzeugt wurde, ist im Folgenden aufgelistet:
(
type = (base)
id = (310)
info = (title = "live multicast television session")
source = (name = "A.Sender" email = asender@tx.com)
media = (video = (client = odbitsO.16))
time = (length = 50 m repeat = continuous)
category = ("Entertainment")
options = (none)
modules = (m = 320)
)
(
type = (media)
id = (320 310)
media = (video = (client = odbitsO.16))
connection = (229.1.1.2/7000)
time = (length = 50 m)
)
Sitzungsbeschreibung, Beispiel 1
Das Basismodul 310 hat eine eindeutige Identifizierung (ID-Feld), die bei der Erzeugung der Links zwischen zwei Modulen während der Verarbeitung der Sitzungsbeschreibung verwendet wird. Das Feld der Module des Basismoduls 310 listet Typ und eindeutige Identifizierung des Medienmoduls 320 auf, das mit dem Basismodul 310 verbunden ist. Die zweite Identifizierung in dem ID-Feld des Medienmoduls 320 ist die eindeutige Identifizierung, die zu dem Basismodul 310 gehört, das das Medienmodul später wieder mit dem Basismodul 310 verbindet. Bei Erweiterung ermöglichen diese Hin- und Rückverbindungen einen Modulbaum, der von einem Basismodul nach unten oder von einem Medienmodul nach oben durchlaufen wird. Die Verwendung dieses Merkmals wird später mit Bezug auf das Beispiel 4 von einer Sitzungsbeschreibung erläutert.
Das Verbindungsfeld des Medienmoduls 320 enthält die IP-Multicast-Adresse und die Port-Nummer, unter der der Medienstrom empfangen werden kann.
4 ist ein Blockdiagramm einer Sitzungsbeschreibung 400 für eine komplexe Multicast-Sitzung einer Multimediakonferenz mit zwei Spuren oder Teilsitzungen und einer Podiumsdiskussion. Jede Spur dient einer Mehrparteienvideo- und -audiokonferenz sowie einer gemeinsamen Leerfläche zum Hinterlassen von Notizen und Nachrichten. Die Podiumsdiskussion wird verschlüsselt, und die gesamte Konferenz wird in Form einer Teilnahmegebühr bezahlt, die von jedem Teilnehmer im voraus entrichtet werden muss.
Die Sitzungsbeschreibung 400 enthält ein Basismodul 410 der obersten Ebene, das mit weiteren Basismodulen 420, 430, 440 und einem Optionsmodul 411 verbunden ist. Das Überebenenbasismodul 410 enthält Daten mit Bezug auf die Gesamtsitzung einschließlich Name, Zweck und Zeitinformation. Das Optionsmodul 411 enthält Einzelheiten bezüglich der Zahlungsart der Teilnahmegebühren.
Jedes weitere Basismodul 420, 430, 440 bezieht sich auf Teilsitzungen der Konferenz. Das Basismodul 420 bezieht sich auf die erste Spur der Konferenz. Das Basismodul 420 ist mit den Medienmodulen 421–423 verbunden, die jeweils Informationen über Verbindung, Zeit und Medienformatdaten für die entsprechenden Video-, Audio- und Leerflächenströme enthalten.
Das Basismodul 420 ist ebenfalls mit dem Optionsmodul 424 verbunden, das Daten mit Bezug auf eine QoS-Richtlinie für die erste Spur enthält, womit definiert wird, welches der Medienmodule optional ist und welches zwingend vorgeschrieben ist für eine Teilnahme an der ersten Spur. Die Liste der zwingend vorgeschriebenen enthält Identifizierungen derjenigen Medienmodule, die für die Sitzung oder Teilsitzung notwendig sind, damit diese korrekt abgewickelt werden können, während die Liste der optionalen die Identifizierungen der Medienmodule enthält, die nicht notwendig sind, um die Sitzung oder Teilsitzung korrekt abwickeln zu können, wenn die Systemressourcen knapp sind.
Das Basismodul 430 bezieht sich auf die zweite Spur der Konferenz. Sie wird mit Medienmodulen 431–433 verbunden, die jeweils Informationen bezüglich Verbindung, Zeit und Medienformatdetails für die jeweiligen Video-, Audio- und Leerflächenströme enthalten. Das Basismodul 430 ist ebenfalls verbunden mit dem Optionsmodul 434, das Daten enthält, die Bezug zu einer QoS-Richtlinie für die zweite Spur haben, wodurch definiert wird, welches Medienmodul optional ist und welches zwingend vorgeschrieben ist für einen Teilnehmer an der zweiten Spur. Das Basismodul 440 hat Bezug zu der Podiumsdiskussion. Es ist mit den Medienmodulen 441 und 442 verbunden, die jeweils Informationen über Verbindung, Zeit und Medienformatdetails für die jeweiligen Video- und Audioströme der Podiumsdiskussion enthalten. Das Basismodul 440 ist ebenfalls mit dem Optionsmodul 434 verbunden, das Verschlüsselungsdetails enthält (d.h. wie und wo die notwendigen kryptografischen Schlüssel zur Verfügung stehen), was notwendig für einen Teilnehmer ist, um die Medienströme 441, 442 der Podiumsdiskussion gemäß einem bekannten Verschlüsselungsmechanismus wie zum Beispiel DES oder der Verschlüsselung mit öffentlichem Schlüssel entschlüsseln zu können.
Die Videomedienströme, die in dem Medienmodul 441 definiert sind, sind in Schichten angeordnet. Die Schichtung der Medienströme macht es möglich, dass Anwender mit verschiedenen Systemressourcen so viel von den Datenströmen empfangen können, wie ihre Systemressourcen zulassen. Jeder Anwender muss die unterste Schicht des Datenstroms empfangen, worin die minimalen Datenstromdaten enthalten sind. Wenn jedoch ein Anwender ausreichend freie Systemressourcen hat, kann die nächste Schicht darüber mit Erweiterungen der vorangehenden Schicht empfangen werden. Aufeinanderfolgende Schichten können empfangen werden, so dass der empfangene Medienstrom verbessert wird, bis die maximale Anzahl von Schichten empfangen worden ist oder alle freien Systemressourcen in ihrer Kapazität aufgebraucht sind. Das Medienmodul 441 ist mit einem Optionsmodul 44 verbunden, das Daten bezüglich der Schichtung enthält, die für den Endteilnehmer notwendig sind, um den geschichteten Datenstrom korrekt empfangen zu können.
Der Abschnitt der Sitzungsbeschreibung 400, die für die Module 410, 411, 420 und 440 zur Übertragung an die Endteilnehmer erzeugt wurde, ist im Folgenden als Beispiel 2 für die Sitzungsbeschreibung gezeigt.
(# overall conference session
type = (base)
id = (410)
info = (title = "Multimedia98 Conference")
source = (owner = "JoeBloggs" email = joe@nowhere.com)
media = (video = (client = RealPlayerG2) whiteboard = (client = wb))
time (start = "09:00 GMT 25/12/98" stop = "13:00 GMT 25/12/98")
options = (oc = 411)
modules = (b = 420 b = 430 b = 440 oc = 411)
)
(# conference track 1
type = (base)
id = (420 410)
info = (title = "MM98 Systems and Applications Track")
source = (owner = "JoeBloggs" email = joe@nowhere.com)
media = (video = (client = RealPlayerG2) whiteboard = (client = wb))
time (start = "09:00 GMT 25/12/98" stop = "11:00 GMT 25/12/98")
options = (osq = 424)
modules = (m = 421 m = 422 m = 423 osq = 424)
)
(# session QoS for track 1
type = (option-sQoS)
id = (424 420)
mandatory = (421 422)
optional = (423)
)
(# conference panel discussion
type = (base)
id = (440 410)
info = (title = "MM98 Panel Discussion")
source = (name = "JoeBloggs" email = joe@nowhere.com)
media = (video = (client = RealPlayerG2) whiteboard = (client = wb))
time (start = "11:00 GMT 25/12/98" stop = "13:00 GMT 25/12/98")
options = (osec = 443)
modules = (m = 441 m = 442 osec = 443)
)
(# video for panel discussion
type = (media)
id = (441 440)
info = (title = "MM98 Panel Discussion Video")
source = (owner = "JoeBloggs" email = joe@nowhere.com)
media = (video = (type = live client = RealPlayerG2))
connection = (226.0.0.106/1010 policy = 444)
time = (start = "11:00 GMT 25/12/98" stop = "13:00 GMT 25/12/98")
)
(# media QoS policy for panel discussion video
type = (option-mQoS)
id = (444 440)
mechanism = (layer = (base = 226.0.0.106/1010 number = 3))
)
(# encryption policy for panel discussion
type = (option-sec)
id = (443 440)
participant = (member = w3c)
publickey = (location = http://www.w3.org/members_only/)
info = (location = http://www.w3.org/)
)
(# charging policy for entire conference
type = (option-chg)
id = (411 410)
mechanism = (type = AAA)
price = (fee = 1000GBP)
info = (location = http://www.aaa.net/)
)
Sitzungsbeschreibung, Beispiel 2
Wo zusätzliche Netzbandbreite zur Verfügung steht, können vollständige Sitzungsbeschreibungen den Endteilnehmern angekündigt werden, die sich dann entscheiden können, die angekündigte Sitzung oder Teile davon zu empfangen. Jedoch müssen die einzelnen Module der Sitzungsbeschreibung nicht zusammen angekündigt werden. Wenn durch die zur Verfügung stehende Netzbandbreite für Ankündigungen die Größe der Sitzungsbeschreibungen einschränkt wird, braucht nur das Überebenenbasismodul angekündigt zu werden. In dieser Situation kann die Verbindung zwischen den Modulen beispielsweise eine URI zu einem WWW- oder Intranet-Web-Site oder einem Server sein, einer E-Mail-Adresse, einer IP-Multicast-Adresse, einer FTP-Adresse oder Details einer Datei oder Datenbank, gespeichert auf einem lokalen Computersystem, von dem sich ein interessierter Anwender die restlichen Module besorgen kann.
Das folgende Beispiel einer Sitzungsbeschreibung zeigt, wie sich die obigen Sitzungsbeschreibung für das Basismodul 420 ändern würde, wenn das Medienmodul 421 auf einem WWW-Server gespeichert würde:
(# conference track 1
type = (base)
id = (420 410)
info = (title = "MM98 Systems and Applications Track")
source = (owner = "JoeBloggs" email = joe@nowhere.com)
media = (video = (client = RealPlayerG2) whiteboard = (client = wb))
time (start = "09:00 GMT 25/12/98" stop = "11:00 GMT 25/12/98")
options = (osq = 424)
modules = (m = 421 location = http://www.announce.org/cgi-bin/module.cgi?id = 421
m = 421 m = 423 osq = 424)
)
Sitzungsbeschreibung, Beispiel 3
Darüber hinaus können Überebenenbasismodule einer Sitzungsbeschreibung weit im voraus vor der eigentlichen Übertragung angekündigt werden, zu einem Zeitpunkt, zu dem die letzten Details des Inhalts noch unbekannt sind, wobei in diesem Fall die restlichen Ebenen von vorher angekündigten Links zu einem späteren Zeitpunkt zur Verfügung gestellt werden können.
5 zeigt schematisch ein System zum Verwalten von Medienstromverbindungen an einem Terminal eines Endteilnehmersystems gemäß der vorliegenden Erfindung.
Das Sitzungssteuersystem 500 ist mit einer Ankündigungsempfangsschnittstelle 510 und einer oder mehreren Multicast-geeigneten Multimedia-Applikationen 520 verbunden. Das Sitzungssteuersystem 500 und die Ankündigungsempfangsschnittstelle 510 sind mit einer Netzschnittstelle 530 verbunden, über die die Ankündigungen empfangen werden können und Multicast-Übertragungen initiiert und/oder empfangen werden können.
Ankündigungen, die bei der Netzschnittstelle 530 eingehen, werden zu der Empfangsschnittstelle 510 weitergeleitet. Die Empfangsschnittstelle 510 decodiert jede Ankündigung, um die Sitzungsbeschreibung zu bekommen, und zeigt die Anwender-orientierte Information von dem einen oder den mehreren Basismodulen dem Anwender in einer Liste an. Der Anwender kann eine Sitzungsbeschreibung aus einer Liste auswählen, in der eine Sitzung angekündigt wird, die empfangen werden soll. Die ausgewählte Beschreibung wird zu dem Sitzungssteuersystem 500 geleitet, das festlegt, welche der Multimedia-Applikationen 520 des Anwenders für die Teilnahme an der beschriebenen Sitzung notwendig sind, die Applikationen startet und die notwendigen Medienströme initiiert und erzeugt für die jeweiligen Applikationen 520 über einen Kommunikationsmanager 550.
Die Empfangsschnittstelle 510 kann mit anderen Internet-Kommunikations-Applikationen 540 verbunden sein, wie zum Beispiel einem WWW-Browser oder einem (nicht dargestellten) E-Mail-Client, die verwendet werden können, um weitere Information in Bezug auf die beschriebene Sitzung zu sammeln, auf der Basis von Links, die in der Sitzungsbeschreibung vorgesehen sind. Wo die Gruppe der Basis- und/oder Medienmodule einer Sitzungsbeschreibung unvollständig empfangen werden, versucht die Empfangsschnittstelle 510, die restlichen Module unter Verwendung der Internet-Kommunikations-Applikationen zu erlangen, bevor eine Weiterleitung zu dem Sitzungssteuersystem 500 erfolgt.
6 zeigt ein Flussdiagramm mit den Schritten, die von dem Sitzungssteuersystem 500 bei Empfang einer Sitzungsbeschreibung abgearbeitet werden. Die Beschreibung wird zunächst in Schritt 600 analysiert, um Client-Applikationen für jedes Medienmodul zu identifizieren. Sobald dies erfolgt ist, wird eine zweite Analyse durchgeführt, bei der Applikationen in Schritt 610 gestartet werden, das heißt, für jedes Medienmodul wird die Applikation gestartet, die in dem Client-Feld spezifiziert ist, falls die Applikation nicht bereits gestartet worden ist. Der Abschnitt der Sitzungsbeschreibung mit Bezug auf den jeweiligen Medientyp, d.h. das Medienmodul, das Basismodul direkt über dem Medienmodul, alle anderen Module, die mit dem Basismodul zusammenhängen und alle andere Optionsmodule, auf die das zutrifft, werden an die entsprechende Applikation in Schritt 620 weitergeleitet. Da die Medienmodule mit entsprechenden Client-Applikationen markiert werden, ist jede Applikation in der Lage, solche Medienströme auszuwählen, bei denen eine Teilnahme vorgesehen ist. Die Applikation antwortet auf das Sitzungssteuersystem mit einer Verbindungsanfrage, in der die Anforderungen in Form einer Liste von Identifizierungen von Medienmodulen spezifiziert ist, von denen Datenströme in Schritt 630 initiiert werden sollen. Die Verbindungsanfrage wird durch das Sitzungssteuersystem in Schritt 640 zusammengesetzt, und das System analysiert dann die Sitzungsbeschreibung, um andere Applikationen zu identifizieren, die in Schritt 645 gestartet werden. Wenn ein weiterer Medientyp gefunden wird, werden die Schritte 610 bis 640 wiederholt, ansonsten verwendet das Sitzungssteuersystem die zusammengesetzten Verbindungsanfragen, um eine Liste von Medienmodulen aufzustellen. Diese Liste wird zusammen mit einer Sitzungs-QoS-Richtlinie an den Kommunikationsmanager weitergeleitet, ein System, das in und durch das Sitzungssteuersystem verwendet wird, wodurch entsprechend den QoS-Richtlinien und den zur Verfügung stehenden Systemressourcen festgelegt wird, ob jede Verbindungsanfrage möglich ist.
Die Sitzungs-QoS-Richtlinie wird in zwei Schritten aufgebaut: Als erstes werden die mehrfachen Sitzungs-QoS-Richtlinien, die relevant sind für alle Medienmodule, die initiiert werden sollen, in einer Sitzungs-QoS-Richtlinie zusammengefasst: Als zweites kann die resultierende Sitzungs-QoS-Richtlinie angepasst werden, um (a) standardmäßige Anwender (definiert in einem Anwenderprofil), (b) einen Wunsch des Anwenders, die Richtlinie interaktiv zu bestimmten, und (c) eine Standardkonfiguration der Applikation (definiert in dem/den Applikationenprofil(en)) zu berücksichtigen.
Der Kommunikationsmanager reagiert auf das Sitzungssteuersystem in Schritt 650 durch Anzeige der möglichen Medienstromverbindungsanfragen. Falls notwendig, kann das Sitzungssteuersystem ein Ladesystem kontaktieren, um die Berücksichtigung der Sitzung vor Anfragen an den Kommunikationsmanager, die möglichen Medienstromverbindungen in Schritt 660 einzurichten, zu initiieren.
Sobald eine Sitzung beginnt, werden alle empfangenen Datenströme mit Bezug auf die Sitzung an die dazugehörige Multimedia-Applikation in Schritt 670 weitergeleitet, bis die vorgesehene Datenstromdauer in Schritt 680 endet oder die Multimedia-Applikation das Sitzungssteuersystem auffordert, die Verbindung in Schritt 690 zu beenden, woraufhin das Sitzungssteuersystem in Schritt 700 unterbricht.
7 ist ein Flussdiagramm, in dem der QoS-Managementschritt 650 in 6 mit weiteren Einzelheiten dargestellt ist.
Nachdem die zusammengesetzte Liste der Verbindungsanfragen empfangen wurde, stimmt der Kommunikationsmanager jeden Eintrag in dieser Liste mit einem Medienprofil in Schritt 705 ab. Ein Medienpro fil definiert die Anforderungen, die erfüllt werden müssen, damit der angeforderte Medienstrom zum Computer des Endteilnehmers kommt, einschließlich der minimalen Netzbandbreite, die für einen zufriedenstellenden Empfang des Datenstroms benötigt wird.
Ein Terminal-Profil ist in Schritt 710 festgelegt. Das Terminal-Profil definiert die Ressourcen, die auf Seiten des Computers des Endteilnehmers zur Verfügung stehen, um für die angeforderten Medienströme eingesetzt zu werden. Dies beinhaltet die zur Verfügung stehende Netzbandbreite, den freien Speicher und den Plattenspeicher sowie zur Verfügung stehende Hardware, wie zum Beispiel Monitorgröße, Prozessorgeschwindigkeit und freie Audio- und Videoaufnahmegeräte. Das Medienprofil für jede Verbindungsanfrage wird mit den zur Verfügung stehenden Systemressourcen verglichen, die durch das Terminal-Profil in Schritt 720 definiert werden. Wenn das Terminal-Profil das Medienprofil erfüllt oder überschreitet, wird in Schritt 730 die Verbindungsanfrage als machbar bezeichnet, und das Terminal-Profil wird dementsprechend für die restlichen Verbindungsanfragen in Schritt 740 herabgestuft. Jede Verbindungsanfrage wird verarbeitet, bis es keine weiteren Anfragen gibt oder bis das Terminal-Profil durch das Medienprofil einer Anfrage überschritten wird. In dieser Situation bestimmt der Kommunikationsmanager das optimale Terminal-Profil des Computers des Anwenders, das dieser hätte, wenn alle nicht-wesentlichen Applikationen in Schritt 750 nicht laufen würden, und ob der Computer in der Lage ist, das Medienprofil in Schritt 760 zu erfüllen. Wenn der Computer in der Lage ist, das Medienprofil zu erfüllen, versucht der Kommunikationsmanager Systemressourcen von gegenwärtig zugewiesenen Datenströmen oder Verbindungsanfragen zu befreien, die eine niedrigere Priorität haben, oder durch Nachfragen bei dem Anwender andere, nicht wesentliche Applikationen zu beenden, die in Schritt 770 auf dem Computer laufen. Alternativ kann dies durch Reduzieren der Anzahl der Schichten erfolgen, die von einem geschichteten Übertragungsstrom empfangen werden. Wenn nicht genügend Ressourcen aufzufinden sind, wird ein Ausnahmezustand dem Anwender angezeigt und die Verbindungsanfrage wird als nicht durchführbar markiert. Wenn der Medienstrom, der nicht empfangen werden kann, in einer QoS-Richtlinie für Media-Sitzungen oder Teilsitzungen als zwingend vorgeschrieben definiert ist, werden alle Verbindungsanfrage für diese Media-Sitzung oder Teilsitzung in Schritt 790 abgesagt. Wenn jedoch der Medienstrom optional ist, fährt der Kommunikationsmanager damit fort, die weiteren Verbindungsanfragen in Schritt 720 zu verarbeiten. Sobald alle anhängigen Verbindungsanfragen verarbeitet worden sind, meldet der Kommunikationsmanager diejenigen, die nötig sind, an das Sitzungssteuersystem.
Die Verarbeitung einer Sitzungsbeschreibung wird im Folgenden mit Bezug auf 4 und Beispiel 4 einer Sitzungsbeschreibung beschrieben, die die Sitzungsbeschreibung ist, die für die Spur 1 erzeugt worden ist (Module 410 und 420–424 in 4).
(# overall conference session
type = (base)
id = (410)
info = (title = "Multimedia98 Conference")
source = (owner = "JoeBloggs" email = joe@nowhere.com)
media = (video = (client = RealPlayerG2) whiteboard = (client = wb))
time (start = "09:00 GMT 25/12/98" stop = "13:00 GMT 25/12/98")
options = (oc = 0010)
modules = (b = 420 b = 430 b = 440 oc = 411)
)
(# conference track 1
type = (base)
id = (420 410)
info = (title = "MM98 Systems and Applications Track")
source = (owner = "JoeBloggs" email = joe@nowhere.com)
media = (video = (client = RealPlayerG2) whiteboard = (client = wb))
time (start = "09:00 GMT 25/12/98" stop = "11:00 GMT 25/12/98")
options = (osq = 424)
modules = (m = 421 m = 422 m = 423 osq = 424)
)
(# video for track 1
type = (media)
id = (421 420)
info = (title = "MM98 Systems and Applications Track Video")
source = (owner = "Joe Bloggs" email = joenowhere.com)
media = (video = (type = live client = RealPlayerG2))
connection = (226.0.0.100/1000)
time = (start = "09:00 GMT 25/12/98" stop = "11:00 GMT 25/12/98")
)
(# audio for track 1
type = (media)
id = (422 420)
info = (title = "MM98 Systems and Applications Track Audio")
source = (owner = "JoeBloggs" email = joe@nowhere.com)
media = (audio = (type = live format = g711))
connection = (226.0.0.101/1001)
time = (start = "09:00 GMT 25/12/98" stop = "11:00 GMT 25/12/98")
)
(# whiteboard for track 1
type = (media)
id = (423 420)
info = (title = "MM98 Systems and Applications Track Whiteboard")
source = (owner = "JoeBloggs" email = joe@nowhere.com)
media = (whiteboard = (client = wb))
connection = (226.0.0.102/1002)
time = (start = "09:00 GMT 25 12/98" stop = "11:00 GMT 25/12/98")
)
(# session QoS for track 1
type = (option-sQoS)
id = (424 420)
mandatory = (421 422)
optional = (423)
)
Sitzungsbeschreibung, Beispiel 4
Das Sitzungssteuersystem, das die obige Sitzungsbeschreibung empfangen hat, arbeitet entlang der Baumstruktur der Sitzungsbeschreibung, beginnend bei dem Basismodul 410. Das erste Modul, auf das es trifft, ist das Basismodul 420. Da dies kein Medienmodul ist, sondern Teilmodule aufweist, fährt das Sitzungssteuersystem fort, indem es diesen Zweig weiter nach unten zum Medienmodul verfolgt.
Das Medienfeld des Medienmoduls 421 definiert bereits die Multimedia-Client-Applikation, die erforderlich ist, als "RealPlayerG2" (eine Multimedia-Applikation von Real Networks Inc.), so dass das Sitzungssteuersystem dies ignoriert und mit dem nächsten Medienmodul fortfährt. Das Medienfeld des Medienmoduls 422 hat keine Multimedia-Client-Applikation definiert, jedoch ein Format ist für die Audiodaten spezifiziert. Das Sitzungssteuersystem erkennt, dass dieses bestimmte Audioformat unterstützt wird durch RealPlayerG2, so dass das Medienfeld abgeändert wird, damit darin als Client steht: Real PlayerG2. Das nächste Medienmodul 423 hat bereits eine Client-Applikation als wb definiert, und damit wird dies durch dieses Modul ignoriert, und auch das Optionsmodul 424 wird ignoriert.
Das Sitzungssteuersystem analysiert die Baumstruktur wieder, um Client-Applikationen zu starten. Das erste Medienmodul 421 spezifiziert, dass RealPlayerG2 gestartet werden sollte, daher startet das Sitzungssteuersystem die Applikation auf Seiten des Anwendersystems und führt Buch über diese Aktivität. Das zweite Medienmodul 522 spezifiziert eine Applikation, die bereits gestartet wurde, und somit ignoriert das Sitzungssteuersystem dies und fährt fort mit dem nächsten Medienmodul. Das Medienmodul 423 spezifiziert, dass wb gestartet werden sollte, so dass das Sitzungssteuersystem die Applikation startet und über diese Aktivitäten Buch führt.
Der RealPlayerG2 wird zum Medienmodul 421, Basismodul 420 und den Modulen 422–424 weitergeleitet. Die Applikation verarbeitet die Medienmodule, die dazu dienen festzulegen, was behandelt werden kann, und in diesem Fall ist 421 und 422 definiert. Mit der Festlegung, welche Datenströme verarbeitet werden können, sendet die Applikation eine Verbindungsanfrage zu dem Sitzungssteuersystem zurück, in der eine Verbindung mit den Medienströmen der Module 421 und 422 angefordert wird. Ähnlich wird wb an das Medienmodul 423, Basismodul 420, die Module 421–422 und das Modul 424 weitergeleitet. Die Applikation verarbeitet die gegebenen Module wie oben beschrieben und fordert eine Verbindung zu dem Medienstrom der Module 423 an.
Die obigen Verbindungsanfragen werden durch das Sitzungssteuersystem in einer Liste zusammengesetzt, wobei diese Liste dann zusammen mit dem Sitzungs-QoS-Richtlinienmodul 424 an den Kom munikationsmanager geleitet wird. Der Kommunikationsmanager legt fest, ob jede Anfrage gemäß den Schritten in 7 möglich ist.
Wenn man annimmt, dass es für zwingend vorgeschriebene Medienströme genügend Ressourcen für alle Verbindungsanfragen gibt, schickt der Kommunikationsmanager eine Liste von möglichen Datenströmen an das Sitzungssteuersystem zurück, das dann den Baum wieder abarbeitet, um die Verbindungsdaten festzulegen, die in dem Verbindungsfeld von jedem Medienmodul enthalten sind, so dass es den Kommunikationsmanager auffordern kann, eine Verbindung zu dem entsprechenden Medienstrom für jede der möglichen Verbindungsanfragen gemäß den Verbindungsdaten zu initiieren. Das Sitzungssteuersystem verwaltet dann die Sitzung und deren Medienstromverbindungen, wie dies beschrieben wurde mit Bezug auf die Schritte 670 bis 700 in 6.
Auf Grund der Heterogenität des Internet und der unterschiedlichen Möglichkeiten und Betriebsumgebungen der Computersysteme der Endteilnehmer wurde das Sitzungssteuersystem, das beschrieben wurde, in Java (Java ist Handelsname von Sun Microsystems Inc.) implementiert. Die Ankündigungsempfangsschnittstelle, das Sitzungsverzeichnis, empfängt die Ankündigungen und leitet diejenigen, die von dem Endteilnehmer ausgewählt wurden, an den Sitzungssteuerungsmanager weiter, der als eine Anwendungsprogrammierungsschnittstelle implementiert ist, die als Hintergrundprozess auf dem Computer des Endteilnehmers läuft.
Obgleich die vorliegende Erfindung mit Bezug auf das Internet und Multicast-Übertragungen beschrieben wurde, ist dem Leser sicher klar, dass die beschriebene modulare Sitzungsbeschreibung und das Sitzungssteuersystem anwendbar sind auf die Ankündigung und die nachfolgende Verwaltung von Verbindungen mit Medienströmen ei ner (Multi-)Media-Sitzung, bei der andere bekannte Transportmechanismen, wie zum Beispiel Unicast, eingesetzt werden.
Darüber hinaus ist es, obgleich Mechanismen für die Verschlüsselung, das Laden und andere derartige Dienste nicht explizit beschrieben wurden, für den Leser offensichtlich, dass geeignete Sitzungsbeschreibungen und dazugehörige Funktionen innerhalb des Sitzungssteuersystems für die Verarbeitung mit den entsprechenden erforderlichen Mechanismen ohne weiteres implementiert werden können.

Claims

Verfahren zum Ankündigen der Beschreibung (300) einer Mediensitzung über ein Kommunikationsnetz, wobei bei dem Verfahren ein modulares Beschreibungssystem eingesetzt wird, das dazu ausgelegt ist, eine verteilte Ankündigung mit Links, die einem Anwender zur Verfügung stehen, zu anderen Teilen der Ankündigung zu erzeugen, die noch nicht übertragen wurden, wobei das Verfahren die Schritte umfasst: Erzeugen eines ersten Basismoduls (310, 410) mit einer ersten Datenstruktur mit Anwender-orientierten Daten, die bezüglich der Mediensitzung relevant sind, Erzeugen wenigstens eines Medienmoduls (320, 421, 422, 423) mit einer zweiten Datenstruktur mit Medien-orientierten Daten, die für einen Anwender notwendig sind, um einen entsprechenden Medienstrom von der Mediensitzung zu empfangen, Bereitstellen eines Links zwischen dem ersten Basismodul (310, 410) und dem wenigstens einen Medienmodul (320, 421, 422, 423) und Ankündigen der Mediensitzung, indem wenigstens das erste Basismodul (310) potentiellen Empfängern der Mediensitzung zur Verfügung gestellt wird, wobei es der Link zwischen dem ersten Basismodul (310, 410) und dem wenigstens einen Medienmodul (320, 421, 422, 423) einem Anwender möglich macht, auf das wenigstens eine Medienmodul (320, 421, 422, 423) zuzugreifen und danach den Medienstrom zu empfangen.
Verfahren nach Anspruch 1, das außerdem den Schritt umfasst: Erzeugen eines zweiten Basismoduls (420), wobei das zweite Basismodul (420) Anwender-orientierte Daten mit Bezug auf eine Teilsitzung der Mediensitzung enthält, Verbinden des zweiten Basismoduls (420) mit dem ersten Basismodul (410) und Verbinden des wenigstens einen Medienmoduls (421) mit dem zweiten Basismodul (420).
Verfahren nach Anspruch 1 oder 2, das außerdem den Schritt umfasst: Erzeugen wenigstens eines Optionsmoduls (411) mit einer dritten Datenstruktur mit Daten mit Bezug auf Dienstebenenkriterien, die erforderlich sind, um an der Mediensitzung teilzunehmen, und Verbinden des oder jedes Optionsmoduls (411) mit einem jeweiligen Basismodul (420).
Verfahren nach Anspruch 3, bei dem sich die Daten in dem Optionsmodul (411) auf eine Qualität der Dienstvereinbarung bezieht, die anzuwenden ist für die Mediensitzung oder einen Teil davon.
Verfahren nach Anspruch 3 oder 4, bei dem sich die Daten in dem Optionsmodul (411) auf ein Sicherheitssystem beziehen, das anzuwenden ist für die Mediensitzung oder einen Teil davon.
Verfahren nach einem der Ansprüche 3 bis 5, bei dem sich die Daten in dem Optionsmodul (411) auf ein Ladesystem beziehen, das anzuwenden ist für die Mediensitzung oder einen Teil davon.
Verfahren nach einem der vorangehenden Ansprüche, bei dem ein oder mehrere Medienmodule (421, 422, 423) Daten umfas sen, die notwendig sind für einen Anwender, um einen geschichteten Medienstrom einer jeweiligen Mediensitzung zu empfangen, und das Verfahren außerdem den Schritt Verbinden des oder jedes Medienmoduls (421, 422, 423) mit einem oder mehreren jeweiligen Optionsmodulen (444) mit Daten mit Bezug auf einen geschichteten Mechanismus des jeweiligen geschichteten Medienstroms, die für eine Partei notwendig sind, um an dem geschichteten Medienstrom teilzunehmen, umfasst.
Verfahren nach einem der vorangehenden Ansprüche, bei dem die Daten in einem Medienmodul (320, 421, 422, 423) Daten enthalten, die für einen Anwender notwendig sind, um Daten für die Einbindung in der Mediensitzung zu empfangen, zu senden oder sowohl zu empfangen als auch zu senden.
Verfahren nach einem der vorangehenden Ansprüche, bei dem die Mediensitzung angekündigt wird durch Senden aller konstituierenden Module der Sitzungsbeschreibung.
Verfahren nach einem der Ansprüche 1 bis 8, bei dem die Mediensitzung angekündigt wird durch Senden nur einiger der konstituierenden Module der Sitzungsbeschreibung, wobei die restlichen Module der Sitzungsbeschreibung einem Nutzer nacheinander zugänglich gemacht werden, wobei einer oder mehrere Links verwendet werden, die in den gesendeten Modulen vorgesehen sind.
Verfahren nach Anspruch 10, bei dem die restlichen Module der Sitzungsbeschreibung in einem oder mehreren Servern gespeichert sind und der eine oder mehrere Links zu den restlichen Modulen in Form von URI-Zeigern vorliegen.
Verfahren nach einem der vorangehenden Ansprüche, bei dem die Module der Sitzungsbeschreibung Links zu Modulen enthalten, die nach der Ankündigung erzeugt werden.
Verfahren nach einem der vorangehenden Ansprüche, bei dem das erste Basismodul (310, 410) ein eindeutiges Identifizierungsfeld aufweist, das bei der Erzeugung des Links zwischen dem ersten Basismodul (310, 410) und dem wenigstens einem Medienmodul (320, 421, 422, 423) verwendet wird.
Verfahren nach Anspruch 13, bei dem der Link zwischen dem ersten Basismodul (310, 410) erzeugt wird durch Auflisten des Typs und der eindeutigen Identifizierung des wenigstens einen Medienmoduls (320, 421, 422, 423) mit Verbindung zu dem ersten Basismodul (310, 410).
Verfahren nach Anspruch 14, bei dem ein Link in zwei Richtungen zwischen wenigstens einem Medienmodul (320, 421, 422, 423) und dem ersten Basismodul (310, 410) erzeugt wird durch Erzeugen eines Links zwischen dem wenigstens einen Medienmodul (320, 421, 422, 423) zurück zu dem ersten Basismodul (310, 410), wobei der Link zurück zu dem ersten Basismodul (310, 410) erzeugt wird durch Auflisten in dem Identifizierungsfeld des Medienmoduls (320, 421, 422, 423), wobei die eindeutige Identifizierung zu dem ersten Basismodul (310, 410) mit Verbindung zu dem Medienmodul (320, 421, 422, 423) gehört.
Verfahren nach einem der vorangehenden Ansprüche, bei dem jeder Kommunikationskanal und Medienstrom, die notwendig sind zum Teilnehmen an der Mediensitzung, identifiziert wird in der Sitzungsbeschreibung, um die jeweiligen Ströme und Kanäle für Multimedia-Applikationen während der Ausführungszeit durch generische Middleware instantiieren zu können.
Ein von einem Computer lesbares Speichermedium, auf dem Befehle gespeichert sind, durch die wenigstens ein Teil einer modularen Beschreibung (300) einer Mediensitzung in einem modularen Beschreibungssystem für ein Kommunikationsnetz definiert wird, bei dem eine verteilte Ankündigung Links enthält, die einem Anwender zur Verfügung stehen, zu anderen Teilen der Ankündigung, die noch nicht übertragen wurden, wodurch bei Ausführung durch einen Computer dieser dazu gebracht wird, das Verfahren zum Erzeugen durchzuführen: Erzeugen eines ersten Basismoduls (310, 410) mit einer ersten Datenstruktur mit Anwender-orientierten Daten, die für die Mediensitzung relevant sind, Erzeugen wenigstens eines Medienmoduls (320, 421, 422, 423) mit einer zweiten Datenstruktur mit Medien-orientierten Daten, die notwendig sind für einen Anwender, um einen jeweiligen Medienstrom von der Mediensitzung zu empfangen, Bereitstellen eines Links zwischen dem ersten Basismodul und dem wenigstens einen Medienmodul, Ankündigen der Mediensitzung dadurch, dass wenigstens das erste Basismoduls (310) für mögliche Empfänger der Mediensitzung zur Verfügung gestellt wird, wobei es der Link zwischen dem ersten Basismodul und dem wenigstens einen Medienmodul einem Anwender möglich macht, auf das wenigstens eine Medienmodul zuzugreifen und danach den Medienstrom zu empfangen.
Modulares Beschreibungssystem für eine Mediensitzung in einem Kommunikationsnetz, bei dem eine Beschreibung der Mediensitzung angekündigt wird unter Verwendung einer verteilten Ankündigung, die Links enthält, die einem Anwender zur Verfügung stehen, zu anderen Teilen der Ankündigung, die noch nicht übertragen wurden, wobei das System umfasst: eine Einrichtung zum Erzeugen eines ersten Basismoduls (310, 410) mit einer ersten Datenstruktur mit Anwender-orientierten Daten, die bezüglich der Mediensitzung relevant sind, eine Einrichtung zum Erzeugen wenigstens eines Medienmoduls (320, 421, 422, 423) mit einer zweiten Datenstruktur mit Medienorientierten Daten, die für einen Anwender notwendig sind, um einen entsprechenden Medienstrom von der Mediensitzung zu empfangen, eine Einrichtung zum Bereitstellen eines Links zwischen dem ersten Basismodul (310, 410) und dem wenigstens einen Medienmodul (320, 421, 422, 423) und eine Einrichtung zum Ankündigen der Mediensitzung, indem wenigstens das erste Basismodul (310) potentiellen Empfängern der Mediensitzung zur Verfügung gestellt wird, wobei es der Link zwischen dem ersten Basismodul (310, 410) und dem wenigstens einen Medienmodul (320, 421, 422, 423) einem Anwender möglich macht, auf das wenigstens eine Medienmodul (320, 421, 422, 423) zuzugreifen und danach den Medienstrom zu empfangen.