[INFO] Das A und O bei VoIP ist der Router

Viele mit VoIP (genauer: dem SIP-Protokoll) neu in Berührung kommenden ärgern sich über Fehler und Probleme wie

• einseitige oder auch gar keine Kommunikation,
• kein Klingeln am Telefon,
• Abbruch nach 1 oder 2 Minuten,
• Meldungen für den Anrufer der VoIP-Rufnummer wie "die gewählte Rufnummer ist nicht vergeben"
• Dauerbesetzt für den Anrufer der VoIP-Rufnummer obwohl die Leitung an sich frei ist,
• mit dem einen Provider funktioniert es, mit dem anderen nicht,
• Probleme beim Anschluss mehrere VoIP-Clients (es klingeln z.B. nur einzelne Clients),
• Zurückweisung der Anmeldung am Server des Providers wegen einer privaten IP-Adresse usw.

Diese Probleme treten zudem verstärkt auf, wenn mehrere SIP-Clients über die LAN-Anschlüsse an das Netzwerk angebunden werden.

Problemursache

In sehr vielen Fällen ist hieran der Router bzw. die darin eingebaute Firewall Schuld. Wer mehr zu der NAT-Problematik nachlesen will findet hier einige grundlegenden Informationen:
http://www.intertex.se/index2.asp?iMenuID=320&iItemID=264
http://www.intertex.se/index2.asp?iMenuID=345&iItemID=289
bzw. auf deutsch unter:
http://www.florianmessner.com/support/themen/voip/firewall-nat-wlan/voip-nat-1.htm

Dass es mit einem Provider geht, mit dem anderen aber nicht oder nicht richtig, heißt übrigens nicht, dass die eigentliche Ursache des Problems nicht doch am Router liegt, denn die Provider setzen unterschiedliche (oder eben auch gar keine) Hilfsmittel ein, um die NAT-Problematik in den Griff zu bekommen.

Wichtig: Nicht jeder Router, der irgendetwas mit VoIP zu tun hat (z. B. einen ATA integriert hat), ist gleichzeitig auch "sip-aware" wie die Beispiele der Fritz!Box Fon oder auch der Netgear TA612V zeigen (die haben nämlich keinen SIP Proxy und Registrar Server eingebaut!). Dort funktioniert es nur so, dass die Daten für das direkt am FXS-Port angeschlossene analoge Telefon VOR dem Netzwerkkontakt bearbeitet werden, Firewalleinstellungen und Netzwerkverkehr haben somit keine Auswirkungen auf Telefongespräche. Schließt man aber einen SIP-Client (VoIP-Softwareclient oder VoIP-Telefon/Adapter) an einen LAN-Anschluss des Routers an oder wird diese hinter einem anderen Router eingesetzt, wird der Datenverkehr zu diesen Clients von der Firewall bzw. dem Netzwerkverkehr (ggf. des anderen Routers) sehr wohl beeinträchtigt

Wie kann man herausfinden, ob der eigene Router die Ursache des Problems ist?

Ob der eigene Router einschließlich der darin enthaltenen Firewall unabhängig vom Provider und unabhängig evtl. eingesetzter Hilfsmittel (STUN, RTP Proxies, uPnP, ICE) "sip-aware" (d. h. letztlich integrierter SIP Registrar und Proxy Server und SIP transparente Firewall) ist, kann man ganz gut mit dem SNOM Softphone in einer Version 3.6 (bei der Version 5.0 könnte es sein, dass SNOM selbst Funktionen implementiert hat, die die Herausgabe der privaten IP-Adresse verhindern)
http://www.ip-phone-forum.de/forum/viewtopic.php?t=12217
herausfinden, welches man auf dem PC installiert und dann den Anbieter blueSIP (die setzen keine freien RTP Proxies ein, was der Sprachqualität dient) heranzieht. Findet sich im Log des Softphones (nach Eingabe der Providerdaten, dabei ICE auf aus; KEINEN STUN-Server) die Zeile "Please don´t use private IP addresses" bzw. "[...] refused with code 479" dann bedeutet dies, dass der Router/Firewall zumindest mit den Standardeinstellungen nicht (uneingeschränkt) für VoIP (SIP) geeignet ist bzw. auf die oben genannten Hilfsmittel (die mal mehr, mal weniger reibungslos funktionieren und z. T. sicherheitskritisch sind) zwingend angewiesen ist. Z. B. wird die Anmeldung von einem SNOM 360 angeschlossen am LAN-Anschluss der Fritz!Box Fon mit einer 479-Fehlermeldung vom blueSIP-Server abgewiesen.

Was kann ich machen, wenn mein Router nicht sip-aware ist?

