Zugschlusbeobachtungen (Entries tagged as telefon)

Die Zeiten ändern sich

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 27 May 2012 23:03:04 +0200

Es ist etwa 20 Jahre her, dass meine damalige allerbeste Freundin nach einem knappen Jahr Australien wieder in ihre etwa 200 km von meinem damaligen Wohnort entfernte Heimat zurückgekehrt ist. Wir haben kurz telefoniert, Inhalt: “Schön, dass Du wieder da bist. Werden wir mehr als zwei Stunden miteinander reden? Ja? Ok, ich bin in knapp zwei Stunden da.”

Ich schwang mich ins Auto und bin hingefahren. Und in derselben Nacht wieder zurück. Und: Es war billiger als ihre Rückkehr am Telefon zu feiern.

Ich hatte damals ein dieselgetriebenes Auto, der Liter Diesel kostete knapp eine Mark und 20 Pfennige. Und Telefonkosten in der Nebenzeit bemaßen sich für ein innerdeutsches Ferngespräch nach der Faustregel “Eine halbe Stunde kostet zehn Mark”. Für das, was ein anderthalbstündiges Telefonat kostete, konnte ich damals 400 Kilometer weit fahren.

Seitdem sind die Telefonkosten ins unermessliche gefallen (Flatrate, Telefonat kostet einfach nichts). Und der Sprit ist dann doch “ein wenig” teurer geworden. Aus Umweltsicht ist das eigentlich fein, denn Telefonieren hat damals schon die Umwelt so gut wie nicht belastet. Die Fahrt mit meiner alten Dreckschleuder, die heute - natürlich - nichtmal die rote Plakette bekäme, war eine ganz schöne Sauerei.

Adernpaare in Wänden

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 04 Aug 2009 13:55:18 +0200

Lerninhalt des letzten Sonnabends: Wenn in einem zehnpaarigen Telefonkabel die Paare 1 und 3 bis 8 belegt sind, bedeutet das nicht notwendigerweise, dass drei Paare (nämlich 2, 9 und 10) für einmal DSL und einmal S0 benutzbar sind.

Im konkreten Fall hat der Elektriker, der das vor ein paar Jahren gebaut hat, nämlich Paar 2 freigelassen, weil es - richtig - kaputt ist. Und so hat der Anwender jetzt zwar eine Fritzbox an der Wand, aber immer noch kein Internet, und kann nur mit viel Glück wieder so telefonieren wie vorher.

So ein Mist.

Telefonkater

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 03 Feb 2009 16:00:00 +0100

Es ist nicht überliefert, wohin das Telefonat ging.

Quality of Service im Ethernet fuer Telefonieanwendungen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 27 Jun 2008 10:31:38 +0200

Schon seit etwa anderthalb Jahren hat sich ein Kunde mit seinen Büroräumen auf ein anderes Gebäude ausgedehnt. Zwischen den beiden Gebäuden gibt es zwar Glasfaser, aber keine Kupferverkabelung. Trotzdem möchte man auch im neuen Büro gerne telefonieren können; dort sollen Nebenstellen der am alten Ort vorhandenen Alcatel OmniPCX Enterprise aufgestellt werden.

Daraus entsteht die logische Entscheidung, die Telefone im neu hinzugekommenen Bereich des Gebäudes per IP anzubinden: Das geht nämlich über die vorhandenen Glasfasern, während man für digitale Endgeräte an der TK-Anlage entweder Kupfer werfen, oder den neuen Standort mit einem (teuren!) Gateway zum Umsetzen von IP auf die digitalen Endgeräte ausstatten müsste.

Also bietet sich die Möglichkeit, ein bisschen über IP-Telefonanlagen in überlasteten Netzen zu lernen.

Da der neue Standort mit relativ sportlichem Zeitplan produktiv werden soll, und der TK-Anlagen-Lieferant am liebsten seine eigenen Switche verkauft anstelle seinen Kunden bei der Konfiguration fremdgelieferter Switche zu helfen, wird zunächst für die Telefonie eine getrennte Infrastruktur aufgebaut: Neben dem Gigabit-Link für das Datennetz wird auf einem zweiten Fasernpaar mit Hilfe von Medienwandlern und einem uralten HP4000M eine zweite Verbindung zwischen den beiden Gebäuden realisiert, die ausschließlich für die Telefonie genutzt wird. Im alten Standort kommen zwar beide Links auf demselben Switch und demselben VLAN raus, aber in dieser Konfiguration ist wenigstens sichergestellt, dass das Datennetz nicht die Telefonie behindern kann (es sei denn, man überlastet die Backplane des Switches, auf dem die beiden Links in den neuen Standort ankommen und an den auch die TK-Anlage angeschlossen ist).

Das hat jetzt anderthalb Jahre lang prima funktioniert. Nun soll der alte HP4000 weg und durch einen moderneren Switch ersetzt werden, und bei der Gelegenheit hätte man gerne auch gleich etwas Redundanz, Ring und Spanning Tree. Und ich spiele ein wenig mit der IP-Telefonie und versuche, etwas über ihr Verhalten auf einem überlasteten Netz zu lernen.

Leider hat der Kunde keine Reserve-TK-Anlage, was mich dazu zwingt, die Tests mit der produktiven Anlage zu machen und sicherzustellen, dass meine Tests den Produktivbetrieb des Kunden nicht behindern. Also nehme ich mir einen Stapel Switche unter den Arm und fahre hin.

Zeichnung des Testlabs

Das Bild zeigt mein Testlab, das mit dem produktiven Officenetzswitch des Kunden und der TK-Anlage auch Infrastruktur umfasst, die besser nicht ausfallen sollte. Mein Testclient A kommt neben die TK-Anlage; über einen dot1q-Trunk Gigabit Ethernet verbinde ich meinen Test-Switch 1 mit der Infrastruktur des Kunden. Mein Testclient B kommt an Test-Switch 1. Test-Switch 2 mit Testclient C und einem Alcatel-IP-Telefon wird über einen dot1q-Trunk mit Test-Switch 1 verbunden. Der Trunk zwischen Test-Switch 1 und Test-Switch 2 wird beidseitig auf 10 Mbit Fullduplex geschaltet, um es später bei der Simulation eines überlasteten Netzes einfacher zu haben. Alle anderen Links im Spiel sind Fast Ethernet.

Das Test-Setup funktioniert: Alle Testclients sehen einander, die TK-Anlage und das Telefon; das Telefon bucht sich sauber in die TK-Anlage ein und ich kann telefonieren. Als Testgesprächspartner dient zunächst die unter einer normalen Baden-Badener Ortsrufnummer erreichbare SWR3-Stauhotline, die den Vorteil hat, dass ein Automat einen geduldig minutenlang vollsabbelt und man auf diese Weise prima entscheiden kann, ob das Telefonat noch ordentlich funktioniert oder nicht.

