Re: Issue with RTT values in Wireshark

[Martin Mathieson <martin.r.mathieson () googlemail com>]

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 () gmail com>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
> Nitin
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe