Open-Source-Stack für Enterprise-VoIP-Entwicklung Die richtige Wahl

Teams, die eine maßgeschneiderte VoIP-Lösung entwickeln, müssen sich für mehr als nur eine Softwarekomponente entscheiden. Obwohl einige Plattformen bereits mehrere VoIP-Aufgaben abdecken, ist es bei Enterprise-Implementierungen üblich, SIP-Routing, Anwendungslogik, Medienverarbeitung und WebRTC-Konnektivität voneinander zu trennen. Auf diese Weise kann jede Schicht unabhängig skaliert werden.

In den folgenden Abschnitten betrachten wir die Open-Source-VoIP-Projekte, die bei der Entwicklung von Enterprise-VoIP-Software immer wieder zum Einsatz kommen:

• Asterisk
• FreeSWITCH
• Kamailio
• OpenSIPS
• Janus
• LiveKit
• RTPEngine

Unser Hauptziel ist es, zu zeigen, was die einzelnen Lösungen tatsächlich leisten und wo sie am besten eingesetzt werden können. Außerdem betrachten wir, wo jede von ihnen an ihre Grenzen stößt, denn genau dieser Aspekt wird in Anbieterpräsentationen meist ausgelassen.

Die grundlegende Trennung: Signalisierung und Medien

Bevor der Vergleich der Tools beginnt, ist es sinnvoll, klar zwischen zwei Bereichen zu unterscheiden, die häufig miteinander vermischt werden: Signalisierung und Medien.

Die Signalisierung beginnt, wenn ein Telefon oder eine App signalisiert: „Ich möchte diese Nummer anrufen.“ Dabei handelt es sich um einen reinen Aushandlungsschritt, denn das System muss bestimmen, wohin der Anruf geleitet wird, wer ihn entgegennimmt und wie die Sitzung aufgebaut wird. Bei klassischem VoIP wird dies über SIP (Session Initiation Protocol) abgewickelt.

Sobald der Anruf aufgebaut ist, beginnt die Medienphase. Dabei handelt es sich um den eigentlichen Sprach- oder Videostream, bei dem Audiopakete zwischen den Endpunkten übertragen werden. Manchmal laufen sie über ein Relay. Manchmal ist eine Transkodierung erforderlich, wenn die Codecs nicht übereinstimmen.

Einige Tools übernehmen nur eine dieser Aufgaben, während andere Plattformen sowohl die Signalisierung als auch die Medienverarbeitung abdecken. Letztere vereinfachen kleinere Implementierungen, können jedoch die Skalierung und die betrieblichen Anforderungen stärker miteinander koppeln.

Asterisk

Asterisk wurde ursprünglich als Private Branch Exchange (PBX) entwickelt. Und im Kern funktioniert es auch heute noch wie eine solche. Ein wesentlicher Vorteil dieser Software besteht darin, dass sie viele Funktionen abdeckt, ohne umfangreiche individuelle Entwicklung zu erfordern.

Was kann Asterisk? Die Plattform übernimmt Anrufweiterleitung, Voicemail, IVR-Menüs und Konferenzen und kann als eigenständiger SIP-Server eingesetzt werden. Damit eignet sie sich beispielsweise für Callcenter oder Unternehmen, die ein bestehendes Legacy-Telefonsystem ersetzen möchten.

Asterisk basiert auf dem Dialplan-Modell. Dadurch wird die Verwaltung schwieriger, sobald Tausende gleichzeitige Anrufe eine komplexe Routing-Logik erfordern. Dieser Nachteil wird mit zunehmender Komplexität der Routing-Logik, Mandantentrennung und steigendem Signalisierungsvolumen deutlicher. Teams, die sich mit der Asterisk-Entwicklung beschäftigen, lösen dieses Problem bei großen Systemen in der Regel, indem sie mehrere Instanzen hinter einem SIP-Proxy betreiben. So bleibt Asterisk auf Anwendungsdienste wie IVR, Warteschlangen, Konferenzen und Voicemail fokussiert.

Trotz dieser Einschränkungen eignet sich die Plattform für kleine bis mittelgroße Implementierungen, Callcenter und Systeme, die integrierte Telefoniefunktionen ohne umfangreiche Anpassungen benötigen.

FreeSWITCH

Diese Software wurde teilweise von ehemaligen Asterisk-Mitwirkenden entwickelt, die einen modulareren Kern schaffen wollten. FreeSWITCH funktioniert eher als Softswitch und Medienserver denn als klassische PBX. Die Architektur trennt den Kern von den einzelnen Modulen.

