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

[Matt Roth]

Kevin,

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.

The function that's called to bridge the channels is 
ast_channel_bridge() in channel.c.  It then hands the bridging over to 
ast_generic_bridge() where the real work is done.

Inside the bridging loop, ast_generic_bridge() calls ast_waitfor_n(), 
providing it with an array populated by both channels.  The way it is 
currently written, ast_waitfor_n() picks a channel to read from and 
passes it back to ast_generic_bridge().  ast_generic_bridge() reads a 
frame from the returned channel, writes it to the other channel, then 
swaps the order of the channels in the array to prioritize them.

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.

I attempted to fix the problem by changing the following line in 
ast_generic_bridge() from:

    who = ast_waitfor_n(cs, 2, &toms);

to:

    who = ast_waitfor_n(cs, 1, &toms);

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.

Thank you,

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer

Kevin P. Fleming wrote:

> Matt Roth wrote:
>
>> All of this leads me to believe that the problem dwells somewhere in the
>> code responsible for bridging the channels.  Does anyone have any ideas
>> as to the specific cause or the direction that I should go to further
>> pursue it?  I've heard that Asterisk's locking scheme is questionable,
>> but I don't know if that would apply to this scenario.
>
>
> That code lives in rtp.c, and is very simple. It also handles many 
> thousands (if not millions) of calls every day all over the world, and 
> if it had a major flaw like this we'd surely have heard about it before.
>
> I really can't help much more in this thread without interfering with 
> the tech support ticket/case that it already open... but I'll try to 
> get some more information tomorrow to see what else you have tested 
> since the last time I talked to tech support about it.
> _______________________________________________
> --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
>