Zurück zu Laptopbau

VoIP - Verbuggt und instabil

Warum Sie Ihren alten DSL 16.000er Vertrag mit Splitter bis zum Schluss laufen lassen sollten

In diesem Artikel erkläre ich das Prinzip von VoIP, VDSL und warum damit viele Probleme verknüpft sind, die einem die Mitarbeiter der Telekom am Telefon nicht erklären. Alles begann damit, dass bei uns in Reinheim DSL 16.000 lange die schnellste Option für Internet war und wirkliche Fortschritte nicht abzusehen waren. Es sei gesagt, dass DSL 16.000 bedeutet, dass die maximale Datenübertragung beim Downstream 16.000Kb/s, also 15,625Mib/s oder 1,953MB/s beträgt. Das gilt jedoch nicht für den Upstream. Dieser beträgt maximal 1Mb/s, in der Praxis etwa 800Kb/s, also 0,0976MB/s. Das Hochladen von 1GB, also etwa der Datenmenge, die bei einem Austausch von Fotos von letztem Jahr anfällt, dauert demnach fast 3 Stunden. DSL 16.000 sollte also eigentlich DSL 800 heißen.

Ein Grund für die schlechte Geschwindigkeit ist das Absplitten des Telefons. Da dieses bei DSL 16.000 komplett vom Internet getrennt ist, wird eine Menge zusätzlicher Hardware benötigt. Außerdem kann die für Telefon benötigte Bandbreite nicht für Internet genutzt werden (auch, wenn man nicht telefoniert) und umgekehrt. Bei einer Vereinheitlichung von Telefon und Internet kann die Bandbreite effizienter genutzt werden und auf den Splitter, der natürlich auch eine gewisse Verschlechterung des Signals verursacht, kann verzichtet werden. Stattdessen benötigt wird allerdings ein Standard (SIP), der die Nutzung von Telefondiensten über das Internet ermöglicht. Statt der alten ISDN-Anlage werden nun IP-Telefone oder ATA-Adaper benötigt (Das sind im Prinzip auch IP-Telefone, die ein gewöhnliches Analogtelefon als Hörer benutzen).

Konfiguration

Die folgende Abbildung zeigt unsere Konfiguration mit DSL 16.000 und VDSL 25.000:

Das NAT durchdringen

Wie man sieht, hängt bei VDSL das Telefon hinter dem Router. Das gesprochene Wort wird also digital kodiert, in einzelne Pakete zerlegt und über das Ethernet gesendet. Damit die Pakete ankommen, wird neben der Telefonnummer auch eine IP benötigt. Im Prinzip ist es also möglich, IP-Adressen statt Telefonnummern anzurufen. Jedoch besitzt nicht jedes Telefon am Ende eine IP-Adresse, die über das Internet erreichbar ist. In der Regel besitzt nur der Router eine globale IP-Adresse, die Telefone, bzw. der ATA-Adapter nur eine Lokale. Die Weiterleitung von Paketen aus dem lokalen Adressbereich in den Globalen heißt Network Adress Translation (NAT). Damit nun eingehende Pakete, die an die Adresse des Routers gesendet werden, den Weg zum richtigen Telefon finden, gibt es folgende Möglichkeiten:

Anschlussrestriktionen der Telekom

