path: root/apps
diff options
authorrussell <russell@f38db490-d61c-443f-a65b-d21fe96a405b>2010-11-24 17:03:16 +0000
committerrussell <russell@f38db490-d61c-443f-a65b-d21fe96a405b>2010-11-24 17:03:16 +0000
commit67716e62574008f97c35ad15844ff4982ac3070f (patch)
tree628e4819f9fa40c3af12de6d9350d16c538b2306 /apps
parente78bf4a3087a9f84b95d92ce6e13b8796e7efacb (diff)
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: http://svn.digium.com/svn/asterisk/branches/1.6.2@296001 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'apps')
1 files changed, 10 insertions, 1 deletions
diff --git a/apps/app_dial.c b/apps/app_dial.c
index 0424ec0d8..e05a88713 100644
--- a/apps/app_dial.c
+++ b/apps/app_dial.c
@@ -839,7 +839,16 @@ static struct ast_channel *wait_for_answer(struct ast_channel *in,
/* Turn off hold music, etc */
/* If we are calling a single channel, make them compatible for in-band tone purpose */
- ast_channel_make_compatible(outgoing->chan, in);
+ if (ast_channel_make_compatible(outgoing->chan, in) < 0) {
+ /* If these channels can not be made compatible,
+ * there is no point in continuing. The bridge
+ * will just fail if it gets that far.
+ */
+ *to = -1;
+ strcpy(pa->status, "CONGESTION");
+ ast_cdr_failed(in->cdr);
+ return NULL;
+ }