<!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.0412291951160.8403@bob.daviesfam.org"
type="cite">
<pre wrap="">
On Tue, 28 Dec 2004, Steve Kann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
This is where I always had trouble when trying to report measurements from
the jitter buffer - just because the jitter buffer is a particular size,
doesn't in my opinion tell you too much about how long a frame will be
delayed. If its true that we are just looking at delay "spikes" then you
are right. But I tended to see that the delay jumps higher for seconds or
tens of seconds, sometimes followed by lost packets and a return to lower
delay (symptom of congestion and a router running out of buffer).
Timestamp discontinuities made things more complicated.
Still - the thing is to try it and see how things go.
</pre>
</blockquote>
<br>
Well, I'm presently finishing up the first implementation of sending
the RR stuff in libiax2/iaxclient. Next, I'll work on parsing the
incoming RR reports from the other side, and making this available to
iaxclient programs via some API.<br>
<br>
I'm guessing based on your off-list comments that you're going to try
to put the new jitterbuffer in channel.c, instead of in chan_iax2.c.
It shouldn't matter, as long as we can get to them from where we send
PONGs, though. In the meantime, I might throw something together
using the existing jitterbuffer, such as it is, as a proof-of-concept,
and in order to more easily test the receiving code in libiax2.<br>
<br>
I think another unstated part of the specification should be that if
you can't properly generate a particular IE, you should not send it.
For example, the current jitterbuffer can't say anything at all about
loss, because it has no idea if things are lost, so it would just not
send this IE.<br>
<br>
-SteveK<br>
<br>
<br>
<br>
</body>
</html>