© Chainarong Chokrung / 123RF.com

Asterisk gilt als sperrig und kompliziert. Dabei steht außer Frage, dass die freie Telefonanlage selbst komplexe Setups betreiben kann. Unser Workshop verrät, wie Sie mit FreePBX einen erstklassigen Ersatz für kommerzielle Alternativen bauen.

“Ruf doch mal an”, lautete der Slogan der Deutschen Telekom in den 90er-Jahren kurz nach der Privatisierung der Bundespost. Auch drei Jahrzehnte später spielt das Telefon im Alltag noch immer eine große Rolle, wenn auch je nach Zielgruppe auf unterschiedliche Weise. Während die Generation Z mittlerweile vor allem auf Sprach- und Textnachrichten setzt, gilt im mittelständischen Umfeld die klassische Telefonie per Handy noch immer als Standard. Hier spielt auch das gute alte Festnetz noch eine wichtige Rolle, wobei klassische analoge Telefonie inzwischen praktisch verschwunden ist. Das Gros der Ferngespräche läuft heute über VoIP, und längst enthält der klassische Router (eine Fritzbox etwa) auch eine kleine Telefonanlage.

Im privaten Umfeld ist damit das Thema Telefonie abgefrühstückt, im kommerziellen Umfeld muss man aber andere Technologien einsetzen. Jahrzehntelang haben Firmen wie Auerswald [1] viel Geld mit komplexen Telefonanlagen verdient. Die Anforderungen in Büros mit vielen Telefonen an Sprachmenüs, Warteschlangen und Rufweiterschaltungen und andere Features gehen weit über das hinaus, was eine Fritzbox oder ein vergleichbares Gerät leisten kann.

Open-Source-Verfechter bringen regelmäßig Asterisk als Alternative zu einer kommerziellen Telefonanlage ins Spiel, schrecken damit aber viele Menschen ab. Asterisk ist ein komplexes Biest, und schon der Anschluss der Software an einen SIP-Trunk etwa der Telekom ist kein triviales Unterfangen. FreePBX [2] hingegen, die am weitesten verbreitete freie Asterisk-Distribution, verspricht Administratoren, sie vor den Zumutungen von Asterisk so weit wie möglich zu bewahren.

Allerdings ist auch der Einstieg in FreePBX kein Selbstläufer. Dieser Artikel ist der erste Teil einer Workshop-Reihe, die Administratoren dabei unterstützt, mit FreePBX eine Telefonanlage aufzubauen und an die eigenen Bedürfnisse anzupassen. Dabei kommen grundlegende Themen wie die nötige Hardware und das korrekte Setup ebenso zur Sprache wie die spezifische Konfiguration für einen TLS-SIP-Trunk der Telekom. Hinzu kommen empfohlene Einstellungen in Sachen Performance und Sicherheit sowie komplexe weiterführende Themen wie ein digitales Fax auf Grundlage von Hylafax [3]. Bis heute ist die Fernkopie in Deutschland notwendig, weil sie neben der klassischen Briefpost noch immer den einzigen rechtsverbindlichen Weg der Kommunikation bietet.

Am Ende des Aufwands steht ein fertig konfiguriertes FreePBX mit Fax-Funktion, das bei Bedarf die Weiterleitung von Anrufen an externe Nummern ebenso unterstützt wie Warteschlangen, Bandansagen und diverse weitere Funktionen. Wir starten die Artikelreihe mit dem Thema Hardware, sowohl mit Blick auf die Telefonanlage als auch auf die später zu nutzenden Telefone.

Blech oder virtuell?

Administratoren, die sich erstmals mit FreePBX befassen, kommen heute durch viele entsprechende Einträge im Netz schnell in Versuchung, einen Raspberry Pi als mögliche Lösung in Betracht zu ziehen. Ein RasPi 5 hat zumindest für kleinere Telefonanlagen auch durchaus genug Dampf im Kessel.

