Aber wieso eigentlich eine Telefonanlage?
Leute, die sich mit der Technik der IP-Telefonie etwas genauer auskennen, werden wissen, dass es auch möglich ist, ein Telefon direkt über seine IP-Adresse anzurufen. Je nach Hersteller und Telefon geht das auf dem ein oder anderen Weg. Allein für Geräte des Herstellers Grandstream liefert der Hersteller mindestens sieben verschiedene Anleitungen, wie man je nach Gerät, Softwarestand und Umgebung ein anderes Telefon über seine IP-Adresse anrufen kann. Neben dem korrekten Weg, welchen man sich merken muss, benötigt man auch die IP-Adresse der Person, die man anrufen möchte. Also z. B. in einem Mesh-Netzwerk die Rufnummer 10.247.143.75. Das ist, verständlicherweise, weitaus schwerer zu merken als z. B. eine einfache Durchwahl wie die 42 und damit ist die Bedienung dann nicht mehr so einfach, wie wir uns das wünschen würden.
Man könnte die Bedienung jetzt dadurch vereinfachen, dass man die IP-Adressen im Telefonbuch eines jeden Telefons speichert und dann aus dem Telefonbuch heraus nur noch den entsprechenden Eintrag auswählt. Das ist bei einer sehr geringen Anzahl an Telefonen ohne Probleme möglich, skaliert aber nicht mit der Anzahl der Telefone. D. h. wenn die Anzahl der Telefone wächst, muss manuell auf jedem Telefon jedes neue Telefon nachgetragen werden. Auch Änderungen müssen immer auf allen Telefonen gepflegt werden. Das ist ein zu großer Aufwand, um dies manuell zu erledigen. Man müsste sich hierfür ein Programm schreiben und zentral laufen lassen, welches alle Telefone mit den notwendigen Daten versorgt. Aber wenn wir ohnehin bei einem zentralen Programm sind, welches die Telefone mit den notwendigen Informationen versorgt, dann kann das auch eine Telefonanlage sein, die uns das Leben in diesem Moment massiv vereinfacht.
Noch eine Telefonanlage?
Im Hamnet gibt es bereits seit längerer Zeit die Möglichkeit zur Telefonie. Hierbei wird z. B. das eigene Rufzeichen in eine wählbare Nummer umgewandelt. Es handelt sich hierbei also um bereits erprobte und genutzte Technologie. Im Notfunk können wir uns jedoch nicht immer darauf verlassen, einen Zugang zum Hamnet zu haben und wollten daher eine inselfähige Lösung entwickeln. Diese Lösung sollte komplett autark in einem Netzwerk den Dienst „Telefonie“ anbieten können, ohne auf externe Verbindungen angewiesen zu sein.
Das hört sich im ersten Moment auch nicht schwierig an, denn Lösungen für Telefonanlage gibt es im Bereich der Open-Source-Software sehr viele. Jede dieser Lösungen bietet uns dutzend Funktionen neben dem Telefonieren, von Anrufbeantworter über Fax bis zu Konferenzräumen. Funktionen, die jemandem, der eine solche Software regelmäßig pflegt und betreut, keine Probleme bereiten, aber jemandem, der diese Software vielleicht einmal im halben Jahr bedient, massiv Probleme bereiten würden. Daher entschieden wir uns dafür, eine eigene Lösung anzugehen, welche genau das bietet, was wir benötigen: Telefonie und diese einfach zu verwalten und bedienen. Denn auch hier durften wir nicht vergessen, dass die Technik nicht durch IT-Spezialisten aufgebaut und betreut wird und die Akzeptanz maßgeblich daran hängt, wie einfach alles zu bedienen ist.
Der Rest ist, wie man so schön sagt, Geschichte. Ein Team um Sebastian (DL3SD) herum hat eine Anlage entwickelt, welche nicht nur genau die Funktionen bietet, die wir wünschen, sondern auch so gut dokumentiert ist, dass bisher mehrere Dutzend Funkamateure diese Anlage ohne Probleme in Betrieb nehmen und testen konnten. Diese Anlage bietet ein einfach zu nutzendes Frontend auf einer Webseite, welches nur die benötigten Dienste und Informationen zur Verfügung stellt, um auch unerfahrenen Nutzern den Einstieg zu erleichtern. Über dieses Webfrontend können Telefone eingerichtet werden und sobald diese sich im Netzwerk anmelden, werden diese automatisch für die Nutzung vorbereitet, erhalten ihre Rufnummer und auch ein Telefonbuch der anderen Teilnehmer im Netz. Bisher werden Telefone des Herstellers Snom und Grandstream mit diesen Funktionen unterstützt.
Bereits mit diesem einfachen Set-up, kann ein Netz von Telefonen zum Beispiel in einem Landkreis verteilt und genutzt werden. Sofern neben dem reinen Inselbetrieb für die Anlage auch ein Zugang zum Hamnet oder Internet zur Verfügung steht, können sich einzelne Insel-Telefonanlagen auch untereinander anrufen und erreichen. Hierzu wird und wurde durch das Referat eine redundante Infrastruktur im Hamnet und im Internet aufgebaut.
Durch das redundante Set-up und die Anbindung von Gateways ist es uns auch möglich, das öffentliche Telefonnetz mit anzubinden. Natürlich immer vorausgesetzt, eines der Gateways im Hamnet und Internet hat noch eine Anbindung an das öffentliche Internet. Dies bedeutet, dass die Teilnehmer der Telefonanlage sowohl Teilnehmer im öffentlichen Telefonnetz anrufen als auch von diesen angerufen werden können. Hierzu muss der Anrufende die Nummer eines der Gateways sowie das Ziel seines Anrufes kennen. Bei einem Anruf auf einem der Gateways erhält man die Möglichkeit, die gewünschte Zielrufnummer einzugeben (z. B. 14223). Nach der Bestätigung der Eingabe mit der #-Taste wird die Verbindung hergestellt und das angerufene Telefon klingelt.
Geht es jetzt los?
Wie schon im vorherigen Posting erwähnt, ist die Software immer nur ein Teil der Lösung und erst mit der passenden Hardware wird aus einer Idee ein funktionales System. Die Telefonanlage ist grundsätzlich auf allen x86 fähigen Rechnern lauffähig, d. h. sie kann auf einem Laptop genauso wie auf einem Mac oder einem Linux System laufen, aber das wünschen wir uns gar nicht. Wir möchten nicht, dass für den „produktiven Einsatz“ das Eigentum von Funkamateuren genutzt wird, sondern dass es hierfür speziell vorgehaltene Technik geben wird. Die Gründe hierfür lassen sich ganz grob auf 3 Fragen reduzieren:
- Ist das Material immer in unserem Zugriff, auch dann, wenn der Besitzer z. B. im Urlaub sind?
- Was ist, wenn der Besitzer z. B. aus dem DARC austritt oder es „menschelt“?
- Wer bezahlt Technik, die kaputtgegangen ist?
Modulkoffer M00
Eine zentrale Telefonanlage in einem Mesh-Netzwerk stellt einen Single Point of Failure dar, also einen kritischen Punkt, bei dessen Ausfall bestimmte Dienste nicht mehr lauffähig sind. Daher mussten wir uns überlegen, wie wir dieses System möglichst robust und im Fehlerfall austauschbar machen konnten. Wir haben daher ein standardisiertes Modul entwickelt, welches als Modulkoffer „M00“ in unserem Konzept Einzug fand. Dieses Modul wird überall absolut identisch aufgebaut und kann 1:1 gegeneinander ausgetauscht werden. D. h. auch wenn ein Modulkoffer einmal kaputtgeht, kann einfach ein weiterer als Ersatz genutzt werden. Die Funktionen sind identisch, ausschließlich die Konfiguration der Telefone muss übernommen werden.
Woraus besteht jetzt dieser „Modulkoffer M00“?
Als Gehäuse dient ein 19“ breites Gehäuse, in dem normalerweise Studio-Equipment oder IT-Equipment untergebracht ist. Diese Gehäuse sind relativ günstig zu kaufen und durch die Nutzung u. a. im Event-Bereich auch hervorragend verfügbar. D. h. auch Ersatzteile oder komplett neue Gehäuse, falls einmal eines so beschädigt werden sollte, sind ohne größeren Aufwand zu beschaffen. Im Fall der Telefonanlage haben wir uns für ein Gehäuse mit drei Höheneinheiten (was ca. 133 mm Innenhöhe entspricht) entschieden. In diesem Gehäuse untergebracht ist natürlich als erstes der Kleinstrechner, auf welchem die Telefonanlage läuft. Dieser wird mit 12 V betrieben und ist im Leerlauf relativ sparsam. Wir haben uns hier für Intel NUC entschieden, da diese laut Datenblatt für einen Betrieb zwischen 10 und 19V zugelassen und sowohl neu als auch gebraucht optimal erhältlich sind.
Weiterhin enthält das Gehäuse einen Router für das Mesh-Netzwerk. Dieser Router hat einzig die Aufgabe, die Dienste der Telefonanlage im Netzwerk bekannt zu machen und die Telefonanlage an das Netz anzubinden. Wir hätten hier auch die Möglichkeit gehabt, die Telefonanlage an einen der vorhandenen Knoten per Kabel anzuschließen, haben uns hier aber dagegen entschieden, da dann vor Ort wieder Konfigurationsaufwand entstanden wäre, den wir um jeden Preis vermeiden wollten. Der Router wird mit 24V Betrieb, da dieser auch die angeschlossene Wifi Antenne über PoE (Power over Ethernet) mit Strom versorgt. Dies wäre grundsätzlich auch mit 12V möglich gewesen, hätte jedoch bei längeren Kabelstrecken eventuell zu Problemen geführt, welche einen stabilen Betrieb hätten stören können. Die 24V werden über einen verbauten DC-DC-Wandler aus den 12V Systemspannung erzeugt.
Alles, was jetzt noch fehlte, war eine passende Stromversorgung, d. h. ein passender Akku für das Gehäuse. Hier kam jedoch schnell der Punkt, dass ein einzelner Akku zu Unterbrechungen im Betrieb führen könnte. Immer dann, wenn der Akku leer ist und getauscht werden müsste, müsste die Telefonanlage abgeschaltet werden. D. h. es wäre für einen Zeitraum von 5 Minuten kein Telefonat mehr möglich. Dies war natürlich nicht in unserem Interesse, daher musste ein zweiter Akku direkt eingeplant werden. Wie in den Telefonkoffern, von dem wir euch in einer der nächsten Teile berichten, haben wir uns auch bei der Telefonanlage für unsere 18Ah LiFePo4 Akkus entschieden. Je weniger verschiedene Akkus wir verwenden, desto einfacher können wir Akkus austauschen. Mit zwei dieser Akkus sollte die Telefonanlage ca. 24 Stunden komplett autark lauffähig sein, bevor ein Akkuwechsel oder eine Ladung der Akkus notwendig wird.
Das Problem bei LiFePo4 Akkus ist jedoch, dass man diese nicht einfach parallel schalten kann. Es kann sonst zu sehr hohen Ausgleichsströmen zwischen den Akkus führen, was zu einer Beschädigung nicht nur der Akkus, sondern auch der Kabel und Stecker führen kann. Daher mussten wir hier eine Lösung finden, welche die Schaltung von zwei Akkus parallel ermöglicht. Mit einem Zusatzmodul zum verwendeten Batterie-Management-System sollte diese Lösung auch für uns gefunden werden. Auch wenn die Lieferzeit vom Hersteller aus Fernost großzügig waren, so sind auch diese Teile mittlerweile eingetroffen.
Zum Ende hin blieb nur noch ein Problem über, welches durch uns gelöst werden musste. Die Montage aller Komponenten im Gehäuse. Für den Intel NUC gab es eine passende Blende, in welcher der NUC einfach eingeschraubt wurde und dann im Gehäuse fest war. Jedoch gab es dies weder für die Akkus noch für die Batterie-Management-Systeme, den Sicherungsverteiler oder den Router für das Mesh-Netzwerk. Hier kam uns, wie so oft bei diesen Projekten, der 3D-Druck zu Hilfe. Mit diesem konnten passgenaue Adapterplatten und Halter für alle Bauteile entworfen und gedruckt werden. Wir können ja nicht davon ausgehen, dass jeder das Material wie das sprichwörtliche rohe Ei behandelt, daher muss das Material alles sicher verankert sein, damit man nicht plötzlich einen Haufen Elektroschrott hat.
Aktuell haben wir 1 dieser Modulkoffer und sind dabei, die Mittel für einen Zweiten zu organisieren, um die vollständige Redundanz auf dem Anhänger zu erzielen. Weiterhin sind wir noch dabei, die Infrastruktur im Hamnet und im Internet weiter auszubauen, um auch hier ausreichend Redundanz vorzuhalten. Dieser Modulkoffer gehört auch zu dem Equipment, welches sich Distrikte für Veranstaltungen ausleihen können, um das Equipment vorzuführen. Voraussetzung für den Verleih ist nur, dass der oder die Ausleihende das Ausbildungswochenende von uns mitgemacht hat, damit man eine ungefähre Ahnung von dem hat, was man da vorführt.
Weitere Informationen zur Software hinter der Telefonanlage gibt Sebastian in seinem Talk „Einführung in die Notfunk-Telefonanlage“, welcher anlässlich des diesjährigen Notfunk-Symposiums in Ottobeuren aufgezeichnet wurde. Den Talk könnt ihr euch unter media.notfunk.radio/w/2Mbv43ivAnZwt9DVv6bpDm anschauen. Anleitungen zur Notfunk-Telefonanlage finden DARC-Mitglieder unter www.darc.de/der-club/referate/notfunk/technik/nfpbx/