Summary:	ASTERISK-07617: [patch] ast_pbx_outgoing_exten in pbx.c doesn't put any information about which call failed in CDR or channel variables
Reporter:	salaud (salaud)	Labels:
Date Opened:	2006-08-29 05:44:05	Date Closed:	2011-06-07 14:07:53
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20061210__bug7821.diff.txt
Description:	ast_pbx_outgoing_exten  in pbx.c creates a blank CDR and no channel variables that relate to the called that failed, if a call fails.  The bottom line is that it should be possible to look a CDR (or the channel variables) of a failed call and figure out which spooled called failed.  Having a reference to the uniqueid would be great.  It would be even better to know which attempt it was that failed or worked correctly.
Comments:	By: jmls (jmls) 2006-11-01 06:29:30.000-0600 is this a bug or a feature request ? If the latter, then this shouldn't be here :) By: salaud (salaud) 2006-11-01 12:58:58.000-0600 I wouldn't think of this as feature.  Unless in the sense that brakes are a "feature" on a car. :)  In effect, it makes NO sense to have a "failed" exten, if you can't find out what failed.  Knowing what failed doesn't seem like much of a feature more of a bug... or not rather a bad piece of code, but a missing piece of code that is a bug. Anyway, it's probably a small fix and would create a working piece of functionality where there is none now. By: Serge Vecher (serge-v) 2006-11-07 13:07:14.000-0600 RTFM -> cdr.conf.sample ;loguniqueid=yes ;log uniqueid By: salaud (salaud) 2006-11-07 16:08:58.000-0600 WTFM or better WTFS - Write The Fine Software I have added several bug reports in this venue and have come to this sort of crap over and over again.  I promise I will no longer contribute here if I see another RTFM on here.  I spend a lot of time working in around asterisk and creating interesting apps around it. Now:  I log the uniqueid id.  BUT THIS DOES NOT HELP IN THE DIALPLAN!  Having the the uniqueid in the CDR is not going to tell me which NUMBER / EXTENSION failed during the call processing.  Perhaps, after the fact I could analyze the cdr logs and put two and two together.  I go around my elbow to get there, of course, and I have. Bottom line is that the channel variables, especially the NUMBER DIALED needs to be available at the 'failed' extension.  I want to be able say that a call to a certain extension failed and do something with that information immediately, not reading back the cdrs.  I really don't think it should be necessary to record the uniqueid at the beginning of the call with all the channel variables to the side, then when it fails look it up in a db, just to get which extension (or other channel variables) where initally there before the failure. I really think that this was just an oversight in the code.  If you actually look at the code that a cited above, you will see just a few lines that need to be changed to make sure that the channel variables (exten in particular) survive at the failed extension.  This will keep people from gonig all around this oversight just to get this simple information. I'll leave it here on this issue.  No one wants to fix it, fine.  But, I am getting pretty tired of trying in this forum. By: Serge Vecher (serge-v) 2006-11-14 10:22:37.000-0600 salaud: please do not get offended. You have made a claim about a specific bug "ast_pbx_outgoing_exten in pbx.c doesn't put any information about which call failed in CDR or channel variables" making a reference to uniqueid which I have countered with a specific configuration option. Contributions from the community are valued and make Asterisk what it is; that is why Digium has made available several "venues" to collect these inputs based on what they are. As you have correctly observed the bug-tracker is not a "forum" but a tool to keep track of specific bugs and feature implementations with patches. Based on the original notes and your additional input, this report is neither. If you believe that there is an ovesight in the code and you can propose the patch that fills that gap, feel free to reopen this report with that patch attached. If you cannot develop the patch yourself, you can start a discussion on #asterisk-dev IRC channel or the asterisk-dev mailing list, which are the proper "forum" venues. Thanks. By: salaud (salaud) 2006-11-14 13:18:21.000-0600 serge-v:   (1) (a) Though you are correct that you can turn on an option to log the uniqueid, the configuration option that you cited DOES NOT fix ALL the problem that opened this issue.  This unique id DOES NOT exist in the channel variables or is not available at run-time, only after the fact.  Even if you could get it, you would need to fish through the cdrs to get at the original extension that was dialed.   (b)  Perhaps I stated the problem wrong.  Think of this as saying, what happens at 'i' having ${INVALID_EXTEN}, needs to happen at 'failed'.  But, with ${FAILED_EXTEN}.   Right now, you cannot DIRECTLY have any idea which 'call', meaning to which EXTEN or number failed.  'failed' is useless without going around through the cdr or pushing the exten into a user channel variable.  This should be here already.  It is an oversight.  Just as you would find if ${INVALID_EXTEN} had not been created. (2)  There STILL exists an oversight in the code. (3)  If there is an oversight in the code, and SALAUD cannot fix the problem, then, the issue remains OPEN for SOMEONE to fix.   (4)  I have taken the time log an issue which still needs to be addressed, in my opinion, by closing something that I can't personally fix, you disuade me from posting any others. (5)  Has it even bee tested to see whether or not someone can DIRECTLY figure out which call (specifically which EXTEN) failed while in the 'failed' priority? (6) Was my note even read? (7) Name something useful that can be done with the information DIRECTLY available in the standard channel variables at the 'failed' priority. (8)  At worst, being able to do something useful at the 'failed' priority with the standard channel variables is a 'feature'.  Not something that should be carried to another 'venue'.  A patch should be submitted and tracked here (or in 1.4) by SOMEONE and don't have to be me. By: Tilghman Lesher (tilghman) 2006-12-10 23:53:51.000-0600 Please try this patch to see if it fixes your issue.  The values should be available in "ORIG_CONTEXT" and "ORIG_EXTEN". By: Tilghman Lesher (tilghman) 2007-01-16 18:07:37.000-0600 We need your feedback on this patch. By: Tilghman Lesher (tilghman) 2007-01-25 17:25:21.000-0600 No response from reporter.