Summary:	ASTERISK-04615: [patch] Addition of user definable ExitStatus field to manager Hangup event.
Reporter:	Matthew Nicholson (mnicholson)	Labels:
Date Opened:	2005-07-18 19:04:45	Date Closed:	2011-06-07 14:02:38
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/ManagerInterface
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) manager_exit_status.diff.txt
Description:	This patch will return the value of the ExitStatus channel variable with the Hangup manager event. ****** ADDITIONAL INFORMATION ****** Example: extensions.conf: exten => s,1,Set(ExitStatus=SUCCESS!!!) The hangup event for this channel for the manager will include the following: Event: Hangup ExitStatus: SUCCESS!!!
Comments:	By: nick (nick) 2005-07-18 19:11:34 I think you might want to explain the utility of this, given that we have a hangupcause. By: Matthew Nicholson (mnicholson) 2005-07-18 19:18:35 Sorry.  I needed something like this for a customer's application.  They have specfic data that needs to be returned to our manager proxy in addition to the cause of the hangup.  This is additional metadata collected in the dialplan that asterisk does not really care about. By: Kevin P. Fleming (kpfleming) 2005-07-19 20:55:39 In that case I think it would make more sense to make the variable name be specific to the Manager interface then, as opposed to this generic name which will likely lead to confusion. In addition, we typically use all-uppercase variable names for builtin purposes. Does anyone have any opposition to MANAGER_HANGUP_STATUS? If not, I'll change it before the commit. By: Stefan Reuter (srt) 2005-07-20 05:55:19 -1 I am not sure we really need this additional attribute. To me this looks like a very customer specific feature (one specific variable that is passed on one specific event and that is no way related to any asterisk internal state). There already is a way to send arbitrary data to an AMI-connected application via dialplan: The UserEvent. Instead of the Set(ExitStatus=SUCCESS!!!) you could as well use UserEvent(SetExitStatus|ExitStatus: SUCCESS!!!). The only difference is that your application has to keep track of the channel-exitstatus relationship (by listening to SetExitStatus events) until hangup instead of Asterisk. I prefer to use the extension capabilities that already exist instead of further cluttering the Manager API. By: Olle Johansson (oej) 2005-07-20 06:56:53 I don't see this addition as a generic addition, even though I understand your need for it. The name "EXITSTATUS" assumes some well-defined parameters, not a free text field. In this form, I would name it "hangupcomment" or something like that to make sure it's very generic. Then we could forward it in a SIP bye if it existed as X-hangupcomment or something. However, I can't find a huge need for this as a generic function in Asterisk. Any others see a need for this function? By: Matthew Nicholson (mnicholson) 2005-07-20 09:43:36 Ahh.  I was not aware of the UserEvent.  I like this even better than my patch.  I would say go ahead and close this with out committing it to CVS in that case. By: Olle Johansson (oej) 2005-07-20 09:52:06 ...reading docs is a good thing (tm) :-) Closed on reporter's request.