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

From: rakesh jain <[email-masked]>
Date: Tue, 18 Jan 2000 17:02:48 +0530 (IST)

Hi,

	I have one doubt about rtp time stamp value in RTCP SR packet.
        The units of the rtp time stamp field should be same in RTP and
        RTCP packets. In case of RTP packet, rtp time stamp depends on 
	codec, It can start from random value, on first rtp packet, and
        incremented by number of samples in next rtp packets. I think
        it is cumulative.
        So in case of RTCP packet, we need to pass rtp time stamp value
        in sample period units. ( cumulative number of samples )
        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.
        My question is, will this truncation effect seriously at receiver
        end in some calculations. If I am wrong or not clear please let
        me know.
        thanks in advance,

  rakesh jain

---

From: "CCFang" <[email-masked]>
Date: Tue, 18 Jan 2000 21:09:28 +0800

Hi all...

    I think that the time stamp in RTCP packet should not be float.
    For example, in G.723, we send one RTP packet every 30 ms.
    The RTP time stamp will increase 240 every packet.
    It means that "we should increase 8 every ms".
    So, using the time difference between RTCP packets,or the time between
RTP and RTCP,
    there is no xxx.xxx ms.

    I am new in this group, and my English is poor.  *^_^*

    regards

    CCFang

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jan 2000 10:03:05 -0500

The RTP timestamp in sender report is used for correlating the real
"wallclock" time with the RTP clock. It has nothing to do with the
difference in transmission times of SR packets, nor with the sending
time of the current RTCP packet. RFC1889 has the following to say about
its construction:

RTP timestamp: 32 bits
        Corresponds to the same time as the NTP timestamp (above), but
        in the same units and with the same random offset as the RTP
        timestamps in data packets. This correspondence may be used for
        intra- and inter-media synchronization for sources whose NTP
        timestamps are synchronized, and may be used by media-
        independent receivers to estimate the nominal RTP clock
        frequency. Note that in most cases this timestamp will not be
        equal to the RTP timestamp in any adjacent data packet. Rather,
        it is calculated from the corresponding NTP timestamp using the
        relationship between the RTP timestamp counter and real time as
        maintained by periodically checking the wallclock time at a
        sampling instant.

Thus, what you do is at some discrete sample time before the
transmission of the RTCP SR (which therefore has an integral RTP
timstamp value), you observe wallclock time. It is these two numbers
that get placed in the RTP timestamp and NTP timestamp fields in the
next SR. Note that this means the timestamp in the SR does *not*
correspond to the RTP time when the SR is sent.  

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Bill Fenner <[email-masked]>
Date: Tue, 18 Jan 2000 08:26:53 -0800

>Note that this means the timestamp in the SR does *not*

I must be confused.  The NTP timestamp is the time when the SR is sent:

   NTP timestamp: 64 bits
        Indicates the wallclock time ... when this report was sent ...

and the RTP timestamp corresponds to the NTP timestamp:

   RTP timestamp: 32 bits
        Corresponds to the same time as the NTP timestamp (above) ...

so how can the timestamp in the SR not correspond to the time when
the SR is sent?

  Bill

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jan 2000 11:57:06 -0500

> so how can the timestamp in the SR not correspond to the time when

The NTP timestamp doesn't need to be the exact time when its sent, it
needs to be
the time of the most recent RTP sample instant before it was sent. The
timestamp in the SR
is used for correlation purposes. It doesn't even need to be near the
time of sending of the SR, in fact. 

-Jonathan R.

---

From: Bill Fenner <[email-masked]>
Date: Tue, 18 Jan 2000 09:24:19 -0800

Not only am I confused, I'm also stubborn.

>[The NTP timestamp] doesn't even need to be near the

If this were the intent of the spec, I'd expect to see an additional
correction factor in the section about calculating the RTT (the
current algorithm assumes that the LSR echoed in the receiver's
report is the transmission time of the SR.).  Since LSR is expected
to be the transmission time of the SR, and the description of the
NTP timestamp field describes it as the transmission time of the SR,
I can only conclude that the NTP timestamp field is meant to be the
transmission time of the SR.

  Bill

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jan 2000 13:54:30 -0500

> transmission time of the SR.

I forgot about that; you're right, then, that it needs to be pretty much
the send time. However, you'll still need to use the sample time of the
last sample obtained before sending the packet, in order to get an
integral number for the RTP timestamp.

-Jonathan R.

---

From: Bill Fenner <[email-masked]>
Date: Tue, 18 Jan 2000 11:14:05 -0800

>However, you'll still need to use the sample time of the

That's a little restrictive.  Take a video codec with timestamps in units
of 90kHz.  If you're doing 60fps video, there are 1499 integral timestamp
values in between each frame that could also be used as the RTP timestamp.

  Bill

---

From: "M. Reha Civanlar" <[email-masked]>
Date: Tue, 18 Jan 2000 14:39:01 -0500

And, I believe, among these 1499 values, the one that corresponds to the RTCP
report send time as close as possible (not the sample time of the last sample)
MUST be used as the RTP timestamp in that report...

-Reha

----- Original Message -----
From: Bill Fenner <[email-masked]>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jan 2000 14:54:43 -0500

Right again, Bill. I was thinking audio, where each sample = 1 tick. My
(now minor) point is that you still need to pick an integer for this
timestamp, so it may not be the actual send time, but rather the closest
thing.

-Jonathan R.

---

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

> values in between each frame that could also be used as the RTP timestamp.
Actually, one of the reasons we chose the 90kHz clock for video was precisely
so that you did have enough resolution to pick a sample time which is close
enough to the actual report time to be reasonable. 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.
--
Ron Frederick
[email-masked]