[Home]

Summary:ASTERISK-19960: Incorrect data in queue_log, event TRANSFER, field data1
Reporter:vladimir shmagin (shmagin)Labels:
Date Opened:2012-06-05 06:04:01Date Closed:2013-02-19 13:19:18.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:1.8.7.2 1.8.11.1 1.8.13.0 Frequency of
Occurrence		Constant
Related
Issues:
is duplicated byASTERISK-20558 Incorrect TRANSFER entry in queue_log on attended transfer
Environment:The bug was reproduced on Ubuntu 10.4, Debian Squeeze 6.0.0, Centos 6.2 and does not depend on software platformAttachments:( 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:
{noformat}
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 |
{noformat}

queue_log table info:

{noformat}
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    |
{noformat}

Data from log:\\
{noformat}
[May  3 08:53:54] DTMF[6195] channel.c: DTMF begin '#' received on SIP/78114-00013afd
[May  3 08:53:55] DTMF[6195] channel.c: DTMF begin '9' received on SIP/78114-00013afd
[May  3 08:53:55] DTMF[6195] channel.c: DTMF begin '8' received on SIP/78114-00013afd
[May  3 08:53:55] DTMF[6195] channel.c: DTMF begin '0' received on SIP/78114-00013afd
[May  3 08:53:56] DTMF[6195] channel.c: DTMF begin '2' received on SIP/78114-00013afd
[May  3 08:53:56] DTMF[6195] channel.c: DTMF begin '1' received on SIP/78114-00013afd
[May  3 08:53:57] DTMF[6195] channel.c: DTMF begin '#' received on SIP/78114-00013afd
{noformat}

In this case the number +3800238+ instead +98021+ was written in queues_log data1 field.

h4. 2. How to reproduce:

*sip.conf*\\
{noformat}
[general]
[telsip](!)
type=friend
host=dynamic
context=local
disallow=all
allow=alaw
secret=sipsecret
[113](telsip)
[114](telsip)
[115](telsip)
{noformat}

*extensions.conf*

{noformat}
[general]
[local]
exten=>100,1,Queue(testQ,t)
exten=>_11X,1,Dial(SIP/${EXTEN})
{noformat}

*queues.conf*
{noformat}
[general]
[testQ]
strategy = rrmemory
member => SIP/113
member => SIP/114
{noformat}

In *features.conf* change section [featuremap] to the following:
{noformat}
[featuremap]
blindxfer => #1
atxfer => #
{noformat}

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:
{noformat}
1338889351|1338889315.20|testQ|SIP/114|TRANSFER|100|local|4|32|1
{noformat}
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

Uploading patch.