| Summary: | ASTERISK-13180: revision r77858 breaks 'failed'-extension functionality | ||
| Reporter: | Eugene Rogoza (erogoza) | Labels: | |
| Date Opened: | 2008-12-09 02:14:55.000-0600 | Date Closed: | 2008-12-11 14:07:44.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/PBX |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | The function 'ast_pbx_outgoing_exten()' in pbx.c offers a possibility for creating a fake channel "OutgoingSpoolFailed" and running the PBX on the extension "failed" on it. However, only the first priority of this extension in the dialplan gets executed, then this fake channel gets hung up. The reason for this is the 'ast_check_hangup()' instead of 'c->_softhangup' in 'ast_pbx_run()'. 'ast_check_hangup()' additionally checks for the presense of 'chan->tech_pvt', and because fake channels do not have any PVT structures associated, the value of that field is NULL, which then returns 1 as a function result, which causes the exit from the main loop on priorities in 'ast_pbx_run()'. Dummy PVTs for fake channels don't seem to be the best solution as the following piece of code in 'ast_channel_free()' would then be executed: if (chan->tech_pvt) { ast_log(LOG_WARNING, "Channel '%s' may not have been hung up properly\n", chan->name); ast_free(chan->tech_pvt); } ****** ADDITIONAL INFORMATION ****** See issue 10230. | ||
| Comments: | By: Leif Madsen (lmadsen) 2008-12-10 10:30:24.000-0600 I think this issue makes sense to be assigned to Russell. Please re-assign should you feel different, or if someone else wishes to take this on. By: Digium Subversion (svnbot) 2008-12-11 14:07:43.000-0600 Repository: asterisk Revision: 163171 U trunk/main/channel.c ------------------------------------------------------------------------ r163171 | russell | 2008-12-11 14:07:43 -0600 (Thu, 11 Dec 2008) | 16 lines Fix the "failed" extension for outgoing calls. The conversion to use ast_check_hangup() everywhere instead of checking the softhangup flag directly introduced this problem. The issue is that ast_check_hangup() checked for tech_pvt to be NULL. Unfortunately, this will be NULL is some valid circumstances, such as with a dummy channel. The fix is simple. Don't check tech_pvt. It's pointless, because the code path that sets this to NULL is when the channel hangup callback gets called. This happens inside of ast_hangup(), which is the same function responsible for freeing the channel. Any code calling ast_check_hangup() better not be calling it after that point, and if so, we have a bigger problem at hand. (closes issue ASTERISK-13180) Reported by: erogoza ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=163171 | ||