[asterisk-users] AgentCallBackLogin vsAddQueueMember

Thu Jul 5 04:02:14 CDT 2007

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