Bereitstellung von redundanten SIP Proxy Ressourcen

Die Erfindung betrifft ein Verfahren zur Adressauflösung der Adresse eines SIP-Proxys in einem SIP Netzwerkes mit Bereitstellung von redundanten SIP-Proxy-Ressourcen und einen SIP- Proxy-Server sowie ein Serversystem, welche für die Durchführung eines derartigen Verfahrens ausgestaltet sind.

Eine der wichtigsten gegenwärtigen Entwicklungen der Kommunikationsnetze betrifft die Weiterentwicklung von herkömmlichen Datennetzen - deren wichtigster Repräsentant die so genannten IP-Netze sind - für die Bereitstellung von Echtzeitdiensten, wie zum Beispiel die Übertragung von Sprache, Video- und Audioinformationen. Für das wichtigste Datennetz, das auf dem IP- (Internet-Protocol) Protokoll basierende Internet gibt es derzeit im Wesentlichen zwei wichtige alternativ einsetzbare Protokolle für die Verbindungsherstellung für Echtzeitüber- tragungsdienste . Diese Protokolle sind das H.323 und das SIP- (Session Initiation Protocol) Protokoll. Das SIP-Protokoll wurde zuerst in dem RFC 2543 der IETF (Internet Engineering Task Force) niedergelegt. Im Folgenden sollen einige für das Verständnis der Erfindung wesentliche Elemente des SIP- Protokolls beschrieben werden.

Bei einem Verbindungsaufbau mittels des SIP-Protokolls spielen folgende wichtige Bestandteile eines SIP-Netzwerkes eine zentrale Rolle. Endgeräte oder Endpunkte eines SIP-Netzes werden als User-Agents bezeichnet. Diese User-Agents umfassen üblicherweise einen SIP-Client, der Anfragen (Requests) an einen Server stellen kann. Wichtig für das Funktionieren von SIP sind auch die so genannten DNS-Server (DNS: Domain Name System), welche für die Adressauflösung benötigt werden. Von zentraler Bedeutung sind daneben die so genannten SIP-

Proxies, oder SIP-Proxy-Server, welche SIP-Anfragen von einem User-Agent erhalten und diese zu einem anderen Ort weiterlei-

ten. Daneben gibt es auch so genannte Registrar Server, welche SIP-Registrierungsanforderungen entgegennehmen können und die Information über User-Agents in so genannten Lokalisierungsservern oder anderen Datenbanken auffrischen können.

Eine sehr wichtige Rolle spielt in SIP-Netzen die Adressauflösung. Durch das SIP-Protokoll bereitgestellten Funktionen der Adressauflösung wird innerhalb von SIP-Netzen ein hoher Grad von Mobilität und Portabilität erreicht. Eine typische Adressauflösung und die Rolle eines SIP-Proxies werden dabei im Folgenden an Hand der Figur 1 näher dargestellt. In diesem Bild soll von einem ersten SIP-Endgerät User-Agent 1 ein anderer SIP-Teilnehmer User-Agent 2 kontaktiert werden. Die Adresse des anderen Endgerät User-Agent 2 liegt dem User-Agent 1 in Form einer SIP-Adresse vor, beispielsweise SIP:

UsorBjjthere . com. Um diese Adresse aufzulösen, muss der User- Agent zunächst einen geeigneten SIP-Proxy für diese Aufgabe identifizieren. Er richtet eine Anfrage (SRV Query oder SRV SER Query) an einen DNS-Server (Schritt 1) . In dieser Anfrage soll der für die threre . com-Domäne zuständige SIP-Proxy-

Server lokalisiert werden, das heißt die entsprechende Internetadresse gefunden werden. Im zweiten Schritt sendet dann der DNS-Server dem User-Agent 1 die Internet-Adresse des zu verwendenden SIP-Proxies (SRV-Record oder DNS-SRV-Record) . Im Schritt 3 kann mit dieser Adresse dann das Endgerät User- Agent 1 eine Aufforderung (SIP-Request) an den SIP-Proxy bzw. Proxy-Server zur Auflösung der Adresse des B-seitigten Endgeräts User-Agent 2 richten. Diese Aufforderung bestätigt der SIP-Proxy in Schritt 4 durch die Nachricht 100 trying. In Schritt 5 richtet der SIP-Proxy eine Anfrage an einen Lokalisierungsdienst (Location Service) , welcher die derzeit aktuelle Registrierungs-URL (Universal Resource Locator) für den User-Agent 2 ermittelt und in Schritt 6 (Response) zurückschickt. In Schritt 7 stellt der SIP-Proxy eine Anfrage an einen Domain-Name-Server (Enum-Query) , um die den momentan registrierten Aufenthaltsort des User-Agent 2 entsprechende IP-Adresse zu erhalten. Diese wird in Schritt 8 (NAPTR-

Record: DNS Naming Authority Pointer Resource Record; wird für ENUM Telefonnurtimerzuordnung verwendet) geliefert. Die IP- Adresse wird in Schritt 9 (SIP-Request) verwendet, um schließlich den User-Agent 2 zu kontaktieren, welcher darauf- hin eine Bestätigung zurücksendet (Schritt 10: 200 okay) .

Diese Bestätigung wird dann an den User-Agent 1 weitergegeben (Schritt 11) .

Der in Figur 1 dargestellte Verbindungsaufbau ist stark ver- einfacht. In vielen Fällen sind mehr als ein SIP-Proxy Server bei einem Verbindungsaufbau beteiligt. Zudem wird die Adressauflösung in der Regel auch nicht durch einen einzelnen Domänen-Server vorgenommen, sondern durch ein (häufig hierarchisches) Server-System. Dabei gibt es beispielsweise die Mög- lichkeit, dass ein erster DNS-Server einen kommerziellen

(Server) Dienst zum Aufsuchen von der IP-Adresse verwendet, wie er zum Beispiel DynDNS gegeben ist. An Hand der Figur 1 wird klar, dass der SIP-Proxy Server eine zentrale Rolle spielt. Um eine hohe Verfügbarkeit des SIP-Netzes zu gewähr- leisten, muss für Redundanz bzw. Ausfallsicherheit der SIP-

Proxy-Ressourcen gesorgt werden. Ziel ist dabei eine dem herkömmlichen Telefonnetz PSTN (public switched telephone net- work) vergleichbare Ausfallsicherheit.

Für die Herstellung von Ausfallsicherheit bei SIP-Proxy-

Ressourcen in einem SIP-Netz gibt es verschiedene Ansätze. Zwei Ansätze bzw. zwei Konzepte sind in Figur 2 skizziert. Bei dem ersten Konzept besorgt sich der User-Agent eine neue bzw. eine alternative IP-Adresse, wenn der Kontakt zum SIP- Proxy nicht herstellbar ist (Schritte 3 und 4 in Figur 1) .

Dies kann beispielsweise dadurch realisiert sein, dass in dem User-Agent die Funktion der Anfrage nach einer Adresse für einen Back-up-Proxy-Server bzw. einen Ersatz-Proxy-Server für die jeweilige Domäne (in Figur 1: there.com) vorgesehen ist. In diesem Fall kann der User-Agent die Schritte 1 und 2 noch einmal wiederholen und erhält dann vom DNS-Server eine alternative IP-Adresse. Eine andere Möglichkeit im Rahmen des ers-

ten Konzeptes ist die Ausnutzung von vom Protokoll (üblicherweise routinemäßig) bereitgestellten Informationen im so genannten DNS-SER-Record (Schritt 2 von Figur 1) . Diese Berichte (Records) liefern Adressen von nahe gelegenen SIP-Proxies, welche SIP-Pakete akzeptieren. Den mittels Bericht bekannt gegebenen SIP-Proxies sind Gewichte bzw. Prioritäten zugeordnet. An Hand dieser Informationen über SIP-Proxies kann die Adresse eines anderen, alternativen SIP-Proxies ausgewählt werden. Die erste dieser beiden Möglichkeiten hat den Nach- teil, dass sie praktisch zu einer Doppelung der SIP-Proxies führt, was eine sehr ressourcenintensive Weise zur Herstellung von Redundanz ist. Die zweite Vorgehensweise hat den Nachteil, dass der User-Agent in der Lage sein muss, SER-SRV- Records zu analysieren und auszuwerten, das heißt, er muss mit erheblichen zusätzlichen Funktionalitäten ausgestattet werden.

Der zweite Ansatz bzw. das zweite Konzept besteht darin, durch eine dynamische Zuordnung der verwendeten IP-Adresse für Redundanz zu sorgen. Beispielsweise wird eine Lastverteilung vorgenommen, die Anfragen bzw. Requests, die an dieselbe IP-Adresse geschickt wurden, auf verschiedene SIP-Proxy- Server verteilt (Load Balancer) . Eine andere Möglichkeit ist die Anwendung des in dem RFC 2338 beschriebene Virtual Router Redundancy Protocol (VRRP) . In diesem Fall ist ein Paar von SIP-Proxy-Servern vorgesehen, wobei durch das VRRP Protokoll dafür gesorgt wird, dass bei einem Ausfall der jeweilige Ersatzserver die Bearbeitung von Anfragen übernimmt. Diese Ü- bernahme wird üblicherweise mit Hilfe eines VRRP-Dämons (VRRPD) bewerkstelligt. Die letzte Realisierung hat wiederum den Nachteil einer Doppelung, das heißt einer wenig effizienten Verwendung der Ressourcen. Die Verwendung von Lastverteilung hat eine Schwachstelle bei der Lastverteilung selber, die als nicht gedoppelte Komponente ein gewisses Störungsri- siko birgt (single failure point) .

