|Summary:||ASTERISK-13725: Attended transfer is not working correctly|
|Reporter:||Marcos Jose Setim (msetim)||Labels:|
|Date Opened:||2009-03-10 17:00:11||Date Closed:||2011-06-07 14:07:53|
|Environment:||Attachments:||( 0) logdebug.txt|
Agent receive a call and try to transfer to an extension (e.g 5000) however sometimes the call get back to it after user has pressed first DTMF (appear that it is not respecting DTMF between digits). It's a randomly problem and we are trying to figure out why this happen.
We are analyzing the problem and we detect that sometimes log full show that res_features.c (did not read data).
I test this patch: http://bugs.digium.com/view.php?id=14374 however it doesn't correct the issue.
My version is 22.214.171.124 with patch 14374.
I hope that log helps. I'm to be available to help but I need some directions.
Asterisk version and Category are mandatory and I can't see the correct values for it.
****** ADDITIONAL INFORMATION ******
Debug capture: http://pastebin.com/m73d91396
|Comments:||By: Marcos Jose Setim (msetim) 2009-03-11 06:49:33|
I'm attaching log debug in replace of pastebin link. Looking for correction we found this bug http://bugs.digium.com/view.php?id=14515 It appear to be related with our problem.
By: Mark Michelson (mmichelson) 2009-03-11 10:58:24
If you apply the patch on issue ASTERISK-13615, does it fix your problem?
By: Denis Galvao (denisgalvao) 2009-03-11 12:19:22
The patch 0014515 does not apply correctly on 126.96.36.199.
wget 'http://bugs.digium.com/file_download.php?file_id=21769&type=bug' -O - | patch -p0
Resolvendo bugs.digium.com... 188.8.131.52
Connecting to bugs.digium.com|184.108.40.206|:80... conectado!
HTTP requisição enviada, aguardando resposta... 200 OK
Tamanho: 913 [text/plain]
100%[==============================================================================================================>] 913 --.--K/s
12:19:41 (165.50 MB/s) - `-' saved [913/913]
patching file res/res_features.c
Hunk #1 FAILED at 1726.
1 out of 1 hunk FAILED -- saving rejects to file res/res_features.c.rej
By: Denis Galvao (denisgalvao) 2009-03-11 13:50:26
Ok,patch applied, but without success.
I tried 1.4.24-rc1, same problem.
The scenario is bellow:
A call B
B do a att transfer do C
A is on hold
B try to cancel with #0 to call back A
A unhold and bridged again with B
B try to do an att transfer again but it fails
B receive beeperr and cant do a second transfer
Even not trying to cancel with #0, just waiting for timeout give us the same result.
By: Marcos Jose Setim (msetim) 2009-03-11 18:41:30
By the way #0 is the disconnect feature from features.conf
By: Steve Murphy (murf) 2009-03-12 10:13:01
Well, this is related to 14515, and in that bug I noted that you can't use
the disconnect feature codes during the transfer (you aren't bridged at the time,
and the code isn't written to respond to those sequences.
But, ignoring that, when you time out and then... could this be one of those bridge-config-getting-lost sorts of issues?
I've been unassigned from my bugs, no longer working at digium, but I spotted the update in my email, and couldn't help throwing in a guess... Sorry!
By: Marcos Jose Setim (msetim) 2009-03-12 11:41:35
Thank you for your answer. Disconnect always work for me on attended transfer because there are bridged channel. Example:
A call B
B do attended transfer to C
A channel go to hold
B channel call to C and is bridged
B talk to C (do you like to get this call?)
B press disconnect code (#0 in my case)
C is bridged to B
A = PSTN Line number
B = an agent
C = third person
Do you think that We need to update 14515 ticket or continue working on this?
What do you mean with "bridge-config-getting-lost sorts of issues"?
By: Denis Galvao (denisgalvao) 2009-03-16 08:47:05
Is there an update here?
By: Leif Madsen (lmadsen) 2009-08-20 16:35:41
Since this issue is quite old now, any chance of the reporter re-testing with the latest version of Asterisk from SVN? Thanks!
By: Leif Madsen (lmadsen) 2009-09-22 08:26:46
Closing this issue due to lack of response from the reporter. I can only assume updating to a newer version has resolved this issue, or has resolved the issue some other way.