Re: [AVTCORE] Leap seconds

[Kevin Gross <[e-mail]>]

If you do want to use the default mode and consider the wallclock in the SRs
be a NTP/UTC time, the presence of a leap seconds in that timebase does
appear to cause problems.

Other timebase discontinuities (initial sync to time server) might be
considered an error and interruption is expected. Leap seconds are scheduled
and ideally should not cause interruption. Senders should not have to lie
about what time it is to keep their receivers happy.

Kevin

On Wed, Sep 14, 2011 at 1:06 PM, Jamie Gordon <[e-mail]> wrote:

> RTP timestamps are not monotonically increasing nor based on UTC,
> they are based on media sampling/rendering time (based on a
> monotonically increasing sampling/playback clock).
>
> Leap second is only relevant if you need to accurately consider the NTP
> time as a UTC date/time, which RTP/RTCP do not need at all - per 3550
> the NTP timestamp in the SR is not required to represent the actual
> wallclock UTC time! It is present to allow conveyance and calculation
> of elapsed times, for purposes such as audio/video sync and RTT
> estimation, and should be based on actual elapsed time rather than calendar
> time.
>
> Receivers do not expect - or certainly should not expect - the RTCP NTP
> clock to change midstream due to leap seconds and senders should not
> change it. Once that clock starts the important thing is to maintain
> proper elapsed time, rather than using a wallclock time which might
> change due to leap second, or even due to the system re-synching to an
> SNTP server, or the user changing the current time.
>
> -Jamie
>
>
> On 9/14/2011 10:22 AM, Kevin Gross wrote:
>
>> I am working on a means of using an IEEE 1588 timebase for RTP
>> streaming. I am aware of IEEE 1733 and will use that if necessary. First
>> I am exploring using existing NTP mapping function in RTCP sender
>> reports. While researching how to translate a 1588 timestamp to its NTP
>> equivalent, I was reminded of the wrinkle leap seconds put into things.
>>
>> The RTCP sender report maps RTP timestamps to NTP timestamps. RTP
>> timestamps are monotonically increasing. The RTP timestamps are based on
>> UTC and have an occasional wobble due to leap seconds. During the leap
>> second, there is an ambiguous mapping between RTP and NTP/UTC. I find no
>> recommendations in RFC 3550 for dealing with this.
>>
>> --
>> Kevin Gross
>> AVA Networks
>> [phone]
>>
>>


-- 
Kevin Gross
AVA Networks
[phone]