DE69923856T2

DE69923856T2 - Verfahren und vorrichtung zur wirkungsgradverbesserung des verbindungsaufbaues im multimedia- kommunikationssystem

Info

Publication number: DE69923856T2
Application number: DE69923856T
Authority: DE
Inventors: Senthil Woburn SENGODAN
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 1998-10-13
Filing date: 1999-10-08
Publication date: 2005-12-29
Anticipated expiration: 2019-10-09
Also published as: EP1121793B1; EP1121793A2; US6490275B1; WO2000022843A3; AU6296999A; DE69923856D1; WO2000022843A2

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die Erfindung bezieht sich auf Multimedia-Kommunikation im Allgemeinen und auf ein Verfahren und System zur Verbesserung der Rufaufbau-Effizienz in Multimedia-Kommunikationssystemen im Besonderen.
2. Beschreibung des verwandten Stands der Technik
Im Gegensatz zu Kommunikationsmitteln wie E-Mail, Fax, Pagern und Mobiltelefonen, die heutzutage in den meisten Büros zu finden sind, ist die Videokonferenz noch nicht in die engere Wahl gerückt. Dies ändert sich jedoch, da Unternehmen dazu übergehen, sich niedrigere Systemkosten und neu aufkommende Standards zunutze zu machen. Die Videokonferenz über das IP-Netzwerk eines Unternehmens ist beispielweise sehr attraktiv. Sie nutzt den Unternehmens-Fundus besser aus, anstatt zusätzliche Investitionen in ISDN-Leitungen zu stecken. Bis jetzt war ISDN der einzige zuverlässige Weg, videofähige Arbeitsplätze und konferenzraumbasierte Systeme zu verbinden. Allerdings ist die Technologie nicht jederzeit zu haben und sie ist noch immer teuer.
Die veröffentlichte Patentanmeldung WO 97/1909 beschreibt ein Kommunikationssystem, das die Übertragung von Breitband-Multimediadaten über ein Netzwerk erlaubt.
Das Kommunikationssystem beinhaltet Netzwerk-Endgeräte, ein Übertragungsbasisnetz und einen Rufaufbau-Server. Der Rufaufbau-Server steuert die Ruf- und Verbindungsbearbeitung. Der Rufaufbau-Server enthält einen Zugangsteil, einen Benutzerteil und einen Zentralteil zur Rufbearbeitung. Der Zentralteil baut einen Ruf zwischen Parteien im System auf und arbeitet unabhängig vom Zugangsteil und vom Benutzerteil und ermöglicht dadurch das Hinzufügen eines neuen Zugangsteils, ohne den existierenden Zentralteil zu beeinflussen. Dennoch befasst sich die veröffentlichte Patentanmeldung WO 97/1909 nicht mit der Minimierung der Rufaufbauzeit oder mit einem Verfahren zur Verbesserung der Effizienz, ohne Raufaufbau-Funktionalität zu opfern.
Die europäische Patentanmeldung EP 0 781 015 beschreibt lediglich ein Telefonsystem, das Endgeräte in Computernetzwerken verwendet, die durch Server verbunden sind, um Daten durch das Computernetzwerk zu übertragen, die wenigstens Audiodaten enthalten. Die europäische Patentanmeldung EP 0 781 015 beschreibt jedoch nicht die Minimierung der Rufaufbauzeit oder ein Verfahren zur Verbesserung der Effizienz, ohne Raufaufbau-Funktionalität zu opfern.
Gemäß dem ITU-Dokument, herausgegeben am 28. Mai 1996, beschreibt die „Empfehlung H.323" Endgeräte, Gerätschaften und Dienste für eine Multimedia-Kommunikation über das lokale Netzwerk (LAN), die keine garantierte Dienstgüte (QoS) bieten. Die H.323 Standard-Architektur wurde zum Spezifizieren von Toren und Torwächtern entwickelt, die Verbindungen zwischen LAN-basierten DVC-Einheiten, durch ISDN verbundene H.320 Einheiten, durch analoges Telefon verbundene H.324-Geräte und ISDN-Telefone und POTS-Telefone ermöglichen. H.323-Systeme erfordern den Austausch mehrerer Nachrichten zwischen mehreren Funktionseinheits-Paaren. Ein sich stark entwickelnder Zweig dieses Marktes beinhaltet Systeme mit Toren und Gebührenerfassungs-Servern, die der internationalen Internet-Telephonie gewidmet sind.
Der H.323-Standard bildet das Fundament für Audio-, Video- und Daten-Kommunikation durch IP-basierte Netzwerke einschließlich des Internets. Durch Erfüllung von H.323 können Multimediaprodukte und Anwendungen von vielen Anbietern miteinander funktionieren und erlauben den Benutzern dadurch zu kommunizieren, ohne sich Sorgen um die Kompatibilität machen zu müssen. H.323 wird der Hauptgedanke für LAN-basierte Produkte für Endverbraucher, Betriebe, Unterhaltung und professionelle Anwendungen sein.
Genauer gesagt ist H.323 eine Übersichts-Empfehlung der Internationalen Telekommunikationsunion (ITU), die Standards für eine Multimedia-Kommunikation über lokale Netzwerke festlegt, die keine garantierte Dienstgüte (QoS) bieten. Diese Netzwerke beherrschen die heutigen Benutzeroberflächen in Unternehmen und umfassen die packetvermittelten Protokolle TCP/IP und IPX über Ethernet, schnelles Ethernet und Token-Ring-Netzwerk-Technologien. Daher sind die H.323-Standards wichtige Bausteine für ein breites neues Feld von gemeinschaftlichen LAN-basierten Anwendungen für die Multimedia-Kommunikation.
Die H.323-Spezifikation wurde 1996 von der Studiengruppe 16 der ITU anerkannt. Version 2 wurde im Januar 1998 anerkannt. Der Standard hat ein breites Spektrum und umfasst sowohl allein stehende Geräte und eingebettete Personal-Computer-Technologie als auch Punkt-zu-Punkt- und Mehrpunkt-Konferenzen. H.323 behandelt auch die Rufsteuerung, Multimedia- und Bandbreiten-Verwaltung sowie die Schnittstellen zwischen lokalen und anderen Netzwerken.
H.323 ist die modernste der Empfehlungen aus der H.32X-Serie, welche Standards für Video-Konferenzen über eine Vielzahl von Netzwerken spezifiziert. H.323 umfasst einen großen Teil der Arbeit, die seit der Anerkennung der H.320-Empfehlung im Jahr 1990 durchgeführt wurde, die eine Spezifikation für Multimedia über leitungsvermittelte digitale Telefonnetzwerke ist. Die H.32X besteht aus folgenden Empfehlungen:

• H.320 ermöglicht Videokonferenzen über schmalbandig geschaltetes ISDN.
• H.321 ist für Videokonferenzen über breitbandiges ISDN ATM LAN.
• H.322 ermöglicht Videokonferenzen über packetvermittelte Netzwerke mit garantierter Bandbreite.
• H.323 ermöglicht Videokonferenzen über packetvermittelte Netzwerke ohne garantierte Bandbreite.
• H.324 ist für Videokonferenzen über PSTN oder POTS (das analoge Telefonsystem).

