it seems wireshark RTP stream analysis jitter calculation incorrect, in example below note the inter RTP packet delay variation ( i.e jitter ), but represented as 0ms
any ideas why jitter is always represented as 0ms ? given the apparent inter RTP packet delay variation....
https://wiki.wireshark.org/RTP_statis...
RTP timestamp: RTP timestamp is based on the sampling frequency of the codec, 8000 in most audio codecs and 90000 in most video codecs. As the sampling frequency must be known to correctly calculate jitter it is problematic to do jitter calculations for dynamic payload types as the codec and it's sampling frequency must be known which implies that the setup information for the session must be in the trace and the codec used must be known to the program(with the current implementation).
ok thanks, that makes a lot of sense, as 8x8 do SIP over TLS, and i don't have the X.509 certificate, i'm unable to dissect the SIP part of the call. I am pushing 8x8 to move away from codec / Payload type = 121, to either G.722 or G.711, but they are struggling to achieve this...only getting thier useless scripted support so far.. Thanks for the explanation though.
https://code.wireshark.org/review/git...
* Ignore jitter calculation for clockrate = 0
The analysis can't determine the clockrate for the payload type DynamicRTP-Type-121 so skips jitter calculation.
I think that the display in such cases should be amended to display "N/A" or similar instead of 0 for the jitter. An item for someone interested to raise at the Wireshark Bugzilla.
+1 for N/A in the Jitter/Skew columns when they can't be calculated
Comments
I just tried Wireshark 3.2.0 on one of my VoIP pcaps and it shows Jitter correctly. Can you tell us which Wireshark version you are using? Are you able to share the pcap file on a public fileshare? There might be something inside your traffic that triggers this behavior.
i'm already running wireshark 3.2.0, i've shared the pcap to link below;
https://drive.google.com/file/d/1PlCG...