Ask Your Question

Wireshark RTP stream analysis jitter calculation always zero?

asked 2020-01-11 06:05:40 +0000

updated 2020-01-12 09:53:04 +0000

Jaap gravatar image

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....

edit retag flag offensive close merge delete


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.

SYN-bit gravatar imageSYN-bit ( 2020-01-11 10:06:54 +0000 )edit

i'm already running wireshark 3.2.0, i've shared the pcap to link below;

Hazza06 gravatar imageHazza06 ( 2020-01-12 02:19:02 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-01-12 02:54:27 +0000

Chuckc gravatar image

updated 2020-01-12 03:14:46 +0000

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).
edit flag offensive delete link more


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.

Hazza06 gravatar imageHazza06 ( 2020-01-12 03:17:00 +0000 )edit
* Ignore jitter calculation for clockrate = 0

The analysis can't determine the clockrate for the payload type DynamicRTP-Type-121 so skips jitter calculation.

Chuckc gravatar imageChuckc ( 2020-01-12 03:21:31 +0000 )edit

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.

grahamb gravatar imagegrahamb ( 2020-01-12 12:25:43 +0000 )edit

+1 for N/A in the Jitter/Skew columns when they can't be calculated

SYN-bit gravatar imageSYN-bit ( 2020-01-12 12:30:59 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-01-11 06:05:40 +0000

Seen: 258 times

Last updated: Jan 12