Trotz des von mir verwendeten Port-Forwardings ist das Thema PPPoE damit nicht vom Tisch: Die Telekom erlaubt nur SIP-Verbindungen von IP-Adressen aus dem eigenen Netz. http://www.netzwelt.de/news/70805-voip-anbieter-vergleich.html, 2015.06.19 http://www.ip-phone-forum.de/showthread.php?t=277009&page=2&p=2098074&viewfull=1#post2098074, 2015.06.20 Wir hatten noch PPPoE-Daten von einem alten AOL-Vertrag, der außer diesen Daten nichts bringt, aber mit nur 4€/Monat auch nicht ins Gewicht fällt. Wir haben diese Daten verwendet, zum einen, weil es bei der Telekom nicht ganz einfach ist, seine eigenen PPPoE-Daten herauszufinden http://avm.de/nc/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/534_T-Online-als-anderer-Internetanbieter-einrichten/, 2015.06.19 und zum anderen, weil es mit dem alten DSL 16.000 und den Telekom-Daten immer zu Internetaussetzern kam, wohingegen mit den AOL-Daten alles problemlos lief. An dieser Stelle ist zu erwähnen, dass mein ATA kaum hilfreiche Fehlermeldungen zeigt. Man sieht erst mal nur, ob man online ist und die Nummern registriert sind, für alles Weitere kann man einen Syslog-Server einstellen, aber da kommen dann so viele Meldungen rein, dass man ewig nach einem möglichen Fehler suchen muss und hat man ihn gefunden, und googelt danach, findet man trotzdem nichts hilfreiches... Die Syslog Meldungen sind eben nur für genau diese Hardware gültig.
Nachdem ich also per try-and-fail dahintergekommen bin, dass man die Telekom-Daten auch im Router eingeben muss, konnte sich der Adapter endlich verbinden. Da ich die notwendige Hardware schon lange vor der Umstellung auf VDSL gekauft und mich eingearbeitet hatte, konnte ich sofort nach der Umstellung wieder online gehen. Was das Internet betrifft, so ist bei VDSL nur zu beachten, dass ein providerspeziefisches VLAN-Tag gesetzt werden muss.http://www.onlinekosten.de/forum/showthread.php?t=133352, 2015.07.27 In meinem Fall übernimmt das der Vigor 130, den ich als Modem betreibe. Den ATA-Adapter hatte ich dann bis zum Abend auch online. Aber jetzt fingen die Probleme erst an:

VoIP läuft nach der Umstellung nur langsam an

Zunächst konnte ich mit den Telefonen nur raus telefonieren, beim Versuch, mich selbst vom Handy aus anzurufen hieß es "Der gewünschte Gesprächspartner ist vorübergehend nicht zu erreichen!". Laut dem Anruf eines Telekom-Mitarbeiters (Der seine Nummer leider nicht hinterlassen hat) muss man für die vollständige Umstellung auf VoIP erst mal einige Minuten lang 'raus telefonieren. Aber ganz so leicht ist es doch nicht. Ich habe alles mögliche Versucht, auch nach stundenlanger Arbeit konnte ich mich selbst nicht anrufen. Irgendwann habe ich entnervt aufgegeben, ein paar Stunden später habe ich noch mal gewählt, und das Telefon klingelte (Ohne, dass ich in Zwischenzeit irgend etwas verändert hätte). Jedoch war es nicht möglich abzuheben, am Handy wurde aufgelegt, am Telefon war ein Besetzt-Signal zu hören. Ich habe dem ganzen einen weiteren Tag gegeben, ohne etwas zu verändern, dann habe ich es plötzlich geschafft, abzuheben. Jedoch nur sehr selten, bei einem von 20 Versuchen. Bei Fehlversuchen klingelte das Telefon nach dem Auflegen dann immer erneut, wieder ein Besetztsignal beim Abheben und das 3 Mal.

Die Ringtone Einstellungen

Die Telekom hat schon im Voraus klar gemacht hat, dass sie absolut gar keine Unterstützung für meine Hardware anbietet (Der Support beschränkt sich auf 3 1/2 Fritzboxen und Speedportrouter und dabei dann hauptsächlich auf Fernwartung). Ich musste das also mal wieder selber anpacken. Das Problem hier: Der ATA-Adapter bietet neben der Konfiguration für Logindaten noch weitere Reiter für Advances Settings und Profile Settings. Hinter jedem verbirgt sich eine viele, viele Bildschirmseiten lange Konfiguration mit rätselhaften Einstellungen, wie Disable Bellcore Style 3-Way Conference, Generate Continuous RFC2833 Events oder Allow DHCP option 42 to override NTP server. Zu den meisten Einstellungen findet man nur sehr spärliche Informationen; was aber unbedingt angepasst werden sollte, sind die Call Progress Tones. Das sind die Frequenzen und Intervalle der Töne, die man am Telefon so hört, also Freizeichen, Besetztzeichen, usw. In Deutschland sollte hier folgendes eingestellt werden http://www.adatis.com/files/infothek_kompatibilitaet_grandstream_gxw_4104.pdf?PHPSESSID=cc67930168a1e2ad1d59f2e17563914f, 2015.06.19:

Dial Tonef1=425@-10,c=0/0;
Ringback Tonef1=425@-12,c=1000/4000;
Busy Tonef1=425@-12,c=480/480;
Reorder Tonef1=425@-12,c=220/220;
Confirmation Tonef1=425@-12,c=0/0; (In Deutschland nicht verwendet)
Call Waiting Tonef1=425@-10,c=240/240-240/500-0/0;
Prompt Tonef1=425@-12,c=0/0;

Probleme beim Abheben

Mit diesen Einstellungen hatte das rätselhafte, erneute Klingeln nach dem Abheben ein Ende. Das Abheben selber funktionierte aber weiterhin nicht immer. Ich konnte beobachten, dass dieses Problem in einem Zeitraum von 2 Wochen langsam seltener wurde, aber nie ganz verschwunden ist. Also habe ich einen Syslog-Server eingerichtet, um Fehlermeldungen des ATAs abzufangen. Dies hat folgendes LOG ausgespuckt:

Also nachdem der HT704 gestartet ist, kommen laufend LOG-Messages rein, etwa solche, wie SIPStack(0)::run: Active transactions: 1 Insbesondere diese Meldung kommt ständig rein. Dann nehme ich das Handy und wähle unsere Nummer. Folgende Messages erscheinen: ------------------------------------------- SIPStack(2)::cb_rcvreq: Received SIP request INVITE SDP::create: failed to parse SDP SIPStack(2)::run: Active call dialogs: 1 SIPStack(2)::run: Active call dialogs: 1 Nuvoton::startRing with CID, Attemping to deliver CID 4915205976262; cpc=ordinary, on port 2 SIPStack(2)::run: Active call dialogs: 1 ------------------------------------------- - es klingelt - Dann hebe ich ab. Folgende Messages erscheinen: ------------------------------------------- ATACtrl::processPhoneOffHook on port 2:0, status = CALL_RINGING/CALL_IDLE, reg'd:1, allow calls w/o reg:0 ,sigReferred:0 Call(7)::Call, Creating Call object 7 at port 2:0, caller 0 RTP::Qos: Layer 3 DSCP for RTP set to 46 RTP::Qos: Layer 3 DSCP for RTCP set to 46 SIPStack(2)::run: Active call dialogs: 1 ------------------------------------------- Nach weniger als einer Sekunde erscheinen ausserdem folgende Messages: ------------------------------------------- SIPStack(2)::run: Active call dialogs: 1 RTP::setSDP on port 2:0. current sdp: (nil), new sdp: (nil) RTP ssRC/SEQ inited on port 2 ch 0 Call(7)::processMedia, Call started on port 2:0:5012, status=CALL_COMMUNICATION,canSend=0,canRecv=0,disa ble2833--1,dtmf: // ab hier war das Bild abgeschnitten GSDSP::stop RTP on port 2:0 GSDSP::RTP stopped on port 2:0 GSDSP::startRTP, Failes to start RTP at port 2:0 due to null pointer SIPStack(2)::cb_rcvreq: Received SIP request BYE SIGCtrl::processCallCompleted on port 2:0, status = CALL_ENDING/CALL_IDLE ATACtrl::processCallCompleted on port 2:0, status = CALL_IDLE/CALL_IDLE canConf:0 ,sigReferred:0 SIPStack(2)::run: Active call dialogs: 1 SIPStack(2)::run: Active call dialogs: 1 GSDSP::stop RTP on port 2:0 GSDSP::RTP stopped on port 2:0 RTP stop on port 2:0 local rtp port:5012 sdp:(nil) Call(7)::processMedia, Call stopped on port 2:0, inTransfer = 0 Call(7)::~Call, Deleting Call object 7 at port 2:0, callCount=0 ------------------------------------------- - Am Telefon ist ein Besetzt-Signal zu hören, am Handy wird der Anruf als beendet angezeigt - Nach einigen Sekunden lege ich am Telefon auf. Folgende Meldungen erscheinen: ------------------------------------------- ATACtrl::processPhoneOnHook on port 2:0, status = CALL_IDLE/CALL_IDLE ,sigReferred:0 SIPStack(0)::run: Active transactions: 1 -------------------------------------------

