QueueMetrics > Running QueueMetrics
FreePBX(AsteriskNow) transfer
QueueMetrics:
QM would happily process that correctly :)
moa:
;D
It can be done!
Since it is close to impossible to find any decent information on this. I'm going to explain how I solved it here.
*Warning* This may be a lengthy post, so to keep it short I've taken out anything that doesn't pertain to this issue in my dialplan. Also, all dialplan will be in AEL syntax.
First off, in order to successfully accomplish this we need a few channel variables that aren't in the new transferred channel. We need the AgentID, the asterisk Call ID, and our Queue the call is coming from.
In my setup, when a call comes in, I'm setting two inherent channel variable:
--- Code: ---context queues-inbound{
XXXX =>{
Set(_CALLID=${UNIQUEID});
Set(_QUEUENAME=test);
Queue(test,t);
}
}
--- End code ---
Now my agents are logged into the queues via local channels:
--- Code: ---queues*CLI> queue show test
test has 0 calls (max unlimited) in 'leastrecent' strategy (3s holdtime, 96s talktime), W:0, C:12, A:4, SL:100.0% within 120s
Members:
local/1234@agents/n with penalty 1 (realtime) (Not in use) has taken no calls yet
--- End code ---
When the agent is dialed another inherent variable is set:
--- Code: ---context agents {
_. => {
Set(_AGENTTHATTRANSFERED=${EXTEN});
...
// doing a mysql database lookup to get Agents SIP Extension
...
Dial(SIP/${AGENT_EXTENSION});
}
}
--- End code ---
Hope everyone is following thus far. Just a few more steps ;)
Here is what the queue_log looks like at this point:
--- Code: ---+---------+------------+------------------+-----------+-------------------+---------------+------------------------------+
| id | time | callid | queuename | agent | event | data |
+---------+------------+------------------+-----------+-------------------+---------------+------------------------------+
| 1194627 | 1289929044 | 1289929028.30773 | test | NONE | ENTERQUEUE | |XXXXXXXXXX_1289929028.30773 |
| 1194629 | 1289929048 | 1289929028.30773 | test | local/1234@agents/n| CONNECT | 4|1289929045.30777|3 |
--- End code ---
I've instructed our agents to use a specific line extension when transferring. For this example, I'm going to use line 6.
--- Code: ---context agents-transferred {
_6. => {
NoOp("Current UniqueID: ${UNIQUEID}");
NoOp("inherited callid: ${CALLID}");
NoOp("inherited agendid: ${AGENTTHATTRANSFERED}");
NoOp("inherited queuename: ${QUEUENAME}");
MYSQL(Connect connid localhost UN PW asterisk_database);
if(${connid} = ""){
Playback(tt-error);
Hangup();
}else{
// make the query to track it
MYSQL(Query resultid ${connid} INSERT into transferred_calls(callid,full_extension) values('${CALLID}','${EXTEN}'));
// disconnect
MYSQL(Disconnect ${connid});
// now enter in our queue log
QueueLog(${QUEUENAME},${CALLID},local/${AGENTTHATTRANSFERED}@agents/n,TRANSFER,${EXTEN:1});
// dial the transferred extesion
Dial(SIP/${EXTEN:1});
};
if(${connid}){
MYSQL(Disconnect ${connid});
};
Hangup();
};
}
--- End code ---
Now once the call gets to here. Here is what the queue_log looks like (agent transferred to sip extension 299):
--- Code: ---+---------+------------+------------------+-----------+-------------------+---------------+------------------------------+
| id | time | callid | queuename | agent | event | data |
+---------+------------+------------------+-----------+-------------------+---------------+------------------------------+
| 1194627 | 1289929044 | 1289929028.30773 | test | NONE | ENTERQUEUE | |XXXXXXXXXX_1289929028.30773 |
| 1194629 | 1289929048 | 1289929028.30773 | test | local/1234@agents/n| CONNECT | 4|1289929045.30777|3 |
| 1194642 | 1289929161 | 1289929028.30773 | test | local/1234@agents/n | TRANSFER | 299 |
--- End code ---
QueueMetrics is happy at this point. Transferred calls are calculated correctly.
But wait
Here's what the queue_log looks like AFTER the transferred call is completed:
--- Code: ---+---------+------------+------------------+-----------+-------------------+---------------+------------------------------+
| id | time | callid | queuename | agent | event | data |
+---------+------------+------------------+-----------+-------------------+---------------+------------------------------+
| 1194627 | 1289929044 | 1289929028.30773 | test | NONE | ENTERQUEUE | |XXXXXXXXXX_1289929028.30773 |
| 1194629 | 1289929048 | 1289929028.30773 | test | local/1234@agents/n| CONNECT | 4|1289929045.30777|3 |
| 1194642 | 1289929161 | 1289929028.30773 | test | local/1234@agents/n | TRANSFER | 299 |
| 1194650 | 1289929253 | 1289929028.30773 | test | local/1234@agents/n | COMPLETEAGENT | 5|204|1 |
--- End code ---
QueueMetrics doesn't like this because of the last entry(COMPLETEAGENT). So if you see above where I created my own database table called transferred_calls and placed the transfer information into it(agents-transferred context). I have a cronjob running every 5 minutes to check this table for anything new, if there is a new transferred call. It grabs the callid and deletes the offending row out of the queue_log.
QueueMetrics is happy, boss is happy, customers are happy!
This is currently working in my lab and I'm about to push it all into production.
Please comment and let me know what everyone thinks. Suggestions, bug fixes, and typo's are all welcome.
QueueMetrics:
--- Quote from: moa on November 16, 2010, 19:36:49 ---It can be done!
--- End quote ---
This sounds a bit like Frankenstein Jr. :-) but.... chapeau!
Excellent work!
I would do the following changes:
1. write to the queue_log file, so that it is uploaded by qloaderd and it is easy to restore.
2. In QM , TRANSFER is a call-closure record. But you could do:
--- Code: ---ENTERQUEUE on queue A
CONNECT on queue A
TRANSFER on queue A
ENTERQUEUE on queue "A-transfers"
CONNECT on queue "A-transfers"
AGENTCOMPLETE on queue "A-transfers"
--- End code ---
When you output the TRANSFER you output both other records. In QM these are two queue "legs" that can be analyzed together or separately.
QueueMetrics
QueueMetrics:
--- Quote from: moa on November 16, 2010, 19:36:49 ---It can be done!
--- End quote ---
Do you mind if we add this to the Advanced Configuration manual? with proper credits, of course! :)
moa:
--- Quote from: QueueMetrics on November 17, 2010, 09:46:02 ---This sounds a bit like Frankenstein Jr. :-) but.... chapeau!
--- End quote ---
It's what I do best :)
--- Quote from: QueueMetrics on November 18, 2010, 14:31:32 ---Do you mind if we add this to the Advanced Configuration manual? with proper credits, of course! :)
--- End quote ---
I don't mind at all. I'm just glad that I got it all working ;D ;D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version