|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|
|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
6002 calls 6003
6003 invokes atxfer DTMF with *2 enters extension 6010
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.