NAT (Network Address Translation) ist eine Technik, die bei fast jedem DSL-Router zum Einsatz kommt. Dabei werden im eigenen Netz private IP-Adressen (z.B. 192.168.1.y) verwendet. Der NAT-Router hat auf der Internet-Seite eine öffentliche IP-Adresse (vom DSL-Provider oftmals dynamisch zugewiesen) und jede Anfrage ins Internet und jede Antwort wird vom Router zwischen den beiden Netzen übersetzt. In der Praxis funktioniert das bei klassischen Internet-Diensten (z.B. http) sehr gut. NAT in Verbindung mit SIP ist aber aus drei Gründen nicht einfach.

1. UDP

SIP basiert auf UDP und ist damit verbindungslos. Bei UDP-Verbindungen (z.B. SIP) schickt der PC / das Endgerät ein verbindungsloses Paket an den outbox-SIP-Server. Dieser schickt ein verbindungsloses Paket an den PC zurück. Der NAT-Router bekommt daher ein Paket vom outbox-SIP-Server und muss erkennen, zu welchem Endgerät dieses Paket gehört. Nur dann kann er es richtig weiterleiten. Dazu führt er eine interne Liste, welches Endgerät mit welchem Server (ggf. – je nach NAT-Typ – auch noch unterteilt in welche Ports) Kontakt aufgenommen hat, damit er mögliche Antworten wiedererkennt. Das funktioniert je nach NAT-Technik und Qualität der NAT-Umsetzung des Routers unterschiedlich gut. SIP benutzt zudem nicht nur einen einzigen UDP-Port, sondern auch die Ton-Übertragung (RTP-Stream) läuft über UDP, zudem noch mit unterschiedlichen Zielen für Signalisierung und RTP (die SIP-Nachrichten werden mit dem für das Produkt zuständigen LoadBalancer oder SIP-Registrar mit eingebautem LoadBalancer ausgehandelt, der RTP-Stream wird direkt von/an das System geschickt, das den Anruf tatsächlich verarbeitet). Dies erschwert die Erkennung durch den Router.

2. Das Endgerät kennt seine IP nicht

Bei der Kommunikation über SIP handeln beide Teilnehmer per SIP-Nachrichten untereinander aus, welcher Sprachcodec genutzt wird und über welche IP-Adressen und Ports sie den Ton übertragen. Hängt das Endgerät hinter einem NAT-Router, so kennt es seine öffentliche IP-Adresse nicht. Eine fehlerfreie Übertragung ist daher kaum möglich.

3. UDP-Pakete in Richtung outbox -> Endgerät kommen unerwartet

Beim Aufruf einer Internet-Seite kommen die Antworten sofort nach der Anfrage. Kein Webserver würde Minuten oder gar Stunden später Antworten schicken. Bei SIP ist das anders: Zum einen können z.B. die RTP-Daten bei einem längeren Gespräch auch noch Minuten nach der Anwahl eintreffen, und zum anderen können bei eingehenden Anrufen (die das Endgerät dem NAT-Router ja nicht ankündigen kann) auch unerwartete INVITE-Nachrichten von outbox an den Router geschickt werden.


Die bekanntesten NAT-Probleme sind:

• Man wählt raus, beim angerufenen B-Teilnehmer klingelt es auch, aber der A-Teilnehmer hört gar nichts oder bekommt z.B. nicht mit, wenn der B-Teilnehmer abhebt (es klingelt scheinbar weiter). In diesem Fall kommen die Signalisierungs-Nachrichten von uns (das Ringing oder bei Zustandekommen des Gespräches das OK) nicht bis zum Endgerät durch.

• Beim Telefonieren hört man den Gegenüber nicht (man selbst ist beim Gesprächspartner aber zu hören). Der RTP-Stream kommt nicht durch den NAT-Router zum Endgerät durch.

• Nach einer bestimmten Zeit (z.B. 5 oder 10 Minuten) werden Gespräche beendet. In diesem Fall hat der NAT-Router beim Gesprächsaufbau die Ports nur für eine befristete Zeit zum Endgerät umgeleitet, und wenn diese Zeit abgelaufen ist und in dieser Zeit z.B. keine SIP-Nachrichten mehr erkannt wurden, hält er die Kommunikation für beendet. Genaugenommen wird das Gespräch nicht beendet, sondern man hört nichts mehr.

• Man empfängt keine ankommenden Anrufe. Der NAT-Router reicht die SIP-Nachrichten, mit denen der Anruf gestartet wird, nicht bis zum Endgerät durch.

• Hat man längere Zeit nicht telefoniert, ist man nicht erreichbar und muss sein Endgerät neu starten. In diesem Fall ‚vergisst‘ der NAT-Router offenbar zu schnell, dass das Endgerät mit outbox Kontakt hatte und würde bei einem ankommenden Anruf keine Pakete mehr zum Endgerät durchreichen. Nach einem Neustart des Gerätes (nach einer Registrierung) oder aber nach einem abgehenden Anruf trägt der Router die Kommunikation in seine interne Liste ein und würde in den folgenden Minuten auch ankommende Anrufe verstehen.