Eine wirklich gute Idee ist das Unterfangen aber dennoch nicht, und zwar aus mehreren Gründen. FreePBX kam bis zur Version 16 als Software-Appliance in Form einer ISO-Datei daher. Grundlage des Systems war CentOS, also der freie Klon von Red Hat Enterprise Linux. Das System firmierte unter der Bezeichnung FreePBX Distro. Indirekt ist Sangoma, die Firma hinter FreePBX und Asterisk, letztlich Opfer von Red Hats Portfolio-Optimierung geworden, denn CentOS gibt es in seiner ursprünglichen Form bekanntlich nicht mehr.

Weil man also das eigene System ohnehin auf neue Fundamente stellen musste, vollzog Sangoma gleich einen radikalen Bruch. Heute ist die empfohlene Installationsmethode – und die einzige, für die man bei Sangoma Support kaufen kann – die Installation von FreePBX unter Debian GNU/Linux 12, für die es auch ein eigenes Skript gibt.

Hier beginnen allerdings schon die Probleme: Sangoma selbst stellt DEB-Pakete für FreePBX nur für die x86_64-Plattform bereit. Der Raspberry Pi nutzt jedoch bekanntlich die ARM64-Architektur. Zwar existieren im Netz unter der Bezeichnung RasPBX Skripte, die FreePBX auf einem Raspberry Pi automatisch aus den Quellen kompilieren. Ein so konstruiertes System bietet aber nicht alle freien Features von FreePBX auf AMD64-Systemen.

Darüber hinaus kann man für solche Installationen weder kommerziellen Support von Sangoma bekommen noch eines der proprietären PBX-Plugins installieren, die der Hersteller für FreePBX anbietet. RasPBX darf insofern eher als elegantes Bastelprojekt mit einem gewissen akademischen Anspruch gelten denn als ein Werkzeug, dem man die unternehmenskritische Telefonie überantworten möchte. Entsprechend raten wir vom Betrieb von FreePBX auf einem Raspberry Pi dringend ab.

Das wirft freilich die Frage auf, welche Hardware man für eine FreePBX-Installation stattdessen nutzen kann. Eines steht fest: Soll die Telefonanlage nicht Dutzende Anrufe parallel verwalten, halten sich die Anforderungen an die gegebene Hardware in relativ engen Grenzen.

Mini-Computer im Hosentaschenformat sind derzeit in Mode und bieten, verglichen mit früheren Zeiten, eine erquickliche Portion Rechenleistung. Gemeint sind kostengünstige Geräte wie die von Minisforum [4], Beelink [5] oder Geekom [6]. Der Minisforum UM760 Slim etwa kommt mit 16 GByte DDR5-RAM sowie einer CPU des Typs AMD Ryzen 5 7640HS daher. Das genügt für die Anforderungen einer Telefonanlage in normaler Firmengröße völlig. Rund 315 Euro sind vor diesem Hintergrund ein akzeptabler Preis.

Wer stattdessen zu einem AM06 Pro (Abbildung 1) von NiPoGi greift, bekommt eine Ryzen-7-5700U-CPU mit 16 Threads und 32 GByte RAM für rund 300 Euro netto. Für 40 Euro mehr hat das Gerät sogar 1 TByte Flash-Speicher statt 512 GByte. Das ist insbesondere dann hilfreich, wenn Sie später zu Trainingszwecken Aufzeichnungen einzelner Telefonate anlegen wollen.

Abbildung 1: Der NiPoGi AM06 Pro ist im Gespann mit Proxmox VE und FreePBX ein geeignetes Gerät für eine eigene Telefonanlage – günstig, aber ausreichend leistungsstark. Quelle: NiPoGi

Proxmox VE hilft

Zu den 350 Euro für die nötige Hardware gesellt sich im Idealfall eine Proxmox-VE-Subskription [7] der Variante Community hinzu, da es sich empfiehlt, die Telefonanlage zu virtualisieren. So bietet das Rechenkistchen deutlich mehr Vielfalt und ermöglicht komplexere Setups.