Die modulare Architektur von FreeSWITCH unterstützt Konferenzen, Codec-Aushandlung, Transkodierung und andere Medienanwendungen. Obwohl diese Lösung häufig für medienintensive Workloads gewählt wird, hängt ihre tatsächliche Kapazität stark von der verwendeten Codec-Kombination und den aktivierten Medienoperationen ab.

Weitere Aspekte, die beim Einsatz von FreeSWITCH berücksichtigt werden sollten:

• Für grundlegende Anwendungsfälle bietet FreeSWITCH native WebRTC-Unterstützung.
• Die Konfigurationssyntax verwendet XML-basierte Dialplans, deren Lernkurve steiler ist als bei Asterisk.
• Auch die Community-Dokumentation ist in einigen Bereichen weniger umfangreich.

Je nach Konfiguration kann FreeSWITCH als Medienserver, Konferenzserver oder B2BUA eingesetzt werden und einige SBC-ähnliche Funktionen übernehmen. Häufig wird FreeSWITCH als Medienserver hinter einer Kamailio-Signalisierungsschicht eingesetzt.

Kamailio

Kamailio ist ein SIP-Proxy, Registrar und Router, der für eine zentrale Aufgabe entwickelt wurde: SIP-Nachrichten schnell zu verarbeiten und weiterzuleiten. Da Kamailio den RTP-Medienstrom selbst nicht verarbeitet, kann eine einzelne Instanz Zehntausende Registrierungen und ein hohes Volumen an Signalisierungsverkehr bewältigen. Kamailio befindet sich am Netzwerkrand: Es entscheidet, wohin Anrufe geleitet werden, verteilt die Last auf Backend-Medienserver und setzt Routing-Richtlinien durch.

Genau dieser enge Fokus ist ein zentraler Bestandteil des Designs. Die Konfigurationssprache von Kamailio, kamailio.cfg, ist leistungsfähig, verzeiht jedoch kaum Fehler. Schon ein kleiner Fehler in der Routing-Logik kann dazu führen, dass Anrufe abgebrochen werden oder – noch problematischer – die Möglichkeit für Toll Fraud entsteht. Deshalb ist das Testen hier wichtiger als bei den meisten anderen VoIP-Komponenten.

Kamailio eignet sich besonders für SIP-Routing mit hohem Datenaufkommen, Load Balancing zwischen Medienservern und Signalisierungsschichten auf Carrier-Niveau.

OpenSIPS

OpenSIPS hat mit Kamailio einen gemeinsamen Ursprung: das OpenSER-Projekt, das vor Jahren in separate Projekte aufgeteilt wurde. Funktional gibt es viele Überschneidungen: Beide sind SIP-Proxys, die selbst keine Medien verarbeiten, und beide lassen sich gut skalieren, wenn die Workload ausschließlich aus Signalisierung besteht. Unterschiede gibt es vor allem bei den Tools und der zugrunde liegenden Philosophie.

OpenSIPS verfügt über eine Management-Schnittstelle, das MI/JSON-Interface. Einige Teams finden es dadurch einfacher, OpenSIPS in externe Systeme zu integrieren. Darüber hinaus bietet es integrierte Unterstützung für NoSQL-Backends zur Speicherung von Registrierungsdaten, was bei großen verteilten Implementierungen relevant sein kann. Während Kamailio über eine größere Community und mehr Dokumentation von Drittanbietern verfügt, bietet OpenSIPS eine Management-Schnittstelle, mit der einige Teams lieber direkt arbeiten.

OpenSIPS und Kamailio eignen sich grundsätzlich für dieselben Anwendungsfälle. Es lohnt sich, beide Lösungen zu evaluieren, bevor eine endgültige Entscheidung getroffen wird, da eine spätere Migration zwischen ihnen aufwendig ist und nur wenige Teams diesen Aufwand zweimal betreiben möchten.

Janus

Janus ist kein weiterer SIP-Server, sondern dient als WebRTC-Gateway. Seine Hauptaufgabe besteht darin, browserbasierte Echtzeitkommunikation mit anderen Protokollen und Topologien zu verbinden. Janus arbeitet mit verschiedenen Plugins:

• eines verwaltet Videoräume
• eines übernimmt das SIP-Gatewaying
• eines streamt aufgezeichnete Inhalte.

Entwickler bauen auf Janus auf, anstatt es wie eine PBX zu konfigurieren.

