EP1856889A1 - Bereitstellung von redundanten sip proxy ressourcen - Google Patents

Bereitstellung von redundanten sip proxy ressourcen

Info

Publication number
EP1856889A1
EP1856889A1 EP06708422A EP06708422A EP1856889A1 EP 1856889 A1 EP1856889 A1 EP 1856889A1 EP 06708422 A EP06708422 A EP 06708422A EP 06708422 A EP06708422 A EP 06708422A EP 1856889 A1 EP1856889 A1 EP 1856889A1
Authority
EP
European Patent Office
Prior art keywords
sip
peer
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.)
Withdrawn
Application number
EP06708422A
Other languages
English (en)
French (fr)
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
Nokia Siemens Networks GmbH and Co KG
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 Nokia Siemens Networks GmbH and Co KG filed Critical Nokia Siemens Networks GmbH and Co KG
Publication of EP1856889A1 publication Critical patent/EP1856889A1/de
Withdrawn legal-status Critical Current

Links

Classifications

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

Definitions

  • the invention relates to a method for address resolution of the address of a SIP proxy in a SIP network with provision of redundant SIP proxy resources and a SIP proxy server and a server system, which are designed for carrying out such a method.
  • IP Internet Protocol
  • SIP Session Initiation Protocol
  • Terminals or endpoints of a SIP network are called user agents.
  • These user agents usually include a SIP client that can make requests to a server.
  • DNS servers DNS: Domain Name System
  • SIP Session Initiation Protocol
  • SIP proxy servers which receive SIP requests from a user agent and forward them to another location.
  • registrar servers which can accept SIP registration requests and refresh the information via user agents in so-called localization servers or other databases.
  • SIP networks address resolution A very important role plays in SIP networks address resolution. Address resolution capabilities provided by the SIP protocol achieve a high degree of mobility and portability within SIP networks. A typical address resolution and the role of a SIP proxies will be described in greater detail below with reference to FIG. In this picture, another SIP user-agent 2 user is to be contacted by a first SIP terminal User-Agent 1.
  • the address of the other terminal User-Agent 2 is the user agent 1 in the form of a SIP address, for example SIP:
  • the user agent To resolve this address, the user agent must first identify a suitable SIP proxy for this task. It sends a request (SRV Query or SRV SER Query) to a DNS server (step 1). In this request should be for the threre. com domain responsible SIP proxy
  • the DNS server then sends the user agent 1 the Internet address of the SIP proxy to be used (SRV record or DNS SRV record).
  • the user-agent terminal 1 can then use this address to make a request (SIP request) to the SIP proxy or proxy server for resolving the address of the B-side user agent 2 terminal.
  • This request confirms the SIP proxy in step 4 by the message 100 trying.
  • the SIP proxy makes a request to a location service, which determines the currently current Universal Resource Locator (URL) for user agent 2 and returns it in step 6 (response).
  • URL Universal Resource Locator
  • step 7 the SIP proxy makes a request to a domain name server (enum query) to obtain the currently registered location of the user agent 2 corresponding IP address. This is determined in step 8 (NAPTR Record: DNS Naming Authority Pointer Resource Record; is used for ENUM telephone long-range assignment) delivered. The IP address is used in step 9 (SIP request) to finally contact the user agent 2, which then sends back an acknowledgment (step 10: 200 okay).
  • step 8 NAPTR Record: DNS Naming Authority Pointer Resource Record; is used for ENUM telephone long-range assignment
  • This confirmation is then forwarded to the user agent 1 (step 11).
  • connection setup shown in FIG. 1 is greatly simplified. In many cases, more than one SIP proxy server is involved in a connection setup.
  • address resolution is usually not made by a single domain server, but by a (often hierarchical) server system. For example, there is the possibility that a first DNS server might become a commercial one
  • Proxy resources are taken care of.
  • the aim here is a similar to the conventional telephone network PSTN (public switched telephone network) resiliency.
  • the first of these two drawbacks has the disadvantage of practically duplicating the SIP proxies, which is a very resource-intensive way of providing redundancy.
  • the second approach has the disadvantage that the user agent must be able to analyze and evaluate SER-SRV records, that is, he must be equipped with considerable additional functionality.
  • the second approach or concept is to provide redundancy by dynamically allocating the used IP address. For example, load balancing is performed that distributes requests or requests sent to the same IP address to various SIP proxy servers (load balancers).
  • SIP proxy servers load balancers
  • Another possibility is the application of the Virtual Router Redundancy Protocol (VRRP) described in the RFC 2338.
  • VRRP Virtual Router Redundancy Protocol
  • a pair of SIP proxy servers is provided, whereby the VRRP protocol ensures that in the event of a failure the respective replacement server handles the processing of requests. This transfer is usually done with the help of a VRRP daemon (VRRPD).
  • VRRPD VRRP daemon
  • the last implementation in turn, has the disadvantage of a duplication, that is, a less efficient use of resources.
  • the use of load distribution has a weak point in the load distribution itself, which as a non-duplicated component carries a certain risk of failure (single failure point).
  • the invention has for its object to provide an address resolution in a SIP network with efficient and low-cost provision of SIP proxy redundancy, the disadvantages of conventional concepts should be avoided.
  • the central idea of the invention is to provide redundancy in SIP proxy resources by providing the SIP proxy resources in the form of a peer-to-peer group of SIP proxy servers.
  • the peer-to-peer concept allows efficient use of the available SIP proxy servers for switching services.
  • Peer-to-peer networks are a current area of many development efforts, which is why a variety of protocols and concepts exist for their use. As far as the architecture of peer-to-peer networks is concerned, there are usually three different types. The first peer-to-peer networks were designed centrally. There was a central data source from which peer-to-peer network nodes could query to find out in which of the other nodes the desired information or data was kept. An example of such a peer-to-peer network structure is Napster. Because the centrally structured peer-to-peer networks do not scale well and also run the risk of failure of the central office, other architectures have been developed. A second type are the decentralized but structured peer-to-peer networks.
  • a third type is the decentralized and unstructured peer-to-peer networks, in which the topology also disappears.
  • a node of a peer-to-peer network then contacts its neighbor.
  • a typical request may be to flood a request message, the request being transmitted to all neighbors within a certain radius.
  • the present invention is preferably realized with structured peer-to-peer networks. These can be made particularly efficient and performant by means of DHT-based methods (eg Chord, Pastry, Kademlia) in terms of degree of replication and search duration.
  • Information can be kept redundant in peer-to-peer networks (that is, copies or replicas are present). Data or information may thus be distributed in distributed form over a plurality of nodes of the peer-to-peer network, with at least two copies of each information unit being provided on different nodes for higher reliability. Depending on the type of peer-to-peer network, the location for storing information and the frequency of copies can be optimized for the most efficient request possible.
  • a common and efficient query method for distributed information is the Distributed Hash Table (DHT) system.
  • DHT Distributed Hash Table
  • SIP proxy resources are provided as (for example, decentralized and unstructured) peer-to-peer group of SIP proxy servers.
  • This peer-to-peer group is responsible, for example, for the terminals of one or more SIP domains, ie these terminals access one of these SIP proxy servers for a connection setup.
  • Several peer-to-peer groups can together form a peer-to-peer network.
  • Information regarding the responsibility for terminal devices (SIP clients) of a SIP domain and functions of the SIP proxy servers can be replicated and stored in a copy.
  • a peer-to-peer group according to the invention may not correspond to a replication group.
  • part of a peer-to-peer group may represent a replication group, or a replication group may include peers of more than one peer-to-peer group.
  • the redundant SIP proxy resources can be used, for example, for establishing a connection via a SIP proxy.
  • IP Internet Protocol
  • a SIP client e.g. made available on request to a DNS server system.
  • DNS Domain Name Server
  • this Domain Name Server (DNS) server system may consist of a single server. In general, however, it will be constituted of several possibly hierarchically ordered servers, for example, it is provided that a DNS server accesses a domain name server service.
  • This DNS server system is e.g. Provides an IP address to use for accessing SIP proxy resources of the peer-to-peer group through external SIP proxy servers. IP addresses can be polled regularly by the SIP proxy
  • SIP domains may be in each case the SIP domain of the requesting SIP client or user agent, or else the SIP domain of the user interface to be contacted when establishing a connection. Agents act.
  • peer-to-peer protocols for the definition of responsibilities or the exchange of information about responsibilities, dynamic and adaptive assignment of SIP proxy server to SIP domain can be implemented reliably. It can be flexibly responded to changes or influences.
  • the peer-to-peer group can also comprise at least one registrar server, which ensures that information acquired by registration by this registrar server can be passed on or made available through peer-to-peer protocols.
  • the SIP proxy servers of the peer-to-peer group are also registrar servers. Registrar and proxy then merge into one instance within a peer-to-peer network. One could then describe this so that the peer-to-peer network consists of generic servers that master both the SIP Proxy and the SIP Registrar function.
  • a response to an influence may also involve an adaptation or modification of one or more replication groups.
  • a replication group can be extended to SIP proxy servers of a SIP proxy server group in which no server was previously part of the replication group.
  • a replication group can also be extended to SIP proxy servers that belong to a different replication group or to no replication group.
  • the concept is flexible with regard to the inclusion of new SIP proxies or the restructuring of existing SIP proxy resources. For example, a dynamic expansion of the domain Necessary responsibility on peers, for example, do not belong to any domain or that are dispensable in another domain. This dynamic expansion can be carried out by the P2P protocol and follows boundary conditions such as the degree of replication within a domain responsible for a SIP domain
  • the invention also includes a SIP proxy server and a server system with a multiplicity of SIP proxy servers which are configured or adapted for providing redundancy according to the invention by the organization of SIP proxy servers and peer-to-peer group.
  • protocol means are provided to allow communication within the peer-to-peer group with peer-to-peer protocols as well as communication with a DNS server system.
  • means for distributed storage of arranged in the servers of the peer-to-peer group are provided to allow communication within the peer-to-peer group with peer-to-peer protocols as well as communication with a DNS server system.
  • a first and a second responsibility within the peer-to-peer group are defined for a SIP domain.
  • the SIP proxy server with the first responsibility can then be resorted to with the second jurisdiction to provide fast and efficient replacement. You can then transfer the first responsibility to another SIP proxy server, creating a new back-up situation (rollover fall back),
  • a second embodiment shows an address resolution for various constellations.
  • Figure 1 shows a typical connection setup using the SIP protocol.
  • FIG. 2 shows conventional methods for establishing reliability with regard to the SIP proxy resources.
  • Figure 3 shows a network scenario in which a terminal is configured as a user agent for the use of the SIP protocol for establishing a connection.
  • FIG. 4 shows a name resolution according to the invention within a peer-to-peer network.
  • FIG. 5 shows a name resolution according to the invention for an outgoing call
  • FIG. 6 shows a name resolution according to the invention for an incoming call
  • Figure 7 shows an inventive failover in case of failure of a SIP proxy server.
  • a SIP phone (which acts as a user agent) SIP TEL statically two SIP addresses of SIP proxy servers, ProxyPeerl and ProxyPeer2 einkonfiguriert. For the address resolution of the first configured SIP proxy server
  • the DNS server system DynDNS has an assignment of SIP proxy addresses to IP addresses. This assignment or address assignment table is regularly communicated to the DNS server system DynDNS by the SIP proxy server group available for establishing the connection.
  • the SIP proxy server group includes the proxy servers Z_ProxyPeerl, Z ProxyPeer2 and Z ProxyPeerl '.
  • SIP proxy servers are organized as a peer-to-peer server system and inform the DNS server system DynDNS of the current assignments of SIP proxy addresses to IP addresses, e.g.
  • SIP proxy server Z_ProxyPeerl assigns the IP address of the SIP proxy server Z_ProxyPeerl as the SIP proxy address ProxyPeerl and assigns the IP address of the SIP proxy server Z_ProxyPeer2 as the SIP proxy address ProxyPeer2.
  • a change in the responsibilities of SIP proxy servers can then simply be communicated to the DNS server system DynDNS as a new assignment of an IP address to a SIP proxy address.
  • the SIP proxy addresses ProxyPeerl and ProxyPeer2 contain the IP addresses of the proxy server.
  • Server Z ProxyPeerl and Z ProxyPeer2 assigned. If a server fails, for example the SIP proxy server Z ProxyPeerl, this is detected by the peer-to-peer group. For example, the IP address of the proxy peer server ProxyPeerl 'is then communicated to the server system DynDNS as the IP address assigned to the SIP proxy address ProxyPeerl (change of responsibility).
  • the user agent SIP-TEL would get the IP address of Z ProxyPeerl 'when resolving the address ProxyPeerl so that it can initiate the service, for example connection setup, via this proxy server. If a server fails, for example the server Z_ProxyPeerl, which leads to a futile contact by the user agent SIP-TEL, the substitute address Proxy-Peer2 can be used. For example, the user agent SIP-TEL has received the IP address from the proxy server Z_ProxyPeerl on its address resolution request.
  • connection establishment by means of a SIP request to this SIP proxy server Z_ProxyPeerl fails because it has just failed, that is, the confirmation message 100 Trying is not received by the user agent SIP-TEL. Then, after a period of time (for example, after the expiration of a timer), the latter can make a request (SRV query) to the DNS server system DynDNS for the dissolution of the SIP proxy address ProxyPeer2, whereupon the DNS server system DynDNS stores the IP address. Address of the SIP proxy server Z ProxyPeer2 returns, so that the terminal SIP-TEL on the SIP proxy server Z_ProxyPeer2 can establish the connection.
  • the invention allows dynamic and flexible provision of proxy resources, which derives its advantages from the fact that the SIP proxy servers are organized as a peer-to-peer group.
  • the exploitation of the characteristics of the SIP proxy system organized as a peer-to-peer network is not limited to the illustrated embodiment.
  • an assignment from a SIP proxy address or a SIP domain (which may be included in the DNS server system DynDNS) could also be used. dividing IP address is then determined by which SIP domain the address of the user agent SIP-TEL belongs to) given to two IP addresses (a regular address and a spare address).
  • the DNS server system DynDNS could, for example, remember inquiries by user agents and return the respective other IP address or substitute address in the case of a second request that occurs shortly after a first request.
  • Figures 4 to 7 show a peer-to-peer network formed by the SIP proxy servers shown as circles.
  • the peer-to-peer network provides redundant SIP proxy
  • the SIP proxies shown as open circles have the responsibility for the SIP domain there, the gray circles are responsible for the SIP domain before and the black circles have the responsibility for the SIP domain after. It is assumed that the terminals associated with the SIP domains are indexed according to the first letter of the name and assigned to SIP proxy servers for storing the information relevant for the contacting (location, IP address,...) To SIP proxy servers are. As shown in FIG. 4, the SIP proxy server 1 takes over the storage of the information for the initial letters a to f.
  • the SIP proxy server 2 for the domain there takes over the storage of the information for the initial letters g to k and the SIP proxy server 3 for the domain there storing the information for the first letter 1 to o.
  • the Information stored for all connected terminals via the SIP proxy server responsible for the respective SIP domain For each of these stored information, there is a copy that is stored on a different SIP proxy server. For example, saves the SIP proxy server 1 for the domain there, the information for the initial letters x to z of the terminals of the domain befo- re, the SIP proxy server 2 for the domain there the information for the initial letters a to f of the terminals of the domain there (ie replicates the information on SIP proxy server 1 for the domain there), etc.
  • the information is replicated within the ring-shaped peer-to-peer network so that for each SIP proxy server in each case an adjacent SIP proxy server stores the replicated information.
  • SIP proxy servers responsible for a SIP domain two each assume the role already described with reference to FIG. 3, ie their SIP addresses (ProxyPeerl and ProxyPeer2 in FIG. 3) are configured in the terminals of the domain or preset. This role or function is designated as proxyl or proxy2 in FIGS. 4 to 7. This function is performed for the domain there in FIGS.
  • FIGS. 4 to 6 sequences for different constellations in a call setup between alice @ there and a second terminal are shown.
  • Alice @ there for example, corresponds to the SIP client (SIP telephone) SIP-TEL from FIG. 3.
  • the SIP client alice @ there calls the terminal bob @ after in the SIP domain after (name resolution within the peer-to-peer network). For this, alice @ there sends an INVITE message to the SIP proxy server with the proxyl function for the domain there (ie to the SIP proxy server 1 responsible for the domain there). For the name resolution, the latter contacts the SIP proxy server with the function proxyl for the domain after (ie, for the SIP proxy server 1 responsible for the domain after) by means of a LOOKUP message. In the course of a RESPONSE message, the corresponding IP address bob @ l .2.3.4 returned. Thereupon, the SIP proxy server 1 of the domain there can send an INVITE message to the address bob @ l .2.3.4, ie to bob @ after.
  • the SIP client alice @ there calls the terminal john @ somewhere in the SIP domain somewhere (name resolution for a call to a terminal outside the peer-to-peer network).
  • the SIP domain somewhere is not managed within the peer-to-peer network.
  • alice @ there sends an INVITE message to the SIP proxy server with the proxyl function for the domain there.
  • this SIP proxy server proxyl for the domain uses a LOOKUP message to contact a DNS system to identify the SIP proxy server responsible for the domain somewhere. Then a LOOKUP
  • the SIP client john @ somewhere calls the terminal alice @ there (name resolution for a call from a terminal outside the peer-to-peer network).
  • the SIP client john @ somewhere first sends an INVITE message to the SIP proxy server proxyl @ somewhere responsible for the domain somewhere. This sends a LOOKUP message and a DNS system DynDNS to identify the SIP proxy server for the domain there.
  • the DNS system DynDNS has stored the SIP proxy server of the domain there with the proxyl function as the SIP proxy server responsible for domain there.
  • SIP proxy server SIP proxy server 1
  • the IP address of alice @ there is requested by means of a LOOKUP message.
  • FIG. 7 shows the function transfer of the function proxyl in the event of a failure of the SIP proxy server 1 with the function proxyl of the domain there. If the SIP proxy server with the proxyl function can not be reached, the terminal SIP-TEL can use the SIP proxy server 2 with the proxy2 function for establishing a call. If the peers detect the failure, the responsibilities of the failed SIP proxy server are redistributed.
  • the SIP proxy server 3 assumes the proxyl function and the SIP proxy server 2 takes over the responsibility for the terminals (name index ak instead of previously gk). SIP proxy server 3 then stores the replicated information from the SIP proxy server 1 (replication ak).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

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 einen 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 werden, 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 für einen Zugriff auf den zuständigen SIP-Proxy-Server weitergeben kann. Die erfindungsgemäße Bereitstellung von SIP-Proxy-Ressourcen ist aufwandsarm, flexible und erlaubt einen schnellen Zugriff auf redundante Ressourcen im Störungsfall.

