EP1844603A1 - Verfahren zur sicherung der kommunikationsverbindungen und der zugeh\rigen vergeb]hrungen in einem redundanten kommunikationsnetzwerk - Google Patents

Verfahren zur sicherung der kommunikationsverbindungen und der zugeh\rigen vergeb]hrungen in einem redundanten kommunikationsnetzwerk

Info

Publication number
EP1844603A1
EP1844603A1 EP05822337A EP05822337A EP1844603A1 EP 1844603 A1 EP1844603 A1 EP 1844603A1 EP 05822337 A EP05822337 A EP 05822337A EP 05822337 A EP05822337 A EP 05822337A EP 1844603 A1 EP1844603 A1 EP 1844603A1
Authority
EP
European Patent Office
Prior art keywords
hardware units
sip
terminals
hardware
failure
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
EP05822337A
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
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 EP1844603A1 publication Critical patent/EP1844603A1/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/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
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching 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
    • 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/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/56—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP for VoIP communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/63—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP based on the content carried by the session initiation protocol [SIP] messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • H04M15/8292—Charging for signaling or unsuccessful connection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/08—Indicating faults in circuits or apparatus
    • H04M3/12—Marking faulty circuits "busy"; Enabling equipment to disengage itself from faulty circuits ; Using redundant circuits; Response of a circuit, apparatus or system to an error
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2254—Arrangements for supervision, monitoring or testing in networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/24—Arrangements for supervision, monitoring or testing with provision for checking the normal operation
    • H04M3/248—Arrangements for supervision, monitoring or testing with provision for checking the normal operation for metering arrangements or prepayment telephone systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/20—Technology dependant metering
    • H04M2215/202—VoIP; Packet switched telephony

Definitions

  • the invention relates to a method for securing the kommunikationseducationen and the associated Verryungen in a redundant communication network, communicate with the terminals via mediators, preferably an IP bearer, by means of messages, with a monitoring function, the correct function of the terminals and / or the hardware units are monitored and in case of failure of one or more hardware units, the still functioning hardware units take over the physical functions of the failed hardware units.
  • MGC-MGC communication MGC
  • IP Internet Protocol
  • the RFC 2976 (INFO Method) was adopted, which allows to transport ISUP messages that could not be mapped to the messages defined by the RFC 2543 or RFC 3261.
  • NGN Next Generation Network
  • the SDP Session Description Protocol in this case includes the exact description of the properties of the currently used RTP bearer, for example the iP address, the RTP port, the used CODEC s, also called payload types, the state of the echo canceler, the state of the bearer, the SDP version counter and more.
  • a stable call is a call which, by lifting the telephone receiver, reaches the state: "subscriber has answered” and no other feature is activated, such as call hold or other call data has been lost and SIP session timer re-INVITE can no longer be answered, since in particular the session description protocol in the session initiation protocol is used to control functions such as call hold, bearer redirection, CODEC switchover of the bearer this means the unnecessary provision of storage and computational capacity for a stable calendar that does not really need this storage and computational capacity.
  • Modern z. B. Software based architectures provide exactly this separation between application and signaling transport, such. B. in the communication systems hiQ6200 and hiQ9200 of the applicant.
  • SMP simple symmetry processor
  • SIP applications have interfaces to a central SIP transport function or location.
  • transport functional parts are provided by third party manufacturers (OEM) or a software development unit of the applicant and incorporated into the products.
  • the SIP transport layer keeps a record of whether a response to a sent message exists between a hardware unit of the network (transport part) and a terminal has been received and sends the message again after expiration of a timer-controlled period according to RFC3261, chapter 17.1.2.2, if this answer is pending.
  • the SIP application is also informed if the answer is completely absent, so that the SIP application is left to proceed, such. B. a trigger or another attempt to another target, etc.
  • Standby page in case of failure of the whole unit and thus also failure of the software and the associated data of the transaction of the transport part
  • a single network manufacturer can have no influence on the structure of the transport part in order, for example, to be able to seamlessly integrate the transport part into the own software-based structure and architecture, because manufacturers of the transport function offer as much software as possible for all potential network manufacturers. This makes it impossible for the network manufacturer to restore states of the transport part on a redundant hardware unit. Nevertheless, the network manufacturer must guarantee the telecommunications service provider the efficient use of its network, such as: B. in the sense of no hanging of resources.
  • the replacement solution of the failed hardware unit by the functioning hardware unit remains at a charging level for the telecommunications service provider or for the user of a terminal in conjunction with at least one of the two hardware units very questionable. If, in the case of an unstable call, a transaction is open in the event of a default, it is possible, for example, to B. if a billing message is lost, unwanted overbilling will occur.
  • a still existing transaction eg. B. is triggered by a failure unit or simply to be taken into account, overcharges for this transaction are avoided.
  • the inventor proposes the known method for securing the communication connections and the associated charging in a redundantly structured communication network, in which terminals are distributed via intermediaries, preferably an IP bearer, and via hardware units
  • the correct function of the terminals and / or the mediator (2) and / or the hardware units is monitored and in case of failure of one or more hardware units, the still functioning hardware units take over the physical functions of the failed hardware units, to improve that immediately after taking over the physical functions, the functional hardware units transmit a message to the participating terminals and additionally specify that the monitoring function is performed by the still functioning hardware units.
  • a license plate is transmitted from one or more of the failed hardware units to one or more of the functional hardware units, so that over-charging for this transaction is avoided.
  • the redundantly constructed communication network can be a SIP communication network and the transmitted messages are SIP messages.
  • the terminals which receive a message from the functional hardware units return an answer to them.
  • the involved SIP terminal may send a 200 OK in response to the UPDATE.
  • SIP Session Timer Session Initiation Protocol
  • the SIP Session Timer monitoring function can determine whether the terminals or hardware components involved send or receive an INVITE or UPDATE message using the UPDATE message without SDP. This determines the role of the SIP endpoint. This is particularly advantageous since the other party no longer has to send a re-INVITE with the Session Description Protocol, which then in turn, in turn, with the no longer necessarily existing Session Description Protocol with all its aspects in the response to the re-INVITE would have to be answered. The effort to connect the new hardware unit with the previous terminal, after taking over the functions of the failed hardware unit is therefore kept smaller than previously in the new process.
  • the billing is performed by a SIP proxy, preferably a proxy server.
  • the message UPDATE can be sent to both communicating terminals after the physical functions have been taken over by the functional hardware units so that the call is not triggered. Where the page waiting to receive the periodic re-INVITE / UPDATE will trigger the call when the message is received.
  • billing may be further performed or stopped depending on the response of the terminals if no response comes from the terminals. If, for example, a reply to a message of a functional hardware unit to the participating terminal with a negative response, it can be concluded that this page is still functional and the call and the charge can continue to run.
  • Figure 1 Schematic structure of a SIP Gaynikationsnet- zes
  • Figure 2 schematic diagram showing the failure of a hardware unit and the subsequent steps explained in the new method.
  • FIG. 1 shows a schematic structure of a SIP communication network 1.
  • SIP communication network 1 communication terminals 7.1-7.X, preferably simple telephone sets, are connected to one another via an intermediary, here an IP bearer 2.
  • the communication terminals 7.1-7. X are connected to Public Switched Telephone Networks 6.
  • computers 12 can also communicate with one another via this SIP communication network 1 and the transfer of SIP messages 13 taking place therein.
  • the invention also covers networks in which SIP terminals are connected directly to a SIP proxy in a pure SIP domain, without a public telecommunications network PSTN 6.
  • the network operator would also like to ensure the failure of one or more hardware units of the SIP communication network 1, so that on the one hand the billing for the existing communication connections can be billed correctly and continue.
  • the users of the SIP Communication network 1 despite failure the usual services without waiting time are available.
  • a new simple method is presented, which enables the securing of the communication connections and the associated billing in a SIP communication network.
  • FIG. 2 shows a schematic diagram in which a failure 14.1 of a hardware unit, in this case the first hardware unit 14, is shown, which, for example, is shown in FIG. Outwardly as a unit within units 8 or 9, for example, communicating via the SIP protocol (eg, the MGCP could run between units 8 and 3).
  • the failure 14.1 of the first hardware unit 14 is represented by the X symbol.
  • FIG. 2 schematically shows how the second hardware unit 15 performs the tasks of the failed first hardware unit 14 and which steps are initiated for this purpose in the new method.
  • the hardware units 14 and 15 in a communication network have a redundant connection 16 with one another, so that a takeover of the function of the failed hardware unit 14 by the still functional hardware unit 15 is made possible.
  • Session Initiation Protocol SIP
  • SIP Session Initiation Protocol
  • the second hardware unit 15 will assume the function of the first hardware unit 14 in accordance with the redundant structure of the communication network. So far, the first hardware unit 14 was connected to a SIP terminal 11, such as a telephone and / or a computer. The connection of the first hardware unit 14 to the SIP terminal 11 is not shown in FIG. After failure 14.1 of the first hardware unit 14, the second hardware unit 15 is connected to the SIP terminal 11 and communicate with it.
  • the second hardware unit 15 in the new method sends a message 17 to the SIP terminal 11, here a SIP UPDATE.
  • the SIP UPDATE is a SIP message or a possible method, which is defined in RFC3311 and is not excluded in the SIP Session Timer draft, which can indicate a change of the SIP call without omitting the Session Description Protocol of the communication. onsnetztechnikes to use.
  • the message 17 may include the additional stipulation that the SIP session timer monitoring function is performed immediately from here, ie from the second hardware unit 15.
  • the SIP session timer monitoring function can specify which of the two parties involved, ie the second hardware unit 15 or the SIP terminal 11 should send the messages INVITE or UPDATE to determine the readiness and presence of the other party.
  • the message INVITE is a SIP message which can establish a connection or, on the other hand, makes it possible for an existing stable connection to change the connection data as re-INVITE. It can also be used for the SIP Session Timer procedure.
  • the determination that the second hardware unit 15 will be the new communication partner of the SIP terminal 11 can thus be determined independently of the previous history on the first hardware unit 14 by the second hardware unit 15. This is particularly advantageous, as it means that the other party can no longer send a re-INVITE with the Session Description Protocol, which then in turn, with the not necessarily existing Session Description Protocol with all its aspects in the response 18, here a 200 OK to re-INVITE, would have to be answered.
  • both the second hardware unit 15 and the SIP terminal 11 know that the call or the connection is in order and the charging and the call need not be terminated.
  • failure 14.1 of the first hard- Waresko 14, which provides only the SIP signaling the associated communication network is still very functional, and the communication participants can still speak or communicate with each other, and the failure 14.1 of the first hardware unit 15 has no effect.
  • the second hardware unit 2 will judge this reaction as an acknowledgment, after which the other party is still functional, and the call and billing can continue.
  • the transmission of the UPDATE is to be carried out to both sides of the connection.
  • ISDN Integrated Services Digital Network service integrating digital telecommunication network

Abstract

Die Erfindung betrifft ein verfahren zur Sicherung der Kommunikationsverbindungen und der zugehörigen Vergebührungen in einem redundant aufgebauten Kommunikationsnetzwerk 1, bei dem Endgeräte 7.1-7.x 11, 12 über Vermittler 2, vorzugsweise einem IP Bearer, und über Hardwareeinheiten 14, 15 mittels Nachrichten 13 kommunizieren, wobei mit einer Überwachungsfunktion die korrekte Funktion der Endgeräte 7.1-7.x, 11, 12 und/oder des Vermittlers 2 und/oder der Hardwareeinheiten 14, 15 überwacht wird und beim Ausfall 14.1 einer oder mehrerer Hardwareeinheiten 14, 15 die noch funktionsfähigen Hardwareeinheiten 15 die physischen Funktionen der ausgefallenen Hardwareeinheiten 14 übernehmen, wobei unmittelbar nach der Übernahme der physischen Funktionen die funktionsfähigen Hardwareeinheiten,15 den beteiligten Endgeräten 7.1-7.x, 11, 12 eine Nachricht 17 übermitteln und zusätzlich festlegen, dass die Überwachungsfunktion von den noch funktionsfähigen Hardwareeinheiten 15 ausgeführt wird. Weiterhin wird bei einer noch bestehenden Transaktion ein Kennzeichen aus einer der ausgefallenen Hardwareeinheiten 14 an eine der funktionsfähigen Hardwareeinheiten 15 übermittelt, so dass Übervergebührungen zu dieser Transaktion vermieden werden.

Description

Beschreibung
Verfahren zur Sicherung der Kommunikationsverbindungen und der zugehörigen Vergebührungen in einem redundanten Kommuni- kationsnetzwerk
Die Erfindung betrifft ein Verfahren zur Sicherung der Kommu- nikationsverbindungen und der zugehörigen Vergebührungen in einem redundant aufgebauten Kommunikationsnetzwerk, bei dem Endgeräte über Vermittler, vorzugsweise einem IP Bearer, mittels Nachrichten kommunizieren, wobei mit einer Überwachungs- funktion die korrekte Funktion der Endgeräte und/oder der Hardwareeinheiten überwacht wird und beim Ausfall einer oder mehrerer Hardwareeinheiten die noch funktionsfähigen Hard- wareeinheiten die physischen Funktionen der ausgefallenen Hardwareeinheiten übernehmen.
Durch die Einführung von MGC-MGC - Kommunikation (= Media Gateway Communication (= MGC) mit der Anwendung der günstigen Bearertechnologie, wie Internet Protocol (= IP) , wird für die Kommunikation der Kommunikations- beziehungsweise Nutzkanal durchgeschaltet . Die MGC-MGC Kommunikation kommt in den Fällen zum Einsatz , in denen eine Auflösung beziehungsweise eine Trennung vom Verbindungsaufbau, Mediumaufbau oder Bearerauf- bau durchgeführt wird, also im Falle einer Auflösung beziehungsweise einer Trennung zwischen Kommunikationsendgerät und (Daten- ) Übermittler . Zurzeit sind mehrere standardisierte Verfahren im Einsatz, die im Falle einer Auflösung beziehungsweise eine Trennung vom Verbinddungsaufbau versuchen die Dienste im Telekommunikationsnetz aufrecht zu erhalten.
Gegenwärtig gibt es beispielsweise den ITU-T Standard (= International Telecommunication Union - Telecomunication Sta- dardisation Sector) Q .1902.x Bearer lndependent CaIl Control Capability Set 2 ( = BICC CS2 ) mit einer eigenen Anzeigefunktion (= Service Indicator) beim Nachrichtentransfer (= Message Transfer Part; = MTP) . Dabei beschreibt der Q765.5 Bearer Application Transport (= BAT) für IP Bearer RTP (= Real Time Transport Protocol ) als Bearertechnologie, wie es möglich ist , bei der Trennung eines Anrufs (= CaIl) und des Vermittlers ( = Bearer) , dem Endkunden seine gewohnten Dienste im Te- lekommunikationsnetz bereitzustellen.
Als Weiterentwicklung sind in der Zwischenzeit bei IETF ( = Internet Engineering Task Force) der RFC 3261 (= Session Initiation Protocol = SIP) und der RFC 3204 (ISUP MIME Type) als Standard entstanden, welche den Tunneltransport von ISUP (= ISDN User Part) Nachrichten in Session Initiation Protocol- Nachrichten erlaubt .
Als zusätzlicher Standard wurde der RFC 2976 (INFO Method) verabschiedet, welcher es erlaubt, ISUP Nachrichten zu transportieren, die nicht auf die durch den RFC 2543 oder RFC 3261 definierte Nachrichten abgebildet werden konnten.
Mit zunehmender Akzeptanz der NGN (= Next Generation Network) Architektur werden die Lösungen bezüglich der Sicherung der Verfügbarkeit der zugehörigen Netzwerkeinrichtungen zur Sicherstellung der Kommunikationsservices und hinsichtlich der Bereitstellung von gesicherten Vergebührungsdaten auch bei Hardwareausfällen immer wichtiger . Insbesondere die Netz- betreiber erwarten die Sicherstellung der bisher bekannten
Funktionalitäten auch bei Hardwareausfällen hochzentralisierten Hardwareeinrichtungen, die die Signalisierungsprotokolle zwischen mehreren MGC s und entsprechenden Endgeräten bereitstellen. Zusätzlich sind insbesondere Ausfallszenarien von erheblicher Bedeutung, die bei Nichtberücksichtigung der auftretenden Phänomenen zu „hängen bleibenden Ressourcen" führen. Dies ist von Bedeutung, da Ressourcen des Netzes unrichtigerweise für neue Belegungen nicht mehr zur Verfügung stehen, was zu einem Geschäftsverlust des Betreibers des Netzes führt . Gerade das Session Initiation Protocol bei RFC3261 stellt erhöhte Anforderungen an die Sicherung eines Anrufs ( = Calls) , damit dort die für den CaIl relevanten Daten, die beim CaI- laufbau standardgemäß dynamisch ausgehandelt werden und dem- entsprechend bei Ausfall wieder restauriert werden müssen, bei diesem CaIl nicht verloren gehen. Gleichzeitig besteht j edoch auch weiterhin zur Kontrolle der Ressourcen im Netz die Forderung, dass auch in diesem Fall sichergestellt wird, dass der CaIl selbst und die Vergebührung nicht unterbrochen wird und auch korrekt wieder- bzw. freigegeben werden kann.
Gegenwärtig wird in Kommunikationsanlagen, beispielsweise der hiE9200 der Anmelderin, solange kein Ausfall stattfand, beim Session Initiation Protocol auf Grund des Session Timer Draft die Gegenseite mit Hilfe einer Überwachungsfunktion, beispielsweise durch re-INVITE mit dem Session Description Protocol überwacht, um die Verbindung und die Vergebührung gegebenenfalls zu stoppen, falls die Gegenseite ausgefallen ist .
Das SDP (= Session Description Protocol umfasst in diesem Fall die genaue Beschreibung der Eigenschaften des derzeit verwendeten RTP Bearers , zum Beispiel die iP-Adresse, den RTP Port , die verwendete CODEC s , auch mit Payload types bezeichnet, den Zustand des Echo Cancelers , den Durchschaltezustand des Bearers , den SDP Versionszähler und weiteres mehr .
Dies erfordert insbesondere für beide beteiligten Netzwerkeinheiten, wie Endgerät und Datenübermittler, dass sie diese Session Description Protocol Daten auch zusätzlich bei einem Hardwareausfall zur vollen Unterstützung auf der Ersatzhardware restaurieren müssen . Hierdurch wird insbesondere die präventive Bereitstellung von Speicherplatz und zusätzlich Rechnerkapazität/-zeit beziehungsweise Prozessorzeit zur Sicherung und zum Wiederherstellen dieser Daten auf der Ersatz- hardware notwendig, um die derzeit implementierte Prozedur voll zu unterstützen. Wird dieser Industriestandard (SIP Session Timer Prozedur) nach einem Hardwareausfall nicht berück- sichtigt , so würde ein stabiler CaIl unnötigerweise ausgelöst , wenn die entsprechenden Calldaten nicht vollkommen wie¬ derhergestellt werden können. Ein stabiler CaIl ist ein CaIl, welcher durch Abheben des Telefonhörers den Zustand: „Teil- nehmer hat sich gemeldet" erreicht und kein weiteres Feature aktiviert ist, wie zum Beispiel CaIl hold. Das Auslösen eines stabilen Calls ergibt sich dadurch, dass die SDP Daten oder auch andere Calldaten verloren gegangen sind und auf SIP Session Timer re-INVITE nicht mehr geantwortet werden kann. Da insbesondere das Session Description Protocol im Session Initiation Protocol zur Steuerung von Funktionen, wie CaIl Hold, Bearer Redirection, CODEC Umschaltung des Bearers , verwendet wird, bedeutet dies die unnötige Bereitstellung von Speicherund Rechenkapazität für einen stabilen CaIl, der diese Spei- eher- und Rechenkapazität nicht wirklich braucht .
Im RFC 3261 (= Session Initiation Protocol = SIP) wird eine klare Trennung zwischen einer SIP-CaIl Prozessapplikation und dem reinen SIP-Transportfunktion eingeführt . Moderne z . B. Software basierte Architekturen sehen genau diese Trennung zwischen Applikation und Signalisierungstransport vor, wie z . B . bei den Kommunikationsanlagen hiQ6200 und hiQ9200 der Anmelderin. Insbesondere bei einer SMP- (simple Symmetrie pro- cessor) -Architektur haben mehrere SIP-Applikationen Schnitt- stellen zu einer zentralen SIP-Transportfunktion bzw. -ort . Üblicherweise werden Transportfunktionsteile von dritten Herstellern (OEM) oder einer Softwareentwicklungseinheit der Anmelderin bereitgestellt und in die Produkte eingefügt .
Erste Lösungen für eine Rettung einer stabilen Verbindung und Weiterführungen einer korrekten Vergebührungen dieser stabilen Verbindung sind in der Praxis festgelegt und beschrieben. Von wichtiger Bedeutung ist die Problematik, die mit der Nutzung einer abgekapselten SIP-Transportschicht einhergeht . Die SIP-Transportschicht führt insbesondere Buch darüber, ob eine Antwort zu einer ausgesendeten Nachricht zwischen einer Hardwareeinheit des Netzes (Transportteil ) und einem Endgerät empfangen wurde, und sendet die Nachricht nach Ablauf einer mittels Timern kontrollierten Dauer nochmals gemäss RFC3261 , Kapitel 17.1.2.2 , falls diese Antwort aussteht . Insbesondere wird die SIP-Applikation auch davon unterrichtet , wenn die Antwort ganz ausgeblieben ist, so dass der SIP-Applikation das weitere Vorgehen überlassen wird, wie z . B . ein Auslösen oder ein anderer Versuch zu einem anderen Ziel , etc .
Die verwendete Architektur und die Nutzung der Produkte von dritten Herstellern im Bereich der SIP-Transportschicht machen es den Netzwerkherstellern - wie die Anmelderin - unmöglich Strukturen des reinen SIP-Transportteiles soweit in Detail zu kennen, um eine dafür notwendige Duplizierung - d.h . eine Duplizierung von der aktiven Seite auf die zu diesem Zeitpunkt noch nicht aktive Seite - der Daten auf einer
Standby-Seite (bei Ausfall der ganzen Einheit und somit auch Ausfall der Software und der dazugehörigen Daten der Transaktion des Transportteils) für den Transportteil wiederherzustellen. Weiterhin kann ein einzelner Netzwerkhersteller kei- nen Einfluss auf die Struktur des Transportteils haben, um beispielsweise den Transportteil nahtlos in die eigene Software basierte Struktur und Architektur einbauen zu können, weil Hersteller der Transportfunktion Ihrerseits möglichst nur eine Software für alle potentielle Netzwerkhersteller an- bietet . Damit ist es dem Netzwerkhersteller unmöglich, auf einer redundanten Hardwareeinheit Zustände des Transportteils wieder zu herstellen. Trotzdem muss der Netzwerkhersteller dem Telekommunikationsdienstanbieter die effiziente Nutzung seines Netzes garantieren, wie z . B . in Sinne von keinem Hän- genbleiben von Ressourcen.
Der grundsätzliche Ansatz zum Erkennen und zur weiteren Behandlung von Hardwareausfällen und der zugehörige Transfer von „Call Data" relevanten Daten auf eine Ersatzeinheit ist aus dem Stand der Technik bekannt . Dabei wird nur auf die SIP applikationsspezifischen und relevanten Anteile eingegangen . Üblicherweise wird ein Ausfall einer Netzwerkeinheit einfach durch Netzwerkoperatoren durch „Ziehen" der Ausfalleinheit nachgestellt werden.
Ausgehend von zwei Hardwareeinheiten des SIP Kommunikations- netzwerks , bei welchen eine ausfällt und die andere noch funktionsfähig ist, bleibt die Ersatzlösung der ausgefallenen Hardwareeinheit durch die funktionsfähige Hardwareeinheit auf einer Vergebührungsebene für den Telekommunikationsdienstan- bieter bzw. für den Benutzer eines Endgeräts in Verbindung mit mindestens einer der beiden Hardwareeinheiten sehr fraglich. Steht dazu im Falle eines unstabilen Calls eine Transaktion bei dem Ausfall offen, können z . B . bei einem Verlust einer Vergebührungsnachricht unerwünschte Übervergebührungen auftreten.
Es ist daher Aufgabe der Erfindung, ein Verfahren zur Sicherung der Kommunikationsverbindungen und der zugehörigen Ver- gebührungen in einem Kommunikationsnetzwerk zur Verbindung von Endgeräten, vorzugsweise in einem SIP Kommunikationsnetz- werk, zur Verfügung zu stellen, welches im Hardwareausfall die gewohnten Kommunikationsdienste bereitstellt, aber gegenüber den bisher bekannten standardisierten Sicherungsverfahren einfacher und mit wesentlich geringerer Speicher- und Rechenkapazität durchführbar ist . Gleichzeitig zu dem Hardware- ausfall sollte bei einer noch bestehenden Transaktion, die z . B . bei einer Ausfalleinheit ausgelöst wird oder einfach dort zu berücksichtigen ist, übervergebührungen zu dieser Transaktion vermieden werden.
Diese Aufgabe wird durch die Merkmale des unabhängigen Patentanspruches 1 gelöst . Vorteilhafte Weiterbildungen der Erfindung sind Gegenstand untergeordneter Ansprüche .
Der Erfinder hat erkannt, dass beim Standard RFC3261 bei Ses- sion Initiation Protocol und bei RFC3264 beim Session Desc- ription Protocol offer/answer und dem SIP Session draft (= Session Timers in the Session Initiation Protocol = draft- ietf-sip-session-timer-13 ) , die Möglichkeit zur Überwachung der SIP Gegenseite zur Verfügung steht . Im Kapitel 7.4 von: "Generating Subsequent Session Refresh Requests des SIP ses- sion drafts" wird die Verwendung der UPDATE Methode bei RFC3311 ermöglicht, ohne das Session Description Protocol (SDP :RFC2327 ) zu verwenden . Quelle : http : / /www, ietf . org/internet-drafts/draft-ietf-sip-session- timer-15. txt , wobei der Inhalt dieser Webseite vollinhaltlich in diese Anmeldung übernommen wird.
Deingemäss schlägt der Erfinder vor, das bekannte Verfahren zur Sicherung der Kommunikationsverbindungen und der zugehörigen Vergebührungen in einem redundant aufgebauten Kommuni- kationsnetzwerk, bei dem Endgeräte über Vermittler, Vorzugs- weise einem IP Bearer, und über Hardwareeinheiten mittels
Nachrichten kommunizieren, wobei mit einer Überwachungsfunk- tion die korrekte Funktion der Endgeräte und/oder des Vermittlers (2 ) und/oder der Hardwareeinheiten überwacht wird und beim Ausfall einer oder mehrerer Hardwareeinheiten die noch funktionsfähigen Hardwareeinheiten die physischen Funktionen der ausgefallenen Hardwareeinheiten übernehmen, dahingehend zu verbessern, dass unmittelbar nach der Übernahme der physischen Funktionen die funktionsfähigen Hardwareeinheiten den beteiligten Endgeräten eine Nachricht übermitteln und zu- sätzlich festlegen, dass die Überwachungsfunktion von den noch funktionsfähigen Hardwareeinheiten ausgeführt wird. Weiterhin wird bei einer noch bestehenden Transaktion (bei so genannten instabilen Calls ) ein Kennzeichen aus einer bzw. mehreren der ausgefallenen Hardwareeinheiten an eine bzw. mehrere die funktionsfähigen Hardwareeinheiten übermittelt , so dass Übervergebührungen zu dieser Transaktion vermieden werden.
Hierdurch wird erreicht, dass im Falle eines Ausfalles einer oder mehrerer Hardwareeinheiten die bestehenden oder erneut aufzubauenden Kommunikationsverbindungen und die zugehörigen Vergebührungen in einem Kommunikationsnetzwerk, vorzugsweise einem SIP Kommunikationsnetzwerk, weiterhin korrekt funktionieren und die gewohnten Kommunikationsdienste den Kommunikationsteilnehmern immer noch zur Verfügung stehen.
Beim redundant aufgebauten Kommunikationsnetzwerk kann es sich um ein SIP Kommunikationsnetzwerk handeln und bei den übermittelten Nachrichten um SIP Nachrichten.
Die beim (Hardware-) Ausfall bisher notwendige Restaurierung der betroffenen Calldaten, zum Beispiel über das Session
Description Protocol , mit dem einhergehenden notwendigen Einsatz von Speicher- und Rechenkapazität, kann durch Einsatz des neuen Verfahrens vermieden werden.
Für das Verfahren ist es von Vorteil, wenn die Endgeräte, die eine Nachricht von den funktionsfähigen Hardwareeinheiten bekommen, diesen eine Antwort zurücksenden . Beispielsweise kann das beteiligte SIP Endgerät eine 200 OK als Antwort auf die UPDATE senden. Hierdurch kann auf einfache Weise festgestellt werden, ob die bestehende Kommunikationsverbindung durch den Ausfall der Hardwareeinheit tatsächlich betroffen ist .
Weiterhin ist es vorteilhaft , wenn die Endgeräte und/oder die Hardwareeinheiten durch einen SIP Session Timer (Session Ti- mer im Session Initiation Protocol) überwacht werden. Hierdurch steht im SIP System eine einfache Methode der Überwachung der beteiligten SIP Kommunikationsgeräte zur Verfügung .
Die SIP Session Timer Überwachungsfunktion kann festlegen, ob die beteiligten Endgeräte oder die Hardwarekomponenten eine INVITE oder UPDATE Nachricht senden oder empfangen, wobei die UPDATE Nachricht ohne SDP verwendet wird. Hierdurch wird die Rolle des SIP Endpunkts festgelegt . Dies ist insbesondere vorteilhaft , da dadurch die Gegenseite nun nicht mehr eine re-INVITE mit dem Session Description Protocol senden muss , die dann standardgemäß wiederum mit dem nicht mehr notwendigerweise vorhandenen Session Description Protocol mit allen seinen Aspekten in der Antwort zur re-INVITE beantwortet werden müsste . Der Aufwand zur Verbindungsherstellung der neuen Hardwareeinheit mit dem bisherigen Endgerät, nach der Übernahme der Funktionen der ausgefallenen Hardwareeinheit, wird daher im neuen Verfahren geringer als bisher gehalten.
In einer Ausführung des Verfahrens wird die Vergebührung durch einen SIP Proxy, vorzugsweise einen Proxy Server, ausgeführt . Im Ausfall des SIP Proxy' s kann aus Sicherheitsgrün- den nach der Übernahme der physischen Funktionen durch die funktionsfähigen Hardwareeinheiten die Nachricht UPDATE an beide kommunizierenden Endgeräte gesendet werden, so dass der CaIl nicht ausgelöst wird. Wobei die Seite, die auf den Empfang der periodischen re-INVITE/UPDATE wartet , den CaIl aus- löst , wenn die Nachricht empfangen wurde .
Im neuen Verfahren kann die Vergebührung abhängig von der Antwort der Endgeräte weiter durchgeführt werden oder gestoppt werden, falls keine Antwort von den Endgeräten kommt . Wird beispielsweise auf eine Nachricht einer funktionsfähigen Hardwareeinheit zum beteiligten Endgerät mit einer negativen Response geantwortet, so kann daraus geschlossen werden, dass diese Seite noch funktionstüchtig ist und der CaIl und die Vergebührung weiterlaufen können.
Zusammengefasst werden stabile und unstabile Calls und deren Vergebührungen bei einem Hardwareausfall deutlich, korrekt und verlustfrei erkannt, sowie entsprechende Massnahmen (Auslösen des Calls , Beendigung der Vergebührung, etc) eingelei- tet .
Im folgenden wird die Erfindung anhand der bevorzugten Ausführungsbeispiele mit Hilfe der Figuren näher beschrieben, wobei darauf hingewiesen wird, dass nur die für das unmittel- bare Verständnis der Erfindung wesentlichen Elemente gezeigt sind. Hierbei werden die folgenden Bezugszeichen verwendet : 1 : SIP Kommunikationsnetz ; 2 : IP Bearer / Übermittler; 3 : Te- lekommunikationsanlage / hiGlOOO ; 4 : TX (= Transit Exchange) ; 5 : LE (= Local Exchange) ; 6 : PSTN (= Public Switched Telefon Network) ; 7.1-7.X: Kommunikationsendgerät / Telefon; 8 : Media Knoten / hiQ9200 ; 9 : CMN CaIl Mediation Node aus BICC ITU-T Q .1901 ,- 10 : SIP Proxy; 11 : SIP Endgerät; 12 : Computer; 13 : Transfer von SIP Nachrichten; 14 : erste Hardwareeinheit; 14.1 : Ausfall der ersten Hardwareeinheit; 15 : zweite Hardwareeinheit; 16 : redundante Verbindung erste und zweite Hard¬ wareeinheit; 17 : Nachricht / UPDATE; 18 : Antwort auf Nach- rieht UPDATE / 200 OK.
Es zeigen im Einzelnen:
Figur 1 : Schematischer Aufbau eines SIP Kommunikationsnet- zes ;
Figur 2 : Prinzipskizze, die den Ausfall einer Hardwareeinheit zeigt und die darauf folgenden Schritte im neuen Verfahren erläutert .
Die Figur 1 zeigt einen schematischen Aufbau eines SIP Kommunikationsnetzes 1. In diesem SIP Kommunikationsnetz 1 werden Kommunikationsendgeräte 7.1-7.X, vorzugsweise einfache Telefonapparate, über einen Vermittler, hier ein IP Bearer 2 miteinander verbunden. Die Kommunikationsendgeräte 7.1-7. X sind an Public Switched Telefon Netzwerken 6 angeschlossen. Über dieses SIP Kommunikationsnetz 1 und den darin stattfindenden Transfer von SIP Nachrichten 13 können aber auch Computer 12 miteinander kommunizieren. Vom Erfindungsgedanken werden auch Netzwerke abgedeckt, bei denen SIP Endgeräte direkt an einem SIP Proxy in einer reinen SIP Domäne angeschlossen sind, ohne öffentliches Telekommunikationsnetz PSTN 6.
Der Netzbetreiber möchte auch beim Ausfall einer oder mehrerer Hardwareeinheiten des SIP Kommunikationsnetzes 1 sicher- stellen, so dass zum einen die Vergebührung für die bestehenden KommunikationsVerbindungen korrekt abgerechnet und weiterlaufen kann. Zum anderen sollen auch den Nutzern des SIP Kommunikationsnetzes 1 trotz Ausfalls die gewohnten Dienste ohne Wartezeit zur Verfügung stehen. Hierzu wird ein neues einfaches Verfahren vorgestellt , welches die Sicherung der Kommunikationsverbindungen und der zugehörigen Vergebührungen in einem SIP Kommunikationsnetz ermöglicht .
Die Figur 2 zeigt eine Prinzipskizze, in der ein Ausfall 14.1 einer Hardwareeinheit, hier der ersten Hardwareeinheit 14 , dargestellt ist, die sich z . B. in Figur 1 nach außen hin als Einheit innerhalb der Einheiten 8 oder 9 befinden könnten, die beispielsweise über das SIP Protokoll in Verbindung stehen (das MGCP könnte z .B. zwischen den Einheiten 8 und 3 laufen) . Der Ausfall 14.1 der ersten Hardwareeinheit 14 wird durch das X-Symbol dargestellt . Weiterhin wird in Figur 2 schematisch dargestellt, wie die zweite Hardwareeinheit 15 , die Aufgaben der ausgefallenen ersten Hardwareeinheit 14 ü- bernimmt und welche Schritte hierzu im neuen Verfahren eingeleitet werden.
In einem Kommunikationsnetzwerk weisen aus Sicherheitsgründen die Hardwareeinheiten 14 und 15 eine redundante Verbindung 16 untereinander auf, so dass eine Übernahme der Funktion der ausgefallenen Hardwareeinheit 14 durch die noch funktionsfähige Hardwareeinheit 15 ermöglicht wird. Dabei wird das Kenn- zeichen - Z .B . eine Information über dem Stand der Transaktion - bei einer noch bestehenden Transaktion (d.h. bei einem unstabilen CaIl z .B . relativ zu einem der Endgeräte 7.1-7.X, 11 , 12 oder zu irgendwelcher transaktion-auslösenden Ausfalleinheit (Vermittler, Hardwareeinheit, Cookies-Server, etc) und für welchen CaIl die Transaktion nun an die funktionsfähige Hardwareeinheit 15 gemeldet wird) aus der ausgefallenen Hardwareeinheiten 14 an die funktionsfähigen Hardwareeinheiten 15 übermittelt wird (das Kennzeichen wird sozusagen intern von einer Einheit 14 zur weiteren Einheit 15 transpor- tiert (nicht von außen sichtbar) , so dass Übervergebührungen zu dieser Transaktion vermieden werden. Damit hat die funktionsfähige Hardwareeinheit 15 Kenntnis davon, dass eine noch offene Transaktion zu einem CaIl besteht . Mit der Übernahme auf die funktionsfähige Hardwareeinheit 15 wird der CaIl präventiv ausgelöst , da auf der ausgefallenen Hardwareeinheiten 14 eine Transaktion begonnen wurde . Die Antwort darauf kommt j edoch nicht zur Applikation in der funktionsfähigen Hardwareeinheit 15 , da die erforderlichen Daten im Transportteil nicht vorhanden sind. Zusammengefasst wird in diesem Fall - bei einer noch bestehenden Transaktion - ein unstabiler SIP- CaIl kontrolliert und ausgelöst , sowie die Vergebührung been- det .
Methoden und Verfahren zum Detektieren von Hardwareausfällen und die weitere Behandlung von Hardwareausfällen beziehungsweise der zugehörige Transfer relevanter Daten auf die Er- satzhardwareeinheit sind aus dem Stand der Technik bereits bekannt . Im neuen Verfahren werden bevorzugt die Session Initiation Protocol (= SIP) relevanten Anteile verwendet .
Bei Ausfall 14.1 der ersten Hardwareeinheit 14 wird entspre- chend dem redundanten Aufbau des Kommunikationsnetzwerkes die zweite Hardwareeinheit 15 die Funktion der ersten Hardwareeinheit 14 übernehmen . Bisher war die erste Hardwareeinheit 14 mit einem SIP Endgerät 11 verbunden, beispielsweise einem Telefon und/oder einem Rechner . Die Verbindung der ersten Hardwareeinheit 14 mit dem SIP Endgerät 11 ist nicht in Figur 2 dargestellt . Nach Ausfall 14.1 der ersten Hardwareeinheit 14 wird die zweite Hardwareeinheit 15 mit dem SIP Endgerät 11 verbunden und mit diesem kommunizieren.
Nach der Übernahme der physischen Funktion (en) der ersten Hardwareeinheit 14 sendet die zweite Hardwareeinheit 15 im neuen Verfahren eine Nachricht 17 an das SIP Endgerät 11 , hier eine SIP UPDATE . Die SIP UPDATE ist eine SIP Nachricht beziehungsweise eine mögliche Methode, welche im RFC3311 de- finiert ist und im SIP Session timer draft nicht ausgeschlossen ist, welche eine Änderung des SIP Calls anzeigen kann, ohne dabei das Session Description Protocol des Kommunikati- onsnetzwerkes zu nutzen. Die Nachricht 17 kann die zusätzliche Festlegung enthalten, dass die SIP Session Timer Überwachungsfunktion ab sofort von hier aus , also von der zweiten Hardwareeinheit 15 aus , durchgeführt wird.
Die SIP Session Timer überwachungsfunktion kann festlegen, welcher der beiden Beteiligten, also die zweite Hardwareeinheit 15 oder das SIP Endgerät 11 die Nachrichten INVITE oder UPDATE, zur Feststellung der Bereitschaft und Anwesenheit der Gegenseite senden soll . Die Nachricht INVITE ist einerseits eine SIP Nachricht , welche eine Verbindung aufbauen kann, o- der andererseits ermöglicht sie für eine bestehende stabile Verbindung als re-INVITE die Verbindungsdaten zu ändern. Sie kann auch für die SIP Session timer prozedur angewendet wer- den.
Die Festlegung, dass die zweite Hardwareeinheit 15 der neue Kommunikationspartner des SIP Endgerätes 11 sein wird, kann also unabhängig von der Vorgeschichte auf der ersten Hard- wareeinheit 14 nun durch die zweite Hardwareeinheit 15 festgelegt werden. Dies ist insbesondere vorteilhaft, da dadurch die Gegenseite nun nicht mehr eine re-INVITE mit dem Session Description Protocol senden kann, die dann standardgemäß wiederum, mit dem nicht mehr notwendigerweise vorhandenen Sessi- on Description Protocol mit allen seinen Aspekten in der Antwort 18 , hier einem 200 OK zur re-INVITE, beantwortet werden müsste .
Erfindungsgemäß antwortet der SIP Partner 11 , der die Nach- rieht 17 , hier ein UPDATE, empfängt mit der einer Antwort 18 , hier einem 200 OK. Dies ist die gemäß RFC3261 SIP standardgemäße positive Antwort auf eine SIP Nachricht , hier positive Antwort auf UPDATE . Damit wissen beide, die zweite Hardwareeinheit 15 und das SIP Endgerät 11 , dass der CaIl beziehungs- weise die Verbindung in Ordnung ist und die Vergebührung und der CaIl nicht beendet werden braucht . Dies ist insbesondere deshalb der Fall , weil trotz Ausfall 14.1 der ersten Hard- wareeinheit 14 , welche nur die SIP Signalisierung bereitstellt, das zugehörige Kommunikationsnetzwerk sehr wohl noch funktionstüchtig ist , und die Kommunikationsteilnehmer noch mit einander sprechen beziehungsweise kommunizieren können, und der Ausfall 14.1 der ersten Hardwareeinheit 15 keine Auswirkungen hat .
Falls die Gegenseite die Nachricht / UPDATE 17 wider erwarten mit einer negativen Antwort 18 beantwortet , wird/kann die zweite Hardwareeinheit 2 diese Reaktion als eine Bestätigung werten, wonach die Gegenseite trotzdem noch funktionstüchtig ist, und der CaIl und die Vergebührung weiterlaufen kann .
Im Falle eines SIP Proxy Ausfalls , welcher zum Beispiel die Vergebührung vornimmt, ist dann erfindungsgemäß das Senden der UPDATE nach beiden Seite der Verbindung durchzuführen.
Insbesondere ist zu beachten, dass die für SIP vorgeschlagene Lösung auch für die Protokolle MGCP (gemäss RFC2705 ) und MEGACO (ITU-T H .248 ) übertragen werden kann, da dort grundsätzlich dieselbe Problematik auftritt .
Es versteht sich, dass die vorstehend genannten Merkmale der Erfindung nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der Erfindung zu verlassen.
Die folgenden Abkürzungen wurden verwendet :
BAT Bearer Application Transport
Bearer übermittler
BICC Bearer lndependent CaIl Control
CaIl Anruf CMN CaIl Mediation Node
CODEC Coding Decoding
IETF Internet Engineering Task Force IP Internet Protocol
ISDN Integrated Services Digital Network = Dienstintegrierendes digitales Telekommunikationsnetz
ISUP ISDN User Part
ITU-T International Telecommunication Union - Telecommu- nication Standardisation Sector
LE Local Exchange
MG Media Getaway
MGC ' Media Getaway Communication
MTP Message Transfer Protocol
NGN Next Generation Network
PSTN Public Switched Telecommunication Network
RFC Request For Comments
RTP Real Time Transport Protocol
SIP Session Initiation Protocol
SDP Session Description Protocol
TX Transit Exchange

Claims

Patentansprüche
1. Verfahren zur Sicherung der Koitimunikationsverbindungen und der zugehörigen Vergebührungen in einem redundant aufge- bauten Kommunikationsnetzwerk ( 1 ) , bei dem Endgeräte (7.1- 7.x, 11 ) über Vermittler (2 ) , vorzugsweise einen IP Bearer, und über Hardwareeinheiten (14 , 15 ) mittels Nachrichten (13 ) kommunizieren, wobei mit einer Überwachungsfunktion die korrekte Funktion der Endgeräte ( 7.1-7. X, 11 , 12 ) und/oder des Vermittlers (2 ) und/oder der Hardwareeinheiten ( 14 , 15 ) überwacht wird und beim Ausfall ( 14.1 ) einer oder mehrerer Hardwareeinheiten (14 , 15 ) die noch funktionsfähigen Hardwareeinheiten ( 15 ) die physischen Funktionen der ausgefallenen Hardwareeinheiten ( 14 ) übernehmen, d a d u r c h g e k e n n z e i c h n e t , dass unmittelbar nach der Übernahme der physischen Funktionen die funktionsfähigen Hardwareeinheiten (15 ) den beteiligten Endgeräten (7.1-7.X, 11 , 12 ) eine Nachricht ( 17 ) übermitteln und zusätzlich festlegen, dass die Überwachungsfunktion von den noch funktionsfähigen Hardwareeinheiten ( 15) ausgeführt wird und dass bei einer noch bestehenden Transaktion ein Kennzeichen aus einer der ausgefallenen Hardwareeinheit ( 14) an eine der funktionsfähigen Hardwareeinheiten ( 15) übermittelt wird, so dass Übervergebührungen zu dieser Transaktion vermieden werden.
2. Verfahren nach dem voranstehenden Anspruch 1 , d a d u r c h g e k e n n z e i c h n e t , dass als redundant aufgebautes Kommunikationsnetzwerk ( 1 ) ein SIP Kommunikationsnetzwerk eingesetzt wird und als Nachrichten SIP Nachrichten übermittelt werden.
3. Verfahren nach einem der voranstehenden Ansprüche 1 und 2 , d a d u r c h g e k e n n z e i c h n e t , dass die Endgeräte (7.1-7.X, 11 , 12 ) , die eine Nachricht ( 17 ) von den funktionsfähigen Hardwareeinheiten (15) bekommen, diesen eine Antwort (18) zurücksenden.
4. Verfahren nach einem der voranstehenden Ansprüche 1 bis 3 , d a d u r c h g e k e nn z e i c h n e t , dass die Endgeräte (7.1-7.X, 11 , 12 ) und/oder die Hardwareeinheiten (14, 15) durch eine SIP Session Timer (Session Timer im Session Initiation Protocol) überwacht werden.
5. Verfahren nach dem voranstehenden Anspruch 4, d a du r c h g e k e nn z e i c hn e t , dass die SIP Session timer Überwachungsfunktion festlegt, ob die beteiligten Endgeräte (7.1-7.X, 11 , 12 ) oder die Hard- warekomponenten (14 , 15) eine INVITE oder UPDATE Nachricht senden oder empfangen, wobei die UPDATE Nachricht ohne SDP verwendet wird.
6. Verfahren nach einem der voranstehenden Ansprüche 1 bis 5 , d a d u r c h g e k e n n z e i c h n e t , dass eine Vergebührung durch einen SIP Proxy (10) ausgeführt wird und beim Ausfall des SIP Proxy' s die Nachricht (17 ) an beide kommunizierenden Endgeräte (7.1-7.X, 11 , 12 ) gesendet wird.
7. Verfahren nach einem der voranstehenden Ansprüche 1 bis 6 , d a d u r c h g e k e n n z e i c h n e t , dass die Vergebührung abhängig von der Antwort (18) der Endgeräte (7.1-7.x, 11, 12 ) weiter durchgeführt wird oder beendet wird, wenn keine Antwort kam und der CaIl beendet wird.
8. Verfahren nach einem der voranstehenden Ansprüche 1 bis 7 , d a d u r c h g e k e n n z e i c h n e t , dass bei einer noch bestehenden Transaktion mit einem der Endgeräte (7.1-7. X, 11 , 12 ) über eine Ausfalleinheit ein CaIl ausgelöst und die dementsprechende Vergebührung angehalten wird.
EP05822337A 2005-01-24 2005-12-23 Verfahren zur sicherung der kommunikationsverbindungen und der zugeh\rigen vergeb]hrungen in einem redundanten kommunikationsnetzwerk Withdrawn EP1844603A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102005003195 2005-01-24
DE102005007419A DE102005007419A1 (de) 2005-01-24 2005-02-18 Verfahren zur Sicherung der Kommunikationsverbindungen und der zugehörigen Vergebührungen in einem redundanten Kommunikationsnetzwerk
PCT/EP2005/013978 WO2006079411A1 (de) 2005-01-24 2005-12-23 Verfahren zur sicherung der kommunikationsverbindungen und der zugehörigen vergebührungen in einem redundanten kommunikationsnetzwerk

Publications (1)

Publication Number Publication Date
EP1844603A1 true EP1844603A1 (de) 2007-10-17

Family

ID=36061600

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05822337A Withdrawn EP1844603A1 (de) 2005-01-24 2005-12-23 Verfahren zur sicherung der kommunikationsverbindungen und der zugeh\rigen vergeb]hrungen in einem redundanten kommunikationsnetzwerk

Country Status (4)

Country Link
US (1) US20080130487A1 (de)
EP (1) EP1844603A1 (de)
DE (1) DE102005007419A1 (de)
WO (1) WO2006079411A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101536464B (zh) * 2006-11-10 2012-09-05 艾利森电话股份有限公司 用于控制通信的方法及设备
US8570853B2 (en) * 2007-07-20 2013-10-29 Ipc Systems, Inc. Systems, methods, apparatus and computer program products for networking trading turret systems using SIP
US20090036128A1 (en) * 2007-08-03 2009-02-05 Newstep Networks Inc. Method and system for dynamic call anchoring

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5473599A (en) * 1994-04-22 1995-12-05 Cisco Systems, Incorporated Standby router protocol
US6751191B1 (en) * 1999-06-29 2004-06-15 Cisco Technology, Inc. Load sharing and redundancy scheme
WO2002091678A1 (en) * 2001-05-10 2002-11-14 Nokia Corporation Method, system and network element device for controlling sessions between terminals
JP2005229273A (ja) * 2004-02-12 2005-08-25 Fujitsu Ltd サーババックアップ装置

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2006079411A1 (de) 2006-08-03
US20080130487A1 (en) 2008-06-05
DE102005007419A1 (de) 2006-08-03

Similar Documents

Publication Publication Date Title
DE60014234T2 (de) System und Verfahren zum Ermöglichen von Fehlertolerante Systeme
DE60023586T2 (de) System und Verfahren zum Wiederanfahren von Signalisierungseinheiten in H.323-basierten Echtzeit-kommunikationsnetzen
DE60124087T2 (de) Verfahren zur überwachung von anrufen in einem ip-basierten netzwerk
DE60014492T2 (de) System und Verfahren zur direkten Benutzer-Signalisierung in H.323 Kommunikationsnetzen
DE60132387T2 (de) Richtlinien-Koordination in einem Kommunikationsnetz
EP2018765B1 (de) Steuerung der dienstqualität und/oder der vergebührung von telekommunikationsdiensten
DE102006014921A1 (de) Verfahren für Lawful Interception bei Anrufweiterschaltung in einem paketorientierten Telekommunikationsnetz
EP1994714B1 (de) Verfahren zur zuordnung von zumindest einer nutzdatenverbindung zu zumindest einer multiplexverbindung
EP1759514A1 (de) Aufbau einer verbindung für den austausch von daten eines ip-basierten dienstes
EP1844603A1 (de) Verfahren zur sicherung der kommunikationsverbindungen und der zugeh\rigen vergeb]hrungen in einem redundanten kommunikationsnetzwerk
EP1854268A1 (de) Signalisierung des ausfalls einer netzeinheit über ein kommunikationsnetz
DE10335149A1 (de) Verfahren zum Umsteuern einer Bearerverbindung (Bearer Redirect) für SIP/ SIP-T Teilnehmer
DE60117452T2 (de) Anrufüberwachung in einem Kommunikationssystem
WO2007113073A1 (de) Verfahren zum wiederherstellen einer mit ipsec kryptographisch gesicherten verbindung zwischen p-cscf und anwendereinheit
EP1841161A1 (de) Verfahren zur gesicherten Nutzdatenübertragung
WO2006056508A1 (de) Verfahren zur sicherung der kommunikationsverbindungen und der zugehörigen vergebührungen in einem redundanten kommunikationsnetzwerk
EP1294166A1 (de) Signalisierungsverfahren für die Übertragung von Nutzdaten über leitungs- und packetvermittelte Datenübertragungsnetze
DE102005057244B4 (de) Verfahren zur Kommunikation zwischen Endgeräten in SIP-Netzen
DE10322539A1 (de) Verfahren zum Aufbau einer Kommunikationsverbindung und Kommunikationssystem
EP1514433B1 (de) Verfahren zur verbindungssteuerung in einem paketorientierten kommunikationsnetz sowie anordnungen zu seiner durchführung
DE102005031410B4 (de) Verfahren zum Aufbau einer multimedialen Verbindung bei kaskadierter Verbindungsweiterleitung
EP3959850B1 (de) Verfahren zum bereitstellen von verbindungsherstellungsdaten sowie anordnung mit einer mehrzahl von kommunikationsservern und einem vermittler
EP2649751A1 (de) Verfahren zur überwachung eines kommunikationssystems
WO2007065738A1 (de) Vorrichtung und verfahren zur unterstützung von fax t.38 anwendungen in fmc netzen
DE102005045121B4 (de) Vorrichtung zur Unterstützung des Leistungsmerkmals "Fall-back" in SIP-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: 20070824

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

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

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

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

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

17Q First examination report despatched

Effective date: 20080118

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20080605