Re: [AVTCORE] Leap seconds

[Kevin Gross <[e-mail]>]

I'm getting the clear impression from this discussion and from the RFC that
the NTP timestamp is not sacred. I'm free to us that for any timebase I wish
and I may well do so.

With all these different timebases in play, how do receivers know which
senders is running off which timebase?

For example, if a receiver receives 48 kHz audio from two different senders,
how does the receiver know that those two sources can be directly mixed
without requiring sample-rate conversion to first synchronize them? Is this
an SDP thing?

Kevin

On Wed, Sep 14, 2011 at 1:00 PM, Stephen Casner <[e-mail]> wrote:

> No, I meant that the leap-second issue was addressed by not syncing to
> UTC and therefore not including leap seconds.  You need not set the MS
> bit to use 1588 time.
>
> The key point is that RTP uses NTP format timestamps, not necessarily
> NTP.
>
>                                                        -- Steve
>
> On Wed, 14 Sep 2011, 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.
> >
> > 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 <[e-mail]> 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  [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]
> > > >
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > Audio/Video Transport Core Maintenance
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/avt
> > >
> >
>



-- 
Kevin Gross
AVA Networks
[phone]