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

[Aidan Williams <[e-mail]>]

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" <[e-mail]>
> To: [e-mail], [e-mail]
> 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