Summary:	ASTERISK-06789: attended transfer feature - calls getting lost
Reporter:	Thomas Artner (tommy)	Labels:
Date Opened:	2006-04-15 12:20:53	Date Closed:	2011-06-07 14:08:23
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The attended transfer feature has the following bad behaviour: .) Person A gets a call and wats to transfer it to Person B .) Person A presses the atxfer feature button and the extension number .) Person A decides not to wait for Person B taking the call, and hangs up the telephone At this point the attended transfer will be cancelled and the caller is lost. This is a very unusual and nearly unusable behaviour. As diskussed many times on the asterisk-user list, the caller should never get lost. If Person A hangs up before Person B takes the call, the attended transfer should go into a blind transfer. The following behaviour of a call transfer might be that what everybody would expect: .) Press the atxfer feature access key .) Dial the extension for the transfer .) Either hang up or stay on the line .) If you stay on the line the transfer completes when you hang up after talking to the person who receives the transferred call .) If you hang up during the ring the call is blind transferred .) If you press the same feature access key (#) again you get the call back and terminate the transfer. After a lot of discussions on the mailing list this would be the best behavior of call transfering. The cheapest PBXs on the market supports this style of call transfer, and hopefully asterisk will do this in the same way in the near future.
Comments:	By: Jan-Peter Koopmann (jkoopmann) 2006-04-16 03:22:38 I second this. I have read the last few discussions on this and I know there is attended and unattended call transfer etc. Nevertheless this is a problem for the regular user since all PBX known to me behave differently. In order to make the transition from a regular PBX to Asterisk smoothly this needs to be addressed. In order for this to work one would probably have to make sure that Asterisk stays in the call/media path. By: jayel (jayel) 2006-04-16 11:53:47 I moved a few small companies from regular PBXs to asterisk, and there are some problems with this different kinds of call transfers. And after spending a lot of money in digium cards, it is hard to explain why  asterisk isnt able to handle the transfers like a regular PBX does. My company might  spend a few bucks if it would help to get this issue fixed in a shorter time! By: mimmo (mimmo) 2006-04-18 08:19:49 I agree. A 'better' call transfer is absolutely required to use Asterisk in a traditional context. In my opinion, especially attended/unattended differentiation is absolutely foolish. To be "typical" it would act like this: - Press pound to get secondary dial tone - Dial the number for the transfer - Either hang up or stay on the line after progress (ring) If you stay on the line the transfer completes when you hang up If you hang up during the ring the call is blind transferred If you press the same feature access key (#) again you get the call back and terminate the transfer By: Serge Vecher (serge-v) 2006-05-04 14:05:15 due to the crunch of an impending 1.4 release, I believe the best course of action is for interested parties to post a bounty on wiki. This is standard procedure for all feature requests not immediately picked up by a developer. Thanks By: Olivier Krief (okrief) 2006-05-04 14:54:38 This feature is a move in the right direction. Would it be hard to implement it ? By: Serge Vecher (serge-v) 2006-05-04 15:07:09 it undoubtedly is. However, the change is not trivial, as evidenced by a lack of developer attention. Unfortunately, the bugtracker is not a good venue for feature requests without code to support them. It is a long standing policy to close feature requests in the BT when no patches are produced. I will wait until Monday for the patch to appear. If not, the issue will be suspended until the bounty is picked up or a patch produced by other means. Thanks. By: Serge Vecher (serge-v) 2006-05-12 11:42:29 Please feel free to reopen the bug when a patch implementing the feature request is available. Thanks.