RE: [AVT] Clock skew and RTP

I did find this on citeseer:

http://citeseer.nj.nec.com/moon99estimation.html

-----Original Message-----
From: Dan Firac [mailto:danutf@redlinecommunications.ro]
Sent: Monday, October 21, 2002 3:57 AM
To: Colin Perkins
Cc: avt@ietf.org
Subject: Re: [AVT] Clock skew and RTP 

Hi Colin,

See comments below.

----- Original Message -----
From: "Colin Perkins" <csp@isi.edu>
To: "Dominique Fober" <fober@grame.fr>
Cc: <avt@ietf.org>
Sent: Friday, October 18, 2002 6:15 PM
Subject: Re: [AVT] Clock skew and RTP

> --> Dominique Fober writes:
> >Thanks a lot for your replies. It answers my question: resuming the
> >thread, it appears that RTP provides a mean to detect the clock skew to
> >NTP synchronized hosts via the SR RTCP packets, but don't include (itself
> >or using a dedicated payload) an explicit solution.
>
> The mapping in RTCP SR packets is used for lip-synchronization, but is not
> needed to estimate clock skew between sender and receiver. The receiver
can
> estimate skew by looking at the relative offset between the RTP timestamps
> in packets it receives, and its local media clock.
The problem with your solution is that the receiver measurements (your so
called 'relative offset') contains the network jitter which can disturb any
skew estimation algorithm.
There is some work about skew estimation algorithms, but what is their
performance? and most of all, what is the cost?
I've studied this problem a lot and I found that the most accurate measure
(without network jitter) can be done only by the source which fills the SR
RTCP packet with the two informations(local media clock + local system
clock). In practice, the NTP skew is much less than the media skew, and that
makes this solution more simpler and more accurate than one with skew
estimation.
Anyway, the RTP rfc doesn't say that RTCP SR to be used ONLY for
lip -synchronization (inter-media sinchronization).
This is the RTP timestamp definition:

    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 MUST be 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.

>
> Colin
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

Best regards,
Dan.

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt