Summary:	ASTERISK-10552: Circular call distribution no longer works
Reporter:	Nick Barnes (bcnit)	Labels:
Date Opened:	2007-10-17 02:35:33	Date Closed:	2007-11-06 14:50:28.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	In Asterisk 1.2, if I wanted to specifically state the order extensions were run, I would use priorities and the 'roundrobin' strategy, for example: ----------------------------------- [queue] strategy=roundrobin timeout=10 retry=1 member => SIP/100,1 member => SIP/102,2 member => SIP/101,3 ----------------------------------- This would have the effect of ringing 100 for 10 seconds, then 102, then 101. In Asterisk 1.4(.13) and being driven from realtime, this no longer works. Using 'roundrobin' is now deprectaed and if the queue defined above were called, 100 would ring for 10 seconds, then would ring for another 10 seconds and so on. I suspect that this behaviour will break a lot of implementations when they are upgraded to 1.4 - it's certainly broken two of ours. ****** ADDITIONAL INFORMATION ****** Whilst most of our queues are in 'rrmemory' with no problem at all, it is absolutely vital that for a couple of queues we are able to control the call flow. I apologise in advance if there is a new way of achieving what I want - I can't see anything in the documentation.
Comments:	By: Mark Michelson (mmichelson) 2007-10-17 09:24:04 I have confirmed that this behavior happens in 1.4, but oddly enough it happened with 1.2.17 as well. Which version of 1.2 did you use which behaved the way you expected? By: Nick Barnes (bcnit) 2007-10-17 09:38:33 Pass. Good question. I will have to check. There is a note on http://www.voip-info.org/wiki-Asterisk+config+queues.conf which does say it works!! I've appended a 'not any more' bit! By: Nick Barnes (bcnit) 2007-10-17 10:06:20 OK. Half an answer. I have been told that it used to work on 1.2.16, but I have just set this up and it doesn't for my simple test. I will look at the other upgrade and test on that previous version. However..... The puzzling thing is why do priorities work if a member returns 'busy' or 'congestion', but not if it just times out? Anyway, I'll get back when I know more information. By: Mark Michelson (mmichelson) 2007-10-17 10:08:38 I had a bit of a brain fart this morning when I was reading this. I realize that what you are experiencing is actually the correct behavior. Member penalties are used for when a member with a lower penalty is busy or unavailable in some way. So in your setup, SIP/102 will only be rung if SIP/100 is busy and SIP/101 will only be rung if both SIP/100 and SIP/102 are unavailable. That being said, I don't know of a simple way to implement the behavior you desire for your queues in 1.4. There IS, however, an issue (ASTERISK-7091) which implements a "linear" strategy, which will always call the queue members in the order specified in queues.conf (or in the order in which they were added if they are dynamic queue members). Unfortunately, the patch on that issue is for trunk and does not apply cleanly to 1.4. Due to the policies regarding new features for 1.4, right now I can't guarantee the linear strategy's inclusion in 1.4, but what I will do is add a 1.4 version of the patch to that issue so that you may use it. A caveat though: the linear strategy has only been tested minimally by me in a small setup, so I can't guarantee that it will work flawlessly. I will add a note here once the 1.4 version of the linear strategy has been added to 7279. By: Nick Barnes (bcnit) 2007-10-17 10:17:08 Hmmm. OK, I take your point, but....... Surely no answer from a member indicates that that member is "unavailable in some way"? ;-) Both sites have queues driven from realtime (MySQL), so I don't know how this would work for the patch, but I'll have a play. If that doesn't work, then I've worked out how to implement it with Local channels and then I'll have a go at hacking the code to see if I can treat no answer the same as a Busy/Congestion which is a better solution for me. Perhaps a new option for the Queue command which says 'treat no answer as unavailable'. I have spoken to the EU and they are absolutely adamant that it used to work on a 1.2 version. I will investigate... By: Mark Michelson (mmichelson) 2007-10-17 10:25:01 If you want to treat no answer as a way of marking a member unavailable, you can use the autopause option. The restrictions here are that you'll not be able to use autofill, and you'll have to insert some dialplan logic to unpause all the queue members after each call. By: Nick Barnes (bcnit) 2007-10-17 10:31:52 Yes, I had a look at that. Trouble is that we've got used to 'autofill' now! I have now implemented it in Local channels (Dial command done from within the local channel with a timeout of less than the queue timeout and a response of BUSY if there's no answer), so it's working for the timebeing, but does mess with other things (same queue members in other queues). Before I brush off my very very very rusty programming skills, do you think that a flag to Queue() as mentioned previously would be a sensible approach? By: Nick Barnes (bcnit) 2007-10-17 10:33:46 ...or are we better off with a new option for queues.conf - say "noanswermeansbusy=yes" By: Mark Michelson (mmichelson) 2007-10-17 10:40:32 I have uploaded a 1.4 version of the linear strategy to issue ASTERISK-7091. By: Mark Michelson (mmichelson) 2007-10-17 10:43:01 I'd have to look a bit further into the idea for that flag. It may be doable but I can't say for sure just yet. By: Mark Michelson (mmichelson) 2007-11-06 14:50:28.000-0600 Since the state of queue members is gotten from their (channel-level) device state, attempting to modify the member's status from solely within app_queue (especially in a thread-safe way) would be at the least difficult, and at worst cause a bunch of new issues to surface. In either case, the changes are too invasive to be introduced into 1.4 anyway. Since I still have not been able to make the circular call distribution work as described in 1.2, I can't see any sort of action taken with regards to this as a bug fix. I am going to go ahead and close this, especially since you have found a workaround.