Zum Inhalt springen
Azorel PBX — Startseite
04.1Architektur-Explorer

Folgen Sie dem Anruf.

Wählen Sie eine Komponente, um zu sehen, was sie tut und mit wem sie spricht — oder starten Sie die Wiedergabe und verfolgen Sie einen Anruf durch AZOREL PBX, Signalisierung und Medien jeweils auf ihrem eigenen Weg.

Komponenten

Wählen Sie eine Komponente im Diagramm oder in der Liste.

Textbeschreibung der Architektur

Telefone & Softphones — SIP-Endgeräte
SIP-Endgeräte, registriert als Nebenstellen. Sie erreichen die Plattform nur über OpenSIPS (Signalisierung, unverschlüsselt oder TLS) und RTPengine (Medien). Unterstützte Geräte laden ihre Konfiguration automatisch über HTTPS: Yealink-Vorlagen, mobile Softphones per QR-Code.
  • → OpenSIPS: SIP-Signalisierung — SIP von Telefonen und Softphones (UDP, TCP oder TLS)
  • → RTPengine: RTP-Medien — RTP-Sprache von und zu Telefonen
  • → Reverse Proxy: Provisionierung (HTTPS) — Geräte laden ihre Konfiguration
SIP-Trunks — Netzbetreiber
SIP-Trunks mit Authentifizierung per Registrierung oder IP. Eingehende Anrufe werden nach Durchwahl (DID) und Anrufer-ID zugeordnet; ausgehende folgen Wählmustern mit Ziffernumschreibung und Trunk-Auswahl. Der Live-Status kommt von FreeSWITCH.
  • → OpenSIPS: SIP-Signalisierung — SIP von und zu Netzbetreibern
  • → RTPengine: RTP-Medien — RTP-Sprache von und zu Netzbetreibern
OpenSIPS — SIP-Grenze
SIP-Grenze / Session Border Controller. Beendet öffentliches TLS, verwirft fehlerhafte SIP-Nachrichten, setzt ACLs, Anfragebegrenzung, GeoIP-Regeln und Sperren durch und verbirgt die interne Topologie. Kein Registrar: REGISTER und neue Dialoge werden an FreeSWITCH weitergeleitet. Seinen Live-Zustand erhält er vom Backend, und er richtet für jeden Anruf das Medien-Relay in RTPengine ein.
  • → FreeSWITCH: SIP-Signalisierung — SIP, weitergeleitet im internen Netz
  • → RTPengine: Steuerung — Richtet jedes Medien-Relay ein und baut es ab
RTPengine — Mediengrenze
Medien-Relay an der Netzgrenze. Jeder RTP-Strom zwischen Außenwelt und Anrufmaschine läuft hier hindurch; FreeSWITCH sendet oder empfängt nie Medien im öffentlichen Internet. OpenSIPS richtet jedes Relay über das Steuerprotokoll von RTPengine ein und baut es ab; auch die NAT-Behandlung der Medien geschieht hier.
  • → FreeSWITCH: RTP-Medien — RTP, weitergeleitet im internen Netz
FreeSWITCH — Anrufmaschine · intern
Maßgeblicher Registrar und Ausführung des Wählplans — Verbinden, IVR, Warteschlangen, Konferenzen, Parken, Voicemail, Aufzeichnung, Wartemusik. Nur im internen Netz. SIP-Verzeichnis und Wählplan werden bei jedem REGISTER und INVITE per mod_xml_curl live vom Backend geholt; Anrufereignisse gehen über ESL an das Backend. Codecs: Opus, G.722, G.711.
    Go-Backend — Steuerung · API
    Modularer Monolith in Go: REST-API, Authentifizierung und Rollenrechte, Audit-Protokoll, Konfigurationsgenerator, Provisionierung, ESL-Client, xml_curl-Endpunkt und ein WebSocket/SSE-Hub für Live-Ansichten. Strukturelle Konfiguration wird erzeugt, geprüft, atomar ausgetauscht und je Komponente neu geladen.
    • → FreeSWITCH: Steuerung — Verzeichnis und Wählplan (xml_curl), Ereignisse und Anrufsteuerung (ESL)
    • → OpenSIPS: Steuerung — Live-Zustand von ACLs, Anfragebegrenzung und Sperren
    • → PostgreSQL: Zustand — Liest und schreibt alle Konfigurationen und Datensätze
    • → Redis: Zustand — Live-Zustand und Begrenzungszähler
    PostgreSQL — Datenbasis
    Maßgebliche Datenbasis für alle fachlichen Daten — Nebenstellen, Trunks, Routen, IVR-Menüs, Verbindungsdatensätze, Audit-Protokoll — mit versionierten Schema-Migrationen.
      Redis — Live-Zustand
      Nur flüchtiger, wiederherstellbarer Zustand: Live-Momentaufnahmen von Anrufen und Registrierungen für Dashboards sowie Zähler der Anmeldebegrenzung. Geht er verloren, baut das System ihn aus PostgreSQL und neuen Ereignissen wieder auf.
        Next.js — Verwaltung
        Next.js-Verwaltungsoberfläche, nur über den HTTPS-Reverse-Proxy erreichbar. Sie arbeitet über die Backend-API; Live-Ansichten von Anrufen und Registrierungen kommen per WebSocket.
        • → Go-Backend: Steuerung — REST-API und Live-Aktualisierungen per WebSocket
        Reverse Proxy — TLS
        HTTPS-Reverse-Proxy mit TLS vor der Verwaltungsoberfläche. Provisionierungsanfragen der Geräte werden an die Provisionierung im Backend weitergereicht.
        • → Next.js: Steuerung — Weiterleitung zur Verwaltungsoberfläche
        • → Go-Backend: Provisionierung (HTTPS) — Provisionierungsanfragen an das Backend
        Admin-Browser — HTTPS
        Meldet sich per HTTPS mit Argon2id-gesichertem Passwort und TOTP an der Verwaltung an; jede Berechtigung wird serverseitig je Rolle geprüft.
        • → Reverse Proxy: Steuerung — Verwaltung über HTTPS
        1. 1. Ein Anruf beginnt. Ein Telefon wählt. Sein SIP-INVITE geht an OpenSIPS — der einzige Weg in die Plattform.
        2. 2. Die Grenze prüft. OpenSIPS prüft die Nachricht, wendet ACLs, Anfragebegrenzung und GeoIP-Regeln an und leitet sie im internen Netz an FreeSWITCH weiter.
        3. 3. Eine Routing-Entscheidung. FreeSWITCH fragt beim Backend den Wählplan für genau diesen Anruf ab; das Backend antwortet aus der in PostgreSQL gespeicherten Konfiguration.
        4. 4. Der Anruf wird behandelt. FreeSWITCH führt die Route aus: lässt eine Nebenstelle oder Sammelrufgruppe klingeln, spielt ein IVR-Menü, reiht den Anrufer in eine Warteschlange — oder wählt einen Trunk.
        5. 5. Das Ziel klingelt. Das ausgehende INVITE verlässt die Plattform über OpenSIPS zum Ziel: ein anderes Telefon oder der SIP-Trunk eines Netzbetreibers.
        6. 6. Die Stimme fließt. OpenSIPS weist RTPengine an, ein Medien-Relay zu öffnen. Das RTP jedes Gesprächsabschnitts läuft an der Grenze durch RTPengine und wird im internen Netz mit FreeSWITCH ausgetauscht — nie direkt mit dem Internet.
        7. 7. Alle sehen es live. Anrufereignisse erreichen das Backend über ESL; der Live-Zustand geht in Redis und erscheint sofort per WebSocket in der Verwaltung. Endet der Anruf, wird sein Datensatz in PostgreSQL geschrieben.