Kompetenz · Telefonie und Contact Center
Wir bauen die Telefonzentrale: SIP-Trunks, zeitbasierte Routing-Regeln, aus der Datenbank gelesene IVR-Menüs, Warteschlangen, Übergabe an einen Menschen, Aufzeichnung und Analyse der Anrufe. Der Anruf wird zu einer Aufnahme mit Transkript und Zusammenfassung, nicht zu einer Erinnerung.
Bereits gebautDrei eigene Implementierungen, unten zitiert. (1) Die Asterisk-Schicht der Kallina-Plattform: 5.522 Zeilen Dialplan-Konfiguration, AGI-Skripte und Audio-Bridges in `asterisk/`, plus automatisch pro Nummer generierte Trunk-Vorlagen. (2) `asterisk-manager` — ein separater Dienst, der die Warteschlangen, Trunks und den RTP-Flow über die Management-Schnittstelle der Telefonanlage verwaltet. (3) Das Middleware für die virtuelle Telefonanlage eines Betreibers, das in Produktion lief: Der Reconciliation-Commit vom 14. Juli 2026 bringt Code ins Repository, der auf dem Server gelaufen war und etwa 40 Tage vor dem Git lag. Der Vorbehalt, bevor Sie fragen: Der SIP-Host, über den unsere Testleitungen laufen, antwortet nicht — heute, 06.09.2026, geprüft, ohne Antwort auf Ping und ohne Antwort auf HTTP. Wir präsentieren keine Demo-Nummer, die Sie jetzt anrufen können, weil wir sie vor Ihnen nicht hochbringen könnten.
Zwischen Ihrem Telefonanbieter und demjenigen, der tatsächlich antwortet — ein Mensch oder ein Voice-Agent — muss es eine Schicht geben, die Entscheidungen trifft. Wer den Anruf um 23:40 entgegennimmt. Was passiert, wenn niemand antwortet. Wohin der Anruf geht, wenn der Kunde „einen Menschen“ verlangt. Was von dem Gespräch übrig bleibt, nachdem es beendet wurde. Diese Schicht ist eine Telefonanlage, und wir bauen sie so, dass sie dem Unternehmen gehört, nicht dem Sprachanbieter: Wenn Sie morgen die Engine des Agenten wechseln, bleiben die Routing-Regeln, die Warteschlangen und die Historie bei Ihnen.
Konkret, was wir gebaut haben: zwölf Dialplan-Dateien — Produktion, IVR, Warteschlange, Transfer, Voicemail, Umleitung, ausgehende Anrufe mit Agent — vier AGI-Skripte in Python und zwei Audio-Bridges, insgesamt 5.522 Zeilen. Die IVR-Engine hat die Menüs nicht in der Datei geschrieben: Sie liest sie über ein AGI-Skript aus der Datenbank und gibt eine von sechs Entscheidungen zurück — zu einem Agenten, zu einem anderen Menü, zu einer Warteschlange, Transfer zu einer externen Nummer, abschließende Nachricht oder Schließung. Die Warteschlangen heißen nach ihrer Kennung und haben keine in der Konfiguration geschriebenen Mitglieder: Sie werden von außen hinzugefügt und entfernt, über die Management-Schnittstelle, was bedeutet, dass ein Operator ohne Neustart der Telefonanlage in eine Warteschlange hinein- oder aus ihr herausgehen kann.
Das Routing hat echte Regeln, nicht nur ein einziges „rufen Sie hier an“: Geschäftszeiten und Zeitzone, Nachtbetrieb wie 22:00 → 06:00 und Prioritätsabgleich — der SIP-Header `Diversion`, der die ursprüngliche Nummer trägt, von der der Anruf weitergeleitet wurde, dann die eigene Nummer, dann die Ersatzregel. Trunks werden pro Nummer generiert, mit einem aus Anbieter und Nummer aufgebauten Namen, durch eine Konfigurationsfunktion — nicht per Hand auf jeder neuen Zeile geschrieben.
Was aus dem Anruf herauskommt, ist genauso wichtig wie der Anruf. Für die Leitung, die mit der virtuellen Telefonzentrale eines Betreibers verbunden ist, haben wir ein Python-Middleware gebaut, das die Liste der Aufzeichnungen jede Minute abfragt, mit einer breiten Abgleichung alle sechs Stunden, damit ein Netzwerkausfall nichts verliert, und einem Scan alle drei Minuten für verpasste Anrufe — diese haben keine Aufzeichnung und wären sonst vollständig unsichtbar. Jede Aufzeichnung wird heruntergeladen, transkribiert, analysiert und in die Anrufanalyse gespiegelt, und der verpasste Anruf wird zu einer Warnung. Die Idempotenz liegt in einem Redis-Set, damit dieselbe Aufzeichnung nicht zweimal verarbeitet wird.
Was dazugehört
Die Trunk-Vorlagen sind parametriert und werden von einer Konfigurationsfunktion befüllt, mit einem Namen aus Anbieter und Nummer. In der Vorlage sind Transport, zulässige Codecs, NAT-Behandlung, DTMF-Modus und Authentifizierung festgelegt. Die praktische Folge: Die zehnte Nummer verbindet sich genauso wie die erste, und die Unterschiede zwischen den Betreibern liegen an einem einzigen Ort.
Geschäftszeiten und Zeitzone, Nachtbetrieb wie 22:00 → 06:00, Prioritätsabgleich: der SIP-Header `Diversion` (die Nummer, von der weitergeleitet wurde), dann die eigene Nummer, dann die Ersatzregel. Die Regel wird über ein AGI-Skript gesucht, das die Plattform während des Anrufs abfragt, mit eigener Wartezeit — also wird eine in der Oberfläche geänderte Regel beim nächsten Anruf angewendet, ohne Neustart.
Zum Sprachagenten wird das Audio über eine Bridge geführt, die den Codec in beide Richtungen umwandelt, `g711_ulaw` ↔ `PCM16`. Zu Menschen gelangt der Anruf in eine von außen verwaltete Warteschlange. Und das Weiterverbinden liegt in der Hand der sprechenden Person: Blindtransfer mit `##` und assisted transfer mit `*2`, wobei der Anruf in einem dafür geschriebenen Kontext landet, der interne vierstellige Nebenstellen von externen Nummern unterscheidet.
Die IVR-Engine erhält die Menü-ID und liest sie per AGI-Skript aus der Datenbank. Das Ergebnis ist eine von sechs Entscheidungen: zu einem Agenten, zu einem anderen Menü (rekursiv), zu einer Warteschlange, externer Transfer, Endnachricht, Schließen. Nachrichten können synthetisiert werden oder vorab aufgenommene Audiodateien sein. Ein Menü zu ändern bedeutet, eine Zeile in der Datenbank zu ändern, nicht eine Konfigurationsdatei auf dem Server zu bearbeiten.
Jede Warteschlange trägt den von ihrer Kennung abgeleiteten Namen. Die Mitglieder werden nicht in der Konfiguration gespeichert: Sie werden während des Betriebs über die Verwaltungsoberfläche der Telefonzentrale hinzugefügt und entfernt, und die gleichzeitige Platzierung auf mehreren freien Positionen ist aktiviert. Praktisch bedeutet das: Ein Operator tritt einer Warteschlange bei oder verlässt sie, ohne dass die Telefonzentrale neu gestartet wird und ohne dass die wartenden Anrufe beeinträchtigt werden.
Ein Agent kann selbst jemanden von außen anrufen und mit der Antwort zurückkommen. Der Mechanismus ist mit einer eigenen Tabelle und expliziten Zuständen implementiert — wird angerufen, in Bearbeitung, erneut versuchen, abgeschlossen, fehlgeschlagen, keine Antwort, abgelaufen — mit maximal drei Versuchen und einer Pause von zwei Minuten dazwischen, und das Ergebnis (einschließlich der geschätzten Ankunftszeit) wird strukturiert an die Konversation zurückgegeben, die es angefordert hat. Das ist kein Konzept: Es gibt fünf dedizierte Serverfunktionen plus eine Bereinigung der hängengebliebenen Anrufe.
Ein geplanter Prozess liest die Liste der Aufzeichnungen jede Minute, mit breiter Abgleichung alle sechs Stunden, damit ein Ausfall nichts verliert. Die Aufzeichnung wird als WAV heruntergeladen, transkribiert, analysiert und zusammen mit dem Audio in die Anrufanalyse gespiegelt. Separat werden alle drei Minuten die nicht angenommenen Anrufe gelesen — die keine Aufzeichnung haben und sonst nirgends existieren würden — und werden zu einer Warnung. Ein verpasster Anruf ist ein verlorener Kunde; ihn sichtbar zu machen ist die günstigste Verbesserung in einem Callcenter.
Der Client, der mit der Telefonzentrale des Betreibers spricht, hat einen eigenen Ratenbegrenzer mit Token Bucket und eine explizite Fehlerbehandlung. Das ist keine theoretische Vorsichtsmaßnahme: Ein Middleware, das jede Minute abfragt und alle sechs Stunden abgleicht, kann ohne Bremse das Limit des Betreibers treffen und genau dann blockiert werden, wenn Sie es brauchen.
Wie es aussieht
Welche Nummern es gibt, bei welchem Betreiber, wer heute für welche zuständig ist, in welchem Zeitplan, und was jetzt passiert, wenn niemand antwortet. Es wirkt wie Bürokratie; es ist der Teil, der Überraschungen verhindert. Aus unserer Erfahrung gibt es in einem Nummernpark fast immer Leitungen, bei denen die Datenbank das eine sagt und die Telefonanlage das andere — und sie werden nicht beim Start entdeckt, sondern jetzt.
Die Nummer geht auf den Trunk, und eingehende sowie ausgehende Anrufe werden als zwei getrennte Dinge getestet, weil sie getrennt kaputtgehen. Wir haben einen dokumentierten Fall, in dem eingehende Anrufe tagelang einwandfrei funktionierten, während alle ausgehenden Anrufe von der Anlage des Betreibers mit `403 Forbidden` abgewiesen wurden, ohne irgendeine Änderung bei uns. Ein einziger Test „angerufen und es ging“ deckt das nicht ab.
Die Regeln für Zeitplan und Priorität, die Menüs, Warteschlangen und Weiterleitungspfade werden als Dialplan und als Zeilen in der Datenbank geschrieben, nicht als mündliche Absprache. Am Ende wissen Sie genau, was mit einem Anruf um 23:40 Uhr am Samstag passiert, wenn der Agent die Anfrage nicht versteht.
Das Ergebnis des Anrufs — Transkript, Zusammenfassung, Sentiment, Adresse der Aufnahme, Dauer — wird weiter über einen signierten Webhook gesendet, und die Organisation wird über die Telefonnummer identifiziert. Dort, wo ein CRM vorhanden ist, wird der Anruf mit dem Datensatz verknüpft und kann den Status automatisch ändern; über diesen Teil schreiben wir auf der Seite zu CRM und Vertriebsautomatisierung.
Eine Telefonanlage auf einem einzelnen Host ist ein Single Point of Failure, und genau das haben wir erlebt: Wenn der Host nicht antwortet, fallen alle Leitungen, die darüber laufen, mit ihm aus, egal wie gut der Agent konfiguriert ist. Die Signatur des Fehlers ist klar — der Anruf kehrt mit „request timed out“ und leerer SIP-Call-ID zurück, das heißt, der SIP-Anruf wurde nie aufgebaut. Deshalb wird in einem realen Projekt die Frage „was passiert, wenn der Host ausfällt“ am Anfang gestellt und budgetiert: ein zweiter Host, Monitoring, das einen Menschen anruft, und ein Ausweichweg zu gewöhnlichen Nummern.
Die Daten
Die Fragen, die jede Person mit einem Datenschutzbeauftragten stellt — hier gestellt, bevor er sie stellt.
Ein Fall
Die Ausgangslage
In einem Analysefluss für Gespräche gelangte ein Teil der Anrufe in die Analyse und ein Teil nicht. Das Muster war es, das die Ursache zeigte: Genau die langen Anrufe fehlten. Ein Fehler, der als „manchmal funktioniert es nicht“ gemeldet und fälschlich in der Transkription gesucht wird.
Was wir gebaut haben
Es gab zwei Transkriptionswege, und beide fielen aus, aus unterschiedlichen Gründen. Der multimodale Weg sendet die gesamte Audiodatei, codiert im Request-Body; oberhalb einer bestimmten Größe antwortete die Body-Limit des Zwischenservers mit 413. Der Backup-Weg verlangte ein Transkriptionsmodell, das der Zugriffsschlüssel nicht mehr erlaubte, also antwortete er mit 403. Beide scheiterten, der Prozess meldete, dass alle Transkriptionsmodelle fehlgeschlagen seien, und der Anruf wurde verworfen. Die kurzen Anrufe blieben unter der Body-Grenze und kamen daher durch — daher das Muster. Die Reparatur war: der multimodale Weg wird für WAV-Dateien über 12 MB übersprungen (Schwelle aus der Umgebung konfigurierbar), das bereits berechnete Transkript wird wiederverwendet, statt erneut transkribiert zu werden, und die Transkription als letzte Instanz wurde auf ein zulässiges Modell verlegt.
Was dabei herauskam
Geprüft an der blockiert gebliebenen Aufnahme: ein Gespräch von 21 Minuten, WAV-Datei von 41 MB — der multimodale Weg umgangen, Transkript übernommen, Analyse erzeugt, Zeile und Audio in der Anrufanalyse angekommen, null Fehler. Die Abgleichung bestätigte anschließend, dass es keine weiteren blockierten Aufzeichnungen mehr gibt.
Was der Fall nicht sagt
Die 12-MB-Schwelle ist eine Eigenschaft des Zwischenservers, nicht des Anrufs. Wenn das Gateway, der Schlüssel oder das Modell geändert wird, muss die Schwelle erneut geprüft werden — deshalb haben wir sie aus der Umgebung konfigurierbar gemacht, nicht im Code festgeschrieben.
Fragen
Heute nicht, und wir sagen das lieber so, als eine Nummer zu nennen, die ins Leere klingelt. Der Agenten-Teil lässt sich auf der Seite sofort anhören. Der Telefon-Teil hängt von einem SIP-Host ab, und der Host, über den unsere Testleitungen laufen, antwortet zum Zeitpunkt der Erstellung nicht — heute geprüft, kein Ping-Antwort und keine HTTP-Antwort. Für ein Projekt von Ihnen wird die Telefonie auf einem projektdedizierten Host eingerichtet, nicht auf dem Testhost.
Weil Routing-Regeln, Warteschlangen, Weiterleitung, Voicemail und Anrufhistorie dem Unternehmen gehören und nicht dem Voice-Anbieter. Mit einer eigenen Telefonzentrale können Sie die Engine des Agenten wechseln, ohne zu ändern, wie sich Ihr Telefon verhält, Sie können denselben Anruf einmal an einen Agenten, einmal an einen Menschen weiterleiten und die Anrufaufzeichnungen bei sich behalten. Ohne sie sind Sie an das gebunden, was der Anbieter bereitstellt.
Dann fallen alle Leitungen aus, die über ihn laufen. Das ist keine Hypothese: Wir haben es selbst erlebt, und die Signatur ist leicht zu erkennen — der Anruf kehrt mit „request timed out“ und leerem SIP-Call-Identifier zurück, also liegt es nicht am Agenten, an der Nummer oder am Prompt. Die Schlussfolgerung, die wir daraus gezogen haben und die wir jetzt in jedem Projekt ansetzen: Kontinuität ist keine Funktion der Telefonzentrale, sondern eine Architektur- und Budgetentscheidung, die am Anfang getroffen wird. Gelöst wird das mit einem zweiten Host und einem Fallback-Weg zu gewöhnlichen Nummern, nicht mit einer Einstellung.
Nein. Das sind zwei verschiedene Dinge, und der Betreiber kann sie unterschiedlich behandeln. Wir haben einen dokumentierten Fall, in dem bei unveränderter Konfiguration und funktionierenden eingehenden Anrufen die Zentrale des Betreibers begann, alle ausgehenden Anrufe mit `403 Forbidden` abzulehnen — der Beweis, dass es am Betreiber lag, war, dass ein zweites Konto mit strukturell identischer Konfiguration weiterhin nach außen anrufen konnte. Deshalb versprechen wir keine Kampagne ausgehender Anrufe vor einem erfolgreichen Ausgehtest auf Ihrer Nummer.
Ja, und wir haben es getan: Wir haben ein Middleware in Python über die API einer virtuellen Telefonzentrale des Betreibers geschrieben, mit eigenem Client, Rate Limiter, Download von Aufzeichnungen, Transkription, Analyse und Alarmierung, im Produktivbetrieb eingesetzt. Vorab zu wissen: Der Zugriff auf die erweiterte API ist oft eine separate, gesondert beauftragte Dienstleistung, und die Credentials funktionieren möglicherweise nicht beim ersten Versuch — bei uns dauerte der Zyklus aus Spezifikationsklärung und Passwort-Reset mit dem Betreiber Monate, obwohl der Dienst bereits fakturiert war. Deshalb setzen wir in einem Angebot, das von der API eines Betreibers abhängt, ausdrücklich die Bedingung: Die Arbeit beginnt, nachdem die Authentifizierung nachgewiesen wurde, nicht nachdem sie versprochen wurde.
Sie können aufgezeichnet, transkribiert und analysiert werden. Sie bleiben an den Arbeitsbereich Ihres Unternehmens gebunden, und der Zugriff erfordert eine Authentifizierung — es gibt keinen gemeinsamen Speicher über Kunden hinweg. Wer in Ihrem Team das Recht zum Anhören hat, wird bei der Implementierung festgelegt. Der Hinweis an den Gesprächspartner und die Rechtsgrundlage der Aufzeichnung sind Ihre Entscheidungen als Verantwortlicher für die Daten; wir schreiben sie in das Szenario, wir nehmen sie nicht an.
Sie sind in den meisten Unternehmen der am schlechtesten behandelte Fall, weil sie keine Spur hinterlassen: keine Aufzeichnung, kein Transkript, nur im Anrufprotokoll vorhanden. Bei uns liest ein Prozess alle drei Minuten das Protokoll, erkennt nicht angenommene Anrufe und verwandelt sie in eine Warnung und eine sichtbare Zeile. Damit klar ist, wovon es abhängt: Wir sehen sie nur soweit, wie der Betreiber sie in seinem Protokoll offenlegt.
Ja, und die Menüs liegen in der Datenbank, nicht in Dateien auf dem Server. Die Engine liest die Menükonfiguration während des Anrufs und entscheidet sich für einen von sechs Wegen: zu einem Agenten, zu einem anderen Menü, in eine Warteschlange, Weiterleitung an eine externe Nummer, eine Abschiedsnachricht oder Beenden. Die Nachrichten können synthetisiert oder vorher aufgezeichnet werden. Praktisch erfordert eine Menüänderung keinen Eingriff an der Telefonanlage.
Durch Abgleich, und das ist ein Baustein, den wir ausdrücklich aufbauen. Die schnelle Abfrage hat ein Fenster von einigen Dutzend Stunden, und darüber läuft alle sechs Stunden ein Abgleich über ein Fenster von einer Woche, der mehrere Ergebnisseiten erneut liest. Jeder verarbeitete Datensatz wird markiert, daher dupliziert das erneute Lesen nichts. Ohne Abgleich bedeutet ein Ausfall von einer Stunde ein dauerhaftes Loch in den Daten — und niemand bemerkt es.
22 davon sind Code und Dateien aus unseren Repositories. Wir veröffentlichen weder ihren Namen noch die Zeile: zusammen, auf einer einzigen Seite, würden sie zu genau beschreiben, wie Systeme gebaut sind, die nicht nur uns gehören. Wir gehen sie mit Ihnen durch, im Repository, auf Anfrage — die Überprüfung bleibt möglich, sie findet nur in einem Gespräch statt.
Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.