NAT und VoIP
NAT übersetzt IP-Adressen und arbeitet daher ausschließlich auf ISO/OSI-Ebene 3. Bezieht man NAPT mit ein, werden zusätzlich noch die Portnummern auf OSI-Ebene 4 verändert. NAT bzw. NAPT arbeiten aber transparent aus Sicht der Anwendungen bzw. höheren OSI-Schichten. Will heißen, der Payload, der sich aus den höheren OSI-Schichten ergibt, wird bei NAT bzw. NAPT nicht verändert. VoIP arbeitet aber sowohl auf der Anwendungs- als auch auf der Netzwerkebene, so dass sehr wohl IP-Adressen in dem Payload der höheren Schichten transportiert werden.
SIP und SDP in unserem Fall arbeiten auf OSI-Schicht 5, also oberhalb IP und TCP/UDP. Deshalb werden in der Anrufsignalisierung von VoIP mittels SIP weiterhin private Adressen von VoIP-Telefonen verwendet. NAT macht zwar die Pakete im Internet durch öffentliche Adressen routbar, jedoch bleibt der Payload unverändert und der privaten Adresse.
VoIP ©iStockphoto/ArtemSam
Meldet sich nun über SIP und SDP ein VoIP-Telefon beim SIP-Server (Registrar bzw. Location-Server) an, sendet es zunächst seine private, lokale IP-Adresse nach RFC 1918 im Payload zum Server. Hierbei teilt das Telefon dem Server also mit, unter welcher IP-Adresse und welchem Port es Anrufe entgegennimmt. Hinter NAT hat das VoIP-Telefon natürlich eine private IP Adresse, die von außen nicht erreichbar ist. Die öffentliche Adresse kennt das VoIP-Telefon aber nicht. Daher versuchen Gegenstellen Anrufe zur privaten IP-Adresse (vergebens) aufzubauen.
Ferner wird über SIP und SDP ein Telefongespräch signalisiert und ausgehandelt. Die eigentlichen Sprachdaten werden jedoch über RTP / RTCP über komplett andere Ports übermittelt. Welche Ports das genau sind, entscheiden die beiden involvierten VoIP-Telefone dynamisch beim Verbindungsaufbau. Also versucht die Gegenstelle den RTP-Stream an den spezifizierten Port zu schicken. Für die öffentliche IP Adresse und RTP Port als Tuple existiert beim NAT-Router aber kein Eintrag und somit keine Übersetzung in eine private IP-Adresse!
In beiden genannten Fällen kommt es zu Problemen, weil auf der Anwendungsebene IP-Adressen- und Portinformationen übermittelt werden.
Abhilfe schafft z.B. Universal Plug & Play (UPnP) in VoIP-Telefonen oder Softphones (bspw. bei SIPPS ). Im VoIP-Szenario fragt das Telefon über UPnP den NAT-Router, welche öffentliche IP-Adresse und Ports es benutzen darf. Diese Informationen verwendet das VoIP-Telefon als Absenderadresse in den entsprechenden Protokollen (SIP / SDP). Der NAT-Router konfiguriert sich dann so, dass die eingehenden Pakete auch das Telefon erreichen. Leider sind nur wenige NAT-Implementierungen UPnP-tauglich.
Eine andere Lösung wird mit STUN (RFC 3489, Simple Traversal of UDP through NAT) zur Verfügung gestellt. Bei STUN handelt es sich um die Möglichkeit, mit der VoIP-Telefone hinter einem NAT-Router die Netzwerkkonfiguration herausfinden können. So sendet das VoIP-Telefon eine Nachricht an einen außerhalb des lokalen Netzes befindlichen STUN-Server. Dieser schickt dann ein Paket zurück, das die öffentliche Absenderadresse und -port des NAT-Routers enthält, also die tatsächlichen Informationen, die vom NAT-Router als Absender eingetragen wurden. So kann das VoIP-Telefon in seinen SIP / SDP-Nachrichten öffentliche Adressen verwenden. Leider werden die Einträge in der Übersetzungstabelle eines NAT-Routers nach einer gewissen Zeit gelöscht, so dass öfters Anfragen zum STUN-Server stattfinden müssen.
