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