Janus stellt Bausteine für SIP-Gatewaying, Aufzeichnung, Streaming und SFU-basierte Videoräume bereit. Im Vergleich zu LiveKit müssen Teams jedoch in der Regel einen größeren Teil der umgebenden Anwendungsschicht selbst entwickeln. Dazu gehören die Raum-Orchestrierung, Benutzerverwaltung, Anwendungs-APIs und clientseitige Produkt-Workflows.

Janus eignet sich für WebRTC-Gateways und individuelle Video- oder Audioanwendungen. Wenn eine detaillierte Kontrolle auf Plugin-Ebene wichtiger ist als eine verwaltete SDK-Erfahrung, ist diese Software eine passende Lösung.

LiveKit

LiveKit verfolgt einen anderen Ansatz. Es handelt sich um eine in Go entwickelte WebRTC Selective Forwarding Unit (SFU). LiveKit wurde für Skalierbarkeit entwickelt und bietet sowohl einen Open-Source-Kern als auch eine gehostete Cloud-Option. Während Janus von Teams die Entwicklung eigener Plugins erwartet, stellt LiveKit Client-SDKs für Web-, Mobile- und native Plattformen bereit. Hinzu kommen Server-APIs für Raumverwaltung, Aufzeichnung und die Ausgabe in Dateien oder Streams.

LiveKit unterstützt verteilte und Multi-Region-Implementierungen. Beim Self-Hosting müssen Teams diese Infrastruktur jedoch selbst konfigurieren und betreiben. Räume können auf verschiedene Nodes verteilt werden. Dabei wird jeder einzelne Raum einem einzigen Node zugewiesen, weshalb die Kapazität für große Räume weiterhin sorgfältig durch Benchmarks geprüft werden muss.

LiveKit eignet sich für browserbasierte und mobile Video- oder Audioanwendungen. Für Teams, die einen SDK-first-Ansatz bevorzugen, anstatt Plugin-Logik von Grund auf selbst zu entwickeln, ist diese Lösung eine gute Wahl.

RTPEngine

RTPEngine ist ein Media Relay. Es wurde von Sipwise entwickelt und wird zusammen mit einem SIP-Proxy wie Kamailio oder OpenSIPS eingesetzt. RTPEngine verarbeitet den eigentlichen RTP-Medienstrom, einschließlich NAT-Traversal, Transkodierung, Aufzeichnung und Verschlüsselung (SRTP/DTLS) für die WebRTC-zu-SIP-Anbindung.

Wie bereits erwähnt, verarbeiten Kamailio und OpenSIPS selbst keine Medien. Dennoch muss der Medienstrom weitergeleitet werden – und genau deshalb spielt RTPEngine in Enterprise-VoIP-Stacks eine wichtige Rolle. Dies ist besonders relevant, wenn sich Endpunkte hinter NAT befinden oder eine Transkodierung zwischen nicht kompatiblen Codecs erforderlich ist. RTPEngine erledigt dies, wenn möglich, im Kernel Space. Dadurch bleibt die Latenz auch bei einem hohen Anrufvolumen niedrig.

Für Implementierungen mit Kamailio oder OpenSIPS, die ein dediziertes, leistungsfähiges Media Relay benötigen, anstatt den Medienverkehr über den Medienserver selbst zu routen, ist RTPEngine eine geeignete Lösung.

Die folgende vereinfachte Kamailio-Route zeigt, wie die SIP-Schicht RTPEngine anweisen kann, SDP umzuschreiben und die Medienübertragung zu verankern, ohne RTP selbst weiterzuleiten:

request_route {
    if (is_method("INVITE")) {
        if (has_body("application/sdp")) {
            if (!rtpengine_manage(
                "replace-origin replace-session-connection"
            )) {
                send_reply("500", "Media Relay Error");
                exit;
            }
        }

        t_on_reply("MEDIA_REPLY");
    }

    if (is_method("BYE")) {
        rtpengine_manage();
    }
}

onreply_route[MEDIA_REPLY] {
    if (has_body("application/sdp")) {
        rtpengine_manage(
            "replace-origin replace-session-connection"
        );
    }
}

Dieses verkürzte Beispiel lässt die Auswahl von RTPEngine-Nodes, die Behandlung von Transaktionsfehlern, NAT-Richtlinien, WebRTC-spezifische Flags und weitere Routing-Logik für den Produktivbetrieb bewusst aus. Es soll lediglich zeigen, dass Kamailio die Session über die Steuerungsschnittstelle von RTPEngine modifiziert, während die RTP-Pakete einem separaten Medienpfad folgen.

