EP1856920A1 - Verfahren zur aufrechterhaltung von sip calls bei hardwareausfall redundanter ip systeme - Google Patents

Verfahren zur aufrechterhaltung von sip calls bei hardwareausfall redundanter ip systeme

Info

Publication number
EP1856920A1
EP1856920A1 EP05794712A EP05794712A EP1856920A1 EP 1856920 A1 EP1856920 A1 EP 1856920A1 EP 05794712 A EP05794712 A EP 05794712A EP 05794712 A EP05794712 A EP 05794712A EP 1856920 A1 EP1856920 A1 EP 1856920A1
Authority
EP
European Patent Office
Prior art keywords
protocol
sip
data
sdp
call
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
EP05794712A
Other languages
English (en)
French (fr)
Inventor
Klaus Hoffmann
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
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP1856920A1 publication Critical patent/EP1856920A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • 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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • 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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0025—Provisions for signalling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/08—Indicating faults in circuits or apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13034—A/D conversion, code compression/expansion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13103—Memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13109—Initializing, personal profile
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13167—Redundant apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13396—Signaling in general, in-band signalling

Definitions

  • Newer communication architectures provide for the separation of switching networks in connection service-related units and the transport of the user information (Bearer Control). This results in a decomposition / separation of connection establishment and medium or. Bearer construction.
  • the About ⁇ transmission of the useful information (switching through the data channel) can thereby technologies across different high bit rate Transporttech ⁇ such as ATM, IP and Frame Relay made.
  • the currently tied networks in narrow ⁇ -run telecommunications services are band networks in broad ⁇ to realize.
  • the subscribers are connected either directly (eg via a DSS1 protocol) or via exchanges configured as media gateway controllers (MGC) (eg via the ISUP protocol).
  • MSC media gateway controllers
  • the Nutzinformati ⁇ tions themselves are converted via Media Gateways (MG) in the per ⁇ wells used transport technology.
  • the control of the media gateway is performed by respectively arrange ⁇ th Media Gateway Controllers (MGC).
  • MMC Media Gateway Controllers
  • MGCP protocol or the H.248 protocol.
  • An adequate protocol to the BICC protocol was developed by the IETF standardization body with the SIP protocol (RFC3261) or the addition SIP-T (RFC3204). With the latter, ISUP messages can be transmitted - in contrast to the SIP protocol.
  • the transmission of the ISUP messages is generally carried out by tunnel, ie by transparent fürrei ⁇ chen.
  • the object of the invention is to indicate a way in which, in the event of failure of IP devices, a call can still be kept stable.
  • the advantage of the invention lies in the fact that, with the aid of the SIP Basis RFC 3261 and MGCP RFC 2705 and H.248 recommendation or BICC recommendation Q.1902.x / Q.1901, a simple and easy to implement method for the replacement of SDP data at equivalent circuit to the spare hardware in a SIP / MGCP / H248 network element for Availability checked ⁇ supply is to run to further features in a Cail.
  • FIG. 1 shows the basic relationships between 2 PSTN subscribers, between which an Internet network is arranged.
  • FIG. 2 shows the conditions on the B side in the event of the failure of a SIP device
  • FIG. 3 shows the conditions on the A side and the B side in the event of the failure of a SIP device
  • FIG. 4 shows the conditions when Raceconditions
  • a network configuration is shown, on which the inventive method comes to drain.
  • two PSTN networks are disclosed, in each of which a plurality of PSTN subscribers are arranged in a known manner. These are brought to local exchanges LE, which in turn are connected to transit exchanges TX.
  • the signaling information is supplied from the transit exchange TX immediately above a ISUP protocol Pro ⁇ a respective associated media gateway controller MGC (MGC A or MGC B).
  • MGC A or MGC B media gateway controller
  • the user information is transmitted to a (on the input side) arranged Media Gateway MG (MG A or MG B), which acts as an interface between the TDM network and an ATM or IP transmission network and are transmitted packet-oriented over the relevant transmission network.
  • the media gateway MG A is also controlled by the media gateway controller MGC A, such as the Media Ga ⁇ B teway MG by the media gateway controller MGC B.
  • the media gateway controller MGC In the case of transmission of the payload information by the media gateway MG to the media gateway MG A B are the payloads again under the control of the media gateway MG B assigned Media Gate ⁇ way controller MGC B converted into a TDM data stream and supplied to the candidate PSTN participants. Between the media gateway controller MGC and the respective transmitted to ⁇ parent Media Gateway data are supported by a standardized protocol. This can be at ⁇ play as the MGCP or H.248 protocol. Between the two Media Gateway Controllers MGC A, MGC B is present Preferably, according to the present embodiment, the SIP Pro ⁇ tokoll used. In the signaling path wei ⁇ tere devices such as SIP proxies or SIP units SIP E can be switched.
  • Fig. 2 the failure of a SIP device HWEl is shown.
  • This can be, for example, the SIP proxy device shown in FIG. Failure of device HWE1 is verified by device HWE2. The latter takes over the function of the device HWEl but has according to the present
  • Embodiment still no information about the SDP data of the two endpoints.
  • the device HWE2 another, previously already in the signaling path device (eg, SIP E) to transmit this information. This is done by sending a Re-INVITE message without SDP information. Furthermore, an additional determination is made that the SIP session timer monitoring function is carried out immediately from the device HWE2.
  • the SIP partner SIP E acknowledges (either because it feels addressed to itself or passes on the request and then receives an acknowledgment and forwards it), the received Re-INVITE message without SDP information with a 200 OK acknowledgment, the desired SDP Information includes (RFC3264). Thus, both endpoints know that the call is okay. Billing and call do not need to be stopped.
  • Fig. 3 the entire operation sequence for the A-side and the B-side is shown.
  • the device HWE2 using the standard Re-INVITE message - as just described - the SDP information from the B-side queries (Re-INVITE without SDP).
  • the SDP information is passed to the B-side, whereby the device HWE2 can now store the received SDP information of the B-side (SDP B).
  • this information SDP B is now sent in a re-INVITE message to the A-side.
  • the A-side responds in turn with its own SDP information SDP A in the 200 OK receipt.
  • the information SDP A is in turn stored in the device HWE2.
  • SDP A is sent (SDP A) in an ACK message to the B-side.
  • the device HWE2 has again stored all the data for the successful handling of features.
  • the Cail must be no longer triggered the following by ⁇ feature requirements. Subsequent features such.
  • SIP session timer expiration no longer have to be passed through, but are handled at the respective endpoint of the B2BUA.
  • the involved A and B sides were used to restore the synchronization.
  • race conditions can occur. This means that the device HWE2 does not arrive in time to send the above-described Re-INVITE message before the remote end itself receives a Re-INVITE message (with or without SDP) (feature request by user activity). This is especially because the SETUP ⁇ gen HWEl and HWE2 are designed as highly integrated hardware units to control many important calls simultaneously. Accordingly, this received message is then also uses to restore the current SDP data on the HWE2 device.
  • Fig. 4 the corresponding ratios are shown.
  • the received Re-INVITE message is accepted, the SDP data of the B-side SDP B is stored, and mapped to the Re-INVITE information to the A-side.
  • the A-side beant ⁇ wortet this your part with their own SDP SDP data A. These are in turn stored in the device HWE2 and sent to the 200 OK acknowledgment to the B-side. Again, this is the
  • a SIP device fails.
  • an MGCP (or H.248) device may fail.
  • a DLCX and CRCX message without SDP is sent, and the CRCX ACK is sent to the other side with the local SDP.
  • MDCX instead of DLCX / CRCX is possible.
  • SIP Re-INVITE / or UPDATE With SDP.
  • the SIP Ant ⁇ word is again converted into a MDCX message with the SDP the re- mote side. This has the MGCP device per ⁇ wells also have the option to save the SDP data.
  • NEN Kgs ⁇ also in a unit that provides the interworking of MGCP to H323, VoDSL, VT, or SIP, BICC, come to the end.
  • BICC the CRCX ACK is mapped with SDP to a BICC bearer redirect request message or, in the case of the MGCP protocol, to an MDCX with SDP.