Das H.323-Protokollprofil unterstützt viele Echtzeitanwendungen, welche die Industrie gerne über das Internet nutzt, wie: Videokonferenzen auf Benutzeroberflächen, Internettelephonie und Videotelephonie, gemeinschaftliche Datenverarbeitung, betriebliche Konferenzeinberufung, Fernlernen, unterstützende und Hilfsoberflächen-Anwendungen, usw. Diese Anwendungen existieren bereits auf dem Markt, aber die meisten behandeln das Problem nicht, wie diese Anwendungen über ein packetvermitteltes Netzwerk laufen sollen, wie das Internet und die meisten lokalen Betriebsnetzwerke, die auf der TCP/IP-Protokollfolge basieren. Unter dem Druck des Marktes, diese Art von Anwendungen über das Internet zu verwenden, zeichnet sich H.323 als eine mögliche Lösung für geschäftliche Anforderungen ab.
H.323 definiert vier Hauptkomponenten für ein netzwerkbasiertes Kommunikationssystem. 1 zeigt ein H.323-System 100. In 1 sind die vier Hauptkomponenten eines H.323-Systems 100 einschließlich ihrer Interaktion mit existierenden Netzwerken gezeigt. Diese Komponenten interagieren mit LANs, die keine QoS bieten. Die vier Komponenten beinhalten Endgeräte 110, Tore 120, Torwächter 130 und Mehrpunkt-Steuereinheiten (MSEs) 140.
Diese vier Elemente 110–140 sind lediglich für die Anwendungsschicht des Internetschichtenmodells spezifiziert. Es gibt keine Spezifikation über die darunterliegenden Schichten (Transport-, Netzwerk-, Datenverbindungs- und physikalische Schicht). Diese Eigenschaft macht H.323 flexibel und erlaubt H.323-Geräten, mit Geräten anderer Netzwerke zu kommunizieren.
H.323-Endgeräte 110 stellen die Client-Software dar, die auf den Computern der Endbenutzer läuft und den Benutzern erlaubt, in Echtzeit unter Verwendung der vollen Multimedia-Potenz zu kommunizieren. Diese Endgeräte werden auch als Endpunkte bezeichnet.
Ein Tor 120 ist eine Komponente der H.323-Spezifikation, die weltweite Verbindungsfähigkeit und Interoperabilität vom LAN aus zur Verfügung stellt. Das heißt, ein Tor 120 lässt an ein LAN angeschlossene Computer mit regulären an das PSTN 152 angeschlossenen Telefonen 150 und mit an ein ISDN-Netzwerk 156 angeschlossenen Digitaltelefonen 154 (H.320-Endgeräten) kommunizieren. Ein Tor 120 übersetzt auch zwischen verschiedenen Codectypen, die von verschiedenen Arten von Endgeräten verwendet werden, bildet die Rufsignalisierung zwischen Q.931 und H.225 ab und bildet auch die Steuersignalisierung zwischen H.242/H.243 und H.245 ab.
Im Allgemeinen ist ein Tor 120 eine Komponente, die die Verbindung eines packetvermittelten Netzwerks ohne Dienstgüte mit anderen Netzwerktypen ermöglicht. Ist keine Verbindung zwischen verschiedenen Netzwerktypen erforderlich, ist auch kein Tor 120 erforderlich, da dann Endgeräte miteinander kommunizieren können, wenn sie im selben LAN sind. Endgeräte kommunizieren mit Toren durch die Q.931- und H.245-Protokolle.
Ein Torwächter 130 ist eine H.323-Komponente, die vier Grundfunktionen aufweist:

• Adressübersetzung: derjenige Mechanismus, der das Vorhandensein verschiedener Arten von Systemadressierung ermöglicht. Reguläre Telefonnummern (E.164 Adressen) zum Beispiel können in Verbindung mit E-Mailadressen verwendet werden. Der Torwächter 130 erlaubt die Kommunikation mit Endgeräten, die auf verschiedene Weise adressiert werden.
• Zugangssteuerung: der Torwächter 130 könnte den Ruf eines Benutzers zurückweisen. Ein Benutzer muss beim Torwächter 130 registriert sein, um einen Ruf vollenden zu können.
• Bandbreitensteuerung: Netzwerkverwalter können den Umfang an für Videokonferenzen verwendeter Bandbreite begrenzen, was einen Weg zur Steuerung des LAN-Verkehrs bietet.
• Bereichsverwaltung: Die Torwächter 130 stellen die Funktionen Adressübersetzung, Zugangssteuerung und Bandbreitensteuerung für Endgeräte 110, MSEs 140 and Tore 120 bereit, die am Torwächter 130 in seinem Steuerbereich registriert sind. Dieser Bereich wird als H.323-Bereich bezeichnet.

Die Funktionen des Torwächters 130 sind bei den meisten Anbietern im Tor 120 enthalten, wenn sie auch logisch getrennt sind und unterschiedliche Arten von Funktionalitäten aufweisen.
Die Mehrpunkt-Steuereinheit (MSE) 140 ist ein logisches Gerät, das Konferenzen zwischen drei oder mehr Endpunkten unterstützt. Die MSE 140 ist typischerweise in die Implementierung des Tors integriert und daher bei den meisten Implementierungen kein separater Computer, der Konferenzfunktionen ausführt. Ebenso werden bei einer kombinierten Implementierung der Funktionen der MSE 140 mit den Funktionen des Tors 120 Konferenzen unter Teilnehmern verschiedener Netzwerke (LAN und PSTN) eine bessere Leistung haben als bei getrennten Implementierungen.
Der Rufaufbau in H.323-Systemen erfordert den Austausch mehrerer Nachrichten zwischen mehreren Funktionseinheits-Paaren. Die Abfolge des Nachrichtenaustauschs ist in H.323 spezifiziert und hängt vom Vorhandensein oder Fehlen von Torwächtern beim rufenden und/oder beim gerufenen Endpunkt und der Wahl von direkt/Torwächter-geleiteten Modellen ab. Nichtsdestoweniger könnte die Rufaufbauzeit reduziert und die Effizienz verbessert werden, wenn die Anzahl der Nachrichtenaustauschvorgänge reduziert werden könnte, ohne Rufaufbau-Funktionalität zu opfern.
Es ist ebenso zu erkennen, dass Bedarf an einem Verfahren und einer Vorrichtung zur Verbesserung der Rufaufbau-Effizienz in H.323-Systemen besteht.
Kurzzusammenfassung der Erfindung:
Um die Einschränkungen im vorstehend beschriebenen Stand der Technik und weitere Einschränkungen zu überwinden, die beim Lesen und Verstehen der vorliegenden Beschreibung ersichtlich werden, offenbart die Erfindung ein Verfahren und eine Vorrichtung zur Verbesserung der Rufaufbau-Effizienz in Multimedia-Kommunikationssystemen.
Die Erfindung löst die vorstehend beschriebenen Probleme, indem sie den Rufaufbau in H.323-Systemen unter Verwendung von weniger Nachrichtenaustauschvorgängen durchführt und dadurch zu einem effizienteren Rufaufbauverfahren führt. Außerdem wird durch den Übergang zu weniger Nachrichtenaustauschvorgängen keine Rufaufbau-Funktionalität geopfert.
Ein erfindungsgemäßes Verfahren beinhaltet das Platzieren eines Rufs an einem ersten Endpunkt an einen entfernten Endpunkt, die Zugangsanforderung von einem Torwächter für den Ruf, die Rückgabe einer Akzeptanznachricht an den ersten Endpunkt, wobei die Akzeptanznachricht ein Token enthält, das Informationen für den entfernten Endpunkt bereitstellt und dadurch der Notwendigkeit des entfernten Endpunkts, Zugang von einem Torwächter anzufordern, Abhilfe verschafft, das Leiten einer Aufbaunachricht an den entfernten Endpunkt, wobei diese Aufbaunachricht das Token enthält und den Rufaufbau auf der Grundlage der Informationen im Token vollendet und das Token Ressourcenzuweisungen für den Ruf mitführt.
Weitere Ausführungsbeispiele eines erfindungsgemäßen Systems können alternative oder optionale zusätzliche Aspekte enthalten. Ein solcher Aspekt der Erfindung ist eine Registrierung des ersten Endpunkts und des entfernten Endpunkts an einem gemeinsamen Torwächter.
Ein anderer Aspekt der Erfindung ist die Implementierung der direkten Rufsignalisierung durch den ersten Endpunkt und den entfernten Endpunkt, wobei das Leiten der Aufbaunachricht durch direkte Übertragung der Aufbaunachricht einschließlich des Tokens an den entfernten Endpunkt durchgeführt wird.
Ein anderer Aspekt der Erfindung ist die Implementierung der vom Torwächter geleiteten Rufsignalisierung, wobei das Leiten der Aufbaunachricht durch Leiten der Aufbaunachricht einschließlich des Tokens vom ersten Endpunkt zum gemeinsamen Torwächter und Leiten der Aufbaunachricht einschließlich des Tokens vom gemeinsamen Torwächter an den entfernten Endpunkt durchgeführt wird.
Ein anderer Aspekt der Erfindung ist die Registrierung des ersten Endpunkts an einem ersten Torwächter und die Registrierung des entfernten Endpunkts an einem zweiten Torwächter.
Ein anderer Aspekt der Erfindung ist, dass die Zugangsanforderung eines Torwächters für den Ruf ferner die Zugangsanforderung des ersten Endpunkts vom ersten Torwächter enthält und der erste Torwächter die Zugangsanforderung analysiert, um zu bestimmen, ob ein Kriterium für den Ruf nach den für den ersten Torwächter lokalen Anforderungen akzeptabel ist. Die Zugangsanforderung wird an den zweiten Torwächter geleitet, wenn der erste Torwächter bestimmt, dass das Kriterium für den Ruf akzeptabel ist, wobei der zweite Torwächter die Zugangsanforderung analysiert, um zu bestimmen, ob ein Kriterium für den Ruf nach den für den zweiten Torwächter lokalen Anforderungen akzeptabel ist und eine Zugangsbestätigung einschließlich des Tokens an den ersten Torwächter schickt, wenn ein benötigtes Kriterium für den Ruf nach den für den zweiten Torwächter lokalen Anforderungen als akzeptabel bestimmt wird.
Ein anderer Aspekt der Erfindung ist die Implementierung direkter Rufsignalisierung durch den ersten und zweiten Torwächter, wobei das Leiten der Aufbaunachricht durch direkte Übertragung der Aufbaunachricht einschließlich des Tokens an den entfernten Endpunkt durchgeführt wird.
Ein anderer Aspekt der Erfindung ist die Implementierung direkter Rufsignalisierung durch den ersten Torwächter und die Implementierung geleiteter Rufsignalisierung durch den zweiten Torwächter, wobei das Leiten der Aufbaunachricht durch Übertragung der Aufbaunachricht einschließlich des Tokens an den zweiten Torwächter durchgeführt wird und der zweite Torwächter die Aufbaunachricht einschließlich des Tokens an den entfernten Endpunkt überträgt.
Ein weiterer Aspekt der Erfindung ist, dass die Vollendung des Rufaufbaus ferner das Leiten der Aufbaunachricht durch Übertragung der Verbindungs-/Einrichtungsnachrichten vom entfernten Endpunkt an den zweiten Torwächter und durch Übertragung der Verbindungs-/Einrichtungsnachrichten an die Aufbaunachricht des ersten Endpunkt vom zweiten Torwächter enthält.
Ein anderer Aspekt der Erfindung ist die Implementierung geleiteter Rufsignalisierung durch den ersten Torwächter und die Implementierung direkter Rufsignalisierung durch den zweiten Torwächter, wobei das Leiten der Aufbaunachricht durch Übertragung der Aufbaunachricht einschließlich des Tokens an den ersten Torwächter und durch Übertragung der Aufbaunachricht einschließlich des Tokens vom ersten Torwächter an den entfernten Endpunkt durchgeführt wird.
Ein anderer Aspekt der Erfindung ist, dass die Vollendung des Rufaufbaus ferner das Leiten der Aufbaunachricht durch Übertragung der Verbindungs-/Einrichtungsnachrichten vom entfernten Endpunkt an den ersten Torwächter und durch Übertragung der Verbindungs-/Einrichtungsnachrichten vom ersten Torwächter an den ersten Endpunkt umfasst.
Ein anderer Aspekt der Erfindung ist die Implementierung geleiteter Rufsignalisierung durch den ersten und zweiten Torwächter, wobei das Leiten der Aufbaunachricht durch Übertragung der Aufbaunachricht einschließlich des Tokens an den ersten Torwächter, durch Übertragung der Aufbaunachricht einschließlich des Tokens vom ersten Torwächter an den zweiten Torwächter und durch Übertragung der Aufbaunachricht einschließlich des Tokens vom zweiten Torwächter an den entfernten Endpunkt durchgeführt wird.
Ein weiterer Aspekt der Erfindung ist, dass die Vollendung des Rufaufbaus ferner das Leiten der Aufbaunachricht durch Übertragung der Verbindungs-/Einrichtungsnachrichten vom entfernten Endpunkt zum zweiten Torwächter, durch Übertragung der Verbindungs-/Einrichtungsnachrichten vom zweiten Torwächter an den ersten Torwächter und durch Übertragung der Verbindungs-/Einrichtungsnachrichten vom ersten Torwächter an die Aufbaunachricht des ersten Endpunkts umfasst.
Ein anderer Aspekt der Erfindung ist, dass das Leiten der Zugangsanforderung an den zweiten Torwächter ferner das Leiten der Zugangsanforderung durch eine Torwächterwolke umfasst.
Ein anderer Aspekt der Erfindung ist, dass das Token eine Transportadresse des zweiten Torwächters umfasst.
Ein alternatives Ausführungsbeispiel der Erfindung beinhaltet das Senden einer Aufbaunachricht von einem ersten Endpunkt zu einem entfernten Endpunkt, das Anfordern eines Zugangs für den Ruf von einem Torwächter, wobei die Zugangsanforderung alle Informationen enthält, die zur Abwicklung des Rufaufbaus nötig sind, das Zurückgeben einer Akzeptanznachricht an den entfernten Endpunkt, wobei die Akzeptanznachricht dem entfernten Endpunkt anzeigt, dass der Torwächter eine geleitete Rufsignalisierung implementiert und eine Transportdresse für den Torwächter miteingeschlossen ist, und das Leiten einer Einrichtungsnachricht an den ersten Endpunkt, die den ersten Endpunkt über die Transportadresse für den Torwächter und darüber informiert, dass der Rufsignalisierungskanal durch den Torwächter läuft.
Ein anderer Aspekt der Erfindung ist, dass der erste Endpunkt nicht registriert ist und der entfernte Endpunkt am Torwächter registriert ist.
Ein weiteres Ausführungsbeispiel der Erfindung ist ein Multimedia-Kommunikationssystem, das einen ersten Endpunkt zum Platzieren eines Rufs an einen entfernten Endpunkt umfasst und einen Torwächter, der operativ an den ersten Endpunkt gekoppelt ist, wobei der Torwächter derart konfiguriert ist, dass er eine Adressübersetzung, Zugangssteuerung und Bandbreitensteuerung durchführt, wobei der erste Endpunkt derart konfiguriert ist, dass er für den Ruf Zugang vom Torwächter fordert, wobei der Torwächter konfiguriert ist, eine Akzeptanznachricht an den ersten Endpunkt zurückzugeben, die ein Token enthält, das Informationen für den entfernten Endpunkt beinhaltet, was das Erfordernis des entfernten Endpunkts erleichtert, von einem Torwächter Zugang zu fordern, wobei der erste Endpunkt konfiguriert ist, eine Aufbaunachricht zum entfernten Endpunkt zu leiten, wobei die Aufbaunachricht das Token enthält und der entfernte Endpunkt konfiguriert ist, den Rufaufbau auf der Grundlage der Informationen im Token zu vollenden, wobei das Token Ressourcenzuweisungen für den Ruf beinhaltet.
Diese und verschiedene weitere Vorteile und Merkmale der Erfindung sind ausführlich in den angefügten Ansprüchen aufgezeigt. Für ein besseres Verständnis der Erfindung, ihrer Vorteile und der Ziele, die durch ihren Gebrauch erreicht werden, sollte jedoch auf die Zeichnung und die Beschreibung Bezug genommen werden, die Beispiele einer erfindungsgemäßen Vorrichtung zeigen und beschreiben.
KURZBESCHREIBUNG DER ZEICHNUNG
Nachstehend wird auf die Zeichnung Bezug genommen, in der gleiche Bezugszeichen entsprechende Abschnitte bezeichnen. Es zeigen:
1 ein H.323-System,
2 den Nachrichtenaustausch zwischen einer Torwächterwolke und H.323-Endpunkten,
3 eine Tabelle, welche die Anzahl der ausgetauschten Nachrichten in der H.323v2-Spezifikation und in dem Rufaufbau-Verfahren für H.323-Systeme gemäß der Erfindung vergleicht,
4 die Rufaufbaunachrichten, wenn beide Endpunkte am selben Torwächter registriert sind und eine direkte Rufsignalisierung verwendet wird,
5 die Rufaufbaunachrichten, wenn beide Endpunkte am selben Torwächter registriert sind und eine torwächtergeleitete Rufsignalisierung verwendet wird,
6 die Rufsignalisierung, wenn nur der gerufene Endpunkt registriert ist und eine torwächtergeleitete Rufsignalisierung verwendet wird,
7 die Rufaufbaunachrichten, wenn beide Endpunkte registriert sind und beide Torwächter eine direkte Rufsignalisierung verwenden,
8 die Rufaufbaunachrichten, wenn beide Endpunkte registriert sind und eine direkte/geleitete Rufsignalisierung verwendet wird,
9 die Rufaufbaunachrichten, wenn beide Endpunkte registriert sind und eine geleitete/direkte Rufsignalisierung verwendet wird und
10 die Rufaufbaunachrichten, wenn beide Endpunkte registriert sind und eine geleitete/geleitete Rufsignalisierung verwendet wird.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Die Erfindung wird nachstehend anhand eines Ausführungsbeispiels unter Bezugnahme auf die beiliegende Zeichnung näher beschrieben. Es soll verstanden werden, dass andere Ausführungsbeispiele verwendet und strukturelle Veränderungen vorgenommen werden können, ohne den Bereich der Erfindung zu verlassen.
Die Erfindung bietet ein Verfahren zur Durchführung eines Rufaufbaus in Multimediakommunikationssystemen unter Verwendung einer geringeren Anzahl von Nachrichtenaustauschvorgängen, was zu einem effizienteren Rufaufbauverfahren führt. Außerdem wird beim Übergang auf eine geringere Anzahl von Nachrichtenaustauschvorgängen keine Rufaufbau-Funktionalität geopfert.
2 zeigt die Nachrichten 200, die zwischen einer Torwächterwolke 210 und H.323-Endpunkten 220, 230 ausgetauscht werden. Obwohl jeder Endpunkt einen unterschiedlichen Torwächter verwenden kann, ist in 2 zur Vereinfachung und Verdeutlichung der Signalisierung zwischen Endpunkten und einem Torwächter eine allgemeine Torwächterwolke 210 gezeigt. Bevor die Konferenz beginnt, suchen beide Endpunkte 220, 230 nach einem Torwächter 210, indem sie eine TorwächterErmittlungs-Anforderung (TAF) 240 mehrfach platzieren. Der Torwächter antwortet 242 entweder mit einer TorwächterBestätigungs-Nachricht (TBS) oder mit einer TorwächterZurückweisungs-Nachricht (TZW).
Dann registrieren beide Endpunkte 220, 230 ihre Aliasnamen am Torwächter unter Verwendung der RegistrierungsAnfoderungs-Nachricht (RAF) 244. Der Torwächter 210 bestätigt 246 durch Senden einer RegistrierungsBestätigungs-Nachricht (RBS) oder lehnt die Registrierung unter Verwendung einer RegistrierungsZurückweisungs-Nachricht (RZW) ab. Die Registrierung von Aliasnamen am Torwächter 210 ermöglicht es den Endpunkten 220, 230, einander unter Verwendung benutzerfreundlicher Adressen zu rufen, beispielsweise einer E-Mail- anstatt der Transportadresse. Die Ermittlungs- und Registrierprozedur ist solange gültig, bis der Torwächter 210 etwas anderes anzeigt. Ein Endpunkt 220, 230 oder der Torwächter 210 kann den Ort eines anderen Endpunkts unter Verwendung seines Aliasnamens anfordern, indem eine OrtsAnforderungs-Nachricht (OAF) 250 verwendet wird, wobei der Torwächter 210 mit einer OrtsBestätigungs-Nachricht (OBS) antwortet 252, die die aufgelöste Adresse für den Aliasnamen enthält.
Wenn ein Benutzer von einem Endpunkt 220 einen Ruf platziert, startet der Endpunkt 220 durch Anforderung eines Zugangs vom Torwächter unter Verwendung einer ZugangsAnforderungs-Nachricht (ZAF) 260. Der Torwächter 210 kann durch Akzeptanz (ZBS) oder durch Ablehnung (ZZW) antworten 262. Wird der Ruf akzeptiert, sendet der Endpunkt 220 eine Q.931-Aufbaunachricht 270 an den entfernten Zielpunkt 230. Der Empfänger 230 der Aufbaunachricht 270 fordert im Gegenzug Zugang durch Senden einer ZAF 260 von seinem Torwächter 210 an. Wird der Ruf akzeptiert 262, ist die Q.931-Rufsignalisierungs-Abfolge 270 vollendet und ihr folgt die H.245-Nachrichtenverhandlung 272.
Die ZugangsAnforderungs-Nachricht (ZAF) 250, 260 führt die anfängliche Bandbreite mit, die der Endpunkt für die Dauer der Konferenz benötigt. Benötigt während der logischen H.245-Kanalverhandlung 272 ein Endpunkt 230 mehr Bandbreite, schickt er eine BandbreitenAnforderungs-Nachricht (BAF) 264 an den Torwächter 210. Wird die Anforderung akzeptiert, antwortet 266 der Torwächter 210 mit einer BandbreitenBestätigungs-Nachricht (BBS), und sonst mit einer BandbreitenZurückweisungs-Nachricht (BZW).
Ist der Ruf beendet, senden beide Endpunkte 220, 230 eine EntkopplungsAnforderungs-Nachricht (EAF) 280, um den Torwächter 210 über die laufende Beendung des Rufs zu informieren. Der Torwächter 210 antwortet 282 mit einer Bestätigungs- (EBS) oder Zurückweisungsnachricht (EZW). Wahlweise können sich Endpunkte 220, 230 vom Torwächter 210 durch Senden einer DeregistrierungsAnforderungs-Nachricht (DAF) 290 abmelden. Der Torwächter antwortet 292 entweder mit einer DeregistrierungsBestätigungs-Nachricht (DBS) oder einer DerigistrierungsZurückweisungs-Nachricht (DZW).
Wie aus 2 ersichtlich ist, müssen mehrere Nachrichten zwischen Funktionseinheits-Paaren vor Vollendung der Rufaufbauphase in H.323-Systemen ausgetauscht werden. Die Erfindung ermöglicht es, die Anzahl der Nachrichtenaustauschvorgänge zu verringern.
Ein H.323-System weist ein Endpunkt-Paar auf, das an verschiedene Torwächter angeschlossen ist, die bestimmte Torwächterbereiche repräsentieren. Torwächter erfüllen einen erforderlichen Satz operativer Verantwortungen und können den Funktionseinheiten in ihrem Bereich eine Anzahl an optionalen Funktionen anbieten. Ein Torwächter fungiert als Monitor aller H.323-Rufe innerhalb seines Netzwerkbereichs. Er hat zwei Hauptverantwortungen: Rufzulassung und Adressauflösung.
Ein H.323-Client, der einen Ruf platzieren will, kann dies nicht ohne die Hilfe des Torwächters tun. Der Torwächter stellt für den Ziel-Client die Adressauflösung bereit. Die Anmeldeprozedur mit Aliasnamen macht diese Arbeitsteilung erforderlich. Während dieser Adressauflösungsphase kann der Torwächter auch Zulassungsentscheidungen auf der Grundlage der verfügbaren Bandbreite treffen. Der Torwächter kann für IT/IS-Verwalter als Überwachungspunkt im Netzwerk fungieren, um den ein- und ausgehenden H.323-Verkehr im Netzwerk zu steuern.
Genau genommen definiert sich ein Torwächterbereich durch seinen Inhalt: er ist durch alle bereits am Torwächter registrierten oder noch zu registrierenden Endpunkte, Tore und MSEs definiert. Bereiche werden durch alle an einem einzelnen Torwächter registrierten H.323-Geräte definiert. Eine Bereichsanordnung kann von der physikalischen Topologie unabhängig sein und jeder Bereich hat jeweils nur einen Torwächter. Die Bereichsdefinition ist implementierungsspezifisch, und Torwächterbereiche sind logischer Natur.
3 zeigt eine Tabelle 400, die die Anzahl der ausgetauschten Nachrichten in der H.323v2-Spezifikation 410 und in dem erfindungsgemäßen Rufaufbau-Verfahren für H.323-Systeme 420 vergleicht. 3 zeigt den Vergleich für 10 Szenarien wie folgt:

