EP1436965A2 - Verkehrssteuerung eines kommunikationsnetzes mit einem cluster von verkehrsstromsteuerungen mit gemeinsamer registrierungsdatenbasis - Google Patents

Verkehrssteuerung eines kommunikationsnetzes mit einem cluster von verkehrsstromsteuerungen mit gemeinsamer registrierungsdatenbasis

Info

Publication number
EP1436965A2
EP1436965A2 EP02776840A EP02776840A EP1436965A2 EP 1436965 A2 EP1436965 A2 EP 1436965A2 EP 02776840 A EP02776840 A EP 02776840A EP 02776840 A EP02776840 A EP 02776840A EP 1436965 A2 EP1436965 A2 EP 1436965A2
Authority
EP
European Patent Office
Prior art keywords
cluster
traffic flow
end point
traffic
gatekeeper
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02776840A
Other languages
English (en)
French (fr)
Inventor
Peter Leis
Rainer Liebhart
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Nokia Siemens Networks GmbH and Co KG, Siemens Corp filed Critical Siemens AG
Publication of EP1436965A2 publication Critical patent/EP1436965A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1043Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/15Flow control; Congestion control in relation to multipoint traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1106Call signalling protocols; H.323 and related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols

Definitions

  • the ITU-T standard H.323 defines a protocol family for the standardized control of services in multimedia packet networks (in particular IP networks), i.e. of networks in which a plurality of different services can be transmitted. These services, which are implemented in a unified, multimedia environment, are also called 'multimedia applications'.
  • multimedia application includes both services and ordinary telephony
  • VoIP Key 'Voice over IP
  • VoIP video on demand
  • the essential network components of the packet-oriented H.323 are endpoints (units that want to use applications such as a PC client), gateways (GW) for the transition to the line-oriented telephone network, multipoint control units (MCU) for controlling conferences and gatekeepers (GK ).
  • a gatekeeper controls access to the IP network for all H.323 network components (endpoints, GW, MCU) that belong to its zone.
  • the following functions are assigned to a GK:
  • the gatekeepers of a cluster jointly serve a registration zone and share the control traffic volume.
  • the end points of this zone know at least one primary GK and mostly one secondary GK.
  • the other existing GK of the cluster are generally not directly visible to them, even if this is generally not excluded.
  • an endpoint within its gatekeeper cluster has registered with its primary GK using the H.323 message RRQ (Registration Request). If the primary GK is not available, the endpoint registers with its secondary GK (standard procedure in H.323).
  • the RRQ message is part of the so-called RAS messages (RAS - Registration, Administration and Status). So that the endpoint can now also be reached via any other GK of the cluster with which other endpoints or gateways have registered, the registration data of an endpoint is e.g. sent to all gatekeepers of the gatekeeper cluster at regular intervals using UDP multicast.
  • the deregistration - also called 'deregistration' - of an end point with a GK
  • the other GK of the cluster are informed about it using the same method. This ensures that all gatekeepers in a cluster have identical registration databases.
  • the GK of a GK cluster advantageously form its own multicast group, so that the multicast messages do not burden the other hosts of the LAN segment in which the gatekeepers of the cluster are located.
  • the additional network load for exchanging the registration data is limited by the use of multicast messages, since the gatekeepers of a cluster form a well-defined, self-contained multicast group.
  • registration and der- registration messages are not sent as often as signaling messages for connection establishment and disconnection.
  • a nice advantage of the identical registration databases is that gateways, endpoints, MCUn or gatekeepers of other zones do not have to know which GK of the cluster a particular endpoint they want to reach is registered with.
  • a gateway connects to a GK with which the desired end point has not registered, this GK also has the IP address (and possibly security data) of the end point and can establish a connection directly to the end point (so-called ' direct routed call model 'of the H.323 standard).
  • the H.323 RAS connection thus exists to a gatekeeper of the cluster, while the connection signaling does not run via a gatekeeper or at least not via this gatekeeper, but via another gatekeeper of the cluster.
  • the desired end point is registered with the GK, which is also to establish the connection, the connection is set up according to the 'gatekeeper routed call model'. Connections from the end point to a destination, on the other hand, always run via the primary GK with which the end point is registered.
  • the endpoints monitor the gatekeeper with which they have registered via periodically sent H.323 RRQ messages which the GK has to answer. If the gatekeeper does not acknowledge the RRQ message, the endpoint tries to register with another gatekeeper known to it. This can be a so-called secondary GK, for example. Even if all GK known to an end point have failed, it can still be reached by the other GK of the cluster, since these too have saved the profile of the end point (which in particular contains the IP address of the end point). An "intelligent" endpoint can also learn the IP addresses of other gatekeepers, by capturing their IP address during a call and then registering with them if necessary (with the aim of not only being available, but also being able to establish connections again).
  • the invention is thus a solution which ensures the individual accessibility of the subscribers at a very low cost and at the same time enables GK zones to be scaled to increasing numbers of subscribers without great effort by simply installing additional GK servers in a zone which is in line with the traffic volume automatically share this zone with each other.
  • FIG. 2 shows a connection setup in the arrangement according to FIG. 1.
  • FIG. 1 shows the registration process for an H.323 end point, which is designed as an H.323 client EP, and an H.323 end point, which is designed as an H.323 gateway GW.
  • the H.323 client EP registers with its primary gatekeeper GKi, the gateway GW with its primary gatekeeper GK 2 in accordance with the RAS (Registration, Admission and Status) protocol.
  • the registration of the client EP is stored in the registration database DBi of the gatekeeper GKi, that of the gateway GW in the registration database DB 2 of the gatekeeper GK 2 .
  • the gatekeepers GKi and GK 2 form a gatekeeper cluster CL according to the invention.
  • the registration data are exchanged, for example in a common LAN (Local Area Network) segment, between GKi and GK 2 in accordance with an exchange protocol DBEX, which is preferably implemented as a multicast MC.
  • DBEX Exchange Protocol
  • the registration of the H.323 client EP with the gatekeeper GK 2 and that of the gateway GW with gatekeeper GK ⁇ are thus known.
  • the data of all registered endpoints EP, MG are available to each of the gatekeepers (eg IP address, crypto token for the secure transmission of messages, etc.), which provides a common registration database.
  • FIG. 2 shows the connection establishment from the gateway GW to the H.323 client EP. Since the gateway is registered with GK 2, it sends RAS messages to this gatekeeper. A subsequent connection establishment request from the gateway GW to the client EP is then communicated to the gatekeeper GK 2 in accordance with the gatekeeper routed model GRM. Since this GK 2 also knows the registration database DBi of the gatekeeper GKi and thus also has the registration data of the H.323 client EP, it knows that the client EP is online and can signal the signaling messages from the gateway directly, ie according to the direct routed call model DRM, forward to the client EP. The client EP is in turn registered with GKi, so it will use RAS to inquire whether it can accept connections from gatekeeper GK 2 . Since gatekeeper GKi is the registration database DB 2 of gatekeeper GK 2 of cluster CL Knows according to the invention, gatekeeper GKi can send the client EP a positive confirmation on its request.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Traffic Control Systems (AREA)

Abstract

Ein Cluster CL von Verkehrsstromsteuerungen GK umfasstMittel DB1, DB2, DBEX zur Realisierung einer gemeinsamen Registrierungsdatenbasis. Mithilfe dieser Mittel DB1, DB2, DBEX werden bei den Verkehrsstromssteuerungen GK des Clusters CL auftretende registrierungsrelevante Ereignisse erfasst. Diese und/oder ihre Folgen werden sodann an die anderen Verkehrsstromsteuerungen GK des Clusters CL mitgeteilt.

Description

Beschreibung
Verkehrssteuerung eines Kommunikationsnetzes mit einem Cluster von Verkehrsstromsteuerungen mit gemeinsamer Registrierungsdatenbasis
Der ITU-T Standard H.323 definiert eine Protokollfamilie zur vereinheitlichten Steuerung von Diensten in multimedialen Paketnetzen (insbesondere IP Netze) , d.h. von Netzen, in denen eine Mehrzahl von unterschiedlichen Diensten übermittelt werden kann. Diese in einer vereinheitlichten, multimedialen Umgebung realisierten Dienste werden auch 'Multimediaanwendungen' genannt. Unter den Begriff Multimediaanwendung fallen dabei sowohl Dienste wie gewöhnliche Telephonie
(Stichwort 'Voice over IP (VoIP) ' ) , als auch Dienste wie Fax, Telephonkonferenz, Videokonferenz, Video on Demand (VoD) und ähnliches mehr.
Die wesentlichen Netzkomponenten des paketorientierten H.323 sind Endpunkte (Einheiten, die Anwendungen nutzen möchten wie z.B. ein PC Client), Gateways (GW) für den Übergang in das leitungsorientierte Telephonnetz, Multipoint Control Units (MCU) zur Steuerung von Konferenzen und Gatekeeper (GK) .
Ein Gatekeeper steuert dabei den Zugang in das IP Netz für alle H.323 Netzkomponenten (Endpunkte, GW, MCU), die seiner Zone angehören. Einem GK sind folgende Funktionen zugeordnet:
1) Admission Control (Netzzugangskontrolle)
2) Call Authorization (Authentifizierung einzelner Verbindungen)
3) Address Translation (Umwandlung der Wahlinformation in IP Adressen) 4) Call Control Signalling (Steuerung des Verbindungsauf- und -abbaus, sowie der Teilnehmerfeatures)
5) GK Communication (Kommunikation mit den GK anderer Zonen)
Bei Ausfall des Gatekeepers stehen die oben genannten Funkti¬ onen und in der Folge auch die eingangs genannten Dienste für die Endpunkte der GK Zone nicht mehr zur Verfügung. Dies bedeutet, dass insbesondere der Sprachdienst, basierend auf H.323, nicht mehr verfügbar ist. Die Endpunkte können also weder selbst Verbindungen aufbauen, noch können sie von anderen Teilnehmern (aus dem IP-Netz oder dem gewöhnlichen Telephonnetz) erreicht werden. Da die telephonische Erreichbarkeit für einen Teilnehmer aber hohe Priorität genießt, ist für carriergrade VoIP die Verfügbarkeit des Dienstes ausnehmend wichtig.
Bisher kann die Verfügbarkeit eines GK nur durch hochverfügbare und teure Geräte sichergestellt werden. Da aber solche Maschinen ausfallen können, sind die Ausfalleinheiten möglichst gering zu halten, d.h. die H.323 Zone, die ein Gatekeeper bedient, besteht aus weniger Endpunkten und Gateways, als der GK eigentlich steuern könnte. Dies ist nachteilig hinsichtlich der vorhandenen Ressourcen und der getätigten Investitionen, weil sie nicht im vollen Umfang ihres Leistungsvermögens genutzt werden.
Es ist Aufgabe der Erfindung, einen Weg aufzuzeigen, wie zumindest die Verfügbarkeit des VoIP Dienstes für H.323 End- punkte sichergestellt werden kann, ohne hochverfügbare und teure GK Server installieren zu müssen.
Es wird vorgeschlagen, mehrere Gatekeeper zu einem 'Gatekeeper Cluster' mit gemeinsamer Registrierungsdatenbasis zusam- men zu fassen. Die Gatekeeper eines Clusters bedienen dabei gemeinsam eine Registrierungszone und teilen sich die Steue- rung des anfallenden Verkehrsaufkommens.
Indem die Registrierungsdaten zwischen den vorzugsweise physikalisch getrennten Gatekeepern ausgetauscht wird, erübrigt sich die Installation teurer, hoch verfügbarer Server.
Die Endpunkte dieser Zone kennen zumindest einen primary GK sowie zumeist einen secondary GK. Die übrigen vorhandenen GK des Clusters sind für sie im allgemeinen nicht direkt sicht- bar, auch wenn dies grundsätzlich nicht ausgeschlossen wird.
Bisher registriert sich ein Endpunkt innerhalb seines Gatekeeper Clusters bei seinem primary GK mittels der H.323 Nachricht RRQ (Registration Request) . Falls der primary GK nicht verfügbar ist, registriert sich der Endpunkt bei seinem secondary GK (Standardverfahren in H.323). Die RRQ-Nachricht ist Teil der sog. RAS-Nachrichten (RAS - Registration, Admis- sion and Status). Damit nun der Endpunkt auch über einen beliebigen anderen GK des Clusters erreichbar ist, bei dem sich andere Endpunkte oder Gateways angemeldet haben, werden bei der vorliegenden Lösung die Registrierungsdaten eines Endpunkte z.B. mittels UDP Multicast an alle Gatekeeper des Gatekeeper Clusters in periodischen Abständen versendet. Im umgekehrten Fall, d.h. der Abmeldung - auch ' Deregistrierung' genannt - eines Endpunkts bei einem GK, werden die anderen GK des Cluster über die gleiche Methode darüber informiert. Dadurch wird erreicht, dass alle Gatekeeper eines Clusters identische Registrierungsdatenbanken aufweisen.
Die GK eines GK Cluster bilden vorteilhaft eine eigene Multi- castgruppe, so daß die Multicastnachrichten nicht die übrigen Hosts des LAN-Segments, in dem sich die Gatekeeper des Cluster befinden, belasten. Die zusätzliche Netzlast zum Austausch der Registrierungsdaten wird durch die Verwendung von Multicastnachrichten begrenzt, da die Gatekeeper eines Clusters eine wohldefinierte, in sich geschlossene Multi- castgruppe bilden. Zudem werden Registrierungs- und Dere- gistrierungsnachrichten nicht so häufig gesendet werden wie etwa Signalisierungsnachrichten für den Verbindungsauf- und abbau.
Eine schöner Vorteil der identischen Registrierungsdatenbanken liegt darin, dass Gateways, Endpunkte, MCUn oder Gatekeeper anderer Zonen nicht wissen müssen, bei welchem GK des Clusters ein bestimmter Endpunkt, den sie erreichen wollen, angemeldet ist.
Baut z.B. ein Gateway eine Verbindung zu einem GK auf, bei dem sich der gewünschte Endpunkt nicht angemeldet hat, so verfügt dieser GK ebenfalls über die IP-Adresse (und eventuell Securitydaten) des Endpunkte und kann direkt eine Verbin- düng zum Endpunkt aufbauen (sog. 'direct routed call model ' des H.323 Standard). Die H.323 RAS Verbindung besteht also zu einem Gatekeeper des Clusters, während die Verbindungssigna- lisierung nicht über einen Gatekeeper oder zumindest nicht über diesen Gatekeeper, sondern über einen anderen Gatekeeper des Clusters läuft. Wenn der gewünschte Endpunkt dagegen bei dem GK angemeldet ist, der auch den Verbindungsaufbau durchführen soll, wird die Verbindung gemäß dem 'Gatekeeper routed call model' aufgebaut. Verbindungen vom Endpunkt zu einem Ziel laufen dagegen zunächst immer über den primary GK, bei dem der Endpunkt registriert ist.
Die Endpunkte überwachen den Gatekeeper, bei dem sie sich registriert haben, über periodisch gesendete H.323 RRQ Nachrichten, die der GK zu beantworten hat. Quittiert der Gate- keeper die RRQ Nachricht nicht, versucht der Endpunkt sich bei einem anderen ihm bekannten Gatekeeper anzumelden. Dies kann z.B. ein sog. secondary GK sein. Selbst wenn alle einem Endpunkt bekannten GK ausgefallen sind, ist dieser noch durch die übrigen GK des Clusters erreichbar, da auch diese das Profil des Endpunkte gespeichert haben (das insbesondere die IP Adresse des Endpunkte enthält) . Ein "intelligenter" Endpunkt kann somit auch IP Adressen weiterer Gatekeeper lernen, indem er deren IP Adresse bei einem Anruf erfasst, und sich anschließend bei diesen gegebenenfalls registrieren (mit dem Ziel, nicht nur erreichbar zu sein, sondern auch selbst wieder Verbindungen aufbauen zu können) .
Vorteilhaft ist es möglich, eine H.323 Zone einfach zu vergrößern, indem zusätzlich GK-Server in das Cluster aufgenommen werden. Diese zusätzlichen GK können nun als Teil der Multicastgruppe Verbindungen zu allen Endpunkte aufbauen, die bei irgendeinem der GK des Clusters registriert sind. Neu in die Zone hinzukommende Endpunkte oder Endpunkte, die bereits Teil der Zone sind, können sich dann bei den zusätzlichen GK registrieren.
Mit der hier vorgestellten Methode kann die Auslastung aller eingesetzten GK Server optimiert werden, was zu einer optimalen Verwendung der getätigten Investitionen führt. Die Erfindung ist somit eine Lösung, die sehr kostengünstig die individuelle Erreichbarkeit der Teilnehmer sicherstellt und dabei zugleich ermöglicht, GK Zonen ohne großen Aufwand auf wachsende Teilnehmerzahlen zu skalieren, indem auf einfache Weise zusätzliche GK Server in einer Zone installiert werden, die sich das Verkehrsaufkommen in dieser Zone automatisch untereinander teilen.
Weitere Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt. Es zeigt hierbei:
Figur 1 eine Anordnung zur Durchführung des erfindungsgemä- ßen Verfahrens, die ein Cluster CL mit zwei Gate- keepern GKi, GK2 sowie einen Client EP und einen Gateway GW umfasst,
Figur 2 einen Verbindungsaufbau in der Anordnung nach Fi- gur 1. Figur 1 zeigt den Registrierungsvorgang für einen H.323 Endpunkt, der als H.323 Client EP ausgebildet ist, und einen H.323 Endpunkt, der als H.323 Gateway GW ausgebildet ist. Der H.323 Client EP meldet sich bei seinem primary Gatekeeper GKi, das Gateway GW bei seinem primary Gatekeeper GK2 gemäß dem RAS (Registration, Admission and Status) Protokoll an. Die Registrierung des Clients EP wird in der Registrierungsdatenbasis DBi des Gatekeepers GKi, die des Gateways GW in der Registrierungsdatenbasis DB2 des Gatekeepers GK2 hinter- legt. Die Gatekeeper GKi und GK2 bilden ein erfindungsgemäßes Gatekeeper Cluster CL. Die Registrierungsdaten werden, z.B. in einem gemeinsamen LAN (Local Area Network) Segment, zwischen GKi und GK2 gemäß einem Austauschprotokoll DBEX, das vorzugsweise als Multicast MC realisiert ist, ausgetauscht. Damit ist die Registrierung des H.323 Clients EP auch beim Gatekeeper GK2 und die des Gateways GW bei Gatekeeper GKα bekannt. Jedem der Gatekeeper stehen die Daten aller registrierten Endpunkte EP, MG zur Verfügung (z.B. IP Adresse, Crypto Token für die sichere Übertragung von Nachrichten, etc.), wodurch eine gemeinsame Registrierungsdatenbasis gegeben ist.
Figur 2 zeigt den Verbindungsaufbau vom Gateway GW zum H.323 Client EP. Da das Gateway bei GK 2 registriert ist, sendet es RAS Nachrichten zu diesem Gatekeeper. Ein nachfolgender Verbindungsaufbauwunsch des Gateway GW zu dem Client EP wird sodann dem Gatekeeper GK2 gemäß dem Gatekeeper routed model GRM mitgeteilt. Da dieser GK2 erfindungsgemäß auch die Registrierungsdatenbasis DBi des Gatekeepers GKi kennt und so- mit auch über die Registrierungsdaten des H.323 Client EP verfügt, weiß er, dass der Client EP online ist und kann die Signalisierungsnachrichten vom Gateway direkt, d.h. gemäß dem direct routed call model DRM, an den Client EP weitersenden. Der Client EP ist seinerseits bei GKi registriert, wird also dort mittels RAS Nachrichten nachfragen, ob er von Gatekeeper GK2 Verbindungen annehmen darf. Da Gatekeeper GKi die Registrierungsdatenbasis DB2 des Gatekeepers GK2 des Cluster CL erfindungsgemäß kennt, kann Gatekeeper GKi dem Client EP eine positive Bestätigung auf seine Anfrage zurücksenden.
Es sei betont, dass die Beschreibung der für die Erfindung relevanten Komponenten grundsätzlich nicht einschränkend zu verstehen ist. Für einen einschlägigen Fachmann ist insbesondere offensichtlich, dass Begriffe wie 'Endpunkt', 'Gateway' oder 'Gatekeeper' funktional und nicht physikalisch zu verstehen sind. Somit können sie beispielsweise auch teilweise oder vollständig in Software und/oder über mehrere physikalische Einrichtungen verteilt realisiert werden.

Claims

Patentansprüche
1. Verfahren zur Steuerung des Verkehrs eines Netzes mit zumindest einem Cluster (CL) von zumindest zwei Verkehrsstromsteuerungen (GK) , mit folgenden Schritten:
- Auftreten zumindest eines steuerungsrelevanten Ereignisses bei einer Verkehrsstromssteuerung des Clusters, - Mitteilung des Ereignisses und/oder seiner Folgen an die anderen VerkehrsStromsteuerungen des Clusters,
- Steuerung des Verkehrs durch zumindest eine der Verkehrsstromsteuerungen des Clusters.
2. Verfahren nach Anspruch 1, bei dem das Ereignis als Registrierung oder Deregistrierung eines Endpunktes (EP, GW) ausgebildet ist.
3. Verfahren nach dem vorstehenden Anspruch, bei dem von dem Endpunkt im Falle einer Nachricht von einer dem Endpunkt bis dahin unbekannten Verkehrsstromsteuerung dessen Adresse gespeichert wird.
4. Verfahren nach dem vorstehenden Anspruch, bei dem sich der Endpunkt bei der bis dahin unbekannten Verkehrsstromsteuerung registriert.
5. Verfahren nach dem vorstehenden Anspruch, bei dem sich der Endpunkt dann registriert, wenn die zumin- dest eine Verkehrsstromsteuerung, bei der er bereits registriert ist, nicht mehr erreichbar ist.
6. Verfahren nach einem der vorstehenden Ansprüche, bei dem die Verkehrsstromsteuerungen physikalisch getrennt realisiert sind.
7. Verfahren nach dem vorstehenden Anspruch, bei dem jeder Verkehrsstromsteuerung eine individuelle Registrierungsdatenbank (DB) zugeordnet ist.
8. Verfahren nach einem der vorstehenden Ansprüche, bei dem das Ereignis den anderen Verkehrsstromsteuerungen des Clusters mit Hilfe von Nachrichten (DBEX) mitgeteilt wird.
9. Verfahren nach dem vorstehenden Anspruch, bei dem die Nachrichten als Multicast (MC) Nachrichten ausgebildet sind, wobei das Cluster so konfiguriert ist, dass die Multicast Nachrichten nur von den Verkehrsstromsteuerungen des Clusters empfangen werden.
10. Computerprogrammprodukt, umfassend Softwarecodeabschnitte, mit denen ein Verfahren nach einem der vorstehenden Verfahrensansprüche durch zumindest einen Prozessor ausgeführt wird.
11. Einrichtung, insbesondere Verkehrsstromsteuerung (GK) , Gateway (GW) oder Endpunkt (EP) , umfassend zumindest ein Mittel zur Durchführung eines Verfahrens nach einem der vorstehenden Verfahrensansprüche.
12. Cluster (CL) von Verkehrsstromsteuerungen (GK) , umfassend zumindest ein Mittel zur Durchführung eines Verfahrens nach einem der vorstehenden Verfahrensansprüche.
13. Cluster (CL) nach dem vorstehenden Anspruch, umfassend zumindest ein Mittel (DBX, DB2, DBEX (MC) ) zur Realisierung einer gemeinsamen Registrierungsdatenbasis.
14. Anordnung, insbesondere Netz, umfassend zumindest ein Computerprogrammprodukt und/oder eine Einrichtung und/oder ein Cluster nach den vorstehenden Ansprüchen.
EP02776840A 2001-10-18 2002-10-17 Verkehrssteuerung eines kommunikationsnetzes mit einem cluster von verkehrsstromsteuerungen mit gemeinsamer registrierungsdatenbasis Withdrawn EP1436965A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10151443 2001-10-18
DE10151443A DE10151443A1 (de) 2001-10-18 2001-10-18 Cluster von Verkehrsstromsteuerungen mit gemeinsamer Registrierungsdatenbasis
PCT/DE2002/003936 WO2003036868A2 (de) 2001-10-18 2002-10-17 Verkehrssteuerung eines kommunikationsnetzes mit einem cluster von verkehrsstromsteuerungen mit gemeinsamer registrierungsdatenbasis

