Dynamic agents support in agent web interface?

[Davidgue]

Hi!

As I understand, a dynamic agent is not able to connect or disconnect (or pause/unpause) from a certain queue via the agent web page. Isn't it?

If not available... any hope that it would be possible in a future (soon) release?

Thanks,
David.

[Davidgue]

Hi, it's me again...

Funny enough, pause/unpause commands from the web interface works OK as it applies to all queues an agent is logged in.

But for some reason, the actual state (paused or not) is not updated in the interface: it always shows "active".

Showing the "pause state" would be great to have, especially if you use "autopause=yes".

Thanks again,
David.

[QueueMetrics]

QueueMetrics is a pretty flexible piece of software - what exactly do you get in the queue_log?

[Davidgue]

Hi!

Yes, I know that is pretty flexible.. and we are very happy with it, especially with the reporting capabilities...

The point is that we use mainly "fully dynamic agents" (with Asterisk 1.4.19). We have 3 queues, but each agent (SIP/xxxx) only logs in one of them.

We are interested in the web interface for agents in order to:

- provide them a way to see their status: logeed in / logged out , paused / unpaused
- provide them a way to change their status: log in / log out , pause / unpause

In one of the queues we use the "autopause=yes" feature that automatically pauses an agent after he fails to pickup a call. In teh queue_log, the followin line is appended when this happens:

1208251144|NONE|cola_anuncios|SIP/agente4111|PAUSE|


Problems fixed (after hacking around a little bit with the extensions definitions in the [queuemetrics] context):

* Pause an agent
* Unpause an agent paused with the web interface, or via "autopause=yes"

* The web interface correctly displays the active/inactive status if the agent is logged via dialplan functions AddQueueMember & RemoveQueueMember (dialing the codes to log in / off with the phone)


Problems I think I can fix:

I think I can make the log in / log out features of the web interface work if I store in an AstDB key for each agent the queue they belong, and use that info to log in/off the agent thru [queuemetrics] context using functions AddQueueMember & RemoveQueueMember instead of AgentCallBackLogOn and "asterisk -rx agent logoff".


Problems we have not worked out:

* The web interface DOES NOT displays the pause/unpause status of the agent


BTW, is there a "Spanish es_ES" translation avalaible? If not I can try to make one starting from the "L.A. Spanish" translation...

[QueueMetrics]

Problems we have not worked out:

* The web interface DOES NOT displays the pause/unpause status of the agent

You need to use PAUSEALL, as QM does not track PAUSE so far. With a fully dynamic setup, either the agents log off from one specific queue, or you PAUSE them all as they want to go grab some coffee.

BTW, is there a "Spanish es_ES" translation avalaible? If not I can try to make one starting from the "L.A. Spanish" translation...

That would be welcome. What are the main changes?

[Davidgue]

Thanks for your response...

How easy would be that QM tracks PAUSE state also ? (is there any code I can patch for that?)

Unfortunately Asterisk only uses PAUSE in the specific queue, when the "autopause=yes" feature is used in queues.conf.

I think it would be easier to hack Queuemetrics than to hack Asterisk to write PAUSEALL in the log and mark as paused the agent in all queues (as in the command "PauseQueueMember").

I've been able to login/logoff an agent via the web interface with the following extensions in the quemetrics context:

[queuemetrics]

; 10: Dummy extension
exten => 10,1,Answer
exten => 10,n,Wait(10)
exten => 10,n,Hangup

; Agent logon
exten => 20,1,Answer
exten => 20,n,Set(COLA=${DB(COLA_AGENTE/${AGENTCODE})})
exten => 20,n,NoOp(** Añadiendo ${AGENTCODE} a la cola ${COLA} via QM **)
exten => 20,n,AddQueueMember(${COLA},SIP/${AGENTCODE})
exten => 20,n,Hangup

; Agent logoff
exten => 21,1,Answer
exten => 21,n,Set(COLA=${DB(COLA_AGENTE/${AGENTCODE})})
exten => 21,n,NoOp(** Eliminando ${AGENTCODE} de la cola ${COLA} via QM **)
exten => 21,n,RemoveQueueMember(${COLA},SIP/${AGENTCODE})
exten => 21,n,Hangup

; Agent pause
exten => 22,1,Answer
exten => 22,n,NoOp(** Pausando ${AGENTCODE} en todas las colas via QM **)
exten => 22,n,PauseQueueMember(|SIP/${AGENTCODE})
exten => 22,n,Wait(2)
exten => 22,n,System( echo  "${EPOCH}|${UNIQUEID}|NONE|SIP/${AGENTCODE}|PAUSEREASON|${PAUSEREASON}" >> /var/log/asterisk/queue_log )
exten => 22,n,Hangup

; Agent unpause
exten => 23,1,Answer
exten => 23,n,NoOp(** Despausando ${AGENTCODE} en todas las colas via QM **)
exten => 23,n,UnpauseQueueMember(|SIP/${AGENTCODE})
exten => 23,n,Wait(2)
exten => 23,n,Hangup

I use an AstDB for tracking the queue each agent belongs (I could use the extension field in the web interface for that, but as this never changes in my setup, I prefer to leave that empty and save some keystrokes to our agents).

And for the spanish translation, there are few words that sounds "funny" here from the L.A. version, so I'll update it and send it to you in case you want to include it in the distribution)...

Thanks for all,
David.

[QueueMetrics]

Why don't you simply vhange your code to pause ALL and not just one queue? that would likely work.

[Davidgue]

Hi,

I don't have code to change...

Ther is an option in queues.conf called "autopause". If you set this to "yes", Asterisk "magically" put an agent in "pause" if he or she fails to take a call. Its helpful in situations where an agent forgets to pause himself when he or she leaves for a moment or whatever...

That "magically" implies that Asterisk write:

1208251144|NONE|cola_anuncios|SIP/agente4111|PAUSE|

when this happens.

I cannot change the "autopause" behaviour (without patching asterisk).

This is what I'm trying to explain since my first message...

I think that this is a clear case where QM must conform with Asterisk standard behaviour.

Thanks,
David.

[QueueMetrics]

This is not supported at the moment.


We plan to support single-queue pausing in a future release anyway (issue #335).