1. Keiner der Endpunkte ist registriert 430,
2. Beide Endpunkte sind am selben Torwächter registriert, direkte Rufsignalisierung 432,
3. Beide Endpunkte sind am selben Torwächter registriert, torwächtergeleitete Rufsignalisierung 434,
4. Nur der rufende Endpunkt ist registriert, direkte Rufsignalisierung 436,
5. Nur der gerufene Endpunkt ist registriert, direkte Rufsignalisierung 438,
6. Nur der gerufene Endpunkt ist registriert, torwächtergeleitete Rufsignalisierung 440,
7. Nur gerufene Endpunkte sind registriert, torwächtergeleitete Rufsignalisierung 442,
8. Beide Endpunkte sind registriert, direkte Rufsignalisierung beider Torwächter 444,
9. Beide Endpunkte sind registriert, direkte/geleitete Rufsignalisierung 446 und
10. Beide Endpunkte sind registriert, geleitete/direkte Rufsignalisierung 448.

Um die Anzahl der Nachrichten beim Durchführen eines ZAF/ZBS-Austauschs zwischen dem rufenden Endpunkt und seinem Torwächter zu verringern, könnte der Torwächter des gerufenen Endpunkts zu diesem Zeitpunkt Ressourcen für den Ruf zuweisen, da der Torwächter des gerufenen Endpunkts normalerweise kontaktiert werden muss. Dies umgeht das Erfordernis des gerufenen Endpunkts, zu einem späteren Zeitpunkt einen ZAF/ZBS-Austausch mit seinem Torwächter einzugehen.
Geht außerdem der rufende Endpunkt einen ZAF/ZBS-Austausch mit seinem Torwächter ein und wird am gerufenen Endpunkt eine torwächtergeleitete Rufsignalisierung gewünscht, wird die Transportadresse des gerufenen Torwächters (anstatt die des gerufenen Endpunkts) in der ZBS-Nachricht zurückgegeben. Ist der rufende Endpunkt an keinem Torwächter registriert und wird am gerufenen Endpunkt eine torwächtergeleitete Rufsignalisierung gewünscht, wird der Verbindungsabbau und der Wiederaufbau des Rufs beendet. Stattdessen wird durch den gerufenen Endpunkt dem rufenden Endpunkt direkt eine torwächtergeleitete Rufsignalisierung angezeigt und danach die Funktionalität einer torwächtergeleiteten Rufsignalisierung des gerufenen Endpunkts angewendet.
Die 5–11 veranschaulichen den erfindungsgemäßen Rufaufbau-Nachrichtenfluss. Ist keiner der beiden Endpunkte registriert, ist der Nachrichtenaustausch mit dem in der H.323-Spezifikation beschriebenen Nachrichtenaustausch identisch.
4 zeigt den Rufaufbau-Nachrichtenfluss, wenn beide Endpunkte am selben Torwächter registriert sind und eine direkte Rufsignalisierung verwendet wird 500. Wenn in 4 ein TW 510 eine ZAF 512 von einem EP_1 514 erhält, die anzeigt, dass er mit einem EP_2 516 kommunizieren möchte, wird eine Entscheidung bezüglich ZBS oder ZZW 518 getroffen, wobei sowohl der EP_1 514 als auch der EP_2 516 beachtet werden. Eine ZZW wird gesendet, wenn ein erforderliches Kriterium, wie Bandbreitenbedarf oder Autorisierung, nicht erfüllt ist. Wenn die Erfordernisse erfüllt sind, sendet der TW 510 eine ZBS an den EP_1 514 zusammen mit einem Token (oder verschlüsselten Token). Dieses Token wird dann von dem EP_1 514 zu dem EP_2 516 in der Aufbaunachricht 520 weitergegeben. Die im Token mitgeführten Informationen umfassen:
Eine Versicherung, dass das Token vom Torwächter von EP_2 erzeugt wurde.
Informationen (wie die zugewiesene Bandbreite), die EP_2 bekannt wären, hätte er seine eigene ZAF an den TW gesendet und eine ZBS erhalten.
Nach Empfang der Aufbaunachricht 520 und nach Verarbeitung des Tokens werden die Verbindungs-/Einrichtungsnachrichten 530 von EP_2 516 und EP_1 514 gesendet.
5 zeigt den Rufaufbau-Nachrichtenfluss, wenn beide Endpunkte am selben Torwächter registriert sind und eine torwächtergeleitete Rufsignalisierung verwendet wird 600. Wenn in 5 ein TW 610 eine ZAF 612 von einem EP_1 614 erhält, die anzeigt, dass er mit einem EP_2 616 kommunizieren möchte, wird eine Entscheidung bezüglich ZBS oder ZZW 618 getroffen, wobei sowohl der EP_1 614 als auch der EP_2 616 beachtet werden. Eine ZZW wird gesendet, wenn ein erforderliches Kriterium, wie Bandbreitenbedarf oder Autorisierung, nicht erfüllt ist. Wenn die Anforderungen erfüllt sind, sendet der TW 610 eine ZBS an den EP_1 614 zusammen mit einem Token (oder verschlüsselten Token). Dieses Token wird dann von dem EP_1 614 zu dem EP_2 616 in der Aufbaunachricht 620 weitergegeben, die dann vom TW 610 zu dem EP_2 616 gesendet wird. Die Informationen, die im Token mitgeführt werden, umfassen:
Eine Versicherung, dass das Token vom Torwächter von EP_2 erzeugt wurde.
Informationen (wie die zugewiesene Bandbreite), die EP_2 bekannt wären, hätte er seine eigene ZAF an den TW gesendet und eine ZBS erhalten.
Nach Empfang der Aufbaunachricht und nach Verarbeitung des Tokens werden die Verbindungs-/Einrichtungsnachrichten 630 von dem EP_2 616 zu dem TW 610 gesendet, der wiederum eine Verbindungs-/Einrichtungsnachricht 640 zu dem EP_1 614 sendet.
6 zeigt die Rufsignalisierung, wenn nur der gerufene Endpunkt registriert ist und eine torwächtergeleitete Rufsignalisierung verwendet wird 700. Nach Empfang der Aufbaunachricht 712 von EP_1 714 schickt EP_2 716 eine ZAF 718 an TW_2 710. Alle Informationen, die für den Rufaufbau durch TW_2 710 erforderlich sind, wenn er eine Aufbaunachricht 712 direkt von EP_1 714 empfangen hätte, sind in der ZAF-Nachricht 718 enthalten. Der TW_2 710 verarbeitet dann die Aufbau-Informationen, die in der ZAF-Nachricht 718 enthalten sind. Dann sendet der TW_2 710 eine ZBS (anstatt einer ZZW) zu dem EP_2 716, wenn andere Kriterien wie Bandbreitenbedarf und Autorisierung erfüllt sind. In der ZBS-Nachricht 720 zeigt der TW_2 710 dem EP_2 716 an, dass er den Rufsignalisierungskanal leiten möchte und bietet seine Rufsignalisierungskanaltransportadresse an. Der EP_2 716 sendet eine Einrichtungsnachricht 722 zu dem EP_1 714 und zeigt an, dass der Rufsignalisierungskanal durch den TW_2 710 geleitet werden muss und fügt auch die Rufsignalisierungskanaltransportadresse von TW_2 710 hinzu. Der EP_1 714 muss dann den ursprünglichen Rufaufbau nicht lösen und auch keinen neuen Rufaufbau zu dem TW_2 710 senden.
Ist nur der rufende Endpunkt registriert und wird eine direkte Rufsignalisierung verwendet, ist der Nachrichtenaustausch identisch mit dem in der H.323-Spezifikation offenbarten Nachrichtenaustausch. Ist nur der gerufene Endpunkt registriert und wird eine direkte Rufsignalisierung verwendet, ist der Nachrichtenaustausch mit der H.323-Spezifikation identisch. Es müssen jedoch einige zusätzliche Informationen in die von dem EP_2 zu dem TW_2 gesendete ZAF-Nachricht aufgenommen werden. Alle zum Rufaufbau durch TW_2 erforderlichen Informationen, hätte er eine Aufbaunachricht direkt von EP_1 erhalten, werden aufgenommen. Da der TW_2 entscheidet, den Rufsignalisierungskanal nicht zu leiten, macht er in diesem Fall keinen Gebrauch von diesen Informationen.
7 zeigt den Rufaufbau-Nachrichtenfluss, wenn beide Endpunkte registriert sind und beide Torwächter eine direkte Rufsignalisierung 800 verwenden. Wenn ein TW_1 810 eine ZRF 812 von einem EP_1 814 erhält, überprüft er bestimmte lokal überprüfbare Kriterien, wie Bandbreitenbedarf, Autorisierung, usw. Wenn irgendeine der Anforderungen nicht erfüllt ist, wird eine ZZW 812 zu dem EP_1 814 gesendet. Wenn alle lokalen Anforderungen erfüllt sind, dann durchläuft die ZAF 818 eine Wolke 820 aus null oder mehreren Torwächtern, bevor sie von einem TW_2 822 empfangen wird. Auf der Grundlage eines Bandbreitenbedarfs, einer Autorisierung und anderen Kriterien entscheidet der TW_2 822, ob er eine ZBS oder ZZW sendet. Die Rufsignalisierungskanaltransportadresse von einem EP_2 830 ist in der ZBS 832 mit aufgenommen. Der TW_2 822 entscheidet, ob er eine ZBS oder ZZW sendet. Die Rufsignalisierungskanaltransportadresse von EP_2 830 ist in der ZBS 832 mit aufgenommen. Der TW_2 822 nimmt auch ein Token/verschlüsseltes Token mit auf, das Informationen wie vorstehend beschrieben enthält. Die ZBS/ZZW-Nachricht 832 läuft durch die Torwächterwolke 820, bevor sie am TW_1 810 ankommt. Wenn eine ZZW ankommt, sendet der TW_1 810 eine ZZW zu dem EP_1 814. Ansonsten sendet der TW_1 810 eine ZBS 816 zu dem EP_1 814 mit der Rufsignalisierungskanaltransportadresse von EP_2 830. Die Aufbau- 834 und Verbindungsnachrichten 840 finden zwischen dem EP_1 814 und dem EP_2 830 statt. Der Aufbau 834 beinhaltet das Token, das der TW_2 822 in der ZBS-Nachricht 832 gesendet hatte.
8 zeigt den Rufaufbau-Nachrichtenfluss, wenn beide Endpunkte registriert sind und eine direkte/geleitete Rufsignalisierung 900 verwendet wird. Wenn ein TW_1 910 eine ZAF 912 von einem EP_1 914 empfängt, überprüft der TW_1 910 bestimmte lokal überprüfbare Kriterien, wie Bandbreitenbedarf, Autorisierung, usw. Wenn irgendeine der Anforderungen nicht erfüllt ist, dann wird eine ZZW zu dem EP_1 914 gesendet. Wenn alle lokalen Anforderungen erfüllt sind, durchläuft die ZAF 916 eine Wolke 920 aus null oder mehreren Torwächtern, bevor sie von einem TW_2 922 empfangen wird. Auf der Grundlage von Bandbreitenbedarf, Autorisierung und anderen Kriterien entscheidet der TW_2 922, ob er eine ZBS oder ZZW sendet. Die Rufsignalisierungskanaltransportadresse von TW_2 922 ist in der ZBS 932 enthalten. Der TW_2 922 fügt auch ein Token/verschlüsseltes Token hinzu, wie vorstehend beschrieben. Die ZBS/ZZW-Nachrichten 932 laufen durch die Torwächterwolke 920, bevor sie am TW_1 910 ankommen. Wenn eine ZZW ankommt, sendet der TW_1 910 eine ZZW zu dem EP_1 914. Ansonsten sendet der TW_1 910 eine ZBS 918 mit der Rufsignalisierungskanaltransportadresse von TW_2 922 zu dem EP_1 914. Die Aufbaunachricht 934 wird vom EP_1 914 zu dem TW_2 922 gesendet, der sie zu einem EP_2 930 leitet. Der Aufbau 934 enthält das Token, das der TW_2 922 in der ZBS-Nachricht 932 gesendet hatte. Die Verbindungsnachrichten 940 vom EP_2 930 werden zu dem TW_2 gesendet, der sie zu dem EP_1 914 leitet.
9 zeigt den Rufaufbau-Nachrichtenfluss, wenn beide Endpunkte registriert sind und eine geleitete/direkte Rufsignalisierung 1000 verwendet wird. Wenn ein TW_1 1010 eine ZAF 1012 von einem EP_1 1014 empfängt, überprüft der TW_1 1010 bestimmte lokal überprüfbare Kriterien, wie Bandbreitenbedarf, Autorisierung, usw. Wenn eine der Anforderungen nicht erfüllt ist, wird eine ZZW zu dem EP_1 1014 gesendet. Wenn alle lokalen Anforderungen erfüllt sind, dann durchläuft die ZAF 1016 eine Wolke 1020 aus null oder mehreren Torwächtern, bevor sie von einem TW_2 1022 empfangen wird. Auf der Grundlage von Bandbreitenbedarf, Autorisierung und anderen Kriterien entscheidet der TW_2 1022, ob er eine ZBS oder ZZW sendet. Die Transportadresse des Rufsignalisierungskanals von EP_2 1030 ist in der ZBS 1032 enthalten. Der TW_2 1022 fügt auch ein Token/verschlüsseltes Token hinzu, wie vorstehend beschrieben. Die ZBS/ZZW-Nachrichten 1032 durchlaufen die Torwächterwolke 1020, bevor sie am TW_1 1010 ankommen. Wenn eine ZZW ankommt, sendet der TW_1 1010 eine ZZW zu dem EP_1 1014. Ansonsten sendet der TW_1 1010 eine ZBS 1018 mit der Rufsignalisierungskanalstransportadresse von TW_2 1022 zu dem EP_1 1014. Die Aufbaunachricht 1034 wird vom EP_1 1014 zu dem TW_1 1010 gesendet, der sie zu einem EP_2 1030 leitet. Der Aufbau 1034 beinhaltet das Token, das der TW_2 1022 in der ZBS-Nachricht 1032 gesendet hatte.
Die Verbindungsnachrichten 1040 vom EP_2 1030 werden zu dem TW_1 1010 gesendet, der sie zu dem EP_1 1014 leitet.
10 zeigt den Rufaufbau-Nachrichtenfluss, wenn beide Endpunkte registriert sind und eine geleitete/geleitete Rufsignalisierung 1100 verwendet wird. Wenn ein TW_1 1110 eine ZAF 1112 von einem EP_1 1114 empfängt, überprüft der TW_1 1110 bestimmte lokal überprüfbare Kriterien, wie Bandbreitenbedarf, Autorisierung, usw. Wenn eine der Anforderungen nicht erfüllt ist, wird eine ZZW zu dem EP_1 1114 gesendet. Wenn alle lokalen Anforderungen erfüllt sind, dann durchläuft die ZAF 1116 eine Wolke 1120 aus null oder mehreren Torwächtern, bevor sie von einem TW_2 1122 empfangen wird. Auf der Grundlage von Bandbreitenbedarf, Autorisierung und anderen Kriterien entscheidet der TW_2 1122, ob er eine ZBS oder ZZW sendet. Die Rufsignalisierungskanaltransportadresse von TW_2 1122 ist in der ZBS 1132 enthalten. Der TW_2 1122 fügt auch ein Informationen enthaltendes Token/verschlüsseltes Token hinzu, wie vorstehend beschrieben. Die ZBS/ZZW-Nachrichten 1132 durchlaufen die Torwächterwolke 1120, bevor sie an dem TW_1 1110 ankommen. Wenn eine ZZW ankommt, dann sendet der TW_1 1110 eine ZZW zu dem EP_1 1114. Ansonsten sendet der TW_1 1110 eine ZBS 1118 mit der Rufsignalisierungskanaltransportadresse von sich selbst zu dem EP_1 1114. Die Aufbaunachricht 1134 wird von dem EP_1 1114 zu dem TW_1 1110 gesendet, der sie zu einem TW_2 1122 leitet. Der Aufbau 1134 beinhaltet das Token, das der TW_2 1122 in der ZBS-Nachricht 1132 gesendet hatte. Die Verbindungsnachrichten 1140 von einem EP_2 1130 werden zu dem TW_2 1122 gesendet, der sie zu dem TW_1 1110 leitet, der sie wiederum zu dem EP_1 1114 leitet.
Zusammengefasst stellt die Erfindung ein Verfahren bereit, um den Rufaufbau in H.323-Systemen unter Verwendung einer geringeren Anzahl von Nachrichtenaustauschvorgängen durchzuführen, was zu einem effizienteren Rufaufbauverfahren führt. Außerdem wird beim Übergang auf eine geringere Anzahl an Nachrichtenaustauschvorgängen keine Rufaufbau-Funktionalität geopfert. Zum Vergleich führt das gegenwärtig existierende Schnellstartverfahren im H.323-Standard zwar zu einer geringeren Anzahl an Nachrichtenaustauschvorgängen, beeinträchtigt aber die Rufaufbau-Funktionalität.
Die vorstehende Beschreibung des Ausführungsbeispiels der Erfindung dient der Veranschaulichung und Beschreibung. Sie ist weder erschöpfend noch beschränkt sie die Erfindung auf die genau vorgestellte Form. Es sind viele Modifikationen und Variationen im Lichte der vorstehenden Beschreibung möglich. Der Schutzbereich der Erfindung ist lediglich durch die beiliegenden Patentansprüche beschränkt.

