[asterisk-users] AgentCallBackLogin vs AddQueueMember

[Alan Ferrency]

I apologize for not responding sooner, I obviously don't read this
mailing list regularly.


> Alan Ferrency wrote:
> > In our investigation of the "AddQueueMember" vs.
> > "AgentCallbackLogin" situation, the major loss with using the
> > published "AddQueueMember" replacement is that it assumes each agent
> > is always using the same phone.

I believe I misstated my original meaning, in this quoted statement.
Hopefully my explanation below will help clarify our needs.

On Wed, 28 Feb 2007, Kevin P. Fleming wrote:

> This is not true; it is certainly possible to call AddQueueMember() and
> dynamically construct the channel name that should be added based on the
> channel that is placing the call to AddQueueMember(). In addition, you
> can avoid passing _any_ interface name to AddQueueMember() and will use
> the calling channel name after stripping any suffix present after '-',
> which in the vast majority of cases will do exactly what you want.

This is interesting; I was not aware of the "no interface" option.

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.

If two different people log into the same phone at different times, I
need the queue log activity to be associated with the person, and not
the SIP channel they happen to be using at the time. Later, we need to
extract information from the queue log such as the amount of time each
person (not the phone) is logged in, the number of calls the person (not
the phone) took, how many calls the person abandoned or failed to
answer, and so on.



We can certainly reimplement the functionality we need, by building a
dynamic interface identifier to add to the queue, but there are many
aspects of this which are nontrivial. Specifically, to make this
effective we would need to maintain a map between a person and the phone
that they are using at any particular time. To me, this is the main
benefit we get from AgentCallbackLogin.

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


Can the AddQueueMember solution handle the equivalent of "autologoff" if
a queue member fails to answer a queued call in time?



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

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.

Thanks for any more help you can give me on this point. I want to
believe that the decision to deprecate AgentCallbackLogin makes sense
from a standpoint other than decreased code base maintenance cost, but I
am still just not seeing it.


(I also apologize in advance, if my concerns have been addressed in
future asterisk list threads; I'm about to go read those shortly.)

Thanks,

Alan Ferrency