[go: up one dir, main page]

WO2007012666A1 - Verfahren zum datenaustausch zwischen netzelementen - Google Patents

Verfahren zum datenaustausch zwischen netzelementen Download PDF

Info

Publication number
WO2007012666A1
WO2007012666A1 PCT/EP2006/064781 EP2006064781W WO2007012666A1 WO 2007012666 A1 WO2007012666 A1 WO 2007012666A1 EP 2006064781 W EP2006064781 W EP 2006064781W WO 2007012666 A1 WO2007012666 A1 WO 2007012666A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
message
address
network node
network element
Prior art date
Application number
PCT/EP2006/064781
Other languages
English (en)
French (fr)
Inventor
Mohammad Vizaei
Original Assignee
Nokia Siemens Networks Gmbh & 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 & Co. Kg filed Critical Nokia Siemens Networks Gmbh & Co. Kg
Priority to US11/997,276 priority Critical patent/US20080165782A1/en
Priority to EP06778049A priority patent/EP1913756A1/de
Publication of WO2007012666A1 publication Critical patent/WO2007012666A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2564—NAT traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2578—NAT traversal without involvement of the NAT server

Definitions

  • network node devices for example routers, firewalls or gateways.
  • a category of problematic applications thereby represent so-called “session Bundled Applications,” in the pa ⁇ ketorient striving data exchange addressing information of each data packet are included in addition to a header in a data part ( "Paylo- ad”).
  • ALG Application Layer Gateway
  • the protocol SIP is used to enable the Kiru ⁇ nikationsthetic, the actual data for communication via other protocols are exchanged ⁇ .
  • two of these protocols are mentioned by way of example.
  • SDP Session Description Protocol
  • RFC 2327 the communication connection is managed.
  • SDP Session Description Protocol
  • an exchange of network addresses - for example IP addresses - and interfaces or ports of the communication partners is provided.
  • SDP involves negotiation of codecs to be used between the communication partners, transport protocols, etc.
  • a Trans ⁇ port via RTP for example, comprises a classification of the game as encoded in ⁇ with a codec and payload data compressed into data packets and for shipping.
  • a despatch for example, a transport protocol such as UDP (User Since ⁇ TagRAM Protocol).
  • a solution of the problem is in terms of their method aspect by a method having the features of claim 1.
  • This confirmation message is modified analogously to the invitation ⁇ dung object, for example on a is arranged between the network node devices switch or network nodes th. Analogously to the previous one a passage filter for the first network node device generating message after receipt of the acknowledgment message is then sent by the to be called network element. In this way, an RTP connection (Real Time Protocol) can be set up between the calling and the calling network element, without further consideration of the address translation NAT between the two communicating network elements.
  • RTP connection Real Time Protocol
  • a significant advantage of the method according to the invention is the fact that a generic network node device - in particular gateway or router - can be used without further ge ⁇ creative interventions to connect the two Netztechnikbe ⁇ rich.
  • the inventive method is advantageous in the network ⁇ elements, ie to implement endpoints of a packet-oriented communication and therefore requires little programming effort and in particular no interference with the overall system or in mediating network node devices.
  • Fig. 1 a chronological flowchart for schematic
  • 2A is a structural diagram for schematically illustrating a communication environment
  • Fig. 2B a chronological sequence diagram for schematic
  • FIG. 1 shows a firewall or gateway known from the prior art in which a network address translation (NAT) is performed.
  • An illustrated firewall FW1 is typically located between a local area network and LAN and a public network WAN. The firewall is thus more generally arranged between two domains. The following to be described
  • Firewall FWl is referred to below with the more general term network node device FWl, since its functionality can also be implemented in a gateway, in a router or in a NAT server.
  • a message 101 arrives, which comes from a - not shown - sending element and which by a network address Z and an interface z is characterized (in the drawing »transmitter: Z: z ⁇ ).
  • the network address preferably corresponds to an IP address and the interface is a port number ⁇ characterized.
  • the message 101 was preceded by no further message traffic, so that there is no "binding" for the network address Z or for the interface or port z in the network node device FW1.
  • the incoming message 101 is not forwarded by the network node device to the local area network LAN and instead discarded (dropped).
  • Message 102 which within the local network ⁇ LAN from a - not shown - sending element, which is characterized by the network address X or by the port x, sent (in the drawing "Sender: X: x").
  • the goal of the message 102 is a - not illustrated ⁇ - receiving element in the public network WAN, ie beyond the network node device FWL.
  • the receiving network element is identified by the network address Z or by the port z (in the drawing "Receiver: Z: z").
  • the network node FW1 makes an address translation or NAT (Network Address Translation) with respect to the network address X, and forwards the message 102 in the form of an altered message 103 into the public network WAN.
  • NAT Network Address Translation
  • the modified message 103 is characterized in that the original sender network address X has been replaced by a modified sender address Y.
  • the new ex ⁇ sender address Y corresponds to the network address of the Netzkno ⁇ ten observed FWL.
  • the network node device FWL allocates a fürgangsfil ⁇ ter (pinhole) and causes a bond with a flag of the interface used. With a used for the network node device FWL network address Y this Bin ⁇ is dung:
  • This binding results in each incoming data packet with a sender address Z: z being transmitted to an element with the network address X: x and vice versa.
  • the bond is used originally used and maintained ⁇ port number.
  • the duration of a pass filter or pin Hole with an associated bond is usually limited in time and is usually in the order of about 30 seconds.
  • a third case which is represented in the drawing by a circled numeral 3 is output from a - not shown ⁇ - sending element characterized by the network address Z 'and by the interface z' gen.
  • the address / port combination Z ': z' differs from Al as known from the second case, address / port combination ⁇ nation Z: z.
  • the transmitting element located in the public network area WAN sends a message 106 in the direction of an element (not shown) within the private network LAN. Although the binding described in case 2, still exists, the message is 106 at the Netzknotenein ⁇ direction FWL rejected because it has a non-coincident with the vormali ⁇ gen binding combination of network address and port.
  • Network node device which acts as a firewall between a public network WAN and a local network LAN, often prevents the establishment of Kirunikationsver ⁇ compounds, which are performed, for example, based on the SIP protocol.
  • the resulting problems are described by means of an arrangement according to FIG. 2a.
  • the figure shows a first network area DMA or network domain DMA, which is closed or secured with respect to other network areas with a first network node device FW1.
  • a first network element A is arranged, which wants to establish a communication with a arranged in the second network area DMB second network element B in the following.
  • the first network node unit FWL is ver with the second Netzkno ⁇ teniser FW2 via another network node unit SW " ⁇ prevented," which is also referred to as a switch.
  • SW " ⁇ prevented" which is also referred to as a switch.
  • These are z. B. to a packet-oriented medi ⁇ treatment device, or using a SIP protocol to a SIP server.
  • a "connection” is basically not to be understood as a fixed connection in a connectionless packet-oriented network that is in itself connectionless.
  • the communication connection between the two network elements A, B is established using the SIP protocol.
  • SIP protocol is not mandatory for the execution of the method according to the invention.
  • old ⁇ native communication protocols are such.
  • BH323 can be used.
  • a communication link between the two network elements such A, B using the SIP protocol begins übli ⁇ chlay with a mutual exchange of the own network addresses. This exchange takes place via a the SIP protocol suite delivered listening protocol SDP (Session Descriptor tion Protocol) and is usually a more or invitation message ( "Invite”) and corresponding Bestä ⁇ actuation news accompanied ( "OK").
  • SDP Session Descriptor tion Protocol
  • the calling network element A sends its own IP address and its port for incoming traffic, such as voice, video, data, etc. in the confirmation message sends the called network ⁇ element B its own IP address and a port number incoming for his Data traffic for the current data connection (session).
  • FIG. 2a The arrangement shown in Figure 2a in this case has two as Fire ⁇ wall functioning network node units FWL, FW2, which affect this exchange of SDP messages so that a communication relationship is not concluded at worst.
  • FWL Fire ⁇ wall functioning network node units
  • FW2 Fire ⁇ wall functioning network node units
  • Network elements A, B send their own, only locally known Netztechnikad ⁇ resse, ie a network address, which only in each Niche network area DMA, DMB is known and is implemented with a NAT method of the respective network node device FWL, FW2 in a publicly known network address.
  • a NAT method provides for an address conversion only in the header of the message or the data packet, but not in the payload part ("body") of the data packet, which, however, is to be used by the SIP protocols for the determination of the communication partner.
  • This problem is not solved satisfactorily by "SIP-Aware" ALG (Application Layer Gateways), since they suffer a considerable loss of performance because they have to examine the body of each data packet.
  • the network addresses or IP addresses of the functional units involved are:
  • the network node device FWL is not set up as a special "Applica ⁇ tion Layer Gateway"
  • the content remains unchanged in the body of the invitation message 204 against the received invitation message 202nd
  • changes in the header of the data packet are made by the network node device FW4, including a network address conversion as explained in the description of FIG.
  • the content or SIP part of the invitation message 204 is received at the switch SW in the following form:
  • INVITE sip fwluser@wcom.com SIP / 2.0 Via: SIP / 2.0 / UDP IPv6. com: 5060 From: fwluser ⁇ sip: fwlusergwcom. com> To: fw2user ⁇ sip: fw2user @ wcom. com> Call ID: 12345678@wcom.com CSeq: 1 INVITE
  • the message still contains the private address 192.168.0.1 of the calling user that was not changed by the network address translation Network element A in the local network segment DMA.
  • the port to be used for the network element A is specified as 49170.
  • the switch SW is now overwrites the In contained in the SDP part formation within the invitation message 204 by appli ⁇ dung to the following rules:
  • a correspondingly modified invitation message "Invite F3" 206 is sent by the switch to the second network node unit FW2.
  • the invitation message 206 includes the following structural ⁇ ture on:
  • Network node unit FWl The Dende for the network element A to USAGE ⁇ port remains registered as the 49,170th
  • the received from the second network node unit FW2 invitation message 206 is processed analogously to the procedure insbeson ⁇ particular NAT, at the first network node device FWL and sent 208 "Invite F4" to the second network element B in the form of the invitation message.
  • the invitation message 206 passes through the second network node unit FW2 ⁇ as invitation messages usually a de- fault port number 5060 for signaling (Signaling) use.
  • the invitation message 206 is therefore transmitted in the form of the invitation message 206 by the second network node unit FW2 using a »Port Forwarding Mechanism «.
  • Message 210 discarded at the first network node unit FWl, but has on its way a pass filter in the second Network node unit FW2 opened.
  • a pass-through filter is not only opened, but also a bond in the second network node unit FW2 Herge ⁇ represents.
  • a port number is used as the sending port and marked, which is used in a later course of this communication session for the reception of a user data stream 238.
  • This - in the drawing dash-dotted line - Nutzsteinstrom is transported with an RTP protocol (Real Time Protocol).
  • Another course of the communication session essentially corresponds to the requirements of the SIP protocol and concerns the messages 212, 214, 216, 218 ("Ringing F5" ... "Ringing F8") and 220 ("OK F10").
  • the call establishment by the messages follows the SIP protocol until the data of the acknowledgment message 222 contained in the SDP part is received by the switch SW.
  • the SDP portion of the acknowledgment message 222 received at the switch SW ("200 OK F10") has the following structure:
  • the switch SW overwrites the SDP portion of the acknowledgment message 222 according to the following rules:
  • the IP address within the SDP part of the confirmation ⁇ message 222 is overwritten with the IP address in the IP header of the confirmation message 222, which was previously assigned by the second network node device FW2. This corresponds to the public network address of the second network node device FW2 in the present embodiment, this has the value 195.1.200.0.
  • the first network element A transmits another reverse UDP packet in the form of the message »E2 « 228 in the direction of the second network element B.
  • the message 228 is discarded at the second network node unit FW2.
  • the messages 228, 210 which generate a transmission filter for the first or second network node device FW1, FW2 are repeated if necessary, for example if the transmission filter fails the already mentioned time limit of an open state has already been closed before the payload data connection 238 could be established.
  • a respective processing of the invitation or confirmation messages does not necessarily have to take place in a central instance such as the switch described in the exemplary embodiment or a SIP registrar.
  • a peer-to-peer communication between the network elements can be done, for example, in other network elements.
  • These network elements are arranged, for example, analogously to the exemplary embodiment between the network domains DMA, DMB.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Das erfindungsgemäße Verfahren sieht mindestens ein rufendes und mindestens ein zu rufendes Netzelement in unterschiedlichen, durch Netzknoteneinrichtungen bzw. Firewalls getrennte erste und zweite Netzwerkbereiche vor. In diesen getrennten Netzwerkbereichen oder Domänen ist den Netzelementen üblicherweise eine nur im jeweiligen Netzwerkbereich lokal gültige Netzwerkadresse zugeordnet. Diese lokal gültige Netzwerkadresse wird in Nachrichtenkopf eintragen bzw. Headers von Nachrichten, welche die Netzelemente an außerhalb des eigenen Netzwerkbereichs lokalisierte Netzelemente senden, von der jeweiligen Netzknoteneinrichtung durch eine außerhalb des jeweiligen Netzwerkbereichs gültige Netzwerkadresse umgesetzt, insbesondere durch eine global gültige Netzwerkadresse des Netzknotenelements. Die Erfindung sieht vor, dass nach dem Senden einer Einladungsnachricht (bspw. ein SIP-Invite) eine Modifikation des Inhalts der Einladungsnachricht anhand der im Nachrichtenkopf eintrag enthaltenen außerhalb des ersten Netzwerkbereichs gültigen Netzwerkadresse erfolgt, also z.B. ein Eintrag der im Header enthaltenen durch die Netzknoten einheit zuvor geäderte IP-Adresse in einem Body der Nachrieht. Anschließend sendet das zu rufende zweite Netzelement eine Nachricht in Richtung des rufenden ersten Netzelements. Diese Nachricht erzeugt einen Durchgangsfilter bzw. Pinhole in der zweiten Netzknoteneinrichtung und wird an der ersten Netzknoteneinrichtung verworfen bzw. ‚“dropped“ Anschließend wird eine Bestätigungsnachricht durch das zu rufende Netzelement gesendet. Diese Bestätigungsnachricht ist z.B. durch das verwendete Kommunikationsprotokoll, beispielsweise SIP, vorgesehen. Diese Bestätigungsnachricht wird analog der Einladungsnachricht modifiziert, beispielsweise an einem zwischen den Netzknoteneinrichtungen angeordneten Switch bzw. Netzknoten. Analog zum vorhergehenden wird nun eine einen Durchgangsfilter für die erste Netzknoteneinrichtung erzeugende Nachricht nach Erhalt der Bestätigungsnachricht durch das zu rufenden Netzelement gesendet. Damit kann eine RTP-Verbindung (Real Time Protocol) zwischen dem rufenden und dem zu rufenden Netzelement aufgebaut werden, ohne weitere Beachtung der Adressumsetzung NAT zwischen den beiden kommunizierenden Netzelementen.

Description

Beschreibung
Verfahren zum Datenaustausch zwischen Netzelementen
Die Erfindung betrifft ein Verfahren zum Datenaustausch von Netzelementen, welche in unterschiedlichen Netzwerkbereichen angeordnet sind.
Zur Unterstützung und zur Absicherung eines Datenaustausche zwischen in verschiedenen lokalen paketorientierten Netzwerkbereichen angeordneten Netzelementen ist eine Verwendung von Netzknoteneinrichtungen - beispielsweise Router, Firewalls oder Gateways - bekannt.
Ein paketorientierter Datenaustausch erfolgt zum Beispiel unter Anwendung des »Internet Protocol«, abkürzend auch mit IP bezeichnet. In der weiteren Beschreibung wird zuweilen auf das Internet Protocol Bezug genommen, wenngleich eine Verwen¬ dung dieses Protokolls nur exemplarisch zu verstehen ist. Ein paketorientierter Datenaustausch umfasst alle paketorientierten Kommunikationsweisen, bei welchen sich zum Datenaustausch verwendete Datenpakete aus einem Datenteil und einem charak¬ terisierenden Teil - in der Literatur häufig »Header« genannt - zusammensetzen. Der Header enthält dabei üblicherwei- se eine das sendende Netzelement charakterisierende Absender¬ adresse sowie eine das für den Empfang bestimmte Netzelement charakterisierende Zieladresse.
Bei einer Verwendung von lediglich innerhalb eines ersten lo- kalen Netzwerkbereichs gültigen - »lokalen« - Adressen zur Adressierung eines Netzelements ist für eine Kommunikation mit Netzelementen eines zweiten Netzwerkbereichs eine Umset¬ zung der im ersten Netzwerk lokal gültigen Adressen in für den zweiten Netzwerkbereich gültige Adressen bekannt. Als Ab- sender- bzw. Zieladresse wird dabei die jeweilige IP-Adresse des sendenden bzw. des zum Empfang bestimmten Netzelements verwendet. Ein entsprechendes Verfahren - in der Fachwelt als Adressumsetzung bzw. NAT (Network Address Translation) bekannt - wird üblicherweise durch eine Netzknoteneinrichtung, z.B. anhand von Zuordnungstabellen, durchgeführt.
In dem Dokument RFC 3027 (Request for Comment) der IETF (In¬ ternet Engineering Task Force) werden verschiedene Applikati¬ onen bzw. Kommunikationsprotokolle genannt, bei deren Anwen¬ dung Probleme mit der vorgenannten Adressumsetzung auftreten.
Eine Kategorie problembehafteter Applikationen stellen dabei sogenannte »Bundled Session Applications« dar, bei deren pa¬ ketorientierten Datenaustausch Adressierungsinformationen zusätzlich zu einer im Header auch in einem Datenteil (»Paylo- ad«) eines jeweiligen Datenpakets enthalten sind.
Da die im Payload enthaltenen - ebenso wie die im Header ent¬ haltenen - Adressierungsinformationen üblicherweise domänenspezifisch - d.h. nur in einem jeweiligen Netzwerkbereich gültig - sind, besitzen diese nach einem Übergang in einen anderen Netzwerkbereich auch mit einer erfolgten Adressumsetzung keine Gültigkeit, da Netzknoteneinrichtung üblicherweise nur Adressinformationen im Header derartiger Datenpakete gemäß des NAT-Verfahrens umsetzen.
Eine Ausnahme hierfür bieten Netzknoteneinrichtungen, welche als so genannte »Application Layer Gateways«, kurz ALG, aus¬ gestaltet sind. Diese ALG berücksichtigen auch im Payload enthaltene Adressinformationen für eine NAT-analoge Adressumsetzung. Derartige ALG sind jedoch spezifisch auf das jewei- lige Protokoll einzurichten und weisen des weiteren Laufzeit¬ bzw. Performance-Probleme wegen der benötigten Rechendauer bei einer Auswertung und Umsetzung der Payload-Daten auf.
Ein Beispiel oben genannter Bundled Session Applications sind unter anderem die in der Fachwelt bekannten Kommunikations- protokolle SIP (»Session Initiated Protocol«) bzw. H.323. Das Protokoll SIP wird häufig eingesetzt, um beliebige Kommu¬ nikationsverbindungen oder »Sessions« mit einem oder mehreren Teilnehmern zu verwalten. Eine mögliche Kommunikationsverbindung ist dabei eine VoIP-Telefonie (Voice over Internet pro- tocol) oder auch beliebige Multimediaströme, Konferenzen,
Computerspiele usw. Das Protokoll SIP dient dazu, die Kommu¬ nikationsverbindung zu ermöglichen, wobei die eigentlichen Daten für die Kommunikation über andere Protokolle ausge¬ tauscht werden. Im folgenden werden exemplarisch zwei dieser Protokolle genannt.
Mit einem Session Description Protocol (SDP) gemäß RFC 2327 wird die Kommunikationsverbindung verwaltet. Zu diesem Zweck ist ein Austausch von Netzwerkadressen - beispielsweise IP- Adressen - und Schnittstellen bzw. Ports der Kommunikationspartner vorgesehen. Weiterhin umfasst SDP eine Verhandlung von zwischen den Kommunikationspartnern zu verwendenden Codecs, Transportprotokolle usw.
Mit einem Realtime Transport Protocol (RTP) gemäß RFC 3550 werden die Nutzdaten bzw. Payload transportiert. Ein Trans¬ port über RTP umfasst beispielsweise eine Einteilung der bei¬ spielsweise mit einem Codec kodierten und komprimierten Nutzdaten in Datenpakete und deren Versand. Ein Versand erfolgt beispielsweise mit einem Transportprotokoll wie UDP (User Da¬ tagram Protocol) .
Ein Einsatz eines ALG zur Ermöglichung eines Datenaustausche wie beispielsweise einer Kommunikationsverbindung ist häufig auf ein spezifisches Protokoll wie SIP beschränkt. Zudem müs¬ sen beide Netzwerkbereiche eine gleichgestaltete, d.h. auf das verwendete Kommunikationsprotokoll abgestimmte ALG auf¬ weisen .
Aufgabe der Erfindung ist es, Mittel zum Datenaustausch zwischen mit Netzwerkadressen in einem charakterisierenden Bereich ausgetauschter Datenpakete umsetzenden Netzknotenein- richtungen getrennten Netzelementen anzugeben, mit denen eine im jeweils entgegengesetzten Netzwerkbereich gültige Adressierung des sendenden Netzelements anhand der in einem Datenbereich ausgetauschter Datenpakete eingetragenen Adressie- rungsinformationen gewährleistet ist.
Eine Lösung der Aufgabe erfolgt hinsichtlich ihres Verfahrensaspekts durch ein Verfahren mit den Merkmalen des Patentanspruchs 1.
Das erfindungsgemäße Verfahren sieht mindestens ein rufendes und mindestens ein zu rufendes Netzelement in unterschiedli¬ chen, durch Netzknoteneinrichtungen bzw. Firewalls getrennte erste und zweite Netzwerkbereiche vor. In diesen getrennten Netzwerkbereichen oder Domänen ist den Netzelementen üblicherweise eine nur im jeweiligen Netzwerkbereich lokal gültige Netzwerkadresse zugeordnet. Diese lokal gültige Netzwerk¬ adresse wird in Nachrichtenkopfeintragen bzw. Headers von Nachrichten, welche die Netzelemente an außerhalb des eigenen Netzwerkbereichs lokalisierte Netzelemente senden, von der jeweiligen Netzknoteneinrichtung durch eine außerhalb des jeweiligen Netzwerkbereichs gültige Netzwerkadresse umgesetzt, insbesondere durch eine global gültige Netzwerkadresse des Netzknotenelements. Die Erfindung sieht vor, dass nach dem Senden einer Einladungsnachricht (bspw. ein SIP-Invite) eine Modifikation des Inhalts der Einladungsnachricht anhand der im Nachrichtenkopfeintrag enthaltenen außerhalb des ersten Netzwerkbereichs gültigen Netzwerkadresse erfolgt, also z.B. ein Eintrag der im Header enthaltenen durch die Netzknoten- einheit zuvor geäderte IP-Adresse in einem Body der Nach¬ richt. Anschließend sendet das zu rufende zweite Netzelement eine Nachricht in Richtung des rufenden ersten Netzelements. Diese Nachricht erzeugt einen Durchgangsfilter bzw. Pinhole in der zweiten Netzknoteneinrichtung und wird an der ersten Netzknoteneinrichtung verworfen bzw. »dropped«. Anschließend wird eine Bestätigungsnachricht durch das zu rufende Netzele¬ ment gesendet. Diese Bestätigungsnachricht ist z.B. durch das verwendete Kommunikationsprotokoll, beispielsweise SIP, vor¬ gesehen. Diese Bestätigungsnachricht wird analog der Einla¬ dungsnachricht modifiziert, beispielsweise an einem zwischen den Netzknoteneinrichtungen angeordneten Switch bzw. Netzkno- ten. Analog zum vorhergehenden wird nun eine einen Durchgangsfilter für die erste Netzknoteneinrichtung erzeugende Nachricht nach Erhalt der Bestätigungsnachricht durch das zu rufende Netzelement gesendet. Damit kann eine RTP-Verbindung (Real Time Protocol) zwischen dem rufenden und dem zu rufen- den Netzelement aufgebaut werden, ohne weitere Beachtung der Adressumsetzung NAT zwischen den beiden kommunizierenden Netzelementen .
Ein wesentlicher Vorteil des erfindungsgemäßen Verfahrens ist darin zu sehen, dass eine gattungsübliche Netzknoteneinrichtung - insbesondere Gateway oder Router - ohne weitere ge¬ stalterische Eingriffe zur Verbindung der beiden Netzwerkbe¬ reiche eingesetzt werden kann.
Das erfindungsgemäße Verfahren ist vorteilhaft in den Netz¬ elementen, d.h. Endpunkten einer paketorientierten Kommunikation zu implementieren und erfordert daher nur geringen Programmieraufwand und insbesondere keinerlei Eingriffe in das Gesamtsystem bzw. in vermittelnde Netzknoteneinrichtungen.
Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
Ein Ausführungsbeispiel mit weiteren Vorteilen und Ausgestal- tungen der Erfindung wird im folgenden anhand der Zeichnung näher erläutert.
Dabei zeigen:
Fig. 1: ein chronologisches Ablaufbild zur schematischen
Darstellung einer Funktion einer aus dem Stand der Technik bekannten Firewall; Fig. 2A: ein Strukturbild zur schematischen Darstellung einer Kommunikationsumgebung;
Fig. 2B: ein chronologisches Ablaufbild zur schematischen
Darstellung eines erfindungsgemäßen Nachrichtenaustauschs zum Aufbau einer Kommunikationsverbindung.
Figur 1 zeigt eine aus dem Stand der Technik bekannte Fire- wall bzw. Gateway, bei dem eine Netzwerkadressumsetzung bzw. NAT (Network Address Translation) durchgeführt wird. Eine dargestellte Firewall FWl ist üblicherweise zwischen einem lokalen Netzwerk und LAN und einem öffentlichen Netzwerk WAN angeordnet. Die Firewall ist also allgemeiner gesagt zwischen zwei Domänen angeordnet. Die im Folgenden zu beschreibende
Firewall FWl wird im Folgenden mit dem allgemeinerem Begriff Netzknoteneinrichtung FWl benannt, da deren Funktionalität auch in einem Gateway, in einem Router oder in einem NAT- Server verwirklicht werden kann.
In einem ersten Fall, welcher mit einer eingekreisten Ziffer 1 in Figur 1 dargestellt ist, wird davon ausgegangen, dass an der Netzknoteneinrichtung FWl eine Nachricht 101 eintrifft, welche von einem - nicht dargestellten - sendenden Element stammt und welche durch eine Netzwerkadresse Z und eine Schnittstelle z charakterisiert ist (in der Zeichnung »Sender: Z:z<<). Die Netzwerkadresse entspricht vorzugsweise einer IP-Adresse und die Schnittstelle wird durch eine Port¬ nummer charakterisiert. Es wird weiterhin davon ausgegangen, dass der Nachricht 101 kein weiterer Nachrichtenverkehr vorausging, so dass in der Netzknoteneinrichtung FWl keine »Bindung« (Binding) für die Netzwerkadresse Z bzw. für die Schnittstelle bzw. Port z existiert. Die eingehende Nachricht 101 wird von der Netzknoteneinrichtung nicht an das lokale Netzwerk LAN weitergeleitet und statt dessen verworfen (dis- carded bzw. dropped) . Hier wie in den folgenden Figuren ist ein solcher Drop-Vorgang mit einem unregelmäßigen Stern zeichnerisch dargestellt.
In einem zweiten Fall, welcher mit einer eingekreisten Zif- fer 2 in Figur 1 dargestellt ist, wird von einer zweiten
Nachricht 102 ausgegangen, welche innerhalb des lokalen Netz¬ werks LAN von einem - nicht dargestellten - sendenden Element, welches durch die Netzwerkadresse X bzw. durch den Port x gekennzeichnet ist, gesendet (in der Zeichnung »Sender: X:x«) . Das Ziel der Nachricht 102 sei ein - nicht darge¬ stellten - empfangendes Element im öffentlichen Netzwerk WAN, d.h. jenseits der Netzknoteneinrichtung FWl. Das empfangende Netzelement ist durch die Netzwerkadresse Z bzw. durch den Port z gekennzeichnet ist (in der Zeichnung »Recei- ver: Z:z«) . Der Netzknoten FWl nimmt bezüglich der Netzwerkadresse X eine Adressumsetzung bzw. NAT (Network Adress Translation) durch, und leitet die Nachricht 102 in Form einer veränderten Nachricht 103 in das öffentliche Netzwerk WAN weiter. Die veränderte Nachricht 103 ist dadurch gekennzeich- net, dass die ursprüngliche Absendernetzwerkadresse X durch eine veränderte Absenderadresse Y ersetzt wurde. Die neue Ab¬ senderadresse Y entspricht der Netzwerkadresse der Netzkno¬ teneinrichtung FWl . Im Zuge der Weiterleitung der Nachricht 102 in das öffentliche Netzwerk WAN in Form der Nachricht 103 reserviert die Netzknoteneinrichtung FWl einen Durchgangsfil¬ ter (Pinhole) und ruft eine Bindung mit einer Vormerkung der verwendeten Schnittstelle auf. Mit einer für die Netzknoteneinrichtung FWl benutzten Netzwerkadresse Y lautet diese Bin¬ dung:
X: x nach Y:x und Y:x nach Z:z.
Diese Bindung führt dazu, dass jedes eintreffende Datenpaket mit einer Absenderadresse Z:z zu einem Element mit der Netz- werkadresse X:x übermittelt wird und umgekehrt. Die Bindung verwendet die ursprünglich verwendete und beibehaltene Port¬ nummer. Die zeitliche Dauer eines Durchgangsfilters bzw. Pin- hole mit einer zugehörigen Bindung ist üblicherweise zeitlich begrenzt und liegt meist in einer Größenordnung von ca. 30 Sekunden.
In einem dritten Fall, der in der Zeichnung durch eine eingekreiste Ziffer 3 dargestellt ist, wird von einem - nicht dar¬ gestellten - sendenden Element, charakterisiert durch die Netzwerkadresse Z' und durch die Schnittstelle z' ausgegan¬ gen. Die Adress-/Portkombination Z':z' unterscheidet sich al- so von der aus dem zweiten Fall bekannten Adress-/ Portkombi¬ nation Z: z. Das im öffentlichen Netzwerkbereich WAN lokalisierte sendende Element sendet eine Nachricht 106 in Richtung eines - nicht dargestellte - Elements innerhalb des privaten Netzwerkes LAN. Obgleich die im Fall 2 beschriebene Bindung noch existiert, wird die Nachricht 106 an der Netzknotenein¬ richtung FWl abgewiesen, da diese eine nicht mit der vormali¬ gen Bindung übereinstimmende Kombination aus Netzwerkadresse und Schnittstelle aufweist.
Die anhand von Figur 1 beschriebene Funktionsweise einer
Netzknoteneinrichtung, welche als Firewall zwischen einem öffentlichen Netzwerk WAN und einem lokalen Netzwerk LAN fungiert, verhindert oftmals einen Aufbau von Kommunikationsver¬ bindungen, welche beispielsweise auf Basis des SIP-Protokolls geführt werden. Die dabei entstehenden Probleme werden anhand einer Anordnung gemäß Figur 2a beschrieben. Die Figur zeigt einen ersten Netzwerkbereich DMA bzw. Netzwerkdomäne DMA, welche gegenüber anderen Netzwerkbereichen mit einer ersten Netzknoteneinrichtung FWl abgeschlossen bzw. gesichert ist. Entsprechendes gilt für einen zweiten Netzwerkbereich DMB und einer zweiten Netzknoteneinheit FW2. Im ersten Netzwerkbe¬ reich DMA ist ein erstes Netzelement A angeordnet, welches im Weiteren eine Kommunikation mit einem im zweiten Netzwerkbereich DMB angeordneten zweiten Netzelement B aufbauen möchte. Die erste Netzknoteneinheit FWl ist mit der zweiten Netzkno¬ teneinheit FW2 über eine weitere Netzknoteneinheit SW »ver¬ bunden«, welche im Folgenden auch als Switch bezeichnet wird. Dabei handelt es sich z. B. um eine paketorientierte Vermitt¬ lungseinrichtung, oder unter Verwendung eines SIP-Protokolls, um einen SIP-Server. Eine »Verbindung« ist dabei grundsätzlich nicht als festgeschaltete Verbindung in einem an sich verbindungslosen paketorientierten Netzwerk zu verstehen.
Im Folgenden wird davon ausgegangen, dass die Kommunikationsverbindung zwischen den beiden Netzelementen A, B unter Verwendung des SIP-Protokolls aufgebaut wird. Die Verwendung des SIP-Protokolls ist jedoch nicht zwingend für die Ausführung des erfindungsgemäßen Verfahrens. Beispielsweise sind alter¬ native Kommunikationsprotokolle wie z. B. H.323 einsetzbar.
Eine Kommunikationsbeziehung zwischen den beiden Netzelemen- ten A, B unter Verwendung des SIP-Protokolls beginnt übli¬ cherweise mit einem gegenseitigen Austausch der eigenen Netzwerkadressen. Dieser Austausch erfolgt über ein der SIP- Protokollfamilie zugehörendes Protokoll SDP (Session Descrip- tion Protocoll) und wird normalerweise mit einer oder mehrere Einladungsnachricht (»Invite«) und korrespondierenden Bestä¬ tigungsnachrichten (»OK«) begleitet.
In der Einladungsnachricht sendet das rufende Netzelement A seine eigene IP-Adresse und den zugehörigen Port für einen eingehenden Datenverkehr, beispielsweise Sprach-, Videodaten etc. In der Bestätigungsnachricht sendet das gerufene Netz¬ element B seine eigene IP-Adresse und eine Portnummer für seinen eingehenden Datenverkehr für die aktuelle Datenverbindung (Session) .
Die in Figur 2a gezeigte Anordnung weist dabei zwei als Fire¬ wall fungierende Netzknoteneinheiten FWl, FW2 auf, die diesem Austausch von SDP-Nachrichten beeinträchtigen, so dass im schlimmsten Fall eine Kommunikationsbeziehung nicht zustande kommt. Für das Protokoll SIP würden nämlich die jeweiligen
Netzelemente A, B ihre eigene, nur lokal bekannte Netzwerkad¬ resse senden, d. h. eine Netzwerkadresse, welche nur im je- weiligen Netzwerkbereich DMA, DMB bekannt ist und mit einem NAT-Verfahren von der jeweiligen Netzknoteneinrichtung FWl, FW2 in eine öffentlich bekannte Netzwerkadresse umgesetzt wird.
Ein NAT-Verfahren sieht zudem eine Adressumsetzung nur im Header der Nachricht bzw. des Datenpakets vor, nicht aber im Nutzdatenteil (»Body«) des Datenpakets vor, der jedoch von den SIP-Protokollen für die Bestimmung des Kommunikations- partners heranzuziehen ist. Dieses Problem wird durch »SIP- Aware« ALG (Application Layer Gateways) nur wenig zufriedenstellend gelöst, da für diese ein erheblicher Performanceverlust zu verzeichnen ist, da diese den Body jedes Datenpaket untersuchen müssen.
Zur Beseitigung dieser Probleme wird erfindungsgemäß unter anderem eine Erweiterung im Protokoll ausgetauschter Einla- dungs- bzw. Bestätigungsnachrichten vorgeschlagen, das anhand eines Ablaufdiagramms gemäß Figur 2B unter weiterer Bezugnah- me auf die Funktionseinheiten der Fig. 2A erläutert wird. Das Ablaufdiagramm ist in einer vertikalen Richtung chronologisch zu verstehen, so dass spätere Zeitpunkte weiter unten liegen als frühere Zeitpunkte. In einer horizontalen Richtung ist ein Nachrichtenaustausch zwischen dem ersten Netzelement A der ersten Netzknoteneinheit FWl, dem Switch SW, der zweiten Netzknoteneinheit FW2 sowie dem zweiten Netzelement B darge¬ stellt.
Die Netzwerkadressen bzw. IP-Adressen der beteiligten Funkti- onseinheiten seien:
A : 192 . 168 . . 0 . 1 Private Adresse in DMA
FWl : 195 . 1 . 1 . . 0 Öffentliche Adresse
FW2 : 195 . 1 . 200 . 0 Öffentliche Adresse U UAASS :: 1 19922..116688.. .117700..11 Private Adresse in DMA Im Zuge einer Einrichtung eines Kommunikationsaufbaus ausge¬ hend von dem rufenden ersten Netzelement A wird von diesem eine Einladungsnachricht 202 »Invite Fl« in Richtung des zweiten Netzelements B an die erste Netzknoten FWl gesendet. Diese leitet die Einladungsnachricht in Form einer modifi¬ zierten Nachricht 204 »Invite F2« an den Switch weiter. Da die Netzknoteneinrichtung FWl nicht als spezielles »Applica¬ tion Layer Gateway« eingerichtet ist, bleibt der Inhalt im Body der Einladungsnachricht 204 gegenüber der empfangenen Einladungsnachricht 202 unverändert. Stattdessen werden von der Netzknoteneinrichtung FW4 nur Änderungen im Header des Datenpakets vorgenommen, unter anderem einer Netzwerkadressumsetzung wie in der Beschreibung der Figur 1 erläutert. Der Inhalt bzw. SIP-Teil der Einladungsnachricht 204 wird am Switch SW in folgender Form empfangen:
F2
INVITE sip: fwluser@wcom.com SIP/2.0 Via: SIP/2.0/UDP IPvβ . com: 5060 From: fwluser <sip : fwlusergwcom. com> To: fw2user <sip : fw2user@wcom. com> CaIl-ID: 12345678@wcom.com CSeq: 1 INVITE
v=0 s=Session SDP
C=IN IP4 192.168.0.1 t=3034423619 0 m=audio 49170/AVP 98 a=rtpmap:98 amr
Es handelt sich bei obiger Nachricht um den Inhalt der Nach¬ richt 204, der Header ist nicht dargestellt. Die Nachricht enthält nach wie vor die von der Netzwerkadressumsetzung nicht veränderte private Adresse 192.168.0.1 des rufenden Netzelements A im lokalen Netzwerksegment DMA. Der für das Netzelement A zu verwendende Port ist zu 49170 spezifiziert.
Der Switch SW überschreibt nun die im SDP-Teil enthaltene In- formation innerhalb der Einladungsnachricht 204 unter Anwen¬ dung der folgenden Regeln:
- die IP-Adresse innerhalb des SDP-Teils wird überschrie¬ ben mit der IP-Adresse im mit der Einladungsnachricht 204 mitgelieferten IP-Header der Einladungsnachricht
204, welche der öffentlichen Netzwerkadresse der Netzknoteneinheit FWl entspricht. Im vorliegenden Ausfüh¬ rungsbeispiel ist dies die Netzwerkadresse 195.1.1.0.
- die Schnittstellennummer bzw. Port-Nummer innerhalb des SDP-Teils der Einladungsnachricht 204 bleibt unverän¬ dert. Da die Netzknoteneinheit im Ausführungsbeispiel über eine so genannte »Port Persistance« Eigenschaft verfügt, d. h. keine Änderungen an den Portnummern vor- nimmt, wird die per Einladungsnachricht 204 übersandte Portnummer auch lokal vom Netzelement A verwendet.
Eine entsprechend geänderte Einladungsnachricht »Invite F3« 206 wird vom Switch an die zweite Netzknoteneinheit FW2 ge- sendet. Die Einladungsnachricht 206 weist die folgende Struk¬ tur auf:
F3
INVITE sip: fwluser@wcom.com SIP/2.0 Via: SIP/2.0/UDP IPv6. com: 5060
From: fwluser <sip : fwlusergwcom. com>
To: fw2user <sip : fw2user@wcom. com>
CaIl-ID: 12345678@wcom.com
CSeq: 1 INVITE . . .
v=0 s=Session SDP C=IN IP4 195.1.1.0 t=3034423619 0 m=audio 49170 /AVP 98 a=rtpmap:98 amr
Es handelt sich bei obiger Nachricht um den Inhalt der Nach¬ richt 206, der Header ist nicht dargestellt. Die Nachricht enthält nun die vom Switch SW anhand der oben genannten Re- geln veränderte öffentliche Adresse 195.1.1.0 der ersten
Netzknoteneinheit FWl. Der für das Netzelement A zu verwen¬ dende Port ist unverändert als 49170 eingetragen.
Die von der zweiten Netzknoteneinheit FW2 empfangene Einla- dungsnachricht 206 wird analog zur Vorgehensweise, insbeson¬ dere NAT, an der ersten Netzknoteneinrichtung FWl bearbeitet und in Form der Einladungsnachricht 208 »Invite F4« an das zweite Netzelement B gesendet.
Die Einladungsnachricht 206 passiert die zweite Netzknoten¬ einheit FW2, da Einladungsnachrichten üblicherweise eine De- fault-Portnummer 5060 für eine Signalisierung (Signalling) verwenden. Die Einladungsnachricht 206 wird daher in Form der Einladungsnachricht 206 durch die zweite Netzknoteneinheit FW2 unter Verwendung eines »Port Forwarding Mechanism« durchgelassen.
Im Zuge eines Erhalts der Einladungsnachricht 208 am gerufe¬ nen zweiten Netzelement B wird nun erfindungsgemäße eine vom zweiten Netzelement B in Gegenrichtung gesendetes UDP-Paket bzw. »Reverse UDP Packet« in Richtung des rufenden ersten Netzelement A gesendet, um einem Durchgangsfilter (Pinhole) an der zweiten Netzknoteneinheit FW2 zu forcieren. Dieses in Gegenrichtung gesendete Paket ist als Nachricht 210 »El« dar- gestellt. Wie in der Zeichnung versinnbildlicht, wird die
Nachricht 210 an der ersten Netzknoteneinheit FWl verworfen, hat aber auf ihrem Weg einen Durchgangsfilter in der zweiten Netzknoteneinheit FW2 geöffnet. Durch diese Vorgehensweise wird nicht nur ein Durchgangsfilter geöffnet, sondern auch eine Bindung in der zweiten Netzknoteneinheit FW2 herge¬ stellt. In der Nachricht 210 wird dabei als sendender Port eine Portnummer verwendet und vorgemerkt, welche in einem späteren Verlauf dieser Kommunikationssitzung für den Empfang eines Nutzdatenstromes 238 verwendet wird. Dieser - in der Zeichnung strichpunktiert dargestellte - Nutzdatenstrom wird mit einem RTP-Protokoll (Real Time Protocoll) transportiert.
Ein weiterer Verlauf der Kommunikationssitzung entspricht im Wesentlichen den Vorgaben des SIP-Protokolls und betrifft die Nachrichten 212, 214, 216, 218 (»Ringing F5« ... »Ringing F8«) und 220 (»OK F10«) .
Der Rufaufbau durch die Nachrichten folgt dem SIP-Protokoll bis die im SDP-Teil enthaltenen Daten der Bestätigungsnachricht 222 vom Switch SW empfangen werden. Der SDP-Teil der am Switch SW empfangenen Bestätigungsnachricht 222 (»200 OK F10«) hat dabei die folgende Struktur:
FlO
SIP/2.0 200 OK
From: fwluser <sip : fwlusergwcom. com> To: fw2user <sip : fw2user@wcom. com> CaIl-ID: 12345678@wcom.com CSeq: 1 INVITE
v=0 s=Session SDP
C=IN IP4 192.168.170.1 t=3034423619 0 m=audio 3456 RTP/AVP 98 a=rtpmap:98 amr Dabei ist die im Netzwerkbereich DMB gültige lokale IP- Adresse 192.168.170.1 des gerufenen Netzelements B eingetra¬ gen, sowie dessen Port 3456.
Der Switch SW überschreibt den SDP-Teil der Bestätigungsnachricht 222 nach den folgenden Regeln:
- die IP-Adresse innerhalb des SDP-Teils der Bestätigungs¬ nachricht 222 wird überschrieben mit der IP-Adresse im IP-Header der Bestätigungsnachricht 222, welche vormals durch die zweite Netzknoteneinrichtung FW2 zugewiesen wurde. Dies entspricht der öffentlichen Netzwerkadresse der zweiten Netzknoteneinrichtung FW2 im vorliegenden Ausführungsbeispiel besitzt diese den Wert 195.1.200.0.
- Die Port-Nummer innerhalb des SDP-Teils der Bestäti¬ gungsnachricht 222 wird nicht verändert.
Bei ihrem Verlassen besitzt der SDP-Teil der Bestätigungs- nachricht 224 gemäß den oben angewandeten Regeln die folgende Struktur:
FIl
SIP/2.0 200 OK From: fwluser <sip : fwlusergwcom. com> To: fw2user <sip : fw2user@wcom. com> CaIl-ID: 12345678@wcom.com CSeq: 1 INVITE
v=0 s=Session SDP
C=IN IP4 195.1.200.0 t=3034423619 0 m=audio 3456 RTP/AVP 98 a=rtpmap:98 amr Der Inhalt der Bestätigungsnachricht 224 enthält nun die vom Switch SW anhand der oben genannten Regeln veränderte öffentliche Adresse 195.1.200.0 der zweiten Netzknoteneinheit FWl. Der für das Netzelement B zu verwendende Port ist unverändert als 3456 eingetragen.
Die von der ersten Netzknoteneinheit FWl empfangene Bestäti¬ gungsnachricht 224 wird analog zur Vorgehensweise an der ers¬ ten bzw. zweiten Netzknoteneinrichtung FWl, FW2 bearbeitet und in Form der Bestätigungsnachricht 226 »200 OK F12« an das erste Netzelement A gesendet.
Zu dem Zeitpunkt, an dem die Bestätigungsnachricht 226 das erste Netzelement A erreicht, wird vom ersten Netzelement A ein weiteres Revers UDP-Paket in Form der Nachricht »E2« 228 in Richtung des zweiten Netzelements B gesendet. Mit dieser Nachricht 228 wird in analoger Weise ein Durchgangsfilter und eine Bindung in der ersten Netzknoteneinheit FWl hergestellt. Die Nachricht 228 wird an der zweiten Netzknoteneinheit FW2 verworfen.
Ab jetzt existieren ein Durchgangsfilter und eine Bindung in beiden als Firewall fungierenden Netzknoteneinheiten FWl, FW2.
In Folge dessen kann nun ein Nutzdatenstrom 238 bzw. RTP- Austausch (Real Time Protocoll) aufgebaut werden, welche die Limitierungen der beiden Firewalls, d. h. der beiden Netzkno- teneineiten FWl, FW2, überwindet, da an beiden Netzknotenein- heiten FWl, FW2 Bindungen existieren. Für diese Nutzdatenverbindung 238 besteht nun kein Bedarf an einer Netzwerkadressumsetzung zwischen dem Switch und den beiden Netzknoteneinheiten FWl, FW2.
Die einen Durchgangsfilter für die erste bzw. zweite Netzknoteneinrichtung FWl, FW2 erzeugenden Nachrichten 228,210 werden bei Bedarf wiederholt, z.B. falls der Durchgangsfilter wegen der erwähnten zeitlichen Beschränktheit eines offenen Zu- stands bereits geschlossen wurde, bevor die Nutzdatenverbindung 238 zustande kommen konnte.
Die im nach dem SDP vorgesehenen »Acknowledge«-Nachrichten 230...236 werden üblicherweise im Anschluss an den Erhalt der Bestätigungsnachricht gesendet, haben aber keine Bedeutung für das erfindungsgemäße Verfahren.
Zur Anwendung dieses Ausführungsbeispiels des erfindungsgemä¬ ßen Verfahrens wurde lediglich vorausgesetzt, dass die beiden eingesetzten Netzknoteneinheiten FWl, FW2 von einer »Port Preservation« Gebrauch machen, d. h. die Portnummer in ausgetauschten Nachrichten nicht verändern. Diese Eigenschaft ist in heutigen Netzknoteneinrichtungen FWl, FW2 weit verbreitet. Die Erweiterungen, die das erfindungsgemäße Verfahren bezüg¬ lich des SIP-Protokolls vorsieht, beziehen sich im Wesentli¬ chen auf eine Verwendung zweier »Reverse UDP-Pakets«, d.h. die Nachrichten 210,228. Zur Implementierung dieser Nachrich- ten 210,228 ist lediglich eine geringe Softwareänderung in den Netzelementen A, B erforderlich.
Die am SIP-Protokoll vorgesehenen Erweiterungen umfassen optional darüber hinaus ein Datenfeld, das dem Switch SW an- zeigt, die im voraus beschriebenen Regeln anzuwenden oder nicht .
Eine jeweilige Bearbeitung der Einladungs- bzw. Bestätigungs¬ nachrichten muss nicht notwendigerweise in einer zentralen Instanz wie dem im Ausführungsbeispiel beschriebenen Switch oder einem SIP-Registrar erfolgen. Mit einer Peer-to-Peer- Kommunikationsweise zwischen den Netzelementen kann eine solche Bearbeitung beispielsweise in anderen Netzelementen erfolgten. Diese Netzelemente sind z.B. analog zum Ausführungs- beispiel zwischen den Netzwerkdomänen DMA, DMB angeordnet.

Claims

Patentansprüche
1. Verfahren zum Datenaustausch zwischen Netzelementen bei dem mindestens ein rufendes und mindestens ein zu rufendes Netzelement (A, B) in unterschiedlichen, durch Netzknoteneinrichtungen (FWl, FW2) getrennte erste und zweite Netzwerkbe¬ reiche (DMA, DMB) angeordnet sind, wobei den Netzelementen (A, B) eine nur im jeweiligen Netzwerkbereich (DMA, DMB) lokal gültige Netzwerkadresse zugeordnet ist und wobei in von Netz- elementen (A, B) gesendeten Nachrichten die in Nachrichtenkopfeinträgen enthaltene lokal gültige Netzwerkadresse durch die Netzknoteneinrichtungen (FWl, FW2) in eine außerhalb des jeweiligen Netzwerkbereichs (DMA, DMB) gültige Netzwerkadresse umgesetzt wird, umfassend folgende Verfahrensschritte a) Senden mindestens einer Einladungsnachricht durch das ru¬ fende Netzelement (A) b) Modifikation des Inhalts der Einladungsnachricht anhand der im Nachrichtenkopfeintrag enthaltenen außerhalb des ers¬ ten Netzwerkbereichs (DMA) gültigen Netzwerkadresse c) Senden einer einen Durchgangsfilter für die zweite Netzknoteneinrichtung (FW2) erzeugenden Nachricht (210) nach Erhalt der Einladungsnachricht durch das zu rufende Netzele¬ ment (B) d) Senden mindestens einer Bestätigungsnachricht durch das zu rufende Netzelement (B) e) Modifikation des Inhalts der Bestätigungsnachricht anhand der im Nachrichtenkopfeintrag enthaltenen außerhalb des zwei¬ ten Netzwerkbereichs (DMB) gültigen Netzwerkadresse f) Senden einer einen Durchgangsfilter für die erste Netzkno- teneinrichtung (FWl) erzeugenden Nachricht (228) nach Erhalt der Bestätigungsnachricht durch das zu rufende Netzelement (B)
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Datenaustausch eine Nutzdatenverbindung ist.
3. Verfahren einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass der Datenaustausch einer Kommunikationsverbindung dient.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Einladungs- und/oder Bestätigungsnachrichten gemäß der Protokolle SIP- und/oder SDP gestaltet sind.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Schritte c) und f) wiederholt werden um eine Nutzda¬ tenverbindung (238) zu erhalten.
6. Computerprogrammprodukt mit Programmkode zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 5 und zur Aus¬ führung der Verfahrensschritte c) und/oder f) wenn das Compu¬ terprogrammprodukt auf einem der Netzelement (A; B) abläuft.
7. Netzelement zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 5, mit Mitteln zur Ausführung der Verfahrens¬ schritte c) und/oder f) .
8. Switch zur Durchführung des Verfahrens nach einem der An- sprüche 1 bis 5, mit Mitteln zur Ausführung der Verfahrens¬ schritte b) und/oder e) .
PCT/EP2006/064781 2005-07-29 2006-07-28 Verfahren zum datenaustausch zwischen netzelementen WO2007012666A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/997,276 US20080165782A1 (en) 2005-07-29 2006-07-28 Method for Data Interchange Between Network Elements
EP06778049A EP1913756A1 (de) 2005-07-29 2006-07-28 Verfahren zum datenaustausch zwischen netzelementen

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005035733.4 2005-07-29
DE102005035733A DE102005035733A1 (de) 2005-07-29 2005-07-29 Verfahren zum Datenaustausch zwischen Netzelementen

Publications (1)

Publication Number Publication Date
WO2007012666A1 true WO2007012666A1 (de) 2007-02-01

Family

ID=36997825

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/064781 WO2007012666A1 (de) 2005-07-29 2006-07-28 Verfahren zum datenaustausch zwischen netzelementen

Country Status (4)

Country Link
US (1) US20080165782A1 (de)
EP (1) EP1913756A1 (de)
DE (1) DE102005035733A1 (de)
WO (1) WO2007012666A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8571012B2 (en) * 2006-05-12 2013-10-29 Oracle International Corporation Customized sip routing to cross firewalls
US8582555B2 (en) * 2006-05-12 2013-11-12 Oracle International Corporation SIP routing customization
US8631069B2 (en) * 2007-03-01 2014-01-14 Oracle International Corporation Web and multi-media conference
US8077704B2 (en) * 2009-01-06 2011-12-13 Oracle International Corporation Web service assisted real-time session peering between enterprise VoIP networks via internet
US8489772B2 (en) * 2010-03-09 2013-07-16 At&T Intellectual Property I, L.P. Method for mechanically generating content for messages

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050105526A1 (en) * 2003-11-18 2005-05-19 Nec Corporation Method for traversing network address translators for SIP-signaled sessions

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2369746A (en) * 2000-11-30 2002-06-05 Ridgeway Systems & Software Lt Communications system with network address translation
US7068655B2 (en) * 2001-06-14 2006-06-27 Nortel Networks Limited Network address and/or port translation
US6987765B2 (en) * 2001-06-14 2006-01-17 Nortel Networks Limited Changing media sessions
US20050008024A1 (en) * 2003-06-27 2005-01-13 Marconi Communications, Inc. Gateway and method
US7486684B2 (en) * 2003-09-30 2009-02-03 Alcatel-Lucent Usa Inc. Method and apparatus for establishment and management of voice-over IP virtual private networks in IP-based communication systems
GB0326160D0 (en) * 2003-11-08 2003-12-17 Marconi Comm Ltd Call set-up systems
US8184641B2 (en) * 2005-07-20 2012-05-22 Verizon Business Global Llc Method and system for providing secure communications between proxy servers in support of interdomain traversal

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050105526A1 (en) * 2003-11-18 2005-05-19 Nec Corporation Method for traversing network address translators for SIP-signaled sessions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROSENBERG J ET AL: "Getting SIP through Firewalls and NATs", INTERNET CITATION, 22 February 2000 (2000-02-22), XP002167710, Retrieved from the Internet <URL:http://www.softarmor.com/sipwg/draft-rosenberg-sip-firewalls-00.txt> [retrieved on 20010518] *

