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

[Magnus Westerlund <[e-mail]>]

Hi,

With the new text in the other messages I think I am fine and I
revisited section 5.2 and I think it sufficient clear.

If any one in the WG wants to give their input on this it would be
appreciated.

So, after a revised ID has been submitted with the offset example text
lets progress.

Cheers

Magnus

On 2013-09-26 02:27, Kevin Gross wrote:
> Sorry about that Magnus. I circulated a proposed response on these
> issues among authors back in August but it looks like I never got that
> to you and the avt list. Let me know if you would like to see any
> changes based on this response.
> 
>     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.
> 
> 
> A naive implementation would simply add 2208988800 (as defined in RFC
> 868) to current Unix time(). However, because of the way Unix time is
> defined, this does not include leap seconds. We appreciate that guidance
> is required to correctly calculate the actual number of elapsed seconds
> since the epoch for a leap-second-bearing reference. We can try to add
> this guidance or we can simply advise against specifying an offset for
> leap-second-bearing reference clocks. This issue does not exist for TAI
> reference clocks.
> 
>        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.
> 
> 
> This is correct. There is a fair amount of clarification 5.2 that you
> have not quoted. The fact that you properly understand it indicates to
> me that it may actually be adequately clear. To clarify further I think
> would require a lesson on NTSC and digital audio history.
> 
> Kevin Gross
> [phone]
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> 
> 
> On Wed, Sep 11, 2013 at 1:14 AM, Magnus Westerlund
> <[e-mail] <mailto:[e-mail]>>
> wrote:
> 
>     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.
> 
> 
>     > 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.
> 
>     Cheers
> 
>     Magnus
> 
> 
>     On 2013-09-11 02:13, [e-mail]
>     <mailto:[e-mail]> wrote:
>     >
>     > A New Internet-Draft is available from the on-line Internet-Drafts
>     directories.
>     >  This draft is a work item of the Audio/Video Transport Core
>     Maintenance Working Group of the IETF.
>     >
>     >       Title           : RTP Clock Source Signalling
>     >       Author(s)       : Aidan Williams
>     >                           Kevin Gross
>     >                           Ray van Brandenburg
>     >                           Hans Stokking
>     >       Filename        : draft-ietf-avtcore-clksrc-06.txt
>     >       Pages           : 28
>     >       Date            : 2013-09-10
>     >
>     > Abstract:
>     >    NTP format timestamps are used by several RTP protocols for
>     >    synchronisation and statistical measurements.  This memo specifies
>     >    SDP signalling identifying timestamp reference clock sources
>     and SDP
>     >    signalling identifying the media clock sources in a multimedia
>     >    session.
>     >
>     >
>     >
>     > The IETF datatracker status page for this draft is:
>     > https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc
>     >
>     > There's also a htmlized version available at:
>     > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-06
>     >
>     > A diff from the previous version is available at:
>     > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-clksrc-06
>     >
>     >
>     > Please note that it may take a couple of minutes from the time of
>     submission
>     > until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>     >
>     > Internet-Drafts are also available by anonymous FTP at:
>     > ftp://ftp.ietf.org/internet-drafts/
>     >
>     > _______________________________________________
>     > Audio/Video Transport Core Maintenance
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/avt
>     >
>     >
> 
> 
>     --
> 
>     Magnus Westerlund
> 
>     ----------------------------------------------------------------------
>     Multimedia Technologies, Ericsson Research EAB/TVM
>     ----------------------------------------------------------------------
>     Ericsson AB                | Phone  [phone]
>     <tel:%2B46%2010%207148287>
>     Färögatan 6                | Mobile [phone]
>     <tel:%2B46%2073%200949079>
>     SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>     <mailto:[e-mail]>
>     ----------------------------------------------------------------------
> 
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/avt
> 
> 


-- 

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