[Asterisk-Dev] IAX2 Receiver Reports

[Steve Kann]

steve at daviesfam.org wrote:

>On Tue, 28 Dec 2004, Steve Kann wrote:
>
>  
>
>>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).
>>    
>>
>
>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, 
>
This is already true, I think.

>and that 
>the jitterbuffer delay measurements added in the IEs are the delays that 
>would have been added for the particular ping or pong.
>  
>

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.

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.

>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...
>  
>
right, but it shoudn't matter, as seen above.

-SteveK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20041228/4e601697/attachment.htm