Ein Artikel von Lucas Knapp, Geschäftsführer der EDNT IT-Services GmbH

Gebaut für Architekturen, an die sich Standardanbieter nicht herantrauen

Für ein Büro mit 30 Arbeitsplätzen gibt es heute Dutzende gute Telefonanlagen. Für eine Organisation mit 40 Standorten, drei Carriern, einem Callcenter, Teams-Nutzern, Notrufpflichten pro Standort und einer Unify-Landschaft, die im laufenden Betrieb abgelöst werden muss, gibt es erstaunlich wenige.

Dieser Artikel erklärt, was solche Projekte technisch ausmacht, warum die gängigen Standardprodukte dafür nicht gebaut sind und wie eine offene Plattform auf Basis von Kamailio, FreeSWITCH und FusionPBX diese Lücke schließt.

Was eine komplexe Telefonie-Architektur ausmacht

Komplex ist eine Telefonie-Umgebung nicht wegen der Zahl der Nebenstellen. Komplex wird sie durch Anforderungen, die quer zur Logik einer einzelnen Telefonanlage liegen:

Eine Anlage, die zwei oder drei dieser Punkte abdeckt, findet man leicht. Die Kombination aller Punkte ist die eigentliche Aufgabe, und sie ist eine Architekturaufgabe, keine Produktauswahl.

Wer diese Projekte bisher gebaut hat

Jahrzehntelang war die Antwort auf solche Anforderungen klar: Unify (früher Siemens Enterprise Communications), Avaya, in Teilen Cisco. Deren Großsysteme wie OpenScape Voice und OpenScape 4000, Avaya Aura oder Cisco Unified Communications Manager waren nicht als Telefonanlage gebaut, sondern als Kommunikationsarchitektur: zentrale Anrufsteuerung, eine eigene Sitzungs- und Routing-Schicht, Media-Gateways an den Standorten, Überlebensfähigkeit für Filialen bei WAN-Ausfall, Redundanz über Rechenzentren hinweg. Dazu kamen Systemhäuser mit zertifizierten Architekten, die solche Netze planen konnten.

Dieses Modell gerät von zwei Seiten unter Druck. Erstens wirtschaftlich: Avaya ist 2017 und erneut 2023 durch ein Chapter-11-Verfahren gegangen und konzentriert sich laut Branchenberichten auf seine größten Konzernkunden. Unify wurde 2023 von Atos an Mitel verkauft, und Mitel selbst hat im März 2025 Gläubigerschutz nach Chapter 11 beantragt und im Juni 2025 wieder verlassen. Zweitens durch den Lebenszyklus: Hardwaregenerationen werden abgekündigt, Lizenz- und Supportverträge müssen verlängert werden, und jeder Generationswechsel ist faktisch ein neues Projekt beim selben Hersteller.

Viele Betreiber suchen deshalb einen Nachfolger. Naheliegend wären die Anbieter, die den Mittelstandsmarkt heute dominieren. Genau dort entsteht die Lücke.

Warum Standard-Cloud- und Software-Telefonanlagen hier an Grenzen stoßen

Vorweg, weil es fair ist: Lösungen wie NFON, 3CX oder Starface sind für ihre Zielgruppe oft genau richtig. Ein Standort, 20 bis 200 Nutzer, Standardfunktionen, schneller Rollout: Das lösen sie gut. Die Grenzen, um die es hier geht, sind keine Qualitätsmängel, sondern Folgen bewusster Produktentscheidungen.

1. Das Geschäftsmodell heißt Standardisierung. NFON betreibt mit Cloudya eine selbst entwickelte, mandantenfähige Cloud-Telefonanlage mit einheitlichem, europaweitem Tarifmodell und zertifizierten Endgeräten. Gamma hat 2024 Placetel und Anfang 2025 die Starface-Gruppe übernommen und beschreibt das Ziel selbst als Führungsrolle im deutschen KMU-Cloud-Markt. Wirtschaftlich funktionieren solche Plattformen, weil alle Kunden auf demselben Funktionsumfang laufen. Eine kundenspezifische Routing-Logik für 40 Standorte ist in diesem Modell kein Feature, sondern eine Störung der Skaleneffekte.