Die Erfindung hat zur Aufgabe, eine Adressauflösung in einem SIP-Netz unter effizienter und aufwandsarmer Bereitstellung von SIP-Proxy-Redundanz anzugeben, wobei die Nachteile herkömmlicher Konzepte vermieden werden sollen.

Die Aufgabe wird durch die Gegenstände der unabhängigen Ansprüche gelöst.

Der zentrale Gedanke der Erfindung ist, Redundanz bei SIP- Proxy-Ressourcen herzustellen, indem die SIP-Proxy-Ressourcen in Form einer Peer-to-Peer-Gruppe von SIP-Proxy-Servern bereitgestellt werden. Das Peer-to-Peer-Konzept erlaubt in effizienter Weise, die zur Verfügung stehenden SIP-Proxy-Server für Vermittlungsdienste einzusetzen. Zur besseren Nachvoll- ziehbarkeit der Wirkung und der Vorteile der Redundanzbereitstellung mittels einer Peer-to-Peer-Gruppe von SIP-Proxy- Servern werden im Folgenden kurz einige allgemeine Aspekte von Peer-to-Peer-Kommunikation vorgestellt.

Peer-to-Peer-Netzwerke sind ein aktuelles Gebiet vieler Entwicklungsanstrengungen, weshalb bereits ein Vielfalt von Protokollen und Konzepten für ihre Nutzung existieren. Bezüglich der Architektur von Peer-to-Peer-Netzwerken unterscheidet man in der Regel drei verschiedene Typen. Die ersten Peer-to- Peer-Netzwerke waren zentral konzipiert. Es gab eine zentrale Datenquelle, aus der Knoten des Peer-to-Peer-Netzes Anfragen stellen konnte, um herauszufinden, in welchen der anderen Knoten die gewünschten Informationen bzw. Daten vorgehalten wurden. Ein Beispiel für eine derartige Peer-to-Peer- Netzstruktur ist Napster. Da die zentral strukturierten Peer- to-Peer-Netzwerke nicht gut skalieren und zudem das Risiko des Ausfalls der zentralen Stelle bergen, wurden andere Architekturen entwickelt. Ein zweiter Typ sind die dezentralen, aber strukturierten Peer-to-Peer-Netzwerke. Bei mit Struktur ist dabei gemeint, dass eine das Netzwerk überziehende Topo- logie gegeben ist. Durch die Topologie sollen Informationen leichter aufzufinden sein. Je nachdem, wie stark die Vorgaben

durch die Topologie sind, kann man graduell zwischen locker strukturierten bis hoch strukturierten Netzen differenzieren. Ein dritter Typus sind die dezentralen und unstrukturierten Peer-to-Peer-Netze, bei denen die Topologie ebenfalls weg- fällt. Für eine Anfrage zum Auffinden einer Information bzw. von Daten kontaktiert dann ein Knoten eines Peer-to-Peer- Netzwerkes seinen Nachbarn. Eine typische Anfrage kann beispielsweise darin bestehen, eine Anfragenachricht zu fluten, wobei die Anfrage an alle Nachbarn innerhalb eines bestimmten Radius übertragen wird. Die vorliegende Erfindung wird vorzugsweise mit strukturierten Peer-to-Peer Netzen realisiert. Diese lassen sich mittels DHT-basierter Verfahren (z.B. Chord, Pastry, Kademlia) besonders effizient und performant gestalten, was Replikationsgrad und Suchdauer angeht.

Informationen können in Peer-to-Peer-Netzwerken redundant vorgehalten werden (das heißt, dass Kopien oder Replikas vorhanden sind) . Daten oder Informationen können so in verteilter Form über eine Vielzahl von Knoten des Peer-to-Peer- Netzwerkes verteilt vorgehalten werden, wobei für eine höhere Ausfallsicherheit wenigstens zwei Kopien jeder Informationseinheit auf verschiedenen Knoten bereitgestellt werden. Je nach Typus des Peer-to-Peer-Netzwerkes können der Ort für die Speicherung von Informationen und die Häufigkeit der Kopien für eine möglichst effiziente Anfrage optimiert werden. Eine verbreitete und effiziente Abfragemethode für verteilt vorgehaltene Informationen ist durch das so genannte Distributed Hash Table (DHT) System gegeben.

