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

[Magnus Westerlund <[e-mail]>]

On 2013-09-12 09:06, Aidan Williams wrote:
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
>     *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?

I personally think this is a little to dense to be easily understood. I
think it assumes a fairly good understanding of clocks and different
representations and potential issues to do correctly. I would definitely
like the text to be more explicit about several things.

First what the basic calculation that needs to be done is. Secondly, the
to be clear about the pitfalls with leap seconds, especially to put the
TAI recommendation into perspective.

The full paragraph currently says:

   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.  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.

I would suggest this to be changed to something more like this:


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. So for example if the reference clock used is
NTP that is UTC based, then the epoch was the 0:00:00 on the 1st of
January 1900. As the offset is the value the RTP timestamp would have
had at the time of the epoch, one needs to determine the amount of time
since the epoch. In formats that includes leap seconds, like NTP this
isn't simply to take the reference clock value multiplied by the
timestamp rate and subtract that from the RTP Timestamp media clock
value for the correspondingly used reference clock value modulus 2^32.
For example for UTC compared to the leap second less TAI format there is
a 35 second time difference at the time of writing. To get this
correctly for systems with leap seconds, the leap seconds must be
tracked. Implementations SHOULD use a TAI timestamp reference clock to
avoid complications due to leap seconds. 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.    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.

Trying to write the above I actually got confused about the epoch for
NTP. After some reasoning I deduced that it must be the format epoch,
i.e. 1900 rather than the epoch of the UTC time which I believe is 0h 1
January 1972.

I think it is important to remember that some of the implementors of
this specification will basically get an order: Go implement this for
our system. They may additionally know which clock system it is
coordinated with.

> 
>     > 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?

Maybe not, even if I would prefer a clarification.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------