Re: [AVTCORE] Leap seconds

On Sep 14, 2011, at 11:49 , Kevin Gross wrote:

> To be clear, "Those issues" refers to the year 2038 problem.
> 
> By my reading, my original concern about leap seconds is not addressed in this excerpt or anywhere else in the RFC. I'm hoping to see some additional discussion about that.

NTP timestamp are, as I recall, simply counts of seconds and fractions of seconds since a well-defined origin.  How you choose to interpret and display that count is entirely up to you; I don't think RTP really cares which year something happened in, for example.  You could use any calendar system you like..

> 
> I do recognize that the unsynchronized clock option allows me to replace NTP time with 1588 time. Apparently I should set the MS bit in the timestamps if I do this (and possibly expect problems after 2038).
> 
> Kevin
> 
> On Wed, Sep 14, 2011 at 12:11 PM, Stephen Casner <casner@acm.org> wrote:
> 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  202 429 5418
> > Fax  202 775 4981
> > www.nab.org <blocked::http://www.nab.org>
> > Advocacy  Education  Innovation
> >
> > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> > Kevin Gross
> > Sent: Wednesday, September 14, 2011 1:22 PM
> > To: avt@ietf.org
> > 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
> >
> > +1-303-447-0517
> >
> >
> >
> >
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

David Singer
Multimedia and Software Standards, Apple Inc.