Die Alcatel-Anlage benutzt für die Kommunikation mit ihren IP-Telefonen ein Wireshark nicht weiter bekanntes, auf UDP aufsetzendes Protokoll, das sich weder als SIP noch als H.323 identifizieren lässt. Wird also mit einiger Wahrscheinlichkeit leider etwas proprietäres sein. Oder ich habe nur den richtigen Standard nicht gefunden. Das schöne an Standards ist dass es so viele davon gibt.

Test A0: Testclients A und B tauschen bidirektional über TCP und netcat Daten von /dev/zero nach /dev/null aus. Dabei beschränkt sichTCP selbsttätig auf die Dicke des künstlichen Flaschenhalses zwischen den beiden Test-Switches, und auch das Telefon interessiert sich nicht großartig dafür, dass das Netz gut ausgelastet ist. Das sieht man auch wunderschön im torrus-Plot des Swichports, dessen Auslastung zwar nur knapp, aber doch sichtbar unter 10 Mbit/s bleibt. Auch ohne auf den Switchen konfigurierte Priorisierungsmechanismen funktioniert das Telefon prima und ich muss mir etwas anderes einfallen lassen, um einen Fehler zu erzeugen. Also nehmen wir für die weiteren Tests UDP, das keine ins Protokoll verankerten Durchsatzregelmechanismen hat. Die Wahl zur Erzeugung der Testdaten fällt schnell auf das Paket netperf.

Test A1: Während eines laufenden Telefonats beginne ich, mit netperf massenhaft UDP-Pakete von Testclient C zu Testclient B zu übertragen. Die Netzlast ist also dem Datenstrom, dessen Qualität ich als einziger menschlicher Teilnehmer des Telefonats beurteilen kann, entgegengesetzt. Beim Start der Netzlast verschlechtert sich die Qualität des Telefonats nicht; man hört keine Störungen.

Test B1: Dasselbe, nur andersrum. Diesmal fließen die Netzlastdaten in dieselbe Richtung wie die relevante Richtung des Telefonats, und man bemerkt sofort nach dem Start der Netzlast erhebliche Aussetzer in der Telefonie, als der Switch in seiner Verzweiflung auch massenhaft zum Telefonat gehörende Datagramme verwirft weil sie beim besten Willen nicht mehr auf den saturierten 10-Mbit-Link passen. Nach etwa 30 Sekunden hat das Telefon genug und bootet.

Test A2: Im Setup von Test A1 wird der Flaschenhals entschärft, indem der Link zwischen den beiden Testswitches auf 100 Mbit konfiguriert wird (mehr als 100 Mbit kann mein Test-Switch 2 nicht). Da es auch schon mit 10 Mbit/s funktioniert hat, erstaunt wenig, dass das Testergebnis auch bei einem 100-Mbit-Link zwischen den beiden Testswitches “funktioniert” lautet.

Test B2: Dasselbe wie Test B1, nur mit einem 100-Mbit-Link zwischen den beiden Switches. Auch hier hört man sofort nach Start der Netzlast Störungen, jedoch deutlich weniger als bei Test B1. Auch hier wirft das Telefon nach einiger Zeit (diesmal deutlich länger, einige Minuten) das Handtuch und bootet.

Test A3: Nun führen wir den künstlichen Flaschenhals wieder ein und beschränken die Bitrate auf dem Link zwischen den beiden Testswitches wieder auf 10 Mbit/s. Als Ausgleich dafür erhalten die Switchports, auf denen die TK-Anlage und das Telefon hängt, die Konfigurationsoption “qos priority 4”. Die Wirkung bei der Wiederholung von Test A1 auf diesem Setup ist evident, auch bei Betrieb der Lastgeneratoren bleibt ein Telefonat unbeeinflusst. Dies wird auch bei einem längeren Telefonat zwischen Menschen bestätigt; beide Gesprächspartner bemerken keinen Unterschied in der Gesprächsqualität beim Hinzuschalten der Netzlast. Während des etwa zehnminütigen Tests bleibt das Telefon stets eingebucht und benutzbar.

Der Vollständigkeit halber gibt es dann auch noch Test B3, der Test B1 bei konfiguriertem “qos priority 4” wiederholt, mit denselben Ergebnissen wie Test A3.

Diese Testreihe ist aus dem Mai 2008. Bei der ersten Durchführung der Tests im Sommer 2007 hat sich die Anlage noch signifikant anders verhalten: 2007 buchte sich das IP-Telefon bei fast allen Tests, auch bei den Tests mit auf den Switchen aktiviertem QoS trotz qualitativ nicht eingeschränkter Telefonieverbindung nach einigen Sekunden Netzlast aus der Anlage aus und bootete. Im Frühjahr 2008 erhielt die TK-Anlage eine Runderneuerung und auch eine neue Software, was die spontanen Ausbucher der IP-Telefone drastisch verringert hat. Wie oben gezeigt, fliegen die IP-Telefone mit der derzeitigen Software auf der Anlage nur in Situationen weg, wo sie das auch dürfen.

Technisch habe ich das ganze jetzt so verstanden: Durch das Setzen von “qos priority 4” erhalten die über einen so konfigurierten Port empfangenen Ethernet-Frames eine höhere Priorität als die über einen “normalen” Port empfangenen Frames und werden somit bevorzugt innerhalb des Switches weitergeleitet. Bei der Übertragung des Frames über einen dot1q-Trunk wird die Priorisierung des Frames wohl im VLAN-Tag mit transportiert und bleibt somit bis zum Egress-Port und dem Zielendgerät enthalten. Somit ist es möglich, im gleichen VLAN priorisierte und nicht priorisierte Frames zu transportieren, was gegenüber einer VLAN-Priorisierung (die wohl auch irgendwie geht) praktisch ist, wenn in einer gewachsenen Infrastruktur TK-Endgeräte und nicht-TK-Endgeräte im gleichen VLAN leben und man den Traffic von TK-Endgeräten trotzdem priorisieren muss.

Ein Nachteil besteht darin, dass man die Access-Ports der Switche zum Endgerätetyp passend konfigurieren muss und dass ein versehentlich an einem priorisierten TK-Port angeschlossenes Datenendgerät bei hinreichend bösem Willen die Telefonie sabotieren kann. Das lässt sich aber bei dem Schicht-2-QoS, um das es hier im Artikel geht, kaum verhindern. Es sei denn, man macht dot1q bis zum Endgerät, damit das Endgerät seinen Priorisierungswunsch gleich ins VLAN-Tag schreiben kann. Aber das öffnet eine ganz andere Problemklasse aus dem Bereich Security, was ich gerne vermieden habe.

Andere QoS-Verfahren setzen die Priorität aufgrund von “höheren” Protokollinformationen wie Absender- oder Empfänger-IP-Adresse oder TCP/UDP-Portnummern und bilden die so ermittelte Priorität auf die Priorätit des schließlich zu transportierenden Ethernet-Frames ab. Dazu brauchen die Switches aber IP-Intelligenz (“Layer 3 Switches”), was die vorhandenen Switche nur sehr unbefriedigend beherrschen und was ein größeres Netzredesign erzwingt. Das werden wir im konkreten Fall besser beiben lassen.

