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-0600Date Closed:2011-06-07 14:02:48
Versions:Frequency of
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


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
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.