As some of you might know, I’m not only a supporter of IP Everywhere (and a net addict), I’m as well a notorious user of IP anywhere – see my

Me :-)

Avatar on twitter, facebook, … As I’m usually at least once per month doing standby for the services we run at my employer’s place, I depend on access — and I prefer to have it rather reliable anywhere, if possible.
I do travel by train a lot these days, twice per week Güterloh – Berlin – Gütersloh, which takles about 3 hours per trip.

a bit bulky, my prototype

And since Deutsche Bahn as of now neglected the need of buisiness people in regards of Internet connectivity between Köln and Berlin (which is the relation of the trains I take), I’m stuck with trying to get GSM signals while speeding at up to 250 km/h trough what I’d call a diaspora of mobile Internet. While the ICE is equipped with GSM repeaters (not really sure if they actually work with UMTS’ frequencies as well) that cater at least for the networks of Deutsche Telekom (»D1«) and Vodafone (»D2«), GSM towers between Hannover and Berlin seem to be even less frequent than between Bielefeld and Hannover, where connectivity sometimes already is an issue.
I always thought about lining my access to D1 and D2 and maybe even o2 together to form a »best effort« access, regardless of the underlying network; just recently, @homofaber voiced a request for something similar on twitter, and I wrote down my ideas on that.

about twenty minutes OLSR doing it’s magic.

I am using OLSR for years now to link my home base(s) to the Internet, running OLSR on top of (Open)VPN links. OLRD was made for lossy wireless networks, recalculating the next hop based on a contemporary per-node view of the whole (mesh) network — constantly, based on active probes. But as any two nodes linked by more than one path can be seen as a tiny mesh, I still think this combination is quite cool — and it works well for quite some years now on backing up my main DSL connection. And as I recently got hold of two TP-Link MR-3020, cheap (<30,– EUR), OpenWRT-capable and USB-powered »3G Accesspoints« (which lack actual 3G hardware but expect that to be added via USB), I started this little project …
Last Friday I got the prototype going, which as of now consists of:

• 1 MR3020 as 3G-OpenVPN-Router
• 1 TL-WN821N USB-WiFi stick
• 1 MR3020 as Access Point, wired to the first one
• 2 Huawei E585 mobile 3G hotspots with SIMs for D1/D2
• 1 battery with USB-outputs as a power supply (»EVOPower Black 2 USB Port Compact External Portable Rechargeable Emergency Backup Battery Charger (5000mAh)« off Amazon.com for 30 USD)

All in all, the equipment used is 60,– (2x MR3020) plus 10,– (TL-WN821N) plus 30,– (USB battery) plus 240,– (2x E585),

5% packet loss between Hannover and Bielefeld isn’t that bad/:-)

i. e. about 340,– EUR for a dynamic routing dual-uplink mobile accesspoint. Oops, not as cheap as planned :-)
So, why this setup? Well, the flash on the 3020 is tight; OpenVPN and support for 3G modems don’t fit into the available space with stock OpenWRT images, and I’m not sure if that can be changed by using a customized version of it. But the 3020 is one of the few hackable devices I know of that are run off USB power — and for mobile use, that 5000 mAh battery supplying 5V USB at up to 700 mA is rather nice. Since I already had the mobile 3G hotspots (one from my employer, one – actually, two – purchased by myself) and use them for standby duty already, utilizing them seemed to be a straight forward approach (even if that means I need 2 USB-chargers for Micro-USB and one for Mini-USB – the battery and the MR3020 use Mini – to power/charge the whole bunch). The WiFi-stick is needed as the Atheros radio/it’s current Linux drivers can’t do multipe times STA (station mode); in theory it at least should be capable of doing once STA and multiple times AP (access point mode), and previously, with the »madwifi« drivers for Atheros it actually worked. But for me, it did not work with bleeding edge OpenWRT »Attitude Adjustment« and »mac80211« at all, that’s why I use another MR3020, connected by a ethernet cable to the first, as the access point … I tried an unpowered USB hub and two TL-WN821N, but that’s too much for the 3020, it will just drop, reconnect, drop that hub and it’s devices. Haven’t found an USB-powered USB hub yet – and I don’t have spare sockets on my USB battery either.
So, while it works, it’s a bit experimental,

