I'd like to know what alternative is available for those who run a call centre with dynamic agent->queue allocation.
We have people monitoring the queues and assigning agents depending on the queue demand. cheers! Santiago On 7/5/07, Martin Schrott - thinking:systems <[EMAIL PROTECTED]> wrote: > sorry, was only for users list... > Hi Kevin, > Hi list, > > you are right, acting now is not needed, when callbacklogin will be removed > anywhere in future... > But thinking how to realice alternatives can't be so wrong. > > Callbacklogin gives a very simple way to use more queues for one agent, > which only has to logon to only one system. > No need to make dbs or tables for saving, where the agent has to be logged > in. No need to create your own login functions. No additional tables, which > members are logged in. > Just one entry in queues.conf and agents.conf > This is simple. > > For sure, it would also be possible to use addqueuemembers functionality: > -make own tables where you save, in which queues each member has to be > logged in. > -create a table, to see wich members exist and which are logged in. Do not > forget the destination to call them. > -create a login functionallity, to use your tables. > -Then add the member to each queue by calling aqm once for each queue. (Our > cpu will thank us) for using it so much. > -do not think of logs. (there are patches helping you... and members-name, > wich you can use... try how) > It is as simple as callbacklogin ;-) > > Next difficulty is, using agent-groups... When we use aqm to call different > groups, we only have to make groups in agents.conf and put them into the > queues. > That is it. > > But no problem, we also can create additional tables and script a little > bit. We do not need to sleep at night. > > To summerice: using aqm we would have to make own tables of groups. Then we > have to make tables of members, that are logged in. Then we have to read > this tables, check who is logged in, then call aqm for each member that is > logged in and put it into each queue, the third table has saved this member > for... > > !!! Only to write it here is more work then using agent callbacklogin! > scripting it would be crazy, when callbacklogin does it for us !!! > > So we can only hope, that there will be an alternative application, that > works like callbacklogin. > I am sure, a lot of cc designers will stop upgrading, if callbacklogin is > removed and now new simmilar application is provided! Nobody can effort to > do this additional work to change all dialplans. :-) > > Where is the problem keeping callbacklogin as additional feature in future > versions. Nobody has to support or change it. Just keep it working. Or > create a new application that does all the same, when you can't stand it. > > If you can tell me in thre lines how to use addqueuemember doing all things > we need from callbacklogin app, then I will use it from today on. > Othervise it is a reinventing of the wheel. > > Hope there will be a alternate application in newer versions of asterisk. > > Thanks > > Martin > > > > ----- Original Message ----- > From: "Kevin P. Fleming" <[EMAIL PROTECTED]> > To: "Alan Ferrency" <[EMAIL PROTECTED]> > Cc: "Asterisk Users Mailing List - Non-Commercial Discussion" > <asterisk-users@lists.digium.com> > Sent: Wednesday, April 11, 2007 11:45 PM > Subject: Re: [asterisk-users] AgentCallBackLogin vs AddQueueMember > > > Alan Ferrency wrote: > > > However, this is not what we need. This adds a phone channel to the > > queue, and does not track which person is using that phone. This means > > that all queue activity is associated with a SIP channel in the logs, > > which is not acceptable. > > Right. This is why we added the 'membername' argument to the > AddQueueMember application, so that queue logs can reflect a logical > name for the queue member, regardless of what channel/interface they > logged in from. > > > Using this map of people to phones, our dial plan would then need to > > ensure that: > > - a person cannot be logged into more than one phone > > - only one person at a time can be logged into a phone > > - queue activity logs are associated with a person, not a phone > > For points #1 and #2, you are correct that this logic will have to be > built. Point #3 is already taken care of by the addition of the > 'membername' as I commented on above. > > However, I personally see this as a huge benefit; I much prefer Asterisk > to provide mechanisms for users to do things, but not the policy on how > they are to be used. When chan_agent is in use, you don't get to decide > what to do if a second user tries to log in from the same channel, that > has been decided for you. If instead you write that logic in the > dialplan (or start from an example you find in the docs, on the wiki, > etc.) you can completely control how the system behaves. > > > Can the AddQueueMember solution handle the equivalent of "autologoff" if > > a queue member fails to answer a queued call in time? > > Absolutely; the example in doc/queues-with-callback-members.txt shows > how to do it. > > > To me, saying "We removed the AgentCallbackLogin() application because > > you can reimplement it completely in the dialplan therefore it isn't > > necessary" is just like saying "We removed the VoiceMail() application > > because you can reimplement it in the dialplan." > > If that was true, we would have already done it. In fact there is an > effort under way to do exactly that, and for the reason I outlined > above: today, if you want the voicemail system to behave slightly (or > significantly) differently, you must modify the C code to do it. This is > in spite of the fact that the voicemail system is just a fancy IVR, and > we already have plenty of ways to build IVRs in Asterisk. Olle > Johansson's 'minivm' branch is an attempt to work towards fixing this, > so that the important voicemail-specific parts of app_voicemail will be > available as individual dialplan applications, but the 'personality' of > the voicemail system will be defined by the IVR the administrator > chooses to wrap around them. > > > Yes, it's true: these things can be reimplemented in the dial plan. But > > it's a royal pain in the butt, when what we need already existed. It is > > also inefficient for every end user who needs the functionality to > > reimplement it in their own unique way. > > You will have AgentCallbackLogin at your disposal until Asterisk 1.4 no > longer suits your needs, which could be years from now. There is no > reason for you to do _anything_ today, other than to start thinking > about how you want to do it in the future when you decide to upgrade to > Asterisk 1.6 and have to replace it. If there is no simple replacement > available to you at that time (which would be highly surprising > considering that it already exists today) then I can see your point, but > acting today like the functionality has been removed and that you are > being forced to rearchitect your system seems a little bit extreme (in > my opinion, of course). > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users