Re: [AVTCORE] Leap seconds

[Jamie Gordon <[e-mail]>]

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]
>