Fazit: Die Alcatel-IP-Telefonie ist nun auch auf einer gemeinsam mit Datendiensten genutzten Netzwerkplattform nutzbar, weil durch geeignete Konfiguration der Switches sichergestellt werden kann, dass der Einfluss von Datenanwendungen auf die Telefonie minimal ist.

Weiterer Lerninhalt: Es ist verdammt schwer, mit üblichen Protokollen in heutigen LANs eine Lastsituation zu erzeugen, die von zeitkritischen Anwendungen wie Telefonie überhaupt bemerkt werden. Besonders TCP ist da extrem gutmütig und nimmt seinen Datendurchsatz automatisch so weit zurück, dass andere Anwendungen auf derselben Physik nicht signifikant bemerken, dass da eine TCP-Anwendung das Netz füllt. Ich würde erwarten, dass in einem nicht priorisierten LAN der Start einer weiteren TCP-Anwendung in der Praxis keine Auswirkung auf die Telefonie hat. Höchstens bei vielen TCP-Verbindungen würde ich erwarten, dass das Telefonat einmal kurz aussetzt bis die beteiligten TCP-Stacks einander bemerkt haben und ihren Durchsatz entsprechend reduziert haben. Als Problemkinder bleiben also nur Protokolle wie UDP oder ESP, die keinen solchen Mechanismus haben.

Stand Telekommunikation

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 15 Apr 2008 14:36:43 +0200

Die Janus-Eigenschaft meiner beiden Telefonanschlüsse besteht nach wie vor: Anrufe aus dem Alice-Netz und aus fast allen anderen Netzen kommen - ordentlich - auf dem Alice-Anschluß an. Anrufe von Kunden meines bisherigen Anbieters kommen nach wie vor auf dem alten Anschluß heraus.

Das wird auch bis mindestens zum 22. April so weiter gehen, denn zu diesem Termin hat mein alter Anbieter jetzt endlich die Kündigung bestätigt. Bis dahin hängt ein analoger Anrufbeantworter auf dem IAD des alten Anbieters, der im “Hinweisansage”-Modus darum bittet, den Anruf bitte aus einem anderen Netz zu wiederholen oder unsere 01805-Callcenterfalle anzurufen.

Wir warten nun auf das Kapitel “alter Anschluss ist abgeschaltet und Anrufe aus dem Netz des alten Anbieters landen im Nirvana”. Telcos sind ja soooo berechenbar...

TK-Anlage umgestöpselt

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 04 Apr 2008 13:03:00 +0200

Knapp eine Woche nach der Installation hat mein Alice-Telefonanschluß nun den großen Sprung zur “95” gemacht: Eingehende Telefonate aus Fremdnetzen kommen nun aus dem Sphairon-IAD raus und ich konnte meine Fritzbox endlich vom alten IAD auf das neue umstöpseln.

Jetzt liegt der schwarze Peter erstmal wieder bei meinem bisherigen Anbieter, denn Anrufe aus seinem Netz kommen nach wie vor auf seinem IAD heraus (an dem nur noch als “Notbehelf” mein altes Eurit hängt). Aber man hat mir schon bestätigt, dass das in den nächsten Tagen abgestellt wird.

Letztendlich muss ich dann noch mit Alice ausdebattieren, dass der Anschluss bitte erst ab dem 3. April berechnet wird, denn benutzbar war der Anschluß. auf dem keine Gespräche aus Fremdnetzen herauskamen, nicht wirklich. Inzwischen bin ich bereit, den Anschluß als “funktionstüchtig übergeben” zu betrachten, aber nicht ab dem Installationsdatum.

Nun zu den Erfahrungen mit der Alice-Hotline bei der Bearbeitung dieser Störung. Gesamtnote: Durchwachsen.

Telefoniestörungen darf man bei Alice (inzwischen wieder) über eine 0800er-Rufnummer melden; für alles andere muss man eine 01805 anrufen. Das finde ich gerade noch akzeptabel, denn 01805 ist über den eigenen Festnetz-Anschluss gerade noch bezahlbar, und wenn der eigene Festnetzanschluss nicht funktioniert, kann man ja die 0800 anrufen. Ins Gras beißen hier diejenigen, die Alice-DSL ohne Telefonanschluß gebucht haben, denn die müssen auch bei Störungen, die man bei “Alice mit Telefon” über 0800 hätte melden dürfen (weil sie auch das Telefon mit dahin gerafft hätten, wenn Telefon da wäre), 01805 wählen und dies in Ermangelung eines Telefonanschlusses eventuell sogar über das Mobiltelefon tun.

An der 0800-Störungsannahme muss man sich erstmal einen gefühlt knapp fünfminütigen Sermon anhören, dass man diese Nummer nur bei Telefoniestörungen anrufen darf und kommt dann verhältnismäßig flott zu einem Callcentergagenten, der zuerst die Daten aufnimmt, einige erste Debuggingschritte vornimmt und einen dann gegebenenfalls zu einem Techniker verbindet.

Und genau hier hakt es das erste Mal, denn die Callcenteragenten der ersten Linie scheinen entweder keinen Lesezugriff auf das Ticketsystem zu haben oder diesen nicht angemessen zu nutzen. Denn: Wenn man die Hotline zu einer bereits gemeldeten Störung befragt, beginnt der Callcenteragent wieder bei Adam und Eva. Und wenn er einen dann für würdig befindet, mit einem richtigen Techniker zu sprechen, heißt es oft “die Kollegen sprechen leider alle gerade, rufen Sie bitte später nochmal an”. Einen Rückruf bekommt man zu diesem Stadium des Calls nicht angeboten. Auch das Verbinden zur Technik geht manchmal schief: Ich habe sowohl erlebt, in einer Endlosschleife “Ihre Verbindung wird gehalten” zu landen (und dann vom auf dem zweiten B-Kanal parallel angerufenen Callcenteragenten gesagt bekommen, im Ticket stünde “Kunde hat aufgelegt”) als auch eine so abgrundtief schlechte Verbindung zum Techniker zu haben, dass ich ihn kaum verstanden habe. Im letzteren Fall hat der Techniker auch einen Rückruf verweigert, so dass die Kommunikation per Abwasserleitung stattfinden musste.

Eine weitere Hürde ist die Tatsache, dass das bei mir gezeigte Fehlerbild in den Alice-Prozessen entweder gar nicht oder nur sehr selten vorkommt: Die parallele Bereitstellung des neuen Anschlusses zu einem bestehenden Altanschluss, der technisch nach der Realisierung des Alice-Anschlusses weiterhin besteht und auch in Teilen noch funktioniert. So fand ich mich in der Situation, dass jeder Callcenteragent und Techniker sich erstmal fünf Minuten lang erklären lässt, dass zwei Teilnehmeranschlußleitungen mit zwei Telekom-TAE in der Wohnung sind, an denen zwei IADs hängen, die beide für ausgehende Gespräche genutzt werden können, und die Gespräche abhängig vom Anbieter des Anrufers entweder auf dem einen oder dem anderen IAD herauskommen. Mir erzählt niemand, was stattdessen vermutet wird; ich reime mir allerdings zusammen, dass die vermuten, ich hätte eine fehlkonfigurierte TK-Anlage am Alice-IAD hängen, die die Anrufe nach dem Zufallsprinzip auf ihren internen Ports verteilt.

