Summary:	ASTERISK-13727: r236981 Attended transfer fails to complete if A calls B, B uses Asterisk atxfer to C, and C picks up before B hangs up
Reporter:	David Brillert (aragon)	Labels:
Date Opened:	2010-01-07 08:17:46.000-0600	Date Closed:	2011-06-07 14:02:48
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_features
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) atxferfailurelog.txt
Description:	Attended transfer fails to complete if A calls B, B uses Asterisk atxfer to C, and C picks up before B hangs up. Screened calls with Asterisk DTMF atxfer are not possible in r236981 ****** ADDITIONAL INFORMATION ****** Full log attached with debug enabled in logger.conf, SIP debug, AGI debug
Comments:	By: David Brillert (aragon) 2010-01-07 08:21:18.000-0600 In the logs A=6002 B=6003 C=6010 6002 calls 6003 6003 invokes atxfer DTMF with *2 enters extension 6010 6010 answers Transfer fails with 6003 hearing "I'm sorry that is not a valid extenson, please try again." By: Leif Madsen (lmadsen) 2010-01-07 10:13:44.000-0600 I think this is a duplicate of another issue... going to try and find it. By: David Brillert (aragon) 2010-01-07 10:43:47.000-0600 leif: you might be talking about ASTERISK-15367 But they don't mention any audible error message just silence... There is an attached patch there which should probably be reviewed. Just the same I don't think it is the same issue. I my case if B hangs up the transfer completes. But if C picks up before B hangs up the transfer fails with audible error from Alison so the screening is not possible in DTMF atxfer. I have partially reproduced the error in ASTERISK-15367 where A does not hear MOH if B hangs up to complete the transfer.  I have not tested the reporters patch. By: Leif Madsen (lmadsen) 2010-01-07 10:52:46.000-0600 Ah possibly. OK, I'm going to mark this as a separate issue. By: Leif Madsen (lmadsen) 2010-01-07 10:53:45.000-0600 Based on the topic, do you mean this to be a regression after the revision you stated? By: David Brillert (aragon) 2010-01-07 10:55:39.000-0600 I have no idea when this broke. I only noticed it while I was running a battery of tests with SVN. By: warlock52 (warlock52) 2010-02-04 09:32:20.000-0600 Is there an SVN version where this specific case is fixed because I upgraded to the Trunk 1.4.29 and it is broken there. I now have R244242 downloaded but do not want to put this into production untill I know if the issue with the transfer is solved with this revision. Somewhere else I read that with trunk 1.4.30 it should be ok but who knows when that will be ready and I need to get attended-transfer back up and running again. I appreciate anyone telling me in which version/revision or patch the above case is fixed? By: Leif Madsen (lmadsen) 2010-02-04 14:39:34.000-0600 Please note that "trunk" is a specific thing, and referring to "1.4.29 trunk" or "1.4.30 trunk" is just wrong. trunk:  it's trunk, where new development happens 1.4, or 1.6.0:  branch <-- branches come from the trunk, just like a tree 1.4.29, or 1.4.30:  release <-- snapshot of a branch in time Not sure exactly which commit *could* have fixed the transfer issue -- 244151 could have fixed it. 'svn log | more' is useful for getting a log of changes. By: Leif Madsen (lmadsen) 2010-02-04 14:43:09.000-0600 Note that the change went in to close issue ASTERISK-15367. Please retest after that revision. By: David Brillert (aragon) 2010-02-05 08:58:25.000-0600 lmadesen: I just installed 244151 and tested my reported scenario and the transfer problem is fixed in this revision.  You can close out this report.