Voice-Diagnose – PCAP rein, Befund raus

Ein typischer Vormittag im 2nd Level Voice Support: Eine Telefonanlage beim Kunden kann nicht nach draußen telefonieren. Manchmal. Nicht immer. Natürlich nur bei bestimmten Zielen.

Also ziehe ich einen Mitschnitt, öffne ihn und lese. SIP-Nachrichten, SDP-Aushandlungen, RTP-Ströme. Welcher Dialog gehört zu welchem Anruf? Wer hat das Gespräch beendet, und warum? Stimmt die Medienadresse im SDP mit der überein, von der die Sprachpakete tatsächlich kommen?

Das ist Handwerk, und ich mag dieses Handwerk. Aber es kostet Zeit: 20 bis 45 Minuten pro Ticket, je nachdem, wie verworren der Mitschnitt ist. Und vieles davon ist Fleißarbeit, die sich jedes Mal ähnlich anfühlt.

Irgendwann kam die Frage, die in der Frickelfabrik immer kommt: Kann man das nicht selbst bauen?

Die Idee

Die Arbeitsteilung ist eigentlich naheliegend:

• tshark (die Kommandozeilen-Version von Wireshark) kann einen Mitschnitt präzise zerlegen. Welche SIP-Nachrichten gab es, in welcher Reihenfolge, mit welchen Codes, welche Medienadressen wurden ausgehandelt, wie sahen die RTP-Ströme aus?
• Ein Sprachmodell kann aus diesen Fakten das machen, was ich im Kopf mache: Muster erkennen, Ursachen eingrenzen und einen nächsten Schritt vorschlagen.

tshark liefert die Fakten, das Sprachmodell die Einordnung. Und am Ende entscheidet ein Mensch.

So funktioniert es

1. Upload: Die Kollegin oder der Kollege lädt einen Mitschnitt hoch und gibt die Kundennummer an. Die Kundennummer ist Pflicht, damit jede Analyse einem Vorgang zugeordnet werden kann.
2. Zerlegen: tshark zieht die relevanten Informationen heraus und baut daraus einen kompakten Text. Das Sprachmodell bekommt also keine Binärdatei mit tausenden Paketen, sondern eine aufgeräumte Zusammenfassung.
3. Maskieren: Bevor irgendetwas das Haus verlässt, werden alle Rufnummern ersetzt.
4. Einordnen: Das Sprachmodell bekommt den Text plus einen Produktkontext, also Wissen darüber, wie das betroffene Produkt aufgebaut ist und welche Fehlerbilder typisch sind. Aktuell gibt es Kontexte für vier Produkte.
5. Befund: Heraus kommt eine strukturierte Einschätzung mit Symptom, wahrscheinlicher Ursache und nächstem Schritt.

Bei ISDN-Anschlüssen funktioniert es übrigens anders. Dort gibt es keinen Mitschnitt, sondern ein Text-Protokoll vom Gateway. Das braucht kein tshark und geht direkt an das Sprachmodell.

Datenschutz zuerst – nicht zuletzt

In einem Mitschnitt aus dem Telefonnetz stecken personenbezogene Daten: Rufnummern, Uhrzeiten, Verbindungen. Wer so etwas an ein Sprachmodell schickt, sollte vorher mit dem Datenschutz sprechen. Nicht hinterher.

Deshalb habe ich den Datenschutzbeauftragten früh einbezogen. Die Freigabe kam mit drei klaren Bedingungen:

• Rufnummern werden maskiert, bevor Daten an das Sprachmodell gehen. Das Modell sieht nie eine echte Nummer.
• Jede Analyse wird protokolliert: mit eigener ID, wer, wann, zu welchem Vorgang. Das Protokoll wird 30 Tage aufbewahrt.
• Der Betrieb erfolgt auf Firmeninfrastruktur, und das Sprachmodell läuft in der abgesicherten Cloud-Umgebung des Konzerns, nicht über irgendeinen öffentlichen Dienst.

Was ich dabei gelernt habe: Diese Auflagen sind kein Hindernis. Sie sind ein Argument. Wenn ich das Werkzeug anderen vorstelle, ist die erste Frage fast immer „Und der Datenschutz?“ – und die Antwort ist schon da.

Damit der Wechsel auf die Konzern-Umgebung kein Umbau wird, gibt es eine kleine Abstraktionsschicht. Welches Sprachmodell bei welchem Anbieter angesprochen wird, entscheidet eine einzige Umgebungsvariable. Der Rest des Codes merkt davon nichts.

Was beim Frickeln schiefging

Natürlich lief nicht alles glatt. Drei Geschichten, die ich besonders mag:

