Wireshark · Wireshark-users: Re: [Wireshark-users] Delay-Calculations with RTCP-Packets

["Martin Mathieson" <martin.r.mathieson@xxxxxxxxxxxxxx>]

On 5/22/07, Eram Khan <eramk2003@xxxxxxxx> wrote:
>     Hi!! I am Eram Khan from Germany. Studying Computer Enginerring at the
> Niederrhein University of Applied Sciences and currently busy with my thesis
> project.
>
>   I am testing the VoIP connections of a firm here in Germany with wireshark
> 0.99.5. They have here the Siemens Opticlient Telephone Software. Im using
> the RTCP- Packets to determine the parameters jitter, packet-loss and delay.
> I have problems in delay calculations, according to RFC 3550 the formula is
> : A - LSR - DLSR
>   where A = the arrival time of the reception report,
>   LSR = the middle 32 bits out of 64 bits in the NTP time stamp of the most
> recent sender report and DLSR = the delay expressed in 1/65536 between
> receiving the last SR packet from a source and sending the reception report
> block.
>   I have a confusion regarding the conversion of these values, I hav asked
> my Prof and his colleagues and the Network Administrator here in the firm,
> all hav different views. 2 of the views im describing below:
>
>   View. 1
>
>   Delay (in ms) = Arrival time - (LSRx1000) - DLSR/(65536x1000)
>   Arrival time and DLSR are from the same rtcp packet and LSR is also from
> the same packet.
>   Arrival time conversion with respect to 01.01.1900.
>   I get a negative value for delay.
>
>   View. 2
>   Delay = Arrival time - LSR - DLSR
>   Arrival time and DLSR are from the same rtcp packet and LSR is from the
> next rtcp packet ( which contradicts the definition of LSR)
>   Arrival time conversion with respect to 01.01.1900.
>   I get a negative value sometimes and sometimes an extremely high value for
> delay.
>
>   I hav read the Wireshark guide too and found this:
>   The internal format that Wireshark uses to keep a packet time stamp
> consists of the date (in days since 1.1.1970) and the time of day (in
> nanoseconds since midnight).
>
>   But I calculate the Arrival time from 01.01.1900 as it is for
> NTP-timestamp.
>   Im also confused with conversions of LSR and which value is correct. Could
> somebody send an example calculation where i can see step by step how the
> calculation is done.
>   Thanks a heap!!!
>   Attachments: View1-2 Arrival time calculation and View 2 Delay calculation
> using Frame 1114 in rtcp-test and rtcp-test (consist of rtcp packets only,
> open it with Notepad)

I keep meaning to add a proper worked example to the wiki, but have
never gotten around to it.  Please open the attached capture file and
follow along with this description:

(1) Frame 1 is sent at time 0 (from the wireshark time column)
(2) Its (crazy) timestamp is from 1991, but the important thing to
note is that the middle bytes are 0x0000c8df
(3) Frame 2 is received 1.932841 seconds (= 1932ms) after frame 1.
(4) It also has a crazy timestamp (2036), but again this is not
important, because...
(5) The LSR does match the middle part of the timestamp from frame 1
(0x0000c8df), so we can try to do a calculation
(6) The DLSR is 125830, which is 1920 ms (note that the current
wireshark source version shows this...)
(7) So, out of the 1932ms roundtrip, 1920 was spent between reports at
the far end (10.120.97.10), so the rest was the network propagation
roundtrip reported, which is reported (after rounding) as 13ms

In this trace, the capture was probably done at 172.16.68.164 - if you
capture very close to one of the endpoints you will only see
measurably delays in one direction.

The timestamps in the RTCP frames are only used by wireshark to
confirm that the DLSR corresponds to the same (earlier) frame that is
used in the calculation.  If an endpoint does this calculation, it
uses the original timestamp and actual time of reception of the 2nd
frame.  Wireshark can't - it uses the frame timestamps at the point of
capture.

Relating this to the variables from the RFC:

Delay = Arrival time - LSR - DLSR
         = (timestamp of receiving returned report, i.e. frame 2) -
             (timestamp of sending original report, i.e. frame 1) -
             (DLSR, as seen in the frame 2)

I hope this makes sense,
Martin


> ---------------------------------
> Yahoo! Clever - Sie haben Fragen? Yahoo! Nutzer antworten Ihnen.

Attachment: rtcp-delay-example.pcap
Description: Binary data