(14:07:18) wrmem: Hey Kevin, got a minute to talk about app_queue?
(14:07:28) kpfleming: maybe...
(14:08:56) wrmem: Someone pointed out the limit to it about not ringing more than one phone at a time, and that's right. I saw one solution on one of the list archives about just dequeing the call before starting to dial. Is that roughly right, or is there some other problem with that (overly simple) solution?
(14:09:45) kpfleming: i don't understand the question
(14:10:02) wrmem: Say you got two agents, and two calls come in at the same time.
(14:10:32) wrmem: Only one of the two phones will ring, once that person answers, then the other phone will ring.
(14:10:36) kpfleming: right
(14:11:34) wrmem: Is there a reason not to ring multiples?
(14:11:44) kpfleming: for the same call? you can already do that
(14:12:01) wrmem: no two callers (aka two customers).
(14:14:13) wrmem: is_our_turn() doesn't allow the 2nd person to dial until the first caller is removed from the queue.
(14:15:51) kpfleming: you can't do that, calls could get answered out of order in that situation
(14:16:36) kpfleming: and what do you do if the first call goes unanswered, and has to roll over to another agent, who is already hearing ringing for call #2?
(14:17:09) wrmem: True. Isn't that how the traditional ACD & UCD system would work anyway?
(14:19:26) folsson left the room (quit: Read error: 113 (No route to host)).
(14:19:39) kpfleming: what is 'traditional'? i've seen many different kinds of systems out there
(14:19:51) wrmem: Fair enough.
(14:20:16) kpfleming: keep in mind that app_queue is very simple call director... it's not as powerful as the 'traditional' systems :-)
(14:20:40) wrmem: All true. I'm thinking about tackling the problem, and can make it a queue option. But I wanted to make sure that the basic solution isn't flawed.
(14:20:44) kpfleming: from what i have heard, ICD is much more flexible, but i've never looked at it
(14:21:02) kpfleming: i don't know how you can safely implement it at all, with the way that app_queue works
(14:22:46) wrmem: Thinking about setting a flag when entering try:1
(14:23:17) wrmem: ... entering try_calling, then allowing is_our_turn() to ignore those with that flag.
(14:23:54) anthm: I can promise you, you can't, app_queue is fundamentally designed around a customer hunting for an agent and your requirement is clearyl an agent hunting for a customer
(14:24:32) anthm: unless you want to make the customer become a dynamic agent and have the agents call into the queue as customers =D
(14:25:05) kpfleming: right... it's a different model entirely
(14:25:45) wrmem: Ok. Not seeing why the logic wouldn't work. I'm following an idea that was posted to asterisk-dev in Dec '03, and I can't find the fatal flaw. http://lists.digium.com/pipermail/asterisk-dev/2003-December/002565.html
(14:25:48) tinyurl: tinyurl: http://tinyurl.com/7mnkc lists.digium.com
(14:26:14) kpfleming: but the second (and subsequent) callers will never enter try_calling until the first caller gets answered
(14:26:43) kpfleming: and how do you determine how many simultaneous calls to try ringing?
(14:27:16) wrmem: That can be fixed. Add a flag (or more likely use "handled" as more than a boolean)
(14:27:21) kpfleming: once you have pushed three calls to the 'head of the line', what happens if the number of agents in the queue drops to 2?
(14:27:41) kpfleming: it's going to be hard to do it right
(14:27:52) Silik0n: ahah...
(14:27:54) wrmem: Compare it to what does the queue do with only 1 agent online.
(14:27:57) Silik0n: ast_callerid_split(callerid, ourcidname, sizeof(ourcidname), ourcidnum, sizeof(ourcidnum));
(14:28:03) Silik0n: thats all i needed
(14:28:25) anthm: if you want to do some hacking go signup on ICD and play with it, it's designed to let you do anything you want the distribution strategy is 100% abstracted from the callflow
(14:28:31) kpfleming: but you have _already_ accepted those three calls as being delivered to agents, it's too late to drop the call out of the queue, especially if you are generating ringback to the caller
(14:28:32) Silik0n: seeing looks like that change was maily CID related
(14:28:45) kpfleming: Silik0n: yes, that was part of that change for sure
(14:29:28) wrmem: Not thinking about dropping them out of the queue (like the original poster suggested). Thinking about marking them, so that they remain at the top of the queue if try_calling fails.
(14:30:07) kpfleming: try_calling won't fail, it will continually try to ring the two agents that are in the queue and get 'BUSY' over and over again
(14:30:50) kpfleming: so you could have a number of calls all trying to ring the same agents, and it will be random which one actually rings their phone when they hang up
(14:31:09) kpfleming: you also can't keep them from getting called within their 'wrapup' interval, since you have already decided to deliver a call to them
(14:31:56) kpfleming: in other words, you need an 'agent pulls from the queue' model, that's what you are trying to do
(14:32:12) wrmem: Ok. I see that now. Thanks. I'll have to give it some more thought.