Re: [AVTCORE] Leap seconds

[Qin Wu <[e-mail]>]

Hi, Kevin:
Regarding how to know where the leap seconds are, I think, you may follow two potential ways:
1. you may take take David's suggestion, compare the NTP/RTP pairs in the two consecutive SRs to know if exception happen. 
2. you may look at IDMS draft, the parameter clock source is  defined in SDP to signal the source for clock
   synchronization. Using this parameter, the receiver may know where the leap seconds are.
Does this make sense?

Regards!
-Qin

  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Sent: Wednesday, September 21, 2011 9:33 PM
  Subject: Re: [AVTCORE] Leap seconds


  IEEE 1588 definitely uses TAI time. You cannot convert between TAI/GPS/1588 and UTC/NTP unless you know where all the leap seconds are. If you know where the leap seconds are, you can fix it as you have suggested or in other ways.


  Abolishing leap seconds was discussed earlier in this thread. That is still being studied at the ITU. It is controversial.


  The RFC 3550 gives no hint of the leap-second issue so implementers are unlikely to make proper accommodation for leap seconds. The issue affects applications that use the RTCP SR NTP timestamp to determine playout time. The stream will get glitched at midnight every couple years. Duration of the glitch is from momentary to minutes depending on implementation. Perhaps no big deal for some but not acceptable behavior for the applications I work on.


  Kevin Gross


  On Tue, Sep 20, 2011 at 8:41 PM, Qin Wu <[e-mail]> wrote:

    I am not sure Precision Time protocol defined in IEEE1588 is subject to leap seconds, but I am aware GPS and TAI are two timescales that don't follow leap seconds.
    So one solution to overcome  leap seconds is to use GPS as clocksource and convert GPS time to NTP timestamp. Otherwise manually updated and maintained leap seconds table
    will be used to correct UTC time and NTP time when leap seconds occurs.

    Also I am aware that there is long debate in ITU-T Studay Group 7 regarding abolishing leap seconds. It was said that in 2017, the leap seconds will not be used. UTC will be continuous 
    timescale. so shall we really need to be worried about this issue?

    Regards!
    -Qin

      ----- Original Message ----- 
      From: Kevin Gross 
      To: Colin Perkins 
      Cc: Magnus Westerlund ; [e-mail] ; Marshall Eubanks 
      Sent: Wednesday, September 21, 2011 7:17 AM
      Subject: Re: [AVTCORE] Leap seconds


      Well, that would fix things. By my reading, RFC 3550 is not clear on this however. I'm not sure trying to figure out the original intent of the RFC will help us resolve things because nowhere in the text do I see any indications that the RFC authors gave consideration to the NTP leap second issue.


      The RFC does say "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." (emphasis on timestamp format mine) Since it doesn't say anything about leap seconds, you could interpret it as Dave Singer and Colin Perkins have to mean actual seconds elapsed.


      But a couple sentences later there's, "Running NTP may be useful for synchronizing streams transmitted from separate hosts." Again, no mention of leap-seconds but here, since we're talking about actual NTP (as opposed to "NTP timestamp format"), wouldn't you be inclined to assume that leap seconds are included in timestamps in this suggested implementation?


      I have already determined that TAI time is best for my application. If anyone knows of any existing signaling mechanism I can use to communicate this to receivers (e.g. specific SDP a= records), I would welcome suggestions.


      Kevin Gross

      On Tue, Sep 20, 2011 at 4:21 PM, Colin Perkins <[e-mail]> wrote:

        I guess I'm confused. RTP was intended to use NTP *format* timestamps, but intentionally said nothing about synchronisation to any particular time source. I don't think it's valid to assume that the NTP format timestamps conveyed in RTP are synchronised to UTC, TAI, or anything else, *unless you have some explicit signalling to state that*. 


        Colin





--------------------------------------------------------------------------


      _______________________________________________
      Audio/Video Transport Core Maintenance
      [e-mail]
      https://www.ietf.org/mailman/listinfo/avt







  -- 
  Kevin Gross

  [phone]
  Media Network Consultant

  AVA Networks - www.AVAnw.com, www.X192.org