2. Die Anlage ist ein Monolith. Software-Telefonanlagen wie 3CX oder Starface sind im Kern als eine Anlageninstanz konzipiert. Signalisierung, Medienverarbeitung, Anwendungslogik und Verwaltung laufen im selben System. Skaliert wird vertikal, also mit einem größeren Server. Selbst die Mandantenfähigkeit von 3CX bildet Kunden als Abteilungen innerhalb einer einzigen Instanz ab. Eine Architektur, in der eine SIP-Proxy-Schicht Last auf mehrere Mediaserver verteilt, ein Knoten ausfallen darf und Standorte unabhängig weitertelefonieren, lässt sich so nicht bauen.

3. Das Lizenzmodell wird zur Architekturgrenze. 3CX lizenziert nach gleichzeitigen Gesprächen in festen Stufen bis 1.024 und koppelt die Stufen inzwischen an Obergrenzen für Nebenstellen. Cloud-Anbieter rechnen pro Arbeitsplatz und Monat. Beides ist für planbare KMU-Umgebungen sinnvoll. In einer großen Umgebung entscheidet dann aber die Lizenzstufe, wie die Architektur aussieht, und nicht der Bedarf.

4. Der Kern ist geschlossen. Routing, Wählplan und Rufbehandlung lassen sich nur so weit anpassen, wie die Oberfläche des Herstellers es vorsieht. Eigene Logik im Wählplan, eigene Regeln am Session Border Controller oder eine Anbindung, die der Hersteller nicht vorgesehen hat, sind nicht möglich. Bei Sonderanforderungen lautet die Antwort deshalb oft: geht nicht, oder später, wenn genug Kunden danach fragen.

5. Betrieb und Sicherheit folgen dem Hersteller. Eine reine Cloud-Lösung lässt sich nicht im eigenen Rechenzentrum oder in einer abgeschotteten Umgebung betreiben. Updates kommen im Takt des Herstellers. Und geschlossener Code kann nur der Hersteller selbst prüfen. Wie heikel das ist, zeigte 2023 der Lieferkettenangriff auf die 3CX-Desktop-App, die über einen kompromittierten Build-Prozess mit Schadcode signiert ausgeliefert wurde. Auch Open-Source-Software hat Lieferkettenrisiken, aber dort kann jeder den Code prüfen und jeder Betreiber selbst entscheiden, wann er welche Version einspielt.

6. Der Partnerkanal ist auf Volumen optimiert. Partnerprogramme von Volumenanbietern belohnen viele, schnell ausgerollte Standardinstallationen. Die Fähigkeit, eine Unify-Architektur mit QSIG-Vernetzung, Media-Gateways und Sonderverkabelung zu analysieren und schrittweise abzulösen, wird dort weder verlangt noch aufgebaut.

Das Ergebnis ist eine Marktlücke: Die alten Enterprise-Hersteller sind teuer und unsicher geworden, die neuen Volumenanbieter sind für diese Projekte nicht gebaut.

Die Architektur der acall-Plattform

Die Plattform der acall Technologies GmbH greift das Prinzip der klassischen Enterprise-Systeme auf, eine Trennung in Schichten, und setzt es mit Open-Source-Komponenten um, die weltweit bei Carriern und Providern im Einsatz sind.

Der entscheidende Unterschied zu einer monolithischen Anlage: Jede Schicht hat eine klar abgegrenzte Aufgabe, lässt sich unabhängig dimensionieren und fällt nicht automatisch mit den anderen aus.

Signalisierung: Kamailio als Verkehrsleitzentrale

Kamailio ist ein SIP-Proxy, der bei Carriern und großen VoIP-Providern Millionen Registrierungen und Verbindungsaufbauten verarbeitet. In der Plattform übernimmt er Registrierung, Routing und Lastverteilung. Er entscheidet, welcher Medienknoten einen Anruf bearbeitet, nimmt ausgefallene Knoten automatisch aus der Verteilung und schützt die dahinterliegenden Systeme mit Rate Limiting und Plausibilitätsprüfungen vor Registrierungsfluten und Missbrauch. Weil Kamailio selbst zustandsarm arbeitet, lässt sich diese Schicht redundant betreiben, ohne dass Gespräche an einen bestimmten Server gebunden sind.

Anwendung und Medien: FreeSWITCH als skalierbare Telefonie-Engine

