Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-06.txt

Aidan Williams <aidan.williams@audinate.com> Thu, 12 September 2013 07:06 UTC

Return-Path: <aidan.williams@audinate.com>
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 CF30B11E824C for <avt@ietfa.amsl.com>; Thu, 12 Sep 2013 00:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.042
X-Spam-Level:
X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, SARE_SUB_6CONS_WORD=0.356]
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 fdY93rV7Ec8l for <avt@ietfa.amsl.com>; Thu, 12 Sep 2013 00:06:43 -0700 (PDT)
Received: from zimbra8.audinate.com (sydney.audinate.com [150.101.200.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED5211E8175 for <avt@ietf.org>; Thu, 12 Sep 2013 00:06:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zimbra8.audinate.com (Postfix) with ESMTP id 20175314A75; Thu, 12 Sep 2013 17:06:40 +1000 (EST)
Received: from zimbra8.audinate.com ([127.0.0.1]) by localhost (zimbra8.audinate.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZSOvYqPkn9Qq; Thu, 12 Sep 2013 17:06:39 +1000 (EST)
Received: from localhost (localhost [127.0.0.1]) by zimbra8.audinate.com (Postfix) with ESMTP id 1B703314A69; Thu, 12 Sep 2013 17:06:39 +1000 (EST)
X-Virus-Scanned: amavisd-new at audinate.com
Received: from zimbra8.audinate.com ([127.0.0.1]) by localhost (zimbra8.audinate.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S5o3ciixPr_4; Thu, 12 Sep 2013 17:06:38 +1000 (EST)
Received: from zimbra8.audinate.com (zimbra8.audinate.com [10.12.0.4]) by zimbra8.audinate.com (Postfix) with ESMTP id E577C314A5D; Thu, 12 Sep 2013 17:06:38 +1000 (EST)
Date: Thu, 12 Sep 2013 17:06:38 +1000 (EST)
From: Aidan Williams <aidan.williams@audinate.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <18036806.1238.1378969595799.JavaMail.aidan@praxis.audinate.com>
In-Reply-To: <52301853.4070306@ericsson.com>
References: <20130911001349.28088.35324.idtracker@ietfa.amsl.com> <52301853.4070306@ericsson.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1237_2225124.1378969595798"
X-Mailer: Zimbra 8.0.4_GA_5737 (Zimbra Desktop/7.2.2_11951_Mac)
Thread-Topic: I-D Action: draft-ietf-avtcore-clksrc-06.txt
Thread-Index: eBD7KT8Us64qV4Wiky2WIuQdYcFv7w==
Cc: avt@ietf.org, draft-ietf-avtcore-clksrc@tools.ietf.org
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-06.txt
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: Thu, 12 Sep 2013 07:06:48 -0000

Hi Magnus, 

Thanks for your comments - they were very helpful. I was going to respond to your previous email point by point, but you've beaten me to it. 

----- Original Message -----

> From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
> To: avt@ietf.org, draft-ietf-avtcore-clksrc@tools.ietf.org
> Sent: Wednesday, 11 September, 2013 5:14:27 PM
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-06.txt

> Hi,

> Great to see a new version. I have checked this version against my
> previous comments and believe that it cares of all except the below
> two
> issues.

> Section 5.2:

> The signalling optionally indicates a media clock offset value. The
> offset indicates the RTP timestamp value at the epoch (time of
> origin) of the reference clock. If no offset is signalled, the
> offset can be inferred at the receiver by examining RTCP sender
> reports which contain NTP and RTP timestamps which combined define a
> mapping.

> > First, I am not certain that I understand the offset. So the
> > indicated
> > value is an RTP timestamp, i.e. the integer representation of the
> > 32-bit
> > value of the RTP timestamp. So the epoch time is dependent on the
> > clock
> > system, but the current epoch for an NTP reference clock would be 1
> > jan
> > at 0:00 year 1900. Thus you need to take all the leap seconds etc
> > into
> > account to determine how many time has actually passed since then
> > and
> > then calculate how many wrapping of the timestamp this means. This
> > seems
> > error prone, at least without being more explicit of how to do it
> > for
> > the various reference clocks.

> I still think I need an author response on this to determine if there
> is
> an issue here.

Kevin and I discussed this off list - we decided not to describe how to count all the leap seconds but to recommend the use of a non-leapsecond bearing clock (e.g. TAI): 

Implementations SHOULD use a TAI timestamp reference clock 
to avoid complications due to leap seconds. The NTP/RTP timestamp 
mapping provided by RTCP SRs takes precedence over that provided by 
the SDP, however the media clock rate implied by the SRs MUST be 
consistent with the rate announced in the SDP. 

Are you OK with this as a resolution? 

> > 5. Section 5.2 and Figure 7:
> >
> > A rate modifier may be specified. The modifier is expressed as the
> > ratio of two integers and modifies the rate specified or implied by
> > the media description by this ratio. If omitted, the rate is
> > assumed
> > to be the exact rate specified or implied by the media format. For
> > example, without a rate specification, the media clock for an 8 kHz
> > G.711 audio stream will advance exactly 8000 units for each second
> > advance in the reference clock from which it is derived.
> >
> > and looking at this example in Figure 7:
> >
> > m=audio 5004 RTP/AVP 96
> > a=rtpmap:96 L24/44100/2
> > a=sendonly
> > a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
> > a=mediaclk:direct=963214424 rate=1000/1001
> >
> > I realize that I don't understand what the rate modifier means.
> > Without
> > the rate modifier there would be 44100 RTP timestamp ticks per
> > second of
> > reference clock. Does the rate modifier multiply with the nominal
> > rate
> > so that this example means 441000*1000/1001 RTP TS ticks per second
> > of
> > reference clock?
> >
> > Some clarification may be required here.

> Also this I would like to receive some answer to.

The rate modifier means exactly what you think it does. 
So it would appear that the text is sufficiently clear .. ;-) 

Do you still feel more clarification is needed? 

- aidan