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 computers asked 01 Nov '12, 01:36  Vickynp123 |
!
One Answer:
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:
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 answered 01 Nov '12, 03:10  Kurt Knochner ♦ edited 02 Nov '12, 09:44 showing 5 of 9 show 4 more comments |
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!
I forgot to say that OS of one computer is windows XP and the other one is windows 7.
thanks
what's the wireshark version?
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.
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
The version of the wireshark is 1.8.3, I think is the last version. And the version of WinPap is 4.1.2
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.
see my UPDATE in the answer....
Thanks for your last answer, now I understand better how it works.
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.