ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: Eram Khan <eramk2003@xxxxxxxx>
Date: Tue, 22 May 2007 15:56:39 +0200 (CEST)
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.