FreeSWITCH verarbeitet Sprache und Anwendungslogik: Wählpläne, Sprachmenüs, Warteschlangen, Konferenzen, Aufzeichnung, Fax und Transkodierung. Der Wählplan ist nicht auf vordefinierte Optionen beschränkt, sondern lässt sich mit Skriptlogik erweitern. Damit sind Sonderfälle lösbar, die in geschlossenen Anlagen am Funktionskatalog scheitern: zeit- und standortabhängiges Routing über Dutzende Rufnummernblöcke, Abfragen gegen Fachverfahren vor der Rufzustellung oder Notrufrouting pro Standort. Mehr Last bedeutet einen weiteren FreeSWITCH-Knoten, nicht einen größeren Server.

Netzgrenze: Session Border Controller und Teams-Gateway

Zwischen Plattform und Außenwelt steht der acall Edge-SBC. Er trennt Carrier-Verkehr und Kundeninstanzen sauber, verbirgt die interne Topologie und stellt Trunks zentral bereit. Für Microsoft Teams nutzt die Plattform ein eigenes Direct-Routing-Gateway auf Basis von Kamailio. Teams-Nutzer und klassische Tischtelefone teilen sich so denselben Wählplan und dieselben Durchwahlen. In Carrier-Szenarien deckt die Kombination aus SBC und Routing-Schicht auch Transitaufgaben ab, also das, was in der Telekommunikation als Class-4-Funktion bezeichnet wird, während die Telefonanlagenfunktionen der Class 5 in der Anwendungsschicht liegen.

Verwaltung und Integration: FusionPBX und REST-API

FusionPBX bildet Mandanten als eigene Domänen ab, jeweils mit eigenem Wählplan, eigenen Nutzern, Rechten und Ansagen. Für eine Kommune heißt das: Rathaus, Bauhof, Schulen und Eigenbetriebe laufen getrennt verwaltbar auf einer Plattform. Die acall REST-API mit OpenAPI-Dokumentation öffnet die Telefonie für Drittsysteme: Click-to-Dial, Präsenz, Gesprächsdaten, automatisierte Anlage von Nebenstellen, Übergabe an KI-Dienste und Voicebots.

Betrieb: dort, wo die Daten hingehören

Die Plattform läuft beim Kunden im eigenen Rechenzentrum, auf der Infrastruktur von EDNT in Deutschland oder verteilt über beide. Weil alle Komponenten offen sind, gibt es keinen technischen Grund, Gesprächs- und Verbindungsdaten außerhalb des eigenen Einflussbereichs zu verarbeiten. Für abgeschottete Umgebungen bleibt die Plattform vollständig ohne Hersteller-Cloud betreibbar.

Typische Projekte, die diese Architektur löst

Aus der Praxis: Reifen Lorenz Der Reifenhändler hat seine Unify-Telefonanlage abgelöst und telefoniert heute an über 30 Standorten über die acall-Plattform. Planung, Migration und Betrieb kamen von EDNT und acall.

Migration aus Unify- und Avaya-Landschaften

Große Bestandsanlagen werden nicht an einem Stichtag abgeschaltet, sondern in Etappen abgelöst. Bewährt hat sich ein Ablauf in sechs Schritten:

1. Bestandsaufnahme der Architektur: Anlagen, Vernetzung (QSIG oder SIP), Media-Gateways, Rufnummernblöcke, Carrier, Sonderanschlüsse wie Aufzugsnotruf, Brandmeldeanlage, Fax und Türsprechstellen.
2. Zielarchitektur: Dimensionierung der Schichten, Redundanzkonzept, Mandantenstruktur, Trunk- und Routingkonzept, Integration von Teams und Fachverfahren.
3. Koexistenz herstellen: Die neue Plattform wird per SIP mit der Bestandsanlage gekoppelt. Interne Durchwahlen funktionieren über beide Systeme hinweg.
4. Standortweiser Umzug: Standorte oder Organisationseinheiten wechseln nacheinander, jeweils mit Test und Rückfallebene.
5. Carrier und Rufnummern: Trunks werden umgestellt, Rufnummernblöcke portiert, Notrufzuordnungen pro Standort geprüft.
6. Rückbau: Erst wenn der letzte Standort umgezogen ist, wird die Bestandsanlage abgeschaltet.

Analog- und Sonderanschlüsse bleiben dabei nicht auf der Strecke: Sie werden über Gateways an die Plattform angebunden, statt den Umstieg zu blockieren.

Warum acall und EDNT diese Projekte gut können

