VoIP - Verbuggt und instabil

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:

• IPv6 aktivieren. In IPv6 gibt es genug IP-Adressen, dass jedes Endgerät eine globale IP haben kann. Das Problem hier liegt darin, dass IPv6 zum einen nicht von allen Geräten und Anbietern unterstützt wird und zum anderen darin, dass durch die globalen IPs die Netzwerkinfrastruktur des LANs nach außen sichtbar wird. http://www.heise.de/netze/meldung/Gretchenfrage-NAT-oder-nicht-NAT-fuer-IPv6-218971.html, 2015.06.19
• PPPoE für das Endgerät einstellen. Hierfür muss zum einen der Router PPPoE pass through zulassen und man benötigt die PPPoE-Daten eines Anbieters für jedes Telefon. Da dadurch weitere, globale IPs geöffnet werden, der Router aber trotzdem noch online sein soll, werden für den Router und jedes Telefon PPPoE-Daten benötigt. Hier fallen zusätzliche Kosten an. Außerdem sind die Telefone nun nicht mehr durch die Firewall des Routers geschützt.
• Keep Alive verwenden, um eine Verbindung durch das NAT offen zu halten. Der Router merkt sich dabei, welche lokale IP welche globale IP kontaktiert und leitet Pakete von dieser globalen IP für eine gewisse Zeit an die lokale IP weiter. Der ATA-Adapter muss also in regelmäßigen Intervallen den Server kontaktieren (Keep Alive). Im Idealfall sollte es dadurch möglich sein, IP-Telefone ohne zusätzliche Konfiguration des Routers anzuschließen.
• Port Forwarding einstellen. Hierbei wird im Router fest konfiguriert, dass Pakete, die an einen bestimmten Port gehen, an eine bestimmte, lokale IP weitergeleitet werden. Dafür benötigt jedes Telefon eine feste IP im LAN und muss über unterschiedliche Ports (als die anderen Telefone) SIP-Pakete empfangen. Damit das Telefon später nicht durch laufende Down/Uploads blockiert wird, sollte im Router sowieso eingestellt werden, dass die IP-Adressen bzw. Ports der Telefone privilegiert sind.
  Ein Problem hier ist, dass man natürlich wissen muss, welche Ports geöffnet werden müssen. Ich habe im Voraus vergeblich versucht, dies herauszufinden. Im Forum wusste hierzu niemand Rathttp://www.ip-phone-forum.de/showthread.php?t=277009&p=2074320&viewfull=1#post2074320, 2015.06.19 und die von der Telekom sind am Telefon meinen Fragen hierzu immer wieder ausgewichen und haben versucht, mir Entertain anzudrehen.
  In der Theorie sind die benötigten Ports im ATA-Adapter wohl frei wählbar. Nach einiger Recherche habe ich dann noch eine sehr knappe Anleitung der Telekom gefundenhttp://hilfe.telekom.de/hsp/cms/content/HSP/de/3378/faq-350884716, 2015.06.19, die die Freigabe folgender Ports fordert: 5000-5480 (SIP), 30000-31000, 40000-41000 (RTP) und 3478-3479 (STUN)http://www.speedguide.net/port.php?port=3478, 2015.07.15. Laut Anleitung der Telekom, sollen auch die Ports 80 und 443 (ausgehend) geöffnet werden; keine Ahnung, was hiermit gemeint ist. Der ATA-Adapter ist doch kein Webserver! Gut, da steht nur bei ausgehenden Ports, wahrscheinlich soll der Adapter Webseiten aufrufen können, aber solche ausgehenden Verbindungen werden durch meinen Router sowieso nicht geblockt.
  Dass so viele Ports freigegeben werden müssen, liegt daran, dass IP-Telefonie eine ganze Reihe von Protokollen erfordert. Dazu später mehr. Vermutlich ist es aber ausreichend, nur die SIP-Ports zu öffnen, da die anderen Protokolle, z.B. nur während eines Anrufs aktiv sind und dann kontinuierlich Pakete senden, was einem Keep Alive gleich kommt.
  Wie sich später zeigen wird, ist Port Forwarding, so, wie man sich das vorstellt, bei meinem Cisco RV042G-Router auch nur mit UDP möglich.
• Des weiteren ist hier STUN zu nennen. Dabei kontaktiert der ATA einen speziellen Server, welcher ihm die globale IP des Routers mitteilt. So kann diese IP direkt in der SIP-Session verwendet werden. STUN wird in der Regel in Kombination mit Keep Alive verwendet, ist bei Verwendung eines VoIP-Providers mit fester IP aber in der Regel nicht notwendig, da der SIP-Server die IP des Routers ja anhand der eingehenden Pakete des Clienten feststellen kann. Wirklich benötigt wird STUN nur, wenn eine direkte SIP-Verbindung zwischen zwei Endgeräten etabliert werden soll, die beide hinter einem NAT hängen. Wie schon erwähnt, ist es möglich, direkt IP-Adressen anzurufen. Bei dem HT 704 lautet die "Nummer" dann z.B. *74192*168*1*100*5060, um die IP-Adresse 192.168.1.100 über Port 5060 anzurufen.

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:

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:

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

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.