werniman
Goto Top

Wireshark: RTP-Streams identifizieren

Hallo,
wir haben seit einiger Zeit in der Firma einige Probleme mit unserem Netphone-Server,der unsere Telefonanlage ist. Ab und an ist nämlich einfach einer der Teilnehmer eines Telefonats nicht zu hören,d.h. entweder hört man die Gegenseite nicht oder umgekehrt. Selbst die Telekom,die den Netphone-Server eigentlich supportet, ist inzwischen ziemlich ratlos,weil die Logs des Netphone selbst keinen Fehler aufzeigt. Nun soll als Nächstes ein Dumpfile mit Wireshark gemacht werden, um daran evtl sehen zu können,wo die Verbindung hängt. Soweit,sogut.
Bislang hatte ich Wireshark noch nie wirklich benutzt, aber nun hab ich mir das Programm mal im Vorfeld mit so einem Mitschnitt angeschaut. Über Telephonie=>VoiIP-Anrufe kann ich den betreffenden Anruf finden. Über Telephonie=>RTP=>RTP-Stream sind die aufgezeichneten Audiostreams gelistet und könnten da auch nochmal angehört werden (keine Panik,daran hab ich kein Interesse). Meine Frage ist eher technischer Natur: Wenn man so ein Dump in einer großen Firma für geraume Zeit anfertigt, laufen da im RTP-Fenster so einige Streams zusammen. Wie kann ich rausfinden, welcher RTP-Stream zu welchem Anruf gehört ? Im RTP-Fenster gibts augenscheinlich keinen Zeitstempel o.ä.,um die Streams irgendwie den einzelnen Anrufen zuzuordnen....

Content-ID: 385787

Url: https://administrator.de/forum/wireshark-rtp-streams-identifizieren-385787.html

Ausgedruckt am: 24.12.2024 um 01:12 Uhr

erikro
erikro 07.09.2018 um 16:05:54 Uhr
Goto Top
Moin,

spontane Idee: Filtere das zusätzlich nach den IPs der Telefone.

hth

Erik
LordGurke
LordGurke 07.09.2018 aktualisiert um 18:44:11 Uhr
Goto Top
Benutze stattdessen den Menüpunkt "Telephonie -> VoIP calls", da werden die einzelnen Anrufe gelistet und von dort kommst du auch in die RTP-Analyse der damit zusammenhängenden Streams.

P.S.: Unabhängig davon ob du daran Interesse hast oder nicht, stellt das ein illegales Aufzeichnen der Telefongespräche dar. Illegal solange, wie nicht beide Gesprächsparteien darüber informiert sind.
Florian961988
Florian961988 23.01.2019 aktualisiert um 11:54:38 Uhr
Goto Top
Hallo,

wir haben seit kurzem das gleiche Problem mit der Netphone, ich sehe im Wireshark auch nichts, das Problem besteht sowohl intern als auch extern!

Ich habe natürlich auch schon Telefone und Headsets gewechselt und Kabel kein Erfolg!
Bei uns sind die Telefone in einem VLAN und auch die Netphone in dem Netzwerk, das Telefonnetzwerk läuft über eigenständige Cisco POE Switche die untere einander mit Kupfer verbunden sind!

Das Komische ist einfach das es durch die 100 Leute sporadisch der Fehler auftritt und wenn ich dann teste es einmal auftritt und dann wieder nicht!
Werniman
Werniman 28.01.2019 um 06:42:36 Uhr
Goto Top
Bei uns tritt das Problem noch immer auf. Selbst die Telekom ist ratlos. Deren Support schiebt die Schuld auf Konfigurationsprobleme bei den Trunks, inzwischen wurde da 8-10x die Konfiguration umgeworfen und neu gemacht. Allerdings immer nur mit begrenztem Erfolg...nach diesen Konfiguraitonsorgien funktioniert der Netphone zwar immer erstmal wieder, was ich persönlich aber eher dem in Verbindung damit stehendem Neustart des Netphone-Servers bzw der Dienste zuschreibe. Das funktioniert allerdings auch ohne Umkonfiguration. Es kann aber nicht der Sinn der Sache sein, dass ich den Server mehrfach am Tag manuell neustarte.
Interessanterweise tritt das Problem immer nur periodisch auf. Mal funktionierts einige Wochen lang problemlos, dann geht wieder tagelang fast gar nix. Testweise hab ich mal sämtliche Firewalls ausgeschaltet (im Netphone-Server und im Router) ,aber auch das brachte nichts.

Inzwischen haben wir ein neues Problem: Unsere ganzen Außenstellen sind per VPN an die Zentrale angebunden,wo der Netphone-Server steht. In einer Außenstelle bricht die Kommunikation der Telefone nach 20sek bis 3min zusammen,d.h. die Verbindung wird einfach getrennt und es steht für 1sek kurz "Telefonie nicht verfügbar" auf dem Telefondisplay, dann loggt es sich sofort wieder ein. Das passiert sowohl bei internen, als auch bei externen Gesprächen. Allerdings zeigen die Router keine Unterbrechung der VPN-Verbindung an, auch die RDP-Verbindungen der ThinClients zu den Servern in der Zentrale bleiben bestehen. Zuerst dachte ich, dass vielleicht der dort verbaute Lancom-PoE-Switch eine Macke hat, aber es passiert auch,wenn ich testweise mal ein einzelnes Telefon direkt an den entsprechenden LAN-Port des Routers dranhänge. Auch ein Wechsel des "Telefon-Netzwerks" an einen anderen LAN-Port des Routers brachte keinen Erfolg.
Florian961988
Florian961988 28.01.2019 um 15:35:52 Uhr
Goto Top
Hallo,

mittlerweile bin ich etwas weiter, da ein anderer Fehler hinzu gekommen ist und zwar nach 3 minütiger Gesprächszeit brechen Gespräche ab!
Ich konnte dann beobachten, dass auf den Displays der Telefone die Uhrzeit 3 Minuten vom Client PC weg ist und auf der Netphone auch .
Komischer weiße ist die Uhrzeit vom DC korrekt und irgendwann stellen sich die Zeiten dann auch richtig!
Meine Idee ist jetzt obwohl es eigentlich so ist, den DC als NTP-Server auf dem DC das Tool Nettime!
Werniman
Werniman 28.01.2019 um 21:52:55 Uhr
Goto Top
Ich hab keine Ahnung, wie oft sich der Netphone-Server mit der Uhr des DC synchronisiert, aber ich könnte mir durchaus vorstellen,dass er dadurch durcheinander kommt und dann mit Verbindungsabbrüchen reagiert. Allerdings sollte das dann ja bei uns bei allen Außenstellen vorkommen,nicht nur bei einer. Insofern denke ich nicht, dass es daran liegt.
Momentan holt sich unser DC das Zeitsignal von ptbtime1.ptb.de, denn ich habs bislang noch nicht auf die Reihe gekriegt, dem Server begreiflich zu machen, dass er stattdessen die Zeit vom Lancom-Router holen soll. Bessergesagt klappt das Synchronisieren selbst nicht, da der Lancom-Router dem DC den Zugriff auf seine NTP-Funktion verweigert.
Florian961988
Florian961988 29.01.2019 um 07:25:03 Uhr
Goto Top
Ja,
ich glaube ich habe das mal so gelöst
https://www.lancom-systems.de/docs/LCOS/referenzhandbuch/topics/aa112695 ...
und
w32tm /query /source /computer:<RemotePC>