Erfindungsgemäß werden SIP-Proxy-Ressourcen als (beispielsweise dezentrale und unstrukturierte) Peer-to-Peer-Gruppe von SIP-Proxy-Servern bereitgestellt. Diese Peer-to-Peer-Gruppe ist z.B. für die Endgeräte einer oder mehrerer SIP-Domänen zuständig, d.h. diese Endgeräte greifen für einen Verbin- dungsaufbau auf einen dieser SIP-Proxy-Server zu. Mehrere Peer-to-Peer-Gruppen können zusammen ein Peer-to-Peer Netz bilden. Informationen bzgl. der Zuständigkeit für Endgeräte

(SIP-Clients) einer SIP-Domäne und Funktionen der SIP-Proxy- Server können repliziert und in Kopie abgespeichert werden. Man verwendet den Begriff Replikationsgruppe (replication group) für eine Gruppe von Peers, auf denen Informationen und Kopien der Informationen in verteilter Form gespeichert sind. Eine erfindungsgemäße Peer-to-Peer Gruppe kann muss aber nicht einer Replikationsgruppe entsprechen. So kann beispielsweise ein Teil einer Peer-to-Peer Gruppe eine Replikationsgruppe darstellen oder auch eine Replikationsgruppe Peers von mehr als einer Peer-to-Peer Gruppe umfassen.

Die redundanten SIP-Proxy-Ressourcen können beispielsweise für einen Verbindungsaufbau über einen SIP-Proxy verwendet werden. Für einen Zugriff auf diese Ressourcen wird eine IP- Adresse (IP: Internet Protocol) einem SIP-Clients z.B. auf Anfrage an ein DNS-Server-System verfügbar gemacht. Dieses DNS (Domain Name Server) Server-System kann beispielsweise aus einem einzelnen Server bestehen. In der Regel wird es jedoch aus mehreren eventuell hierarchisch geordneten Servern konstituiert sein, wobei beispielsweise vorgesehen ist, dass ein DNS-Server auf einen Domain-Name-Server-Dienst zugreift. Diesem DNS-Server-System wird z.B. für den Zugriff auf SIP- Proxy-Ressourcen der Peer-to-Peer-Gruppe durch externe SIP- Proxy-Server eine zu benützende IP-Adresse bereitgestellt. Dabei können IP-Adressen regelmäßig durch die SIP-Proxy-

Server-Gruppe dem DNS-Server-System bekannt gemacht werden. Alternativ erfolgt eine Abfrage einer solchen IP-Adresse durch das DNS-Server-System auf eine Anfrage hin. Für die Weitergabe einer zu verwendenden IP-Adresse werden innerhalb der Peer-to-Peer-Gruppe Zuständigkeiten für SIP-Domänen oder einzelne User-Agent-Adressen festgelegt. Dabei kann es sich bei den SIP-Domänen um jeweils die SIP-Domäne des anfragenden SIP-Clients bzw. User-Agents oder aber auch die SIP-Domäne des bei einem Verbindungsaufbau zu kontaktierenden User-

Agents handeln. Durch die Verwendung von Peer-to-Peer- Protokollen für die Festlegung von Zuständigkeiten bzw. den Austausch von Informationen über Zuständigkeiten kann dynamisch und adaptiv eine Zuordnung von SIP-Proxy-Server zu SIP- Domäne auf zuverlässige Weise realisiert werden. Es kann flexibel auf Änderungen bzw. Einflüsse reagiert werden. Beispielsweise bei Hinzukommen eines neuen SIP-Proxy-Servers, bei Ausfall oder Ausschalten eines SIP-Proxy-Servers oder bei Änderung des zur Verfügung stehenden IP-Adress-Pools können erforderliche Maßnahmen mittels Peer-to-Peer-Protokollen kommuniziert bzw. umgesetzt werden. Dabei kann die Peer-to-Peer Gruppe auch zumindest einen Registrar Server umfassen, wodurch gewährleistet wird, dass Informationen, die durch Registrierung durch diesem Registrar Server erfasst werden, durch Peer-to-Peer Protokolle weitergegeben bzw. verfügbar gemacht werden können. Vorzugsweise sind die SIP-Proxy-Server der Peer-to-Peer-Gruppe zugleich Registrar Server. Registrar und Proxy verschmelzen dann innerhalb eines Peer-to-Peer- Netzes zu einer Instanz. Man könnte dann dies so beschreiben, dass das Peer-to-Peer-Netz aus generischen Servern besteht, die sowohl die SIP Proxy als auch die SIP Registrar Funktion beherrschen. Eine Reaktion auf einen Einfluss kann auch eine Anpassung oder Änderung einer oder mehrerer Replikationsgrup- pen beinhalten. Beispielsweise kann eine Replikationsgruppe auf SIP-Proxy-Server einer SIP-Proxy-Server-Gruppe ausgedehnt werden, bei der zuvor kein Server Teil der Replikationsgruppe war. Eine Replikationsgruppe kann auch auf SIP-Proxy-Server ausgedehnt werden, die zu einer anderen Replikationsgruppe oder zu keiner Replikationsgruppe gehören.

