Ask Your Question
0

RTP telephony stream shows 0 jitter

asked 2022-06-09 15:48:32 +0000

I have a capture file of an RTP stream and wanted to check my jitter levels. However when i used the RTP->RTP Streams option under telephony these are the jitter values displayed: Min Jitter = -1 Mean Jitter = 0 Max Jitter = 0 I know for a fact that these values cannot be correct as there is a variance in delay so the mean can't be 0. I've seen some people suggesting that it could be a clock synchronization problem but I have no idea how to solve it. Any help is much appreciated!

edit retag flag offensive close merge delete

Comments

Please add the Wireshark version info to the question.
(wireshark -v or Help->About Wireshark:Wireshark)

Chuckc gravatar imageChuckc ( 2022-06-09 19:50:07 +0000 )edit
Chuckc gravatar imageChuckc ( 2022-06-09 19:56:42 +0000 )edit

Wireshark 3.6.3 (v3.6.3-0-g6d348e4611e2)

UniStudent122222 gravatar imageUniStudent122222 ( 2022-06-09 20:17:27 +0000 )edit

Can you share a packet capture on a public file share and add a link to it in the question above?

If clock_rate is not set (tap-rtp-analysis.c) min_jitter is not calculated.
clock_rate is set based on the payload type.

Chuckc gravatar imageChuckc ( 2022-06-10 16:59:40 +0000 )edit

https://drive.google.com/drive/folder...@Chuckc here is a google drive link with the capture file. Thank you for your help!!

UniStudent122222 gravatar imageUniStudent122222 ( 2022-06-11 10:53:38 +0000 )edit

I'm assuming that since its a dynamic payload type the clock rate is not set and therefore the jitter cannot be calculated in this case. Not sure if this is the right conclusion tho

UniStudent122222 gravatar imageUniStudent122222 ( 2022-06-11 10:54:54 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-06-11 15:54:33 +0000

Chuckc gravatar image

I have not been able to find a sample capture with dynamic payload that is not DTLS.
The clock rate for dynamic payloads is extracted from a string in the packet (tap-rtp-analysis.c) that is not available due to the encryption.
Here is a similar issue: 17905 - RTCP compound packets not shown (closed)

All of the malformed packets in the capture are worth opening a new issue - Wireshark Gitlab Issues
(ReportingBugs, Wishlist - select Bug). Please add a link to it that points back to this question and link to the sample capture in the Gitlab Issue.

edit flag offensive delete link more

Comments

Assuming this is SRTP/SRTCP these are not malformed, just not decrypted.

Jaap gravatar imageJaap ( 2022-06-11 16:08:05 +0000 )edit

There is a mix of [Encrypted RTCP Payload - not dissected] and [Malformed Packet (Exception occurred)]. Maybe not recognizing as encrypted sometimes?

Chuckc gravatar imageChuckc ( 2022-06-11 16:14:41 +0000 )edit

Without the associated signalling it's hard to tell from the packet content alone.

Jaap gravatar imageJaap ( 2022-06-12 05:22:08 +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

Stats

Asked: 2022-06-09 15:48:32 +0000

Seen: 303 times

Last updated: Jun 11 '22