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