DE102005009107B3 - Bereitstellung von redundanten SIP Proxy Ressourcen - Google Patents

Bereitstellung von redundanten SIP Proxy Ressourcen Download PDF

Info

Publication number
DE102005009107B3
DE102005009107B3 DE102005009107A DE102005009107A DE102005009107B3 DE 102005009107 B3 DE102005009107 B3 DE 102005009107B3 DE 102005009107 A DE102005009107 A DE 102005009107A DE 102005009107 A DE102005009107 A DE 102005009107A DE 102005009107 B3 DE102005009107 B3 DE 102005009107B3
Authority
DE
Germany
Prior art keywords
peer
sip
sip proxy
address
server
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.)
Expired - Fee Related
Application number
DE102005009107A
Other languages
English (en)
Inventor
Markus BÖHM
Michael Finkenzeller
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
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 filed Critical Siemens AG
Priority to DE102005009107A priority Critical patent/DE102005009107B3/de
Priority to EP06708422A priority patent/EP1856889A1/de
Priority to PCT/EP2006/060144 priority patent/WO2006092368A1/de
Priority to CNA200680006268XA priority patent/CN101129050A/zh
Priority to CA002599176A priority patent/CA2599176A1/en
Priority to US11/885,269 priority patent/US20080247381A1/en
Priority to KR1020077020790A priority patent/KR20070103772A/ko
Application granted granted Critical
Publication of DE102005009107B3 publication Critical patent/DE102005009107B3/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • 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/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1044Group management mechanisms 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1044Group management mechanisms 
    • H04L67/1048Departure or maintenance mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1061Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1065Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT] 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1087Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1093Some peer nodes performing special functions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • 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

Abstract

Die Erfindung betrifft eine Adressauflösung der Adresse eines SIP-Proxys in einem SIP-Netzwerk, wobei redundante SIP-Proxy-Ressourcen bereitgestellt werden. Für einen Verbindungsaufbau in einem SIP-Netzwerk wird typischerweise durch einen SIP-Client an ein DNS-Serversystem eine Anfrage übermittelt, um eine IP-Adresse für einen Zugriff auf SIP-Proxy-Ressourcen zu erhalten. Erfindungsgemäß sind die SIP-Proxy-Ressourcen in Form einer Mehrzahl von SIP-Proxy-Servern gegeben, wobei die SIP-Proxy-Server zu einer Peer-to-Peer-Gruppe gehören. Dabei werden mittels eines Peer-to-Peer-Protokolls innerhalb der Peer-to-Peer-Gruppe Nachrichten ausgetauscht, um Zuständigkeiten für SIP-Domänen oder User-Agent-Adressen bekannt zu geben. Innerhalb der Peer-to-Peer-Gruppe sind Zuständigkeiten definiert, die bei Störungen und ähnlichen Einflüssen angepasst werden. Die IP-Adresse des für die Anfrage des SIP-Clients zuständigen SIP-Proxy-Servers wird dem DNS-Serversystem verfügbar gemacht, so dass das DNS-Serversystem sie an den SIP-Client weitergeben kann. Die erfindungsgemäße Bereitstellung von SIP-Proxy-Ressourcen ist aufwandsarm, flexibel und erlaubt einen schnellen Zugriff auf redundante Ressourcen im Störungsfall.