Description

Beschreibung
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) .

Claims

Patentansprüche
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, dadurch gekennzeichnet, dass
- SIP-Proxy-Ressourcen in Form einer Mehrzahl von SIP-Proxy- Servern gegeben sind,
- die SIP-Proxy-Server zu einer Peer-to-Peer Gruppe gehören, und
- mittels eines Peer-to-Peer Protokolls innerhalb der Peer- to-Peer Gruppe Nachrichten ausgetauscht werden, wodurch Zu- stä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 Replika- tionsgruppe 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 Peer- to-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 um- fasst .
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die die Peer-to-Peer Server der Peer-to-Peer Gruppe ebenfalls die Funktion von Registrar Server 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 Ad- resse 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.
EP06708422A 2005-02-28 2006-02-21 Bereitstellung von redundanten sip proxy ressourcen Withdrawn EP1856889A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005009107A DE102005009107B3 (de) 2005-02-28 2005-02-28 Bereitstellung von redundanten SIP Proxy Ressourcen
PCT/EP2006/060144 WO2006092368A1 (de) 2005-02-28 2006-02-21 Bereitstellung von redundanten sip proxy ressourcen

Publications (1)

Publication Number Publication Date
EP1856889A1 true EP1856889A1 (de) 2007-11-21

Family

ID=36237552

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06708422A Withdrawn EP1856889A1 (de) 2005-02-28 2006-02-21 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)

