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

[Kevin P. Fleming]

Matt Roth wrote:

> Thank you for the information.  It seems that ast_rtp_bridge() is not 
> being used to bridge the channels, but that did get me on the correct 
> trail.

It should be; if the peers are both SIP/RTP, then ast_rtp_bridge() 
should be called unless you are doing something to stop native bridging 
from occurring (recording, DTMF features, etc). From what I understand 
from previous conversations, you have these audio problems even when a 
simple call with no extra features is being made.

> I don't believe this swap properly prioritizes the channels.  Whichever 
> order they are in, it is ultimately random which one ast_waitfor_n() 
> will return back to be read from.  This means that the same channel can 
> be read multiple times in a row, starving the other one.  That causes 
> dropped audio on the call, in one direction.  It simultaneously 
> unbalances the chan->insmpl and chan->outsmpl member variables and 
> causes ast_read() and ast_write() to perform an ast_seekstream() on the 
> files if the call is being recorded.  These ast_seekstream() calls jump 
> the file pointer forward, leaving a gap in the data which comes across 
> as a pop in the PCM format.

But what you are missing is that frames only arrive 50 times per second. 
Even if the loop _always_ found a frame from channel 1 first, it would 
immediately loop around again and find the frame from channel 2 without 
blocking on channel 1. Assuming it does not take 20ms to actually 
process the frame from channel 1 out to channel 2, there is plenty of 
time to handle both channels during each 20ms cycle regardless of the 
priority they are handed to poll().

There is no possibility of 'starving' a channel, unless one channel is 
feeding frames to Asterisk so fast that it can't do anything but write 
them out and loop around again.

> Now the swapping of the channels guarantees that each gets its fair 
> share of reads.  This should be okay, since Asterisk already relies on 
> silence transmission.  I tested this with a number of calls and the 
> results were good.  I understand that it may be an overly simple fix 
> with possible side effects, which is why I'm submitting it for review.

I don't understand how you think this could have that effect... there 
are two possibilities:

1) the list of fds provided to poll() is always processed by the kernel 
in a random order, in which case all this priority-swapping makes no 
difference whatsoever

2) the list of fds provided to poll() is processed in the supplied order 
(or in the reverse order), in which case swapping them around will 
guarantee each channel gets equal priority, since it won't matter that 
the second/third/etc. channel in the list are even present at all

I understand that you are having a problem, but I just don't see how it 
could be something so basic without affecting many (hundreds or 
thousands) of other users. There has to be _something_ unique about your 
configuration that is causing this behavior to be exhibited, regardless 
of what turns out to be the cause. Until we can identify what that 
source is, we can't be absolutely sure that your fix (or any other fix) 
is the right change to make.