Hersteller und Systemhaus aus einer Hand. acall entwickelt die Plattform, EDNT plant, migriert und betreibt sie. Beide Unternehmen sitzen in Bensheim. Wenn ein Projekt eine Funktion braucht, die es noch nicht gibt, entscheidet nicht ein Produktmanagement auf einem anderen Kontinent über die Priorität, sondern das Team, das den Code schreibt, setzt es um.

Tiefe im technischen Kern. acall bietet Third-Level-Support und Beratung für FreeSWITCH und FusionPBX an, also genau dort, wo Standardpartner das Ticket an den Hersteller weiterreichen. Fehleranalysen enden bei uns nicht an der Oberfläche, sondern im SIP-Trace und im Quellcode.

Infrastruktur aus derselben Hand. Telefonie ist nur so gut wie das Netz darunter. EDNT ist offizieller Partner von OPNsense und Proxmox und betreibt Firewall, Virtualisierung und Telefonie aus einer Hand, auf eigener Infrastruktur im ISO-27001:2022-zertifizierten Rechenzentrum der pfalzkom in Deutschland, ergänzt durch den Standort in Bensheim. Quality of Service, Netzsegmentierung und Hochverfügbarkeit werden gemeinsam geplant und nicht zwischen drei Dienstleistern abgestimmt.

Betrieb rund um die Uhr. Feste Ansprechpartner, 24/7-Support und Monitoring der gesamten Kette vom Trunk bis zum Endgerät.

Wissen, das beim Kunden bleibt. In der EDNT Akademie schulen Techniker, die diese Systeme täglich betreiben, die Administratoren des Kunden. Wer den eigenen Betrieb übernehmen will, kann das.

Was bedeutet das für Ihr Unternehmen?

Dieser Abschnitt ist für die Geschäftsführung.

• Risiko: Ihre Kommunikationsarchitektur hängt heute oft an einem Hersteller, der wirtschaftlich unter Druck steht oder Produktgenerationen abkündigt. Eine offene Plattform nimmt diese Abhängigkeit aus der Gleichung.
• Kosten: Keine Lizenzstufen, die die Architektur diktieren. Sie bezahlen Planung, Migration und Betrieb, nicht das Recht, Ihre eigene Telefonie zu nutzen.
• Handlungsfähigkeit: Neue Standorte, Teams, Callcenter oder KI-Anbindung werden zu Konfigurations- und Integrationsaufgaben, nicht zu Verhandlungen mit einem Hersteller.
• Souveränität: Betrieb in Deutschland oder im eigenen Rechenzentrum, offener Code, deutscher Vertragspartner und Hersteller in Bensheim.

Häufige Fragen

Ist eine Open-Source-Telefonanlage für mehrere Tausend Nutzer geeignet?

Ja. Kamailio und FreeSWITCH laufen weltweit bei Carriern und großen Providern. Entscheidend ist nicht die Software, sondern die Architektur: Mit getrennter Signalisierungs- und Medienschicht wächst die Plattform horizontal, statt an die Grenzen eines einzelnen Servers zu stoßen.

Kann die neue Plattform parallel zu unserer Unify- oder Avaya-Anlage laufen?

Ja. Über eine SIP-Kopplung arbeiten beide Systeme während der Migration zusammen. Standorte ziehen nacheinander um, interne Durchwahlen funktionieren über beide Welten hinweg.

Wie wird Microsoft Teams eingebunden?

Über ein Direct-Routing-Gateway auf Basis von Kamailio. Teams-Nutzer erhalten ihre Durchwahl und sind in denselben Wählplan eingebunden wie klassische Tischtelefone.

Wer ist verantwortlich, wenn etwas nicht funktioniert?

EDNT betreibt die Plattform und ist Ihr Ansprechpartner. Liegt die Ursache im Code, geht der Fall direkt an das Entwicklungsteam von acall, ohne Umweg über eine Hersteller-Hotline.

Nächster Schritt

Sie betreiben eine komplexe Telefonie-Landschaft, stehen vor einem Generationswechsel oder suchen einen Nachfolger für Unify oder Avaya? In einem Architektur-Workshop analysieren wir Ihre Umgebung und skizzieren die Zielarchitektur. Der Einstieg ist der kostenlose Migrations-Check: 30 Minuten mit einem Techniker, unverbindlich.

Lieber direkt sprechen? Rufen Sie uns an unter 06251 8405-600 oder schreiben Sie an vertrieb@ednt.de.