Claims

Verfahren zum Verbessern einer Rufaufbaueffizienz in Multimedia-Kommunikationssystemen, mit den Schritten: Platzieren eines Rufs an einem ersten Endpunkt (220) zu einem entfernten Endpunkt (230); Anfordern (260) von Zugang für den Ruf von einem Torwächter; Zurückgeben (262) einer Akzeptanznachricht an den ersten Endpunkt, wobei die Akzeptanznachricht (262) ein Token (518, 618, 832, 932, 1032, 1132) zur Bereitstellung von Informationen an den entfernten Endpunkt (230) enthält, was das Erfordernis des entfernten Endpunkts (230) erleichtert, Zugang von einem Torwächter (210) anzufordern; Leiten einer Aufbaunachricht (270) an den entfernten Endpunkt (230), wobei die Aufbaunachricht das Token (518, 618, 832, 932, 1032, 1132) enthält; und Vollenden eines Rufaufbaus basierend auf Informationen im Token (518, 618, 832, 932, 1032, 1132), wobei das Token Ressourcenzuweisungen für den Ruf aufweist.
Verfahren gemäß Anspruch 1, bei dem der erste Endpunkt (220) und der entfernte Endpunkt (230) an einem gemeinsamen Torwächter (510) registriert sind.
Verfahren gemäß Anspruch 2, bei dem von dem ersten Endpunkt und dem entfernten Endpunkt eine direkte Rufsignalisierung implementiert wird (432), wobei das Leiten der Aufbaunachricht (270) durch direktes Übertragen der Aufbaunachricht (270) einschließlich des Tokens (518, 618, 832, 932, 1032, 1132) an den entfernten Endpunkt (230) durchgeführt wird, und bei dem das Token eine Sicherung enthält, dass das Token vom Torwächter (260) erzeugt wurde, wobei das Token Informationen aufweist, von denen der entfernte Endpunkt (230) Kenntnis hätte, falls der entfernte Endpunkt (230) mit dem Torwächter (260) kommuniziert hatte.
Verfahren gemäß Anspruch 2, bei dem eine vom Torwächter geleitete Rufsignalisierung implementiert wird (434), das Leiten der Aufbaunachricht (270) durch Leiten der Aufbaunachricht (270) einschließlich des Tokens (518, 618, 832, 932, 1032, 1132) vom ersten Endpunkt an den gemeinsamen Torwächter (260) und Leiten der Aufbaunachricht (270) einschließlich des Tokens vom gemeinsamen Torwächter (260) an den entfernten Endpunkt (230) durchgeführt wird.
Verfahren gemäß Anspruch 1, bei dem der erste Endpunkt (220) an einem ersten Torwächter registriert ist und der entfernte Endpunkt an einem zweiten Torwächter (444, 446, 448) registriert ist.
Verfahren gemäß Anspruch 5, bei dem das Anfordern von Zugang für den Ruf von einem Torwächter zusätzlich die Schritte aufweist: Anfordern (812) von Zugang vom ersten Torwächter (810) durch den ersten Endpunkt (814); Analysieren der Zugangsanforderung (812) durch den ersten Torwächter (810), um zu bestimmen, ob ein Kriterium für den Ruf gemäß am ersten Torwächter (810) lokalen Voraussetzungen akzeptabel ist; Leiten der Zugangsanforderung an den zweiten Torwächter (822), wenn der erste Torwächter bestimmt, dass das Kriterium für den Ruf akzeptabel ist (818); Analysieren der Zugangsanforderung durch den zweiten Torwächter (822), um zu bestimmen, ob ein Kriterium für den Ruf gemäß am zweiten Torwächter (822) lokalen Voraussetzungen akzeptabel ist; und Senden einer Zugangsbestätigung (832) einschließlich des Tokens an den ersten Torwächter (810), wenn ein erforderliches Kriterium für den Ruf gemäß den am zweiten Torwächter (822) lokalen Voraussetzungen als akzeptabel bestimmt wird.
Verfahren gemäß Anspruch 6, bei dem der erste und der zweite Torwächter (810, 822) eine direkte Rufsignalisierung implementieren, wobei das Leiten der Aufbaunachricht durch direktes Übertragen (834) der Aufbaunachricht einschließlich des Tokens an den entfernten Endpunkt durchgeführt wird.
Verfahren gemäß Anspruch 6, bei dem der erste Torwächter (910) eine direkte Rufsignalisierung implementiert und der zweite Torwächter (922) eine geleitete Rufsignalisierung implementiert, das Leiten der Aufbaunachricht (934) durch Übertragen der Aufbaunachricht (934) einschließlich des Tokens an den zweiten Torwächter (922) durchgeführt wird, und indem der zweite Torwächter (922) die Aufbaunachricht (934) einschließlich des Tokens an den entfernten Endpunkt (930) überträgt.
Verfahren gemäß Anspruch 8, bei dem die Vollendung des Rufaufbaus zusätzlich ein Leiten der Aufbaunachricht (934) durch Übertragen von Verbindungs-/Einrichtungsnachrichten vom entfernten Endpunkt (930) an den zweiten Torwächter (922) und Übertragen der Verbindungs-/Einrichtungsnachrichten vom zweiten Torwächter (922) an die Aufbaunachricht des ersten Endpunkts aufweist.
Verfahren gemäß Anspruch 6, bei dem der erste Torwächter (1010) eine geleitete Rufsignalisierung implementiert und der zweite Torwächter (1022) eine direkte Rufsignalisierung implementiert, das Leiten der Aufbaunachricht (1034) durch Übertragen der Aufbaunachricht (1034) einschließlich des Tokens an den ersten Torwächter (1010) durchgeführt wird, und indem der erste Torwächter (1010) die Aufbaunachricht einschließlich des Tokens an den entfernten Endpunkt (1030) überträgt.
Verfahren gemäß Anspruch 10, bei dem die Vollendung des Rufaufbaus zusätzlich ein Leiten der Aufbaunachricht (1034) durch Übertragen von Verbindungs-/Einrichtungsnachrichten vom entfernten Endpunkt (1030) an den ersten Torwächter (1010) und Übertragen der Verbindungs-/Einrichtungsnachrichten vom ersten Torwächter (1010) an die Aufbaunachricht des ersten Endpunkts aufweist.
Verfahren gemäß Anspruch 6, bei dem der erste Torwächter (1110) und der zweite Torwächter (1122) eine geleitete Rufsignalisierung implementieren, das Leiten der Aufbaunachricht (1134) durch Übertragen der Aufbaunachricht (1134) einschließlich des Tokens an den ersten Torwächter (1110) durchgeführt wird, indem der erste Torwächter (1110) die Aufbaunachricht (1134) einschließlich des Tokens an den zweiten Torwächter (1122) überträgt, und indem der zweite Torwächter (1122) die Aufbaunachricht (1134) einschließlich des Tokens an den entfernten Endpunkt (1130) überträgt.
Verfahren gemäß Anspruch 12, bei dem die Vollendung des Aufbaus zusätzlich ein Leiten der Rufaufbaunachricht (1134) durch Übertragen von Verbindungs-/Einrichtungsnachrichten vom entfernten Endpunkt (1130) an den zweiten Torwächter (1122), Übertragen der Verbindungs-/Einrichtungsnachrichten vom zweiten Torwächter (1122) an den ersten Torwächter (1110) und Übertragen der Verbindungs-/Einrichtungsnachrichten vom ersten Torwächter (1110) an die Aufbaunachricht des ersten Endpunkts aufweist.
Verfahren gemäß Anspruch 6, bei dem das Leiten der Zugangsanforderung an den zweiten Torwächter zusätzlich ein Leiten der Zugangsanforderung durch eine Torwächterwolke (1020) aufweist.
Verfahren gemäß Anspruch 5, bei dem das Token (518) eine Transportadresse des zweiten Torwächters (260) aufweist.
Multimedia-Kommunikationssystem, mit: einem ersten Endpunkt (220) zum Platzieren eines Rufs zu einem entfernten Endpunkt (230); einem Torwächter (260), der betrieblich mit dem ersten Endpunkt (220) gekoppelt ist, wobei der Torwächter (260) zum Durchführen von Adressumsetzung, Zugangssteuerung und Bandbreitensteuerung konfiguriert ist; bei dem der erste Endpunkt (220) zum Anfordern von Zugang für den Ruf vom Torwächter (260) konfiguriert ist, der Torwächter (260) zum Zurückgeben einer Akzeptanznachricht (518, 618, 832, 932, 1032, 1132) an den ersten Endpunkt (220) konfiguriert ist, wobei die Akzeptanznachricht (518, 618, 832, 932, 1032, 1132) ein Token zur Bereitstellung von Informationen an den entfernten Endpunkt (230) enthält, was das Erfordernis des entfernten Endpunkts (230) erleichtert, Zugang von einem Torwächter (260) anzufordern, der erste Endpunkt (220) zum Leiten einer Aufbaunachricht (270) an den entfernten Endpunkt konfiguriert ist, wobei die Aufbaunachricht (270) das Token enthält, und der entfernte Endpunkt (230) zum Vollenden des Rufaufbaus basierend auf Informationen im Token konfiguriert ist, wobei das Token Ressourcenzuweisungen für den Ruf aufweist.
Multimedia-Kommunikationssystem gemäß Anspruch 16, bei dem der erste Endpunkt (220) und der entfernte Endpunkt (230) an einem gemeinsamen Torwächter (260) registriert sind.
Multimedia-Kommunikationssystem gemäß Anspruch 17, bei dem von dem ersten Endpunkt und dem entfernten Endpunkt eine direkte Rufsignalisierung implementiert ist (432), wobei der erste Endpunkt die Aufbaunachricht (270) durch direktes Übertragen der Aufbaunachricht (270) einschließlich des Tokens (518, 618, 832, 932, 1032, 1132) an den entfernten Endpunkt (230) leitet, und bei dem das Token eine Sicherung enthält, dass das Token vom Torwächter (260) erzeugt wurde, wobei das Token Informationen aufweist, von denen der entfernte Endpunkt (230) Kenntnis hätte, falls der entfernte Endpunkt (230) mit dem Torwächter (260) kommuniziert hatte.
Multimedia-Kommunikationssystem gemäß Anspruch 17, bei dem eine vom Torwächter geleitete Rufsignalisierung implementiert ist (434), wobei der erste Endpunkt die Aufbaunachricht (270) durch Leiten der Aufbaunachricht (270) einschließlich des Tokens (518, 618, 832, 932, 1032, 1132) an den gemeinsamen Torwächter (260) leitet, und der gemeinsame Torwächter (260) die Aufbaunachricht (270) einschließlich des Tokens an den entfernten Endpunkt (230) leitet.
Multimedia-Kommunikationssystem gemäß Anspruch 16, bei dem der erste Endpunkt (220) an einem ersten Torwächter registriert ist und der entfernte Endpunkt an einem zweiten Torwächter (444, 446, 448) registriert ist.
Multimedia-Kommunikationssystem gemäß Anspruch 20, bei dem der erste Endpunkt (814) Zugang (812) vom ersten Torwächter (810) anfordert, wobei der erste Torwächter (810) die Zugangsanforderung (812) analysiert, um zu bestimmen, ob ein Kriterium für den Ruf gemäß am ersten Torwächter (810) lokalen Voraussetzungen akzeptabel ist, der erste Torwächter die Zugangsanforderung an den zweiten Torwächter (822) leitet, wenn der erste Torwächter bestimmt, dass das Kriterium für den Ruf akzeptabel ist (818); wobei der zweite Torwächter (822) die Zugangsanforderung analysiert, um zu bestimmen, ob ein Kriterium für den Ruf gemäß am zweiten Torwächter (822) lokalen Voraussetzungen akzeptabel ist; und wobei der zweite Torwächter (822) eine Zugangsbestätigung (832) einschließlich des Tokens an den ersten Torwächter (810) sendet, wenn ein erforderliches Kriterium für den Ruf gemäß den am zweiten Torwächter (822) lokalen Voraussetzungen als akzeptabel bestimmt ist.
Multimedia-Kommunikationssystem gemäß Anspruch 21, bei dem der erste und der zweite Torwächter (810, 822) eine direkte Rufsignalisierung implementieren, wobei der erste Endpunkt die Aufbaunachricht durch direktes Übertragen (834) der Aufbaunachricht einschließlich des Tokens an den entfernten Endpunkt leitet.
Multimedia-Kommunikationssystem gemäß Anspruch 21, bei dem der erste Torwächter (910) eine direkte Rufsignalisierung implementiert und der zweite Torwächter (922) eine geleitete Rufsignalisierung implementiert, wobei der erste Endpunkt die Aufbaunachricht (934) durch Übertragen der Aufbaunachricht (934) einschließlich des Tokens an den zweiten Torwächter (922) leitet, und der zweite Torwächter (922) die Aufbaunachricht (934) einschließlich des Tokens an den entfernten Endpunkt (930) überträgt.
Multimedia-Kommunikationssystem gemäß Anspruch 23, bei dem der entfernte Endpunkt (930) den Rufaufbau durch Übertragen von Verbindungs-/Einrichtungsnachrichten an den zweiten Torwächter (922) vollendet, und indem der zweite Torwächter (922) die Verbindungs-/Einrichtungsnachrichten an die Aufbaunachricht des ersten Endpunkts überträgt.
Multimedia-Kommunikationssystem gemäß Anspruch 21, bei dem der erste Torwächter (1010) eine geleitete Rufsignalisierung implementiert und der zweite Torwächter (1022) eine direkte Rufsignalisierung implementiert, wobei der erste Endpunkt (1010) die Aufbaunachricht (1034) durch Übertragen der Aufbaunachricht (1034) einschließlich des Tokens an den ersten Torwächter (1010) leitet, und indem der erste Torwächter (1010) die Aufbaunachricht einschließlich des Tokens an den entfernten Endpunkt (1030) überträgt.
Multimedia-Kommunikationssystem gemäß Anspruch 25, bei dem der entfernte Endpunkt (1030) den Rufaufbau durch Übertragen von Verbindungs-/Einrichtungsnachrichten an den ersten Torwächter (1010) vollendet, und indem der erste Torwächter (1010) die Verbindungs-/Einrichtungsnachrichten vom ersten Torwächter (1010) an die Aufbaunachricht des ersten Endpunkts überträgt.
Multimedia-Kommunikationssystem gemäß Anspruch 21, bei dem der erste Torwächter (1110) und der zweite Torwächter (1122) eine geleitete Rufsignalisierung implementieren, wobei der erste Endpunkt (1114) die Aufbaunachricht (1134) durch Übertragen der Aufbaunachricht (1134) einschließlich des Tokens an den ersten Torwächter (1110) leitet, und indem der erste Torwächter (1110) die Aufbaunachricht (1134) einschließlich des Tokens an den zweiten Torwächter (1122) überträgt und der zweite Torwächter (1122) die Aufbaunachricht (1134) einschließlich des Tokens an den entfernten Endpunkt (1130) überträgt.
Multimedia-Kommunikationssystem gemäß Anspruch 27, bei dem der entfernte Endpunkt (1130) den Rufaufbau durch Übertragen von Verbindungs-/Einrichtungsnachrichten an den zweiten Torwächter (1122) vollendet, und indem der zweite Torwächter (1122) die Verbindungs-/Einrichtungsnachrichten an den ersten Torwächter (1110) überträgt und der erste Torwächter (1110) die Verbindungs-/Einrichtungsnachrichten vom ersten Torwächter (1110) an die Aufbaunachricht des ersten Endpunkts überträgt.
Multimedia-Kommunikationssystem gemäß Anspruch 21, zusätzlich mit einer Torwächterwolke (1020), die den ersten und den zweiten Torwächter (1010, 1022) koppelt, wobei der erste Torwächter (1110) die Zugangsanforderung durch die Torwächterwolke (1020) an den zweiten Torwächter (1122) leitet.
Multimedia-Kommunikationssystem gemäß Anspruch 20, bei dem das Token eine Transportadresse des zweiten Torwächters (822, 922, 1022, 1122) aufweist.