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

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

Just choose 'View | Time Display Format | Seconds since previous
Displayed Packet', and you'll see that they are 1932ms apart.  (I
can't follow your calculations where you try to convert the absolute
time to milliseconds - you don't need to do this).

Martin

On 5/22/07, Eram Khan <eramk2003@xxxxxxxx> wrote:
> Hi!! Martin, well your explanation was quite helpful but I still have some
> queries.
>   I used your 2 frames to do the delay calculation, I still get a negative
> value. Maybe I am not calculating it correctly. Im using the 2 frames u hav
> send to show it to u, maybe u can detect my mistake:
>
>   Delay = (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)
>
>   Timestamp of receiving returned report i.e frame 2 = Oct 17,2006
> 17:13:48.145195000
>
>   (927377 h x60 x 60) + ( 13 min x 60) + 48 secs
>   = 3338557200 secs + 780 secs + 48 secs = 3338558028 secs = 0xc6fe5a4c
>
>   0.145195000 / (2 ^(-32)) = 623607776 = 0x252b7fe0
>
>   middle 32 bits of Arrival time = 0x5a4c252b = 1514939691
>
>   ð     0x5a4c | 0x252b
>   ð     15 | 9515
>   ð     15 x 1 Second | 9515 x 2 ^(-16) seconds
>   ð     15 + 0.145187377 seconds
>   ð     15.14518738 seconds
>   ð     15145.18738 ms
>
>   OR
>   ð     0x5a4c | 0x252b
>   ð     15 |  14939691
>   ð     15 x 1 second | 14939691 x 2^(-32) seconds
>   ð     15 + 3.478417872 x 10-3
>   ð     15.00347842 seconds
>   ð     15003.47842 ms
>
>   Timestamp of sending original report, i.e frame 1 = Oct 17, 2006,
> 17:13:46.212354000
>
>   (927377 h x60 x 60) + ( 13 min x 60) + 46 secs
>   = 3338557200 secs + 780 secs + 46 secs = 3338558026 secs = 0xc6fe5a4a
>
>   0.212354000 /(2^(-32)) = 912053485 = 0x365cd4ed
>
>   middle 32 bits of Arrival time = 0x5a4a365c = 1514813020
>
>   ð     0x5a4a |  365c
>   ð     15 | 13916
>   ð     15 x 1 | 13916 x 2^(-16) seconds
>   ð     15 + 0.212341308
>   ð     15.21234131 seconds
>   ð     15212.34131 ms
>
>   OR
>   ð      0x5a4a |  365c
>   ð     15 |  14813020
>   ð     15 x 1 | 14813020 x 2^(-32)
>   ð     15 + 3.448924981 x 10-3
>   ð     15.00344892 secs
>   ð     15003.44892 ms
>
>   DLSR from frame 2 = 125830/65536 = 1.920013428 * 1000 = 1920.013428 ms
>
>   Now the calculation:
>
>   ð     (15145.18738 ms - 15212.34131 ms) – 1920.013428 ms
>   ð     - 67.15393 – 1920.013428
>   ð     -1987.167358 ms
>
>   OR
>   ð     (15003.47842 ms - 15003.44892 ms) - 1920.013428 ms
>   ð     0.0295 – 1920.013428 ms
>   ð     - 1919.983928 ms
>
>
>   I think I have a problem with the conversions especially 2^(-32) or
> 2^(-16).
>   Would be glad if u could comment on my calculation. Thanks for ur help.
>
>
> Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> schrieb:  On 5/22/07,
> Eram Khan 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.
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
>
>
>
> ---------------------------------
> Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr
> Wissen.