Not the optimal setup yet.

best to hide it in your backpack instead of lodging it onto the table in the train :-) As for 5% packetloss between Hannover and Bielefeld (about 100 km), this might be a bot too good, as the AP 3020 is actually using a OpenVPN-over-TCP tunnel — I initially set it up as an AP to run virtually anywhere after plugging it onto any network (trying proxies and using the HTTPS port in general). Thus, some of the packets might got redelivered via TCP-retransmissions of OpenVPN paylload; I’ll reconfigure it to use plain UDP.

Data usage shows that both 3G links were utilized.

I’m currently looking into using a Seagte Dockstar instead of both 3020, using either 3 WiFi sticks to create one AP and two STA devices or even go to one WiFi and two/three 3G/4G USB modems; funnily enough, you can power up a Dockstar by providing USB power instead of connecting in it’s 12V 2A power supply. Not sure what happens when using multiple USB devices; but the Dockstar ad least has enough flash (and RAM) for a more sophisticated setup :-)
So, whatch this space for future updates; I’d love to see how LTE would work here, especially since at least with D1, you shall be able to connect to urban 800 MHz LTE rollouts (where LTE is used instead of DSL) now, which might be better accessible from the ICE that the UMTS rollouts. So, anyone out there wanting to sponsor an LTE stick (or lend it for 4-8 weeks), please drop me a line :-)

Fritz!OS (Fritz!Box-Firmware ab Version 5) bietet GSM-Voice per USB-Stick …

So, nachdem AVM die 7270 noch mit einer Labor-Firmware von »Fritz!OS« bedenkt – die nahezu baugleiche 7570 aber zum Alteisen stempelt (und alle so: »Schämt Euch!«) –, habe ich mal meine 3,6/0,38-Sticks (Huawei E210, E160, E1550) durch 7,2/5,8 MBit-fähige Sticks (E1750C) ersetzt und mit der Voice-Option rumgespielt.
Ja. Schon cool. Ich könnte jetzt mein Fritz!Box-Netzwerk so konfigurieren, daß Mobilfunkanrufe über diese Box mit FONIC-SIM rausgehen bzw. in GT als auch in B einen solchen stecken — erst nach dem Bucht-Kauf weiterer 7270er allerdings, denn AVM unterstützt die jüngere 7570, von der ich drei Boxen habe, ja nicht mehr.
9 Cent pro Minute ist günstiger als die deutlich über 10 Cent/Minute liegenden Tarife von sowohl Telekom als auch Alice. (Und bevor wieder jemand mosert: einen AGB-Verstoß (»unentgeltliche Überlassung an Dritte«) sehe ich nicht – der ganze Kram wird von einem, meinem, Konto gespeist, insofern ist meine Familie kein »Dritter« im rechtlichen Sinn; es sind (legitime) Nutzer meines Telefoniesetups.)
Allerdings sind 9 Cent/Minute brutto 155% der 5,8 Cent/Minute (inkl. Schäuble-Abgabe MwSt), die localphone.com verlangt (siehe Kommentare). Ich denke, ich werde den Anbieter mal parallel austesten …

Jüngst habe ich ja mich positiv zu den Fritz!Box-Geräten von AVM geäußert, heute muß relativieren:

heute bekam ich folgende Info von AVM:
“für die FRITZ!Box 7570 ist kein weiteres Update geplant.”

