[asterisk-dev] [Code Review] Allow ast_safe_sleep to defer frames similarly to the way autoservice does it.

Kevin Fleming kpfleming at digium.com
Fri May 21 11:03:37 CDT 2010


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/674/#review2063
-----------------------------------------------------------

Ship it!


This looks good, and your testing proves it works. Make it so!


/branches/1.4/include/asterisk/channel.h
<https://reviewboard.asterisk.org/r/674/#comment4351>

    Minor point: make the parameter 'const'.



/branches/1.4/main/channel.c
<https://reviewboard.asterisk.org/r/674/#comment4352>

    splotch!


- Kevin


On 2010-05-21 10:50:52, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/674/
> -----------------------------------------------------------
> 
> (Updated 2010-05-21 10:50:52)
> 
> 
> Review request for Asterisk Developers, Russell Bryant and Kevin Fleming.
> 
> 
> Summary
> -------
> 
> Background:
> A Digium customer discovered a somewhat odd bug. The setup is that parties A
> and B are bridged, and party A places party B on hold. While party B is 
> listening to hold music, he mashes a bunch of DTMF. Party A takes party
> B off hold while this is happening, but party B continues to hear hold
> music. I could reproduce this about 1 in 5 times.
> 
> The issue:
> When DTMF features are enabled and a user presses keys, the channel that
> the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the
> duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read
> from the channel during the sleep, the frame is dropped. Thus the
> unhold indication is never made to the channel that was originally placed
> on hold.
> 
> The fix:
> Originally, I discussed with Kevin possible ways of fixing the specific
> problem reported. However, we determined that the same type of problem
> could happen in other situations where ast_safe_sleep() is used. Using
> autoservice as a model, I modified ast_safe_sleep_conditional() to
> defer specific frame types so they can be re-queued once the sleep has
> finished. I made a common function for determining if a frame should
> be deferred so that there are not two identical switch blocks to
> maintain.
> 
> I have included Kevin on this review since he and I discussed the 
> original fix together. I also have included Russell since this is
> touching a pretty core part of Asterisk and I figure he would want
> to have a say in this.
> 
> The version attached here is for the 1.4 branch since it is the oldest
> branch affected by this issue. The 1.6.2 branch and trunk are also
> affected.
> 
> 
> This addresses bug ABE-2115.
>     https://issues.asterisk.org/view.php?id=ABE-2115
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/include/asterisk/channel.h 264541 
>   /branches/1.4/main/autoservice.c 264452 
>   /branches/1.4/main/channel.c 264541 
> 
> Diff: https://reviewboard.asterisk.org/r/674/diff
> 
> 
> Testing
> -------
> 
> I ran the situation from the Digium customer probably about 30 times and was
> unable to cause the error to occur. In addition, I also ran the test under
> valgrind's memcheck tool and it reported no errors.
> 
> 
> Thanks,
> 
> Mark
> 
>




More information about the asterisk-dev mailing list