You can't do the calculation using just one frame. And bear in mind
that the calculation Ethereal does is relative to the point of capture
(although in many cases you may be capturing on the same machine as the
client).
Look below, the following line is present:
"MSW and LSW as NTP timestamp: Feb 24, 2036 17:42:56,0000 UTC "
This is done by the function ntp_fmt_ts() in packet-ntp.c.
However, this isn't important for calculating the rountrip, as it is
relative. We are comparing:
- the observed difference between the current SR and the one the DLSR
refers to
- the time in the DLSR (which is the number of 1/65536 ths of a second)
Martin
David Grau Serra wrote:
Hi,
The softphone is X-Lite.
And now I show you one capture:
Real-time Transport Control Protocol (Sender Report)
Stream setup by SDP (frame 32)
Setup frame: 32
Setup Method: SDP
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0001 = Reception report count: 1
Packet type: Sender Report (200)
Length: 12
Sender SSRC: 2307084394
Timestamp, MSW: 3351350040
Timestamp, LSW: 2280627634
MSW and LSW as NTP timestamp: Feb 24, 2036 17:42:56,0000 UTC
RTP timestamp: 1509280
Sender's packet count: 5291
Sender's octet count: 846560
Source 1
Identifier: 2307084394
SSRC contents
Fraction lost: 0 / 256
Cumulative number of packets lost: 0
Extended highest sequence number received: 346756267
Sequence number cycles count: 5291
Highest sequence number received: 5291
Interarrival jitter: 0
Last SR timestamp: 2333640687
Delay since last SR timestamp: 1
Real-time Transport Control Protocol (Receiver Report)
Stream setup by SDP (frame 32)
Setup frame: 32
Setup Method: SDP
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 0001 = Reception report count: 1
Packet type: Receiver Report (201)
Length: 7
Sender SSRC: 2307084394
Source 1
Identifier: 428529494
SSRC contents
Fraction lost: 0 / 256
Cumulative number of packets lost: 50
Extended highest sequence number received: 65535
Sequence number cycles count: 0
Highest sequence number received: 65535
Interarrival jitter: 7787
Last SR timestamp: 2333640687
Delay since last SR timestamp: 1
I know how can I calculate jitter and the packet loss rate.
My problem now is how can I calculate delay (round trip delay).
I don't understand why the "Delay since last SR timestamp" is always 1.
I don't know how it works the "MSW" and "LSW" (Timestamp).
These fields and the way the calculation should be done, is described
in RFC 3550, section 6.4.1.
I have read but I am still confuse, I will read again.
Ethereal already does this calculation for you (if the preference is
turned on). There have been fixes made to this calculation, the last
of which I believe was made after the last (0.10.14) release.
I am using 0.10.14, but I use tethreal command line.
DLSR is defined as:
"The delay, expressed in units of 1/65536 seconds, between
receiving the last SR packet from source SSRC_n and sending this
reception report block. If no SR packet has been received yet
from SSRC_n, the DLSR field is set to zero."
If the DLSR is always 1, that indicates that either:
- the RTCP stack isn't filling the value in properly, OR
- it really is replying almost instantly after receiving a report
from the other side. This could be because:
- both clients are sending reports at the same rate and they are
almost exactly in sync
- they are sending reports in response to an incoming SR rather
than on a timer (or some other trigger)
I was thinking as well if it could be the softphone X-Lite....
Note that the Last SR timestamp is formed by taking the middle 32
bits from the MSW and LSW fields. Taken together they are the Most
Significant Word and Least Significant Word or an NTP timestamp.
I would like to know how can I translate the NTP timestamp a human and
readable time?
Many thanks,
David
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
