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.