<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is incorrect. The information in incoming RTCP "SR" packets is used to generate presentation times from incoming RTP packets' timestamps. These presentation times - like the RTP timestamps themselves - are (necessarily) based on the sender's clock (because that was the only clock available to the entity (the sender) that created the presentation times).</blockquote>
<div><br>Please point me at the section of RFC3550 that says that the RTCP SR NTP timestamp is to be used for a presentation time.<br><br>I see it stating that the sender can use any time source for the NTP timestamp. It says that it "may be used for intra- and inter-media synchronization for sources whose NTP timestamps are synchronized" and "may be used by media-independent receivers to estimate the nominal RTP clock frequency".<br>
<br><meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><title></title><meta name="GENERATOR" content="OpenOffice.org 2.3 (Linux)">And on page 14 when talking about the RTP/NTP timestamp pairs: "the purpose is to allow synchronized
presentation of all media sampled at the same time."<br><br>Reading too much into the NTP timestamp violates the fundamental principle of network protocols "be strict about what you send and permissive about what you accept." By immediately adjusting the presentation time based on the NTP timestamp the presentation times become non-monotonic and the receiver does not know much much when to display the new stream in relation to the old stream.<br>
</div></div><br>.mike<br>