Also Published As

Publication number Publication date
EP1913756A1 (de) 2008-04-23
US20080165782A1 (en) 2008-07-10
DE102005035733A1 (de) 2007-02-01

Similar Documents

Publication Publication Date Title
EP2073480B1 (de) Verfahren zur Zuordnung von zumindest einer Nutzdatenverbindung zu zumindest einer Multiplexverbindung
EP2193649B1 (de) Verfahren und Vorrichtung zur Verbindung paketorientierter Kommunikationsendgeräte
EP1193919A2 (de) Verfahren zum Verbindungsaufbau von einem Endgerät eines Kommunikationsnetzes zu einem netzexternen Verbindungsziel und Einrichtungen zur Realisierung des Verfahrens
DE10353925B4 (de) Verfahren zum Austausch von Daten zwischen zwei Hosts
WO2005020535A1 (de) Verfahren, software-produkt und vorrichtungen zur signalisierung der modifikation von bearerverbindungen mittels sip protokoll
WO2007012666A1 (de) Verfahren zum datenaustausch zwischen netzelementen
EP2036313B1 (de) Verfahren zur verwaltung von kommunikationsverbindungen über netzwerk-adressumsetzende nat netzknoten
DE10147148A1 (de) Netzübergangseinrichtung und Kommunikationssystem für Echtzeitkommunikationsverbindungen
DE10321227A1 (de) Verfahren zum Datenaustausch zwischen Netzelementen
DE10226901B3 (de) Verfahren zur Verbindungssteuerung in einem paketorientierten Kommunikationsnetz sowie Anordnungen zu seiner Durchführung
EP2279603B1 (de) Vorrichtung und Verfahren zur Neuverhandlung einer Multimediaverbindung sowie zugehöriges Kommunikationssystem, digitales Speichermedium, Computer-Programm-Produkt und Computerprogramm
EP1521486A2 (de) Anordnung und Verfahren zur Steuerung von Kommunikationsverbindungen
EP1924072A1 (de) Aufbau einer Kommunikationsverbindung in einem privaten IP-Netzwerk ohne Kontaktierung eines öffentlichen STUN-Servers
EP1522183B1 (de) Verfahren zur Adressumsetzung in Paketnetzen und Steuerelement für Kommunikationsnetzwerke
WO2006013133A1 (de) Verfahren zur überwachung eines nachrichtenverkehrs, sowie eine erste und zweite netzwerkeinheit zu dessen durchführung
EP1383295B1 (de) Verfahren zur Adressumsetzung in Paketnetzen und Adressumsetzer für Kommunikationsnetzwerke
EP1513312A1 (de) Multimediale Videotelephonie
Beise Kapitel 4 VoIP-Harmonization of Protocols and Standards
WO2004086717A1 (de) Verfahren zur übertragung von daten in einem datennetz mit einer mehrzahl von rechnern
DE102007001408A1 (de) Verfahren und Kommunikationsanordnung zum Transport von Multimediadaten zwischen IP-Endgeräten in einem lokalen Netz eines WAN
Kanbach et al. Protokollarchitektur mit SIP
WO2007128618A1 (de) Vorrichtung und verfahren zur unterstützung des leistungsmerkmals &#39;hand off call&#39; in fmc netzen
EP1575241A1 (de) Multimedia-Gateway für IP Version 4 und IP Version 6 Netze

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006778049

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 320/KOLNP/2008

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 11997276

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2006778049

Country of ref document: EP