[Home]

Summary:ASTERISK-16280: [regression] DTMF transfers stop working for queue agents idle > 5 minutes
Reporter:Max_cnu (maxochoa)Labels:
Date Opened:2010-06-22 11:33:09Date Closed:2010-07-05 08:10:21
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 1.4.33.1-valgrind-console.txt
( 1) agents.conf
( 2) asterisk-queue_dtmf-configs.tar
( 3) extensions.conf
( 4) queues.conf
( 5) valgrind-1277223141.txt
( 6) valgrind-1277319514-1.4.33.1.txt
Description:Starting in asterisk 1.4.31 and reproducible with asterisk 1.4.33, if an agent logs into a queue, takes at least one call, and then sits idle for 5 minutes, most of the time, on the next call taken, DTMF to transfer the call or hangup the call no longer works.

****** ADDITIONAL INFORMATION ******

Debian 5.0.4 with most recent updates. Sometimes the problem occurs when taking a call, waiting 5 minutes, taking a second call (transferring it), waiting 5 minutes, and then attempting to transfer the third call (DTMF transfer fails.)
Comments:By: Leif Madsen (lmadsen) 2010-06-23 11:09:48

It would really be best if the configuration and logging of this issue were attached as plain text files and not as archives.
By: Leif Madsen (lmadsen) 2010-06-23 11:16:31

I think we're going to have to get someone else to verify this happens, because it seems quite improbable for this to have happened (not impossible, just improbable).

If you go back to 1.4.30 on the exact same machine, does the problem go away? Can you track down which commit may have introduced this?

I'm hesitant to move this forward unless someone else can verify this behaviour.
By: Max_cnu (maxochoa) 2010-06-23 14:46:32

Testing on the same machine using 1.4.30, I was not able to reproduce the problem after 3 agent logins, 5+ calls each, waiting 5-10 minutes between calls. Testing with 1.4.33.1, I was able to reproduce the problem after waiting 30 minutes without taking a call. Attached is the console from and valgrind log from the event.
By: Vinuraj (vinurajk) 2010-06-27 04:50:26

I had this very same issue when  I upgraded asterisk from 1.4.21.2 to 1.4.31 and then to 1.4.33 (ticket no :17533) . In both these versions , I had the same issues with transfers . I am downgrading it to 1.4.30 tonight to see if it fixes transfer issue. Will update this ticket with details .
By: Vinuraj (vinurajk) 2010-06-28 17:49:17

Just to let you all know , I can confirm that transfers are working properly in 1.4.30 .
By: Evandro César Arruda (ecarruda) 2010-06-28 23:54:12

I checked, don't have any alteration in this versions, just has filename changed added, queue event updated and added member field and on the1.4.33 we can see the update to add noanswer on cdr.

We will need to see on locks or something like that lmadsen.

I has this versions on my lab because i'm customizing somethings on other issues, i will create some log messages to debug thsi process and i will put a complete feedback about that.

Thanks people
By: Max_cnu (maxochoa) 2010-07-02 09:43:03

Pretty sure this issue is more appropriately represented by issue 17571. dtmfmode in our setup is set to use RFC2833 throughout.
By: Paul Belanger (pabelanger) 2010-07-05 08:10:20

Closing as a duplicate of ASTERISK-1733571; please try the patch in that issue.