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), dennoch gibt es ein Problem:

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. Ich habe schon viele Router bedient und keiner bietet die Möglichkeit, das Portmapping des NATs manuell zu konfigureren (Statisches NAT). Das ist offenbar eine seltene Option sehr hochpreisiger Geräte... Nun sendet also der ATA-Adapter auf Port 5061 ein Paket los, der Router mappt dieses, anders als bei UDP aber auf einen anderen Port (z.B. 19365). Die Motivation dahinter ist, dass ja eventuell mehrere Teilnehmer im LAN den Port 5061 verwenden könnten. Durch das Mapping kann der Router zurückkommende Pakete wieder an den richtigen Teilnehmer senden.
Natürlich wird aber der SIP-Provider nicht auf dem Port 5061 antworten sondern auf dem gemappten Port 19365. Da dieser zufällig gewählt wurde, ist es unmöglich, ein funktionierendes Port Forwarding dieser Pakete auf den ATA-Adapter zu programmieren. Wenn nun erst nach einigen Stunden ein Anruf eingeht und der SIP-Provider ein Paket schickt, hat der Router vergessen, dass Port 19365 dem ATA-Adapter zugeordnet ist. Es bleibt nur die Möglichkeit, den ATA-Adapter kontinuierlich Pakete schicken zu lassen, um den Port offen zu halten (Keep Alive).
Dies hat bei mir aber einfach nicht so zuverlässig funktioniert wie das Forwarding und der Adapter ging weiterhin (wenn auch seltener) offline.

Die Reihenfolge der SPI-Registrierung ist entscheidend

Wie anfangs erwähnt haben wir 4 Telefone. Jedes muss der ATA-Adapter einzeln beim SIP-Proviger registrieren. Ich schreibe diesen Absatz nach über einem Jahr störungsfreien Betriebs über unverschlüsseltes UDP mit Port Forwarding. Urplötzlich und ohne erkennbaren Grund ist das Telefon wieder ausgefallen. Ich habe schließlich die Firmware des ATAs neu geflasht und alles von Null auf neu konfiguriert. Dann ging's wieder. Jedoch habe ich die RJ11-Stecker der Telefone vertauscht. Aus Faulheit wieder in den Keller zu gehen und das richtig zu machen, habe ich also auch im ATA-Adapter die Reihenfolge verändert. Nun werden die Telefone also in einer anderen Reihenfolge beim Provider registriert. Aus mir unverständlichen Gründen führte dies aber dazu, dass manchmal einzelne Telefone ihre Registrierung verloren haben. WTF???

Bugs im ATA-Adapter

Inzwischen habe ich verschiedene Firmwarerevisionen im ATA getestet. Immerhin gibt sich Grandstream mühe auch jahrealte Geräte zu patchen. Ältere Revisionen hatten unter anderem das Problem, dass Anrufe einfach abgebruchen sind. Insbesondere wenn mehr als ein Telefon gleichzeitig in Gebrauch war, war der Adapter anscheinend überfordert. Manchmal hat dann nicht mal mehr das Webinterface reagiert und ich musste den Stecker ziehen.
Der ATA-Adapter kommt wohl besser mit dem NAT klar, wenn die Option use random port gesetzt ist, dazu noch STUN verwenden. Zeitweilig hatte ich eine Zeitschaltuhr am ATA, die den nachts kurz abgeschaltet hat. So waren wir .. naja.. zumindest meistens erreichbar. Mit neurerer Firmware geht es auch ohne die Uhr.

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€.

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.

Internetprovider wechseln is' nicht

Den ungeliebten Telekom-Tarif können wir immer nur jährlich kündigen und die einzige Alternative wäre bei uns die Entega Medianet (Ehemals HSE/HEAG). Zwischeninfo: DSL bei O2 / 1&1 / what ever läuft am Ende auch alles über's Telekom-Netz und Unitymedia bietet viel zu wenig Upstream. Die Entega wollte ich also mal ausprobieren, in der Hoffnung, dass die als kleiner, lokaler Anbieter einfach nicht genug Ressourcen haben, um ihr Netz so sehr zu vermurksen, wie die Telekom. Aber eine extra-miese 2-Jahres-Mindestlaufzeit auch ohne Neuanschluss hat mich bisher davon abgehalten.
Für den Moment habe ich bei der Telekom KEIN IPv6. Das soll angeblich ja gehen, aber egal, was ich einstelle (Dual Stack/IPv6 only/...) - wir bekommen dann keine IP mehr. Inzwischen kann sich der Hauptrouter auch nicht mehr mit PPPoE authentifizieren. Das hat jahrelang funktioniert, dann plötzlich Connect-Error. Habe alles mögliche versucht, unter Anderem unsere alten PPPoE-Daten von AOL als fail-over Connection auf die gleiche WAN-Verbindung gelegt. Dann hat der Router zufällig mit den Telekom oder AOL-Daten angefangen zu connecten bis zum Fehler. Dann die anderen Daten versucht und das ging dann. Einige Monate jedenfalls, dann war es gar nicht mehr möglich sich zu verbinden und ich musste den Vigor wieder als echten Router statt als Modem betreiben. Trotzdem kein IPv6 und Port Forwarding kann ich jetzt komplett vergessen. Das Telefon schmiert also wieder von Zeit zu Zeit ab.
Die Telekom hat inzwischen selbst gemerkt, dass mit underem Anschluss was nicht stimmt und wollte einen Techniker losschicken (Zitat aus Extra-3: "Genausogut könnten sie sagen wir schicken die Männer der Nachtwache").
Inzwischen habe ich einen 3G-Empfänger auf dem Dachboden installiert, den mein neuer LANCOM-Router dank eines USB-over-RJ45-Extenders als Notfall-Verbindung nutzen kann. Es müsste noch eine SIM-Karte 'rein. Für diesen Zweck gibt es einfach keine zufriedenstellenden Tarife. Alternativ mache ich bei Freifunk mit, um wenigstens etwas gegen diese desolaten Zustände zu unternehmen. Dabei habe ich gemerkt, wie viele Leute tatsächlich Probleme mit der Telekom haben und noch uralte DSL-16.000-Verträge laufen lassen, die ja eigentlich zum Zeitpunkt dieses Absatzes abgeschafft sein sollten. Dagegen haben sich offenbar doch viele Leute gewehrt und die Telekom muss das irgendwie weiter supporten.

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 fast 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 eigentlich bis 2018 sowieso jeder hätte umsteigen sollen.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ügte, 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 (Und oft geht es selbst dann nicht). Was die Konzerne politisch nicht durchsetzen können, wird eben über Technologiehindernisse erzwungen.
Es ist schon beachtlich, dass ich inzwischen meinen eigenen Text hier in Google finde, wenn ich nach diversen Problemen suche. Das zeigt, wie wenig Leute sich wirklich mit der Technik beschäftigen - und folglich sich der Tatsache, dass das Telefon heute so abhörbar wie nie zuvor ist, gar nicht bewusst sind. Die Stasi musste Briefe wenigstens noch für den Empfänger erkennbar aufreißen, um sie zu überwachen und konnte ihre analogen Akten am Schluss nicht vollständig vernichten. Deswegen wissen wir heute immerhin, was damals so alles alles schief gelaufen ist. Nicht auszudenken, wenn die DDR heutige Technologie zur Totalüberwachung hätte einsetzen können. Ich habe diesen Text jetzt über viele Jahre weiter geschrieben. In Sachen verschlüsselte Telefonie sind keine Fortschritte zu erkennen.