Re: [AVT] Clock skew and RTP

[Colin Perkins <csp@csperkins.org>]

--> "Dan Firac" writes:
>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.

True, the measurements have to be filtered to limit the effects of jitter
and find the long term drift.

>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).

RTP doesn't define the skew correction algorithm, so you can certainly use
the information in RTCP SR packets if you think it's useful. The tool I'm
most familiar with uses a much simpler algorithm:
  http://www-mice.cs.ucl.ac.uk/multimedia/publications/ICME2000.ps.gz
which seems to work well for voice tools, where there are talk-spurts to
allow adjustments. A continuous streaming application would likely need
something more sophisticated.

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