Summary:	ASTERISK-15381: Verbose for Call Parking is incorrect
Reporter:	Dan Journo (kesher)	Labels:
Date Opened:	2009-12-30 09:26:12.000-0600	Date Closed:	2013-01-15 11:50:55.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When you park a call, the verbose provided is incorrect. At the time of parking, it reports that its going to timeout to the extension that the caller originally dials, rather than the extention that is parking the call. ****** ADDITIONAL INFORMATION ****** Here is a sample of the verbose:- http://pastebin.com/f27289c6a
Comments:	By: Leif Madsen (lmadsen) 2011-01-28 11:22:16.000-0600 I have a feeling this actually got fixed by Russell Bryant. Can someone re-test? By: Leif Madsen (lmadsen) 2011-01-28 11:22:40.000-0600 Have you already fixed this? By: David Woolley (davidw) 2011-01-28 11:39:28.000-0600 This is not as simple as it seems.  This code can be used in environments where the message will be true, at least on 1.6.x. The situation can arise explicitly, but can also arise if the second channel on an AMI park is one of those being closed out by the masquerade in masq_park_call, at least when a Local channel is involved.  What seems to happen is that asterisk tries to find the owner side of the local channel, then its bridged peer, and finally that's name.  If the local channel is anywhere in the call chain that is being closed because the original channel that was parked has become a zombie, I suspect it ends up accessing the name of a channel that has already been deleted. With current 1.6 versions, specifying an explicit destination will also override the return channel. One other technicality to note is that the behaviour in the simple case is to return to the device associated with the channel that parked the call.  It does not return to an extension, and that device might not even have an extension configured (the parking timeout logic creates a temporary extension, referring to the device, at the time of the timeout, put that extension doesn't look like a normal extension).  It might also have multiple extensions referencing it. I did try to raise a question on the developer list, at the end of the last, week, which covered some of this, but all my postings to the developer list and its owner seem to be disappearing. By: David Woolley (davidw) 2011-01-28 11:45:22.000-0600 Features/Parking would be a more appropriate category.  This code is in features/res_features.c on 1.4, and main/features.c in 1.6 onwards. By: Matt Jordan (mjordan) 2013-01-15 11:50:32.907-0600 Parking got a serious overhaul in Asterisk 1.8. As Asterisk 1.4/1.6.2 are no longer supported, there is a good chance that this is no longer an issue. If you can, please re-test with Asterisk 1.8 and - if it is still an issue - please contact a bug marshal in #asterisk-bugs and we can reopen the issue for you. Thanks! By: Matt Jordan (mjordan) 2013-01-15 11:50:50.793-0600 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions.  After testing with Asterisk 1.8, if you find this problem has not been resolved, please open a new issue against Asterisk 1.8.