[asterisk-users] AgentCallBackLogin vs AddQueueMember

[Kevin P. Fleming]

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).