Re: [asterisk-users] AgentCallBackLogin vsAddQueueMember
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Alan Ferrency [EMAIL PROTECTED] Cc: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@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
Re: [asterisk-users] 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 [EMAIL PROTECTED] To: Alan Ferrency [EMAIL PROTECTED] Cc: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@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:
