Hi Martin,
I have read rfc 3550 with particular emphasis on the part detailing
how the round trip time (RTT) should be calculated. The formula
"A-DLSR-LSR" is provided and an example "46864.500 - 5.250 -
46853.125 = 6.125 seconds" is given. We are working from a tethereal
capture file - This was running on the same pc as one of the
softphones involved in the call but as the two softphones calling
each other are on the same LAN segment we should have captured all
the necessary RTCP sender and receiver reports anyway.I have attached
the sample capture file.
[Martin] Note that within the same LAN segment you are unlikely to
see any
interesting roundtrip delays. You can set the RTCP preference
'Minimum rountrip calculations to report'
to 0 milliseconds.
Myself and David are not clear on a few things:
1) The A field is when the receiver report block is received. Is this
referring to the NTP timestamp? I am struggling to identify this from
the tethereal capture (perhaps the capture format is slightly
non-standard?)and if you could point this out from the attached
capture file we would greatly appreciate it.
[Martin] 'A' seems to be the middle 32 bits from the NTP timestamp,
whose units would be 1/65536th seconds. All 3 quantities in the
formula you quote are in these units, though they are converted into
seconds to make it easier to read.
2)The LSR field is said to be the middle 32 bits of the NTP timestamp
and the NTP timestamp is made up of the MSW and LSW. So if the
figures are MSW=3350115113 and LSW=493921239 I still fail to
understand why the LSR=3005816176...this is based on the figures from
the attach capture file.
[Martin] MSW and LSW are being displayed as decimals, it is easier to
look at them as hex.
MSW = 0xC7AEB329, LSW = 0x0x1D70A3D7
The middle word in this case from this would be 0xB3291D70 = 3005816176
It's clear, thanks.
However, remember that the LSR in a frame refers to the timestamp seen
in a message seen in the opposite direction
(i.e. in a received message it refers to the middle-bytes from the
time of a frame you previously sent).
3)the DLSR does appear to be 1 for all captures but as you said this
could be for the reasons that you described before.
[Martin] As in the other example I looked at, there appears to be only
RTP/RTCP in one direction, so these values looke made up / default to me.
You maybe need to make sure that someone is speaking in both
directions to that RTP and SRs are sent. No calculation can be done
until a SR in one direction
refers to an SR in the previous direction (by matching its LSR and
having a sensible DLSR filled in).
I have catched RTCP packets in both directions, and one of them, but in
SR, the Delay since last SR timestamp is 276541, the DLSR in RRs are 1.
4)Based on the above points and the attached capture file could you
give an example with figures (from the file) of using A-DLSR-LSR?
[Martin] Sorry, I don't have ready access to my old capture
collection at the moment. I realise that the way this calculation is
done is a bit complex.
I notice that RFC 3611 allows non-senders to calculate roundtrip
delays, but I've never seen it used in a real client.
I really do hope this helps you.
Thanks Martin,
David