Eingangs haben wir bereits erwähnt, dass Hylafax als Komponente für vollständig digitalen Fax-Empfang zum Einsatz kommt. Das aber lässt sich auf Debian GNU/Linux 12, also der Distribution, die FreePBX zwingend voraussetzt, nicht ordentlich installieren und einrichten. Debian liegt nämlich nur das reguläre Hylafax bei, nicht das aktuellere und deutlich besser gewartete Hylafax+. Das bekommen Sie stattdessen mit dem RHEL-Klon Alma Linux 8. Ein späterer Teil des Workshops wird sich deshalb detailliert mit dem Hylafax-Setup in Alma Linux befassen. Das wiederum lässt sich am einfachsten realisieren, wenn die angeschaffte Hardware gleich mehrere virtuelle Instanzen mit verschiedenen Distributionen betreiben kann.

Die Kosten für die anzuschaffende Hardware belaufen sich damit auf ungefähr 500 Euro brutto samt Proxmox VE. Das liegt noch immer deutlich unterhalb der Kosten für eine komplexe kommerzielle Telefonanlage. Der kann die hier vorgestellte Lösung im Hinblick auf die angebotenen Funktionen aber durchaus das Wasser reichen. Das gilt umso mehr, als bei Implementierung der beschriebenen Lösung Anschaffung und Betrieb eines Fax-Geräts entfallen.

Die Telefone

Weitere Ausgaben stehen dem Administrator der Telefonanlage allerdings in Sachen Telefone ins Haus. Bis heute erfreut sich der DECT-Standard weltweit großer Beliebtheit. Das ist schon deshalb bemerkenswert, weil DECT längst als obsolet und implizit unsicher gilt und eigentlich längst nicht mehr zur Anwendung kommen sollte. Jedenfalls hat man den DECT-Standard in den vergangenen Jahren immer wieder um Hacks und Tricks erweitert, um allzu klaffende Sicherheitslöcher zumindest provisorisch abzudichten.

Dabei ist DECT [8] technisch nicht einmal besonders robust oder funktional. Das Gros der heute etwa in einem Computermarkt angebotenen Telefone nutzt nur deshalb noch DECT, weil es den Einsatz schnurloser Telefone relativ unkompliziert ermöglicht. Wenn Sie stationäre Schreibtischtelefone bevorzugen, können Sie diese in der Regel mittels SIP mit FreePBX verbinden.

Bevorzugen Sie eine schnurlose Variante, sollten Sie über die zu nutzenden Endgeräte allerdings noch einmal nachdenken. Telefone, die SIP mittels Wi-Fi 6 oder 7 realisieren, gibt es längst am Markt. Sie nutzen die vorhandene WLAN-Infrastruktur inklusive WPA3-Verschlüsselung und kosten kaum mehr als DECT-Telefone, können aber deutlich mehr. Die Modelle WP816, WP826 (Abbildung 2) und WP836 von Grandstream [9] etwa bieten zusätzlich Bluetooth 5.0 und erlauben so den Anschluss komfortabler Headsets mit ordentlicher Übertragungsqualität.

Abbildung 2: Das Wi-Fi-VoIP-Telefon Grandstream WP826 umgeht die Nachteile von DECT und bietet eine Vielzahl an Einstellungsmöglichkeiten.

DECT-Telefone beherrschen zwar oft ebenfalls Bluetooth, allerdings ältere Standards mit niedriger Qualität bei der Sprachübertragung. Wer moderne Wi-Fi-VoIP-Telefone nutzt, erschlägt daher viele Probleme auf einmal. Hohe Bandbreite durch Wi-Fi 7 bei geringer Latenz durch eine engmaschige Wi-Fi-Ausleuchtung gepaart mit viel höherer Abhörsicherheit, umfassende Bluetooth-Fähigkeiten und die Option, die Geräte automatisch zu provisionieren, sprechen für sich.

DECT-Repeater gehören in solch einem Szenario ebenso der Vergangenheit an wie nervige Tonstörungen bei Telefonaten. Auch die Frage, wie man die Telefone überhaupt mit der Telefonanlage verbindet, stellt sich anders als bei DECT erst gar nicht. Viele Basisstationen von DECT-Telefonen sprechen selbst nämlich gar kein SIP, sondern verbinden sich mit der Telefonanlage per F- oder RJ11-Stecker. Einen Anschluss dafür hat die geplante Lösung auf Basis von Proxmox VE und FreePBX erst gar nicht.