Das Konzept ist flexibel hinsichtlich der Einbeziehung neuer SIP-Proxys oder der Umstrukturierung vorhandener SIP-Proxy- Ressourcen. Es kann z.B. eine dynamische Ausweitung der Domä-

nen-Zuständigkeit auf Peers erfolgen, die z.B. noch keiner Domäne zugehören oder die in einer anderen Domäne entbehrlich sind. Diese dynamische Ausweitung kann durch das P2P Protokoll erfolgen und folgt Randbedingungen wie z.B. dem Replika- tionsgrad innerhalb einer für eine SIP Domäne zuständigen

Gruppe. Was den Replikationsgrad angeht, so kann dieser durch einen min. und max. Wert definiert sein. Eine für eine Domäne zuständige Anzahl von Peers kann dann durch den Bedarf einer anderen Domäne solange reduziert werden, bis ein min. Repli- kationsgrad erreicht ist. Die Redundanz ist dann sozusagen über die ganzen Domänen verteilt und nicht zu einer Domäne fest zugeordnet.

Es ist sinnvoll, das Funktionieren der SIP-Proxy-Server in- nerhalb der Peer-to-Peer-Gruppe regelmäßig durch Abfragenachrichten (z.B. sogenannte Hello-Nachrichten) zu überprüfen. So kann der Ausfall eines Servers festgestellt werden und als Reaktion daraufhin die Zuständigkeiten für die entsprechenden SIP-Domänen neu vergeben werden. Bei regelmäßigem Überprüfen entspräche dann eine Zuordnung von SIP-Domäne zu SIP-Proxy- Server einem Soft-State, der bei Nichtbestätigung eliminiert wird.

Die Erfindung umfasst auch einen SIP-Proxy-Server und ein Serversystem mit einer Vielzahl von SIP-Proxy-Servern, welche für eine erfindungsgemäße Redundanzbereitstellung durch die Organisation von SIP-Proxy-Servern and Peer-to-Peer Gruppe ausgestaltet bzw. angepasst sind. Beispielsweise werden Protokollmittel vorgesehen, damit eine Kommunikation innerhalb der Peer-to-Peer Gruppe mit Peer-to-Peer Protokollen sowie eine Kommunikation mit einem DNS Serversystem erfolgen kann. Ebenso werden Mittel für eine verteilte Speicherung von In-

formationen in den Servern der Peer-to-Peer Gruppe angeordnet .

Gemäß einer Weiterbildung werden für eine SIP-Domäne eine erste und eine zweite Zuständigkeit innerhalb der Peer-to- Peer-Gruppe definiert. Bei Ausfall des SIP-Proxy-Servers mit der ersten Zuständigkeit kann dann auf den mit der zweiten Zuständigkeit zurückgegriffen werden, um schnell und effizient Ersatz bereitzustellen. Man kann dann einen weiteren SIP-Proxy-Server die erste Zuständigkeit übertragen, wodurch man eine neue Back-up-Situation kreiert (Rollover fall back) ,

Wie sich erste und zweite Zuständigkeit durch den SIP-Proxy für eine schnelle Bereitstellung von Back-up SIP-Proxy- Ressourcen heranziehen lassen, ist im Folgenden im Rahmen eines Ausführungsbeispiels dargestellt. Ein zweites Ausführungsbeispiel zeigt eine Adressauflösung für verschiedene Konstellationen .

Es zeigen

Figur 1 einen typischen Verbindungsaufbau mittels des SIP- Protokolls .

Figur 2 herkömmliche Methoden zur Herstellung von Ausfallsicherheit bezüglich der SIP-Proxy-Ressourcen.

Figur 3 ein Netzszenario, bei der ein Endgerät als User- Agent für die Verwendung des SIP-Protokolls zur Herstellung einer Verbindung ausgestaltet ist.

Figur 4 eine erfindungsgemäße Namensauflösung innerhalb eines Peer-to-Peer Netzes .

Figur 5 eine erfindungsgemäße Namensauflösung für einen abgehenden Ruf

Figur 6 eine erfindungsgemäße Namensauflösung für einen ankommenden Ruf

Figur 7 eine erfindungsgemäße Funktionsübernahme bei Ausfall eines SIP-Proxy-Servers .

