Summary:	ASTERISK-10456: Parked call inherits transfer capability
Reporter:	Ronald Chan (loloski)	Labels:
Date Opened:	2007-10-05 09:56:32	Date Closed:	2008-01-18 11:15:27.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	bug related to 7904 by k-egg but this time from parking lot Incoming call being parked after retrieving the call from the parking lot the caller has now a transfer capability at his/her own will. Dial plan snippet [from-switch] ; All calls from meridian has a prefix of 01+XXXX 4-digit extension ; should be route to a proper destination ; Meridian to Area Office Local Extension exten => _01XXXX,1,Answer exten => _01XXXX,n,NoCDR() exten => _01XXXX,n,Dial(SIP/${EXTEN:2},60,t) exten => _01XXXX,n,Hangup [internal] include => parkedcalls include => outgoing exten => _1XXX,1,Dial(SIP/${EXTEN},60) ****** ADDITIONAL INFORMATION ******  -- Executing [011001@from-switch:1] Answer("SIP/192.168.100.90-0840a250", "") in new stack    -- Executing [011001@from-switch:2] NoCDR("SIP/192.168.100.90-0840a250", "") in new stack    -- Executing [011001@from-switch:3] Dial("SIP/192.168.100.90-0840a250", "SIP/1001|60|t") in new stack    -- Called 1001    -- SIP/1001-08492b40 is ringing    -- SIP/1001-08492b40 answered SIP/192.168.100.90-0840a250    -- Started music on hold, class 'default', on channel 'SIP/192.168.100.90-0840a250'    -- <SIP/1001-08492b40> Playing 'pbx-transfer' (language 'en')    -- Stopped music on hold on SIP/192.168.100.90-0840a250    -- Started music on hold, class 'default', on channel 'SIP/192.168.100.90-0840a250'  == Parked SIP/192.168.100.90-0840a250 on 701@parkedcalls. Will timeout back to extension [from-switch] 011001, 3 in 45 seconds    -- <SIP/1001-08492b40> Playing 'digits/7' (language 'en')    -- <SIP/1001-08492b40> Playing 'digits/0' (language 'en')    -- <SIP/1001-08492b40> Playing 'digits/1' (language 'en')    -- Added extension '701' priority 1 to parkedcalls  == Spawn extension (from-switch, 011001, 3) exited KEEPALIVE on 'SIP/192.168.100.90-0840a250'    -- Executing [701@internal:1] ParkedCall("SIP/1001-084c1c18", "701") in new stack    -- Stopped music on hold on SIP/192.168.100.90-0840a250    -- <SIP/1001-084c1c18> Playing 'beep' (language 'en')    -- <SIP/192.168.100.90-0840a250> Playing 'beep' (language 'en')    -- Channel SIP/1001-084c1c18 connected to parked call 701    -- Started music on hold, class 'default', on channel 'SIP/1001-084c1c18'    -- <SIP/192.168.100.90-0840a250> Playing 'pbx-transfer' (language 'en')    -- Stopped music on hold on SIP/1001-084c1c18  == Spawn extension (internal, 701, 1) exited non-zero on 'SIP/1001-084c1c18'
Comments:	By: Ronald Chan (loloski) 2007-10-05 09:59:26 i forgot to say this applies to URL: http://svn.digium.com/svn/asterisk/branches/1.4 Repository Root: http://svn.digium.com/svn/asterisk Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3 Revision: 84778 Node Kind: directory Schedule: normal Last Changed Author: russell Last Changed Rev: 84742 Last Changed Date: 2007-10-05 09:39:07 +0800 (Fri, 05 Oct 2007) By: k-egg (k-egg) 2007-10-06 07:55:22 sorry for my next words: rofl!! Hope that anybody will be going to work on this issues!! Seems to me that nobody takes this seriously. But this IS a security issue as well! sinc. k-egg By: Ronald Chan (loloski) 2007-10-06 08:25:45 k-egg, yes! i hope this bug will not be set aside like others here, it is really a _security_ issue on my opinion, we must cooperate with them at all cost :), be patient. By: k-egg (k-egg) 2007-10-07 14:47:25 maybe we should make this "feature" a bit more popular... and inform some news groups ahm... what was the default combination for transfer?  *8 ;) By: Sergey Tamkovich (sergee) 2008-01-10 06:10:04.000-0600 This bug is present in 1.4 and in trunk. it resides in builtin_atxfer() so i will upload patches to issue 7904 By: Ronald Chan (loloski) 2008-01-10 06:27:16.000-0600 sergee, yes please, this is really a long standing bug that needs to be fixed :), i will monitor both this and 7904 issue as well By: Terry Wilson (twilson) 2008-01-18 11:15:26.000-0600 This was the same as 7904 since there was no 'T' transfer was involved, so closing as that one has been fixed.