<!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.&nbsp;&nbsp;&nbsp; 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.&nbsp;&nbsp;
It shouldn't matter, as long as we can get to them from where we send
PONGs, though.&nbsp;&nbsp; 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.&nbsp;
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>