Schlimmstenfalls wäre noch ein teurer Analog-zu-SIP-Wandler nötig, mit negativem Einfluss auf die Übertragung. Wenn Sie Ihre Telefonanlage also ohnehin erneuern und dabei auf moderne Standards setzen, sollten Sie die Endgeräte ebenfalls austauschen, falls sie schnurlos sein sollen. Ganz billig sind beispielsweise die beschriebenen Grandstream-Telefone jedoch nicht: Das Mittelklasse-Modell WP826 schlägt mit ungefähr 160 Euro zu Buche. Die Investition lohnt sich allerdings zweifellos.

Erste Schritte

Gegeben sei also ein frisch erworbener NiPoGi AM06 mit 1 TByte Flash-Speicher, 32 GByte RAM und einer aktuellen Ryzen-CPU. Ab Werk ist auf diesen Geräten meist Windows 11 installiert, das für das anstehende Projekt allerdings hinderlich ist. Stattdessen lässt sich eine ISO-Datei für die Proxmox-VE-Installation leicht von der Proxmox-Website beziehen. Die ID für die aktive Subskription müssen Sie erst nach der Proxmox-Installation eingeben.

Die erste Aufgabe im Hinblick auf die neue Telefonanlage besteht also darin, das Proxmox-VE-ISO auf einen USB-Stick zu schreiben, den Mini-Computer davon zu starten und Proxmox VE zu installieren. Die Einrichtung ist trivial, viele Einstellungsmöglichkeiten bietet Proxmox VE ohnehin nicht. Ist es installiert, loggen Sie sich auf dessen Weboberfläche ein und beginnen mit den eventuell notwendigen Schritten für die zusätzliche Einrichtung. Bei der Gelegenheit empfiehlt es sich, gleich auch die ISO-Dateien für Debian GNU/Linux 12 und Alma Linux 8 im dafür von Proxmox VE angelegten ZFS-Pool zu hinterlegen. Ein abschließendes Update von Proxmox VE auf die aktuellsten Pakete des Anbieters rundet die Erstinstallation ab (Abbildung 3).

Abbildung 3: Proxmox VE verursacht in der Community-Edition nur geringe Kosten, ist aber das perfekte Fundament für mehrere VMs – eine für FreePBX und eine für ein späteres Fax auf Hylafax-Basis.

Als Nächstes steht das Erstellen einer VM mit Debian GNU/Linux 12 auf dem Plan. Sie sollte idealerweise Zugriff auf mindestens zwei physische CPU-Kerne oder vier Threads erhalten und über nicht weniger als 8 GByte RAM verfügen. Das Debian-Setup erledigen Sie entlang der Empfehlungen des Debian-Installers. Sinnvoll ist aber eine Festplattenpartitionierung unter Verwendung von LVM, um flexibel zusätzliche Mountpoints im Dateisystem anlegen zu können. Beachten Sie beim Anlegen der LVM-basierten Partitionierung, dass die Volumes für »/root« und »/var« jeweils mindestens 20 GByte Größe haben müssen. Dagegen darf »/home« klein und sparsam sein.

Im FreePBX-Kontext ist es wichtig, beim Aufsetzen der VM die passenden Locales auszuwählen. Weite Teile des FreePBX-UIs sind ins Deutsche übersetzt. Damit das Webinterface die Übersetzung dann aber auch anzeigt, muss das System über die Locale »de_DE.UTF-8« verfügen. Andernfalls lässt sich Deutsch zwar als Sprache im Web-UI auswählen, die Änderung bleibt aber ohne Wirkung.

Im ersten Schritt nach der VM-Installation passen Sie deshalb »/etc/locale.gen« so an, dass dort neben der System-Locale »en_US.UTF-8« auch die per »locale-gen« erzeugte deutsche Locale aktiv ist. Alternativ können Sie die FreePBX-Instanz auch vollständig mit »de_DE.UTF-8« betreiben.

Sie tun ferner gut daran, unmittelbar nach der Debian-Installation die Paketquelle für Backports in Debian GNU/Linux 12 zu aktivieren und sich von dort einen aktuelleren Kernel zu organisieren. Zu Redaktionsschluss war die aktuellste verfügbare Version des Kernels ein halbwegs modernes Linux 6.12.9 – viel neuer als der Debian-12-Standard Linux 6.1. Gerade latenzkritische Anwendungen wie SIP profitieren von modernen Kernels, die viele Performance-Verbesserungen mitbringen.