Die Meldung GSDSP::startRTP, Failes to start RTP at port 2:0 due to null pointer sieht stark nach einer möglichen Ursache aus. Ich konnte leider kein Log von einem funktionierenden Anruf erstellen, da die Testlizenz für den Syslog-Server indes abgelaufen war. Ich habe mit diesem Log den Support von Grandstream (Also dem Hersteller des ATAs) kontaktiert, die hatten Ad-Hoc keine Lösung und wollten ein vollständiges Whireshark-Trace. Im Forum habe ich 20€ für eine Lösung geboten, aber niemand weiß Rat.

Geisteranrufe

Neben dem Abhebeproblem hat sich außerdem ein anderes Phänomen etabliert: Manchmal klingelt das Telefon (meistens das mit unserer ersten Nummer, die, die Telekom immer auf der Telefonrechnung aufführt) Sturm, in kurzen Intervallen. Diese sind durch keine der Ring Tone-Einstellungen des ATAs beeinflussbar. Es wird keine Nummer angezeigt, hebt man ab, ist niemand dran, legt man auf, klingelt es weiter. Es hilft eigentlich nur, den Stecker zu ziehen und ein paar Stunden zu warten. Meine Eltern haben ihre Telefone mit Zeitschaltuhren versehen, um nicht nachts wachgeklingelt zu werden. Neben diesem komischen Strumklingeln gab es auch Anrufe von nicht existierenden Nummern, wie 1000000000 oder 00000000000. Niemand war dran.

Der Support von Grandstream konnte an dieser Stelle eine Lösung bieten: Im ATA mussten unter Profile-Einstellungen folgende Radio-Buttons auf YES gesetzt werden: Check SIP User ID for incoming INVITE und Allow Incoming SIP Messages from SIP Proxy Only. Damit wird dann gleich einer der Vorteile von VoIP zunichte gemacht, nämlich dass man statt einer Telefonnummer auch eine IP-Adresse anrufen kann. So ist man wieder auf den SIP-Provider angewiesen, woher die Geisteranrufe nun kamen konnte ich nicht herausfinden. Nachdem ich später zu DUSnet als SIP-Provider gewechselt hatte, gab es zunächst keine Geisteranrufe, erst nach ein paar Wochen fing es wieder an, bis ich die genannten Einstellungen gesetzt habe.

Telekom verweigert MSN-Portierung

Das Abheben funktionierte weiterhin nicht zuverlässig. Ich dachte mir also: Bevor ich jetzt andere Hardwarekonfigurationen versuche, teste ich mal einen anderen VoIP-Anbieter. Bei Sipgate kann man sich kostenlos anmelden und bekommt eine Ortsrufnummer zum ausprobieren und was noch viel besser ist: Eine genaue Konfigurationsanleitung für den HT 701, die direkt auf den 704 übertragbar ist. Und es lief sofort ohne Probleme. Die gleiche Konfiguration hat bei der Telekom ebenfalls nicht geholfen. Nach all dem Stress wollte ich natürlich sofort unsere Nummern umziehen und die Sache abschließen. Die Telekom schreibt auf Anfrage hierzu: "Eine Portierung Ihrer MSN Rufnummern zu Sipgate ist nicht möglich". Zwar kann ich bei Sipgate die Portierung in Auftrag geben, aber das würde - warum auch immer - den kompletten Vertrag kündigen, samt Internet. Und hier greift jetzt wieder das Hauptproblem bei VoIP: Ohne Internet geht nix! Trotzdem müssten wir natürlich den Telekom-Vertrag bis zum Ende der Mindestvertragslaufzeit weiter bezahlen. Die Versuchung hier einfach mal die Einzugsermächtigung zu streichen ist natürlich groß...

