QueueMetrics > Running QueueMetrics

FreePBX(AsteriskNow) transfer

<< < (4/4)

moa:

--- Quote from: QueueMetrics on November 17, 2010, 09:46:02 ---This sounds a bit like Frankenstein Jr. :-) but.... chapeau!

--- End quote ---

Does this mean that my forum member status can change from "Newbie" to "Frankenstein Jr." ?

QueueMetrics:
I can just add some karma to your profile. You'll have to provide your own Frau Blücher....  ;D

bhenry:
Just to note, I believe I fixed my issue as well.  I am passing device state with queuemetrics login context.  So it looks something like this:


; extension 25: agent addqueuemember (for asterisk v1.4+)
exten => 25,1,Answer
exten => 25,2,NoOp( "QM: AddQueueMember (asterisk v1.4+) Agent/${AGENTCODE} on queue ${QUEUENAME} made by '${QM_LOGIN}'" )
exten => 25,3,Macro(queuelog,${EPOCH},${UNIQUEID},NONE,Agent/${AGENTCODE},HOTDESK,SIP/${AGENTCODE}@pbx01)
exten => 25,4,AddQueueMember(${QUEUENAME},Local/${AGENTCODE}@from-queue/n,,,SIP/${AGENTCODE}@pbx01)
exten => 25,5,Hangup

This fixed my issue with transfers not being shown in queue_log and also fixes the device state issue of agents remaining in use after a transfer.  I have not put it into production yet but in the labs it is working succesfully.

QueueMetrics:
Applause! :)

trymes:
I am now struggling with this exact problem. As you all have pointed out, it's a side-effect of the fact that FreePBX uses local channels for the queues, which is generally a Good Thing®. However, I am a little uncomfortable with just deleting the "COMPLETEDAGENT" entry from the queue_log, as it leaves a portion of the call leg "lost", and if the call was transferred to another agent, wouldn't you like to be able to see that call and report on it?

I wonder if it wouldn't make sense to modify the way this is currently being done. When we add the "TRANSFER" line, we create the problem that one call has two termination reasons. There are two ways to resolve this:

1.) Delete the second termination reason.
2.) Add entries that "begin" a second call that will be terminated by the eventual "COMPLETEDAGENT" entry.

Your original solution implements #1, but I think it might be better and simpler to implement #2. This would eliminate the cron job and also have the side benefit of allowing us to see the transferred portion of the call and report on it. If the transfer was to another agent, the agent's information could be used, and if it was transferred to an outside person, it could be shown as a call to an agent named "Outside Number" or similar.

Thoughts?

Tom

Navigation

[0] Message Index

[*] Previous page