This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Hi! I was capturing a RTP communication between two PC, where in each of one the wireshark was sniffing. Finally when the communication finished I stopped the wireshark and then I went to Telephony-->RTP-->Show All Stream, and the values that had each computer in both ways, were different in each computer. Why this happens if they were capturing the same communication? why one computer show me that there are more jitter than the other one?

Thanks

P.D: I attached the results of both computersalt text!

asked 01 Nov '12, 01:36

Vickynp123's gravatar image

Vickynp123
1447
accept rate: 0%


As you can see, there are less packets (only one) in one capture. In general, packet loss will have an influence on the jitter calculation. In your case however, it's just one packet. So, that should not have such a big influence (hard to tell without access to the capture file).

There can be a much bigger influence on the jitter calculation. Packets may not arrive in the same order as they were sent (taking different routes, QoS on routers, etc.). So if the packets arrive in a different order, you will get totally different values for jitter.

HOWEVER, your hosts seem to be on the same network (192.168.0). So a packet reordering is rather unlikely.

So, what's the reason for the different jitter values? Some suggestions:

  • a bug in the jitter calculation
  • different Wireshark versions
  • different quality of the timestamps, due to different OS or high load on one of the systems

Can you post the capture files (cloudshark.org) for further analysis?

UPDATE/SOLUTION: As already mentioned in my comment below, I was a bit "off track" regarding the packet ordering. The RTP jitter calculation is based (mainly) on the timestamp in the frame (arrival time) and the timestamp in the RTP packet (send time). So, if you calculate the jitter at the sender side, you will get much lower jitter, as the delta between frame timestamp and RTP timestamp is much smaller than at the receiver side. So, it should be "normal" to see different jitter values if you calculate those values at the sender/receiver side.

Looking at the reordered packets. That will also have an influence on the jitter, as the frame timestamp (at the receiver) changes slightly due to the different packet order. HOWEVER, this slightly change will only cause a very small change in the jitter value and can (possibly) be ignored.

Regards
Kurt

permanent link

answered 01 Nov '12, 03:10

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 02 Nov '12, 09:44

Thanks for your answer, I think that the only possibility that can be possible is the last one, because I did another captures with the same situation and the variability in the packets loss and the jitter were also differents. On the other hand, I checked the version of both wiresharks and both have the same version. I have uploaded the captures, the links are:

http://www.cloudshark.org/captures/1811bc69b827 http://www.cloudshark.org/captures/64f69abd3c2e

Tell me something if you arrive to another conclusion when you will see the captures.

Many thanks!

(01 Nov '12, 03:28) Vickynp123

I forgot to say that OS of one computer is windows XP and the other one is windows 7.

thanks

(01 Nov '12, 03:30) Vickynp123

what's the wireshark version?

(01 Nov '12, 03:33) Kurt Knochner ♦

If you filter the capture files to contain just the communication between 192.168.0.106/107, you'll see that there is a different packet order in the capture files, and that (most certainly) explains the different jitter value.

CAP1: http://www.cloudshark.org/captures/9f9e59cf1bef
CAP2: http://www.cloudshark.org/captures/3994ae6480eb

Take a look at frame #19. That's were the different packet order starts. Look at the IP IDs.

So, what's the reason for the reordering in that environment?

If there is only a plain switch between those systems (no WAN simulator used in bridged mode, that does QoS and the like!), the only plausible reason would be WinPcap receiving the packets in different order. Why? Good question, as the amount of reordered packets is quite large. It could be a bug in WinPap while writing the pcap file. What is your Wireshark and WinPcap version?

EDIT: Maybe I'm a bit off the track, but if you calculate the jitter at the client side and at the server side, there might/should be different jitter values, as there is almost no delay at the client side between the packets caused by the network. I'll have to check how the RTP jitter is actually calculated. Maybe, the packet order does not really have a big influence :-)

Regards
Kurt

(01 Nov '12, 04:22) Kurt Knochner ♦

The version of the wireshark is 1.8.3, I think is the last version. And the version of WinPap is 4.1.2

(01 Nov '12, 18:52) Vickynp123

let's see what others think about this "effect".

BTW: I will again think about the problem and if I come to different results, I will update my answer.

(02 Nov '12, 03:11) Kurt Knochner ♦

see my UPDATE in the answer....

(02 Nov '12, 06:25) Kurt Knochner ♦

Thanks for your last answer, now I understand better how it works.

(06 Nov '12, 17:51) Vickynp123

If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(06 Nov '12, 23:38) Kurt Knochner ♦
showing 5 of 9 show 4 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×238
×6

question asked: 01 Nov '12, 01:36

question was seen: 3,041 times

last updated: 06 Nov '12, 23:38

p​o​w​e​r​e​d by O​S​Q​A