asterisk users - Jul 2007 - AgentCallBackLogin vsAddQueueMember

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

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
>