Summary:	ASTERISK-03977: [request] HANGUPCAUSE doesn't populate in chan_sip
Reporter:	gnudialer gnudialer (gnudialer)	Labels:
Date Opened:	2005-04-24 20:36:04	Date Closed:	2011-06-07 14:04:46
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	NORMAL CLEARING is the only one that works. Otherwise you just get 0 for HANGUPCAUSE, and CAUSECODE is empty. I checked the csv logs, and don't find anything useful.  Also, I've ran asterisk with logs of Vs and the only thing that shows is "Call failed to go through, reason 0." ****** ADDITIONAL INFORMATION ****** Please go easy on me as this is my first time using Mantis, and I've thoroughly investigated this problem.
Comments:	By: gnudialer gnudialer (gnudialer) 2005-04-24 20:56:41 This might help. :) ;;;;;;;;;;; the .call file Channel: Local/${PHONENUMBER}@testin/n MaxRetries: 0 RetryTime: 60 WaitTime: 30 Context: testout Extension: s Priority: 1 ;;;;;;;;;;;;;; in extensions.conf [testin] exten => _1NXXNXXXXXX,1,Dial(sip/cpdemo6/${EXTEN:1}) exten => h,1,Echo(HEY THE CAUSECODE IS: ${CAUSECODE}) ;exten => h,1,Echo(HEY THE HANGUPCAUSE IS: ${HANGUPCAUSE}) [testout] exten => s,1,Dial(Console/default) ;;;;; doesn't really matter what we dial The docs don't act like HANGUPCAUSE is guaranteed to work when using sip, but they say it "seems to work."  CAUSECODE is supposed to work on all. edited on: 04-24-05 21:01 By: Tilghman Lesher (tilghman) 2005-04-24 21:40:04 Where exactly did you read about the existence of the variable CAUSECODE?  I'm not finding it anywhere in the source.  I am, however, finding that HANGUPCAUSE is related in chan_iax2 and pbx_dundi, to a structure member named causecode.  Perhaps this is the source of the confusion? I'm also not finding HANGUPCAUSE being set or checked anywhere within chan_sip, which makes this a feature request.  It's a feature request, in that we'd need to map SIP error codes into Q.931 causecodes, which is what Asterisk uses to represent call termination state. By: gnudialer gnudialer (gnudialer) 2005-04-24 21:48:12 Under the sub-heading "Return Values in Channel Variables," on this page... http://www.voip-info.org/wiki-Asterisk+cmd+Dial it says, " For all (?) channels the CAUSECODE variable returns the errormessage if the dial has failed." The page was created by oej. Under the first heading on this page: http://www.voip-info.org/wiki-Asterisk+variable+hangupcause it says, "Hangupcause is the latest PRI hangup return code on a zap channel connected to a PRI interface. Note that this appears to also work on SIP channels, maybe other channels as well." This was also written by oej. So the way I figure, for HANGUPCAUSE it is a feature request, but for CAUSECODE it is a bug. By: Tilghman Lesher (tilghman) 2005-04-24 22:23:19 Note the question mark right after the word "all".  That means that the author is not sure whether or not "all" is really correct.  In any case, I believe that the usage of the word "CAUSECODE" here is a typo by oej, which should be "HANGUPCAUSE".  (Or it could be part of a bug oej developed that was never applied to CVS.)  In any case, the Dial application does not, in itself, actually set the variable.  That is handled (if handled at all) by the channel driver. But fair enough:  the documentation on the Wiki has been updated, to eliminate the typo. By: gnudialer gnudialer (gnudialer) 2005-04-24 22:47:35 and I've never discovered DIALSTATUS. I think I can make my situation work using DIALSTATUS, so feel free to close this for now if you want.  If I can't make it work, I might be able to scare up a bounty from some of our sponsors to get HANGUPCAUSE solid on all channels. I really really really appreciate the clarification. This request that I made my have seemed anal-rententive, but please keep in mind that this functionality is almost necessary for efficient operation of a predictive dialer.  I mean, you don't want your campaign calling back a disconnected number 20 times for no reason. Thanks again. By: Tilghman Lesher (tilghman) 2005-04-24 22:53:51 Closed on request of reporter.