[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
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?
[snip]
--
Dipl.-Ing. Stefan Döhla | Email: stefan.doehla at iis.fraunhofer.de
Multimedia Transport | Phone: +49 (0)9131 776 6042 (!NEW!)
Audio Department | Fax: +49 (0)9131 776 6099 (!NEW!)
Fraunhofer IIS |
Am Wolfmantel 33 |
91058 Erlangen, Germany | Web: http://www.iis.fraunhofer.de/amm