Publications (1)

Publication Number Publication Date
EP1436965A2 true EP1436965A2 (de) 2004-07-14

Family

ID=7702921

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02776840A Withdrawn EP1436965A2 (de) 2001-10-18 2002-10-17 Verkehrssteuerung eines kommunikationsnetzes mit einem cluster von verkehrsstromsteuerungen mit gemeinsamer registrierungsdatenbasis

Country Status (5)

Country Link
US (1) US20050021820A1 (de)
EP (1) EP1436965A2 (de)
AU (1) AU2002339376A1 (de)
DE (1) DE10151443A1 (de)
WO (1) WO2003036868A2 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7363381B2 (en) * 2003-01-09 2008-04-22 Level 3 Communications, Llc Routing calls through a network

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6205211B1 (en) * 1998-08-04 2001-03-20 Transnexus, Llc Internet telephony call pricing center
US6965591B1 (en) * 1998-09-14 2005-11-15 At&T Corp. System and method for gatekeeper-to-gatekeeper communication
US6229804B1 (en) * 1998-11-17 2001-05-08 3Com Corporation Gatekeeper election methods for internet telephony
US6667968B1 (en) * 1998-12-03 2003-12-23 Telefonaktiebolaget L M Ericsson (Publ) System and method for providing multiple endpoints in a device disposed in a packet-switched network
US6519249B1 (en) * 1998-12-23 2003-02-11 Nortel Networks Ltd Scalable gatekeepers in an internet telephony system and a method of operation
NO310800B1 (no) * 1999-02-09 2001-08-27 Ericsson Telefon Ab L M Anordning for distribusjon og befordring av trafikk i et nett, spesielt H.323 generert trafikk
GB9903125D0 (en) * 1999-02-11 1999-04-07 Nokia Telecommunications Oy Handover in a mobile communication system
US6785223B1 (en) * 1999-04-22 2004-08-31 Siemens Information And Communication Networks, Inc. System and method for restarting of signaling entities in H.323-based realtime communication networks
US6751652B1 (en) * 1999-06-29 2004-06-15 Transnexus, Inc. Intelligent end user devices for clearinghouse services in an internet telephony system
US7099301B1 (en) * 1999-07-13 2006-08-29 Innomedia, Inc. Voice over internet protocol proxy gateway
NO314608B1 (no) * 1999-10-04 2003-04-14 Ericsson Telefon Ab L M Fremgangsmåte for ruting av anrop
US7203956B2 (en) * 1999-12-22 2007-04-10 Transnexus, Inc. System and method for the secure enrollment of devices with a clearinghouse server for internet telephony and multimedia communications
DE10004811A1 (de) * 2000-02-04 2001-08-09 Ericsson Telefon Ab L M Kommunikationssystem, Verfahren und Steuereinrichtung zum Leiten von Anrufen innerhalb von privaten Netzen, die über geographische beabstandete Zonen verteilt sind
US7218722B1 (en) * 2000-12-18 2007-05-15 Westell Technologies, Inc. System and method for providing call management services in a virtual private network using voice or video over internet protocol
US7197567B1 (en) * 2002-02-28 2007-03-27 Cisco Technology, Inc. Devices, softwares and methods for enabling SIP devices to operate in H.323 networks and H.323 devices to operate in sip networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03036868A2 *

