Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-hdrext-01.txt

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Aug 2006 10:15:19 +0100

On 28 Jul 2006, at 21:39, Ron Frederick wrote:
...
> I suppose all of this is already determined, though, if you go with  
> the model that the streaming server is already computing some  
> mapping between its RTP timestamps and NTP time in RTCP. The offset  
> it reports would be the difference between that NTP time and the  
> NTP time of when it actually sent the packet, converted back to RTP  
> timestamp units. So, the question of what the "apparent capture  
> time" is was already determined when the streaming server picked  
> what NTP timestamp to use in RTCP. Has there been any guidance in  
> any of the specs for how a streaming server should choose this  
> value when sending stored content?

Does it matter? I always viewed the actual value of the NTP timestamp  
to be irrelevant, provided a common clock was used across all streams  
needing to be synchronised.

Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Ron Frederick <[email-masked]>
Date: Wed, 02 Aug 2006 10:25:23 -0700

Colin Perkins wrote:
>> the model that the streaming server is already computing some mapping 
>> between its RTP timestamps and NTP time in RTCP. The offset it reports 
>> would be the difference between that NTP time and the NTP time of when 
>> it actually sent the packet, converted back to RTP timestamp units. 
>> So, the question of what the "apparent capture time" is was already 
>> determined when the streaming server picked what NTP timestamp to use 
>> in RTCP. Has there been any guidance in any of the specs for how a 
>> streaming server should choose this value when sending stored content?
> 
> Does it matter? I always viewed the actual value of the NTP timestamp to 
> be irrelevant, provided a common clock was used across all streams 

The specific value may not matter, but the manner in which one knows 
what value to put in the packets matters, so that all the streams really 
do continue to share that common clock over time. One generally wants 
this to be based on something other than the sample clock of any 
individual media, as the individual streams tend to run at slightly 
different rates than they are configured to and they will lose sync over 
time if you just report NTP times based on the ideal sampling rate. As 
long as there is some mapping between this common clock and the local 
system clock, it should be possible to report actual transmission times 
using these NTP timestamps, or to convert such an NTP timestamp back to 
the corresponding RTP timestamp and encode it as an offset from the RTP 
timestamp already in the packet.
-- 
Ron Frederick
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Aug 2006 18:51:38 +0100

On 2 Aug 2006, at 18:25, Ron Frederick wrote:
>>> I suppose all of this is already determined, though, if you go  
>>> with the model that the streaming server is already computing  
>>> some mapping between its RTP timestamps and NTP time in RTCP. The  
>>> offset it reports would be the difference between that NTP time  
>>> and the NTP time of when it actually sent the packet, converted  
>>> back to RTP timestamp units. So, the question of what the  
>>> "apparent capture time" is was already determined when the  
>>> streaming server picked what NTP timestamp to use in RTCP. Has  
>>> there been any guidance in any of the specs for how a streaming  
>>> server should choose this value when sending stored content?
>> Does it matter? I always viewed the actual value of the NTP  
>> timestamp to be irrelevant, provided a common clock was used  
>> across all streams needing to be synchronised.
>
> The specific value may not matter, but the manner in which one  
> knows what value to put in the packets matters, so that all the  
> streams really do continue to share that common clock over time.  
> One generally wants this to be based on something other than the  
> sample clock of any individual media, as the individual streams  
> tend to run at slightly different rates than they are configured to  
> and they will lose sync over time if you just report NTP times  
> based on the ideal sampling rate.

Yes, of course.

> As long as there is some mapping between this common clock and the  
> local system clock, it should be possible to report actual  
> transmission times using these NTP timestamps, or to convert such  
> an NTP timestamp back to the corresponding RTP timestamp and encode  
> it as an offset from the RTP timestamp already in the packet.

Doesn't RFC 3550 state to use the local system clock for this  
purpose? That's how I always interpreted the talk of "wallclock time"  
in sections 4 and 6.4.1 of RFC 3550.

Colin

---

From: Ron Frederick <[email-masked]>
Date: Wed, 02 Aug 2006 11:18:25 -0700

Colin Perkins wrote:
>> transmission times using these NTP timestamps, or to convert such an 
>> NTP timestamp back to the corresponding RTP timestamp and encode it as 
>> an offset from the RTP timestamp already in the packet.
> 
> Doesn't RFC 3550 state to use the local system clock for this purpose? 
> That's how I always interpreted the talk of "wallclock time" in sections 
> 4 and 6.4.1 of RFC 3550.

The spec does use the term "wallclock time" frequently, but it doesn't 
really require it to be the local system clock. In fact, it mentions 
that it might be a "relative" NTP timestamp such as a "system uptime" 
value on systems that have no notion of wallclock time, or even possibly 
just be the constant value 0 on systems that have no notion of wallclock 
or elapsed time.

For systems which only have a notion of elapsed time, it should still be 
possible for the offset to make sense. It won't be as useful for 
computing one-way delay between a sender and receiver, which would be 
possible if the two systems had clocks which were synchronized with one 
another, but it would still be possible to meaningfully compare the 
relative transmit times of packets on two different RTP streams from the 
same sender.

For systems that cannot measure any form of time, offset calculations 
won't really be possible, so we don't have to worry about that case. 
Such systems would simply not implement this extension.
-- 
Ron Frederick
[email-masked]