|Summary:||ASTERISK-19960: Incorrect data in queue_log, event TRANSFER, field data1|
|Reporter:||vladimir shmagin (shmagin)||Labels:|
|Date Opened:||2012-06-05 06:04:01||Date Closed:||2013-02-19 13:19:18.000-0600|
|Versions:||18.104.22.168 22.214.171.124 126.96.36.199||Frequency of|
|Environment:||The bug was reproduced on Ubuntu 10.4, Debian Squeeze 6.0.0, Centos 6.2 and does not depend on software platform||Attachments:||( 0) queue_log_transfer_data1.diff|
|Description:||h4. 1. Description:|
That bug was reported earlier in Asterisk 1.6: ASTERISK-16012
Unfortunately the problem persists in 1.8 branch.
Here we give more detailed information.
cdr table info:
mysql> select src,dst,lastdata,lastapp from cdr where accountcode='1336020803_55160';
| src | dst | lastdata | lastapp |
| 78114 | 3800238 | (Outgoing Line) | AppQueue |
| 88123208925 | 3800238 | KC01,t,,,1800 | Queue |
| 88123208925 | 3800238 | Local/98021@sip_kc1-dc0e;1 | Transferred Call |
queue_log table info:
mysql> select queuename,event,data1,data2,data3,data4 from queue_log where
substr(time,1,16)='2012-05-03 08:53' and callid like '1336020803%' and queuename='KC01';
| queuename | event | data1 | data2 | data3 | data4 |
| KC01 | ENTERQUEUE | | 88123208925 | 1 | |
| KC01 | CONNECT | 11 | 1336020814.90200 | 10 | |
| KC01 | TRANSFER | 3800238 | KC01 | 11 | 14 |
Data from log:\\
[May 3 08:53:54] DTMF channel.c: DTMF begin '#' received on SIP/78114-00013afd
[May 3 08:53:55] DTMF channel.c: DTMF begin '9' received on SIP/78114-00013afd
[May 3 08:53:55] DTMF channel.c: DTMF begin '8' received on SIP/78114-00013afd
[May 3 08:53:55] DTMF channel.c: DTMF begin '0' received on SIP/78114-00013afd
[May 3 08:53:56] DTMF channel.c: DTMF begin '2' received on SIP/78114-00013afd
[May 3 08:53:56] DTMF channel.c: DTMF begin '1' received on SIP/78114-00013afd
[May 3 08:53:57] DTMF channel.c: DTMF begin '#' received on SIP/78114-00013afd
In this case the number +3800238+ instead +98021+ was written in queues_log data1 field.
h4. 2. How to reproduce:
strategy = rrmemory
member => SIP/113
member => SIP/114
In *features.conf* change section [featuremap] to the following:
blindxfer => #1
atxfer => #
Restart Asterisk and make call from phone 115 to extension 100. Answer with phone 114 and press #113. After transfer you obtain the following record in queue_log:
Although there must be 113 instead of 100.
That bug spoils our statistics. I beg you to fix it. Thank you in advance!
|Comments:||By: Steven Davis (davissteve80) 2012-06-15 11:27:32.455-0500|
We see this problem as well. Matches this explanation exactly.
By: Ian M Sherman (shermster) 2013-01-15 09:28:21.333-0600
I've also had this issue with Asterisk attended transfers logging the queue number instead of the extension to which the call was transferred to. A fix for this would be very useful
By: Kevin Harwell (kharwell) 2013-02-19 13:14:43.603-0600