Summary:	ASTERISK-16323: Parking a call calls out the parked extension on the parked channel - blind transfert on Polycom
Reporter:	Michael Gaudette (bluefox)	Labels:
Date Opened:	2010-07-06 13:37:44	Date Closed:	2011-06-07 14:05:03
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_parkandannounce
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) myDebugLog
Description:	Hi, When parking a call I get the parked extension (eight-zero-zero, for example) on the channel that is being parked, instead of the channel that is parking the call. When the timeout expires, the parked phone calls itself (which make no sense). That only happens on a blind transfert, a normal transfer works correctly. ****** STEPS TO REPRODUCE ****** Two polycom phones calling each other. On the receiving phone, blind transfer into the custom (non-default) parking. Here is the relevant dialplan code: exten => 10,1,noop() exten => 10,n,Set(CHANNEL(parkinglot)=parkinglot_test) exten => 10,n,Park() (So I am transfering blind into extension 10).  You'll hear the called extension into the wrong phone, and after timeout the phone will ring back itself! ****** ADDITIONAL INFORMATION ****** If your curious, it is reasonnable to park a call using a blid transfer even if you don't hear the channel where it is parked under these cirumstances: 1) You have have one parking place 2) You monitor (hints) the parked channel so you have a visual idea of where the call landed.
Comments:	By: Paul Belanger (pabelanger) 2010-07-06 14:43:54 You have posted no debug information (see below) -- We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt By: Michael Gaudette (bluefox) 2010-07-06 14:57:14 Here is the debug lof for one single parked call with the problem By: Michael Gaudette (bluefox) 2010-07-06 14:59:36 I have a system with 1.4.33.1, and its not doing this.  Back around 1.4.26 I reported such an issue, and it was fixed. I do not know if this is relevant or useful, but just in case here it is. By: Leif Madsen (lmadsen) 2010-07-07 09:21:17 What is the issue number of the issue you originally reported that was fixed? By: Michael Gaudette (bluefox) 2010-07-07 10:45:32 I believe that would be 0014066. By: Michael Gaudette (bluefox) 2010-07-13 20:42:02 This is still stuck in feedback, is this a problem or am I misunderstanding the process? By: Leif Madsen (lmadsen) 2010-07-14 13:29:14 The process is manual. Issues get missed. By: Michael Gaudette (bluefox) 2010-07-14 13:32:15 There was no sarcasm in my comment, I figured as much.  Let me know if you need anything more, or if there is a patch to test. I'll test it ASAP. By: Leif Madsen (lmadsen) 2010-07-14 13:39:37 Either was mine. I was just being quick on my comments :) By: Russell Bryant (russell) 2010-08-18 15:03:32 This is not something that can be fixed.  The Park() application is not intended to be used directly like this.  It is doing exactly what is expected. Normally, when executing a blind transfer to a parking extension that was automatically created by the parking code, Asterisk detects this and handles things properly.  When writing it in custom dialplan, Asterisk has no idea that this transfer is for parking the call. By: Michael Gaudette (bluefox) 2010-08-19 09:49:51 Hi, Sorry to reopen this, but I want to test and make sure this is all working as intended.  How is parking then intended to work with multiple parking lots? As for as I understood I though I needed to use the Park() app to redirect the parked call to the correct parking lot. I will make sure I test it under the same conditions are I did with my custom dialplan to check whether blind xfer and normal xfer work as intended. Call is an excess of zeal if you will, testing helps Asterisk get better in the long run. By: Michael Gaudette (bluefox) 2010-08-25 13:19:06 Just as an add-on information/question, is  something that worked on 1.4 and doesn't anymore on 1.6 considered a regression bug? By: Michael Gaudette (bluefox) 2010-09-10 14:11:34 Hi, I am truying to know how I can test the system the way it was intended to be used.  This, to me, seems like a regression, since it works fine with 1.4.  But I'm willing to test out the system the way it was meant to be used (according to russell) if I only knew how. I believe I am using the system as intended, but I'll be glad to be showed wrong By: Russell Bryant (russell) 2010-09-13 11:15:06 To configure multiple parking lots, you define it in features.conf (including a context associated with it).  Then, you include that context in your dialplan just like you would include the parkedcalls context previously. By: Michael Gaudette (bluefox) 2010-09-13 11:25:24 Sorry if this is turning into a how-to, but how would one go about doing what you suggest under this scenario: - Every phone, regardless of the parking lot, has the same context for SIP registration - The dialplan is DB driven (key words) and when parking a call, the dialplan calls the cmd Park(${some-db-driven-variable}-parkinglot) is used. i.e : Park(sales-parkinglot).  But I don't know which parking lot when writing the dialplan, since I get this at call time from a database. It works wonderfully well with 1.6 (but not with blind transfers), and the concept works with 1.4 (although there is a single parking lot, so it's not actually useful) Is Park a cmd which will be deprecated in this case, since it isn't meant to be used? By: Leif Madsen (lmadsen) 2010-09-13 11:29:58 Even if it was deprecated, that just means there is an alternative to using it (which in this case appears to be "don't use it"). Deprecated does not mean "removed" from Asterisk. At this point your questions should probably be directed to the asterisk-users list.