Kostenloses Tool: SIP-pcap im Browser analysieren mit KI-Diagnose – Feedback gesucht

[m313rs]

Hallo Zusammen,

ich arbeite hauptberuflich als VoIP-Engineer bei einem Carrier und habe in meiner
Freizeit ein Tool gebaut, das ich hier gern zur Zerreißprobe stelle: www.cause31.de

Was es macht: pcap/pcapng (oder rohe SIP-Logs) reinziehen, das Tool parst alles
lokal im Browser, gruppiert die Dialoge, korreliert Call-Legs über SBC-Grenzen
hinweg (Session-ID/icid) und zeichnet ein End-to-End-Ladder-Diagramm. Auf Knopfdruck
gibt's eine KI-Diagnose mit Root-Cause-Hypothese und RFC-Referenz – und man kann
der KI Rückfragen zum Trace stellen.
Warum ich es gebaut habe: Ich kenne die Situation von beiden Seiten – der Carrier
sagt "bei uns ist alles grün", und der Anlagen-Techniker steht mit einem Wireshark-
Mitschnitt da, den keiner Zeit hat auseinanderzunehmen. Genau dafür ist das Ding.
Zum Datenschutz, weil das bei Traces die erste Frage ist: Das Parsing läuft
komplett im Browser, nichts wird hochgeladen oder gespeichert. Nur wenn man aktiv
auf "KI-Analyse" klickt, geht der ausgewählte Dialog an die Analyse – Rufnummern
werden vorher standardmäßig maskiert.
Es ist komplett kostenlos und ein Freizeitprojekt. Ich suche ehrliches Feedback:
Werft eure gemeinsten pcaps drauf (gern anonymisiert) und sagt mir, wo der Parser
stolpert oder die Diagnose Unsinn erzählt.

Danke & Grüße
Chris

 

[ip-phoneforum72]

Der Grundgedanke ist Mega cool.
Solange man die technische Struktur nicht genauer kennt allerdings ein DSGVO-No-Go. Nicht erst bei KI Abfrage.

Ich schau’s mir an.

 

[m313rs]

Danke dir – und fairer Punkt, den höre ich nicht zum ersten Mal. Deshalb kurz zur Struktur:

Das pcap wird nicht hochgeladen. Parsing, Call-Korrelation und Ladder-Diagramm laufen komplett im Browser (JS/lokal). Kannst du selbst verifizieren: F12 → Netzwerk-Tab → pcap laden → es geht kein einziger Request raus. Bis dahin ist das datenschutztechnisch dasselbe wie Wireshark lokal.

Erst wenn man aktiv auf KI-Analyse klickt, geht der ausgewählte Dialog raus und zwar zwangsweise anonymisiert, das lässt sich nicht abschalten: Rufnummern maskiert, IPs durch konsistente Pseudonyme ersetzt, Display-Namen und Benutzerkennungen entfernt. Die Zuordnungstabelle bleibt im Browser, die Antwort wird lokal wieder rückübersetzt. Details stehen in der Datenschutzerklärung auf der Seite.

Wenn dir beim Reinschauen was auffällt, was ich übersehen habe, immer her damit, genau dafür hab ich's hier gepostet.

LG Chris

 

[ip-phoneforum72]

Die Seite nimmt der Statistik Daten auf. Was davon landet bei dir?

 

[m313rs]

Das ist ein Counter für die Website-Aufrufe und KI-Analyse-Aufrufe. Ist ein JSON mit drei Feldern: pageLoads, analyses und since (Datum). Heißt: keine IPs, keine Timestamps pro Aufruf, keine Inhalte. ich sehe nur wie oft, aber nicht wer. Daneben gibt's ein Rate-Limit, das kurzzeitig im RAM IPs zählt, um Missbrauch der KI-Funktion zu verhindern. Wird nicht gespeichert, kann ich selbst nicht einsehen.

 

[ip-phoneforum72]

Ok, die Auswertung reduziert sich aktuell auf recht spezifische Fälle, korrekt?
Recht allgemeine SIP Themen erfasst er nicht, korrekt?

Hast du einen Überblick, was du bisher implementiert hast?

 

[m313rs]

zu 1: Ausgelegt ist es auf lesbares SIP über UDP oder TCP. Der Mitschnitt selbst darf ruhig gemischt sein (Spiegelport mit ARP, DNS, RTP und allem). Das Tool fischt sich protokollbasiert SIP Messages raus. TLS-verschlüsseltes SIP geht naturgemäß nicht. RTP wird bewusst nicht angefasst – aus Datenschutzgründen bleibt der komplett außen vor. -> RTP-/RTCP-Auswertung (Jitter/Loss aus Sequenznummern, Timestamps und RTCP-Reports, ohne Gesprächsinhalt und ohne KI Analyse) wäre was für die Zukunft.

