Summary:	ASTERISK-19296: Attended transfer and hangup events
Reporter:	Thomas Sevestre (to)	Labels:
Date Opened:	2012-02-02 10:00:05.000-0600	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	Features
Versions:	1.8.9.0 13.18.4	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	Say we have 3 users with extensions 100, 101 and 102 100 call 101 101 answers and use the attended transfer features to call 102 101 hangup before 102 answers => The hangup event (AMI) is not fired immediately (it is fired when 102 answers) Edit: With atxferdropcall=yes and the same scenario as above, the bridge between 100 and 101 lingers after 101 hangs up until either 102 answers or atxfernoanswertimeout expires.  There is no need for the 100 to 101 bridge to remain once 101 hangs up in this case.  The call to 102 should immediately transfer to 100 in this case.
Comments:	By: Richard Mudgett (rmudgett) 2012-02-02 11:34:32.867-0600 Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need: 1. the specific steps or actions you took that caused you to encounter the problem, 2. the behavior you expected, and 3. the behavior you actually encountered (in as much detail as possible). This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks! You did not specify which method you are using to transfer the call. Based on your wording I am guessing you are using the DTMF initiated transfers in features.conf.  You likely need to look at the atxferdropcall option and set it to yes. By: Thomas Sevestre (to) 2012-02-02 12:30:31.730-0600 Thanks for your quick answer. Indeed, I'm using DTMF initiated attended transfers in features.conf. atxferdropcall is not what I want. Let's give it anther try! If I'm not clear enought, I'll build a sample configuration. sip.conf look like this for each user: [100] type=friend defaultuser=100 context=default host=dynamic call-limit=2 extension.conf looks like this: [default] exten => _X., 1, Dial(${EXTEN},30,tT) exten => _X., 2, Hangup(16) And the detailed scenario is: 100 calls 101 with the Dial application with the options 'tT' 101 answers 101 does an attended transfer with DTMF (*2 then 102) 101 hangs up before 102 answers at the very moment 101 hangs up, I have these logs in the CLI (log level = 3) [Feb  2 17:28:10] DEBUG[2342]: chan_sip.c:3070 sip_alreadygone: Setting SIP_ALREADYGONE on dialog 4e48d7e87051902715178a213becfac2@__OBFUSCATED__:5060 [Feb  2 17:28:10] DEBUG[2342]: res_rtp_asterisk.c:2487 ast_rtp_remote_address_set: Setting RTCP address on RTP instance '0xb68b52c0' [Feb  2 17:28:10] DEBUG[2342]: chan_sip.c:23712 handle_request_bye: Received bye, issuing owner hangup ... but no AMI event is fired. I'd like to have a Hangup event on the channel SIP/101-xxxx since the channel is not up anymore. The event should be fired at the very moment 101 hangs up (before 102 answers on the timeout is reached) By: Richard Mudgett (rmudgett) 2012-02-02 13:30:03.515-0600 I think the wording in features.conf.sample needs to be improved for the atxferdropcall option. The DTMF features take place *inside* the call bridge.  When atxferdropcall is no, the bridge will stay active until the transfer is completed even though 101 has "hung up".  The transfer is not completed until 102 answers or 101 gets called back.  This is why you don't get the AMI hangup event to the original call to 101 when you expect.  When atxferdropcall is yes, the transfer completes as soon as 101 hangs up and the bridge is disconnected. By: Mark Petersen (roadkill) 2012-04-18 04:24:00.120-0500 ? can this be related to ASTERISK-16340 "[patch] After a blind transfer by the calling party the transferees peer cannot be dialed again within the same call" By: Richard Mudgett (rmudgett) 2012-04-18 09:21:58.568-0500 No.  This is a documentation only issue because of a misunderstanding of how DTMF transfers operate. By: Thomas Sevestre (to) 2012-05-03 10:44:18.552-0500 When atxferdropcall is yes, should I get an event as soon as 101 hangs up? If yes, it doesn't work. I don't know how to build clean patch but I guess the behavior of set_kill_chan_tech should be improved. By: Richard Mudgett (rmudgett) 2012-05-03 12:12:34.741-0500 Looks like you found something.  There is no reason for the bridge between 100 and 101 to hang around if atxferdropcall=yes and 101 hangs up before 102 answers.  The current code will wait for 102 to answer or the atxfernoanswertimeout before actually transferring 100 to 102 and breaking the bridge between 100 and 101. By: Gabriel Ortiz Lour (elbriga) 2013-11-08 07:47:24.162-0600 Hello, is there any progress on this issue? I also would appreciate receiving the HangUp event when 101 hangup. Anything new/different on some new version? By: Richard Mudgett (rmudgett) 2013-11-08 11:30:02.751-0600 Your issue is in queue, please be patient, and we will get to it as time permits and developer resources become available. The DTMF transfer code was redesigned as part of the bridging architecture improvements in Asterisk v12.  It should not have this problem. Asterisk v12 is in Beta at this time. By: Thomas Sevestre (to) 2017-07-21 09:38:07.192-0500 I've tested with the latest 13 version, the behavior is still the same. The new AttendedTransfer event is fired at the right moment. It is easy to emulate the hangup event.