Das Telefonat, das es nicht gab

Eines Tages meldete das Werkzeug bei einem Mitschnitt: „Kein SIP gefunden.“ Ich habe die Datei in Wireshark geöffnet, und da war SIP. Jede Menge sogar.

Der Unterschied steckte eine Schicht tiefer. Der Mitschnitt war mit tcpdump -i any entstanden, also auf allen Interfaces gleichzeitig. Dabei schreibt Linux die Pakete nicht mit einem Ethernet-Kopf, sondern mit einem eigenen Pseudo-Kopf namens „Linux cooked capture“ (SLL2). Wireshark kennt das. Meine Auswertung hat aber stur nach Ethernet gesucht.

Die schnelle Lösung war eine Umwandlung in normales Ethernet-Framing. Die eigentliche Erkenntnis kam aber danach: Solche Mitschnitte enthalten fast immer mehrere Gespräche gleichzeitig und tausende Pakete Hintergrundrauschen. Das Problem war nicht die Zerlegung, sondern was danach kam. Daraus ist der nächste große Baustein entstanden: Man soll in einem Mitschnitt den Anruf auswählen können, um den es geht.

Merksatz: Wenn tshark ein Paket korrekt erkennt, das Ergebnis aber trotzdem falsch ist, liegt der Fehler fast immer in der eigenen Verarbeitung danach. Nicht im Zerlegen.

tshark ist nicht Wireshark

Als es darum ging, wie viel Rechenleistung der Server braucht, stand plötzlich die Annahme im Raum, dass hier „Wireshark“ läuft – mit grafischer Oberfläche, entsprechend groß dimensioniert.

tshark und Wireshark teilen sich dieselbe Zerlegungs-Maschinerie, dieselben Dissektoren und dieselben Heuristiken. tshark hat aber keine Oberfläche, es ist ein schlankes Kommandozeilenwerkzeug. Das klingt nach einem Detail, macht aber den Unterschied zwischen „braucht eine eigene, große VM“ und „läuft problemlos in einem Container“.

Die IP-Sperre, die jeden durchließ

Das Werkzeug soll nur aus dem Firmennetz erreichbar sein, also über eine Freigabeliste von IP-Adressen. Davor sitzt ein Reverse Proxy. Und genau da lauert die Falle: Ohne korrekte Konfiguration sieht die Anwendung bei jeder Anfrage nicht die Adresse des Besuchers, sondern die des Proxys. Und der steht natürlich auf der Freigabeliste.

In Express heißt der Schalter trust proxy. Erst damit wertet die Anwendung den Header X-Forwarded-For aus – und zwar nur von dem Proxy, dem sie wirklich vertrauen soll.

Merksatz: Jede IP-basierte Zugangskontrolle hinter einem Proxy ist nur so gut wie die Proxy-Konfiguration.

Was es bringt

Eine Analyse, die vorher 20 bis 45 Minuten gedauert hat, liegt jetzt nach wenigen Minuten als strukturierter Befund vor. Das heißt nicht, dass ich keine Mitschnitte mehr lese. Aber ich lese sie gezielter, weil ich weiß, wo ich hinschauen muss.

Und noch etwas: Kolleginnen und Kollegen, die nicht jeden Tag SIP-Leitern im Kopf haben, bekommen einen Einstieg. Der Befund erklärt, was passiert ist, und ist damit gleichzeitig ein kleines Stück Weiterbildung.

Wichtig bleibt: Der Befund ist ein Vorschlag. Die Entscheidung trifft der Mensch, der das Ticket bearbeitet.

Was noch kommt

• Anruf-Auswahl: In Mitschnitten mit mehreren Gesprächen den richtigen Dialog wählen
• Symptom-Auswahl: Damit das Werkzeug weiß, wonach es suchen soll („einseitige Sprache“, „Abbruch nach 30 Sekunden“ …)
• SIP-Ablaufdiagramm direkt im Befund
• Feedback: War der Befund richtig? Damit das Werkzeug besser wird
• Export direkt ins Ticket
• Umzug in den Regelbetrieb auf der Firmeninfrastruktur

Fazit

Das Spannendste an diesem Projekt war für mich nicht die KI. Es war die Kombination: ein bewährtes Werkzeug für die Fakten, ein Sprachmodell für die Einordnung, ein Mensch für die Entscheidung. Und Datenschutz nicht als Pflichtübung am Ende, sondern als Fundament von Anfang an.

Passend dazu auf der Frickelfabrik:

• SIP-Traces lesen lernen: das Wireshark-Tutorial mit zwei Beispiel-Mitschnitten
• „Telefon geht nicht“: warum die Störungssuche bei VoIP so knifflig ist