Wireshark-users: Re: [Wireshark-users] RTCP: Calculate round trip delay (Bishwarup)
From: "Martin Mathieson" <martin.r.mathieson@xxxxxxxxxxxxxx>
Date: Tue, 6 Mar 2007 13:47:43 +0000
I have an RTCP packet (Sender report) with the following specifications.

*Frame 3494 (114 bytes on wire, 114 bytes captured)
    Arrival Time: Jan  9, 2007 11:37:42.890920000
    Time delta from previous packet: 0.004804000 seconds
    Time since reference or first frame: 47.108231000 seconds

Last SR timestamp: 556982720 (0x2132e1c0)
Delay since last SR timestamp: 308288

I just checked in a change 20982 that shows how many milliseconds the
DLSR corresponds to (by dividing by 65535).

As someone else suggested, you really need to read and understand the
RFC...  Wireshark can do this calculation for you, but you should
understand how the delay is worked out.

Best regards,
Martin

*All I know is that 890920000 would give me the number of milliseconds
elapsed since the first packet.

Now to calculate the round trip delay, I won't do this..

Wrong ->   RTD = 890920000 - 556982720 - 308288

I want to know that what I need to do with the three numbers above to
calculate the round trip delay?



Anders Broman (AL/EAB) wrote:
> Hi,
> When you look at the RTP timestamps do the come up as correct NTP
timestamps?
> It's not uncommon for clients to fill in the timestamp incorrectly.
> Best regards
> Anders

Gerry Brown wrote:
>
> Make sure to read the RFC 3550.  The values are not always strictly
> binary. For instance, NTP is sec/millisecs.  The value of DLSR is
> represented as 1/65536 of a sec ticks.
>
> gerry
>
>
>
>
>
>
>
> - This message has been scanned for viruses, spam and dangerous
> content by *www.CleanMailGateway.com*
> <http://www.CleanMailGateway.com/>, and is believed to be clean.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users