zu 2: Call-Dialoge komplett – Setup, Abbrüche, re-INVITEs, Session-Timer. Presence/SUBSCRIBE/NOTIFY-Kram bewusst nicht, der Fokus liegt auf Trunk-Debugging zwischen Anlage und Carrier. Wie kompliziert der Fall ist, spielt keine Rolle. Die Diagnose ist keine feste Regelliste, dem Tool ist egal, wie viele RFCs am Ende herangezogen werden müssen.

zu 3: Implementiert ist aktuell: pcap/pcapng- und Log-Parsing komplett im Browser, Korrelation der Call-Legs, auch multiple Call-ID's über mehrere Hops, End-to-End-Ladder, KI-Diagnose mit RFC-Referenz plus Rückfragen, Gut-/Schlechtfall-Vergleich.
REGISTER-Analysen sind noch nicht weit ausgebaut – der Raum ist da aber auch klein, meistens hängt es schlicht an den Credentials. Steht auf der Liste.

 

[ip-phoneforum72]

Du willst es also noch erweitern?

Wird es denn genutzt?
Man kann ja anhand der Rückmeldungen hier meinen, dass es keinen interessiert.

Ansonsten wird es vermutlich Unternehmen schwer das zu nutzen. Sie müssten ja erst einen AV Vertrag mit dir schließen. Ob die das aber machen?

Wer ist deine Zielgruppe?

 

[m313rs]

Genutzt wird es im kleineren Kreis. Das Tool ist erst ein paar Wochen alt. Ob's jetzt am Ende die Masse interessiert, entscheidet sich ja eher draussen, nicht hier. Ich bau es gerade an echten Fällen entlang aus.

Zum AVV: Der wäre nur Thema, wenn bei mir personenbezogene Daten verarbeitet würden – werden sie aber nicht. Wie gesagt, Parsing läuft komplett im Browser (mein Server sieht den Trace nie) und was bei der KI-Analyse rausgeht, ist zwangsanonymisiert. Wo keine personenbezogenen Daten sind, gibt's nichts zu beauftragen. Sollte trotzdem ein AVV von nöten sein, auch kein Thema.

Zielgruppe: TK-Techniker und Systemhäuser, die zwischen Anlage und Carrier hängen und beim Trunk-Problem beweisen müssen oder wollen, wer schuld ist.

Aber lass mich die Frage mal umdrehen, weil du offensichtlich aus der Praxis kommst: Was wäre denn deine Einschätzung, woran es scheitern könnte? Kein Bedarf, weil Trunk-Probleme zu selten sind? Oder traut man dem Tool schlicht nicht?

 

[ip-phoneforum72]

Scheitern? Nur wg der Sorge seiner Daten.
Ansonsten fehlende Auswertung natürlich auch. Wenn die Erwartungshaltung größer ist, als das Tool leistet. Vermutlich solltest du daher dran bleiben und z.B. auch rt(c)p Daten z.B. analysieren und bewerten.

 

[m313rs]

Gut, die Auswertung ist dann jetzt drin Pro Call und pro Richtung: Paketverlust (aus Sequenznummern-Lücken), Jitter (nach RFC 3550 aus Timestamps und Ankunftszeiten berechnet), Aussetzer, Duplikate und Reordering. Dazu die tatsächliche Paketierung (Ptime) aus den RTP-Timestamps, abgeglichen gegen das a=ptime aus dem SDP. Weicht sie ab, gibt's eine Warnung. Ist RTCP im Trace, kommt die Selbstauskunft der Gegenstelle dazu (Fraction Lost, kumulierte Verluste etc.). Einseitiges Audio wird als eigener Befund erkannt, ist ja der Klassiker. Kannst es ja mal testen und Feedback geben. Sieht man jetzt unter "Call-Flow" als "Media-Qualität". Wie gesagt, auch das, alles nur im Browser, keine KI. Danke!

 

[ip-phoneforum72]

Ok, grundsaetzlich weiterhin super.
Ich habe das aber mal ueber die DEV Tools analysiert und per HAR File ausgewertet.
Du verfolgst schon einen schönen Ansatz zum Datenschutz.
Allerdings ist hier noch deutlich Luft nach oben. Laut meiner Analyse (die ja auch falsch sein kann):

Aus meiner Sicht wäre die Lösung noch deutlich datenschutzfreundlicher, wenn zusätzlich vor der KI-Übertragung beispielsweise ersetzt würden:

• Call-ID
• Authorization
• Proxy-Authorization
• username=
• realm=
• nonce=
• response=
• SDP o=
• Contact-URI
• SIP-Domain
• Via-Hostnamen
• sämtliche X-...-Header

Denn für eine technische SIP-Fehleranalyse sind diese Informationen in vielen Fällen gar nicht erforderlich.
Derzeit werden diese Daten anscheinend NICHT maskiert!

Insgesamt​

Ich muss sagen: Die Architektur macht einen sehr guten Eindruck. Die Entscheidung, nicht die PCAP, sondern einen lokal extrahierten SIP-Dialog als Text zu übertragen, ist aus Datenschutzsicht deutlich besser als viele vergleichbare Cloud-Analysen.

Die Analyse zeigt aber auch, dass die Aussage „Benutzerkennungen entfernt“ auf Basis meines HAR nicht zutrifft. Im Gegenteil: Der SIP-Benutzername wird mehrfach im Request übertragen – sowohl in den Authorization-Headern als auch im SDP (o=). Ebenso bleiben Domain, Call-ID und Authentifizierungsparameter erhalten. Diese Felder würde ich für eine möglichst datenschutzfreundliche Umsetzung ebenfalls bereinigen oder pseudonymisieren.

Ansonsten TOP!
Weiter dranbleiben.

 

[m313rs]

Beim Auth-Header und den Domains hast du absolut recht. response= war davon der heikelste Teil, der Digest-Hash ist ja offline angreifbar. Der geht jetzt geschwärzt raus, der Rest (username, realm, nonce, cnonce, opaque) wird konsistent pseudonymisiert statt gelöscht, damit 401-Loops und stale-Verhalten diagnostizierbar bleiben. Domains/Hostnamen werden topologie-erhaltend ersetzt (gleiche Basis-Domain -> gleiches Pseudonym), o=-Zeile und X-Header-Werte sind ebenfalls drin. Die Call-ID finde ich dagegen etwas schwächer. Man bräuchte ja zur Korrelation eines Calls CDRs, und wer die hat, hat sowieso schon alle Daten. Habe ich der Vollständigkeit halber aber trotzdem mit in die Pseudonymisierung genommen.
Fänd's cool, wenn du deinen HAR-Test nochmal wiederholen könntest.

 

[ip-phoneforum72]

Hallo,

ich habe mir das neue HAR angesehen und muss sagen: Die Änderungen sind deutlich erkennbar.

Die Pseudonymisierung ist gegenüber der ersten Version erheblich verbessert. Insbesondere Benutzerkennungen, Call-ID, Digest-Header, Session-IDs und eigene Header werden jetzt sauber ersetzt bzw. geschwärzt. Im HAR ist außerdem nachvollziehbar, dass an die KI nur noch die pseudonymisierten Werte übertragen werden und die Rückübersetzung offenbar erst lokal im Browser erfolgt. Das entspricht genau dem Konzept, das du beschrieben hattest.

Einen kleinen Punkt habe ich noch beobachtet:
In der angezeigten KI-Auswertung erscheinen wieder die Originalwerte. Nach Analyse des HAR gehe ich aber davon aus, dass diese erst lokal anhand der Mapping-Tabelle zurückübersetzt werden und nicht von der KI stammen. Falls das so ist, wäre das aus meiner Sicht vielleicht noch ein Satz in der Dokumentation oder Datenschutzerklärung wert – das macht die Architektur für Außenstehende deutlich nachvollziehbarer.

Ansonsten macht die Lösung inzwischen einen wirklich durchdachten Eindruck. Danke auch dafür, dass du das Feedback so schnell aufgegriffen und umgesetzt hast.
Grundsätzlich interessant (und für mich als Du wäre das eher enttäuschend):
Hier im Forum sind schon einige (wenige), die echt Ahnung haben. Dieses Tool hier, ist eine absolute Bereicherung! Und doch scheint das Interesse der anderen ja gegen "0" zu gehen. Was ist los mit Euch (anderen?). Wollt Ihr nicht mal Stellung nehmen? Kann doch nicht sein, dass Kollege m313rs was so Gutes entwickelt hat - und kein anderer reagiert.

 

[ip-phoneforum72]

Ich habe den Test jetzt noch einmal mit einer deutlich realistischeren SIP-PCAP wiederholt.

Positiv ist zunächst, dass die klassischen SIP-Identitäten mittlerweile sehr gut pseudonymisiert werden. Rufnummern, SIP-Benutzer, Call-ID, IP-Adressen, Domains sowie die üblichen Digest-Parameter werden nach meinem Test zuverlässig ersetzt. Außerdem konnte ich im HAR keine Hinweise darauf finden, dass nach der lokalen Rückübersetzung erneut Daten an den Server übertragen werden.