Quelle: Posting vom 18.01.2012 im IP-Phone-Forum

 
Tja, großes Kino; AVM hat bei der 7390 massiv verkackt, weshalb »in Fachkreisen« (zumindest in den einschlägigen Gruppen) die 7570 für VDSL noch immer empfohlen wird. Technisch ist die 7570 ( bzw. der Speedport W920V) »eine “Seitenentwicklung” der 7270 V2 die im Januar 2009 als “vorerst nicht für den Fachhandel” vorgestellt wurde«, konkret ein »Derivat der 7270 in das zusätzlich der VDSL-Teil des Speedport 300HS Modems integriert wurde«. Somit perfekt für mich, der bislang das VDSL-Modem Speedport 300 HS und ein 7270-Derivat am Start hatte.
Ich besitze nun zwei 7570 und einen W902V – und stelle fest, daß AVM dieses Gerät, welches anders als die 7390 auch 100 MBit/sec-VDSL-Anschlüsse bedienen kann (mit Tricks), nun zu Alteisen deklariert hat. Im Grunde wäre das nicht weiter tragisch, denn die Community hat sich schon früh mit dem Speed2Fritz-Projekt hervorgetan, welches »Firmwarecompsitions« ermöglicht: So kann z. B. ein Spedport W503V auf Basis der 72×0-Firmware aufgebrezelt werden zu einer (teils abgespeckten) »SpeedBox« 72×0 – aber dafür muß die Basishardware komplett unterstützt sein, und für den VDSL-Modem-Part der 7570 hat AVM die Produktpflege schmählich vernachlässigt :-(
Um es nochmal klar zu sagen:

Obwohl die Modelle 3370, 7340, 7360 und 7390 für Übertragungsraten bis zu 100 Mbit/s beworben werden unterstützt *bisher* laut Abschnitt 2 dieses AVM-FAQ Eintrags keins dieser Modelle die 100 MBit/s VDSL-Profile der Anbieter Wilhelm.tel, M-Net, NetAachen und NetCologne. Dies erklärt die Nutzung der 7570 an vielen dieser Anschlüsse, bzw. ein externes Modem.

Quelle: AVM Wiki

 
Es wäre auch nicht so schlimm, würde es sich um einen Speedport handeln, also ein für die Telekom auftragsgefertigtes Produkt; aber die 7570 ist eine offizielle AVM-Box, und sie wird von den ganzen schönen Neuerungen wie diesen ausgeschlossen (Quelle: Firmwareübersicht 7270):

Und obwohl die 7270 zwei Jahre älter ist als die 7570, wird für jene noch entwickelt; insbesondere AVMs Antwortversuch auf Personal-Cloud-Dienste wie Pogoplug und Co., MyFRITZ!, stünde auch der 7570 gut zu Gesicht. Aufgrund der Produktnähe zwischen 7270 V2 und 7570 ist mir diese Produktpolitik jedenfalls vollkommen unverständlich :-(
(Nachtrag: In die Reihe der Probleme reiht sich nun auch noch ein Zeitzonen-Bug:

Temporäre Falschdarstellung der Uhrzeit bei FRITZ!Fon-DECT-Handgeräten
Aufgrund einer seltenen Datumskonstellation im März 2012 kommt es bei FRITZ!Fon-Geräten vom 25.3. bis 1.4.2012 zu einer temporären Uhrzeit-Fehlanzeige. Die Uhrzeit wird während dieser Woche weiterhin als Winterzeit angezeigt, das heißt um exakt eine Stunde verschoben, beispielsweise 11:00 anstelle der korrekten Angabe 12:00 Uhr. Ebenfalls betroffen sind die Weckzeit sowie die WLAN-Nachtschaltung. Dies gilt nicht für alle sonstigen mit der FRITZ!Box verbundenen Geräte wie PCs, Laptops, Smartphones oder Fernseher.
Ab Sonntag, den 1.4.2012, wird automatisch wieder die korrekte Uhrzeit angezeigt. Ein manueller Eingriff in die Zeitdarstellung ist nicht möglich. Für eventuell entstandene Unannehmlichkeiten bitten wir um Entschuldigung.

 
Sprich: für eine Woche sind alle zeitabhängigen Fritz!-Box-Funktionen unbrauchbar, und die Reaktion des Unternehmens ist: »*achselzuck* Oops, sorry.«. Großes Kino, wie gesagt.)

Szizze des finalen Aufbaus

Es ist ja schon ein paar Sonnenumrundungen her, daß ich mich mit dem Voice-Geraffel auseinandersetze.
Mittlerweile bin ich dazu übergegangen, wo möglich, eine AVM Fritzbox (ggf. als Speedport-Version mit AVMisierter Oberfläche) als DSL-Abschluß laufen zu lassen (wenn nicht direkt DSL, so doch zumindest PPPoE sollte dort terminieren), ebenso das lokale Festnetz sollte dort aufschlagen. Die Dinger (ich kann nur für die 71er und 72er Serie sprechen) sind enorm vielseitig und so stabil, wie es sich für ein IAD gehört.
Mit Asterisk mache ich aktiv derzeit nichts, denn bislang – nachdem ich mich zu einem generischen Netzwerksetup durchgerungen habe – decken die Fritzboxen alle Kommunikationsbedürfnisse und Konfigurationswünschen (irgendwie) ab.
Was derzeit funktioniert: Anrufe an ein Berliner Festnetznummer (MSN) werden über das IPSec zwischen meinen Fritzboxen weitergeleitet, kommen als Anrufe auf lokalen Gütersloher MSNs an. Genauso kann ich vom Berliner S0 auf einer Güterloher MSN anrufen, auch das liefe über SIP (mit Vorwahl liefe es via Festnetz). Hierzu ist die FB in Gütersloh am SIP-Registrar der Berliner FB angemeldet und hat als »Internetrufnumer« eine lokale Gütersloher MSN. Die Gütersloher MSNs sind in den »Wahlregeln« in Berlin auf die SIP-Verbindung aus GT geroutet.
Außerdem kann ich derzeit per *121#-Präfix von Berlin aus über Gütersloh rauswählen bzw. von Gütersloh über Berlin. Ist primär »lustig«, denn in Zeiten von Festnetz-Flatrates bei den DSL-Zugängen ist da kein Sparpotential da. Wo ich aber evtl. sparen kann ist bei Anrufen ins Mobilfunknetz – ich habe eine FONIC-SIM in einem E160, der per Firmwareupdate nun auch sprachfähig ist. Und eine Labor-Firmware für die 7270 soll jetzt die Nutzung eines UMTS-Sticks für Voice & Data ermöglichen – klingt nach Routing von Mobilfunknummern darüber, denn 9 Cent/Minute in alle Netze ist billiger als die Tarife von DTAG oder Alice. Einziger Wermutstropfen: meine auf der 7270 basierenden W920V / 7570 werden wahrscheinlich außen vor bleiben, denn diese Feature gibt es nur für die 5er Firmwareversionen (xx.05.yy). Außer der 7570, die AVM schon heute nur saumäßig unterstützt – in der letzten Firmware war nicht einmal der SIP-Registrar drin, den die 72er und auch die 71er schon lange haben – hat m. W. keine andere aktuelle AVM-Box diesen ADSL/VDSL-Chip drin, und die Telekom und AVM scheinen sich nicht mehr grün, sodaß kaum eine 5er Firmware für den Speedport W920V zu erwarten ist (wäre sie auch sonst nicht; einige der Features der AVM-Firmware sind ja grundsätzlich nie in der Speedport-Firmware nutzbar gewesen), jedenfalls war der Unterschied des Leistungsumfanges auf der 71er Plattform immens).

Das saugt. Wie geplant hatte ich grade den Spedport 300 HS mit 1.07er Firmware und Dauer-Debugmodus angeschlossen (so wie der erste 300 HS auch all die Jahre lief), und die VDSL-Raten waren nochmals deutlisch schlechter als bei der 7570 – ich paste hier mal die Rohdaten, vielleicht versteht das ja jemand:

/ # /ifx/vdsl2/dsl_pipe g997csg 0 0 0 # current upstream
nReturn=0 nLine=0 nChannel=0 nDirection=0 ActualDataRate=2216000 PreviousDataRate=0 ActualInterleaveDelay=700 ActualImpulseNoiseProtection=4
/ # /ifx/vdsl2/dsl_pipe g997csg 0 0 1 # current downstream
nReturn=0 nLine=0 nChannel=0 nDirection=1 ActualDataRate=19224000 PreviousDataRate=0 ActualInterleaveDelay=700 ActualImpulseNoiseProtection=4
/ # /ifx/vdsl2/dsl_pipe g997lsg 0 0 # capacity upstream
nReturn=0 nLine=0 nDirection=0 LATN[0]=102 LATN[1]=454 LATN[2]=-32768 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=102 SATN[1]=446 SATN[2]=-32768 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=59 SNR[1]=67 SNR[2]=-32768 SNR[3]=-32768 SNR[4]=-32768 ATTNDR=2378144 ACTPS=0 ACTATP=43
/ # /ifx/vdsl2/dsl_pipe g997lsg 0 1 # capacity downstream
nReturn=0 nLine=0 nDirection=1 LATN[0]=203 LATN[1]=560 LATN[2]=-32768 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=203 SATN[1]=555 SATN[2]=-32768 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=61 SNR[1]=61 SNR[2]=-32768 SNR[3]=-32768 SNR[4]=-32768 ATTNDR=22024000 ACTPS=0 ACTATP=131
# Resync erzwungen durch Modem-Abschaltung ("line de-/activation")
/ # /ifx/vdsl2/dsl_pipe g997csg 0 0 1 # current downstream
nReturn=0 nLine=0 nChannel=0 nDirection=1 ActualDataRate=19084000 PreviousDataRate=19224000 ActualInterleaveDelay=700 ActualImpulseNoiseProtection=4
# Resync erzwungen durch Modem-Abschaltung ("line de-/activation")
/ # /ifx/vdsl2/dsl_pipe g997csg 0 0 1 # current downstream
nReturn=0 nLine=0 nChannel=0 nDirection=1 ActualDataRate=18532000 PreviousDataRate=19084000 ActualInterleaveDelay=700 ActualImpulseNoiseProtection=4
# Reboot des Speedport 300 HS
/ # /ifx/vdsl2/dsl_pipe g997csg 0 0 0 # current upstream
nReturn=0 nLine=0 nChannel=0 nDirection=0 ActualDataRate=2200000 PreviousDataRate=0 ActualInterleaveDelay=800 ActualImpulseNoiseProtection=4
/ # /ifx/vdsl2/dsl_pipe g997csg 0 0 1 # current downstream
nReturn=0 nLine=0 nChannel=0 nDirection=1 ActualDataRate=18040000 PreviousDataRate=0 ActualInterleaveDelay=700 ActualImpulseNoiseProtection=4
/ # /ifx/vdsl2/dsl_pipe g997lsg 0 0 # capacity upstream
nReturn=0 nLine=0 nDirection=0 LATN[0]=102 LATN[1]=454 LATN[2]=-32768 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=102 SATN[1]=446 SATN[2]=-32768 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=62 SNR[1]=64 SNR[2]=-32768 SNR[3]=-32768 SNR[4]=-32768 ATTNDR=2355728 ACTPS=0 ACTATP=43
/ # /ifx/vdsl2/dsl_pipe g997lsg 0 1 # current downstream
nReturn=0 nLine=0 nDirection=1 LATN[0]=204 LATN[1]=562 LATN[2]=-32768 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=204 SATN[1]=556 SATN[2]=-32768 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=59 SNR[1]=59 SNR[2]=-32768 SNR[3]=-32768 SNR[4]=-32768 ATTNDR=20672000 ACTPS=0 ACTATP=131

Nachdem ich bei 18 MBit/sec im Downstream angekommen war, habe ich das Experiment Speedport 300 HS an Fritzbox 7570 abgebrochen und habe, das dünne VDSL-Anschlußdrähtchen gegen ein Cat. 5e-Kabel tauschend – just in case –, die 7570 wieder inkl. Modem benutzt. In tabellarischer Form also:

7570 08h
300HS 1.
300HS 2.
300HS 3.
300HS 4.
7570 20h


Down-/Upstream


DSLAM-Datenrate Max.
kBit/s
0/0
 
 
 
 
0/0


DSLAM-Datenrate Min.
kBit/s
0/0
 
 
 
 
0/0


Leitungskapazität
kBit/s
22263 / 2314
22024 / 2378


20672 / 2355
21260 / 2374


Aktuelle Datenrate
kBit/s
22088 / 2144
19224 / 2216
19084 / ?
18532 / ?
18040 / 2200
21136 / 2208


 




Störabstandsmarge
dB
6/6




6/6


Leitungsdämpfung
dB
23/9




23/9

Frequenzspektrum aus Sicht der 7570

Man sieht, daß mehr als rd. 22 MBit/sec im Down- und 2,2 MBit/sec im Upstream nicht mehr drin sind. Nun frage ich mich allerdings, warum? Drei MBit/sec im Downstream zu verlieren tut schon weh, zumal 31892/3216 vor rd. 5 Jahren noch erreichbar waren und auch nach der Reparatur des Straßenbaukollateralschadens 2009 noch angezeigt wurden (effektiv waren die Werte sogar in beide Richtungen etwas besser als vorher).
Die Graphen der 7570 (mit 7270-basierter Firmware (speed2fritz)) zeigt folgendes: Spektrum, DSL-Info, Übersicht. Die Werte vom Speedport 300 HS aus 2008 sind hier verlinkt. Leider habe ich zwischenzeitlich – es lief ja – das Monitoring/Plotting der Leitungsdaten aufgegeben …
Wäre es nicht wg. T-Entertain, würde ich aufgrund des nur noch geringen Unterschiedes ja auf mehrere 16 MBit-Sec-Anschlüsse setzen, was (ohne Telefonie-Flatrate-Gedöns) günstiger kommen dürfte — nur auf Entertain müßte ich dann (oder vielmehr meine Familie; ich hätte ja noch meine VDR-Armada :-)) verzichten, denn vom Preislichen abgesehen, 16 MBit/sec sind mir zuwenig für Surfen & Fernsehen …
Any ideas, was der Grund sein könnte und was ich tun kann, um die Leitung wieder »sauberzupusten«?

Hmm.

Mein (mittlerweile) 2. Speedport 300 HS und der W503V wurden ersetzt durch eine Fritzbox 7570 VDSL …

Im Zuge des Kehraus in der heimischen IT wollte ich wieder einmal zwei Geräte durch eines ersetzen. Aber irgendwie läuft das alles nicht so, wie ich es gerne hätte. 2007 mit 25088/2740 kbps gestartet, nennt die 7570 jetzt läppische 22740/2144 kBit/s, nach Resync nur noch 22088/2144 kBit/s bzw. 22200/2240 kbit/s, als synchronisierte verfügbare Bandbreite. Eigentlich hatte ich mir gleichbleibende, wenn nicht bessere, Performance erhofft, denn der (erste) Speedport 300 HS nannte noch >30000/>2700 kBit/sec als erreichbar – die 7570 hingegen sagt:

Da die Verluste doch signifikant sind, werde ich nachher mal wieder die alte Konstellation reaktivieren und die Sync-Raten beobachten :-( Sonderbar ist, daß, da die Fritzbox 7570 eigentlich eine 7270 mit integriertem Speedport 300 HS-VDSL-Modem ist – und somit quasi die Verschmelzung der beiden vormalseingesetzten Geräte –, doch ein so deutlicher Leistungsabfall zu sehen ist. Allerdings habe ich leider keine aktuellen Werte vom vormals eingesetzten Speedport 300 HS, da jener mit Orginalsoftware ausgerüstet und somit nicht abfragbar war. Also heißt es gepatchte Firmware installieren und Monitoring-Script reaktivieren …
Weder Deutsche Telekom noch 1&1 mögen hier, wo VDSL-25 liegt (und mal sogar knapp 50-tauglich war (allerunterste Grenze, was bei Preisgleichheit mich ja nicht störte; jedes kBit/sec zählt)), anbieten. Aber wahrscheinlich muß ich glücklich sein, denn o2 sagt:

Sie können voraussichtlich eine Übertragungsgeschwindigkeit von 6001 kbit/s bis 12000 kbit/s erreichen.

 
Keine Ahnung, was die getrunken haben; die Telefónica-Leitung käme aus dem gleichen Gebäude wie mein VDSL, und vor VDSL hatte ich ja T-DSL 16000 ohne Probleme …

Vor gut einer Woche hörte in GT das ISDN auf, zu funktionieren. Das hatte es in der Vergangenheit immer mal wieder gemacht und schließlich habe ich dann Fritzboxen getauscht, ISDN-Verkabelung durchgemessen und selbts das ISDN-Telefon zum NTBA getragen – aber ISDn spielen, das wollte es nicht. Da es hinter einer Fritzbox allerdings, an deren internem S0, zu funktionieren schien und auch eine Rauswahl über eine FB-FB-Kopplung via Berlin möglich war, entschloß ich mich Sonntag abend, ein Ticket aufzumachen mit der Bitte um Ersatz-NTBA.
Damit die Familie nicht völlig ohne (Festnetz-) Telefonie da saß die Woche über, zimmerte ich noch schnell eine Weiterleitung von einer meiner Berliner MSNs an der dortigen Fritzbox per SIP und den IPSec-Tunnel zwischen den Fritzboxen auf die FB in Gütersloh, an der die Gigaset hängt. Ferner kam eine zweite SIP-Verbindung zum Tragen, über die von GT aus über B ins Festnetz telefoniert werden konnte. Da man bei einer Störung seine Festnetznummern nur für die Dauer der Störung gesondert umleiten lassen kann – ein sehr kundenfreundliches Feature, ich war positiv überrascht –, habe ich davon Gebrauch gemacht und die beiden Haupt-MSNs nach GT umgeleitet. Bis auf einen anderen Klingelton und die Notwendigkeit, 05241 für Ortsgesrpäche nach GT vorzuwählen – ok, und die Berliner Rufnummer, die die Angerufenen sahen, die sie aber auch zurückrufen konnten ;) –, beides auf mitternächtlichen Knowledgemangel zu schieben (heute kann ich’s »richtig« ;)), tat das ganz gut für die ersten paar Tage.
Problem 1: Das Telekom-Callcenter rief statt mich auf der hinterlegten Mobilnummer auf unseren heimischen Rufnummern an. Kluge Idee bei der Meldung eines ISDN-Totalausfalls – Manko Nummer eins und zwei.
Da die Anruferin jemanden auf der Rufnummer, die gestört gemeldet war, erreicht hatte, insistiere sie erst einmal darauf, daß keine Störung vorläge, so berichtete mir meine Frau – mich hat man ja grade nicht angerufen, und meine Frau konnte nur mühsam erklären, daß ich »gemacht hätte, über Rufumleitung oder so, daß das Telefon hier noch geht«.
Man konnte sich dann wohl aber darauif einigen, daß ein NTBA zugeschickt würde zum Selbstaustausch, er müßte so Mittwoch eintreffen.
Das führte aber dann zu Problem 2: mit der in die Wege geleiteten Zusendung stellte man das Ticket auf »erledigt« – gut für die KPI (MTTR), schlecht für den Kundenservice, denn, wir erinnern uns: die Rufumleitugen waren nur für die Dauer der Störung eingerichtet. Und so kamen auch tapfer die SMS, daß a) die Störung behoben sei und b) die Rufumleitung MSN 1 sowie c) die Rufumleitung MSN 2 nun wieder aufgehoben seien. Und GT war wieder telefonich nicht erreichbar.
Hier fehlt es klar an besserer Prozeßsteuerung – eine Störung darf erst dann final beendet werden, wenn der Kunde die Behebung bestätigt (oder diese angeforderte Bestätigung nach 1-2 (Arbeits-)Tagen ausbleibt). Anderenfalls greifen die kundenseitig getroffenen Linderungsmaßnahmen wenig :-(
Ich versuchte dann eine Wiedereröffnung per Twitter – was nur partiell gelang (ich bekam weder eine SMS über die Wiedereröffnung noch taten die Rufumleitungen wieder):

@Telekom_hilft Können Sie ein Ticket wiedereröffnen? Details siehe bit.ly/A6iZvH – das ist einfach trotz Fehler geschlossen worden :(

— wusel (@wusel) March 12, 2012

@wusel Na klar, ich gebe das Ticket noch mal an die Kollegen vom Außendienst. ^wi

— Telekom hilft (@Telekom_hilft) March 12, 2012

@Telekom_hilft FYI: Da in den letzten 3 Std. keine Wiedereröffnung erfolgte, habe ich die Störung erneut gemeldet …

— wusel (@wusel) March 12, 2012

[capimg=http://blogdoch.net/images/posterous-422417258.jpg.scaled1000-2_thumb.png">Meine Störung war auf dem fast-track for closure …