In Fig. 3 hat ein SIP-Telefon (welches als User-Agent fungiert) SIP-TEL statisch zwei SIP-Adressen von SIP-Proxy- Servern, ProxyPeerl und ProxyPeer2 einkonfiguriert. Zur Ad- ressauflösung der ersten konfigurierten SIP-Proxy-Server-

Adresse ProxyPeerl kontaktiert das Endgerät SIP-TEL mittels einer SRV-Query Nachricht das DNS-Server-System DynDNS . Das DNS-Server-System DynDNS verfügt über eine Zuordnung von SIP- Proxy-Adressen zu IP-Adressen. Diese Zuordnung bzw. Adresszu- Ordnungstabelle wird regelmäßig durch die für den Verbindungsaufbau zur Verfügung stehenden SIP-Proxy-Server-Gruppe an das DNS-Server-System DynDNS kommuniziert. Die SIP-Proxy- Server-Gruppe umfasst die Proxy-Server Z_ProxyPeerl, Z ProxyPeer2 und Z ProxyPeerl'. Dabei haben die Proxy-Server Z_ProxyPeerl, Z_ProxyPeer2 und Z_ProxyPeerl ' jeweils eine Zuständigkeit für SIP Adressen (z.B. SIP-Proxy-Server Z_ProxyPeerl die Zuständigkeit für die Adresse ProxyPeerl und SIP-Proxy-Server Z ProxyPeer2 die Zuständigkeit für die Adresse ProxyPeer2). Die SIP-Proxy-Server sind als Peer-to- Peer-Server-System organisiert und teilen dem DNS-Server- System DynDNS jeweils die aktuellen Zuordnungen von SIP- Proxy-Adressen zu IP-Adresse mit, z.B. die IP-Adresse von dem SIP-Proxy-Server Z_ProxyPeerl als der SIP-Proxy-Adresse ProxyPeerl zugeordnet und die IP-Adresse von dem SIP-Proxy- Server Z_ProxyPeer2 als der SIP-Proxy-Adresse ProxyPeer2 zugeordnet. Eine Änderung der Zuständigkeiten von SIP-Proxy- Servern lässt sich dann einfach als neue Zuordnung einer IP- Adresse zu einer SIP-Proxy-Adresse an das DNS-Serversystem DynDNS kommunizieren.

Aktuell sind in dem DNS-Server-System DynDNS den SIP-Proxy- Adressen ProxyPeerl und ProxyPeer2 die IP-Adressen der Proxy-

Server Z ProxyPeerl und Z ProxyPeer2 zugeordnet. Bei Ausfall eines Servers, beispielsweise des SIP-Proxy-Servers Z ProxyPeerl wird dieses durch die Peer-to-Peer-Gruppe erkannt. Beispielsweise wird dann die IP-Adresse des Proxy- Peer-Servers ProxyPeerl ' dem Server-System DynDNS als die der SIP-Proxy-Adresse ProxyPeerl zugeordnete IP-Adresse mitgeteilt (Wechesel der Zuständigkeit) . Dann bekäme der User- Agent SIP-TEL bei der Auflösung der Adresse ProxyPeerl die IP-Adresse von Z ProxyPeerl', so dass er über diesen Proxy- Server den Dienst, zum Beispiel Verbindungsaufbau, initiieren kann. Bei Ausfall eines Servers, beispielsweise des Servers Z_ProxyPeerl, der zu einer vergeblichen Kontaktaufnahme durch den User-Agent SIP-TEL führt, kann die Ersatzadresse Proxy- Peer2 verwendet werden. Beispielsweise hat der User-Agent SIP-TEL auf seinen Adressauflösungsanforderung hin die IP- Adresse von dem Proxy-Server Z_ProxyPeerl erhalten. Der Verbindungsaufbau (mittels eines SIP-Requests) zu diesem SIP- Proxy-Server Z_ProxyPeerl schlägt jedoch fehl, weil dieser gerade ausgefallen ist, das heißt die Bestätigungsnachricht 100 Trying wird durch den User-Agent SIP-TEL nicht empfangen. Dann kann dieser nach einer Zeit (beispielsweise nach Ablauf eines Timers) eine Anfrage (SRV-Query) an das DNS-Server- System DynDNS zur Auflösung der SIP-Proxy-Adresse ProxyPeer2 stellen, worauf das DNS-Server-System DynDNS die IP-Adresse des SIP-Proxy-Servers Z ProxyPeer2 zurückgibt, so dass das Endgerät SIP-TEL über den SIP-Proxy-Server Z_ProxyPeer2 den Verbindungsaufbau realisieren kann.

