Hi Thomas,
Thomas.Schierl at hhi.fraunhofer.de wrote:
Hi Stefan,
Stefan Döhla wrote:
Colin, Thomas, all,
the draft is describing the proposed header extension and RTCP SR
request quite good, however:
Isn't the NTP timestamp generation subject to the same problems as
in RTCP? I could easily send an RTCP SR as well for every RTP packet
within a sampling instance of one (in terms of RTP time), i.e. there
could be an RTP packet and an RTCP SR packet containing the same RTP
timestamp if I were able to generate them virtually at the same time
(just a few ns away). Clearly, this is not datarate-efficient nor
sensible, but I don't see a big difference to the proposed approach.
So what about the source for the NTP time: Should the NTP time be
filtered at the sender before inclusion into the HDR_EXT? Because if
not, the NTP timestamp would either be only related to the RTP
timeline (bad - then we have two different timelines, one via RTCP,
the other in the HDR_EXT) or be jittery (bad because not instantly
useful, though the same timeline as RTCP).
Here it is important to use the same NTP timestamp value for the same
point of synchronization in all the sessions. This is only
guaranteed, if such header extensions are used for the same sampling
time instance in all the sessions, i.e. using the same NTP wallclock
timestamp. I think this is stated in the draft.
Let me rephrase it a little: If I accidentally receive an RTCP SR with
the same RTP timestamp as in an RTP packet in either session, would
the NTP timestamp be the same?