[Asterisk-Dev] IAX2 Receiver Reports

[Steve Kann]

steve at daviesfam.org wrote:

>On Tue, 28 Dec 2004, Steve Kann wrote:
>
>  
>
>>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.
>>    
>>
>
>
>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.
>  
>

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.

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.

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.

-SteveK



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20041229/5fe75e71/attachment.htm