FreeSWITCH oder Asterisk? Warum wir gewechselt haben – und nicht bereuen
„Wenn du das auf Asterisk aufbauen willst, dann ohne mich."
Das sagte unser leitender Ingenieur, als wir zum ersten Mal ernsthaft über eine Multi-Mandanten-Telefonanlage für mehrere Kunden nachgedacht haben. Es war keine Übertreibung. Es war eine ehrliche Einschätzung von jemandem, der Asterisk von innen kennt – und der genau wusste, was uns das kosten würde.
Dieser Artikel ist kein theoretischer Vergleich. Er ist ein Erfahrungsbericht – ergänzt um konkrete technische Fakten, die die Entscheidung erklären. Wir erzählen, wie wir von proprietären Systemen über Asterisk zu FreeSWITCH und FusionPBX gekommen sind, was die Zahlen sagen – und warum wir nach vielen Jahren im Produktivbetrieb diese Entscheidung nicht bereuen.
Der Weg: Von H.323 bis FusionPBX
Die Anfänge: Teles iPBX mit H.323
In den späten 1990er-Jahren haben wir unsere ersten internationalen Standorte mit einer Teles iPBX auf Basis von H.323 verbunden. Damals war das State of the Art. VoIP war neu, die Protokolle waren komplex, und wer es zum Laufen brachte, hatte einen echten Wettbewerbsvorteil.
Die Welt hat sich seitdem verändert. SIP hat H.323 weitgehend verdrängt. Und die Frage war nicht mehr, ob man VoIP einsetzt – sondern auf welcher Basis.
Asterisk: leistungsfähig, aber aufwendig
Der nächste Schritt war Asterisk auf Linux – mit selbst geschriebenen Dialplänen. Wer Asterisk kennt, weiß, was das bedeutet: eine eigenwillige Dialplan-Sprache, die mächtig ist, aber fehleranfällig. Jede Änderung musste sorgfältig getestet werden. Jeder neue Anwendungsfall bedeutete neue Konfigurationsarbeit. Die Administration war aufwendig, und das Fehlerpotenzial war real.
Asterisk war kein schlechtes System. Es war – und ist – das am weitesten verbreitete Open-Source-PBX-Projekt weltweit, mit einer riesigen Community und einem breiten Modul-Ökosystem. Für kleine und mittlere Installationen bis etwa 200–500 gleichzeitige Gespräche ist es heute noch eine valide Wahl. Aber es hat Grenzen, die man erst sieht, wenn man dagegen stößt.
Gemeinschaft: Asterisk mit Komfort
Um 2008/2009 haben wir auf die Telefonanlage Gemeinschaft gewechselt – eine damals verbreitete deutschsprachige PBX-Lösung auf Asterisk-Basis. Weniger Rohkonfiguration, mehr Oberfläche. Das war ein Fortschritt.
Aber die Basis blieb Asterisk. Und mit wachsender Kundenzahl wurde die eigentliche Frage immer drängender: Wie betreibt man eine Anlage für viele Kunden – wirklich sauber, wirklich getrennt, wirklich skalierbar?
Das Problem: Asterisk und Multi-Mandanten
Als unsere Kundenbasis wuchs, stellten wir fest: Multi-Mandanten-Betrieb ist in Asterisk nicht nativ vorgesehen. Er wird herangebaut – durch zusätzliche Schichten, Workarounds und Eigenentwicklungen.
Wir haben uns umgeschaut. Wir haben Lösungen evaluiert. Das Ergebnis: Fast alle Multi-Mandanten-Lösungen auf Asterisk-Basis sind nachträglich drum herum programmiert. Kein natives Konzept, sondern ein Pflaster auf einer Architektur, die für etwas anderes gebaut wurde.
Dazu kam ein zweites Problem, das unser leitender Ingenieur so formulierte:
„Der Sourcecode von Asterisk ist ein echter Spaghetticode. Die Dokumentation ist dürftig. Wenn du auf dieser Basis eine Multi-Mandanten-Anlage für viele Kunden aufsetzen willst, dann ohne mich. Das ist der Untergang."
Das war kein Pessimismus. Es war Erfahrung – und sie hat einen technischen Hintergrund, der sich in Zahlen ausdrücken lässt.
Die Architektur dahinter: warum das kein Zufall ist
Asterisk wurde 1999 von Mark Spencer entwickelt – als erstes verbreitetes Open-Source-PBX-Projekt. Es ist über Jahrzehnte gewachsen, mit vielen Entwicklern und wenig zentraler Architektur. Der Kern verwaltet aktive Gesprächskanäle über Linked Lists mit Mutex-Locking – ein Modell, das bei kleinen Lasten funktioniert, aber bei hoher Nebenläufigkeit zu CPU-Spitzen durch Lock-Contention führt. Je mehr gleichzeitige Gespräche, desto mehr kämpfen die Threads um dieselben Ressourcen.
FreeSWITCH wurde 2006 von Anthony Minessale und anderen ehemaligen Asterisk-Entwicklern gegründet – explizit mit dem Ziel, die Architekturprobleme von Asterisk zu lösen. Das Ergebnis ist fundamental anders: Jede Call-Leg läuft in einem eigenen dedizierten Thread durch eine State Machine (init, routing, execute, hangup, reporting, destroy). Signaling und Media-Processing laufen in getrennten Threads. Statt zentraler Locks ein Shared-Nothing-Ansatz mit Hash-Table-Lookups.
Das ist keine theoretische Unterscheidung. Sie zeigt sich in konkreten Zahlen.
Die Hard Facts: Kanaldichte und Performance im Vergleich
| Kriterium | Asterisk | FreeSWITCH |
|---|---|---|
| Gleichzeitige Calls (8-Core-Server, Standard-Codecs) | ca. 1.500–3.000 | ca. 5.000–10.000 |
| Calls pro Core (relativ) | Baseline | ca. 2–3× mehr SIP-Sessions pro Core |
| RAM-Verhalten unter Last | steigt überproportional durch Lock-Contention | geringerer Overhead durch Thread-Isolation |
| KI-Voice-Workloads (Streaming STT/TTS, 16 vCPU/32 GB) | stabile Kapazität bis ca. 250–350 gleichzeitige Sessions | deutlich höhere stabile Kapazität |
| Praktischer Flaschenhals | zentrale Channel-Locks/Mutexes | RTP-Media-Pfad (Bandbreite, Packets-per-Second) |
| Kleine Deployments (50–200 Calls) | vollständig ausreichend | kein praktischer Unterschied |
| Multi-Tenant nativ | nein – wird herangebaut | ja – Kernarchitektur |
Hinweis: Exakte Werte schwanken je nach Codec-Mix, Netzwerkbedingungen und Hardware. Für belastbare Zahlen auf eigener Hardware empfiehlt sich ein Lasttest mit SIPp.
Die Schlussfolgerung: Für kleine Einzelinstallationen bis 200–500 gleichzeitige Gespräche sind beide Systeme praktisch gleichwertig. Ab 1.000+ gleichzeitigen Calls – und erst recht für Multi-Tenant-Betrieb mit vielen Kunden – ist FreeSWITCH strukturell im Vorteil.
Programmieren kostet Zeit – und löst das falsche Problem
Vor allem aber haben wir uns eine grundsätzlichere Frage gestellt: Wohin soll unsere Entwicklungszeit fließen?
Wir hätten die fehlende Multi-Mandanten-Fähigkeit selbst drum herum programmieren können. Andere haben das getan. Aber das wäre Zeit gewesen, die wir in Eigenentwicklungen stecken, die ein Fundament-Problem kaschieren – statt echten Mehrwert für unsere Kunden zu schaffen.
Unsere Prioritäten lagen woanders: eine benutzerfreundliche Oberfläche, die Administratoren wirklich abnimmt. Softphone-Clients, die Endnutzer gerne benutzen. Integrationen, die Kunden in ihrer täglichen Arbeit weiterbringen – CRM-Anbindungen, Callcenter-Funktionen, KI-Schnittstellen. Ein Ökosystem, das auf echten Kundenanforderungen basiert, nicht auf dem Flicken einer Architektur.
Programmieren rund um ein strukturelles Problem ist keine Lösung für die Zukunft. Es ist technische Schuld, die sich mit jedem neuen Kunden und jedem neuen Feature verzinst. Wir wollten unsere Energie in Dinge stecken, die skalieren – nicht in Workarounds, die bremsen.
Das war der eigentliche Grund für den Wechsel. Nicht nur die Technik. Die Frage, wo wir in fünf Jahren stehen wollen.
Die Entscheidung: FreeSWITCH und FusionPBX
Also haben wir recherchiert. Und wir haben FreeSWITCH gefunden – und damit FusionPBX als Verwaltungsschicht darüber.
Was uns überzeugt hat, war nicht nur die Architektur. Es war auch die Programmierbarkeit: FreeSWITCH bietet eine mächtige Event Socket Library (ESL), die sprachagnostisch ist und gut mit Automatisierungstools wie n8n zusammenspielt. Der XML-Dialplan ist für programmatische Generierung ausgelegt. WebRTC-Unterstützung läuft heute nativ über mod_sofia – FreeSWITCH ist damit eine der wenigen Telefonie-Engines, die SIP und WebRTC aus demselben Stack heraus bedient.
FreeSWITCH ist nativ multi-mandantenfähig. Kein Workaround, kein Pflaster. Das ist kein Feature – das ist das Design.
FreeSWITCH ist ein Level-4/5-Switch. Dieselbe Engine, die in unserer Unternehmensanlage läuft, läuft in Vermittlungszentralen von Telekommunikationsanbietern. Carrier-grade-Architektur, nicht Unternehmens-Kompromiss.
Der Sourcecode ist modular und sauber. Unser leitender Ingenieur hat sich den Code angeschaut – und diesmal war sein Urteil ein anderes: „Das ist eine Basis für die Zukunft."
Der Nachteil war real: Das Ökosystem rund um FreeSWITCH war damals deutlich kleiner als das um Asterisk. Weniger fertige Tools, weniger Community-Lösungen.
Aber das war für uns kein Hinderungsgrund. Es war eine Chance – und diesmal die richtige Art von Eigenentwicklung: nicht das Flicken einer Architektur, sondern das Aufbauen eines Ökosystems auf einem soliden Fundament. Diese Entscheidung, und die Möglichkeit, darauf echte Lösungen zu entwickeln, hat sich von Anfang an richtig angefühlt. Nicht blind optimistisch – sondern mit der Überzeugung, endlich auf der richtigen Basis zu stehen.
Was daraus geworden ist
Seitdem betreiben wir FusionPBX mit FreeSWITCH als Basis – und wir haben aktiv zu den Projekten beigetragen, sie optimiert und gepflegt. Das ist kein Zufall: Wer auf Open Source setzt und wirklich von der Plattform abhängt, hat ein Interesse daran, dass sie besser wird.
Aus dieser Praxis heraus ist die acall VoIP-Toolbox entstanden: die REST-API, die Softphone-Clients, der Edge SBC, das MS-Teams-Gateway, die Abrechnungsplattform. Alles, was fehlte, um aus dem rohen FreeSWITCH/FusionPBX-Fundament ein vollständiges, betreibbares Provider-Geschäft zu machen – haben wir selbst gebaut.
Nicht als Workaround. Als echtes Produkt, das auf Kundenwünschen basiert und sich im Produktivbetrieb bewiesen hat.
Und nach all dieser Zeit können wir sagen: Es war die richtige Entscheidung. Nicht weil alles einfach war – es gab Lernkurven, Rückschläge und Momente, in denen das kleinere Ökosystem spürbar war. Sondern weil die Grundlage gestimmt hat. Weil wir unsere Energie in das gesteckt haben, was zählt: Lösungen, die Kunden wirklich helfen, und ein Ökosystem, das mit ihren Anforderungen gewachsen ist – statt gegen die eigene Architektur zu kämpfen.
Wo stehen beide Projekte heute – und wohin geht die Reise?
Das ist eine Frage, die wir ehrlich beantworten müssen. Beide Projekte haben ein reales, kommerziell abgesichertes Zukunftsszenario.
FreeSWITCH / SignalWire
FreeSWITCH bleibt als offene, MPL-lizenzierte Engine bestehen und wird aktiv vom Gründerteam über SignalWire gepflegt. Der eigentliche Innovationsschub findet zunehmend in der kommerziellen SignalWire-Cloud-Schicht statt: programmierbare Call-Control per SWML, ein No-Code-AI-Agent-Builder, ein „Call Fabric" genanntes UC-Framework sowie ein eigener Voice-AI-Stack mit Fokus auf niedrige Latenz.
SignalWire hat 2021/2022 strategische Investments von Deutsche Telekom (Dezember 2021) und T-Mobile Ventures (Series B, abgeschlossen März 2022) erhalten – ein klares Indiz für Carrier-Interesse an der Plattform, das bis heute trägt.
Für Betreiber wie acall, die FreeSWITCH self-hosten, bedeutet das: Die Kernengine bleibt technologisch solide und wird von denselben Leuten weiterentwickelt, die sie geschrieben haben. Wer tiefer in Richtung AI-Voice-Agents oder Multi-Tenant-Cloud will, kann optional auf die SignalWire-Schicht aufsetzen – ist aber nicht dazu gezwungen.
Asterisk / Sangoma
Asterisk bleibt mit geschätzt über einer Million aktiver Installationen die am weitesten verbreitete Open-Source-Telefonie-Engine. Sangoma investiert gezielt in generative KI oberhalb der Engine – u.a. mit „Sangoma Scribe" für Transkription und Sentimentanalyse. Parallel dazu hat sich rund um Asterisk eine wachsende Open-Source-Szene für AI-Voice-Agents gebildet, die AudioSocket-basierte Integrationen mit OpenAI Realtime und Google Gemini Live nutzt.
Sangoma positioniert sich damit ähnlich wie Red Hat bei Linux: als Unternehmen mit der engsten Beziehung zur Entwickler-Community.
Einordnung
FreeSWITCH/SignalWire treibt konsequent Richtung Cloud-native, programmierbare, latenzoptimierte AI-Kommunikationsplattform. Asterisk/Sangoma baut auf seiner riesigen installierten Basis auf und ergänzt sie modular um KI-Features, bleibt dabei aber näher an klassischer On-Premise-Logik.
Für ein souverän gehostetes, auf Skalierung und AI-Voice-Pipelines ausgelegtes Produkt wie die acall VoIP-Toolbox spricht die architektonische und strategische Ausrichtung von FreeSWITCH weiterhin für sich – insbesondere weil die Engine selbst offen und selbst hostbar bleibt, ohne Zwang zur SignalWire-Cloud.
Asterisk: wann es trotzdem die richtige Wahl ist
Zur Ehrlichkeit gehört auch das: Wir setzen Asterisk – und auch Kamailio – weiterhin ein. Für Speziallösungen, wo Asterisk seine Stärken ausspielt: bestimmte Protokoll-Szenarien, spezifische Integrationsprojekte, Umgebungen, in denen das größte Ökosystem einen konkreten Vorteil bietet.
Es geht nicht darum, Asterisk schlecht zu reden. Es geht darum, die richtige Technologie für die richtige Aufgabe zu wählen.
Für den Betrieb einer skalierbaren, multi-mandantenfähigen Plattform – für ein Systemhaus, das Telefonie für Dutzende oder Hunderte von Kunden betreiben will – ist FreeSWITCH/FusionPBX die bessere Grundlage. Das ist keine Meinung. Das sind unsere Erfahrung aus fast 40 Jahren Unternehmenstelefonie und die Zahlen, die diese Erfahrung belegen.
Was das für Ihre Entscheidung bedeutet
Wenn Sie heute vor der Frage stehen, auf welcher Basis Sie Ihre Telefoninfrastruktur aufbauen – oder Ihren Kunden Telefonie anbieten wollen – dann lohnt es sich, die richtigen Fragen zu stellen:
Brauchen Sie Multi-Mandanten-Fähigkeit? FreeSWITCH ist nativ dafür gebaut. Asterisk kann das – aber es ist konstruiert, nicht gewachsen.
Wie viele gleichzeitige Gespräche erwarten Sie? Bis 200–500: beide gleichwertig. Ab 1.000+: FreeSWITCH liegt mit 2–3× mehr Sessions pro Core strukturell vorn.
Planen Sie KI-Voice-Workloads? Streaming STT/TTS ist ressourcenintensiv. FreeSWITCH verarbeitet durch Thread-Isolation pro Channel deutlich mehr parallele AI-Sessions stabil, bevor CPU-Contention zum Problem wird.
Wollen Sie die Plattform langfristig warten und erweitern? Modularer, sauberer Code schlägt gewachsenen Monolithen – besonders wenn das Team nicht unendlich groß ist.
Wohin soll Ihre Entwicklungszeit fließen? In das Flicken einer Architektur – oder in Produkte und Integrationen, die Ihren Kunden echten Mehrwert bringen?
Ist das Ökosystem entscheidend? Dann hat Asterisk heute noch die größere Community und mehr fertige Integrationen. FreeSWITCH holt auf – und die acall VoIP-Toolbox schließt die wichtigsten Lücken für den professionellen Betrieb.
Fazit
Unser leitender Ingenieur hatte recht. Nicht weil Asterisk schlecht ist – sondern weil die Anforderung, eine skalierbare Multi-Mandanten-Plattform zu betreiben, eine Architektur braucht, die dafür gebaut wurde. FreeSWITCH ist diese Architektur. FusionPBX ist die Verwaltungsschicht darüber. Und die acall VoIP-Toolbox ist das Ökosystem, das beides für den Produktivbetrieb fertig macht.
Programmieren rund um ein Fundament-Problem löst das Problem nicht. Es verschiebt es – und macht es teurer. Wir haben uns entschieden, unsere Zeit in das zu stecken, was Kunden wirklich brauchen: eine benutzerfreundliche Oberfläche, Softphones, die funktionieren, und Integrationen, die im Alltag einen Unterschied machen.
Das war damals eine Wette auf die Zukunft. Nach vielen Jahren im Produktivbetrieb, mit einem gewachsenen Ökosystem und Kunden, die täglich darauf vertrauen, wissen wir: Es war die richtige Entscheidung.
Sie evaluieren FreeSWITCH/FusionPBX als Basis für Ihre Infrastruktur? Ein acall-Partner unterstützt bei Architektur, Migration und Betrieb. Informieren Sie sich auf acall.eu.