Kein DSL ohne Festnetzflat

Allerdings stellt sich die Frage, wo stattdessen Internet beziehen. Unglücklicher Weise gibt es scheinbar keinen Anbieter, der VDSL 25.000 OHNE Telefon verkauft. Wir würden also eine nicht nutzbare Festnetzflat draufzahlen, für nichts. Eine Möglichkeit wäre noch, ein Coax-Kabel legen zu lassen, Unitymedia bietet einen Internetvertrag ohne Telefon, der mit 30€ um 6-9€ günstiger ist, als Verträge mit Telefonflat.https://www.unitymedia.de/privatkunden/internet/basis-internetzugang/, 2015.07.27 Jedoch kostet die Verlegung eines neuen Kabels um die 1000€, wenn man eine 1-Jahres-Kündigungsfrist akzeptiert, bezahlt Unitymedia davon gut die Hälfte, was bedeutet, dass sich das nach etwa 4 Jahren lohnen würde. Aber wer kann schon soweit in die Zukunft sehen? Wenn es bis dahin Glasfaser bei uns gibt, wäre die Kabellegung ein Reinfall und jetzt schon für die Zukunft ein Paar Glasfasern mitverlegen zu lassen ist äußerst schwer durchzusetzen.
Für's erste belassen wir also das Internet bei der Telekom und ich habe zwei Nummern bei DUSnet geholt, das ist zwar etwas teuer, als Sipgate, bietet aber 5 Rufnummern in einem Vertrag an (Bei Sipgate geht in den Starter-Tarifen erst mal nur eine). Dann haben wir die beiden wichtigsten Telekom-Nummern auf die Dusnet-Nummern weitergeleitet und es läuft.

Verschlüsselte Telefonie

Auch mit DUSnet konnte man sofort anrufen und angerufen werden. Ich habe innerhalb von mehreren Monaten 2 Mal erlebt, dass beim abheben aufgelegt wurde. Das ist so selten, dass ich es für denkbar halte, dass tatsächlich der Anrufer im gleichen Moment aufgelegt hat. Eine andere Theorie, woher das Abhebeproblem kommt, ist folgende:

Standardgemäß wird das SIP-Protokoll über UDP abgewickelt. Bei UDP ist es möglich, dass einzelne Pakete auf dem Weg verloren gehen. Wie man den Whireshark-Traces oder Syslog-Meldungen entnehmen kann, werden beim Abheben eine ganze Reihe von Befehlen hin und her geschickt, wenn davon welche verloren gehen, erklärt dies vielleicht den Fehler. Im Gegensatz zur Telekom bietet DUSnet die Möglichkeit, das SIP-Protokoll über TLS abzuwickeln. TLS basiert auf TCP und ist außerdem verschlüsselt. Eine solche Verschlüsselung sollte eigentlich die Mindestanforderung für VoIP sein, da nun nicht mehr nur Provider und Geheimdienste die Telefonate mithören und aufzeichnen können, sondern im Prinzip jeder, der es (z.B. durch Spyware oder Sicherheitslücken im Router) schafft, die UDP-Pakete abzufangen. Trotzdem ist eine Verschlüsselung nicht leicht einzurichten, wie sich im Folgenden zeigen wird. Wie bereits erwähnt, dient SIP nur zum Verbindungsaufbau, das eigentliche Telefongespräch wird über RTP abgewickelt. Auch mit TLS ist der RTP-Transport noch unverschlüsselt. TLS verschlüsselt auch nur bis zum Provider, welcher demnach weiterhin die Verbindungsdaten speichern kann (Was ja auch nicht unsinnvoll ist). Für RTP währe eine Verschlüsselung zwischen den Endteilnehmern zweckmäßig.
Dafür gibt es bereits das SRTP-Protokoll. Dieses regelt nach allem, was ich weis, aber nicht den Schlüsselaustausch. Genau hier wird es wieder kompliziert. Zwar gibt es Erweiterungen, wie ZRTP, die direkt über die RTP-Ports einen Diffie-Hellman-Schlüsselaustausch zwischen den Endteilnehmern durchführen, jedoch ist ZRTP noch kaum verbreitet.https://de.wikipedia.org/wiki/ZRTP, 2015.07.27 DUSnet und der HT704 bieten zwar prinzipiell SRTP-Unterstützung, laut DUSnet wird diese erzwungen, wenn man über den Server secure.dus.net verbindet.