Bedenken Sie zudem, dass Debian GNU/Linux 12 ab Werk nicht automatisch über SSH verfügt. Es empfiehlt sich, während der Installation die Option »SSH Server« zu aktivieren oder den SSH-Daemon mit »apt install openssh-server« nachzuinstallieren. Schließlich ist es sinnvoll, sowohl für den Benutzer Root als auch für den während der Debian-Installation angelegten regulären User einen öffentlichen SSH-Schlüssel zu hinterlegen, damit das Login auf Schlüsselbasis klappt.

Das können Sie von einem Host aus erledigen, auf dem der private SSH-Schlüssel liegt. Das passende Kommando lautet »ssh-copy-id User@IP« sowie »ssh-copy-id root@IP«. Im Nachgang sollten sowohl »ssh root@IP« als auch »ssh User@IP« funktionieren.

FreePBX installieren

Der nächste Schritt ist das Setup von FreePBX. Die gute Nachricht ist, dass die FreePBX-Entwickler dafür ein Shell-Skript beisteuern, das die Installation automatisch erledigt. Das erste Kommando aus Listing 1 lädt das Skript herunter, das zweite führt es aus. Die Log-Meldungen des interaktiven Skripts verfolgen Sie in einem zweiten Terminal (drittes Kommando). Es schadet nicht, vorab einen Blick in das Skript zu werfen, das mit fast 1300 Zeilen nicht ganz schlank daherkommt.

# wget https://github.com/FreePBX/sng_freepbx_debian_install/raw/master/sng_freepbx_debian_install.sh -O /tmp/sng_freepbx_debian_install.sh
# bash /tmp/sng_freepbx_debian_install.sh
# tail -f /var/log/pbx/freepbx17-install.log

Während des Laufs stellt das Skript einige Fragen, unter anderem nach der zu nutzenden Asterisk- und FreePBX-Version. Bei neuen Setups sollten Sie hier zu Asterisk 21 und FreePBX 17 greifen, die älteren Versionen sind vor allem für Bestands-Setups interessant. Planen Sie, FreePBX mit einem Telekom-Trunk zu verbinden, sollten Sie unbedingt zu Asterisk 21 greifen: Die Company-Flex-Tarife der Telekom bieten mehrere SIP-Endpunkte pro Trunk und mehrere Proxyserver für Multi-Standort-Setups an. Damit können frühere Versionen von Asterisk nicht umgehen.

Ist das FreePBX-Skript durchgelaufen, startet es die Debian-Instanz neu. Nach ein paar Sekunden funktioniert das Login per SSH wieder, und Sie können die FreePBX-Maschine erstmals auch im Browser über Port 80 erreichen. Dort begrüßt Sie die Konfigurationsmaske von FreePBX für die Erstinstallation. Sie lässt sich primär durch beharrliches Klicken auf den Weiter-Button übergehen. Wichtig ist aber, einen Namen und ein Passwort für denjenigen Benutzer in FreePBX festzulegen, der später als Administrator fungiert. Achtung: Dabei handelt es sich nicht um den Systemverwalter Root, FreePBX hat eine eigene Benutzerverwaltung.

Haben Sie auch diese Hürde überwunden, sind Sie erstmals im FreePBX-GUI eingeloggt. Der Schalter, um es auf deutsche Sprache umzustellen, befindet sich oben rechts. Zumindest für die GUI empfiehlt sich dieser Schritt, denn im Telefonsprech gibt es feststehende Begriffe wie Hauptleitung und Amtskennzahl, deren englische Entsprechungen sich nicht immer automatisch erschließen.

Gut möglich übrigens, dass die Dashboard-Übersicht (Abbildung 4) von FreePBX Warnungen oder Fehler anzeigt. Sie resultieren noch aus den Veränderungen während des ersten Setups. Es ist an dieser Stelle in Ordnung, die Fehlermeldungen per Klick auf das kleine X daneben zu entsorgen. Die Warnungen im Abschnitt Zusammenfassung – etwa jene, dass Asterisk innerhalb der letzten zehn Minuten neu gestartet worden ist – verschwinden von allein.