Landscapes

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

Abstract

Der Stand der Technik kann den erhöhten Anforderungen an die Sicherung eines SIP Calls nicht gerecht werden, da die für den Call relevanten Daten, die beim Call Aufbau standardgemäß dynamisch ausgehandelt werden, beim Ausfall einer Einrichtung, über die der Call geführt wird, wieder restauriert wer- den müssen, damit dieser Call nicht verloren geht. Dies hat seinen Grund darin, dass die als SDP Daten (Session Description Protokoll) bekannten endpunktebezogenen Daten in der redundanten Einrichtung, die im Fehlerfall ersatzgeschaltet wird, nicht vorhanden sind. Die Erfindung löst dieses Problem, indem beim Umschalten auf die redundante Einrichtung die endpunktbezogenen Daten über protokollbezogene Meldungen einem benachbarten Knoten entnommen werden, wo diese Daten gespeichert sind und in die redundante Einrichtung übertragen werden.

Description

Verfahren zur Aufrechterhaltung von SIP Calls bei Hardwareausfall redundanter IP Systeme
Neuere Kommunikationsarchitekturen sehen die Trennung vermittlungstechnischer Netzwerke in verbindungsdienstbezogene Einheiten und den Transport der Nutzinformationen (Bearer Control) vor. Hieraus resultiert eine Dekomposition/ Trennung von Verbindungsaufbau und Medium-bzw. Beareraufbau . Die Über¬ tragung der Nutzinformationen (Durchschaltung des Nutzkanals) kann dabei über unterschiedliche hochbitratige Transporttech¬ nologien wie z.B. ATM, IP oder Frame Relay vorgenommen werden.
Mit einer derartigen Trennung sind die gegenwärtig in Schmal¬ bandnetzen geführten Telekommunikationsdienste auch in Breit¬ bandnetzen zu realisieren. Dabei werden die Teilnehmer entweder direkt (z.B. über ein DSSl-Protokoll) oder über als Media Gateway Controller (MGC) ausgebildete Vermittlungsstellen (z. B. über das ISUP-Protokoll) angeschlossen. Die Nutzinformati¬ onen selbst werden über von Media Gateways (MG) in die je¬ weils benutzte Transporttechnologie umgewandelt.
Die Steuerung der Media Gateways wird von jeweils zugeordne¬ ten Media Gateway Controllern (MGC) durchgeführt. Zur Steue¬ rung der Media Gateways verwenden die Media Gateway Control¬ ler normierte Protokolle, wie z. B. das MGCP Protokoll oder das H.248 Protokoll. Zur Kommunikation untereinander verwenden die Media Gateway Controller ein durch die ITU standardi¬ siertes BICC (Bearer Independent CaIl Control) Protokoll, das aus einer Mehrzahl von standardisierten Protokollen gebildet ist und somit eine Protokollfamilie umfasst. Ein dem BICC Protokoll adäquates Protokoll ist bei dem IETF Standardisierungsgremium mit dem SIP Protokoll (RFC3261) bzw. dem Zusatz SIP-T (RFC3204) entstanden. Mit letzterem können ISUP-Nachrichten - im Gegensatz zum SIP Protokoll - übertra- gen werden. Die Übertragung der ISUP-Nachrichten erfolgt im Allgemeinen durch Tunnel, d. h. durch transparentes Durchrei¬ chen .
Die Netzbetreiber erwarten die Sicherstellung der bisher be- kannten Funktionalitäten auch bei Hardwareausfällen hochzentralisierter Hardwareeinrichtungen, die die Signalisierungs- protokolle zwischen mehrere MGCs und entsprechenden SIP End¬ geräten bereitstellen. Lösungen bzgl. der Verfügbarkeit (a- vailability) der zugehörigen Netzwerkeinrichtungen und der Sicherstellung der Services sowie der Bereitstellung von gesicherten Vergebührungsdaten auch bei Hardwareausfällen sind hierbei von enormer Bedeutung. Zusätzlich sind insbesondere die Ausfallszenarien von Bedeutung, die bei Nichtberücksich- tigung der auftretenden Phänomen zu „hängen bleibenden Res- sourcen" führen. Dies ist insofern ein wesentlicher Gesichtspunkt, da damit Netzressourcen für neue Belegungen nicht mehr zur Verfügung stehen, was schließlich einen Geschäftsverlust für den Betreiber bedeutet.
Insbesondere im SIP-Protokoll (RFC3261) werden erhöhte Anfor¬ derungen an die Sicherung eines Calls gestellt, da dort die für den CaIl relevanten Daten, die beim CaIl Aufbau standard¬ gemäß dynamisch ausgehandelt werden, dementsprechend bei Aus¬ fall wieder restauriert werden müssen, damit dieser CaIl nicht verloren geht. Gleichzeitig besteht jedoch auch zusätz¬ lich die Forderung, dass auch in diesen Fällen sicherzustellen ist, dass die Calls auch nach einem Hardwareausfall noch weitere Features behandeln können. Bisherige Lösungsansätze beschränken sich darauf, den CaIl bei irgendwelchen Userakti- vitäten wenigsten kontrolliert Auslösen zu können. Die Problematik des Standes der Technik besteht darin, das bei Ausfall einer Einrichtung die als SDP Daten (Session Description Protokoll) bekannten endpunktebezogenen Daten in der redundanten Einrichtung nicht vorhanden sind. Dies hat seinen Grund darin, dass das Halten der SDP Daten (Bearer-
Endpunktdaten) in den redundanten Einrichtungen viel Speicherplatz und Dynamik kostet, weswegen darauf verzichtet wird.
Der Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzei- gen, wie bei Ausfall von IP-Einrichtungen ein CaIl weiterhin stabil gehalten werden kann.
Die Erfindung wird ausgehend von den im Oberbegriff von Patentanspruch 1 angegebenen Merkmalen durch die im kennzeichnenden Teil beanspruchten Merkmale gelöst.
Der Vorteil der Erfindung ist darin zu sehen, dass unter zur Hilfenahme des SIP Basis RFC 3261 und MGCP RFC 2705 und H.248 recommendation oder BICC recommendation Q.1902.x/Q.1901 ein einfaches und leicht zu implementierbares Verfahren für die Wiederbeschaffung von SDP Daten bei Ersatzschaltung auf die Ersatzhardware in einem SIP/MGCP/H248 Netzelement zur Verfü¬ gung steht, um weiterhin Features in einem CaIl ablaufen zu lassen.
Die Erfindung wird im Folgenden anhand eines figürlich dargestellten Ausführungsbeispiels näher erläutert.
Es zeigen:
Figur 1 die grundsätzlichen Verhältnisse zwischen 2 PSTN- Teilnehmern, zwischen denen ein Internetnetz angeordnet ist,
Figur 2 die Verhältnisse auf der B-Seite beim Ausfall einer SIP-Einrichtung, Figur 3 die Verhältnisse auf der A-Seite und der B-Seite beim Ausfall einer SIP-Einrichtung,
Figur 4 die Verhältnisse beim Auftreten von Raceconditions
In Fig. 1 ist eine Netzkonfiguration aufgezeigt, auf der das erfindungsgemäße Verfahren zum Ablauf gelangt. Hierbei sind beispielhaft 2 PSTN-Netze offenbart, in denen jeweils eine Mehrzahl von PSTN-Teilnehmern in bekannter Weise angeordnet ist. Diese sind an Ortsvermittlungsstellen LE herangeführt, die ihrerseits mit Transit-Vermittlungsstellen TX verbunden sind.
In den Transit-Vermittlungsstellen TX wird nun die Trennung zwischen Signalisierungsinformationen und Nutzinformationen durchgeführt. Die Signalisierungsinformationen werden von der Transit-Vermittlungsstelle TX unmittelbar über ein ISUP- Pro¬ tokoll einem jeweils zugeordneten Media Gateway Controller MGC (MGC A oder MGC B) zugeführt. Die Nutzinformationen werden zu einem (eingangsseitig angeordneten) Media Gateway MG (MG A oder MG B) übertragen, das als Schnittstelle zwischen TDM-Netz und einem ATM- bzw. IP- Übertragungsnetz fungiert und werden über das betreffende Übertragungsnetz paketorien- tiert übertragen. Das Media Gateway MG A wird von dem Media Gateway Controller MGC A ebenso gesteuert, wie das Media Ga¬ teway MG B vom Media Gateway Controller MGC B. Im Falle einer Übertragung der Nutzinformationen vom Media Gateway MG A zum Media Gateway MG B werden die Nutzinformationen wieder unter Steuerung des dem Media Gateway MG B zugeordneten Media Gate¬ way Controllers MGC B in einen TDM Datenstrom umgewandelt und dem in Frage kommenden PSTN-Teilnehmer zugeführt werden. Die zwischen dem Media Gateway Controller MGC und dem jeweils zu¬ geordneten Media Gateway übertragenen Daten werden von einem standardisierten Protokoll unterstützt. Dieses kann bei¬ spielsweise das MGCP oder das H.248 Protokoll sein. Zwischen den beiden Media Gateway Controllern MGC A, MGC B wird vor- zugsweise gemäß vorliegendem Ausführungsbeispiel das SIP Pro¬ tokoll verwendet. In den Signalisierungspfad können noch wei¬ tere Einrichtungen wie SIP-Proxies oder SIP Einheiten SIP E geschaltet sein.
In Fig. 2 ist der Ausfall einer SIP Einrichtung HWEl aufgezeigt. Dies kann beispielsweise die in Fig. 1 aufgezeigte SIP Proxy-Einrichtung sein. Der Ausfall der Einrichtung HWEl wird von der Einrichtung HWE2 verifiziert. Letztere übernimmt die Funktion der Einrichtung HWEl hat aber gemäß vorliegendem
Ausführungsbeispiel noch keine Information über die die SDP Daten der beiden Endpunkte.
Es wird nun von der Einrichtung HWE2 eine weitere, zuvor schon sich im Signalisierungspfad befindende Einrichtung (z. B. SIP E) angesprochen, diese Information zu übermitteln. Dies erfolgt durch Senden einer Re-INVITE Nachricht ohne SDP Information. Ferner erfolgt eine zusätzliche Festlegung, dass die SIP Session Timer Überwachungsfunktion ab sofort von der Einrichtung HWE2 aus durchgeführt wird. Der SIP Partner SIP E quittiert (entweder weil er selbst sich angesprochen fühlt, oder die Anforderung weiterreicht und darauf seinerseits eine Quittung erhält und diese weiterreicht) die empfangene Re- INVITE Nachricht ohne SDP Information mit einer 200 OK Quit- tung, die die gewünschte SDP Information umfasst (RFC3264) . Damit wissen beide Endpunkte dass der CaIl in Ordnung ist. Vergebührung und CaIl brauchen nicht beendet zu werden. Dies ist möglich bzw. nicht erforderlich, weil trotz Ausfall der Einrichtung HWEl, welche nur die SIP Signalisierung bereit- stellt, das beispielsweise zugehörige Media Gateway oder an¬ dere angeschlossene SIP Clients sehr wohl noch funktionstüch¬ tig ist, wodurch die Teilnehmer noch mit einander sprechen können und den Ausfall der Einrichtung HWEl nicht bemerken. Damit erhält die Einrichtung HWE2 nun auch den aktuellen Stand der SDP Daten, womit das aufwendige und ständige Repli¬ zieren zwischen den Einrichtungen HWEl und HWE2 auf der in- takten Einrichtung HWE2 nicht mehr erforderlich ist. Dies spart Dynamik (CPU Zeit) und Hardware und damit Kosten.
In Fig. 3 ist der gesamte Funktionsablauf für die A-Seite und die B-Seite aufgezeigt. Nach Erkennen des Hardwareausfalls fragt die Einrichtung HWE2 mit Hilfe der standardkonformen Re-INVITE Nachricht - wie soeben beschrieben - die SDP Information von der B-Seite ab (Re-INVITE ohne SDP) . In der Antwort in der 200 OK Quittung ist die SDP Information der B- Seite geführt, womit die Einrichtung HWE2 nun die empfangene SDP Information der B-Seite (SDP B) speichern kann.
Gleichzeitig wird diese Information SDP B nun in einer Re- INVITE Nachricht zur A-Seite gesendet. Die A-Seite antwortet Ihrerseits mit der eigenen SDP Information SDP A in der 200 OK Quittung. Die Information SDP A wird wiederum in der Einrichtung HWE2 gespeichert. Gleichzeitig wird sie (SDP A) in einer ACK Meldung zur B-Seite gesendet. Mit diesem Ablauf hat die Einrichtung HWE2 wiederum alle Daten zur erfolgreichen Behandlung von Features gespeichert. Der CaIl muss bei nach¬ folgenden Featureanforderungen nicht mehr ausgelöst werden. Nachfolgenden Features wie z. B. SIP Sessiontimer Ablauf müssen nicht mehr durchgereicht werden, sondern werden am jeweiligen Endpunkt des B2BUA behandelt. Die beteiligte A- und B- Seite wurden benutzt um die Synchronisation wieder herzustellen.
Gleichermaßen können Racekonditions auftreten. Dies bedeutet, dass die Einrichtung HWE2 nicht rechtzeitig dazukommt die o- ben beschrieben Re-INVITE Nachricht zu senden, bevor vom entfernten Ende selbst eine Re-INVITE Nachricht (mit oder ohne SDP) (featureanforderung durch User Aktivität) kommt. Dies ist insbesondere deshalb von Bedeutung, weil die Einrichtun¬ gen HWEl und HWE2 als hochintegrierte Hardwareeinheiten dazu ausgelegt sind viele Calls gleichzeitig zu kontrollieren. Entsprechend wird diese empfangene Nachricht dann auch be- nutzt, um die aktuellen SDP Daten auf der Einrichtung HWE2 zu restaurieren.
In Fig. 4 sind die entsprechenden Verhältnisse aufgezeigt. Hier wird die empfangene Re-INVITE Nachricht akzeptiert, die SDP Daten der B-Seite SDP B gespeichert, und auf die Re- INVITE Information zur A-Seite gemapped. Die A-Seite beant¬ wortet dies Ihrerseits mit den eigenen SDP Daten SDP A. Diese werden wiederum in der Einrichtung HWE2 gespeichert und mit der 200 OK Quittung zur B-Seite gesendet. Auch hier ist die
Einrichtung HWE2 wieder voll im Bilde. Im Falle des Empfanges von UPDATE mit SDP oder einer Re-INVITE ohne SDP wird dasselbe generelle Verfahren angewendet und standardgemäß gemapped.
Vorteilhaft ist, dass alle oben beschriebenen Abläufe auch in einer Einrichtung, die das Interworking von SIP/ SIP-T zu H323, VoDSL, VT oder BICC bereitstellt, zum Ablauf kommen können. Dies bedeutet beispielsweise, dass die Re-INVITE Nachricht zur A-Seite im Falle des SIP Protokolles bei Ver- wendung des BICC Protokolles in eine „bearer redirection re- quest" umgewandelt wird. Im Falle des MGCP Protokolles würde es zu einer standardgemäßen MDCX Nachricht (mit SDP oder ohne SDP, implementierungsabhängig) entsprechend der Anforderung, das MG bzw. IAD (Integrated Access Device) zu unterrichten umgewandelt werden. Die Antwort MDCX ACK kann dann wieder auf die 200 OK Quittung mit SDP A gemapped werden. Alternativ kann auch ein DLCX und CRCX Zyklus angewendet werden. Für die anderen Protokolle wird ebenso Verfahren.
Im Ausführungsbeispiel wurde davon ausgegangen, dass eine SIP Einrichtung ausfällt. Gleichermaßen kann auch eine MGCP (o- der H.248) Einrichtung ausfallen. Um auch in diesem Scenario weitere Features behandeln zu können, wird anstatt den CaIl auszulösen, eine DLCX und CRCX Nachricht ohne SDP gesendet, und die CRCX ACK mit dem lokalen SDP zur anderen Seite gesendet. Alternativ ist auch die Nutzung von MDCX anstatt DLCX/CRCX möglich. Bei einem Interworking zu SIP wird dann daraus eine SIP Re-INVITE/oder UPDATE mit SDP. Die SIP Ant¬ wort wird wiederum in eine MDCX Nachricht mit dem SDP der re- mote Seite umgesetzt. Dadurch hat die MGCP Einrichtung je¬ weils auch die Möglichkeit die SDP Daten zu speichern.
Es ist zu beachten, dass alle oben beschriebenen Abläufe auch in einer Einheit, die das Interworking von MGCP zu H323, VoDSL, VT, SIP oder BICC bereitstellt, zum Ablauf kommen kön¬ nen. Entsprechend bei BICC wird die CRCX ACK mit SDP auf eine BICC bearer redirect request message oder im Falle des MGCP Protokolls auf eine MDCX mit SDP gemapped.
Schließlich ist zu beachten, dass die für SIP vorgeschlagene Lösung auch auf die Protokolle MGCP (RFC2705) und MEGACO (ITU-T H.248) übertragen werden kann, da dort grundsätzlich dieselben Probleme auftreten.