Portmapping durch den Router

Zuerst habe ich die Aktivierung von TLS in Angriff genommen. Jedoch hat dies erneut zu Problemen geführt: Der ATA-Adapter ging dadurch immer wieder offline. DUSnet zeigt löblicher Weise die Ports, von denen aus sich die Endgeräte verbinden, im Kundencenter an, wodurch ich dieses Problems Ursache recht schnell entdeckt habe:
Bei Verwendung von TCP oder TLS stimmen die manuell im ATA konfigurierten Ports nicht mit denen, die DUSnet anzeigt, überein. Nach diversen Whireshark-Traces und Supportanfragen bei Grandstream sieht es wohl so aus, als würde der Router trotz Port Forwardings ausgehende Pakete dieser Ports bei Verwendung von TCP über das NAT mit seinem Port Mapping leiten. Die Verwendung von Keep Alive konnte das Problem des Offline-Gehens nicht vollständig beheben. Der Cisco RV042G ist sowieso nicht wirklich gut, es fehlen wichtige Techniken, wie VLAN-Tagging oder IKEv2. Nach allem, was ich weiß, bieten DrayTek-Router unter dem Schlüsselwort Port Redirection eine solchge Möglichkeit, auch das Port Mapping der ausgehenden Pakete zu konfigurieren, anderes Stichwort ist hier statisches NAT. Der RV042G bietet noch die Möglichkeit des Port Triggerings, hierbei kann man festlegen, dass bestimmte Ports der WAN-Seite auf bestimmte Ports der LAN-Seite gemappt werden, aber eben wieder nicht umgekehrt.
Für den reibungslosen und sicheren Betrieb von VoIP wird wohl der Kauf eines umfangreicheren und teureren Routers mit Unterstützung von statischem NAT von Nöten sein.

Bugs im ATA-Adapter

Neben diesem Problem des Offline-Gehens brechen Anrufe auch manchmal einfach so ab. Das liegt, wie es aussieht, aber am ATA-Adapter. Insbesondere, wenn dieser mehrere Telefonate gleichzietig schaffen soll und man zusätzlich das Webinterface benutzt hat, hängt er sich auf. Dabei bricht die Verbindung einfach ab, im Webinterface wird angezeigt, dass der Anruf noch laufen würde, auch wenn längst aufgelegt wurde. Selbst der Reboot über die Weboberfläche geht dann nicht mehr immer.
Der ATA-Adapter kommt wohl besser mit dem NAT klar, wenn die Option use random port gesetzt ist, dazu noch STUN verwenden. Zusätzlich starte ich den Adapter jetzt immer zusammen mit einer Zeitschaltuhr am Modem für die IP-Erneuerung neu, so sind wir ... naja ... meistens jedenfalls erreichbar und bekommen täglich eine frische IP. Bis ein besserer Router angeschafft ist, ist das OK.

Eine echte Alternative zu diesem Adapter giebt es derzeit wohl nicht - andere VoIP-Stationen kosten 500€ und mehr und sind für Unternehmen oder Hotels ausgelegt, für unsere Zwecke aber einfach nicht das Richtige. Alternativ könnten wir alle 4 Telefone durch IP-Telefone ersetzen, das sind dann aber auch mindestens 4 x 70€. Ich hoffe, Grandstream bringt irgend wann eine stabilere Firmenware.