Am Montag nachmittag habe ich das erste Mal eine Technikerin am Telefon, die nach einigen Testcalls zum gleichen Urteil kommt wie ich: Ein Problem bei der Portierung. Sie würde sich kümmern, und ich sollte am Dienstag Nachmittag nochmal probieren.

Am Dienstag Nachmittag ist der Status unverändert. So rufe ich dann gegen 17.30 Uhr erneut die Hotline an und berichte, dass die zum vorhandenen Ticket angekündigte Statusänderung nicht eingetreten ist und das Routing eingehender Gespräche nach wie vor nicht funktioniert. Auch dieser Callcenteragent lässt sich - anstelle einfach ins Ticket zu gucken - die Geschichte von Adam und Eva erneut erzählen und macht dann - anstelle die Information zum vorhandenen Ticket zu schreiben - ein neues Ticket auf. Ich beiße in die Tischkante.

Um 21.30 Uhr am Dienstag abend ruft eine neue Technikerin an, lässt sich die Geschichte - wer ist überrascht - nochmal von Anfang an erzählen und diagnostiziert - richtig - ein Routingproblem. Sie würde sich kümmern, und ich sollte am nächsten Tag nochmal probieren.

Aber hier hört die Zeitschleife auf: Am Mittwoch nachmittag kommt eine SMS, die ankündigt, dass die eingehende Erreichbarkeit meiner Rufnummern “im Laufe der Nacht durch Automatismen sichergestellt” werde. Und diese Ankündigung war schliesslich korrekt: Seit Donnerstag morgen kommen eingehende Gespräche brav auf dem Alice-IAD raus.

Störungsbehebungszeit: eine Woche. Das ist, äh, Note fünf. Das sollten wir besser können, liebe Alice, insbesondere, wenn der Kunde klare Statusmeldungen liefert und seine Diagnose vor allen Dingen von der ersten Störungsmeldung ab korrekt war. Eventuell nützt es was, ein Ticketsystem nicht nur zu betreiben, sondern es auch zu nutzen, und dem Kunden zur Abwechslung auch mal zuzuhören anstelle nur stur den Debuggingprozessen zu folgen. Hier hätte echt nur noch gefehlt, einen Telekomtechniker zum Durchmessen der Teilnehmernanschlussleitung in Marsch zu setzen.

Nach jedem Telefonat kommt per Mail ein Link zu einer Webumfrage, in der man seine Meinung über den Supportvorgang kundtun kann. Es gibt sogar einige Freitextfelder, in denen man in Prosa ranten kann. Es wird allerdings immer gezielt nach dem Agenten gefragt, so dass die von mir vergebenen Noten im Ganzen besser sind als Alice es eigentlich verdient hätte - der einzelne Agent ist ausgesucht höflich und nett, aber er kann halt nix tun wenn die Prozesse dahinter stinken.

Detected an inconsistency in the global routing table

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 30 Mar 2008 09:28:13 +0200

Hier der aktuelle Stand in der Alice-Saga: Beide Telefonanschlüsse funktionieren weiterhin und können für ausgehende Gespräche genutzt werden. Eingehende Gespräche kommen, wenn der Anrufer auch Alice-Kunde ist, auf dem Alice-Anschluß an, sonst auf dem alten Anschluss von U.

Die so kommunizierte Fehlermeldung stellt die Alice-Technik nach wie vor vor große Herausforderungen. Ob das nun daran liegt, dass es den absoluten Ausnahmefall darzustellen scheint, dass bei einer Umschaltung von einem alten Anbieter zu Alice der Alice-Anschluß parallel zum bestehenden Anschluß geschaltet wird und beide Anschlüsse funktionieren können, oder daran dass die Alice-Techniker offensichtlich nur Zugriff auf den Zustand einer Rufnummer innerhalb des Alice-Netzes haben und nicht sehen können, ob die Nummer von “draußen” überhaupt zu Alice geroutet wird, ist unklar.

Wir werden sehen, wie lange der Zustand noch anhält.

Liebe Alice-Kunden, die bei mir versuchen anzurufen: Derzeit ist an meinem Alice-Anschluß nur ein ISDN-Telefon angeschlossen, das im “Kabäuschen” steht. Somit gibt es keinen Anrufbeantworter und auch die Chance, dass ich das Telefon nicht klingeln höre. Bitte Geduld, oder auf dem Mobiltelefon anrufen.

"Sie müssen gerade über Alice telefonieren, Sie haben keinen anderen Anschluss mehr"

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 28 Mar 2008 09:16:54 +0100

Nachdem auch über Nacht sich an der Telefoniesituation nichts geändert hat und Anrufe auf meine Festnetznummer weiterhin auf dem “alten” Anschluss rauskommen, rufe ich die Alice-Neukundenhotline an, um mich nach dem Portierungstermin für meine Rufnummern zu erkundigen.

Der Callcenteragent nimmt mir allerdings nicht ab, dass mein alter Anschluß noch funktioniert, weil er offensichtlich nur den Prozess der Migration von T-Anschlüssen kennt, wo für den Alice-Anschluß dieselbe TAL verwendet wird wie für den wegfallenden T-Anschluss und es somit gar nicht sein kann, dass der alte Anschluss weiterhin erreichbar ist.

Irgenwann glaubt er mir dann doch, dass an dem Alice-IAD derzeit nur ein Test-Telefon hängt, mit dem ich ausgehend telefonieren kann, das aber bei Anrufen z.B. auf meine 0621 727 398 34 nicht kllingelt und stattdessen die am “alten” Anschluß angeschlossenen Telefone klingeln. Er nimmt eine Störung “eingehende Erreichbarkeit gestört” auf und will mich an die Technik verbinden, was derzeit aber nicht geht.

Ich soll später nochmal anrufen. Recht schönen Dank auch. Rückruf gibt’s keinen. So kann man es sich natürlich auch einfach machen.

Online mit Alice

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 27 Mar 2008 22:25:00 +0100

Im dritten Anlauf hat die Installation der Alice-DSL endlich geklappt. Und sie war gar nicht nötig; der Anschluss hätte schon vor dem 12. März funktioniert.

Der Telekom-Techniker (diesmal ein echter T-Com-Mitarbeiter) war für den Zeitraum von 08.00-16.00 Uhr angekündigt und kommt um 15.45 Uhr. Er entschuldigt sich wortreich dafür dass er so spät kommt, während ich ihm den roten Teppich ausrolle dafür dass er überhaupt erschienen ist. Er hängt seinen Piepser an die TAE und stellt am Kellerverteiler und am APL im Nachbarhaus fest, dass meine Ex-Alice-TAE immer noch korrekt auf den richtigen Stift im APL rangiert ist, schließt den APL wieder ab und verabschiedet sich.

**HMPF** Stellt sich nur die Frage, warum ich den Anschluß nicht schon vor zwei Wochen zum Laufen bekommen habe - denn ich habe schon vor zwei Wochen einfach mal das Sphairon IAD auf den Anschluß geschaltet und das Ding hat sich totgestellt. Genauso benimmt es sich immer noch.

Das Fehlerbild sieht so aus: Nach LED-Lage synchronisiert das Modem ordentlich mit dem DSLAM - die DSL-LED blinkt erstmal langsam, dann schnell und dann leuchtet sie dauernd. Nur bekommt das per Ethernet angehängte Notebook auf seine PADIs keine Antwort.

Die Hotline bringt schnell eine Erklärung: Das IAD konfiguriert sich erst, wenn man über ein Telefon die schon mit der Auftragseingangsbestätigung übermittelte PIN eingegeben hat, und so lange man das nicht getan hat, geht auch der Internetzugang nicht. Ich war fälschlicherweise der Meinung, die PIN sei nur für die Alice-Telefonie relevant. Ist sie aber nicht.

Ich habe einen Alice-ISDN-Anschluß bestellt, was bedeutet, dass ich die PIN über ein ISDN-Telefon eingeben muss: Die TAE-Anschlüsse des IAD sind in dieser Konfigurationsvariante tot. Ich greife mir mein Eurit und ein Patchkabel und sehe erst zu spät, dass dem Patchkabel ein Verriegelungsnupsi fehlt. Ich habe die PIN bis zur letzten Ziffer eingegeben, als mir das Patchkabel unten aus dem Eurit fällt. Danach ist das Sphairon so verwirrt, dass es nur noch Besetztzeichen von sich gibt: Ein Werksreset mit folgender 30-Sekunden-Entstromung ist angesagt. Während der Wartezeit stelle ich per Seitenschneider sicher, dass dieses Patchkabel mich in Zukunft nicht mehr sabotieren wird.

Nachdem das Sphairon nicht mehr beleidigt ist, kann endlich die PIN zum zweiten Mal - dieses Mal unfallfrei - eingegeben werden, und das Sphairon sagt mir “Willkommen bei Alice” und bootet nochmal. Danach kommt auf PADI auch brav ein PADO zurück und ich entlasse den geduldigen Hotliner aus dem Gespräch.

Der Rest ist einfach: pppoeconf und mit dem Notebook ausprobieren, nach Erfolg das Ethernet der Fritzbox auf das Sphairon umstecken und die neuen Zugangsdaten eintragen, und schwupps, bin ich mit Alice online. Die zugewiesene IP-Adresse endet auf .0, was eventuell bei manchen Netzen aus dem letzten Jahrtausend zu Problemen führt, aber die Adresse ist ja morgen schon wieder weg.

Da die neue Alice-Leitung parallel zur bestehenden DSL aufgebaut wurde, dürfte somit sichergestellt sein, dass die Migration ohne Unterbrechung der Internet-Connectivity stattfindet. Im Moment könnte ich Sandra ihre eigene 16Mbit-DSL anbieten, was ja schon ganz nett ist. Die Migration der anbieterunabhängigen VoIP-Telefonnummern war ein einfaches Umstecken eines Patchkabels und nach einer Minute gegessen. So soll es sein.

Zwei Zitterpartien bleiben noch: Die anbietergebundene Telefonie ist noch nicht migriert, sprich, die Rufnummernportierung kann nochmal schieflaufen, und auf der Alice-Webseite steht unter “Auftragsstatus”, dass ich den Anschluß schon seit dem 12. März nutzen kann. Hier sehe ich ja eine Rechnung ab dem 12. März kommen.

Um die Telefonieportierung kümmere ich mich morgen mal, und die Rechnung telefoniere ich dann mal mit der Hotline aus, wenn sie da ist.

Wir haben heute einen großen Schritt voran gemacht und hätten, wenn die Dokumentation von Alice besser gewesen wäre, diesen Schritt schon vor zwei Wochen machen können. Das hätte mir zwei Homeofficetage erspart... Aber es geht voran.

Falsche Angaben des Kunden ...

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 18 Mar 2008 20:36:08 +0100

... hat der für heute angekündigte Monteur des Incumbents auf seinen Arbeitsbericht geschrieben, bevor er ihn an seinen Auftraggeber zurückgegeben hat.

Ob er meine Klingel gefunden hat, entzieht sich meiner Kenntnis. Draufgedrückt hat er jedenfalls nicht, denn das hätte ich gehört. Ich war den ganzen Tag zuhause und habe die Wohnung nichtmal zum Müll rausbringen verlassen.

Das ist jetzt der erste Schritt in der Bereitstellung meines neuen Alice-Anschlusses, den ganz originär und alleine die Telekom, bzw. deren Subunternehmer versemmelt hat. Recht schönen Dank auch.

Einen neuen Montagetermin gibt es in vier Werktagen, wobei Sonnabend nicht als Werktag zählt. Also übermorgen in einer Woche. Danke, Ostern.

Lieber spät als gar nicht

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 16 Mar 2008 21:25:50 +0100

Mein Alice-Anschluss kommt voran. Die Auftragsbestätigung, die die Ausführung des Auftrags am 12. März ankündigt, wurde von Alice ausweislich der Received-Header am 13. März um kurz nach 14.00 Uhr ins Netz gepumpt und wäre dank uncodierter 8-Bit-Header und anderer Spam-Merkmale fast im Spamfilter gelandet. Eine so unsaubere E-Mail mit gewünschtem Inhalt habe ich seit Jahren nicht mehr gesehen.

Am 14. März kam dann auch das Sphairon IAD an, dessen DSL-LED an der noch nicht beschalteten TAE dauerhaft leuchtet (was eigentlich eine Verbindung anzeigt). Hoffen wir mal, dass es hier kein dead-on-arrival-Gerät ist.

Wenn Alice mal in Bewegung kommt (Alice II)

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 12 Mar 2008 21:30:43 +0100

... ist sie so schnell, dass die in Real geschehenen Dinge die IT locker überholen. Was leider in einem nicht ausgeführten Auftrag endet.

Wir erinnern uns: Im November hatte ich Alice beauftragt und bis Ende Februar noch keine Auftragsbestätigung, wohl aber die Kündigungsbestätigung von U erhalten. Die drohende Abschaltung des alten Anschlusses konnte ich über die Spezialhotline von U noch einmal verhindern und der Internetzugang funktioniert bis heute.

In der ersten Märzwoche springt das Status-Barometer im Alice-Webfrontend plötzlich um einen Punkt weiter: Erstmalig steht dort etwas anderes als “Ihre Bestellung wird bearbeitet”, und es wird sogar ein Termin genannt; “voraussichtlich Anfang April”. Die Dinge bewegen sich also.