Description

  • Die Erfindung betrifft ein Verfahren zur Adressauflösung der Adresse eines SIP-Proxys in einem SIP Netzwerk 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übertragungsdienste. 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. Beispiele für mittels des SIP Protokolls realisierte Kommunikationsdienste sind in den Druckschriften WO 02/097653 A1 und WO 02/102031 A2 angegeben.
  • 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 weiterleiten. 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 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:
    UserB@there.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 there.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 Telefonnummerzuordnung verwendet) geliefert. Die IP-Adresse wird in Schritt 9 (SIP-Request) verwendet, um schließlich den User-Agent 2 zu kontaktieren, welcher daraufhin eine Bestätigung zurücksendet (Schritt 10: 200 okay). Diese Bestätigung wird dann an den User-Agent 1 weitergegeben (Schritt 11).
  • Der in 1 dargestellte Verbindungsaufbau ist stark vereinfacht. 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öglichkeit, dass ein erster DNS-Server einen kommerziellen (Server) Dienst zum Aufsuchen von der IP-Adresse verwendet, wie er zum Beispiel durch DynDNS gegeben ist. An Hand der 1 wird klar, dass der SIP-Proxy Server eine zentrale Rolle spielt. Um eine hohe Verfügbarkeit des SIP-Netzes zu gewährleisten, muss für Redundanz bzw. Ausfallsicherheit der SIP-Proxy-Ressourcen gesorgt werden. Ziel ist dabei eine dem herkömmlichen Telefonnetz PSTN (public switched telephone network) 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 2 skizziert (entsprechend dem von der Firma Cisco herausgegebenen White Paper „High-Availability Solutions for SIP Enabled Voiceover-IP Networks"). 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 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 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 ersten Konzeptes ist die Ausnutzung von vom Protokoll (üblicherweise routinemäßig) bereitgestellten Informationen im so genannten DNS-SER-Record (Schritt 2 von 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 Nachteil, 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örungsrisiko birgt (single failure point).
  • Ein Redundanzkonzept zur Ausfallsicherung ist auch in der Druckschrift EP 1487186 A1 beschrieben.
  • 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 Nachvollziehbarkeit 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 Peerto-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. Mit Struktur ist dabei gemeint, dass eine das Netzwerk überziehende Topologie 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 wegfä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 Verbindungsaufbau 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 Replikationsgruppen 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 Replikationsgrad 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. Replikationsgrad 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 innerhalb 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 Informationen 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
  • 1 einen typischen Verbindungsaufbau mittels des SIP-Protokolls.
  • 2 herkömmliche Methoden zur Herstellung von Ausfallsicherheit bezüglich der SIP-Proxy-Ressourcen.
  • 3 ein Netzszenario, bei der ein Endgerät als User-Agent für die Verwendung des SIP-Protokolls zur Herstellung einer Verbindung ausgestaltet ist.
  • 4 eine erfindungsgemäße Namensauflösung innerhalb eines Peer-to-Peer Netzes.
  • 5 eine erfindungsgemäße Namensauflösung für einen abgehenden Ruf
  • 6 eine erfindungsgemäße Namensauflösung für einen ankommenden Ruf
  • 7 eine erfindungsgemäße Funktionsübernahme bei Ausfall eines SIP-Proxy-Servers.
  • In 3 hat ein SIP-Telefon (welches als User-Agent fungiert) SIP-TEL statisch zwei SIP-Adressen von SIP-Proxy-Servern, ProxyPeer1 und ProxyPeer2 einkonfiguriert. Zur Adressauflösung der ersten konfigurierten SIP-Proxy-Server-Adresse ProxyPeer1 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. Adresszuordnungstabelle 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_ProxyPeer1, Z_ProxyPeer2 und Z_ProxyPeer1'. Dabei haben die Proxy-Server Z_ProxyPeer1, Z_ProxyPeer2 und Z_ProxyPeer1' jeweils eine Zuständigkeit für SIP Adressen (z.B. SIP-Proxy-Server Z_ProxyPeer1 die Zuständigkeit für die Adresse ProxyPeer1 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_ProxyPeer1 als der SIP-Proxy-Adresse ProxyPeer1 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 ProxyPeer1 und ProxyPeer2 die IP-Adressen der Proxy-Server Z_ProxyPeer1 und Z_ProxyPeer2 zugeordnet. Bei Ausfall eines Servers, beispielsweise des SIP-Proxy-Servers Z_ProxyPeer1 wird dieses durch die Peer-to-Peer-Gruppe erkannt. Beispielsweise wird dann die IP-Adresse des Proxy- Peer-Servers ProxyPeer1' dem Server-System DynDNS als die der SIP-Proxy-Adresse ProxyPeer1 zugeordnete IP-Adresse mitgeteilt (Wechesel der Zuständigkeit). Dann bekäme der User-Agent SIP-TEL bei der Auflösung der Adresse ProxyPeer1 die IP-Adresse von Z_ProxyPeer1', so dass er über diesen Proxy-Server den Dienst, zum Beispiel Verbindungsaufbau, initiieren kann. Bei Ausfall eines Servers, beispielsweise des Servers Z_ProxyPeer1, 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ösungsanforderunq hin die IP-Adresse von dem Proxy-Server Z_ProxyPeer1 erhalten. Der Verbindungsaufbau (mittels eines SIP-Requests) zu diesem SIP-Proxy-Server Z_ProxyPeer1 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 mitzuteilende 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 4 bis 7 illustriert. 4 bis 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 Kontaktierung relevanten Informationen (Ort, IP-Adresse, ..) SIP-Proxy-Servern zugeordnet sind. Dabei übernimmt wie in 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 l 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 before, 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 replizierten 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 1 bei SIP-Proxy-Server 1). Bei den für eine SIP-Domäne zuständigen SIP-Proxy-Servern übernehmen jeweils zwei die anhand 3 schon beschriebene Rolle, d.h. ihre SIP-Adressen (ProxyPeer1 und ProxyPeer2 in 3) sind bei den Endgeräten der Domäne einkonfiguriert bzw. voreingestellt. Diese Rolle oder Funktion ist in den Figuren 4 bis 7 als proxy1 bzw. proxy2 bezeichnet. Diese Funktion wird für die Domäne there in den Figuren 4 bis 7 durch die SIP-Proxy-Server 1 und 2 wahrgenommen. In den Figuren 4 bis 6 werden Abläufe für verschiedene Konstellationen bei einem Gesprächsaufbau zwischen alice@there und einem zweiten Endgerät gezeigt. Dabei entspricht alice@there beispielsweise dem SIP-Client (SIP-Telefon) SIPTEL aus 3.
  • In 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 proxy1 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 proxy1 für die Domä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@1.2.3.4 zurückgesendet. Daraufhin kann der SIP-Proxy-Server 1 der Domäne there eine INVITE Nachricht an die Adresse bob@1.2.3.4, d.h. an bob@after senden.
  • In 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 4 eine INVITE Nachicht zu dem SIP-Proxy-Server mit der Funktion proxy1 für die Domäne there. Zur Namensauflösung kontaktiert dieser SIP-Proxy-Server mit der Funktion proxy1 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 an die IP-Adresse john@1.2.3.4 von john@somewhere gesendet.
  • In 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 proxy1@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 proxy1 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 proxy1@somewhere eine INVITE Nachricht an die IP-Adresse alice@1.2.3.4 von alice@there.
  • 7 zeigt die Funktionsweitergabe der Funktion proxy1 bei einem Ausfall des SIP-Proxy-Servers 1 mit der Funktion proxy1 der Domäne there. Bei Nichterreichbarkeit des SIP-Proxy-Servers mit der Funktion proxy1 kann des Endgerät SIP-TEL den SIP-Proxy-Server 2 mit der Funktion proxy1 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 proxy1 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 (replication a–k).

Claims (21)

  1. Verfahren zur Adressauflösung der Adresse eines SIP-Proxys in einem SIP-Netzwerk mit Bereitstellung von redundanten SIP-Proxy-Ressourcen, bei dem – durch einen SIP-Client auf SIP-Proxy-Ressourcen zugegriffen wird, und – SIP-Proxy-Ressourcen in Form einer Mehrzahl von SIP-Proxy-Servern gegeben sind, dadurch gekennzeichnet, dass – die SIP-Proxy-Server zu einer Peer-to-Peer Gruppe gehören, und – mittels eines Peer-to-Peer Protokolls innerhalb der Peerto-Peer Gruppe Nachrichten ausgetauscht werden, wodurch Zuständigkeiten für SIP-Domänen oder User-Agent-Adressen bekannt gegeben werden.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass – durch eine oder mehrere SIP-Proxy-Server ein Peer-to-Peer-Netz gegeben ist, und – bei einem Verbindungsaufbau zwischen zwei SIP-Clients, für die eine Zuständigkeit durch SIP-Proxy-Server des Peer-to-Peer-Netz gegeben ist, eine Adressauflösung innerhalb des Peer-to-Peer-Netzs vorgenommen wird.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass – durch eine oder mehrere SIP-Proxy-Server ein Peer-to-Peer-Netz gegeben ist, und – für einen Verbindungsaufbau zwischen zwei SIP-Clients, bei denen für nur einen die Zuständigkeit durch SIP-Proxy-Server des Peer-to-Peer-Netz gegeben ist, die IP Adresse eines für Anfragen zuständigen SIP-Proxy-Servers des Peer-to-Peer-Netzes einem DNS-Serversystem verfügbar gemacht wird.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – durch eine oder mehrere SIP-Proxy-Server ein Peer-to-Peer-Netz gegeben ist, und – innerhalb des Peer-to-Peer-Netzes mindestens eine Replikationsgruppe gegeben ist.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass Informationen bezüglich Zuständigkeiten von SIP-Proxy-Servern für SIP-Domänen und die jeweiligen IP Adressen in der Peerto-Peer Gruppe verteilt und redundant vorgehalten werden.
  6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Informationen bezüglich Zuständigkeiten von SIP-Proxy-Servern für SIP-Domänen und die jeweiligen IP Adressen mittels eines Distributed-Hash-Table (DHT) Verfahrens ermittelt werden.
  7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einer die Peer-to-Peer Gruppe beeinflussenden Änderung betroffene Zuständigkeiten und IP Adressen von SIP-Proxy-Servern für SIP-Domänen oder User-Agent-Adressen angepasst werden.
  8. Verfahren nach einem der Ansprüche 4 bis 7, dadurch gekennzeichnet, dass bei einer die Peer-to-Peer Gruppe beeinflussenden Änderung zumindest eine Replikationsgruppe angepasst wird.
  9. Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass die die Peer-to-Peer Gruppe beeinflussende Änderung durch das Hinzukommen eines neuen SIP-Proxy-Servers, durch den Ausfall oder das Abschalten eines SIP-Proxy-Servers der Peer-to-Peer Gruppe oder durch eine Änderung hinsichtlich des für die Peer-to-Peer Gruppe zur Verfügung stehenden Adressenpools von IP Adressen gegeben ist.
  10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Funktionieren der SIP-Proxy-Servern der Peer-to-Peer Gruppe regelmäßig durch den Austausch von Nachrichten überprüft wird.
  11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Peer-to-Peer Gruppe wenigstens einen Registrar Server umfasst.
  12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die Peer-to-Peer Server der Peer-to-Peer Gruppe ebenfalls die Funktion von Registrar Servern besitzen.
  13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein SIP-Proxy-Server für die Anfrage des SIP-Clients entweder dann zuständig ist, – wenn er die Zuständigkeit für die SIP-Domäne des SIP-Clients hat, oder – wenn er die Zuständigkeit für die SIP-Domäne eines SIP-User-Agents hat, zu welchem mittels der SIP-Proxy-Ressourcen eine Verbindung herzustellen ist.
  14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – entweder für die Bereitstellung der IP Adresse eines für die Anfrage des SIP-Clients zuständigen SIP-Proxy-Servers ein DNS-Serversystem eine Anfrage an die Peer-to-Peer Gruppe richtet, oder – Informationen bezüglich IP Adressen von SIP-Proxy-Servern und bezüglich Zuordnungen dieser IP Adressen regelmäßig durch die Peer-to-Peer Gruppe dem DNS-Serversystem übermittelt werden.
  15. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – der SIP-Client über wenigstens eine SIP-Adresse für den Zugriff auf SIP-Proxy-Ressourcen verfügt, und – durch den SIP-Client an ein DNS-Serversystem eine Anfrage übermittelt wird, um eine der SIP-Adresse zugeordnete IP Adresse für einen Zugriff auf SIP-Proxy-Ressourcen zu erhalten.
  16. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass innerhalb der Peer-to-Peer Gruppe für SIP-Domänen oder User-Agent-Adressen jeweils eine erste und eine zweite Zuständigkeit festgelegt werden.
  17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass für SIP-Domänen jeweils ein erster und ein zweiter SIP-Proxy-Server entsprechend der ersten und zweiten Zuständigkeit für die Adressauflösung festgelegt werden, und bei entdecktem Ausfall oder bei festgestellter Nichterreichbarkeit des ersten SIP-Proxy-Servers auf den zweiten zurückgegriffen wird.
  18. Verfahren nach Anspruch 16 oder 17, dadurch gekennzeichnet, dass – der SIP-Client über eine erste und eine zweite SIP Adresse für den Zugriff auf SIP-Proxy-Ressourcen verfügt, und – bei erfolgloser Verwendung einer der ersten SIP-Adresse korrespondierenden IP Adresse durch den SIP-Client an das DNS-Serversystem die Anfrage übermittelt wird, um eine der zweiten SIP Adresse zugeordnete IP Adresse für einen Zugriff auf SIP-Proxy-Ressourcen zu erhalten.
  19. Verfahren nach einem der Ansprüche 16 bis 18, dadurch gekennzeichnet, dass bei Erkennung eines Ausfalls eines SIP-Proxy-Servers mit erster Zuständigkeit für eine SIP-Domäne ein Ersatzserver bestimmt wird, der die erste Zuständigkeit für die SIP-Domäne übernimmt.
  20. SIP Proxy Server, welcher für eine Peer-to-Peer Kommunikation im Rahmen eines Verfahrens nach einem der Ansprüche 1 bis 19 ausgestaltet ist.
  21. Serversystem, umfassend eine Mehrzahl von SIP Proxy Servern, welches für die Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 19 angepasst ist.
DE102005009107A 2005-02-28 2005-02-28 Bereitstellung von redundanten SIP Proxy Ressourcen Expired - Fee Related DE102005009107B3 (de)

Priority Applications (7)

Application Number Priority Date Filing Date Title
DE102005009107A DE102005009107B3 (de) 2005-02-28 2005-02-28 Bereitstellung von redundanten SIP Proxy Ressourcen
EP06708422A EP1856889A1 (de) 2005-02-28 2006-02-21 Bereitstellung von redundanten sip proxy ressourcen
PCT/EP2006/060144 WO2006092368A1 (de) 2005-02-28 2006-02-21 Bereitstellung von redundanten sip proxy ressourcen
CNA200680006268XA CN101129050A (zh) 2005-02-28 2006-02-21 提供冗余的sip的代理资源
CA002599176A CA2599176A1 (en) 2005-02-28 2006-02-21 Provisioning of redundant sip proxy resources
US11/885,269 US20080247381A1 (en) 2005-02-28 2006-02-21 Provisioning of Redundant Sip Proxy Resources
KR1020077020790A KR20070103772A (ko) 2005-02-28 2006-02-21 중복적인 sip 프록시 자원들의 이용가능

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102005009107A DE102005009107B3 (de) 2005-02-28 2005-02-28 Bereitstellung von redundanten SIP Proxy Ressourcen

Publications (1)

Publication Number Publication Date
DE102005009107B3 true DE102005009107B3 (de) 2006-07-13

Family

ID=36237552

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102005009107A Expired - Fee Related DE102005009107B3 (de) 2005-02-28 2005-02-28 Bereitstellung von redundanten SIP Proxy Ressourcen

Country Status (7)

Country Link
US (1) US20080247381A1 (de)
EP (1) EP1856889A1 (de)
KR (1) KR20070103772A (de)
CN (1) CN101129050A (de)
CA (1) CA2599176A1 (de)
DE (1) DE102005009107B3 (de)
WO (1) WO2006092368A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2587774A1 (de) * 2011-10-24 2013-05-01 Alcatel Lucent Verfahren für SIP-Proxy-Ausfallsicherung

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7920549B2 (en) * 2005-07-20 2011-04-05 Verizon Business Global Llc Method and system for providing secure media gateways to support interdomain traversal
US20080056274A1 (en) * 2006-08-31 2008-03-06 Mastrogiulio Joseph V Method and apparatus for dynamically maintaining a routing database for a SIP server
US7656836B2 (en) * 2006-10-05 2010-02-02 Avaya Inc. Centralized controller for distributed handling of telecommunications features
US8111614B2 (en) * 2006-11-29 2012-02-07 Net2Phone, Inc. Remote redundant voice server system
GB2444995B (en) * 2006-12-21 2011-07-27 Vodafone Plc Peer to peer network
CN100531098C (zh) 2007-03-13 2009-08-19 华为技术有限公司 一种对等网络系统及重叠网间节点的互通方法
WO2009002143A1 (en) * 2007-06-22 2008-12-31 Telefonaktiebolaget Lm Ericsson (Publ) Method of providing a service through a user equipment unit in an ip multimedia subsystem telecommunications network, including a user database server, service policy server and application server for use with said method
US7970916B2 (en) * 2007-07-25 2011-06-28 Cisco Technology, Inc. Register clustering in a sip-based network
US8300644B2 (en) 2008-09-30 2012-10-30 Avaya Inc. Coordination of user information across session initiation protocol-based proxy servers
US7885253B2 (en) 2008-09-30 2011-02-08 Avaya Inc. Synchronization of session-initiation-protocol proxy databases
JP4920052B2 (ja) 2009-03-11 2012-04-18 株式会社日立製作所 通信システム及びサーバ
US9219615B2 (en) 2011-01-28 2015-12-22 Throughtek Co., Ltd. Remote information communication system and linking method thereof
US9729502B2 (en) * 2011-02-02 2017-08-08 Junction Networks, Inc. System and method for geographic SIP scaling
CN102647397B (zh) * 2011-02-17 2016-12-21 中兴通讯股份有限公司 一种sip会话保护的方法和系统
CN102891833B (zh) * 2011-07-21 2017-03-29 中兴通讯股份有限公司 网络容灾方法和系统
CN102821172B (zh) * 2012-09-10 2015-06-17 华为技术有限公司 Sip注册服务器地址的获得方法、设备及系统
US9198091B2 (en) 2013-03-15 2015-11-24 Vonage Network, Llc Systems and methods for rapid setup of telephony communications
US9179482B2 (en) * 2013-03-15 2015-11-03 Vonage Network, Llc Systems and methods for rapid setup of telephony communications
US11778000B1 (en) 2013-03-25 2023-10-03 Junction Networks Inc. Event subscription in distributed session initiation protocol architectures
US9215169B2 (en) * 2013-05-15 2015-12-15 Verizon Patent And Licensing Inc. Delivering correct number information in a private SIP network
US9203936B2 (en) * 2013-10-07 2015-12-01 At&T Intellectual Property I, Lp Method and apparatus for initiating communication sessions
US9191264B2 (en) * 2013-10-08 2015-11-17 At&T Intellectual Property I, Lp Method and apparatus for initiating communication sessions
US9912623B2 (en) 2015-01-16 2018-03-06 General Electric Company Systems and methods for adaptive context-aware control of multimedia communication sessions

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002097653A1 (en) * 2001-05-30 2002-12-05 Tekelec Scalable, reliable session initiation protocol (sip) signaling routing node
WO2002102031A2 (en) * 2001-06-12 2002-12-19 The Trustees Of Columbia University In The City Of New York System and method for call routing in an ip telephony network
EP1487186A1 (de) * 2003-06-11 2004-12-15 Siemens Aktiengesellschaft Redundanten Betrieb eines Endgerätes an zumindest zwei Kommunikationsknoten

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020103850A1 (en) * 2001-01-31 2002-08-01 Moyer Stanley L. System and method for out-sourcing the functionality of session initiation protocol (SIP) user agents to proxies
KR100661313B1 (ko) * 2003-12-03 2006-12-27 한국전자통신연구원 평생 번호를 사용한 이동성 제공이 가능한 sip 기반의멀티미디어 통신 시스템 및 이동성 제공 방법
US20050138119A1 (en) * 2003-12-23 2005-06-23 Nokia Corporation User-location service for ad hoc, peer-to-peer networks
US7532712B2 (en) * 2004-12-01 2009-05-12 Time Warner Cable, Inc. System and method for providing caller ID service in a multi-region cable network
US7742421B2 (en) * 2007-07-31 2010-06-22 Tekelec Systems, methods, and computer program products for distributing application or higher layer communications network signaling entity operational status information among session initiation protocol (SIP) entities
ES2387135T3 (es) * 2007-12-17 2012-09-14 Telefonaktiebolaget L M Ericsson (Publ) Optimización de la pila de protocolos de inicio de sesión
US7720976B2 (en) * 2008-03-31 2010-05-18 Alcatel-Lucent Usa Inc. Peer-to-peer communication between different types of internet hosts

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002097653A1 (en) * 2001-05-30 2002-12-05 Tekelec Scalable, reliable session initiation protocol (sip) signaling routing node
WO2002102031A2 (en) * 2001-06-12 2002-12-19 The Trustees Of Columbia University In The City Of New York System and method for call routing in an ip telephony network
EP1487186A1 (de) * 2003-06-11 2004-12-15 Siemens Aktiengesellschaft Redundanten Betrieb eines Endgerätes an zumindest zwei Kommunikationsknoten

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Cisco White-Paper, "High-Availability Solutions for SIP-Enabled Voice-over-IP Networks" Copyright (c( 1992-2002 Cisco Systems, Inc., 7 Seiten, im Internet Online zugängig per Link: http://www.cis co.com/en/US/tech/tk652/tk701/technologies_white_ paper09186a00800a9818.shtml *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2587774A1 (de) * 2011-10-24 2013-05-01 Alcatel Lucent Verfahren für SIP-Proxy-Ausfallsicherung
WO2013060567A1 (en) * 2011-10-24 2013-05-02 Alcatel Lucent A method for sip proxy failover
US9389969B2 (en) 2011-10-24 2016-07-12 Alcatel Lucent Method for SIP proxy failover

Also Published As

Publication number Publication date
US20080247381A1 (en) 2008-10-09
KR20070103772A (ko) 2007-10-24
WO2006092368A1 (de) 2006-09-08
EP1856889A1 (de) 2007-11-21
CN101129050A (zh) 2008-02-20
CA2599176A1 (en) 2006-09-08

Similar Documents

Publication Publication Date Title
DE102005009107B3 (de) Bereitstellung von redundanten SIP Proxy Ressourcen
DE60122782T2 (de) Adressierungsverfahren und system zur verwendung einer anycast-adresse
DE60026231T2 (de) Verfahren und Vorrichtung zur Durchführung eines Schnellen Dienstnachschlagen in einem Neztwerkgruppen
DE102008010145B4 (de) Peer-to-Peer-Kommunikationssystem und -verfahren
DE60025129T2 (de) Verfahren und Vorrichtung zur Bereitstellung von skalierbaren Diensten unter Benutzung einer Paketverteilungstabelle
DE60206525T2 (de) Zugangsbereitstellungverfahren und -system zu teilnehmerdiensten
DE102006021591B3 (de) Verfahren und Anordnung zur Datenübertragung zwischen Peer-to-Peer-Netzwerken
DE60208659T2 (de) Skalierbare ressourcenermittlung und rekonfiguration für verteilte rechnernetze
DE60310676T2 (de) System und verfahren zum identifizieren eines drahtlosen versorgungsknotens für eine mobileinheit
DE112020001459T5 (de) Konsistente Route-Ankündigungen zwischen redundanten Controllern im globalen Netzwerk-Access-Point
DE202015009264U1 (de) Anycast-basiertes, wide-area-verteiltes kartierungs- und lastverteilungssystem
DE102005008590B3 (de) Verfahren zum Aufnehmen einer VoIP-Kommunikation mittels einer Peer-to-Peer-Datenbank
DE102006005814A1 (de) Verfahren und Vorrichtung zum Verarbeiten eines Kontaktes mit einem Client innerhalb eines Kontaktverteilers in Verbindung mit computerunterstützten automatischen Rufvermittlungen
EP2027738A1 (de) Verfahren zur mehrfachen registrierung eines multimodalen kommunikationsendgerätes
DE102011122179A1 (de) Hochgradig skalierbarer und verteilter Anruf-/Medienmodellierungs- und -Steuerungsrahmen
DE602004010345T2 (de) Verfahren und Einrichtung zur Migration zu einem alternativen Call Controller
DE102011110062A1 (de) Ausfallsicherung auf basis der sendung von kommunikationen zwischen verschiedenen domänen
DE10345051B4 (de) Verfahren zum Aufbau einer Kommunikationsverbindung in einem direkt kommunizierenden Kommunikationsnetzwerk
EP1487186A1 (de) Redundanten Betrieb eines Endgerätes an zumindest zwei Kommunikationsknoten
WO2006053798A1 (de) Anrufverteilung in einem direktkommunizierenden netzwerk
EP3676991B1 (de) Bahnautomatisierungsnetz sowie verfahren zum übermitteln von nachrichten in einem bahnautomatisierungsnetz
DE602004006171T2 (de) Sitzungseinleitungsprotokollsignalisierung (sip)
EP3054654B1 (de) Netzwerksystem und verfahren zur namensauflösung in einem netzwerksystem
Kaiser et al. User-friendly, versatile, and efficient multi-link DNS service discovery
WO2006048363A1 (de) Verfahren zur initialisierung eines datennetzes

Legal Events

Date Code Title Description
8100 Publication of patent without earlier publication of application
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE

8339 Ceased/non-payment of the annual fee