Was ein Sch…..

Also es ist nun schon einige Wochen her. Da gab es richtig Probleme mit der Anlage die ich hier beschreiben wollte. Auch daher die Verspätungen.

Was ist passiert?

Die Anlage wurde planmäßig installiert und in Betrieb genommen. Das waren so ca. 50 Telefone, 25 Analoge Nebenstellen (Faxe und DECT Telefone). Das ganze gepaart mit einer Queue und tollen Funktionen im Dialplan. Alle Tests waren erfolgreich und es sah super aus.

Die Anlage war also in Betrieb. Dann kam ein Elektriker. Der wollte einen Supertollen Umschalter im Rechenzentrum fertig installieren (Neubau). Ganz ohne dass der Strom ausfällt – versprochen Also alle Server eingeschaltet gelassen. Passiert doch nix. Aber dann … wie von Geisterhand … auf einmal …. Dunkelheit … und diese Ruhe. Huch. Strom doch weg. Haha. Also RZ tot.

Naja, eigentlich kein Problem sollte man denken. Ok, die Server wieder hochfahren und gut is. Vielleicht macht der ein oder andere noch einen Festplattencheck, aber dann hat sich die Sache. War auch so. Alles wieder gut.

Oder?

Wenige Minuten später … ein Anruf übers Handy. Die TK Anlage steht still. Hä? Das gab’s ja bisher noch nie – egal was ich an Konfigurationsfehlern eingebaut hatte auf allen Testsystemen. Von nun an ging es hin&her. Fehlersuche … überall. Es gab einfach keine Fehlermeldung mit einem Hinweis auf den Fehler. Das Szenario war auch verschieden. Einerseits zog der asterisk Prozess 100% CPU und nahm nichts mehr an. Andererseits schmierte der Prozess mit einem Core Dump einfach sang und klanglos ab. Auch die Laufzeiten waren total verschieden. Mal lief der Prozess ein paar Stunden, mal nur wenige Minuten.

Das ganze ging zwei Wochen hin&her. Zuerst habe ich versucht herauszufinden was los ist – strace, tcpdump, entfernen der Scripte aus dem Dialplan … alles hat nichts gebracht. Auch andere Versionen wurden ausprobiert, keine Änderung. Zwischenzeitlich wurde eine externe Firma mit ins Boot genommen. Die sich genauso die Zähne ausgebissen haben (Konfig geprüft, eigene Versionen von Asterisk paketiert, …), allerdings hatten die dann auch die entscheidende Idee. Das ganze ging gut 2 Wochen.

And the problem was *trommeln* ….

Das Problem waren am Ende Umleitungen am Telefon. Und jetzt fragt ja nicht “Hä?”! Es handelt sich dabei auch nicht um einen Konfigurationsfehler, sondern um ein Fehler in der Asterisk Software. Dieser Fehler ist in Version 1.6 genau so vorhanden, wie in der 1.8 – die wir mittlerweile dann doch einsetzen

genauer gesagt …

Man kann an einer solchen Telefonanlage vieles auf verschiedene Arten lösen. Auch Umleitungen. Einerseits kann man die Umleitungen innerhalb der Anlage abhandeln und andererseits geht das über das Telefon. Besser ist definitiv das ganze über die Anlage zu machen. Das erweist sich auch an vielen anderen Stellen als sinnvoll.

Nun hatte ich das sogar so gemacht. Der “alte” Ablauf für eine Umleitung sah so aus:

1. Benutzer drückt eine gewisse Taste am Telefon
2. gibt das Umleitungsziel ein
3. mit der Bestätigung wird im Telefon lokal die Umleitung gesetzt und im Hintergrund eine Nummer angerufen, die als Parameter ebenfalls das Umleitungsziel besitzt. Dadurch wird in der Anlage ebenfalls eine Umleitung gesetzt.

Am Ende war also im Telefon eine Umleitung, die jedoch im normalfall nicht zum Zug kam, weil bereits in der Anlage umgeleitet wurde. Das ganze funktionierte einwandfrei. Die jeweilige Nummer wurde in der AstDB gespeichert und war somit für den Server jederzeit verfügbar. Bei jedem Anruf wurde geprüft ob eine Umleitung in der Datenbank vorhanden war und entsprechend gehandelt.

Wie gesagt, das ganze funktioniert wunderbar. Jedoch nur solange die Datenbankinformationen mit denen der Telefone gleich sind. Hat ein Telefon eine Rufumleitung aktiviert und der Server nicht, so wird der Anruf an das Telefon weitergeleitet. Das Telefon leitet um und dann …. macht’s PENG!!! Kein Witz. Sobald die Umleitung vom Telefon die Anlage erreicht streckt die Asterisk die Flügel und gibt den Geist auf. Auf diese Idee muss man erst einmal kommen. Vor allem, weil das sich von der Version 1.6x bis 1.8x durchzieht.

Aber was hat das ganze mit dem Stromausfall zu tun?? Na das ist dann auch recht einfach. Da der Server nicht heruntergefahren wurde sondern hart ausgeschaltet, waren die Informationen in der Asterisk DB verloren. Also gab es einige Telefone die eine lokale Umleitung aktiviert hatten, der Server davon jedoch nichts mehr wußte. Mit jedem Anruf auf ein solches Telefon wurde die Anlage gekillt. Es gab natürlich einige resets auf dem Server. Die Datenbank frisch gemacht, auf einen anderen Server umgeschwenkt. Das System sogar komplett neu installiert. Aber – naja am Ende ist mal halt schlauer – was sollte das bringen, so lange man die Telefone nicht zurücksetzt. Wir sind eben immer von einem Serverproblem ausgegangen.

Abhilfe

Nachdem das Problem erkannt war wurde dann erst einmal schnelle Hilfe geleistet. Nagios bekam von mir einen Plugin spendiert, der den Status der Telefone mit dem der Datenbank verglich. Sobald es inkonsistenzen gab wurde es rot. Des Weiteren habe ich ein Script geschrieben, welches alle Umleitungen auf allen Telefonen ausschaltet. Das war jedoch nur die Notfallmedizin.

Nachdem ein wenig Ruhe eingekehrt war habe ich mich dann hingesetzt und die ganze Logik für die Rufumleitungen neu geschrieben. Das ganze funktioniert nun über eine Website für die Snom Telefone (xml). Dort wird das Umleitungsziel eingegeben, das ganze wird dann in eine MySQL Datenbank geschrieben und von Asterisk genutzt. Lokal am Telefon gibt es keine Umleitung mehr. Seit dem ist nun auch Ruhe.

Das ganze war einfach extrem blöd, weil die Anlage ja bereits im produktiven Einsatz war. Dadurch entsteht durchaus ein gewisser Druck