EP1913756A1 - Verfahren zum datenaustausch zwischen netzelementen - Google Patents

Verfahren zum datenaustausch zwischen netzelementen

Info

Publication number
EP1913756A1
EP1913756A1 EP06778049A EP06778049A EP1913756A1 EP 1913756 A1 EP1913756 A1 EP 1913756A1 EP 06778049 A EP06778049 A EP 06778049A EP 06778049 A EP06778049 A EP 06778049A EP 1913756 A1 EP1913756 A1 EP 1913756A1
Authority
EP
European Patent Office
Prior art keywords
network
message
address
network node
network element
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
EP06778049A
Other languages
English (en)
French (fr)
Inventor
Mohammad Vizaei
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 EP1913756A1 publication Critical patent/EP1913756A1/de
Withdrawn legal-status Critical Current

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

  • the invention relates to a method for data exchange of network elements, which are arranged in different network areas.
  • network node devices for example routers, firewalls or gateways.
  • a packet-oriented data exchange takes place, for example, using the »Internet Protocol «, abbreviated to IP. In the further description is sometimes referred to the Internet Protocol, although a USAGE ⁇ -making of this protocol is exemplary only.
  • a packet-oriented data exchange includes all packet-oriented communication ways in which to to exchange data packets used in a data part and a charac ⁇ ter Budapest in the literature often "header" - composed.
  • the header contains at NASAerwei- se a the sending network element characterizing ⁇ sender address and a destined for the receiving network element characterizing destination address.
  • 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
  • SIP Session Initiated Protocol
  • H.323 the communication protocols SIP known as "Session Initiated Protocol” or H.323.
  • the SIP protocol is often used munication to any commu ⁇ or "sessions" with one or more participants to manage.
  • a possible communication connection is a VoIP (Voice over Internet protocol) telephony or any multimedia streams, conferences,
  • 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.
  • the inventive method provides at least a calling and at least one network element in Chen evocative of differing ⁇ separated by firewalls or network node devices first and second network areas.
  • the network elements are usually assigned a locally valid network address only in the respective network area.
  • This locally valid network ⁇ address is converted into the message header entries and headers of messages that send the network elements to localized outside their network area network elements from the respective network node device by a valid outside their network area network address, in particular by a globally valid network address of the network node element.
  • the invention provides that, after the sending of an invitation message (for example a SIP Invite), the content of the invitation message is modified on the basis of the network address valid outside the first network area contained in the message header entry, that is to say an entry contained in the header by the network node. unit previously changed IP address in a body of Nach ⁇ judge.
  • the second network element to be called sends a message in the direction of the calling first network element. This message generates a pass-through filter or pinhole in the second network node device and is "dropped" at the first network node device.
  • a confirmation message is sent by the management to be called Netzele ⁇ .
  • This confirmation message is eg by the used communication protocol, such as SIP, before ⁇ seen.
  • 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:
  • the port number or port number within the SDP part of the invitation message 204 is changed unverän ⁇ . Since the network node unit in the exemplary embodiment has a so-called "port-persistence" feature, ie, does not make any changes to the port numbers, the port number transmitted by invitation message 204 is also used locally by network element A.
  • 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:
  • INVITE sip fwluser@wcom.com SIP / 2.0 Via: SIP / 2.0 / UDP IPv6. com: 5060
  • 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 SDP portion of the confirmation message 224 has the following structure according to the rules applied above:
  • the received from the first network node unit FWL Affirmation ⁇ supply object 224 is analogous to the procedure at the ers ⁇ th and the second network node device FWL, edited FW2 and sent in the form of the confirmation message 226 "200 OK F12" to the first network element A.
  • 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.
  • a user data stream 238 or RTP exchange (Real Time Protocol) can now be set up, which reduces the limitations of the two firewalls, ie. H. of the two network node lines FW1, FW2, because at both network node units FW1, FW2 bindings exist.
  • RTP exchange Real Time Protocol
  • 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.
  • the provided in the SDP "Acknowledge" messages 230 ... 236 are usually sent after receiving the confirmation message, but have no meaning for the inventive method.
  • extensions provided on the SIP protocol optionally include a data field which indicates to the SW switch whether or not to apply the rules described above.
  • 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) .
EP06778049A 2005-07-29 2006-07-28 Verfahren zum datenaustausch zwischen netzelementen Withdrawn EP1913756A1 (de)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP1913756A1 true EP1913756A1 (de) 2008-04-23

Family

ID=36997825

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06778049A Withdrawn EP1913756A1 (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

Family Cites Families (8)

* 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
DE10353925B4 (de) * 2003-11-18 2009-12-24 Nec Europe Ltd. Verfahren zum Austausch von Daten zwischen zwei Hosts
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

Non-Patent Citations (1)

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

Also Published As

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

Similar Documents

Publication Publication Date Title
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
EP2073480B1 (de) Verfahren zur Zuordnung von zumindest einer Nutzdatenverbindung zu zumindest einer Multiplexverbindung
EP1656781A1 (de) Verfahren, software-produkt und vorrichtungen zur signalisierung der modifikation von bearerverbindungen mittels sip protokoll
EP1913756A1 (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
EP1771993A1 (de) Verfahren zur überwachung eines nachrichtenverkehrs, sowie eine erste und zweite netzwerkeinheit zu dessen durchführung
EP1521486A2 (de) Anordnung und Verfahren zur Steuerung von Kommunikationsverbindungen
EP2279603B1 (de) Vorrichtung und Verfahren zur Neuverhandlung einer Multimediaverbindung sowie zugehöriges Kommunikationssystem, digitales Speichermedium, Computer-Programm-Produkt und Computerprogramm
DE102004040480A1 (de) Verfahren und Vorrichtung zum Nutzdatenabgriff multimedialer Verbindungen in einem Paketnetz
EP1522183B1 (de) Verfahren zur Adressumsetzung in Paketnetzen und Steuerelement für Kommunikationsnetzwerke
EP1383295B1 (de) Verfahren zur Adressumsetzung in Paketnetzen und Adressumsetzer für Kommunikationsnetzwerke
EP1924072A1 (de) Aufbau einer Kommunikationsverbindung in einem privaten IP-Netzwerk ohne Kontaktierung eines öffentlichen STUN-Servers
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
EP1575241A1 (de) Multimedia-Gateway für IP Version 4 und IP Version 6 Netze

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

AK Designated contracting states

Kind code of ref document: A1

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

17Q First examination report despatched

Effective date: 20080602

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20081014