Merged revisions 296002 via svnmerge from
authorRussell Bryant <russell@russellbryant.com>
Wed, 24 Nov 2010 17:23:39 +0000 (17:23 +0000)
committerRussell Bryant <russell@russellbryant.com>
Wed, 24 Nov 2010 17:23:39 +0000 (17:23 +0000)
commit712ba23185df3392917e2d3d81bff5c6ab912b46
tree66f0bab933baeff538d5203fe4369409f081bf80
parentcd866cde29159fdf1c21413c3163098818e67c94
Merged revisions 296002 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r296002 | russell | 2010-11-24 11:13:08 -0600 (Wed, 24 Nov 2010) | 52 lines

  Merged revisions 296001 via svnmerge from
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2

  ................
    r296001 | russell | 2010-11-24 11:03:16 -0600 (Wed, 24 Nov 2010) | 45 lines

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

    ........
      r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010) | 38 lines

      Handle failures building translation paths more effectively.

      The problem scenario occurred on a heavily loaded system that was using the
      codec_dahdi module and exceeded the hardware transcoding capacity.  The failure
      mode at that point was not good.  The report came in to us as an Asterisk
      lock-up.  The "core show locks" shows a ton of threads locked up (but no
      obvious deadlock).  Upon deeper investigation, when the system is in this
      state, the CPU was maxed out.  The CPU was being consumed by the Asterisk
      logger spewing messages on every audio frame for calls set up after transcoder
      capacity was reached.

      The purpose of this patch is to make Asterisk handle failures to create a
      translation path in a more graceful manner.  If we can't translate, then the
      call just needs to be dropped, as it's not going to work.  These are the
      changes:

      1) In set_format() of channel.c (which is called by set_read_format() and
      set_write_format()), it was ignoring if ast_translator_build_path() failed and
      returned NULL.  It now pays attention to that case and returns a result
      reflecting failure.  With this change in place, the bridging code will
      immediately detect a failure and end the bridge instead of proceeding to try to
      bridge frames that can't be translated and making channel drivers freak out by
      sending them frames in a format they weren't expecting.

      2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was
      ignored.  It is now reflected in the return value of the function.  This didn't
      turn out to have any affect on the bug, but seemed like a good change to leave
      in.

      3) In app_dial(), when only sending a call to a single endpoint, it will
      attempt to do some bridging of its own of early audio.  It uses
      make_compatible() when it's going to do this.  However, it ignored failure from
      make compatible.  So, even with the fix from #1, if there was early audio going
      through app_dial, there would still be a period of invalid frames passing
      through.  After detecting failure here, Dial() exits.

      ABE-2658
    ........
  ................
................

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
apps/app_dial.c
main/channel.c