QM sometimes missing hangup for outbound calls since upgrade Asterisk 11 to 13.

QueueMetrics > Running QueueMetrics

(1/1)

cwstevens:
Hello. We upgraded from Asterisk 11.6-cert9 to Asterisk 13.1-cert2 and, to resolve the AMI connection issues we upgraded Queuemetrics 14.06.2 to 15.02.2. We have started to see outbound calls sometimes being seen as ongoing forever in the Realtime page and we never experienced this prior to the upgrade.

We upgraded two locations on 4/25. I have had to cut one ongoing outbound call on one system and two ongoing outbound calls on the other. This does not always happen as both systems make many outgoing calls.

We are using qloader.pl 1.29 to populate the MySQL database. I have made sure that all of the records appear in the MySQL queue_log table and I compared records from before the upgrade and they look identical. Here is an example:

Before upgrades:
# partition, time_id, call_id, queue, agent, verb, data1, data2, data3, data4, data5, serverid, unique_row_count
P001, 1429931596, system-name-1429931489.57245, outbound, Agent/6111, COMPLETEAGENT, 12, 95, , , , , 1
P001, 1429931501, system-name-1429931489.57245, outbound, Agent/6111, CONNECT, 12, , , , , , 1
P001, 1429931489, system-name-1429931489.57245, outbound, Agent/6111, CALLOUTBOUND, , 2345671234, , , , , 1

After upgrades:
# partition, time_id, call_id, queue, agent, verb, data1, data2, data3, data4, data5, serverid, unique_row_count
P001, 1430188108, system-name-1430188016.8627, outbound, Agent/6111, COMPLETEAGENT, 19, 73, , , , , 1
P001, 1430188035, system-name-1430188016.8627, outbound, Agent/6111, CONNECT, 19, , , , , , 1
P001, 1430188016, system-name-1430188016.8627, outbound, Agent/6111, CALLOUTBOUND, , 15555551234, , , , , 1

I do not see a difference in the format of the log but there still seems to be a problem. Both systems have been running Asterisk/QM for nearly 2 years and this is the first time we have ever seen ongoing calls. Any help/suggestions would be appreciated. Thank you.

cwstevens:
The "After Upgrades" is an actual call that I had to cut from the Realtime page. QM said the call was almost 900 minutes long before I stopped it. Thank you.

cwstevens:
We have experienced this again. I did more digging and this looks to have something to do with the agent performing an attended transfer. Here is a log example:

--- Code: ---1430255507|system-name-1430255480.13833|dispatch|NONE|ENTERQUEUE||1234561234 CALLER NAME|1
1430255511|system-name-1430255480.13833|dispatch|local/5106@agents|CONNECT|4|system-name-1430255507.13849|3
1430255550|system-name-1430255550.13875|outbound|Agent/6151|CALLOUTBOUND||15551231234|
1430255555|system-name-1430255480.13833|dispatch|local/5106@agents|ATTENDEDTRANSFER|APP|Dial|4|44|1
1430255571|system-name-1430255550.13875|outbound|Agent/6151|CONNECT|21||
1430255712|system-name-1430255480.13833|outbound|Agent/6151|COMPLETEAGENT|21|141|
--- End code ---

The original call answered by the agent is uniqueid "system-name-1430255480.13833" and has the corresponding COMPLETEAGENT. The outbound call is uniqueid "system-name-1430255550.13875" but never has a final COMPLETEAGENT. These are the calls that are showing as ongoing in Realtime. Does anyone have any suggestions? Thank you.

cwstevens:
We can reproduce this problem with the following steps:

1. Agent answers inbound call.
2. Agent places new outbound call.
3. Agent waits for called number to ring then does transfer from the phone before the called party answers.

The outbound call only reaches the "macro-queuedial-answer" macro from the Dial in "qm-queuedial" in extensions_queuemetrics.conf. The call never goes back to the "qm-queuedial" context and the "h" exten.

All other types of transfer is working correctly. Blind transfer or waiting for the called party to answer for an attended transfer is ok.

Does anyone have any ideas? Loway, do you have any suggestions? Thank you.

Navigation

[0] Message Index

Go to full version