-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PCAP captured RTP showing poor call quality #117
Comments
Attached is a sample of the recorded call from VoIP Mon |
Hello, Do you mirror packets to the voipmonitor? I suppose that the sniffer is not running directly on the production server alongside with SBC |
Correct - Mirror it from the router/FW The marked packets are then sent to the sniffer |
on the picture I see that the voipmonitor is not getting packets (large packet loss) - there must be problem with the mirroring kapacity on your switch. If the sniffer / linux drops it due to overload you would see it directly in the CDR that libpcap reported dropped packets in the kernel and this event is logged in the /var/log/syslog (voipmonitor process) and such CDR are flagged that linux kernel dropped packets. (I suppose you are not using DPDK) |
Thanks - Ill check and revert back :-) |
can you please paste more logs from the syslog where voipmonitor writes stat every 10 seconds? around the dropped packets |
Please find attached |
From the log it is not obvious where the problem is - can you please upgrade to the latest sniffer and let us know if it is still problem? |
When our US SBCs are busy, the VoIP monitor calls shown in the CDR list shows poor call statistics
Furthermore when listening to the audio playback, the audio quality is very choppy and very very bad.
However the actual call between user 1 and user 2 was OK without these issues
This makes the troubleshooting of calls really difficult when users report quality issues
Strangely, when there aren't many calls, all CDR calls show good metrics and the recordings are good too
Its like not all packets are processed, and it takes a very long time for calls to show in voipmonitor - I can put this down to the volume of calls that needs to be oppressed
Any Ideas please?
The text was updated successfully, but these errors were encountered: