DE60031817T2

DE60031817T2 - Verfahren zum Kommunikationssitzungsaufbau zwischen einem Endgerät eines paketbasierten Netzwerks und einem Endgerät verbunden mit einem Fernzugriffsserver

Info

Publication number: DE60031817T2
Application number: DE60031817T
Authority: DE
Inventors: Yeon-Seung Ryu
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 1999-09-06
Filing date: 2000-08-25
Publication date: 2007-03-01
Anticipated expiration: 2020-08-26
Also published as: DE60031817D1; KR20010026362A; KR100326332B1; EP1081920A2; NO20004401D0; NO20004401L; NO331615B1; US6862626B1; EP1081920A3; EP1081920B1

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Aufbau einer Kommunikationssitzung zwischen einem Endgerät eines IP (Internet Protokoll) Netzwerkes und eines Endgerätes welches über ein PPP (Point to Point Protocol) mit einem Remote Access Server (Fernzugriffserver) verbunden ist, und im Speziellen auf ein Kommunikationsprotokoll zwischen einem Gatekeeper und einem Remote Access Server.
1 illustriert eine Netzwerkstruktur für das Befähigen eines ersten Terminals C 12, welches mit einem Fernsprechnetz (Public Switched Telephone Network PSTN) oder einem ISDN (Integrated Service Digital Network) 10 verbunden ist, auf ein IP Netzwerk über eine Einwahlverbindung mit einem Remote Access Server 20 zuzugreifen. In diesem Fall macht das Terminal C 12 eine PPP Verbindung mit dem Remote Access Server 20, wobei diesem eine IP Adresse zugewiesen ist, so dass dieses Datenpakete mit einem bestimmten Leitrechner (Host) über das IP Netzwerk 30 austauschen kann.
2 ist eine Netzwerkstruktur, wie durch ITU-T (International Telecommunication Union – Telecommunication Standardisation Sector) in H.323 (Packed Based Multimedia Communications System) vorgeschlagen. ITU-T H.323 bietet einen Standard für das Befähigen von H.323 Terminals, um Multimediakommunikation miteinander in einem paketbasierten Netzwerk wie in einem IP Netzwerk zu machen, und definiert die Entitäten eines Gatekeepers 38, Terminals 32, 36, Gateway 34 und MCU (Multipoint Controll Unit, nicht gezeigt), sowie ein Kommunikationsprotokoll zwischen diesen Entitäten. Gemäß diesem Protokoll sollten die Terminals ihre Aliase und IP Adressen in dem Gatekeeper 38 registrieren und eine Zulassung von diesem empfangen zum Betreiben einer Kommunikation miteinander. Das benutzte Protokoll besteht aus RAS (Registration, Admission and Status) und Q.931 von ITU-T H.225.0 (Line Transmission of Non-Telephone Signals).
3 ist ein Flussdiagramm welches den Prozess des Nachrichtenaustauschs, um ein Terminal A zu befähigen eine Verbindung mit einem Terminal B in dem H.323 Netzwerk herzustellen, illustriert. Zuerst senden die Terminals RRQ Nachrichten (Registration Request/Registrierungsanfrage) zu dem Gatekeeper, um deren Aliase (eine Art von Telefonnummer) und IP Adressen in den Schritten 50-1 und 50-3 zu registrieren, und dann empfangen sie RCF Nachrichten (Registration Confirm/Registrierungsbestätigung) in den Schritten 50-2 und 50-4, so dass diese durch die von dem Gatekeeper gemäß deren Aliase abgerufenen IP Adressen miteinander kommunizieren können. Gleichzeitig mit dem Abrufen der IP Adressen des empfangenden Terminals tauscht das sendende Terminal eine ARQ Nachricht (Admission Request/Zulassungsanfrage) und eine ACF Nachricht (Admission Confirm/Zulassungsbestätigung) mit dem Gatekeeperjeweils in den Schritten 50-5 und 50-6 aus, um die Zulassung für die Kommunikation zu empfangen. Wenn ein Terminal A die ACF Nachricht von dem Gatekeeper empfängt, sendet Terminal A in Schritt 50-7 eine Q931 Einrichtungsnachricht für eine Ruf-Signalisierung an das empfangende Terminal B, wie in 3 gezeigt. Dann tauscht das empfangende Terminal B ebenso eine ARQ Nachricht und ACF Nachricht mit dem Gatekeeper jeweils in den Schritten 50-8 und 50-9 aus, um die Zulassung für die Kommunikation zu empfangen. Wenn das empfangende Terminal B die ACF Nachricht von dem Gatekeeper erhält, sendet das empfangende Terminal B in Schritt 50-10 eine Q931 Verbindungsnachricht zu dem sendenden Terminal A, und führt H.245 Ruf-Signalisierung, um eine Kommunikation zu etablieren, in Schritt 50-11 aus.
In Bezug auf 4, welches die Struktur eines kombinierten Netzwerkes illustriert, welches die Netzwerke der 1 und 2 beinhaltet, greift das Terminal C 12 auf den Remote Access Server 20 zu, um mit einem bestimmten H.232 Terminal zu kommunizieren, wie beispielsweise Terminal A 32 oder B 36, welche mit dem IP Netzwerk 30 verbunden sind. Natürlich, wenn mit dem IP Netzwerk 30 verbunden, sollte das Terminal C 12 seinen Alias und IP Adresse in dem Gatekeeper 38 registrieren, und dann die Zulassung für die Kommunikation zu empfangen.
Deshalb, während das Terminal C 12 eine Einwahlverbindung mit dem Remote Access Server 20 mit der Hilfe eines Modem aufrecht erhält, können die Terminals des IP Netzwerkes 30 mit dem Terminal C 12 zu jeder Zeit kommunizieren. Jedoch bleibt das Terminal C 12 gewöhnlich „Off-Line" von dem Remote Access Server 20 wegen der Kosten einer Modem-Einwahlverbindung, wenn die Kommunikation mit dem IP Netzwerk 30 nicht benötigt wird. Wenn die Einwahlverbindung mit dem Remote Access Server 20 terminiert wird, verliert das Terminal C 12 seine IP Adresse, und seine registrierte Information in dem Gatekeeper 38 wird unwirksam, so dass die Terminals in dem IP Netzwerk sich nicht mehr mit dem Terminal C in einem Kreisnetz wie ein PSTN verbinden können.
Ein Artikel publiziert in Computer Networks, Elsevier Science Publishers B.v., Amsterdam, NI (11.02.1999), Band 31 (3), Seiten 205 bis 223, bezieht sich auf den H.323 Standard und beschreibt die Typen und Funktion von H.323 Terminals und anderen H.323 Geräten ebenso wie deren Zusammenspiel.
EP-A-0781015 offenbart ein Computernetzwerktelefonsystem. Es wird weiterhin beschrieben, dass Terminals in Computernetzen über Server verbunden sind, um Daten, welche zumindest Audiodaten beinhalten, durch die Computernetzwerke zu übertragen. Wenn ein Quell-Terminal einen Anruf zu einem Zielterminal macht, ruft der Server des Computernetzwerkes das Zielterminal an und stellt eine Verbindung zwischen dem Server des Computernetzwerkes und dem Zielterminal her.
Es ist die Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren für das Ermöglichen, dass ein erstes Terminal in einem IP Netzwerk mit einem zweiten Terminal, welches auf einen Remote Access Server zugreift, kommuniziert, anzubieten, selbst wenn das zweite Terminal die Einwahlverbindung mit dem Remote Access Server terminiert.
Diese Aufgabe ist gelöst durch den Gegenstand der unabhängigen Ansprüche.
Bevorzugte Ausführungsformen sind in den abhängigen Ansprüchen definiert.
Gemäß einem Aspekt der vorliegenden Erfindung beinhaltet ein Verfahren zum Ermöglichen, dass ein erstes Terminal auf einem paketbasierten Netzwerk mit einem zweiten Terminal, welches auf einen Remote Access Server zugreift, zu kommunizieren, die Schritte des Registrierens der Aliase und IP (Internet Protocol) Adressen des ersten Terminals und Remote Access Server in dem Gatekeeper, Zulassen, dass das erste Terminal an den Gatekeeper eine Nachricht zum Anfragen einer Verbindung mit dem zweiten Terminal sendet, Veranlassen, dass der Gatekeeper den Remote Access Server anfragt, dass diese sich mit dem zweiten Terminal, selbst wenn dieses nicht in dem Gatekeeper registriert ist, verbindet, Veranlassen, dass der Remote Access Server anfragt, dass das zweite Terminal seine Alias und IP Adresse in dem Gatekeeper registriert und Etablieren einer Kommunikation zwischen dem ersten und zweiten Terminal durch den Gatekeeper.
Die vorliegende Erfindung wird nun, als ein Beispiel, in Bezug auf die angefügten Zeichnungen genauer beschrieben.
1 ist ein Diagramm für das Illustrieren der Struktur eines Kommunikationsnetzwerkes für ein Terminal, welches mit einem PSTN oder ISDN verbunden ist, um eine Einwahlverbindung mit einem IP Netzwerk durch einen Remote Access Server zu machen;
2 ist ein Diagramm für das Illustrieren eines Kommunikationsnetzwerkes, welches in H.323 der ITU-T empfohlen wird;
3 ist ein Flussdiagramm für das Illustrieren des Flusses von Nachrichten zwischen Terminals in einem H.323 Netzwerk;
4 ist das kombinierte Netzwerk, beinhaltend die Netzwerke der 1 und 2; und
5 ist ein Flussdiagramm für das Illustrieren des Prozesses des Verbindens eines Terminals in einem IP Netzwerk und eines Terminals, welches auf einen Remote Access Server zugreift, gemäß der vorliegenden Erfindung.
Die vorliegende Erfindung stellt ein Kommunikationsprotokoll zwischen dem Gatekeeper und dem Remote Access Server gemäß eines Nachrichtenflusses wie in 5 gezeigt bereit, wo die Nachrichten-Syntax und Datenstruktur ASN.1 (Abstract Syntax Notation No. 1), wie in Tabelle 1 gezeigt, entspricht.
Tabelle 1
Die Terminologie, welche in Tabelle 1 benutzt wird, entspricht ITU-T H.323 und H.225.0 Version 2, außer MRQ (Modem Dial Out Request/Modem-Auswahl-Anfrage), MCF (Modem Dial Out Confirm/Modem-Auswahl-Bestätigung), MRJ (Modem Dial Out Reject/Modem-Auswahl-Ablehnung) und MIP (Modem Dial Out In Progress/Modem-Auswahl-In-Durchführung), welche durch die vorliegende Erfindung vorgeschlagen werden, ausgetauscht durch die Benutzung von „Non Standard Data" der „Non Standard Message" von H.225.0 RAS. Zusätzlich wurde eine Datenstruktur vorgeschlagen. definiert durch „Modem GW Info" benutzt in „Terminal Type" in der konventionellen RRQ Nachricht.
MRQ ist eine Nachricht, welche von dem Gatekeeper an den Remote Access Server gesendet wird, wenn der Gatekeeper ARQ von einem ersten Terminal empfängt, welches eine Verbindung mit einem zweiten Terminal, welches nicht in dem Gatekeeper registriert ist aber welches durch den Remote Access Server verbunden werden soll, anfragt. Die MRQ Nachricht beinhaltet die Telefonnummer „destAlias" des zweiten Terminals sowie das Zeitlimit „timeToWait" für das Warten auf eine Antwort auf die MRQ Nachricht ('in seconds', d.h. Angabe in Sekunden).
MCF ist eine Nachricht für das Benachrichtigen des Gatekeepers, dass der Remote Access Server eine PPP Verbindung mit dem zweiten Terminal hergestellt und eine IP Adresse zugewiesen hat in Erwiderung auf die MRQ Nachricht. Die zugewiesene IP Adresse kann „DestRasAddress" beinhaltet sein.
MRJ ist eine Nachricht für das Benachrichtigen des Gatekeepers, dass der Remote Access Server eine Verbindung mit dem zweiten Terminal in Erwiderung auf die MRQ Nachricht nicht herstellen kann. Der Zurückweisungsgrund ist in „Reject Reason" beinhaltet.
MIP ist eine Nachricht für das Benachrichtigen des Gatekeepers, dass der Remote Access Server dabei ist, eine Verbindung mit dem zweiten Terminal herzustellen, wenn dieser eine Nachricht als Antwort auf MRQ nicht bis „timeToWait" senden kann.
In Bezug auf 5 senden das Terminal A in dem IP Netzwerk und der Remote Access Server RRQ Nachrichten, um deren Aliase und IP Adressen jeweils in den Schritten 60-1 und 60-2 zu registrieren. In diesem Fall bestimmt der Remote Access Server „terminal-Type" für den Gateway in der RRQ Nachricht. Der Gateway ist definiert durch eine Datenstruktur „GatewayInfo", deren „Non Standard Data" für das Bekanntmachen dieser Information benutzt wird. „nonStandardData" ist definiert durch eine Struktur „nonStan dardParameter", welche aus „nonStandardIdentifier" und Daten besteht. „nonStandardIdentifier" ist definiert durch eine Struktur „nonStandardIdentifier", welche aus einem Objekt oder „h221NonStandard" besteht. Das Objekt wird benutzt, um den Objektbezeichner des Remote Access Servers zu bestimmen. Die Daten von „Non Standard Parameter" beinhalten eine Struktur „ModemGWInfo", wie in Tabelle 1 gezeigt. Die anderen Felder der RRQ Nachricht sind dieselben wie in den anderen Terminals.
Danach, wenn der Gatekeeper eine RCF Nachricht für das Benachrichtigen des Terminal A und des Remote Access Servers über die vollständige Registrierung jeweils in den Schritten 60-1 und 60-2 sendet, sendet das Terminal A eine ARQ Nachricht an den Gatekeeper, um mit dem Terminal B zu kommunizieren in Schritt 60-3. Wenn der Gatekeeper den Alias des Terminal B, welcher in der ARQ Nachricht enthalten ist, feststellt, sendet der Gatekeeper in Schritt 60-4 eine MRQ Nachricht an den Remote Access Server, so dass der Remote Access Server versucht eine Einwahl-PPP-Verbindung mit dem Terminal B in Schritt 60-6 zu machen. In diesem Fall, wenn es keinen verfügbaren Port gibt ('no available port') oder das Terminal B aktiv ('destination is busy') ist, sendet der Remote Access Server eine MRJ Nachricht an den Gatekeeper in Schritt 60-7. Wenn der Remote Access Server versucht eine PPP-Verbindung mit dem Terminal B zu machen, sendet dieser eine MIP Nachricht an den Gatekeeper in dem Zeitintervall, welches in der MRQ Nachricht angegeben ist, in Schritt 60-5. Wenn der Remote Access Server die PPP Verbindung mit dem Zuweisen der IP Adressen fertig stellt, sendet der Remote Access Server eine MCF Nachricht an den Gatekeeper in Schritt 60-7.
Danach, während der Gatekeeper auf die Registrierung des Terminal B wartet, sendet das Terminal B eine GRQ Nachricht (Gatekeeper Request/Gatekeeper Anfrage), um den Gatekeeper um die Registrierung zu ersuchen. Wenn das Terminal B eine GCF Nachricht (Gatekeeper Confirm/Gatekeeper Bestätigung) von dem Gatekeeper in Schritt 60-8 empfängt, sendet das Terminal B eine RRQ Nachricht an den Gatekeeper, um den Alias und IP Adresse zu registrieren. Dann sendet der Gatekeeper eine RCF Nachricht, um die Registrierung des Terminal B in Schritt 60-9 zu bestätigen.
Dann sendet der Gatekeeper ACF an das Terminal A, um die Kommunikation zuzulassen, in Schritt 60-10. Der danach folgende Nachrichtenfluss entspricht mit der Spezifikation H.323. Nämlich, wie in 5 gezeigt, wenn das Terminal A, eine ACF Nachricht empfangend, die Q931 Einrichtungsnachricht sendet für die Ruf-Signalisierung an das Terminal B in Schritt 60-11, sendet das Terminal B ARQ Nachricht an den Gatekeeper für das Empfangen einer Kommunikationserlaubnis in Schritt 60-12. Wenn das Terminal B eine ACF Nachricht von dem Gatekeeper in Schritt 60-13 empfängt, sendet das Terminal B eine Q931 Verbindungsnachricht an das Terminal A in Schritt 60-14. Endlich, beim Durchführen von H.245 Rufsignalisierungen, ist die Kommunikation in Schritt 60-15 eingerichtet. Die Beendigung der Kommunikation erfolgt, wie in der Spezifikation H.323 definiert.
Daher bietet die Erfindung Mittel an für das Befähigen, dass das H.323 Terminal in dem IP Netzwerk eine Kommunikation mit einem Terminal in einem PSTN oder ISDN, welches derzeitig nicht mit dem Remote Access Server verbunden ist, durch den Austausch von Steuerungsnachrichten zwischen dem Gatekeeper und dem Remote Access Server wie gewünscht herstellen kann. Zusätzlich gebraucht das erfinderische Verfahren die herkömmliche H.225.0 RAS Nachricht gemäß dem internationalen Standard, wobei Kompatibilität mit dem herkömmlichen Kommunikationssystem gewährleistet wird. Des Weiteren kann ein Terminal in einem PSTN oder ISDN angerufen werden von einem Terminal in einem IP Netzwerk, selbst wenn dieses „Off-Line" mit dem Remote Access Server ist, und spart deshalb die Kosten, welche benötigt würden, wenn die Online-Verbindung mit dem Remote Access Server aufrecht erhalten würde.