Wie das zusammenspielt

Die folgende Tabelle fasst die einzelnen Tools zusammen, die in den vorherigen Abschnitten erläutert wurden:

Eine typische Enterprise-VoIP-Architektur kombiniert diese Tools jedoch in mehreren Schichten, anstatt sich nur für eines davon zu entscheiden.

Die Signalisierung bleibt am Netzwerkrand und wird von Kamailio oder OpenSIPS übernommen. Kamailio oder OpenSIPS steuert während des Session-Aufbaus auch RTPEngine, leitet die RTP-Pakete jedoch nicht selbst weiter. Dadurch können Signalisierungs- und Medienkapazitäten unabhängig voneinander skaliert werden.

Dahinter übernehmen FreeSWITCH oder Asterisk die Anwendungslogik:

• IVR
• Voicemail
• Konferenzen

Janus oder LiveKit bleibt am WebRTC-Rand und vermittelt zwischen Browser-Clients und dem SIP-Core, wenn das Produkt browserbasierte Anrufe unterstützen soll.

Das Engineering-Team von Chudovo hat Varianten dieses mehrschichtigen Ansatzes bei Telekommunikationsprojekten eingesetzt, bei denen das Signalisierungsvolumen und die Medienverarbeitung unabhängig voneinander skaliert werden mussten. Bei einem dieser Projekte führte die Verlagerung des SIP-Registrars vom Medienserver dazu, dass während der Spitzenzeiten weniger Registrierungsfehler auftraten, da der REGISTER-Traffic nicht mehr mit aktiven Anrufen um CPU-Ressourcen konkurrierte.

Das folgende vereinfachte Kamailio-Snippet zeigt, wie ein Registrar die Kontaktdaten von Endpunkten speichern und ein INVITE an einen registrierten Benutzer weiterleiten kann. Dieses Beispiel erhebt keinen Anspruch darauf, produktionsreifer Code zu sein, da Authentifizierung, Autorisierung und weitere Aspekte, die in einer Produktionsumgebung berücksichtigt werden müssen, bewusst ausgelassen wurden. Dazu gehören unter anderem Transaktions- und Dialogverarbeitung, Record-Route-Logik, NAT-Traversal, Rate Limiting, Accounting, Media-Relay-Steuerung sowie die korrekte Verarbeitung von In-Dialog-Anfragen, CANCEL- und ACK-Nachrichten.

route {
    if (is_method("REGISTER")) {
        save("location");
        exit;
    }

    if (is_method("INVITE")) {
        if (!lookup("location")) {
            sl_send_reply("404", "Not Found");
            exit;
        }
        t_relay();
        exit;
    }

    sl_send_reply("405", "Method Not Allowed");
}

Abwägungen und Einschränkungen

Es gibt einige Einschränkungen, die in den meisten Anbietervergleichen nicht erwähnt werden. Daher lohnt es sich, sie direkt anzusprechen.

1. Kamailio und OpenSIPS setzen voraus, dass jemand im Team über fundierte SIP-Kenntnisse verfügt. Eine häufige Ursache für Vorfälle im Produktivbetrieb ist eine fehlerhafte Routing-Konfiguration.
2. Mit zunehmender Komplexität des Routings, steigender Mandantenzahl und wachsenden Integrationsanforderungen können Asterisk-Dialplans schwer zu warten sein. Daher ist es wichtig, die Anrufkapazität separat zu benchmarken, um die erwarteten Codecs, Aufzeichnungseinstellungen und Medienoperationen unter realistischen Bedingungen zu testen.
3. Da die Dokumentation von FreeSWITCH einige Lücken aufweist, greifen Teams bei speziellen Anwendungsfällen häufig auf Community-Foren oder kostenpflichtige Supportverträge zurück.
4. Im Vergleich zu Janus erfordert LiveKit in der Regel weniger individuelle Entwicklung für Raum-Orchestrierung, Benutzerverwaltung, Anwendungs-APIs und clientseitige Workflows.
5. LiveKit ist kein direkter Ersatz für SIP. Für die Anbindung an das PSTN wird weiterhin eine SIP-fähige Komponente benötigt.
6. RTPEngine erfordert ein von der SIP-Schicht getrenntes Monitoring und eine separate Kapazitätsplanung, wodurch eine zusätzliche betriebliche Abhängigkeit entsteht. Teams berücksichtigen dies manchmal erst, wenn ein Vorfall das Problem sichtbar macht.

Den richtigen Ausgangspunkt wählen