Hi,
I've written this patch to use the 'Delay since last SR' (DLSR) field found
in SR reports to calculate and report roundtrip-propagation delays. This is
described in rfc 3550, section 6.4.1, inside the description of DLSR.
Only the endpoint can compute the end-end roundtrip delay, and only they
know exactly when the report is received and can compare it with the 'Last
SR timestamp' (LSR) that they set. This patch instead takes the difference
between the capture times of the 2 reports and subtracts the DLSR (the LSR
is checked in case the SR it's referring to wasn't captured). The time
difference represents a roundtrip network delay between the point of capture
and the sender of the SR containing the DLSR.
I don't necessarily want this patch to be applied (at least for now) - I'd
be very interested to hear from other VoIP people first:
- have you ever calculated this value by hand, if so was it realistic /
useful
- do RTP stacks tend to fill these RTCP SR fields properly/accurately?
- is there some other (unintrusive) method thought to be better for
estimating network delay?
Note that this patch is quite large, in part because a fair bit of code was
inside an 'if (tree)' test. The calculated information is shown in the INFO
column as well as in the protocol tree, so this test was removed and the
code unindented.
Regards,
Martin
Attachment:
packet-rtcp.c.diff
Description: Binary data
Attachment:
packet-rtcp.h.diff
Description: Binary data
