Hey,
We have a pretty significant problem with queues, agents and voicemail.
We have a customer that has phones that occasionally go offline, but the agent is still logged in to the queue.
It seems that the way Thirdlane works causes the phone in this instance to decide the agent is busy, and then divert to their non-existant mailbox, which has a Wait(100) then congestion.
Obviously not what we want - how do we fix it?
Thanks,
Andrew
Thanks Eric. This is the way
Thanks Eric. This is the way we have got around this in the past; I had seen a few notes in release docs that indicated this should be fixed, but seeing as it was obviously not working, was worried we were doing something wrong.
The sad thing about changing is that the latest version of iSymphony has added support for Queue agents very nicely in the iSymphony interface, which we will break to a degree if we move down this path; manual log ins/outs will need to be managed from the TL interface rather than iSymphony which sits open on the call centre managers desk.
Hopefully Alex will fix his logic soon... :)
Andrew
Hi, Just a quick update to
Hi,
Just a quick update to anyone who is experiencing the same issue, and is using iSymphony 2.1 Beta or the 2.2 RC. iSymphony introduced a new feature known as the "agent login context", which should allow you to set the context an agent extension is logged in to.
Unfortunately it doesn't work, and as such the extensions were being logged into from-inside- as opposed to agent-extensions-, and so the RINGGROUP_TIMEOUT was being ignored.
We've filed a bug report with i9, and hopefully they'll update to fix this very soon!
Thanks,
Andrew
are you using asterisk 1.4.x?
are you using asterisk 1.4.x?
I'm surprised isymphony is spending much time with agents at all considering the complete removal of agentcallbacklogin. While I don't advise a 1.6.1.x migration until more of the more serious bugs they introduced in the last couple months get resolved, the 1.4 branch only has about a year of life left in it. That will mean the death of anything using agentcallbacklogin or agents.conf.
Yes; we are still using the
Yes; we are still using the 1.4.x branch, and to be honest, we are not likely to upgrade for another 18 months due to the way things are changing.
i9 have also done a lot of work implementing dynamic logins and dynamic agents, which work quite well; what we are missing is a good set of logic code to emulate the same behaviour where agents belong in multiple codes. If there were decent scripts and a "best practice" method of handling a single login into multiple queues, I think most of us would be very happy to migrate away from agents straight away.
Andrew
did you not take a look at
did you not take a look at the 'agent panel' for the user portal in the last release? it does an AddQueueMember for the sip channel of the user and will do it for a single queue or all queues. Instead of the queue calling dialplan to find an agent, it simply sends an invite to SIP/channel.
queues are not supposed to go to voicemail period. The RINGGROUP_TIMEOUT variable is supposed to prevent that. My advice is stop using chan_local (aka agentCallbackLogin) and add the members directly to the queue as SIP/channel not Local/exten@dialplan-crap. The latest version of pbx manager supports Dynamic members via the user portal so that SIP/channel is added and removed dynamically from the queue.