Also Published As

Publication number Publication date
DE10151443A1 (de) 2003-05-08
WO2003036868A2 (de) 2003-05-01
US20050021820A1 (en) 2005-01-27
AU2002339376A1 (en) 2003-05-06
WO2003036868A3 (de) 2003-11-27

Similar Documents

Publication Publication Date Title
DE10245330B4 (de) Softwareschalter der verteilte Firewalls für eine Lastteilung von Internet-Telefonie-Verkehr in einem IP-Netz verwendet
DE60014234T2 (de) System und Verfahren zum Ermöglichen von Fehlertolerante Systeme
DE69923856T2 (de) Verfahren und vorrichtung zur wirkungsgradverbesserung des verbindungsaufbaues im multimedia- kommunikationssystem
EP1211878B1 (de) Verfahren und Vorrichtung zur Anrufumleitung mittels eines Stellvertreter in einem Kommunikationssystem
DE102006039170B4 (de) Verfahren zum Anbieten eines Call Center-Dienstes in einem Peer-to-Peer-Netzwerk
EP1318654A2 (de) Anordnung zur Steuerung und/oder Überwachung von mindestens zwei Kommunikationssystemen durch mindestens eine Anwendung
DE10329084A1 (de) Verfahren und Anordnung zum Zugriff auf ein erstes Endgerät eines ersten Kommunikationsnetzwerkes durch einen Kommunikationsknoten in einem zweiten Kommunikationsnetzwerk
EP2469885B1 (de) Verfahren zur Integration von Funktionen eines Telekommunikationsnetzes in ein Datennetz
EP1418729B1 (de) Verfahren und Anordnungen zur Kommunikation zwischen einem leitungsvermittelten Kommunikationsnetz und mehreren VoIP-Netzwerkdomänen
DE10316236A1 (de) Verfahren und Anordnung zur Konfiguration einer Einrichtung in einem Datennetz
EP1436965A2 (de) Verkehrssteuerung eines kommunikationsnetzes mit einem cluster von verkehrsstromsteuerungen mit gemeinsamer registrierungsdatenbasis
EP1255384A1 (de) Verfahren zur Übertragung von Verbindungskonfigurationen aus dem Telefonnetz in ein Datennetz
EP2469822B1 (de) Computer-Telephonie-Integration mit Anbindung der Computer über einen Presence-Server
DE10254904B3 (de) Betriebsmodus für ein Kommunikationssystem
EP1661363B1 (de) Verfahren zur unterstuetzung des name delivery leistungsmerkmales fuer gemischte tdm netze/sip centrex kommunikations- architekturen
EP1313301A1 (de) Multimediales Kommunikationssystem mit aktivierbaren Zusatzdiensten während einer Konferenz
DE10345017A1 (de) Verfahren und Vorrichtung zur Adressierbarkeit von Personen für Sprachkommunikation hinter beliebigen verbindungsorientierten Anschlussarten
WO2006048317A2 (de) VERFAHREN UND SYSTEM ZUR IDENTIFIZIERUNG EINES TEILNEHMERS UND DES BENUTZTEN ANSCHLUSSES BEI VoIP VERBINDUNGEN
WO2007036403A1 (de) Abwesenheitsassistenzsystem für multimediafähige kommunikationssysteme
WO2005020536A1 (de) Kommunikationsserververbund für rechnernetze
EP1154656A2 (de) Dienst-Einheit
DE102006043233B4 (de) Verfahren zum Anbieten von Centrex-Leistungsmerkmalen in einem Peer-to-Peer-Netzwerk
WO2003039096A1 (de) Functionsplit für einheiten zur netzsteuerung
EP3959850A1 (de) Verfahren zum bereitstellen von verbindungsherstellungsdaten sowie anordnung mit einer mehrzahl von kommunikationsservern und einem vermittler
WO2009132672A1 (de) Kommunikationssystem sowie kommunikationsendgerät und übergabestelle für den einsatz in dem kommunikationssystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040218

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20050317

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APBV Interlocutory revision of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNIRAPE

17Q First examination report despatched

Effective date: 20050317

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20070626

18R Application refused

Effective date: 20060312