Summary:	ASTERISK-11648: res_features.c don't return calls to the [park-call] "t" extension. when the extension is busy and the parktime occurs
Reporter:	Jorge Eduardo Silva Jackson (edusilva)	Labels:
Date Opened:	2008-03-15 11:33:13	Date Closed:	2011-06-07 14:07:24
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_features
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) comebacktoorigin_1_4_13.diff
Description:	When I send calls to parkinglot, and the timeout occurs, the parked call return to the park generator exten. When it's busy the channel on park hangup. I thing, the call should return to [park-call] "t" exten when it occurs. ****** STEPS TO REPRODUCE ****** 1 - Call to user ej: SIP/polycom 2 - Answer the call 3 - Park the call 4 - Hangup 5 - Wait while timeout occurs with exten busy. 6 - On timeout the callee is hangup.
Comments:	By: David Woolley (davidw) 2008-03-15 12:12:41 What happens when it returns (excepting ParkAndAnnounce) is that it dials the base name of the requesting channel.  If that only supports one call,and is already in a call, yes it will be busy and the call will fail!  In my view, therefore, it is doing all that is reasonably possible. I see two possibilities here: 1) you change this to a feature request and specify the behaviour more precisely, e.g. what happens to the call that made the line busy. 2) you park the call in such a way that the parker is a queue and the line you want to return to is a member of that queue. Also note that, if you can arrange to use ParkAndAnnounce, the call is returned to dialplan logic and that may open up your options. Moreover, unless you use ParkAndAnnounce, the call is not returned to an extension in the sense that Asterisk uses the word, It is returned to an app_dial string, i.e. the sort of thing that you put in the first parameter of the Dial() application. (I'm just learning exactly how Park works, so I hope I haven't exceeded the limits of my understanding.) By: Jorge Eduardo Silva Jackson (edusilva) 2008-03-17 07:52:25 ParkAndAnnounce is not the solution for me. I think that if the caller is hangup without reason, it is a mistake. Think this: 1 - Your call me 2 - I park the call 3 - I call other people to be able to solve your problem 4 - Much delayed, the parked call (your call) is hangup. 5 - Your stay angry. I think this is a bug. I can't apply de patch for use "comebacktoorigin=no" (http://bugs.digium.com/view.php?id=6953), because I work with 1.4.xx and this patch is for 1.2.xx. I Modify res/features.c by hand and now it's working, but I think it's (or other solution) should be included in official releases. Regards. EDU By: David Woolley (davidw) 2008-03-17 08:45:24 I would say that this was definitely a feature request and not a bug.  As a feature request, I think it needs specifying much more precisely. Also, it appears that the function you want is Hold, not Park.  Asterisk does support Hold initiated from a SIP phone, with enqiries taking place on an alternative channel to the phone (typically represented, by the phone, as being a second line). Moreover, the classic way of doing the sequence you describe, on even mechanical relay based PABXes, is to start an attended transfer and then abandon the transfer to regain the original caller.  I haven't personally tried this with Asterisk, but I believe it works and I believe there is no timeout on the hold for attended transfer initiated by using feature codes (SIP attended transfers actually hold the call and start a second "line" for the enquiry, so Asterisk would never perceive a transfer in that case, just an indefinite  Hold.) The classic use of Park is when you want to transfer the call to another nearby phone, but you don't know the extension number.  You either park then walk over to the phone, and retrieve, or you shout to someone else to retrieve it. If you do want to proceed with the current issue, whether or not you accept that it is really a feature request, you need to say how you parked the call (there are at least 5 variants that I can think of, although it sounds like you may be doing a non-SIP transfer to the parking extension or a dialplan entry that uses Park()).  You also need to specify what happens to the call when it times out.  Note that Asterisk doesn't seem to have a camp on busy primitive, so that would have to be simulated with higher level functions, if it is what  you want. By: Joel Vandal (jvandal) 2008-03-17 09:20:10 Why not add something like this on dialplan and customize it to specify the destination on busy/no answer : [park-dial] exten => _.,2,GotoIf($["${DIALSTATUS}" = "ANSWER"]?3:4) exten => _.,3,Hangup() exten => _.,4,Dial(${EXTEN}) By: Clod Patry (junky) 2008-03-17 15:00:48 there's already an option in 1.6 for that need. do you want a patch for 1.4? I already ported 6953 to 1.4. By: Jorge Eduardo Silva Jackson (edusilva) 2008-03-17 18:30:41 Yes, I want this patch. :) Can you upload here ? Regards. By: Clod Patry (junky) 2008-03-17 18:41:53 there you go for the patch for 1.4.13 (should be almost the same for 1.4.15) By: Jorge Eduardo Silva Jackson (edusilva) 2008-03-17 18:52:11 Ok !!! I will test it tomorrow Lot of Tks. By: David Brillert (aragon) 2008-03-18 12:52:45 This park timeout>busy>disconnect drives me crazy too. Junky? What behavior does this patch change? What happens to the parked caller when the extension is busy... Can the patch be applied to 1.4.19? By: Clod Patry (junky) 2008-03-18 13:54:31 aragon: read ASTERISK-6769 . All informations are there. Also, yes the patch ( comebacktoorigin_1_4_13.diff ) applies to 1.4.19-RC3. By: Jorge Eduardo Silva Jackson (edusilva) 2008-03-18 20:03:11 Yes, it's work fine. Tks a lot Junky. By: Clod Patry (junky) 2008-03-18 20:57:42 aragon: can you confirm it works for you too? So I can close that bug. By: David Brillert (aragon) 2008-03-19 18:18:18 I plan to test this tomorrow By: Jason Parker (jparker) 2008-03-20 12:11:57 Per junky, there is already a similar feature in trunk/1.6.  As this is not a bug, I am closing this report.