[queuemetrics] context and FreePBX

[trymes]

I'm certain that this has been hashed out before, but it's still pretty unclear to me, so...:

We have QM installed on top of Elastix, which uses FreePBX. After reading the manual, it is obvious that the call monitoring and other features require a proper queuemetrics context. It also seems that tracking agent availability might not be possible without appending the login and logout events to the queue_log. I have a few problems, though:

1.) FreePBX is pretty complex in how it handles and constructs the dialplan. I feel more comfortable using their login/logout routines.
2.) The provided login/logout routines do not contemplate the recently added realtime queue_log storage. What would the proper command be for that?
3.) Does the sample QM context need tweaking for monitoring ongoing calls via chanspy for FreePBX systems? I can say for certain that it causes very strange behavior if you try to use it without configuring it properly.

Any insight appreciated.

Tom

[QueueMetrics]

1. I totally understand. On the other side, there are some things Qm can't do without the cooperation of Asterisk, so here is why.
2. Do they use "echo" or the "queuelog" command?
3. It usually does not, but it depends on the format of Agent channels.

[mudslide567]

I am using QM 1.6.2 in conjunction with freePBX 2.8.x.x. in a hot seating environment and it works like a charm pretty much out of the box [although I still reverted back to the "echo" for queue logging].  The other note I would make is that when you have a complex set up [12 different queues and 100+ agents], using the QM mechanism for logging in and out and joining queues is much more practical and user friendly than the freePBX approach, but that is just one person's opinion.

[trymes]

OK, so my apologies for being unclear. I completely understand QM's need for integration with Asterisk, so I have no qualms with adding a custom [queuemetrics] context to my dialplan. Having said that, I also recognize that just bypassing FreePBX's built-in dialplan for things like queue login/out can sometimes result in unexpected behavior. For that reason, I am seeking to determine what might be the best combination of FreePBX and QM dialplan bits to get the best of both worlds.

Mudslide, thanks for the input. We have a simple queue system here: one queue with ~35 dynamic agents who log in and out using the FreePBX queue toggle. Basically, they dial *45XXX, where 'XXX' is the queue #. This can be saved as a speed dial on their phone and it logs them in if they are logged off, and it logs them off if they are logged in. Quite handy. Here is the relevant piece of dialplan logic.

Code: [Select]

[app-queue-toggle]
include => app-queue-toggle-custom
exten => s,1(start),Answer
exten => s,n,Wait(1)
exten => s,n,Macro(user-callerid,)
exten => s,n,Set(QUEUESTAT=LOGGEDOUT)
exten => s,n,AGI(queue_devstate.agi,getqueues,${AMPUSER})
exten => s,n,GotoIf($["${QUEUESTAT}" = "LOGGEDOUT"]?activate)
exten => s,n,GotoIf($["${QUEUESTAT}" = "LOGGEDIN"]?deactivate)
exten => s,n,GotoIf($["${QUEUESTAT}" = "STATIC"]?static:end)
exten => s,n(deactivate),Noop(Agent Logged out)
exten => s,n,Macro(toggle-del-agent,)
exten => s,n,Set(STATE=NOT_INUSE)
exten => s,n,Gosub(sstate,1)
exten => s,n,Playback(agent-loggedoff)
exten => s,n,Macro(hangupcall,)
exten => s,n(activate),Noop(Agent Logged In)
exten => s,n,Macro(toggle-add-agent,)
exten => s,n,Set(STATE=INUSE)
exten => s,n,Gosub(sstate,1)
exten => s,n,Playback(agent-loginok)
exten => s,n,SayDigits(${CALLBACKNUM})
exten => s,n,Macro(hangupcall,)
exten => s,n(static),Noop(User is a Static Agent)
exten => s,n,Set(STATE=INUSE)
exten => s,n,Gosub(sstate,1)
exten => s,n,Playback(agent-loginok)
exten => s,n,Macro(hangupcall,)
exten => sstate,1,Set(DEVICES=${DB(AMPUSER/${AMPUSER}/device)})
exten => sstate,n,GotoIf($["${DEVICES}" = "" ]?return)
exten => sstate,n,Set(LOOPCNT=${FIELDQTY(DEVICES,&)})
exten => sstate,n,Set(ITER=1)
exten => sstate,n(begin),Set(DEVICE_STATE(Custom:QUEUE${CUT(DEVICES,&,${ITER})}*${QUEUENO})=${STATE})
exten => sstate,n,Set(ITER=$[${ITER} + 1])
exten => sstate,n,GotoIf($[${ITER} <= ${LOOPCNT}]?begin)
exten => sstate,n(return),Return()
; end of [app-queue-toggle]
From what I can see, it does nothing to add the login and logout states to the log, which is just as well, considering we're on the realtim log (echoing to a file would accomplish nothing....). I would like to get some input so that I can make a FreePBX feature request to have login and logout actions logged.

As for Chanspy weirdness, I can say that I tried it without realizing it needed a proper context, and I think I inadvertently bridged two customer's calls in the queue, such that they ended up talking to each other! I do know that FreePBX has its own chanspy context set up such that a feature code is dialed and you are connected to chanspy. Maybe QM could be pointed towards that?

Code: [Select]

[app-chanspy]
include => app-chanspy-custom
exten => 555,1,Macro(user-callerid,)
exten => 555,n,Answer
exten => 555,n,Wait(1)
exten => 555,n,ChanSpy()
exten => 555,n,Hangup
; end of [app-chanspy]
Tom

[QueueMetrics]

I do know that FreePBX has its own chanspy context set up such that a feature code is dialed and you are connected to chanspy. Maybe QM could be pointed towards that?

What is wrong with the plain, vanilla ChanSPy command?

[trymes]

Nothing is wrong with it. However, I generally prefer to avoid adding any custom dialplan code to FreePBX installations whenever possible. While it is easy and generally quite safe, I feel it is best to avoid if possible, as future changes to FreePBX can break your custom code in ways you might not anticipate.

In other words, if you don't need to use custom dialplan code, don't. If you have to, it's not the end of the world.

[mudslide567]

if you create an extensions_queuemetrics.conf file and include it in freePBX's extensions_custom.conf, you will not and cannot break freePBX even when freePBX does version upgrades. 

[trymes]

That's accurate, but I still stand by my preference for not adding custom code unless necessary. While it is unlikely that you will break FreePBX, you might affect the dialplan in ways you don't expect and don't immediately notice, especially if you later upgrade FreePBX. This is less likely for things like ChanSpy, but for things like Queue login, you might end up doing things that undermine what FreePBX is designed to do.

To get right down to it, FreePBX is a pretty complex beast, and any custom additions to the dialplan increase the risk of encountering unusual behavior. For that reason I think it is best to avoid any custom additions WHEN POSSIBLE. Sometimes it isn't possible, and QM looks to be one of those times, but I want to dig a little deeper and see what options are out there that would allow me to add as little custom code as possible. I'm thinking of things like creating a context that echoes entries to queue log and then points to the built-in queue toggle, rather than recreating the wheel, etc.

Tom