Am 7. März stelle ich morgens fest, dass ich auf den noch bei U befindlichen Rufnummern nicht mehr erreichbar bin: “Diese Rufnummer ist uns nicht bekannt.” Ich kann noch raustelefonieren, und der Internetzugang funktioniert auch. Die “normale” Hotline von U ist den ganzen Tag über nicht erreichbar: Ich probiere es dreimal und bleibe jeweils 20 Minuten in der 01805-Warteschleife, bevor ich auflege. Da die Hotline bisher immer ganz gut erreichbar war, konstatiere ich eine Großstörung und warte auf die Behebung.

Am 8. März, Samstags, erreiche ich dann jemanden bei der Hotline, der mich erstmal durch die “Schauen wir mal, ob wir den Fehler dem Kunden in die Schuhe schieben können” Routine schleust: IAD entstromen, IAD werksresetten, TK-Anlage durch ISDN-Telefon ersetzen, ISDN-Telefon durch analoges Telefon ersetzen. Als alle seine Ideen versiegen, nimmt er schließlich die Störung auf, und kündigt an, dass im nächsten Schritt die Leitung durchgemessen wird. Vor dem Hintergrund, dass ich über die Leitung gerade mit ihm telefoniere und der Internetzugang perfekt funktioniert, weise ich ihn darauf hin, dass wir wohl beide wissen dass dieses Durchmessen nicht helfen wird, verabschiede mich höflich und verschwinde aus der Leitung.

Also doch wieder über die “Spezialhotline”, die am Montag ihre Arbeit beginnt und zur Hochform aufläuft: Man findet flott heraus, dass Alice die Portierung zum 3. April beauftragt hat und die Rufnummern auch zum 3. April erwartet, U die Nummern jedoch schon zum 3. März abgegeben hat und die Nummern somit in der Luft hängen. Fehler erkannt, Rückportierung der Nummern angestoßen, und schon am 12. März klingelt eine der fünf Nummern wieder. Die zweite kommt einen halben Tag später, nachdem ich erkannt habe, dass der durch den hilflosen Hotliner vom Sonnabend veranlasste Werksreset bei der nachfolgenden Neukonfiguration per TR-069 einen der SIP-Accounts auf die Vermisstenliste gesetzt hat. Also, nochmal Werksreset, und nun sind alle fünf SIP-Accounts da. Die noch fehlenden drei Rufnummern kommen dann hoffentlich heute nacht.

Aber zurück zum eigentlichen Inhalt dieses Artikels: Alice. Wir erinnern uns, die Ausführung des Auftrags ist für Anfang April avisiert, ich habe keine Auftragsbestätigung und auch noch kein IAD von Alice zugesendet bekommen. Nichtsdestotrotz steht heute morgen plötzlich ein Subunternehmer der T-Com vor der Tür und möchte eine TAL in meine Wohnung schalten. Das ist ja schön und gut, aber der APL ist im Heizungskeller, der Schlüssel für den Heizungskeller ist in einem verschlossenen Kasten vor dem Heizungskeller, der Schlüssel für den Kasten ist bei den netten Nachbarn und die sind nicht da. Also muss der T-Commer seine Sachen wieder einpacken, streichelt Murphy und verabschiedet sich. Ich greife zum Telefon und rufe die Alice-Neukundenhotline an.

Dort hat sich inzwischen auch was verändert, denn die Automatenstimme sagt mir nun, dass man den Auftrag am 12. März, also heute, ausführen wird, und dass ich bitte sicherstellen soll, dass der APL zugänglich ist. Hmpf. Danke für die rechtzeitige Information. Der Automat verabschiedet sich höflich und wartet darauf, dass ich auflege. Das tue ich aber nicht, denn ich will ja mit einem Menschen sprechen. Nach einigem “Sie haben zu wenige Ziffern eingegeben” und “ich habe Sie nicht verstanden” lande ich endlich bei einem Hotline-Agenten. Der teilt mir mit, dass ich heute morgen eine Mail erhalten haben müsste (torres’ Maillog spricht eine deutliche andere Sprache) und auch eine SMS versendet werden sollte. Die Hardware würde ebenfalls heute versandt.

Das ist ja alles schön und gut, aber diese Benachrichtigung kommt zu spät, denn der T-echniker ist schon wieder auf dem Weg zum nächsten Kunden, weil Alice es nicht geschafft hat, den Kunden rechtzeitig zu informieren. Wir vereinbaren am Telefon einen neuen Montagetermin für den 18. März.

Zwei Stunden nach dem vergeblichen Technikerbesuch trudelt dann die SMS ein, dass man den Auftrag heute auszuführen gedenkt. Toll, Alices Prozessen beim Funktionieren zuzugucken: Erst guckt man ihnen zu, wie sie mit der Geschwindigkeit der Kontinentalverschiebung Fahrt aufnehmen, und dann macht es mit 16K-DSL-Geschwindigkeit **sssst** und schon weiß man nicht mehr wo der Prozess ist, der einem da plötzlich zwischen den Fingern davongeflutscht ist. So muss moderne Telekommunikation funktionieren</ironie>.

Zustand: Warten auf Hardware, warten auf Nachbarn, warten auf neuen Montagetermin. Und hoffen, dass der zweite Anlauf Portierung nicht schon wieder danebengeht. Und im Alice Kundencenter ist der avisierte Termin erstmal wieder verschwunden.

Von einem, der auszog, Alice-Kunde zu werden I

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 03 Mar 2008 21:43:16 +0100

Dies ist die letzte Woche angekündigte Fortsetzung von Telefonieren - Mai 2007 bis Februar 2008. Da es sich um eine im Laufen befindliche unendliche Geschichte handelt, mit Nummerierung im Subject...

Alice hat - wie oben berichtet - im Mai innerhalb von angemessen kurzer Zeit geliefert. Außerdem ist Alice der einzige verbliebene Anbieter im Markt, der marktgerechte Preise ohne Knebelvertrag liefert. Mit 24 Monaten Mindestlaufzeit könnte ich ja notfalls noch leben, aber mit einer Verlängerung um 12 Monate eher nicht - ich mag einen Umzug nicht nach der Restlaufzeit meines Internetvertrags ansetzen müssen. Also fälle ich die Entscheidung, es nach sechs Monaten U doch mal mit der hübschen Alice zu probieren.

Der Zufall will es, dass ich Anfang November mit meinem Studienfreund Herrn Dr. H. aus W. am R. telefoniere und er mir nebenläufig erzählt, der Umstieg auf Alice stünde unmittelbar bevor: Man hätte inzwischen einen Umstelltermin für den 10. Dezember avisiert bekommen. Ich überhöre dieses Alarmzeichen und bitte Dr. H. um Bekanntgabe seiner Alice-Kundennummer, damit er mich als Alice-Neukunden werben kann. Die Ermittlung der Kundennummer dauert noch bis Ende November, so dass ich am 26. November endlich online den Auftrag zur Umstellung von U auf Alice zum 3. Januar 2008 erteilen kann.

Die Auftrags_eingangs_bestätigung kommt postwendend innerhalb weniger Minuten, und ein paar Tage später kommt ein vorausgefülltes Portierungsformular, das ausgedruckt, unterschrieben und zurückgefaxt werden will - was am 8. Dezember geschieht.

