<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=US-ASCII" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<a class="moz-txt-link-abbreviated" href="mailto:steve@daviesfam.org">steve@daviesfam.org</a> wrote:
<blockquote cite="midPine.LNX.4.58.0412282202180.8403@bob.daviesfam.org"
type="cite">
<pre wrap="">
On Tue, 28 Dec 2004, Steve Kann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Also, LAGRQ frames are presently sent to the remote side, in order to
get an idea of the Round-Trip + playout(jitterbuffer) delay. The
implementation of LAGRQ is presently a bit broken, because they
currently go through the jitterbuffer on _both_ the sender and receiver
side, and the timestamps used to do this are wrong. (actually, I
haven't checked this recently, but it was the case).
</pre>
</blockquote>
<pre wrap=""><!---->
Yeah - I'd suspect that the LAGRQ/RP isn't right. And it always seemed
rather pointless as they aren't reported in any obvious way that I
noticed.
Ping roundtrip + the jitter buffer delay on both sides is nicer.
The only problem at the moment is that we need to be careful that the ping
is sent immediately, the pong reply is sent back immmediately, </pre>
</blockquote>
This is already true, I think.<br>
<br>
<blockquote cite="midPine.LNX.4.58.0412282202180.8403@bob.daviesfam.org"
type="cite">
<pre wrap="">and that
the jitterbuffer delay measurements added in the IEs are the delays that
would have been added for the particular ping or pong.
</pre>
</blockquote>
<br>
This shouldn't matter. The PING/PONG will still give an accurate RTT
estimate, and the jitterbuffer delay that's returned will be the
_maximum_ delay. I think it turns out, in practice, that the maximum
delay is usually just about what happens to most packets, because most
packets are sent in a consistent time, while a few packets are late
(because of buffering spikes, etc). Regardless, we're trying to give
an upper bound to the delay, and while 1/2rtt + "delay" would be a
better upper bound, rtt+delay is more conservative, because it takes
into account differing delay lengths.<br>
<br>
Also, reporters should probably report the delay from jitterbuffering,
_plus_ any additional rendering delays after buffering, i.e. DSP
delays, codec delays, audio subsystem delays, etc.<br>
<br>
<blockquote cite="midPine.LNX.4.58.0412282202180.8403@bob.daviesfam.org"
type="cite">
<pre wrap="">But to get the right jitter buffer delay for a ping or pong is complicated
by the fact that the ping has a timestamp that isn't consistent with
ordinary voice frames, and - even worse - the pong has the timestamp of
the originally sent ping...
</pre>
</blockquote>
right, but it shoudn't matter, as seen above. <br>
<br>
-SteveK<br>
<br>
</body>
</html>