Claims

Patentansprüche
1. Verfahren zur Aufrechterhaltung von Verbindungen, die in eine Signalisierungsverbindung und eine Bearerverbindung ge- trennt sind, wobei die Signalisierungsverbindung über eine Mehrzahl von Einrichtungen und Knoten geführt wird, wobei in letzteren endpunktbezogene Daten gespeichert sind, dadurch gekennzeichnet, dass bei Unterbrechung einer Einrichtung (HWEl) die Signali- sierungsverbindung über eine redundanten Einrichtung (HWE2) geführt wird, die die endpunktbezogenen Daten (SDP) über protokollbezogene Meldungen einem oder mehreren benachbarten Knoten oder Einrichtungen entnimmt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass als Übertragungsprotokoll das SIP oder SIP-I/T Protokoll zur Anwendung gelangt.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass als Übertragungsprotokoll das BICC Protokoll zur Anwen¬ dung gelangt .
4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass als Übertragungsprotokoll das H.248 Protokoll zur Anwen¬ dung gelangt .
5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass als Übertragungsprotokoll das MGCP Protokoll zur Anwen¬ dung gelangt .
6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei einem Empfang einer Re-INVIE Nachricht und einem In- terworking von SIP zu BICC, welches intern im Knoten oder nach extern benutzt wird, die Re-INVITE Nachricht auf die BICC „bearer redirection" Prozedur gemappt wird.
7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der benachbarte Knoten als Endgerät ausgebildet ist.
EP05794712A 2005-02-22 2005-09-19 Verfahren zur aufrechterhaltung von sip calls bei hardwareausfall redundanter ip systeme Withdrawn EP1856920A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005008052 2005-02-22
PCT/EP2005/054653 WO2006089592A1 (de) 2005-02-22 2005-09-19 Verfahren zur aufrechterhaltung von sip calls bei hardwareausfall redundanter ip systeme

