[FFmpeg-devel] Fix NTP time in RTCP SR packets

[Reimar Döffinger]

Hello,
On Fri, Feb 15, 2008 at 09:34:19AM +0100, Luca Abeni wrote:
> Reimar D?ffinger wrote:
> > On Fri, Feb 15, 2008 at 08:40:40AM +0100, Luca Abeni wrote:
> >> I recently notice some errors in the statistics
> >> computed on RTP streams generated by libavformat.
> >> After some investigation, I noticed that the errors
> >> are due to the fact that rtcp_send_sr() is invoked
> >> with the gettimeofday() time and not the NTP time as
> >> a parameter.
> > 
> > As you probably know I am always and still opposed to leaking
> > unnecessary information about the local system to a server,
> > and thus strongly dislike the fact that gettime is used at all, at
> > least without enabling it explicitly.
> 
> I suspect the problem you are pointing out is orthogonal
> respect to my fix, since av_gettime() is already used...

Yes, I still want to point it out.

> Anyway, as far as I understand there is no choice, because the
> standard mandates the use of NTP time. And I do not think that
> this code is sending out any information about the local
> computer (apart of the fact that the clock is currently set):
> this code is used during live streaming, so the receiver can
> already know that I am sending the packets now, even without
> reading the NTP time in them :)

Uh, as I understand it, this sends out the local time with usec
precision. The server sure as hell does not know that, and it could e.g.
be used to guess values if someone uses a stupid random number
generator, system/network load and other things.
IOW this is one of the things everyone planning a side-channel attack
just dreams of.

> In any case, if we can find a standard-compliant way of setting
> the RTCP fields without leaking information about the local
> system, I am in favour of it (suggestions welcome).

Why would it need to be standard compliant? There is no single computer
in the world that has a exact time, so requiring to send out the current
time is impossible to fulfil anyway.
Honestly, I am in favour of always sending out 0, there is a limit to
the kind of idiocy in a standard that should be accepted.
Or just send out a number that increases by a fixed amount (or if the
stream has timestamps, just send those back).

Greetings,
Reimar D?ffinger