Summary:	ASTERISK-13883: [patch] channel-specific hangupcauses
Reporter:	Marcus Hunger (fnordian)	Labels:
Date Opened:	2009-04-02 06:05:25	Date Closed:	2011-06-07 14:03:03
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/Channels
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chancauses.patch
Description:	Hi, regarding the discussion on asterisk-user (http://lists.digium.com/pipermail/asterisk-users/2009-January/224721.html) I want to suggest a solution for this problem. At the moment, channels store their general asterisk hangupcause in the channel which is hung up. Let's store some more channel-specific data about the cause in there, too. The connected channel could then get the information from the channel and make it available to the dialplan and it's own hangup-routine. My implementation uses two channel-variables to store the cause: HANGUP_TECH and *_CAUSE, where *_CAUSE is compounded of the value of HANGUP_TECH + '_CAUSE'. E.g. HANGUP_TECH=SIP, SIP_CAUSE=404 not found. Currently app_dial takes care of propagating the hangupcause. In the case of multiple channels with different causes, it chooses one of them using a priority-scheme. This mechanism is enhanced by handling the HANGUP_TECH + *_CAUSE variables to achieve that these are passed to the calling channel. Please find my implementation attached as a patch. It's still proof of concept but seems to work ;-)
Comments:	By: Leif Madsen (lmadsen) 2009-06-16 15:35:21 Just wanted to comment that it looks like you have this diff'd against 1.6.1, whereas you should really be diff'ing this against trunk since this is a new feature. If you can update the patch, we can see what we want to do about it, and see if it can make it in for 1.6.3 or 1.6.4. Thanks! By: Leif Madsen (lmadsen) 2009-07-13 10:27:06 Pinging reporter for feedback on this issue. Thanks! By: Marcus Hunger (fnordian) 2009-07-14 03:55:30 Hi there, sorry, this one got a little bit out of my sight. Last time I dealt with this issue was on the dev-meeting at amoocon. I presented it there and we agreed that this might be interesting but should perhaps be implemented in another way. Later I emailed Russel about it, but never got a reply. So, although I am still interested in seeing the feature, I am a bit confused about how it should be done. So, if you guys think the approach of using HANGUP_TECH and *_CAUSE might be promising, I am willing to port the patch as it is. If there were some ideas pointing in another direction, I would consider them, too. By: Tilghman Lesher (tilghman) 2009-07-25 12:55:19 I'm inclined to call this a duplicate of ASTERISK-12437.  If that fix works for you, let's close this one out. By: Marcus Hunger (fnordian) 2009-07-27 03:57:57 implementation of 13140 looks promising. although some stuff is missing. - 13140 just provides reporting of a sip-cause. it's not possible to set them. - there is no passthrough for causetext in chan_local By: Tilghman Lesher (tilghman) 2009-07-29 16:40:43 It's definitely possible to set the causes, in addition to the default reporting.  Just use the same function as is used in the code. By: Marcus Hunger (fnordian) 2009-07-31 04:19:10 I cannot see chan_sip reading SIP_CAUSE in the patch (https://issues.asterisk.org/file_download.php?file_id=23301&type=bug). By: Tilghman Lesher (tilghman) 2009-08-07 14:32:02 Correct, it's obtaining the raw code, rather than re-obtaining it from a variable that it itself sets. By: Tilghman Lesher (tilghman) 2009-08-07 14:33:18 Also, the patch for 13140 has been updated to fix the chan_local deficiency. By: Tilghman Lesher (tilghman) 2009-09-10 16:53:27 Hello?  Testing?  Anybody there? By: Tilghman Lesher (tilghman) 2009-09-10 16:54:23 I'm just going to close this, since ASTERISK-12437 has been committed.