[Asterisk-Dev] Help Debugging Dropped Call Audio - Possibly Fixed

[Florian Overkamp]

Hi,

Kevin P. Fleming wrote:
>> That change passed only the first element of the array of channels to 
>> ast_waitfor_n(), guaranteeing that it would win the race to be read.  
>> In conjunction with the swapping of the channels in the array on each 
>> pass of the bridging loop, this guarantees that each channel gets read 
>> an equal number of times.  I tested this by leaving the additional 
>> logging in place, making the change, and placing a test call.  The 
>> call produced no "WARNING" or "NOTICE" messages and the recording had 
>> no pops.
> 
> But it doesn't actually guarantee that at all... you have to keep in 
> mind that the packet delivery from the channels is not consistent 
> (jitter and packet loss come into play) and its very possible in this 
> configuration to lose packets from a channel because you have decided to 
> wait for a packet from the other one and the 'current' packet from that 
> channel is late and/or lost. In that case, you will read from this 
> channel, then read from the other channel, then go back to this one, 
> even though the other channel still has a pending packet to be read.

Actually, shouln't the bridge happen _after_ a jitterbuffer of sorts ? 
In such a case the JB would return a 'no data' packet on the read and 
leave it to the other end to decide what to do, or simply generate an 
intermediate packet to cover it up ?

I could be wrong though, I'm not that deep into the code these days.

Florian