Publications (1)

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

Family

ID=35445802

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05794712A Withdrawn EP1856920A1 (de) 2005-02-22 2005-09-19 Verfahren zur aufrechterhaltung von sip calls bei hardwareausfall redundanter ip systeme

Country Status (2)

Country Link
EP (1) EP1856920A1 (de)
WO (1) WO2006089592A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3253033A1 (de) * 2006-12-29 2017-12-06 Huawei Technologies Co., Ltd. Verfahren und vorrichtung zur dienstverarbeitung nach netzwerkelementausfällen

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2006089592A1 (de) 2006-08-31

Similar Documents

Publication Publication Date Title
DE60014234T2 (de) System und Verfahren zum Ermöglichen von Fehlertolerante Systeme
DE60014492T2 (de) System und Verfahren zur direkten Benutzer-Signalisierung in H.323 Kommunikationsnetzen
EP1561328B1 (de) Übertragung von anrufsteuerungsparametern zwischen zwei media gateway controllern in sip/sip-t netzen --------------------------------------------------------------------------------------
EP2073480B1 (de) Verfahren zur Zuordnung von zumindest einer Nutzdatenverbindung zu zumindest einer Multiplexverbindung
EP1656781A1 (de) Verfahren, software-produkt und vorrichtungen zur signalisierung der modifikation von bearerverbindungen mittels sip protokoll
EP1505842A2 (de) Verfahren zum Umsteuern einer Bearerverbindung (Bearer Redirect) für SIP/ SIP-T Teilnehmer
EP1309165A1 (de) Verfahren zum Umschalten zwischen einer Sprachübermittlung und einer Faxübermittlung, Vorrichtung und Computerprogrammprodukt
EP1227632B1 (de) Verfahren zum Betrieb eines Multimedia-Kommunikationsnetzwerkes
EP1714473A1 (de) Aufbau einer paketorientierten multimediaverbindung unter mitwirkung eines interactive voice responce systems
WO2006089592A1 (de) Verfahren zur aufrechterhaltung von sip calls bei hardwareausfall redundanter ip systeme
DE102004040480B4 (de) Verfahren und Vorrichtung zum Nutzdatenabgriff multimedialer Verbindungen in einem Paketnetz
EP1658719B1 (de) Verfahren zur Steuerung eines Media Gateways
EP1305918B1 (de) Verfahren zum übertragen von sprachdaten über verschiedene arten von netzen sowie zugehörige einheiten
WO2006134034A1 (de) Verfahren zur steuerung des leistungsmerkmals 'sip call-transfer'
DE10147148A1 (de) Netzübergangseinrichtung und Kommunikationssystem für Echtzeitkommunikationsverbindungen
DE10226901B3 (de) Verfahren zur Verbindungssteuerung in einem paketorientierten Kommunikationsnetz sowie Anordnungen zu seiner Durchführung
EP1342347B1 (de) Verfahren zum übertragen von daten verschiedener anwendungen über ein paketübertragungsnetz, zugehörige einheiten und zugehöriges programm
DE102004002680A1 (de) Adaptereinheit und Verfahren
EP2279603B1 (de) Vorrichtung und Verfahren zur Neuverhandlung einer Multimediaverbindung sowie zugehöriges Kommunikationssystem, digitales Speichermedium, Computer-Programm-Produkt und Computerprogramm
DE102005057244B4 (de) Verfahren zur Kommunikation zwischen Endgeräten in SIP-Netzen
EP1841161A1 (de) Verfahren zur gesicherten Nutzdatenübertragung
EP1396969B1 (de) Verfahren zur Einrichtung einer Faxverbindung über ein paket-orientiertes Netzwerk
DE102005045121B4 (de) Vorrichtung zur Unterstützung des Leistungsmerkmals "Fall-back" in SIP-Netzen
DE102005007419A1 (de) Verfahren zur Sicherung der Kommunikationsverbindungen und der zugehörigen Vergebührungen in einem redundanten Kommunikationsnetzwerk
WO2007014833A1 (de) Verfahren zur unterstützung der leistungsmerkmale 'call hold', 'conference calling' und 'three-party service' in fmc netzen

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

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

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

17Q First examination report despatched

Effective date: 20130129

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

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

Owner name: NOKIA SOLUTIONS AND NETWORKS GMBH & CO. KG

18D Application deemed to be withdrawn

Effective date: 20130611