Mir sind allerdings noch einige Felder aufgefallen, die im Request an die KI unverändert enthalten waren. Dazu gehören beispielsweise Freitextfelder (z. B. Organisation oder Session-Name), Geräte- und Serverbezeichnungen, ICE-Parameter, SDES-a=crypto-Zeilen sowie einzelne Kennungen innerhalb anderer Header.

Mein Eindruck ist daher: Die "klassische" SIP-Pseudonymisierung funktioniert inzwischen wirklich gut. Bei einer sehr umfassenden Datenschutzbetrachtung gäbe es aus meiner Sicht aber noch Potenzial, auch solche eher ungewöhnlichen bzw. eingebetteten Informationen zu bereinigen.



Falls dich noch interessiert, was ich persönlich als nächste Optimierungsschritte sehen würde:

Datenschutz
Die "klassischen" SIP-Identitäten scheinen inzwischen wirklich gut abgedeckt zu sein. Ich würde zusätzlich überlegen, auch eher ungewöhnliche oder eingebettete Informationen konsequent zu pseudonymisieren, z. B.

• Freitextfelder (Organization, Session-Name usw.)
• Geräte- und Serverbezeichnungen
• ICE-Parameter
• SDES-a=crypto
• Session-IDs
• Kennungen innerhalb von URLs oder proprietären Headern

Gerade diese Dinge fallen bei einer normalen SIP-Betrachtung oft nicht auf, können aber je nach Umgebung durchaus Rückschlüsse auf den Kunden zulassen. Und die crypto Angaben sehe ich als eher problematisch zur Weitergabe...


KI-Diagnose
Die eigentliche Analyse finde ich erstaunlich gut. Mir ist allerdings aufgefallen, dass die KI teilweise sehr konservativ bewertet und Auffälligkeiten relativ schnell als "kritisch" einstuft, obwohl der Dialog technisch erfolgreich abläuft.

Vielleicht könnte man der KI noch stärker mitgeben, zwischen

• RFC-konform,
• ungewöhnlich,
• potenziell problematisch und
• tatsächlich ursächlich für den beobachteten Fehler

zu unterscheiden.

Bei meinem Referenzdialog wurden beispielsweise mehrere Punkte als "kritisch" bewertet, obwohl der Rufaufbau einschließlich Re-INVITE und BYE vollständig erfolgreich verlief. Ich könnte mir vorstellen, dass hier eine etwas zurückhaltendere Einstufung (z. B. Hinweis statt kritisch) die Praxistauglichkeit noch erhöhen würde.

Aus meiner Sicht wäre das sogar die größte Verbesserung überhaupt:

Die KI sollte ihre Sicherheit (Confidence) angeben.

Zum Beispiel:

Bewertung	Confidence
Kritisch	98 %
Warnung	72 %
Hinweis	38 %

oder

• Hohe Sicherheit
• Mittlere Sicherheit
• Hypothese

Gerade bei SIP gibt es sehr viele Konstellationen, die ungewöhnlich, aber trotzdem vollkommen legitim sind. Wenn die KI stattdessen formuliert:

"Mit mittlerer Sicherheit deutet dies auf ... hin."

wirkt das fachlich deutlich glaubwürdiger und hilft dem Anwender besser bei der Einordnung.

Ein weiterer Ansatz könnte sein, die Schwere nicht nur an der RFC-Abweichung, sondern auch an den beobachteten Auswirkungen zu orientieren. Wenn ein Gespräch vollständig aufgebaut wird, Audio funktioniert und sauber beendet wird, dann sollten Auffälligkeiten eher als Hinweis oder Optimierungspotenzial erscheinen, solange keine konkreten Symptome auf einen tatsächlichen Fehler hindeuten. Das würde die Zahl der False Positives vermutlich deutlich reduzieren und die Analysen für Administratoren noch wertvoller machen.


Das ändert aber nichts daran, dass ich den grundsätzlichen Ansatz und die Qualität der Analyse wirklich gelungen finde. Das sind aus meiner Sicht eher Feinschliff-Themen.


Unabhängig davon finde ich den gewählten Ansatz – lokale Analyse und nur Übertragung des ausgewählten SIP-Dialogs – nach wie vor sehr gelungen. Ich wollte die Beobachtungen lediglich als weiteres Feedback aus einem praxisnahen Test teilen.

 

[m313rs]

Danke für das ausführliche Feedback. Ich habe dementsprechend Anpassungen vorgenommen (weitere Pseudo-/Anonymisierungen, Prompt bzgl. Einstufung angepasst).