Summary:	ASTERISK-18562: Call Parking Ringback Happens to Caller Channel, Rather Than Parking Party
Reporter:	JoshE (n8ideas)	Labels:
Date Opened:	2011-09-15 11:28:21	Date Closed:	2011-11-02 20:02:29
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Features/Parking
Versions:	1.8.6.0	Frequency of Occurrence	Constant
Related Issues:	is related to ASTERISK-18556 Call parking causes announcment and ringback to caller channel is related to ASTERISK-18557 Call Parking parkinghints = yes doesn't work as expected
Environment:		Attachments:
Description:	Using multiple parking lots with the following config: [general] comebacktoorigin = yes [parkinglot_tenant] context => parkedcalls-tenant parkext => 700 parkpos => 701-704 findslot => first parkingtime => 30 Calls are not delivered back to the party that parked the call, but are instead delivered to the channel that is already parked. So if you park extension 101 from 102, the the ringback will occur on the second appearance of 101 rather than correctly (per my reading of documentation on comebacktoorigin) to 102.
Comments:	By: David Woolley (davidw) 2011-09-15 11:49:26.217-0500 At the time that Park is issued, for a park from a SIP device, the channel being parked should be the second channel (the attended transfer enquiry channel) on the parking device.  The parked call subsequently gets tranferred to the intended parkee, but the number to return to has already been captured at that point. If you do a blind transfer, the identity of the device that requested the transfer has been lost by the time you hit the Park application (which needn't be the auto-generated priority one for extension 700). You can explicitly use the ParkAndAnnounce application, to direct the returned call to any extension. Again, it is working as intended. By: JoshE (n8ideas) 2011-09-15 18:33:00.766-0500 That's all well and good, I suppose.  I have a (sorta) workaround by calling the app this way: Park(${PARKTIMEOUT},from-inside,${DIALED_NUMBER},1,s) DIALED_NUMBER is a variable I capture on all incoming calls which is inherited here.  This functionality suppresses the announcement and puts the call back into the originally dialed number on parking lot timeout. The issue still does affect the use of the default parkext (700, in above features.conf example).  That parkext returns the call on "comebacktoorigin" to the calling party (resulting in a hangup on calls traversing a trunk), which is contrary to what the features.conf.sample documentation suggests should be the case. For people trying to make park work "as designed", they can't have their users hit the parkext to park a call. By: Richard Mudgett (rmudgett) 2011-09-20 16:31:53.946-0500 Note for further investigation: The explanation about Park is correct if Park is actually executed.  For a SIP transfer, Park is not actually going to be executed.  An internal API that behaves like Park is called instead.  Some more investigation is needed to see if something could be done about the behavior. By: Richard Mudgett (rmudgett) 2011-10-17 15:42:19.169-0500 I have replicated your described behavior using: {code} exten => 700,1,NoOp(Park not on first priority) exten => 700,n,Park {code} Blind transferring to this 700 extension exhibits your described symptoms and is expected behavior when the Park application is *executed*.  The Park application *must* be the first priority of a parking extension for a channel driver to invoke special parking procedures.  The Park application is *not actually executed* as a result. You may want to investigate the features.conf parkext_exclusive option added for the v1.8.7 parking fixes.