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

[SteveK]

On Dec 24, 2005, at 11:13 AM, Florian Overkamp wrote:

> 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 ?

You wouldn't want to do that in the normal case, as it adds latency  
to the link, and the far end _still_ would need it's own jitterbuffer  
for the jitter and loss induced in the second leg of the trip -- it's  
better to just deal with it all at the eventual receiver.

On the other hand, in the case of Monitor()'ed calls, for ideal call  
recording quality, you'd want a jitterbuffer somewhere between the  
packets being received and being written to disk, but asterisk  
doesn't have that.   You could do that by enabling the jb for VoIP- 
 >VoIP calls when Monitor() is active, which would add latency to  
these calls, or some other way, which would require some more code to  
implement.




>
> I could be wrong though, I'm not that deep into the code these days.
>
> Florian
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> Asterisk-Dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>