Claims

Ein Verfahren für das Befähigen eines ersten Terminals, über einen Remote Access Server mit einem zweiten Terminal zu kommunizieren, besagtes erstes Terminal und besagter Remote Access Server kommunizieren miteinander mittels eines paketbasierten Netzwerkes und besagtes zweites Terminal greift auf besagten Remote Access Server zu, beinhaltend die Schritte: Registrieren (60-1, 60-2) der Aliase und IP-Adressen von besagten ersten Terminal und Remote Access Server in einem Gatekeeper; Senden (60-3) einer Nachricht von besagtem ersten Terminal zu besagtem Gatekeeper zum Anfordern einer Verbindung mit besagtem zweiten Terminal; Bewirken, dass besagter Gatekeeper anfordert (60-4), dass besagter Remote Access Server sich mit besagtem zweiten Terminal verbindet, selbst wenn dieses nicht in besagtem Gatekeeper registriert ist; Senden einer Nachricht durch besagten Remote Access Server (60-5, 60-7) zu besagtem Gatekeeper für das Benachrichtigen des besagten Gatekeepers, dass (a) der Remote Access Server keine Verbindung mit dem zweiten Terminal herstellen kann; oder (b) der Remote Access Server eine Verbindung mit dem zweiten Terminal hergestellt hat und eine IP-Adresse zugewiesen hat; oder (c) der Remote Access Server dabei ist, eine Verbindung mit dem zweiten Terminal herzustellen; In dem Fall, dass eine Verbindung zwischen besagtem Remote Access Server und besagtem zweiten Terminal hergestellt ist, Bewirken, dass besagter Remote Access Server anfordert (60-6), dass besagtes zweites Terminal seinen Alias und IP-Adresse in besagtem Gatekeeper registriert (60-8); und Aufbauen (60-11 bis 60-15) einer Kommunikation zwischen besagten ersten und zweiten Terminals durch besagten Gatekeeper.
Das Verfahren gemäß Anspruch 1, wobei das Anfordern, dass sich besagter Remote Access Server mit dem zweiten Terminal verbindet, das Senden einer Nachricht, welche die Telefonnummer des besagten zweiten Terminals und einen Antwortzeitgrenzwert zu besagtem Remote Access Server beinhaltet, beinhaltet.
Das Verfahren gemäß der Ansprüche 1 oder 2, wobei der Schritt, dass besagter Remote Access Server anfordert, dass besagtes zweites Terminal sich registriert, die Schritte beinhaltet: besagter Remote Access Server versucht sich mit dem zweiten Terminal zu verbinden, Benachrichtigen des besagten Gatekeepers, dass kein Port verfügbar oder dass besagtes zweites Terminal beschäftigt ist, Benachrichtigen des Gatekeepers über die IP-Adresse, die dem zweiten Terminal, wel ches verbunden ist, zugewiesen ist, Zulassen, dass besagtes zweites Terminal seinen Alias und IP-Adresse in besagtem Gatekeeper registriert, und Veranlassen, dass besagter Gatekeeper die Registrierung des besagten zweiten Terminals zulässt.