Wie aus dem obigen Ausführungsbeispiel deutlich wird, erlaubt die Erfindung eine dynamische und flexible Bereitstellung von Proxy-Ressourcen, welche ihre Vorteile daraus schöpft, dass die SIP-Proxy-Server als Peer-to-Peer-Gruppe organisiert sind. Die Ausnützung der Eigenschaften des als Peer-to-Peer- Netzwerk organisierten SIP-Proxy-Systems ist nicht auf den dargestellten Ausführungsfall beschränkt. Beispielsweise könnte auch in dem DNS-Server-System DynDNS eine Zuordnung von einer SIP-Proxy-Adresse oder einer SIP-Domäne (die mitzu-

teilende IP-Adresse bestimmt sich dann daraus, welcher SIP- Domäne die Adresse des User Agent SIP-TEL zugehört) zu zwei IP-Adressen (einer regulären Adresse und einer Ersatzadresse) gegeben sein. Das DNS-Server-System DynDNS könnte sich zum Beispiel Anfragen durch User-Agents merken und bei einer zweiten, in kurzem Abstand auf eine erste Anfrage erfolgenden Anfrage die jeweils andere IP-Adresse bzw. Ersatzadresse zurückgeben.

Die Vorteile des erfinderischen Konzepts bei der Namensauflösung und der Bereitstellung von Redundanz werden im Folgenden auch anhand der Fig. 4 bis Fig. 7 illustriert. Fig. 4 bis Fig. 7 zeigen ein Peer-to-Peer-Netz, welches durch die als Kreise dargestellten SIP-Proxy-Server gebildet wird. Dabei werden durch das Peer-to-Peer-Netz redundante SIP-Proxy-

Ressourcen für die drei SIP-Domänen there, before und after bereitgestellt. Die als offene Kreise dargestellten SIP- Proxy-Server haben die Zuständigkeit für die SIP-Domäne there, die grau ausgefüllten Kreise haben die Zuständigkeit für die SIP-Domäne before und die schwarz ausgefüllten Kreise haben die Zuständigkeit für die SIP-Domäne after. Es wird angenommen, dass die den SIP-Domänen zugehörigen Endgeräte entsprechend des Anfangsbuchstabens des Namens indiziert und SIP-Proxy-Servern zwecks Speicherung der für die Kontaktie- rung relevanten Informationen (Ort, IP-Adresse, .. ) SIP- Proxy-Servern zugeordnet sind. Dabei übernimmt wie in Fig. 4 gezeigt der SIP-Proxy-Server 1 jeweils die Speicherung der Informationen für die Anfangsbuchstaben a bis f. Der SIP- Proxy-Server 2 für die Domäne there übernimmt die Speicherung der Informationen für die Anfangsbuchstaben g bis k und der SIP-Proxy-Server 3 für die Domäne there die Speicherung der Informationen für die Anfangsbuchstaben 1 bis o. Auf diese Weise werden die Informationen für alle angeschlossenen Endgeräte über die für die jeweilige SIP-Domäne zuständigen SIP- Proxy-Server gespeichert. Zu jeder dieser gespeicherten Information gibt es eine Kopie die jeweils auf einem anderen SIP-Proxy-Server abgelegt ist. Beispielsweise speichert der

SIP-Proxy-Server 1 für die Domäne there die Informationen für die Anfangsbuchstaben x bis z der Endgeräte der Domäne befo- re, der SIP-Proxy-Server 2 für die Domäne there die Informationen für die Anfangsbuchstaben a bis f der Endgeräte der Domäne there (d.h. repliziert die Informationen auf SIP- Proxy-Server 1 für die Domäne there), etc. Die Replikation der Informationen ist innerhalb des ringförmig ausgestalteten Peer-to-Peer-Netzes so vorgenommen, dass für jeden SIP-Proxy- Server jeweils ein benachbarter SIP-Proxy-Server die repli- zierten Informationen speichert. Alternativ wäre denkbar, die replizierten Informationen so abzuspeichern, dass keine replizierten Informationen für eine andere SIP-Domäne abgespeichert werden (wie z.B. in Fig. 1 bei SIP-Proxy-Server 1) . Bei den für eine SIP-Domäne zuständigen SIP-Proxy-Servern über- nehmen jeweils zwei die anhand Fig. 3 schon beschriebene Rolle, d.h. ihre SIP-Adressen (ProxyPeerl und ProxyPeer2 in Fig. 3) sind bei den Endgeräten der Domäne einkonfiguriert bzw. voreingestellt. Diese Rolle oder Funktion ist in den Figuren Fig. 4 bis Fig. 7 als proxyl bzw. proxy2 bezeichnet. Diese Funktion wird für die Domäne there in den Figuren Fig. 4 bis Fig. 7 durch die SIP-Proxy-Server 1 und 2 wahrgenommen. In den Figuren Fig. 4 bis Fig. 6 werden Abläufe für verschiedene Konstellationen bei einem Gesprächsaufbau zwischen ali- ce@there und einem zweiten Endgerät gezeigt. Dabei spielt entspricht alice@there beispielsweise dem SIP-Client (SIP- Telefon) SIP-TEL aus Fig. 3.

In Fig. 4 ruft der SIP-Client alice@there das Endgerät bob@after in der SIP Domäne after (Namensauflösung innerhalb des Peer-to-Peer-Netzes) . Dazu sendet alice@there eine INVITE Nachicht zu dem SIP-Proxy-Server mit der Funktion proxyl für die Domäne there (d.h. zu dem für die Domäne there zuständigen SIP-Proxy-Server 1) . Dieser kontaktiert zur Namensauflösung den SIP-Proxy-Server mit der Funktion proxyl für die Do- mäne after (d.h. zu dem für die Domäne after zuständigen SIP- Proxy-Server 1) mittels einer LOOKUP Nachricht. In Zuge einer RESPONSE Nachricht wird die entsprechende IP-Adresse

bob@l .2.3.4 zurückgesendet. Daraufhin kann der SIP-Proxy- Server 1 der Domäne there eine INVITE Nachricht an die Adresse bob@l .2.3.4, d.h. an bob@after senden.

In Fig. 5 ruft der SIP-Client alice@there das Endgerät john@somewhere in der SIP Domäne somewhere (Namensauflösung für einen Ruf zu einem Endgerät außerhalb des Peer-to-Peer- Netzes) . Die SIP-Domäne somewhere wird nicht innerhalb des Peer-to-Peer-Netzes verwaltet. Zunächst sendet alice@there wie bei Fig. 4 eine INVITE Nachicht zu dem SIP-Proxy-Server mit der Funktion proxyl für die Domäne there. Zur Namensauflösung kontaktiert dieser SIP-Proxy-Server mit der Funktion proxyl für die Domäne there mittels einer LOOKUP Nachricht ein DNS System, um den für die Domäne somewhere zuständigen SIP-Proxy-Server zu identifizieren. Danach wird eine LOOKUP

Nachricht zu diesem für die Domäne somewhere zuständigen SIP- Proxy-Server gesendet, um die IP-Adresse von john@somewhere zu erhalten. Schließlich wird eine INVITE Nachricht and die IP-Adresse john@1.2.3.4 von john@somewhere gesendet.

In Fig. 6 ruft der SIP-Client john@somewhere das Endgerät alice@there (Namensauflösung für einen Ruf von einem Endgerät außerhalb des Peer-to-Peer-Netzes) . Der SIP-Client john@somewhere sendet zunächst eine INVITE Nachricht zu dem für die Domäne somewhere zuständigen SIP-Proxy-Server proxyl@somewhere . Dieser sendet eine LOOKUP Nachricht and eine das DNS System DynDNS, um den SIP-Proxy-Server für die Domäne there zu indentifizieren. Das DNS System DynDNS hat als für Domäne there zuständigen SIP-Proxy-Server den SIP-Proxy- Server der Domäne there mit der Funktion proxyl gespeichert. Bei diesem SIP-Proxy-Server (SIP-Proxy-Server 1) wird mittels einer LOOKUP Nachricht die IP-Adresse von alice@there erfragt. Wenn SIP-Proxy-Server 1 nicht den entsprechenden Namensbereich verwaltet, wird eine P2P LOOKUP Abfrage bei dem entsprechenden Peer gemacht. Schließlich sendet der SIP- Proxy-Server proxyl@somewhere eine INVITE Nachricht an die IP-Adresse alicc@l .2.3.4 von alice@there.

Fig. 7 zeigt die Funktionsweitergabe der Funktion proxyl bei einem Ausfall des SIP-Proxy-Servers 1 mit der Funktion proxyl der Domäne there. Bei Nichterreichbarkeit des SIP-Proxy-Servers mit der Funktion proxyl kann des Endgerät SIP-TEL den SIP-Proxy- Servers 2 mit der Funktion proxy2 für den Gesprächsaufbau verwenden. Bei einem Erkennen des Ausfalls durch die Peers werden die Zuständigkeiten des ausgefallenen SIP-Proxy- Servers neu verteilt. Im vorliegenden Fall übernimmt der SIP- Proxy-Server 3 die Funktion proxyl und der SIP-Proxy-Server 2 übernimmt die Zuständigkeit für die Endgeräte (name index a-k statt vorher g-k) . SIP-Proxy-Server 3 speichert dann die replizierten Informationen von dem SIP-Proxy-Server 1 (replica- tion a-k) .