IETF Logo Mail Archive

Re: [AVTCORE] Leap seconds

Colin Perkins <csp@csperkins.org> Wed, 21 September 2011 17:05 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A7211E80F4 for <avt@ietfa.amsl.com>; Wed, 21 Sep 2011 10:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.535
X-Spam-Level:
X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRlZyoQpp+DV for <avt@ietfa.amsl.com>; Wed, 21 Sep 2011 10:05:45 -0700 (PDT)
Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id EF2EF11E808C for <avt@ietf.org>; Wed, 21 Sep 2011 10:05:44 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R6QHN-0003Gf-mu; Wed, 21 Sep 2011 17:08:13 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-193--984725583"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <0E31FE76-300C-4A54-B15B-C77A7BD57A2C@apple.com>
Date: Wed, 21 Sep 2011 18:08:10 +0100
Message-Id: <959CBFE5-59AC-436D-9100-E229F9C776C7@csperkins.org>
References: <CALw1_Q0qK1WDc_KjEneOWrqr+jfVsqdwFYpF=ht-tS4SSNp8nQ@mail.gmail.com> <71C9EC0544D1F64D8B7D91EDCC6220200A2D0340@NABSREX027324.NAB.ORG> <alpine.BSF.2.00.1109141110001.25117@hsa.packetdesign.com> <CALw1_Q2L5z1bdVaENm7ky-epWjmxD326FLQ7THrObO_KMfdXfw@mail.gmail.com> <78481CCB-7A70-4BC4-91DC-A707301F22A5@apple.com> <CALw1_Q2VFe3d52ufVp2wSeNCHiwqgnhLh39dQTWYa52jWLaV+g@mail.gmail.com> <8EF3B729-407D-4A6F-9B5C-9E6833F2478B@apple.com> <CALw1_Q05fXDmTFapSaH1NRCsp2eWdemNus40gXsFwsx4HbR34Q@mail.gmail.com> <0F41102E-7F7A-4D69-B22D-6BFC3215D6C0@apple.com> <CALw1_Q0UD563WAES2bauEFa2+zr+qtwCs_=sX8hRED1VgPQTfw@mail.gmail.com> <CAJNg7VJqxQ9QFV7dgBbH8PVQVt88kAsX-xgr9XAf4ZO4-_x2kw@mail.gmail.com> <CALw1_Q2jGj_pHowfzgxMSBKXdEU99k=ST217PCBYtznRjBsvfA@mail.gmail.com> <4E78487D.1030602@ericsson.com> <CALw1_Q0urojdegAdsJ7L7bT=0680RN-0pk1g7J4zhP-aK3M5ew@mail.gmail.com> <6A72C4E9-B429-4B97-B4AA-98E420DF4C94@csperkins.org> <0E31FE76-300C-4A54-B15B-C77A7BD57A2C@apple.com>
To: David Singer <singer@apple.com>, Kevin Gross <kevin.gross@avanw.com>
X-Mailer: Apple Mail (2.1084)
Cc: "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [AVTCORE] Leap seconds
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2011 17:05:46 -0000

Dave, Kevin,

It might be worth you getting together to write a draft on this, since you seem to be converging on points that aren't immediately obvious from reading RFC3550.

On 21 Sep 2011, at 17:32, David Singer wrote:
> On Sep 20, 2011, at 15:21 , Colin Perkins 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*.
> 
> Yes, what RTP needs for its operation is correct measurement of interval durations.
> 

> Indeed, I think that for RTP purposes it's important that taking two sender reports -- RTP/'NTP' timestamp pairs -- we can form the difference between the two RTP values, and the two NTP values, and determine, for example, if the source's RTP clock is running slightly fast or slow.  If the NTP interval incorrectly counts seconds, this could be ... confusing.

Yes, agreed. This is probably something that should be documented in a draft, rather than being implied (unclearly) by RFC3550.


On 21 Sep 2011, at 00:17, Kevin Gross wrote:
...
> 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.


I don't know of any such mechanism, but it sounds like it would be useful to define one.

-- 
Colin Perkins
http://csperkins.org/

v2.23.0 | Report a Bug | By Email