Families Citing this family (24)

* 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 华为技术有限公司 一种对等网络系统及重叠网间节点的互通方法
US20100223326A1 (en) * 2007-06-22 2010-09-02 Rogier Noldus Method of Providing a Service through a User Equipment Unit in a an IP Multimedia Sub-System 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 中兴通讯股份有限公司 网络容灾方法和系统
EP2587774B1 (de) * 2011-10-24 2015-03-04 Alcatel Lucent Verfahren für SIP-Proxy-Ausfallsicherung
CN104935681B (zh) * 2012-09-10 2018-10-09 华为技术有限公司 Sip注册服务器地址的获得方法、设备及系统
US9179482B2 (en) * 2013-03-15 2015-11-03 Vonage Network, Llc Systems and methods for rapid setup of telephony communications
US9198091B2 (en) 2013-03-15 2015-11-24 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

Family Cites Families (10)

* 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
US7020707B2 (en) * 2001-05-30 2006-03-28 Tekelec Scalable, reliable session initiation protocol (SIP) signaling routing node
AU2002345675A1 (en) * 2001-06-12 2002-12-23 The Trustees Of Columbia University In The City Of New York System and method for call routing in an ip telephony network
EP1487186B8 (de) * 2003-06-11 2017-05-17 Unify GmbH & Co. KG Verfahren und Kommunikationsanordnung zum wechselweisen Betrieb eines Endgerätes an zumindest zwei Kommunikationsknoten
KR100661313B1 (ko) * 2003-12-03 2006-12-27 한국전자통신연구원 평생 번호를 사용한 이동성 제공이 가능한 ｓｉｐ 기반의멀티미디어 통신 시스템 및 이동성 제공 방법
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
EP2179541B1 (de) * 2007-07-31 2018-11-21 Tekelec, Inc. Systeme, verfahren und computerprogrammprodukte zur verteilung von betriebsstatusinformationen über signalisierungseinheiten von anwendungen oder kommunikationsnetzen höherer schicht unter sip-einheiten
EP2290898B1 (de) * 2007-12-17 2012-09-26 Telefonaktiebolaget LM Ericsson (publ) Stapeloptimierung für ein Sitzungsstartprotokoll
US7720976B2 (en) * 2008-03-31 2010-05-18 Alcatel-Lucent Usa Inc. Peer-to-peer communication between different types of internet hosts

