Merged revisions 264996 via svnmerge from

Merged revisions 264996 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r264996 | mmichelson | 2010-05-21 11:28:34 -0500 (Fri, 21 May 2010) | 32 lines

  Allow ast_safe_sleep to defer specific frames until after the sleep has concluded.

  From reviewboard

  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.

  Review: https://reviewboard.asterisk.org/r/674/
........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264997 65c4cc65-6c06-0410-ace0-fbb531ad65f3