Die mit der Auftragseingangsbestätigung übersandten Zugangsdaten für das Webfrontend “Alice Lounge” funktionieren nicht, und die Hotline ist auch der Meinung, ich müsste mich mit dem Servicepasswort aus dem Mai und nicht mit dem aus dem November authentifizieren. Nachdem endlich die Zugangsdaten so weit gefixt sind, dass ich mich in der Lounge einloggen kann, kann ich zwar die Rechnungen von Mai bis August einsehen, finde aber keine Auskünfte über den Stand des zweiten Auftrags. Auch die Hotline behauptet in jedem Gespräch, dass mein Anschluß doch gekündigt sei und ich deswegen nicht mit einem Neuanschluss rechnen könne. Im zweiten Suchanlauf können die Agenten den neuen Auftrag dann jedoch trotzdem finden.

Bleibt noch das Problem, dass die übersandten Zugangsdaten gefährlich trivial sind, und ich der Aufforderung der Auftragseingangsbestätigung, das Passwort so schnell wie möglich zu ändern, nicht nachkommen kann, da die Funktion zur Änderung des Passworts in “meinem” etwas verwirrten Webfrontend nicht vorhanden ist.

Seit dem Fax des Portierungsformulars spielt die hübsche Alice die Analphabetin und rührt sich schriftlich nicht. Kurz vor Weihnachten rufe ich das erste Mal an der Hotline an und lasse mir mitteilen, man würde auf das ausgefüllte und zurückgefaxte Portierungsformular warten. Auf meine Auskunft, dass dieses Formular am 8. Dezember gefaxt wurde, wird erwidert, dass man auch etwas Zeit zur Bearbeitung des Formulars benötige.

Diese Telefonate wiederholen sich nahezu wortgleich im Wochentakt. Ende Januar wechselt die Aussage dann auf “Wir haben das Portierungsformular an U weitergeleitet und warten auf eine Reaktion.” Die mir zur Verfügung stehende Sonderhotline von U teilt mir “hintenrum” mit, dass das Portierungsformular von Alice am 29. Januar, also nach knapp sechs Wochen Bearbeitungszeit seitens Alice, eingegangen und die Portierung zum 29. Februar am 4. Februar bestätigt wurde. Damit sei der Prozess von seiten U abgeschlossen und man würde zum 29. Februar abschalten.

Die Alice-Hotline behauptet derweil beharrlich weiter, auf den Eingang der Portierungsbestätigung (also vermutlich eher deren Bearbeitung im eigenen Hause) zu warten.

Am 20. Februar geht mir langsam der Arsch auf Grundeis. Immerhin habe ich von meinem alten Anbieter die Auskunft, dass am 29. Februar abgeschaltet wird, und von meinem neuen Anbieter noch nicht einmal eine Auftragsbestätigung. Die Hotline von Alice darf diesmal etwas länger Rede und Antwort stehen, und die gesammelten Aussagen lassen sich reduzieren auf:

Ja, wir haben die Portierung für den 29. Februar 2008 an U beauftragt. Sobald die Bestätigung von U hier bei uns im Haus bearbeitet wurde, bestellen wir bei der Telekom die TAL, und sobald die Telekom den Schaltungstermin bestätigt hat, bekommen Sie eine Auftragsbestätigung mit dem voraussichtlichen Ausführungstermin. Das wird dann in etwa eine Woche vor dem wirklichen Ausführungstermin sein. Ja, übrigens, die Telekom ist im Moment sehr langsam und braucht von der TAL-Bestellung bis zur Ausführung derzeit etwa sechs bis acht Wochen. Oh, ja, das stimmt. Es kann passieren dass Ihr jetziges Telefon am 29. Februar abgeschaltet wird und wir dann erst im April oder Mai schalten.

Na das kann ja heiter werden. Offensichtlich sind Alices Prozesse darauf ausgelegt, dass die bestellte TAL möglichst keinen einzigen Tag ungenutzt bleibt, und dass die Telekom eine bestellte TAL in rudimentär realistischem Zeitrahmen liefert. Und Reibungsverluste auf dem Kunden hängen bleiben. Wie das bei Kunden funktionieren soll, die aufgrund ihres bestehenden Knebelvertrags dafür Sorge tragen müssen, dass die Kündigung in einem relativ engen Zeitfenster beim bisherigen Anbieter eingehen muss, die aber nicht selbst kündigen dürfen weil sonst die Portierung der Rufnummer(n) in die Binsen geht, bleibt mir völlig unklar.

Über die Spezialhotline von U konnte ich den Abschalttermin 29. Februar aus den Systemen entfernen lassen, und wenn ich diesen Artikel gleich noch veröffentlichen kann, hat das auch geklappt.

Wir warten also weiter darauf, dass Alice endlich kapiert, dass da ein Prozess entgleist ist, und lassen uns jede Woche weiterhin durch die Blume sagen, was Amerikaner schon in den 1970ern in “Saturday Night Live” gelernt haben: We don’t care. We’re a phone company. We don’t have to.

Bei Dr. H. hat die Umstellung übrigens abgesehen von der langen Bereitstellungszeit reibungslos mit weniger als einem Tag Ausfall geklappt. Hallelujah.

Telefonnummern?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 27 Feb 2008 13:23:18 +0100

Ralf Hildebrandt fragt in einem Kommentar zu diesem Artikel, warum ich zehn Rufnummern gehabt habe. Ich versuch das mal zu erklären.

Zehn Rufnummern habe ich eigentlich schon seit WG-Zeiten. In einer Dreier-WG ist das auch ganz praktisch, und ich habe das dann beibehalten, als ich in eine eigene Wohnung gezogen bin. Die Nummern waren damals so aufgeteilt:

steht im Telefonbuch, Anrufer landen direkt auf dem Anrufbeantworter ohne dass überhaupt ein Telefon klingelt
Ist die Nummer, die ich “normalerweise” benutze: Nicht veröffentlicht, Telefon klingelt, nach sechsmal klingeln kommt der Anrufbeantworter
Ist die Nummer für VIPs: Telefon klingelt auch im Schlafzimmer, kein Anrufbeantworter
Die “normale” Nummer für Firmendinge: Klingelt nur im Arbeitszimmer
Die “Notfallnummer” für Firmendinge: Klingelt auch im Schlafzimmer
Temporäre Nummer für Kleinanzeigen etc, ist normalerweise komplett abgeschaltet
Faxmodem, und wenn das nicht funktioniert, das Faxgerät
direkt das Faxgerät für Faxe, die auf jeden Fall auf Papier rauskommen sollen

Damit sind acht Nummern sinnvoll verwendet. Und da zehn auch nicht mehr gekostet haben als acht, waren es halt zehn. Damals[tm] war es bei T so, dass die Bereitstellung weiterer Nummern zusammen mit dem Anschluß kostenlos war und die weiteren Nummern auch keine monatliche Grundgebühr gekostet haben, die nachträgliche Hinzunahme weiterer Nummern aber kostenpflichtig war. Da hat man also zusammen mit dem Anschluß das Maximum geordert und ggf. dann halt nicht benutzt.

Inzwischen sind Faxgerät und Faxmodem durch Arcor PIA ersetzt, es gibt VoIP, und ich habe gelernt, dass man die Nummern, die einmal zusammen auf einem ISDN-Anschluß waren, nicht wirklich einfach wieder auseinander bekommt. Deswegen wurden beim Umzug im Jahr 2007 von den ehemals zehn Rufnummern nur fünf von T zu U umgezogen (was auch daran liegt, dass U für “mehr Rufnummern” monatlich Geld sehen will).

Und, genug Erklärung?

Telefonieren - von Mai 2007 bis Februar 2008

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 26 Feb 2008 22:26:43 +0100

Wie schon neulich beschrieben, ist die Rufnummernportierung zu einem anderen Anbieter bei gleichzeitigem Umzug in Deutschland nicht vorgesehen und erfordert ein Reihe Klimmzüge.

In diesem Artikel beschreibe ich, wie die Telefon- und Internetanbindung meiner Wohnung in den letzten Monaten realisiert war.

In meiner alten Wohnung war die Telekommunikation verhältnismäßig konservativ aufgestellt: T-ISDN, T-DSL 3000 und IP mit statischem /28-Netz und Volumenabrechnung aus dem Rahmenvertrag der Firma. Das statische /28 hat seine Existenzberechtigung verloren, weil ich ein paar Monate zuvor meine Server von “echter Hardware im Multifunktionszimmer” auf “Mietserver bei verschiedenen Anbietern” umgestellt hatte und ich durch die viele Zeit bei Sandra gelernt hatte, dass ich für den reinen Client-Betrieb unter Verwendung von OpenVPN keine statischen IP-Adressen daheim mehr brauche. Also kann es in der neuen, gemeinsamen Wohnung ein Consumer-Zugang mit dynamischer IP von der Stange sein.

Genau zur rechten Zeit, Anfang April, kommt mir zu Ohren, dass Anbieter U ein gut verstecktes, nur einer geschlossenen Benutzergruppe zugängliches Angebot macht: Sechs Monate DSL 16000 und Telefonie mit Doppelflat für unter fünf Euro Grundgebühr, danach entweder Ausstieg oder 24 Monatsvertrag zu einem nicht konkurrenzfähigen Preis. Ich entscheide mich, das Risiko einzugehen und lasse mich in die geschlossene Benutzergruppe aufnehmen. U soll hier aus offensichtlichen Gründen anonym bleiben.

Ich erteile also Mitte April den Auftrag für das Produkt und die Portierung von fünf meiner zehn T-Rufnummern. Schon zwei Wochen später kommt die Nachricht “Portierung abgelehnt”. Nur zwei Telefonate später weiß ich auch wieso. Die Rufnummern sind derzeit an einer anderen Adresse geschaltet als wo der Neuanschluss hin soll. Das sehen die Prozesse von U nicht vor. Abhilfe: Ich soll mir den Anschluß erstmal an der alten Adresse schalten lassen und dann erst umziehen.

Das kommt aber aus terminlichen Gründen nicht in Frage. So kommt Plan B zum Preis einer Telekom-Einrichtungsgebühr zum Zuge: Das T-ISDN zieht mitsamt den Rufnummern um und wird dann sofort wieder gekündigt. Da ich nun den neuen Portierungsauftrag erst erteilen kann, wenn das T-ISDN umgezogen ist, ich die hundert Euro Einrichtungsgebühr für ein kurzfristig kündbares T-DSL nicht zahlen mag und ich allerdings auch wenig Lust darauf habe, einige Wochen ohne breitbandigen Internetzugang zu sein, kommt hier die schöne Alice zum ersten Mal ins Spiel: Sie darf für die Übergangszeit Internet liefern.

Die Telekom kriegt den Umzug des T-ISDN innerhalb von sieben Werktagen nach Erteilung des Online-Auftrags hin; Alice braucht mit zehn Werktagen bis zum ersten Installationsversuch etwas länger, ist aber noch im grünen Bereich. Dass der erste Alice-Installationsversuch in die Hose geht, ist meine Schuld, denn ich erwische die Nachbarn mit dem Schlüssel zum Heizraum, in dem auch der Telekom-Übergabepunkt montiert ist, nicht rechtzeitig und der Techniker muss unverrichteter Dinge wieder abziehen.

Hier merkt man schon, dass man als Kunde eines Nichttelekomanbieters im Servicefall die Arschkarte gezogen hat: Für ein T-ISDN oder ein analoges T-Net wäre der Techniker später am gleichen Tag oder am nächsten Tag nochmal wiedergekommen; für Alice muss ein neuer Auftrag erteilt werden, das dauert mindestens vier Werktage.

Sofort nach der Installation des T-ISDN erteile ich den Auftrag an U, der diesmal durchgeht. U bestätigt und nennt einen Liefertermin im Juli. Fünf Wochen Realisierungszeit ist nicht berauschend, aber wir sind ja mit T und Alice versorgt.

Im Juli wird dann schliesslich von T zu U umgeschaltet. U liefert seine Telefonie als Next Generation Network (NGN) und stellt deswegen ein Endgerät zur Verfügung, das als Router für WLAN und kabelgebundenes Netz und als Telefonübergabegerät mit zwei a/b-Ports und einem S0-Bus dienen kann.

Die Migration geschieht ohne Technikerbesuch und unter Weiterverwendung der vorher für das T-ISDN geschalteten TAL: Man ersetzt zum gemeldeten Zeitpunkt Mittags den NTBA durch das NGN-Gerät von U und ist nach anderthalb Stunden Downtime mit Telefon und Internet online. So soll es sein, reibungslos und prima.

Leider funktioniert das NGN-Gerät von U leider anfänglich nicht so wie eigentlich geplant, so dass ich darüber nachdenke, U vorzeitig zu verlassen und die Nummen gleich weiter zu Alice zu schieben. Das aber geben die Prozesse von Alice nicht her: Man kann keine Rufnummern auf einen bereits bestehenden Anschluß portieren. Für diese Auskunft braucht man zwei Wochen, in denen sich das Produkt von U durch mehrfache Firmwareupdates deutlich verbessert. Ich entschließe mich, die sechs Monate bei U weiterlaufen zu lassen; der Preis ist umwerfend. Die Alice-DSL ist somit nicht mehr notwendig und Alice fängt sich eine Kündigung zu “Ende August”.

Im November kommt mir die Sache wieder auf den Tisch, denn Ende Januar 2008 läuft die Vergünstigung von U ab, und so ganz hundertprozentig funktioniert das Produkt von U immer noch nicht. Wenn auch die akutesten und nervigsten Bugs inzwischen umschifft werden konnten, will das NGN-Gerät immer noch ein bis zweimal in der Woche resettet werden. Unter diesen Umständen einen 24-Monats-Vertrag zu einem eher unattraktiven Preis einzugehen, ist keine Alternative.

Und was dann passiert ist, blogge ich ein andermal.