Non-Patent Citations (1)

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

Also Published As

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

Similar Documents

Publication Publication Date Title
DE102005009107B3 (de) Bereitstellung von redundanten SIP Proxy Ressourcen
DE60122782T2 (de) Adressierungsverfahren und system zur verwendung einer anycast-adresse
DE60208659T2 (de) Skalierbare ressourcenermittlung und rekonfiguration für verteilte rechnernetze
DE60026231T2 (de) Verfahren und Vorrichtung zur Durchführung eines Schnellen Dienstnachschlagen in einem Neztwerkgruppen
DE60025129T2 (de) Verfahren und Vorrichtung zur Bereitstellung von skalierbaren Diensten unter Benutzung einer Paketverteilungstabelle
DE60206525T2 (de) Zugangsbereitstellungverfahren und -system zu teilnehmerdiensten
DE69706649T2 (de) Verfahren und vorrichtung um einen klient-knoten mit einem server-knoten gemäss der belastungsstufen zu verbinden
DE102008010145A1 (de) PEER-TO-PEER-Kommunikationssystem und -verfahren
DE112020001459T5 (de) Konsistente Route-Ankündigungen zwischen redundanten Controllern im globalen Netzwerk-Access-Point
DE60310676T2 (de) System und verfahren zum identifizieren eines drahtlosen versorgungsknotens für eine mobileinheit
DE102009041127A1 (de) Registrierung eines Endpunkts mit einem Schiebefenster von Controllern in einer Liste von Controllern eines überlebensfähigen Netzes
EP2018761A1 (de) Verfahren und anordnung zur datenübertragung zwischen peer-to-peer-netzwerken
DE10143754A1 (de) Skalierbares Peer-to-Peer-Netzwerk mit einem Verzeichnisdienst
DE202015009264U1 (de) Anycast-basiertes, wide-area-verteiltes kartierungs- und lastverteilungssystem
WO2007141159A1 (de) Verfahren zur mehrfachen registrierung eines multimodalen kommunikationsendgerätes
DE102017125649A1 (de) Verfahren zur Datenkommunikation unter Verwendung von Random-Netzwerkadressen und eine entsprechende Vorrichtung
DE602004010345T2 (de) Verfahren und Einrichtung zur Migration zu einem alternativen Call Controller
DE102008036453A1 (de) Verfahren zum Versenden von Daten und Kommunikationseinrichtung
DE102011055403A1 (de) Entferntes Informations- und Kommunikationssystem und dessen VerbindungmverfahrenRemote information communication system and linking method thereof
WO2005041535A1 (de) Verfahren zum aufbau einer kommunikationsverbindung in einem direkt kommunizierenden kommunikationsnetzwerk
DE102004036259B3 (de) Netzwerkmanagement mit Peer-to-Peer-Protokoll
DE102005008590B3 (de) Verfahren zum Aufnehmen einer VoIP-Kommunikation mittels einer Peer-to-Peer-Datenbank
DE102022121503B4 (de) Verfahren und IP-Multimedia-Subsystem zum Durchführen einer Datenübertragung, Computerprogrammprodukt und Speichermedium
EP1800457A1 (de) Verfahren zur bestimmung eines leitenden teilnehmers in einem netzwerk
DE112022005649T5 (de) Verfahren zum übertragen und empfangen multimedialer daten

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: 20070928

AK Designated contracting states

Kind code of ref document: A1

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

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

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080620

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: 20081231