Bei ausgehenden Gesprächen wird jetzt die neue Nummer von Dusnet angezeigt. Dusnet bietet zwar an, eine andere, ausgehende Nummer zu senden, aber das funktioniert nicht. Unsere alten Nummern werden von der Telekom gefangen gehalten.

Andere Hardware aber trotzdem Probleme

Schließlich habe ich noch ein Gigaset PRO DE310 VoIP-Telefon versucht. Generell ist dazu zu sagen, dass IP-Telefone ein wesentlich schlechteres Preis/Leistungsverhältnis bieten, als Analog-Telefone. Jedenfalls konnte sich das Gigaset wieder problemlos mit Sipgate verbinden, bei der Telekom sind ausgehende Gespräche nach wenigen Sekunden abgebrochen, manchmal erhielt man auch nur ein Besetzt-Signal. Deswegen und wegen mangelndem Anrufbeantworter und einem nicht-abschaltbaren Display-Backlight habe ich das Gigaset-Telefon wieder zurückgeschickt und drei weitere Nummern bei Dusnet bestellt. Wir haben jetzt alle Telekom-Nummern weitergeleitet und ich verwende inzwischen offiziell die DUSnet-Nummer. Im letzten Monat ist ein mal der ATA-Adapter abgestürtzt, ansonsten sind wir über DUSnet wieder recht zuverlässig erreichbar.
Was die Telekom betrifft, haben wir von einem Mitarbeiter erfahren, dass wenn mehrere Nummern im Haushalt verwendet werden, aber nicht alle mit einem Telefon verbunden sind, ein Protokoll starte, das versucht, die nicht-belegten Nummern einem Telefon zuzuordnen... Klingt für mich ziemlich abstrus, aber falls das stimmt, wäre das eine Erklärung für einige unserer Probleme. Wie auch immer, was wir bei DUSnet im Moment draufzahlen sollte eigentlich beim Internetzugang gespart werden können, aber die Provider stellen sich halt quer.

Fazit:

Ich konnte bislang jede an VoIP beteiligte Instranz für mindestens ein Problem verantwortlich machen: Probleme beim Abheben aufgrund des Providers, nicht-konfigurierbares NAT am Router und Abstürze bei hoher Auslastung wegen Bugs in der ATA-Firmenware. Dazu kommen diverse andere Probleme, deren Ursache ich nicht immer ermitteln konnte.
Die Umstellung auf VoIP ist offensichtlich nur bei Unternehmen zu empfehlen, die das auch als Kerngeschäft betreiben. Allerdings fallen dann zusätzliche Kosten an, da man mit dem Internet immer eine sinnlose Festnetzflat mitbezahlt. Die Vorteile von VoIP, wie Videotelefonate oder verschlüsselte Verbindungen sind in der Praxis kaum nutzbar. Wir hatten bisher nur Nachteile, der einzige Grund, überhaupt umzusteigen war die höhere Internetgeschwindigkeit (insbesondere beim Upstream) und die Tatsache, dass bis 2018 sowieso jeder umsteigen muss.http://www.teltarif.de/forum/x-festnetz/telekom-droht-mit-abschaltung-t-dsl/3864.html, 2015.06.19 Während das gute, alte Festnetz über Notstromaggregate verfügt, führt jetzt ein Stromausfall immer auch zu Internetausfall und somit zu Telefonausfall.http://www.faz.net/aktuell/technik-motor/computer-internet/deutsche-telekom-stellt-auf-ip-telefonie-statt-festnetz-um-13688149-p3.html?printPagedArticle=true#pageIndex_3, 2015.07.16 Dass die Provider alle auf VoIP wechseln, liegt meiner Meinung nach ausschließlich an dem Bestreben, Kosten zu senken. Für die meisten Kunden ist die einzige Chance, das zum laufen zu bringen, der Zwangsrouter. Was die Konzerne politisch nicht durchsetzen können, wird eben über Technologiehindernisse erzwungen.