[asterisk-users] AgentCallBackLogin vsAddQueueMember

Mon Aug 6 16:29:41 CDT 2007

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 <martin.schrott at tsy.at> 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" <kpfleming at digium.com>
> To: "Alan Ferrency" <alan at pair.com>
> Cc: "Asterisk Users Mailing List - Non-Commercial Discussion"
> <asterisk-users at 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
>