Hi Nitin,
Looking at 3550 (for the first time in years!) it does say that that both sender and receiver reports will have receiver report *blocks*. Each side does send an actual Receiver Report frame at the beginning, although neither are involved in the calculations. So its fine to see times calculated involving only Sender Report frames. You see Sender Report frames because both sides are sending.
I was interested to see some RTCP Extended reports (RFC 3611) in the capture. These have lots of interesting fields, inlcuding Round Trip Delay, and System Delay. It appears as though lots of the fields are filled in with plausible values, but not these 2, which are both 0. Hopefully Wireshark is decoding these OK, but I've never seen them being used in a real trace before. If you look up the spec and see that these are not being dissected correctly, file a bug report and we'll get it fixed. If we are not doing this right, but Hammer is, that might explain where their values come from?
I'm going to draw a detailed picture of how this calculation works (now), and attach include it in
wiki.wireshark.org/RTCP. This will show you exactly what we are measuring. This calculation can be useful, but what you see very much depends upon where the capture point is. It also depends upon the accuracy of the DLSR value filled in by the endpoints. Wireshark does verify the 'Last SR timestamp' field by comparing it against the middle part of the timestamp in the frame we use in our calculation.
One other thing I see is that the DCP / ToS in the IP frames indicates that RTP is send with Expedited Forwarding, whereas RTCP is not. Which might mean that your RTCP frames are treated quite differently from the RTP frames, whose roundtrip time you are actually interested in. Having said that, the measured roundtrip seems pretty constant in both directions.
Hope this helps. I will add a picture to wiki now,
Martin
On Sun, Apr 8, 2012 at 11:08 AM, NITIN GOYAL
<nitinkumgoyal@xxxxxxxxx> wrote:
Hi Martin
Yeah it is actually RTCP network round trip time propagation delay using the DSLR values.
Now, in general as I have explained and calculated by Wireshark, in one direction it seems good but in another direction the delay is very very low which is not practical.
Now, I have tried a tool called Hammer Call analyzer by Empirix (this tool also uses libpcap and calculate the various values as Wireshark do) with the same pcap, i have captured on a LTE network for VoIP calls, the values on both the directions are almost same but that is not the case with the Wireshark.
I have validated it with almost 10 captures I have taken so far. Also, i have seen the RFC 3550 and it seems like that the way WIreshark is calculated the values by referring that RFC only but in all of my captues i dont see any RR(Response Request) packet but only SR(Senders Request) packet but RFC explains calculation using RR packet only.
I can provide you a pcap, please see the attachment. ( i have made a rar as without rar size was more than 800KB which this list is not allowing)
Regards
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
