Summary:	ASTERISK-11143: hangupcause is always 0 if call made via call file fails
Reporter:	Andrew Pepler (pep)	Labels:
Date Opened:	2008-01-03 06:06:44.000-0600	Date Closed:	2008-01-14 12:46:25.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	PBX/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Asterisk output gives this: Channel 0/1, span 1 got hangup request, cause 28 So it is capturing the ISDN code but it is not being passed to the hangupcause variable.
Comments:	By: Joshua C. Colp (jcolp) 2008-01-08 10:24:01.000-0600 Can you please provide more information such as the call flow and console output? By: Andrew Pepler (pep) 2008-01-09 03:53:23.000-0600 A call is generated by a call file which connects to the dialplan. I have put in a failed extension to deal with failed calls and a NoOp showing hangupcause gives 0.  The reason variable is also 0. This is the console output: [Jan  9 09:40:14] NOTICE[27965]: channel.c:3123 __ast_request_and_dial: Unable to request channel Zap/g0/0175314       > cdr_odbc: Query Successful!    -- Executing [failed@callback:1] NoOp("OutgoingSpoolFailed", "0") in new stack    -- Executing [failed@callback:2] NoOp("OutgoingSpoolFailed", "0") in new stack  == Auto fallthrough, channel 'OutgoingSpoolFailed' status is 'UNKNOWN'    -- Executing [h@callback:1] Hangup("OutgoingSpoolFailed", "") in new stack  == Spawn extension (callback, h, 1) exited non-zero on 'OutgoingSpoolFailed'       > cdr_odbc: Query Successful! [Jan  9 09:40:15] NOTICE[27965]: pbx_spool.c:341 attempt_thread: Call failed to go through, reason (0) Call Failure (not BUSY, and not NO_ANSWER, maybe Circuit busy or down?) By: Joshua C. Colp (jcolp) 2008-01-09 09:38:22.000-0600 The reason for failure is available in the REASON dialplan variable, not hangupcause. If you use that instead it should work fine. By: Andrew Pepler (pep) 2008-01-10 09:48:55.000-0600 The reason variable only gives basic failure codes that do not relate to the full ISDN clear codes that hangupcause gives. Is there a reason that the hangupcause variable cannot be populated at this stage so that there is a consistency between using a call file and dialing from the dial plan? By: Grzegorz Garlewicz (garlew) 2008-01-13 01:45:15.000-0600 I think this is per design - the failed extension actually creates a separate channel when the original one no longer exists. You can achieve what you want using a local channel in the call file. By: Andrew Pepler (pep) 2008-01-14 09:17:02.000-0600 Is there a reason not to provide the hangupcause information to this new channel? By: Jason Parker (jparker) 2008-01-14 12:46:24.000-0600 If I'm reading this correctly, there was no channel created to have been hungup (which means no HANGUPCAUSE). Re-closing, per comments from file and garlew.