Simulation des "Fräulein vom Amt" in einer Handvermittlung mit Spracherkennung und Verbindungsaufbau
Hallo zusammen,
für meinen kleinen Asterisk-Telefonserver auf einem Raspberry Pi 3B hatte ich mir in den Kopf gesetzt eine Handvermittlung mit Spracherkennung zu simulieren. Man ruft also die Vermittlung an, sagt die gewünschte Zielnummer oder den Namen des Teilnehmers auf, mit dem man sprechen will und nach ein paar Sekunden wird man von einer freundlichen Stimme verbunden - das "Fräulein vom Amt" also mit Künstlicher Intelligenz umgesetzt. Die Künstliche Intelligenz steckt hauptsächlich in der Spracherkennung.
Bild mit der KI Banana2 von Gemini erzeugt
Es begann also mit einer simplen Idee: Eine historische Telefonvermittlung soll Anrufe per Spracherkennung weiterleiten. Klingt machbar, dachte ich. Zwei Tage später weiß ich, dass der Teufel im Detail steckt. Für das Coding und für die Installationsanleitungen der Spracherkennungsoftware kamen die kostenlosen Versionen von Claude Sonnet 4.6 und Gemini zum Einsatz, wobei ich hauptsächlich mit Claude arbeitete.
Der erste Kandidat war Vosk, eine lokale Open-Source-Spracherkennung. Die Idee war elegant: Audio direkt aus Asterisk per EAGI-Schnittstelle streamen, kein Zwischenspeichern, keine Verzögerung. Die Realität war ernüchternd. Vosk verweigerte konsequent die Arbeit mit der kryptischen Meldung "Failed to process waveform". Stundenlange Fehlersuche, Hex-Dumps des Audiostreams, verschiedene Konvertierungsversuche – nichts half. EAGI und Vosk wollten einfach nicht miteinander.
Also Plan B: WAV-Datei aufnehmen, sox zur Aufbereitung, dann Vosk. Das funktionierte – fast. Das kleine deutsche Modell kannte das Wort "fünf" schlicht nicht, zumindest nicht mit aktivierter Grammar. Ohne Grammar wurde es erkannt, mit Grammar nicht. Ein Bug, eine Eigenart, wer weiß. Dazu kam dass Vosk bei jedem Anruf das Modell neu laden musste – mehrere Sekunden Wartezeit, für eine Vermittlung inakzeptabel. Vosk flog raus.
Whisper von OpenAI war die Rettung. Ebenfalls lokal, ebenfalls kostenlos, aber deutlich intelligenter. Allerdings auch hier kein einfacher Weg. Das tiny-Modell halluzinierte fröhlich "1, 2, 3, 4" wenn man eine vierstellige Nummer sprach. Das base-Modell war besser, aber der entscheidende Durchbruch kam erst mit dem initial_prompt – einer Liste aller bekannten Nummern und Namen die Whisper als Kontext bekommt. Ohne diesen Prompt rät Whisper wild drauflos.
Dann das Feintuning mit verschiedenen Telefonen. Jedes Gerät klingt anders, jedes hat andere Codec-Einstellungen, manche sind leiser, manche haben mehr Rauschen. AGC einschalten, Lautstärke verstärken, sox-Filter anpassen. Parameter wie beam_size, best_of und no_speech_threshold wurden iterativ optimiert bis die Erkennungsrate über 95% lag.
Damit es sich auch wie eine echte Vermittlung anfühlt, mussten noch deutsche Sprachprompts her. Asterisk bringt von Haus aus englische Ansagen mit, die deutschen Pendants mussten erst beschafft werden. Zusätzlich wurden drei eigene Ansagen benötigt – eine Begrüßung, eine Wartemeldung und eine Verbindungsansage. Die wurden per Text-to-Speech online generiert, im richtigen Format für Asterisk aufbereitet und eingebunden. Wenn schon, dann richtig.
Ursprünglich sollte das alles auf einem Raspberry Pi laufen. Der Pi ist bereits als IAX2-Gateway im Einsatz, wäre also naheliegend gewesen. Aber Whisper base auf einem Pi ist schlicht zu langsam – die Wartezeit wäre für Museumsbesucher unzumutbar. Also wurde die Spracherkennung auf einen Fujitsu Esprimo Q520 ausgelagert, einen kleinen aber feinen Mini-PC mit 8 GB RAM. Auch der geht während der Erkennung kurz in die Knie – alle vier CPU-Kerne springen auf 60 bis 90 Prozent. Eine Nvidia-Grafikkarte würde die Verarbeitungszeit von fünf Sekunden auf unter eine Sekunde drücken.
Beim Auswerten der Aufzeichnung durch die Spracherkennung ist mein kleiner Rechner fast am Anschlag beschäftigt. Der Raspberry Pi wäre zu schwach dafür.
Den praktischen Nutzen im Alltag darf man dabei nicht vergessen: Wer kennt schon alle Durchwahlen auswendig? Namen sprechen und verbunden werden ist deutlich komfortabler als im Telefonbuch blättern. Für den produktiven Einsatz braucht man allerdings schnellere Hardware – die fünf Sekunden Wartezeit erinnern im Moment eher an die Geduld die man früher bei einer echten Handvermittlung aufbringen musste. Was für das Museumsprojekt durchaus seinen Charme hat, im Büroalltag aber schnell zur Geduldsprobe wird.
Das gesamte Projekt – Code, Konfiguration, Dokumentation und alle Fallstricke – wird natürlich veröffentlicht. Zum Nachmachen, zum Weiterentwickeln, und damit andere nicht dieselben Umwege gehen müssen. Vielleicht findet sich ja jemand der das Ganze auf schnellerer Hardware zum Laufen bringt und die Wartezeit auf ein modernes Niveau drückt. Die Grundlage ist gelegt.
!!!
Fotos, Grafiken nur über die
Upload-Option des Forums, KEINE FREMD-LINKS auf externe Fotos.
!!! Keine
Komplett-Schaltbilder, keine Fotos, keine Grafiken, auf denen
Urheberrechte Anderer (auch WEB-Seiten oder Foren) liegen! Solche Uploads werden wegen der Rechtslage kommentarlos gelöscht!
Keine Fotos, auf denen Personen erkennbar sind, ohne deren schriftliche Zustimmung.
Den Beitrag-Betreff bei Antworten auf Threads nicht verändern!
Re: Simulation des "Fräulein vom Amt" in einer Handvermittlung mit Spracherkennung und Verbindungsaufbau
Volker:Hallo zusammen,
für meinen kleinen Asterisk-Telefonserver auf einem Raspberry Pi 3B hatte ich mir in den Kopf gesetzt eine Handvermittlung mit Spracherkennung zu simulieren. Man ruft also die Vermittlung an, sagt die gewünschte Zielnummer oder den Namen des Teilnehmers auf, mit dem man sprechen will und nach ein paar Sekunden wird man von einer freundlichen Stimme verbunden - das "Fräulein vom Amt" also mit Künstlicher Intelligenz umgesetzt. Die Künstliche Intelligenz steckt hauptsächlich in der Spracherkennung.
...
Den praktischen Nutzen im Alltag darf man dabei nicht vergessen: Wer kennt schon alle Durchwahlen auswendig? Namen sprechen und verbunden werden ist deutlich komfortabler als im Telefonbuch blättern. Für den produktiven Einsatz braucht man allerdings schnellere Hardware – die fünf Sekunden Wartezeit erinnern im Moment eher an die Geduld die man früher bei einer echten Handvermittlung aufbringen musste. Was für das Museumsprojekt durchaus seinen Charme hat, im Büroalltag aber schnell zur Geduldsprobe wird.
Das gesamte Projekt – Code, Konfiguration, Dokumentation und alle Fallstricke – wird natürlich veröffentlicht. Zum Nachmachen, zum Weit
Hi Volker,
diese "künstliche Intelligenz" und den praktischen Nutzen bietet heute jedes SmartPhone und das in Bruchteilen einer Sekunde. Aber schön zu hören, dass man es auch historisch korrekt mit etwas Wartezeit für seine eigenen Telefonspielereien realisieren kann.
Re: Simulation des "Fräulein vom Amt" in einer Handvermittlung mit Spracherkennung und Verbindungsaufbau
Hallo Kalle,
beim Smartphone geht die Spracherkennung online, ist also auf leistungsfähigen externen Servern ausgelagert. Für das Smartphone selbst wäre das viel zu rechenintensiv. Das Auslagern hatte ich mir auch überlegt. Aber dafür braucht man eine kostenpflichtige API-Schnittstelle, was schnell ins Geld gehen kann.
dokumentiert. Die Antwortzeit ist für den praktischen Betrieb noch zu langsam, obwohl mein Rechner für die Spracherkennung voll ausgelastet ist. Aber beim "Fräulein vom Amt" hat es ja auch länger gedauert. Damals liefen die Uhren bekanntlich langsamer. Das ist alles noch ein Experiment und eine Vorstudie.
Ich habe übrigens noch eine Sprachausgabe mit gTTS von Google eingebaut. Das Sprachfile wird also auf einem Google-Server erzeugt, übrigens kostenlos. Das war notwendig, um die Bestätigung zu erfahren, dass die eigenen Worte korrekt verstanden wurden. Auf einem schnellen Rechner mit einer Grafikkarte von Nvidia als GPU würde das alles viel schneller laufen. Für den Zweck reicht es noch.
Natürlich geht das nicht nur mit der Spracheingabe "Zeitangabe Deutschland". Ich habe eine ganz Liste in einem json-File untergebraucht. Wer meinen Asterisk-Server kennt, erreicht die Vermittlung unter der Nummer 123, wenn mein Rechner an ist.
Später will ich echte Klön-Gespräche im Plauderton per Telefon mit einem LLM wie DeepSeek oder Claude Sonnet ermöglichen. Dazu brauche ich aber einen schnelleren Rechner oder eine API für die Spracherkennung. Eine API von Claude Sonnet oder DeepSeek für die Anworten der Künstlichen Intelligenz brauche ich so oder so. Die Antworten in Textform können recht leicht in Sprache verwandelt werden. Das benötigt relativ wenig Rechenleistung. Die API des chinesischen DeepSeek ist am kostengünstigsten.
Skeptiker werden sich fragen, was das soll? Egal, was man davon hält, die Nachfrage ist mit hohen Wachstumsraten hoch. Insbesondere Callcenter setzen auf KI, um Personalkosten zu senken, wettbewerbsfähig zu bleiben und um den Kundenservice zu verbessern. Das ist der Trend. Deshalb probiere ich es aus, um zu sehen, wohin die Reise geht. Die Skeptiker gab es auch vor über 25 Jahren bei der Einführung des Internets und hielten das Internet für eine Blase, an der man nach ein paar Jahren das Interesse verlieren wird.
Re: Simulation des "Fräulein vom Amt" in einer Handvermittlung mit Spracherkennung und Verbindungsaufbau
Volker:Hallo Kalle,
beim Smartphone geht die Spracherkennung online, ist also auf leistungsfähigen externen Servern ausgelagert. Für das Smartphone selbst wäre das viel zu rechenintensiv. Das Auslagern hatte ich mir auch überlegt. Aber dafür braucht man eine kostenpflichtige API-Schnittstelle, was schnell ins Geld gehen kann.
...
Hi Volker,
bei Android gibt es schon lange die "Offline-Spracherkennung", die zumindest zur einfachen Sprachsteuerung der Telefonfunktionen ausreichend ist. Dazu muss man nur die entsprechende Sprache bei den Einstellungen unter „Bildschirmtastatur“/"Google Voice Typing" (nach)installieren.
Re: Simulation des "Fräulein vom Amt" in einer Handvermittlung mit Spracherkennung und Verbindungsaufbau
Hallo Kalle,
ah, hochinteressant. Das wusste ich nicht. Danke für den Hinweis. Ich habe mir das mal von Claude Sonnet 4.6 ausführlich erklären lassen, warum Spracherkennung über Telefon einen halb in den Wahnsinn treibt, wenn man kein Geld für teure kostenpflichtige Sprachmodelle ausgeben will:
"Android-Spracherkennung funktioniert so gut, weil sie direkt auf dem Gerätmikrofon aufsetzt – unkomprimiertes Audio mit 16 kHz oder mehr, optimiert auf den NPU-Chip des Smartphones. Sobald man das über eine Telefonleitung versucht, bricht die Qualität massiv ein, weil Telefonie-Audio grundlegend anders ist.
G.711 (alaw/ulaw), der klassische Telefonstandard, ist technisch keine Kompression im eigentlichen Sinne, sondern logarithmische PCM-Quantisierung mit 8 kHz Samplingrate – was nach Nyquist maximal 4 kHz Frequenzübertragung bedeutet. Das reicht für Sprache gerade so aus, ist aber weit entfernt von dem, was Spracherkennungsmodelle erwarten. G.722 dreht das teilweise um: Es ist zwar komprimiert (ADPCM), überträgt aber Frequenzen bis 8 kHz und klingt als HD-Voice deutlich natürlicher. Mobilfunk ist nochmal eine andere Baustelle – Codecs wie AMR oder AMR-WB sind stark verlustbehaftet und auf minimale Funkbandbreite optimiert. Bei schlechtem Empfang reduziert der Codec die Bitrate dynamisch, was Artefakte und den typischen metallischen Klang erzeugt. Dazu kommen Paketlöcher bei LTE und ständige Handover zwischen Funkmasten.
Für Spracherkennung ist das alles problematisch, weil die Modelle nicht nur mit begrenzter Bandbreite klarkommen müssen, sondern auch mit codec-spezifischen Artefakten, die im Trainingsdatensatz schlicht nicht vorhanden sind. Android Voice Typing würde damit sehr fehlerhafte Ergebnisse liefern, Whisper hat zusätzlich das Architekturproblem – für Batch-Verarbeitung gebaut, nicht für Echtzeit-Streams, halluziniert bei Stille und erwartet 16 kHz. Vosk war der Versuch einer schlanken Streaming-Lösung, ist aber in der Praxis zu ungenau – schlechte Ziffernerkennung und generell unbefriedigende Ergebnisse.
Die großen Callcenter haben das Problem gelöst, aber mit erheblichem Aufwand: spezialisierte kommerzielle Systeme von Nuance, Google CCAI oder Amazon Transcribe, die explizit auf echten Telefongesprächen trainiert wurden und jahrelange Optimierung auf die verschiedenen Codec-Artefakte, 4 kHz Bandbreite und Echtzeit-Streaming hinter sich haben.
Prinzipiell könnte man als Privatperson ebenfalls auf solche Cloud-APIs zugreifen – Google Speech-to-Text, Amazon Transcribe oder Azure Speech bieten das an, und die Qualität wäre tatsächlich gut. Das Problem ist der Preis: Bei einem Asterisk-Hobbyprojekt summieren sich die Kosten pro Minute schnell auf einen Betrag, der nicht mehr verhältnismäßig ist. Was für ein Callcenter mit klarem Geschäftsmodell selbstverständlich ist, wird für den privaten Bastler schnell zum Kostenproblem.
Für selbst gehostete Lösungen mit Asterisk bleibt die Lücke damit bestehen: Gute Offline-Spracherkennung für Telefonie-Audio gibt es im Open-Source-Bereich schlicht nicht zufriedenstellend, und die guten Lösungen sind entweder zu teuer oder nur in der Cloud verfügbar."
Übrigens ist mein Spracherkennungsprojekt jetzt dokumentiert:
Re: Simulation des "Fräulein vom Amt" in einer Handvermittlung mit Spracherkennung und Verbindungsaufbau
Du musst ja nicht über die Telefonbandbreite gehen... vermute ich mal. Dann also das alte Telefon als Headset an das Mobile und testen ob die alte Kohle noch reicht, ansonsten Deine HiFi-Version einbauen.
Re: Simulation des "Fräulein vom Amt" in einer Handvermittlung mit Spracherkennung und Verbindungsaufbau
Hallo zusammen, Hallo Metabastler,
das muss schon unter normalen Telefonbedingungen funktionieren. Hier die kurze Demonstration meiner verbesserten Version, Das Gespräch wirkt jetzt natürlicher:
Man merkt mir an, dass ich so langsam von der zickigen Spracherkennung genervt bin. Im Hintergrund Störgeräusche durch einen dänischen Film. Die Spracherzeugung für das "Fräulein vom Amt" erfolgt online mit gTTS von Google. Der Dienst ist kostenlos. Die Spracherkennung ist wieder Whisper. Der Audio-Codec ist G.722.
Das Museumsprojekt "Fräulein vom Amt" hat eine wichtige Weiterentwicklung erfahren. Für die Sprachausgabe wird jetzt ausschließlich Google Text-to-Speech (gTTS) eingesetzt, und das macht einen erheblichen Unterschied.
Früher wurden vorproduzierte Audiodateien abgespielt. Das klang oft holprig und zusammengestückelt, weil jede Ansage aus einzelnen Bausteinen zusammengesetzt wurde. Mit gTTS wird der gesamte Satz in einem Stück synthetisiert und klingt dadurch deutlich flüssiger und natürlicher — fast wie ein echtes Gespräch. Wer die Vermittlung anruft, hat das Gefühl, tatsächlich mit einer Telefonistin zu sprechen.
Ein weiterer großer Vorteil ist, dass man überhaupt keine Audiodateien mehr erstellen, pflegen oder auf dem Server ablegen muss. Der Text wird direkt zur Laufzeit in Sprache umgewandelt. Das spart Zeit und vermeidet Fehlerquellen. Soll eine Ansage geändert werden, ändert man einfach den Text im Programm — fertig.
Besonders elegant ist die Mehrsprachigkeit. Um das System auf Englisch oder Französisch umzustellen, genügt es, eine einzige Variable im Skript zu ändern. gTTS übernimmt dann automatisch die korrekte Aussprache in der gewünschten Sprache, ohne dass neue Aufnahmen nötig wären.
Auch der Gesprächsablauf selbst wurde verbessert. Das Programm führt jetzt einen echten Dialog. Wenn die Spracherkennung einen Namen oder eine Nummer erkannt hat, fragt das System zur Bestätigung nach, zum Beispiel: "Soll ich Sie mit Michael, Nebenstelle 1066, verbinden?" Wird die Antwort nicht verstanden, fragt das Programm gezielt nach, statt einfach aufzulegen. Erst nach mehreren erfolglosen Versuchen beendet es das Gespräch höflich.
Ein Detail das zunächst unscheinbar wirkt, aber im Alltag wichtig ist: lange Telefonnummern werden jetzt Ziffer für Ziffer aufgesagt. Nummern bis zu vier Stellen spricht gTTS als Zahl aus, was gut verständlich ist. Bei längeren Nummern wie externen Anschlüssen werden die einzelnen Ziffern nacheinander genannt, damit der Anrufer die Nummer sicher aufnehmen kann.
Das Telefonbuch mit allen Namen und Nebenstellen liegt in einer einfachen JSON-Datei. Wer einen neuen Teilnehmer einträgt oder eine Nummer ändert, muss nichts weiter tun — kein Neustart des Servers, keine Neukompilierung, keine neue Audiodatei. Bei jedem Anruf lädt das Programm die JSON-Datei automatisch und baut daraus auch gleich den Kontext für die Spracherkennung auf. Namen und Nummern aus dem Telefonbuch werden von Whisper dadurch bevorzugt erkannt.
Das Ergebnis ist ein System das sich tatsächlich wie eine echte Vermittlung anfühlt — reaktionsschnell, verständlich und pflegeleicht.
Re: Simulation des "Fräulein vom Amt" in einer Handvermittlung mit Spracherkennung und Verbindungsaufbau
Hallo zusammen,
Hier sind die neuesten Verbesserungen.
Der komplette Dialog — von der Begrüßung bis zum Klingeln beim Teilnehmer — dauert jetzt 23 Sekunden, und die Zeitabläufe wirken natürlich und nicht mechanisch.
Die Spracherkennung verarbeitet umgangssprachliche Eingaben zuverlässig — Anrufer müssen nicht in kurzen Kommandos sprechen. Das System erkennt die relevanten Schlüsselwörter (Namen und Nebenstellen) aus einer JSON-Datei, auch wenn sie von anderem Text umgeben sind. Es funktioniert mit einem alten Wählscheibentelefon über eine Fritz!Box, also reines alaw-Schmalband.
Die obere Grenzfrequenz des Bandpassfilters wurde von 3200 Hz auf 3900 Hz angehoben, was näher an der tatsächlichen Bandgrenze des klassischen Telefonnetzes liegt und die Konsonantenerkennung verbessert. beam_size wurde von 10 auf 4 reduziert, best_of von 10 auf 2. Diese beiden Änderungen reduzieren die Rechenzeit auf dem Host-Rechner (Intel Core i3 Mini-PC) erheblich, ohne spürbare Einbußen bei der Erkennungsgenauigkeit. Bei einem geschlossenen Vokabular von rund 63 bekannten Namen ist aggressives Beam Search schlicht nicht nötig — der initial_prompt lenkt Whisper bereits stark in Richtung der erwarteten Namen.
Gleichzeitige Anrufer werden sauber getrennt: Asterisk startet pro Anruf einen eigenen AGI-Prozess, sodass jede temporäre Audiodatei durch Prozess-ID und einen Aufnahme-Index eindeutig benannt ist, zum Beispiel vermittlung_roh_23193_0.wav und vermittlung_roh_24817_0.wav. Datei-Konflikte sind auch bei gleichzeitiger Last nicht möglich.
Hier ein Beispiel, wie die Spracherkennung aus dem Rohtext die Stichwörter herausfischt:
Launched AGI Script /usr/share/asterisk/agi-bin/whisper_vermittlung.py whisper_vermittlung.py: Fräulein vom Amt gestartet whisper_vermittlung.py: Kanalformat: alaw whisper_vermittlung.py: Prompt gebaut: 63 Einträge -- <IAX2/incoming-raspi111-1029> Playing '/tmp/ansage_27737.slin' (escape_digits=) (sample_offset 0) (language 'en') whisper_vermittlung.py: ROHTEXT [0]: [ja guten morgen, schönen sonder guten morgen, schmeißen sie bitte diesen hans müller mal aus dem bett] whisper_vermittlung.py: Name erkannt: hans müller -> 1864 -- <IAX2/incoming-raspi111-1029> Playing '/tmp/ansage_27737.slin' (escape_digits=) (sample_offset 0) (language 'en') whisper_vermittlung.py: ROHTEXT [20]: [aber bitte schnell.] whisper_vermittlung.py: Bestätigung [0]: [aber bitte schnell.] -> ja -- <IAX2/incoming-raspi111-1029> Playing '/tmp/ansage_27737.slin' (escape_digits=) (sample_offset 0) (language 'en') -- <IAX2/incoming-raspi111-1029>AGI Script whisper_vermittlung.py completed, returning 0 -- Executing [500@telefone:4] GotoIf("IAX2/incoming-raspi111-1029", "0?hangup,1") in new stack -- Executing [500@telefone:5] GotoIf("IAX2/incoming-raspi111-1029", "0?hangup,1") in new stack -- Executing [500@telefone:6] GotoIf("IAX2/incoming-raspi111-1029", "0?hangup,1") in new stack -- Executing [500@telefone:7] NoOp("IAX2/incoming-raspi111-1029", "Verbinde: Typ=name Name= Nummer=1864") in new stack -- Executing [500@telefone:8] Dial("IAX2/incoming-raspi111-1029", "IAX2/outgoing-raspi111/1864") in new stack -- Called IAX2/outgoing-raspi111/1864 -- Call accepted by 192.168.1.111:4569 (format g722) -- Format for call is (g722) -- IAX2/outgoing-raspi111-14636 answered IAX2/incoming-raspi111-1029
Anmelden