Ist der Router nicht "sip aware" , ist es der einfachste und oft am wenigsten nervenaufreibendste Weg, sich einen entsprechenden Router zu kaufen. Die Empfehlung lautet hier derzeit für den SOHO Bereich eindeutig:
Intertex IX66 / IX67 / IX68 (Nachteil: teuer),
Siemens (Efficient Networks) Business Routers (etwa die Modelle 5851, 5950) ab der Firmware 6.1.x
oder aber auch
Linksys WRT54G/GS jedoch nur mit Firmware "SIPatH / Milkfish" oder DD-WRT in der VoIP-Version >= v.23 (scheint aber noch nicht immer 100 %ig perfekt zu funktionieren und ist mit etwas mehr Konfigurationsaufwand verbunden, dafür aber deutlich billiger als der IX66 / IX67)
Vgl. dazu http://www.ip-phone-forum.de/forum/viewtopic.php?t=22112

Auf professioneller Ebene sind es dann geräte wie SIPassure von Borderware
http://www.borderware.com/products/sipassure/sip_traffic_management.php

Will bzw. kann man das aus finanziellen / technischen Gründen nicht, so kann man versuchen, mittels STUN-Server und Portweiterleitungen am Router das Problem in den Griff zu bekommen (wobei ich aus meiner Erfahrung sagen kann, dass dies z. T. viel Zeit verschlingt und in vielen Fällen (gerade wenn mehrere VoIP-Clients angeschlossen werden sollen) oft dann doch nicht reibungslos funktioniert und damit viel Frust aufkommt).

Mein Rat lautet daher: Besorgt euch einen geeigneten ("sip-aware") Router und schaltet dann am VoIP-Endgerät sämtliche Punkte wie STUN, uPnP, ICE etc. ab. Wenn möglich, testet den Router vor dem Kauf mit dem oben angegebenen Testaufbau (SNOM Softphone + blueSIP). Wenn ihr dann im Log keine Fehlermeldung habt wie "Please don´t use private IP addresses" oder "refused with code 479" sollte dem VoIP-Vergnügen (jedenfalls auf eurer Seite) nicht mehr viel im Wege stehen. Fehler oder Störungen auf Anbieterseite können natürlich weiterhin bestehen, aber da hilft dann kein noch so guter Router.


Die Erfahrungen eines VoIP-Endgeräteherstellers

Zu der Problematik auch einmal die durchaus leidvollen Erfahrungen eines VoIP-Endgeräteherstellers:

wir haben mal gesammelt und folgende Antwort zum Thema NAT zusammengestellt:
Einige [VoIP] Betreiber scheinen offenbar das Problem "NAT" noch nicht richtig ernst zu nehmen. Wir versuchen schon seit geraumer Zeit verschiedene Betreiber von der Notwendigkeit eines Session Border Controllers zu überzeugen.

Wie Sie vielleicht wissen, haben wir bei älteren Versionen des Telefons auch aktiv NAT unterstützt (STUN, UPnP). Das hat in der Praxis aber mehr Probleme gebracht als es gelöst hat. Versuchen Sie mal die Soft-Phones mit einem DrayTek Vigor2500 oder auch einer Linux Firewall. Diese Geräte verwenden "symmetrical NAT" und insbesondere der DrayTek unterstützt kein UDP Fragementation. Weitere interessante Ergebnisse unter
http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-02.txt
http://midcom-p2p.sourceforge.net

Die Fakten:

- NAT können wir nicht wegdiskutieren. Es ist realitätsfern wenn manche IETF-Hoheiten empfehlen, doch einfach auf IPv6 umzusteigen (dort wird es übrigens auch Firewalls geben).

- Wenn wir Kunden empfehlen, Änderungen am Router oder am Telefon vorzunehmen, gehen wir im Support unter. Zwei unserer Kollegen (die sich ein bischen mit dem Thema auskennen!) haben mal zwei Tage gebraucht um rauszufinden, dass sie beim Port Forwarding einen Zahlendreher drin hatten. Das wollen wir nicht widerholen, schon gar nicht mit möglicherweise unerfahrenen Kunden.

- Die Hersteller von Routern werden wir nicht erziehen können. UPnP war ein netter Versuch, aber die Implementierungen waren derart buggy, dass auch dieser Ansatz mehr geschadet als geholfen hat. Ganz zu schweigen davon, dass ja bereits einge Geräte im Feld sind, wo symmetrical NAT als Feature angepriesen wird ("Stateful Inspection" etc.).

- Wir werden übrigens auch nicht die anderen Hersteller von Endgeräten überzeugen können. Schauen Sie sich doch mal die Geräte von Cisco & Co an - die unterstützen ebenfalls kein NAT. Microsoft Messenger unterstüzt übrigens auch kein NAT (UPnP wurde in RTC1.2 herausgenommen, da Microsoft offenbar auch keine guten Erfahrungen damit machen konnte!).

- Wir haben teilweise mit Kunden Stunden verbracht und versucht die Telefone in diesen Umgebungen zum Laufen zu bekommen - ohne Erfolg. Eine frustrierende Erfahrung für den Kunden und für uns auch. Solche Erfahrungen treiben die Kunden in die Arme von Skype, die dieses Problem ebenfalls von Anfang an Ernst genommen haben. Könnten Sie sich Skype vorstellen wo die Kunden Port Forwarding machen müssen damit es klappt?

Zum Vergrößern anklicken....

Diskussionen hierzu bitte unter http://www.ip-phone-forum.de/showthread.php?t=91493