• Beim Betrieb mehrerer SIP-Endgeräte stören diese sich gegenseitig. Insbesondere abgehende Gespräche oder Neustarts führen dazu, dass andere Geräte danach nicht mehr erreichbar sind. In diesem Fall arbeitet die NAT-Unterstützung des einen Endgerätes so gut, dass der Router z.B. nach so vielen KeepAlive- o.ä. Paketen nachher nicht mehr anders kann, als die SIP-Rückmeldungen etc. an das Endgerät zu leiten (und damit wird das vorher angemeldete Endgerät vom Router regelrecht vergessen).

Nachfolgend möchten wir Ihnen folgende Vorschläge zur Abhilfe machen:

• PortForwarding: Man leitet einfach alle relevanten Ports um. Mindestens ist das der Port 5060 (Signalisierung), welche Ports man für den RTP-Stream nimmt, ist egal, solange man im Endgerät konfiguriert, dass auch nur diese Ports verwendet werden. Seitens outbox kann RTP auf allen Ports >10.000 und <60.000 übertragen werden. Da das Problem aber die Übertragung outbox -& gt; NAT-Router -& gt; Endgerät ist, genügt beim PortForwarding die Freigabe der Ports, die seitens des Endgerätes in Frage kommen. Selbst mehrere Endgeräte sind theoretisch so möglich, solange man sich die RTP-Ports natürlich nicht überschneiden und solange man auf dem zweiten Endgerät die SIP-Signalisierung auf Port 5061, auf dem dritten auf Port 5062 konfiguriert etc. Zusätzlich muss man dem Endgerät noch seine öffentliche IP-Adresse mitteilen (was bei dynamischen IPs natürlich schwierig wird) oder sich darauf verlassen, dass das Problem anders (beispielsweise durch die Nutzung des STUN-Servers) gelöst wird.
• DMZ (demilitarized zone): Man konfiguriert die IP des Endgerätes im Router als DMZ-Ziel.
• STUN (simple traversal of UDP over NAT): Man konfiguriert im Endgerät einen STUN-Server (stun.siplogin.de, Port 3478). Mit dessen Hilfe kann das Endgerät verschiedene Tests machen und so die öffentliche IP-Adresse und den zum Einsatz kommenden NAT-Typen. Mit dieser Information kann das Endgerät nun durch KeepAlive-Pakete dem Router beim Pflegen seiner „wer-mit-wem-Liste“ helfen und so die Trefferquote erhöhen, mit der der Router eingehende Pakete an das Endgerät weiterleitet.
• Application Helper Module seitens des NAT-Routers: Neuere hochwertige NAT-Router unterstützen evtl. SIP und haben vom Hersteller schon fertige Konfigurationsblöcke, die das NAT-Handling für SIP erleichtern (bei falscher Konfiguration aber auch erschweren!). Halbwegs in diese Kategorie fallen auch NAT-Router mit eingebauter VoIP-Funktionalität (z.B. die FritzBox Fon), bei denen der NAT-Router auf das eigene SIP-System entsprechend optimiert ist und wo es deutlich schwerer ist, dahinter noch ein anderes SIP-Endgerät zu betreiben.
• Konfigurations-Finetuning: Unabhängig von den o.g. Maßnahmen kann man alles durch Detail-Einstellungen natürlich optimieren oder verschlechtern. Z.B. kann man die KeepAlive-Frequenz am Endgerät erhöhen oder das Registrar-Interval kleiner drehen (nicht zu klein, das würden die outbox-Systeme nicht akzeptieren), damit mehr Pakete durch den NAT-Router geleitet werden (und er damit seine „wer-mit-wem-Liste“-Liste nicht so schnell vergisst und mehr Ports offenhält). Finetuning setzt aber gutes Wissen über NAT-Techniken generell, SIP sowie das Endgerät und den Router voraus.

Weitergehende Abhilfe:
Um NAT-Probleme in den Griff zu bekommen gibt es leider keine Musterlösung. Es können daher nur zusätzlich folgende Maßnahmen ausprobiert werden:

• Rückbau auf das Wesentliche, dann Schritt für Schritt erweitern: Wer zehn Softphones auf fünf verschiedenen PCs hinter einem NAT-Router betreibt, sollte ggf. Schritt für Schritt gucken, dass er die Geräte einzeln ans Laufen bekommt und dann nach und nach ein weiteres Endgerät hinzunehmen.
• STUN-Server ein- oder austragen. Manchmal hilft das Eintragen des STUN-Servers schon, manchmal aber sind die Ergebnisse aber auch besser, wenn man STUN deaktiviert.
• Endgeräte wechseln. Insbesondere Softphones kann man ja sehr einfach austauschen, und die Erfahrung zeigt, dass z.B. Ninja (X-Lite-Nachfolger), Phoner oder Twinkle völlig unterschiedliche NAT-Implementierungen haben (ein Wechsel von Ninja auf Phoner oder umgekehrt hat schon mehreren Kunden geholfen).
• Den NAT-Router wechseln

Sollten alle oben genannten Maßnahmen zu keinem positivem Ergebnis führen, wäre die Zuweisung einer festen IP nötig – dies schließt NAT-Probleme aus. Bitte haben Sie Verständnis, dass wir Ihnen in diesem Fall unsererseits keinen Support anbieten können. Bitte entnehmen Sie die relevanten Informationen dem Handbuch des Routers oder konsultieren Sie den Hersteller.