[asterisk-users] AgentCallBackLogin vs AddQueueMember

[Alan Ferrency]

On Wed, 11 Apr 2007, Kevin P. Fleming wrote:

> Alan Ferrency wrote:
>
> > This means that all queue activity is associated with a SIP channel
> > in the logs, which is not acceptable.
>
> 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.

Okay, 'membername' does seem like it will solve several of our concerns.
Thank you for pointing out this option and its intended use.

> > 1. a person cannot be logged into more than one phone
> > 2. only one person at a time can be logged into a phone
>
> For points #1 and #2, you are correct that this logic will have to be
> built.

If all the rest of our functionality is taken care of, solving these
might not be a problem.

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

... which is exactly what I've been trying to do with this thread.

We have no plans to upgrade asterisk out of the 1.2 branch, because at
this point the implementation costs would be far too high, as long as
all we'd get out of it is downtime followed by "status quo."

(We're still using 1.2.3, because from what I've read, the combination
of features we require has serious deadlock race conditions in newer
versions of Asterisk. Let's just say, "this is far from ideal.")

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

This is not the way I am acting.  My intent with this thread is to:

* learn enough about the new solution to know whether it will serve our
  needs or not
* if not, try to push development in the direction we will need, _when_
  the time comes that we must upgrade
* show "anyone who's listening" our specific use case for
  AgentCallbackLogin, which may or may not have been considered

My intent has not been to try to stop the deprecation of
AgentCallbackLogin.

When the time comes that we do decide to upgrade and reconfigure, I will
need a high level of confidence that the solution I propose will serve
our needs, and will provide value comparable to the cost of
implementation. I can't achieve that by ignoring the situation until the
last minute.


>From the example "new solution" and related documentation I have read
previously, I did not come away with the impression that it did
everything we needed it to. Your clarifications have helped on several
points that I missed. So from my personal perspective, I consider this
thread at least partially successful.


It may be that more complete documentation would help mitigate this
(perceived) problem. At least it would let you answer e-mails such as
mine, which are likely far more common than you'd prefer, with a single
"rtfm://" URL.

As it is now, we have a chicken-and-egg situation. Since no one is
required to stop using AgentCallbackLogin, few have stopped using it.
So, there are few examples in the wild of how to reimplement specific
feature requirements. This lack of examples increases the migration cost
away from AgentCallbackLogin, and the circle is closed.


Thank you for your help,
Alan Ferrency