Subject: Re: rtp time stamp in RTCP packet....

From: Bill Fenner <[email-masked]>
Date: Tue, 18 Jan 2000 12:16:45 -0800

>However, to avoid introducing errors in synchronization, you should do
>as others have said here and make sure the reported NTP time corresponds
>to an integral value of the RTP sample clock, picked to be as close as
>possible to the actual send time.

Interestingly enough, the spec seems to disallow this -- the RTP timestamp
"...MUST be calculated from the corresponding NTP timestamp...".

If inter-media syncrhonization requires more resolution than RTT
measurement (which seems likely in most applications), it makes sense
to fudge the NTP time to exactly correspond to the RTP timestamp.
Should the spec discuss this tradeoff?

  Bill

---

From: Ron Frederick <[email-masked]>
Date: Tue, 18 Jan 2000 12:27:11 PST

> Should the spec discuss this tradeoff?
Yes, I think this would be a good clarification to make...
--
Ron Frederick
[email-masked]

---

From: "M. Reha Civanlar" <[email-masked]>
Date: Tue, 18 Jan 2000 15:31:46 -0500

Or, you can wait until a suitable NTP time to send it.

-Reha

---

From: Stephen Casner <[email-masked]>
Date: Tue, 18 Jan 2000 21:49:05 -0800 (Pacific Standard Time)

> Should the spec discuss this tradeoff?

I claim not.  First, I think the RTT measurement and the media sync
require resolution of about the same magnitude.  Furthermore, if the
truncation involved in calculating an RTP timestamp from an NTP
timestamp introduces too large an error for media sync, that is a bug
in the design of the payload format.  The RTP spec says: "The
resolution of the [RTP timestamp] clock must be sufficient for the
desired synchronization accuracy and for measuring packet arrival
jitter (one tick per video frame is typically not sufficient)."

On Tue, 18 Jan 2000, rakesh jain wrote:

>         In case of each RTCP packet, we can calculate rtp time stamp
>         value, using time difference between the sending time of the last
>         RTCP packet and the sending time of the current RTCP packet, but
>         after conversion from time units to sample period units, the value
>         may not be perfect integer, can be float also, and we can send
>         perfect integer value for rtp time stamp, so we need to do
>         truncation.

The RTP spec says that you should calculate the RTP timestamp from the
RTCP timestamp so that the correspond to the same time.  That
calculation can be done in floating point (double precision) or with
multiple-precision integer arithmetic.  In both cases, there will be a
truncation to get the integer RTP timestamp.

However, if you do this by accumulating differences between SR sending
times as you are likely to have truncation errors that accumulate.
Further, you won't account for drift between the sampling clock and
the clock used for the NTP timestamps if these come from different
oscillators (for example, a crystal on the audio board and a crystal
on the motherboard from which the operating system clock is derived).

The method I recommend is to periodically, at the time a sample buffer
completes, establish a correspondence between the RTP timestamp that
will correspond to the first sample in that buffer and the time that
sample was taken according to the clock used for the NTP timestamps.
That time is usually the current time minus the duration of the buffer
and some allowance for interrupt or operating system latency.  That
correspondence is an offset in RTP timestamp units:

   offset = int(current_NTP_time * RTP_timestamp_clock_rate) - RTP_timestamp

where current_NTP_time is in seconds and fraction.  You don't need to
do this calculation on every sample buffer, just often enough to
accommodate the drift between the two oscillators.  If they come from
the same oscillator, you only need to do this once.  Ideally, the
capture interrupt routine would return a timestamp for the capture
time from which you could form the NTP timestamp.

Then, when it is time to send an RTCP SR packet, you get the current
NTP time and calculate the RTP timestamp for the SR as:

   RTP_timestamp = int(current_NTP_time * RTP_timestamp_clock_rate) - offset

Presto!

I hope to produce an Internet-Draft on this topic (including
synchronization).
							-- Steve