-
Die
Erfindung betrifft ein Verfahren zum Datenaustausch von Netzelementen,
welche in unterschiedlichen Netzwerkbereichen angeordnet sind.
-
Zur
Unterstützung
und zur Absicherung eines Datenaustauschs 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 Verwendung
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 charakterisierenden Teil – in der Literatur häufig »Header« genannt – zusammensetzen.
Der Header enthält
dabei üblicherweise
eine das sendende Netzelement charakterisierende Absenderadresse
sowie eine das für
den Empfang bestimmte Netzelement charakterisierende Zieladresse.
-
Bei
einer Verwendung von lediglich innerhalb eines ersten lokalen Netzwerkbereichs
gültigen – »lokalen« – Adressen
zur Adressierung eines Netzelements ist für eine Kommunikation mit Netzelementen
eines zweiten Netzwerkbereichs eine Umsetzung der im ersten Netzwerk
lokal gültigen
Adressen in für
den zweiten Netzwerkbereich gültige
Adressen bekannt. Als Absender- 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 (Internet Engineering
Task Force) werden verschiedene Applikationen bzw. Kommunikationsprotokolle
genannt, bei deren Anwendung Probleme mit der vorgenannten Adressumsetzung
auftreten.
-
Eine
Kategorie problembehafteter Applikationen stellen dabei sogenannte »Bundled
Session Applications« dar,
bei deren paketorientierten Datenaustausch Adressierungsinformationen
zusätzlich
zu einer im Header auch in einem Datenteil (»Payload«) eines jeweiligen Datenpakets
enthalten sind.
-
Da
die im Payload enthaltenen – ebenso
wie die im Header enthaltenen – 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, ausgestaltet sind. Diese ALG berücksichtigen auch im Payload
enthaltene Adressinformationen für
eine NAT-analoge Adressumsetzung. Derartige ALG sind jedoch spezifisch
auf das jeweilige 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 Kommunikationsprotokolle SIP
(»Session
Initiated Protocol«)
bzw. H.323.
-
Das
Protokoll SIP wird häufig
eingesetzt, um beliebige Kommunikationsverbindungen oder »Sessions« mit einem
oder mehreren Teilnehmern zu verwalten. Eine mögliche Kommunikationsverbindung
ist dabei eine VoIP-Telefonie (Voice over Internet protocol) oder
auch beliebige Multimediaströme,
Konferenzen, Computerspiele usw. Das Protokoll SIP dient dazu, die
Kommunikationsverbindung zu ermöglichen,
wobei die eigentlichen Daten für
die Kommunikation über
andere Protokolle ausgetauscht 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 Transport über RTP umfasst beispielsweise
eine Einteilung der beispielsweise mit einem Codec kodierten und
komprimierten Nutzdaten in Datenpakete und deren Versand. Ein Versand
erfolgt beispielsweise mit einem Transportprotokoll wie UDP (User
Datagram Protocol).
-
Ein
Einsatz eines ALG zur Ermöglichung
eines Datenaustauschs wie beispielsweise einer Kommunikationsverbindung
ist häufig
auf ein spezifisches Protokoll wie SIP beschränkt. Zudem müssen beide
Netzwerkbereiche eine gleichgestaltete, d.h. auf das verwendete
Kommunikationsprotokoll abgestimmte ALG aufweisen.
-
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 Adressierungsinformationen 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 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 Nachrichtenkopfeinträgen 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
Netzknoteneinheit zuvor geäderte
IP-Adresse in einem Body der Nachricht. 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 rufende 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.
-
Ein
wesentlicher Vorteil des erfindungsgemäßen Verfahrens ist darin zu
sehen, dass eine gattungsübliche
Netzknoteneinrichtung – insbesondere
Gateway oder Router – ohne
weitere gestalterische Eingriffe zur Verbindung der beiden Netzwerkbereiche
eingesetzt werden kann.
-
Das
erfindungsgemäße Verfahren
ist vorteilhaft in den Netzelementen, 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 Ausgestaltungen der Erfindung wird im
folgenden anhand der Zeichnung näher
erläutert.
-
Dabei
zeigen:
-
1:
ein chronologisches Ablaufbild zur schematischen Darstellung einer
Funktion einer aus dem Stand der Technik bekannten Firewall;
-
2A:
ein Strukturbild zur schematischen Darstellung einer Kommunikationsumgebung
-
2B:
ein chronologisches Ablaufbild zur schematischen Darstellung eines
erfindungsgemäßen Nachrichtenaustauschs
zum Aufbau einer Kommunikationsverbindung.
-
1 zeigt
eine aus dem Stand der Technik bekannte Firewall bzw. Gateway, bei
dem eine Netzwerkadressumsetzung bzw. NAT (Network Address Translation)
durchgeführt
wird. Eine dargestellte Firewall FW1 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 FW1 wird im Folgenden
mit dem allgemeinerem Begriff Netzknoteneinrichtung FW1 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 1 dargestellt
ist, wird davon ausgegangen, dass an der Netzknoteneinrichtung FW1
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 Portnummer charakterisiert. Es
wird weiterhin davon ausgegangen, dass der Nachricht 101 kein
weiterer Nachrichtenverkehr vorausging, so dass in der Netzknoteneinrichtung
FW1 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 (discarded 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 Ziffer 2 in 1 dargestellt
ist, wird von einer zweiten Nachricht 102 ausgegangen,
welche innerhalb des lokalen Netzwerks 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 dargestellten – empfangendes
Element im öffentlichen
Netzwerk WAN, d.h. jenseits der Netzknoteneinrichtung FW1. Das empfangende
Netzelement ist durch die Netzwerkadresse Z bzw. durch den Port
z gekennzeichnet ist (in der Zeichnung »Receiver: Z:z«). Der
Netzknoten FW1 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 gekennzeichnet, dass die ursprüngliche
Absendernetzwerkadresse X durch eine veränderte Absenderadresse Y ersetzt
wurde. Die neue Absenderadresse Y entspricht der Netzwerkadresse
der Netzknoteneinrichtung FW1. Im Zuge der Weiterleitung der Nachricht 102 in
das öffentliche
Netzwerk WAN in Form der Nachricht 103 reserviert die Netzknoteneinrichtung
FW1 einen Durchgangsfilter (Pinhole) und ruft eine Bindung mit einer
Vormerkung der verwendeten Schnittstelle auf. Mit einer für die Netzknoteneinrichtung
FW1 benutzten Netzwerkadresse Y lautet diese Bindung:
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 Netzwerkadresse X:x übermittelt
wird und umgekehrt. Die Bindung verwendet die ursprünglich verwendete
und beibehaltene Portnummer. 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 dargestellten – sendenden
Element, charakterisiert durch die Netzwerkadresse Z' und durch die Schnittstelle
z' ausgegangen.
Die Adress-/Portkombination Z':z' unterscheidet sich
also von der aus dem zweiten Fall bekannten Adress-/Portkombination
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 Netzknoteneinrichtung
FW1 abgewiesen, da diese eine nicht mit der vormaligen Bindung übereinstimmende
Kombination aus Netzwerkadresse und Schnittstelle aufweist.
-
Die
anhand von 1 beschriebene Funktionsweise
einer Netzknoteneinrichtung, welche als Firewall zwischen einem öffentlichen
Netzwerk WAN und einem lokalen Netzwerk LAN fungiert, verhindert
oftmals einen Aufbau von Kommunikationsverbindungen, welche beispielsweise
auf Basis des SIP-Protokolls geführt werden.
Die dabei entstehenden Probleme werden anhand einer Anordnung gemäß 2a beschrieben.
Die Figur zeigt einen ersten Netzwerkbereich DMA bzw. Netzwerkdomäne DMA,
welche gegenüber
anderen Netzwerkbereichen mit einer ersten Netzknoteneinrichtung
FW1 abgeschlossen bzw. gesichert ist. Entsprechendes gilt für einen
zweiten Netzwerkbereich DMB und einer zweiten Netzknoteneinheit
FW2. Im ersten Netzwerkbereich 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 FW1 ist mit der zweiten Netzknoteneinheit
FW2 über
eine weitere Netzknoteneinheit SW »verbunden«, welche im Folgenden auch
als Switch bezeichnet wird.
-
Dabei
handelt es sich z. B. um eine paketorientierte Vermittlungseinrichtung,
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 alternative Kommunikationsprotokolle wie z.
B. H.323 einsetzbar.
-
Eine
Kommunikationsbeziehung zwischen den beiden Netzelementen A, B unter
Verwendung des SIP-Protokolls beginnt üblicherweise mit einem gegenseitigen
Austausch der eigenen Netzwerkadressen. Dieser Austausch erfolgt über ein
der SIP-Protokollfamilie
zugehörendes
Protokoll SDP (Session Description 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 Netzelement B seine eigene IP-Adresse und eine
Portnummer für
seinen eingehenden Datenverkehr für die aktuelle Datenverbindung
(Session).
-
Die
in 2a gezeigte Anordnung weist dabei zwei als Firewall
fungierende Netzknoteneinheiten FW1, 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
Netzwerkadresse senden, d. h. eine Netzwerkadresse, welche nur im
je weiligen Netzwerkbereich DMA, DMB bekannt ist und mit einem NAT-Verfahren
von der jeweiligen Netzknoteneinrichtung FW1, 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 Kommunikationspartners
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 Einladungs- bzw. Bestätigungsnachrichten
vorgeschlagen, das anhand eines Ablaufdiagramms gemäß 2B unter
weiterer Bezugnahme auf die Funktionseinheiten der 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 FW1, dem Switch SW, der zweiten Netzknoteneinheit
FW2 sowie dem zweiten Netzelement B dargestellt.
-
Die
Netzwerkadressen bzw. IP-Adressen der beteiligten Funktionseinheiten
seien:
-
Im
Zuge einer Einrichtung eines Kommunikationsaufbaus ausgehend von
dem rufenden ersten Netzelement A wird von diesem eine Einladungsnachricht 202 »Invite
F1« in
Richtung des zweiten Netzelements B an die erste Netzknoten FW1
gesendet. Diese leitet die Einladungsnachricht in Form einer modifizierten Nachricht 204 »Invite
F2« an
den Switch weiter. Da die Netzknoteneinrichtung FW1 nicht als spezielles »Application
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 1 erläutert. Der Inhalt bzw. SIP-Teil
der Einladungsnachricht 204 wird am Switch SW in folgender
Form empfangen:
F2
INVITE sip:fw1user@wcom.com SIP/2.0
Via:
SIP/2.0/UDP IPv6.com:5060
From: fw1user <sip:fw1user@wcom.com>
To: fw2user <sip:fw2user@wcom.com>
Call-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 Nachricht 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 Information innerhalb der Einladungsnachricht 204 unter
Anwendung der folgenden Regeln:
- – die IP-Adresse
innerhalb des SDP-Teils wird überschrieben
mit der IP-Adresse im mit der Einladungsnachricht 204 mitgelieferten
IP-Header der Einladungsnachricht 204, welche der öffentlichen
Netzwerkadresse der Netzknoteneinheit FW1 entspricht. Im vorliegenden
Ausführungsbeispiel
ist dies die Netzwerkadresse 195.1.1.0.
- – die
Schnittstellennummer bzw. Port-Nummer innerhalb des SDP-Teils der
Einladungsnachricht 204 bleibt unverändert. Da die Netzknoteneinheit
im Ausführungsbeispiel über eine
so genannte »Port
Persistance« Eigenschaft
verfügt,
d. h. keine Änderungen
an den Portnummern vornimmt, 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 gesendet. Die Einladungsnachricht 206 weist
die folgende Struktur auf:
F3
INVITE sip:fw1user@wcom.com
SIP/2.0
Via: SIP/2.0/UDP IPv6.com:5060
From: fw1user <sip:fw1user@wcom.com>
To: fw2user <sip:fw2user@wcom.com>
Call-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 Nachricht 206,
der Header ist nicht dargestellt. Die Nachricht enthält nun die
vom Switch SW anhand der oben genannten Regeln veränderte öffentliche Adresse
195.1.1.0 der ersten Netzknoteneinheit FW1. Der für das Netzelement
A zu verwendende Port ist unverändert
als 49170 eingetragen.
-
Die
von der zweiten Netzknoteneinheit FW2 empfangene Einladungsnachricht 206 wird
analog zur Vorgehensweise, insbesondere NAT, an der ersten Netzknoteneinrichtung
FW1 bearbeitet und in Form der Einladungsnachricht 208 »Invite
F4« an
das zweite Netzelement B gesendet.
-
Die
Einladungsnachricht 206 passiert die zweite Netzknoteneinheit
FW2, da Einladungsnachrichten üblicherweise
eine Default-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 gerufenen
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 »E1« dargestellt.
Wie in der Zeichnung versinnbildlicht, wird die Nachricht 210 an
der ersten Netzknoteneinheit FW1 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 hergestellt.
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 Protokoll) 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:
F10
SIP/2.0 200 OK
From:
fw1user <sip:fw1user@wcom.com>
To: fw2user <sip:fw2user@wcom.com>
Call-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 eingetragen, 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ätigungsnachricht 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ätigungsnachricht 222 wird
nicht verändert.
-
Bei
ihrem Verlassen besitzt der SDP-Teil der Bestätigungsnachricht 224 gemäß den oben
angewandeten Regeln die folgende Struktur:
F11
SIP/2.0
200 OK
From: fw1user <sip:fw1user@wcom.com>
To: fw2user <sip:fw2user@wcom.com>
Call-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 FW1. Der für das Netzelement
B zu verwendende Port ist unverändert
als 3456 eingetragen.
-
Die
von der ersten Netzknoteneinheit FW1 empfangene Bestätigungsnachricht 224 wird
analog zur Vorgehensweise an der ersten bzw. zweiten Netzknoteneinrichtung
FW1, 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 FW1 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 FW1, 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 Netzknoteneineiten FW1, FW2, überwindet,
da an beiden Netzknoteneinheiten FW1, FW2 Bindungen existieren.
Für diese
Nutzdatenverbindung 238 besteht nun kein Bedarf an einer
Netzwerkadressumsetzung zwischen dem Switch und den beiden Netzknoteneinheiten
FW1, FW2.
-
Die
einen Durchgangsfilter für
die erste bzw. zweite Netzknoteneinrichtung FW1, FW2 erzeugenden Nachrichten 228, 210 werden
bei Bedarf wiederholt, z.B. falls der Durchgangsfilter wegen der
erwähnten
zeitlichen Beschränktheit
eines offenen Zustands 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
FW1, FW2 von einer »Port
Preservation« Gebrauch
machen, d. h. die Portnummer in ausgetauschten Nachrichten nicht
verändern.
Diese Eigenschaft ist in heutigen Netzknoteneinrichtungen FW1, FW2
weit verbreitet. Die Erweiterungen, die das erfindungsgemäße Verfahren
bezüglich
des SIP-Protokolls vorsieht, beziehen sich im Wesentlichen auf eine
Verwendung zweier »Reverse
UDP-Pakets«,
d.h. die Nachrichten 210, 228. Zur Implementierung
dieser Nachrichten 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 anzeigt, die im voraus beschriebenen
Regeln anzuwenden oder nicht.
-
Eine
jeweilige Bearbeitung der Einladungs- bzw. Bestätigungsnachrichten 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ührungsbeispiel
zwischen den Netzwerkdomänen
DMA, DMB angeordnet.