Abbildung 4: Das FreePBX-Dashboard dient als zentrale Infoseite für alle zu FreePBX gehörenden Dienste. Nach der Erstinstallation sehen Sie möglicherweise noch Fehler, die aber bald verschwinden und die Sie löschen können.

Fail2ban

In diversen Setups beim Autor hat sich die kleine Komponente Fail2ban übrigens als Herausforderung entpuppt. Ihre Zielsetzung ist eigentlich gut: Melden sich Clients zu oft mit falschen Zugangsdaten an einem System an, etwa per SSH, im Webinterface oder an Asterisk selbst, dann hinterlegt Fail2ban automatisch eine passende Nftables-Regel, um Angriffe zu unterbinden. Allerdings klappt in FreePBX die Erkennung des lokalen, “guten” Netzwerks nicht immer zuverlässig.

Das ist gerade in Umgebungen mit mehreren lokal anliegenden Netzen eine Herausforderung. Im schlimmsten Fall sperrt Fail2ban den Administrator dann aus. Das Problem lässt sich lösen, indem Sie sich am VNC-Terminal der Proxmox-VE-Instanz als Root anmelden und Fail2ban mittels »systemctl stop fail2ban.service« anhalten. Danach lässt sich im Web-UI von FreePBX über den Menüpunkt Connectivity | Firewall | Schnittstellen festlegen, zu welcher Firewall-Zone das lokale Netzwerkinterface gehören soll (Abbildung 5). Hier hilft die Option Local weiter.

Abbildung 5: Wenn Fail2ban nach der FreePBX-Installation Amok läuft, hilft es, die lokalen Netze explizit zu definieren. So bleibt ein Login per SSH möglich.

Alternativ deaktivieren Sie im Webinterface die FreePBX-Firewall bis zum Abschluss der Arbeiten in diesem Menü vollständig. Das legt auch Fail2ban lahm.

Flickwerk

Theoretisch würde an dieser Stelle der nächste logische Schritt beginnen, die Konfiguration von Amtsleitung und SIP-Clients. Stattdessen steht aber erst noch der Austausch einer Komponente von FreePBX gegen eine gepatchte Version auf dem Programm.

Das gilt zumindest dann, wenn die Telefonanlage später das SIP 302 Partial Rerouting unterstützen soll, im Deutschen etwas sperrig als Rufumleitung im Amt beschrieben. SIP-Trunks aller großen Anbieter im Business-Umfeld beherrschen das Feature ab Werk, und es hat durchaus seine Daseinsberechtigung. Um zu verstehen, was gemeint ist, tauchen wir kurz in die Tiefen der Telefonie und des SIP-Protokolls ab.

Rufumleitungen sind ein Standardwerkzeug der Telefonie. Anrufe auf dem Handy etwa werden meist nach einer gewissen Klingeldauer auf die Mailbox umgeleitet, falls keine Antwort erfolgt. Festnetztelefonie beherrscht das Feature grundsätzlich ebenfalls. Das kann gerade in kleineren Betrieben hilfreich sein, wo das Büro nicht durchgehend besetzt ist, eingehende Anrufe aber trotzdem nicht beim Anrufbeantworter landen sollen.

Technisch gibt es zwei Möglichkeiten, Rufumleitungen zu implementieren. Asterisk als Telefonanlage im Hintergrund von FreePBX kann einen eingehenden Anruf registrieren und im nächsten Schritt als Bridge fungieren. Dann ruft Asterisk parallel zum eingehenden Telefonat eigenständig die Nummer an, die als Ziel der Rufumleitung hinterlegt ist, und stellt im Hintergrund eine Audio-Brücke zwischen beiden Anrufen her. Der Nachteil: Das Telefonat wird durch das lokale Telefonsystem geroutet, was eine deutlich höhere Latenz verursacht und zudem im System zwei Sprachkanäle belegt.

