Re: [AVTCORE] Leap seconds

[Stephen Casner <[e-mail]>]

Those issues are addressed in RFC 3550:

   Wallclock time (absolute date and time) is represented using the
   timestamp format of the Network Time Protocol (NTP), which is in
   seconds relative to 0h UTC on 1 January 1900 [4].  The full
   resolution NTP timestamp is a 64-bit unsigned fixed-point number with
   the integer part in the first 32 bits and the fractional part in the
   last 32 bits.  In some fields where a more compact representation is
   appropriate, only the middle 32 bits are used; that is, the low 16
   bits of the integer part and the high 16 bits of the fractional part.
   The high 16 bits of the integer part must be determined
   independently.

   An implementation is not required to run the Network Time Protocol in
   order to use RTP.  Other time sources, or none at all, may be used
   (see the description of the NTP timestamp field in Section 6.4.1).
   However, running NTP may be useful for synchronizing streams
   transmitted from separate hosts.

   The NTP timestamp will wrap around to zero some time in the year
   2036, but for RTP purposes, only differences between pairs of NTP
   timestamps are used.  So long as the pairs of timestamps can be
   assumed to be within 68 years of each other, using modular arithmetic
   for subtractions and comparisons makes the wraparound irrelevant.

The timestamp is not required to be synchronized with UTC at all.  For
some applications it would be convenient to use UTC in order to
synchronize the RTP stream with some other kinds of events, but RTP
does not require it.

                                                        -- Steve

On Wed, 14 Sep 2011, Allison, Art wrote:

> As I understand it the UTC clock will monotonically increase after
> January 2017 (no more leap seconds). What happens at 03:14:07 UTC
> <http://en.wikipedia.org/wiki/Coordinated_Universal_Time>  on Tuesday,
> 19 January 2038 (32 bit count overflow) will need to be addressed by
> someone, - your guess if any equipment being built today will be in
> service then.
>
> See
> http://www.agi.com/downloads/resources/white-papers/Debate-Over-UTC-and-
> Leap-Seconds.pdf  for more information.
>
>
>
>
>
> Art Allison
> Senior Director Advanced Engineering, Science and Technology
> National Association of Broadcasters
> 1771 N Street NW
> Washington, DC 20036
> Phone  [phone]
> Fax  [phone]
> www.nab.org <blocked::http://www.nab.org>
> Advocacy  Education  Innovation
>
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Kevin Gross
> Sent: Wednesday, September 14, 2011 1:22 PM
> To: [e-mail]
> Subject: [AVTCORE] Leap seconds
>
>
>
> 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]
>
>
>
>