Dongle: interaktiver Antwort-Bot (Zwei-Wege-Audio, VAD, Gesprächsaufzeichnung)

[haumacher]

Ziel

Der Dongle kann bisher nur eine Ansage abspielen. Der Docker-/Cloud-Antwort-Bot kann sich dagegen "richtig" mit Anrufern unterhalten. Dieses Issue verfolgt, dem Dongle dieselbe Fähigkeit zu geben: ankommendes Audio empfangen, erkennen ob das Gegenüber spricht oder schweigt (Voice Activity Detection), und über einen Workflow aus vordefinierten Ansagen einen Dialog ablaufen lassen — autark auf dem ESP32, ohne Server im Audio-Pfad.

Stand: Machbarkeit belegt (Stufe 1)

Auf der echten Hardware (http://answerbot) verifiziert:

• Zwei-Wege-Audio: der bestehende RTP-Task empfängt jetzt zusätzlich (gebundener Socket, voll-duplex), inkl. SRTP-RX (Remote-Key aus dem a=crypto-Angebot) und A-law-Decode. Plain RTP wird direkt geparst.
• Energie-VAD (vad.c, host-getestet): RMS→dBFS pro 20-ms-Frame, Schwelle + Mindest-Stille mit Entprellung — dasselbe Schema wie der Cloud-AB (AlawSilenceTrimmer). Per Aufnahme-Analyse bewiesen: erkennt Stille exakt min-silence-time nach Sprech-Ende (1,5 s).
• Comfort-Noise statt Ansage zum Testen (konfigurierbarer Pegel), endlos bis der Anrufer auflegt; Pieps bei erkannter Stille als hörbares Testsignal.
• Gesprächsaufzeichnung: Echtzeit-Streaming (chunked HTTP/HTTPS PUT) an einen konfigurierbaren Endpoint, Misch aus Sende- und Empfangsspur auf der Dongle-Zeitachse. Bewusst nicht über phoneblock.net.
• Konfiguration (NVS + Web-UI): silence-db, min-silence-time, padding-time, Rausch-Pegel, Recorder-URL/-Auth.

Architektur-Entscheidungen

• VAD + Dialog laufen komplett auf dem Dongle (passt zur autarken Philosophie).
• Aufzeichnung wird direkt an ein nutzer-kontrolliertes Ziel gestreamt (WebDAV/Nextcloud o. ä.), kein Puffern (kein Platz im Flash), nicht über phoneblock.net.

Offene Punkte / nächste Stufen

• Stufe 2: echter Mini-Dialog (Phasen-Statemachine wie Cloud-AB) statt Pieps.
• Stufe 3: mehrere Ansagen-Clips je Phase.
• HTTPS-Recording für entfernte Ziele (geschrumpfte mbedTLS-Puffer) — aktuell HTTP/LAN validiert.
• Heap-Budget bei SRTP + paralleler TLS-Upload-Session messen/absichern.
• Dateiname mit Anrufernummer (vorbereitet, aktuell Zeitstempel).
• Web-UI für Recorder-URL/-Auth (aktuell nur über /api/config).
• Rechtliches: Aufzeichnung berührt §201 StGB / DSGVO — Ansage/Aufbewahrung bedenken.

Diagnose-Notiz

Eine gefühlte Reaktionszeit von ~4,5 s stellte sich als Transport-/Wiedergabe-Latenz (Fritz!Box/Telefon-Jitterpuffer) heraus, nicht als VAD-Problem — auf der Dongle-Zeitachse (gemischte Aufnahme) beträgt der Abstand Sprach-Ende→Reaktion exakt 1,5 s.