Weil es sich aus Provider-Sicht beim ausgehenden Anruf um ein ganz normales Gespräch handelt, fallen dafür im dümmsten Fall außerdem Gebühren an. Der durchschnittliche SIP-Trunk bei der Telekom hat zu allem Überfluss ab Werk nur zwei solcher Sprachkanäle. Ein weitergeleitetes Telefonat würde also dazu führen, dass ein weiterer Anrufer ein Besetztzeichen erhielte. Eine anwesende Person im Unternehmen könnte während eines weitergeleiteten Telefonats keinen zusätzlichen ausgehenden Anruf starten. In Summe ist diese Lösung also mit vielen Nachteilen behaftet.

Streng genommen ist die Lösung technisch auch falsch. Das SIP-Protokoll sieht für genau diese Situation Call Deflection vor, verkörpert durch das SIP-Signal 302 alias Partial Rerouting. Dabei schickt Asterisk dem SIP-Anbieter die Anforderung, den Anruf an ein anderes Ziel umzulenken, und der handelt entsprechend das Telefonat auf eigene Initiative neu aus. Folgerichtig fallen weder Gebühren an, noch entsteht ein zusätzlicher blockierter Kanal in der Telefonanlage. Im Gegenteil: Hat Asterisk dem SIP-Provider die Rufumleitung einmal signalisiert, sind wieder beide Sprachkanäle frei.

Allerdings ist die SIP-302-Funktionalität in Asterisk fehlerhaft implementiert. Das betrifft alle Setups, in denen Asterisk hinter einer Firewall steht, wie es meist der Fall sein dürfte, und NAT im Bundle mit IPv4 benutzt. Damit SIP 302 ordentlich funktioniert, muss Asterisk bei der Rückmeldung an den Anbieter im SIP-Header die korrekte Identität des Anschlussinhabers setzen. Sie enthält auch die IP-Adresse, mit der der Anschluss beim Provider angemeldet ist. Allerdings setzt Asterisk in NAT-basierten Setups den Header falsch und meldet dem Provider als Absender die lokale IP-Adresse. Der verweigert folgerichtig die Rufumleitung und das Gespräch bricht ab. Der Anrufende hört womöglich nur “Diese Rufnummer ist zurzeit nicht verfügbar”.

Das Problem ist in der Asterisk-Welt seit spätestens 2023 bekannt, und ein entsprechender Patch liegt im Bugtracker der Lösung vor [10]. Der Autor dieses Artikels hat eine gepatchte Version des betroffenen Moduls res_pjsip_nat erstellt, die das erratische Verhalten nicht mehr zeigt. Die gepatchte Version finden Sie auf der Heft-DVD dieser Ausgabe sowie im Download-Bereich zu diesem Artikel.

Sie spielen die entsprechende Library »res_pjsip_nat.so« in die FreePBX-Debian-Instanz ein und kopieren sie dort nach »usr/lib/x86_64-linux-gnu/« ins Unterverzeichnis »asterisk/modules/«. Im Anschluss starten Sie Asterisk mittels »fwconsole restart« komplett neu. Damit ist die Installation von FreePBX für den Augenblick abgeschlossen.

Ausblick

Im nächsten Teil des Workshops wird es um das Herstellen der Verbindung mit einem SIP-Trunk der Telekom gehen, um das Einrichten eingehender wie ausgehender Telefonrouten und um das Anbinden der beschriebenen Grandstream-VoIP-Wi-Fi-Telefone.

Dabei gibt es einige technische wie gesetzliche Anforderungen zu beachten. Gerade die Telekom ist in der Branche in dieser Hinsicht berüchtigt: Eine vollständige Dokumentation über die korrekte Konfiguration externer Telefonanlagen etwa für den CompanyFlex-SIP-Trunk hat der Anbieter nämlich bis heute nicht vorgelegt. Deshalb ist es bei der Telekom kompliziert, die passende Signalisierung per SIP-Header zu gewährleisten und das Setup entsprechend zum Laufen zu bringen.

Dass die vorgestellte Konfiguration TLS-Verschlüsselung nutzen soll, um sichere Telefonate zu ermöglichen, erhöht die Schwierigkeit noch weiter. Auf Grundlage des gezeigten Beispiels lässt sich die Konfiguration aber meistern. (jcb/jlu)