Summary:	ASTERISK-00027: Make attended Call transfer to work with ATA186 too with a simple update of the call transfer function.
Reporter:	dtoma (dtoma)	Labels:
Date Opened:	2003-07-30 07:05:01	Date Closed:	2011-06-07 14:04:56
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When I try to attended transfer a call to an ATA186 user (SIP v1.26), the call is closed when I press on transfer. The reason is that Asterisk tries to close the call and then recall the final destination from the first one. As this is a very short hangup, ATA consider it as "Flash" and then when it is called back, it is busy so the call cannot be initiated. If a one second delay can be entered before the recall is done, then the attended call transfer can work on ATA 186 too.
Comments:	By: Mark Spencer (markster) 2003-08-16 11:03:24 It shouldn't require a hangup.  What device is executing the transfer?  Can you send a call flow? By: dtoma (dtoma) 2003-08-17 11:55:56 It does not depend on the device executing the transfer. Just an example: let's say I have 1xCisco 7960, 1xX-Lite, 1xATA186. This is the flow who can reproduce this behaviour (case 1, when the attended transfer can be made): - I initiate a call from X-Lite to ATA. - ATA Phone answer and then press Flash. - music on hold is hear on X-Lite and dialtone on ATA. - dial to Cisco 7960 - 7960 answer - Hangup ATA - the call on 7960 is hanged up too then imediatelly ring with a call from X-Lite. - You can answer the call and then the transfer is completed. If the final destination is an ATA too, then it cannot be recalled as it is busy (the phone off-hook). You need to close it in order be be able to receive the new call. By: Mark Spencer (markster) 2003-08-24 19:11:18 I don't see any sort of transfer in here.  What am i missing? By: dtoma (dtoma) 2003-08-25 01:55:19 Tried again with the original call from PSTN(X100P), then answer on ATA and try to transfer to the other phone connected to the same ATA. Unattended transfer works (with both Flash and '#', but the attended one don't. When I put the phone in the middle on-hook (after the final one answer), the final one is hang up, but the PSTN remains on MOH till it manually hang. This is a normal behaviour or a bug? By: Mark Spencer (markster) 2003-08-25 08:56:15 I will need a paste of the entire call flow when running with "sip debug" on Asterisk in order to see how the unattended transfer is supposed to work. By: John Todd (jtodd) 2003-09-08 21:26:12 Additional notes: 1) call from ATA -> Voicemail2 (just to test transferring an application) 2) press flash on ATA 3) dial my 7960 4) pick up 7960, call path works fine, blah blah 5) hang up ATA 6) 7960 hangs up At this point, the voicemail2 application is still running.  Both lines have hung up, but apparently voicemail2 is still chugging along, as if the call to the ATA was still alive.  No packets are flowing to the ATA during this "phantom call" post-hangup period. By: John Todd (jtodd) 2003-09-08 21:29:00 PS: I tried the above test with "canreinvite=" set to yes,yes and no,no on both Cisco hosts. By: John Todd (jtodd) 2003-09-08 21:38:00 Not sure if my notes help, but it's the same thing that fhedberg was trying (I think) above. By: fhedberg (fhedberg) 2003-09-14 04:44:07 Sorry for the extra garbage in the sip trace, the u2560099 is the SIP user at hand. By: fhedberg (fhedberg) 2003-09-14 16:08:32 Hmm... Think I missed something. Should the ATA really do a BYE before the REFER? It makes the non-hangup transfer pretty impossible... By: John Todd (jtodd) 2003-09-14 16:56:01 Moving this project to "SIP" where it belongs. By: florian (florian) 2003-10-08 09:41:06 fhedberg: should asterisk try to wait a few milliseconds for a potential REFER to come and handle it gracefully ? I'd very much like to see it behave 'normally' since the ATA is still the cheapest voice gateway around in .nl :-P By: Brian West (bkw918) 2004-01-10 23:52:25.000-0600 This works in ata 3.0 firmware.  I tried it. Worked fine. By: Brian West (bkw918) 2004-01-10 23:52:46.000-0600 Works with 3.0 firmware.