| Summary: | ASTERISK-18754: Queues ringinuse=yes does not ring busy extension | ||||
| Reporter: | thorben jensen (info@thorben.dk) | Labels: | |||
| Date Opened: | 2011-10-25 11:43:04 | Date Closed: | 2013-05-17 17:24:05 | ||
| Priority: | Minor | Regression? | |||
| Status: | Closed/Complete | Components: | Applications/app_queue | ||
| Versions: | 10.0.0-beta2 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | CentOS 6 | Attachments: | |||
| Description: | I have configured a queue with "ringinuse=yes" but calls from the queue are not sent to a busy extension. | ||||
| Comments: | By: thorben jensen (info@thorben.dk) 2011-10-25 11:46:31.572-0500 I forgot to mention that the extension has call waiting enabled. This is queues.conf: [general] persistentmembers=yes keepstats=yes monitor-type=MixMonitor updatecdr=yes shared_lastcall=no [1500_1] strategy=ringall timeout=60 weight=0 leavewhenempty = strict ringinuse = yes joinempty = no autopause = no setinterfacevar = yes retry=2 servicelevel = 10 announce-frequency=0 announce-holdtime=yes announce-position=no autofill=no wrapuptime=0 reportholdtime=no eventwhencalled=yes announce = ivr/IVR-1500_1-56 periodic-announce = ivr/IVR-1500_1-57 periodic-announce-frequency = 0 maxlen=0 By: Leif Madsen (lmadsen) 2011-11-01 08:36:56.571-0500 What happens if autofill=yes ? By: Leif Madsen (lmadsen) 2011-11-01 08:37:32.072-0500 Additionally some queue output would be useful here, such as the state of the queue members, and which members are in the queue. By: thorben jensen (info@thorben.dk) 2011-11-02 04:59:06.091-0500 I tried to set autofill=yes but it made no change. [1503_1] strategy=ringall timeout=15 weight=0 leavewhenempty = strict ringinuse = yes joinempty = no autopause = no setinterfacevar = yes retry=5 servicelevel = 15 announce-frequency=0 announce-holdtime=no announce-position=no autofill=yes wrapuptime=0 reportholdtime=no eventwhencalled=yes announce = ivr/IVR-1503_1-56 periodic-announce = ivr/IVR-1503_1-57 periodic-announce-frequency = 0 maxlen=0 1503_1 has 1 calls (max unlimited) in 'ringall' strategy (0s holdtime, 0s talktime), W:0, C:0, A:7, SL:0.0% within 15s Members: SIP/210_1 (dynamic) (In use) has taken no calls yet Callers: 1. SIP/voip30-00001116 (wait: 0:01, prio: 0) -- Executing [1503@dialsipextension_1:6] Queue("SIP/voip30-000010dc", "1503_1,tTwW,,,10000") in new stack -- Started music on hold, class 'default', on SIP/voip30-000010dc By: thorben jensen (info@thorben.dk) 2011-11-02 05:02:34.355-0500 Extension SIP/210_1 was on an outgoing call and had call waiting activated, but the queue did not attempt to call extension SIP/210_1 By: thorben jensen (info@thorben.dk) 2011-11-07 21:36:56.793-0600 Any ideas, anybody? By: Richard Mudgett (rmudgett) 2011-11-08 13:54:33.074-0600 Very few people can comment on this issue while it is in the "Waiting for feedback" state. I have removed it from this state since you seem to have answered Leif's question. FYI, When you enter feedback, you need to answer the "I'm done. Send it back."/"I'm not done. I will add more information later." question. By: thorben jensen (info@thorben.dk) 2011-11-27 05:40:09.831-0600 Any takers on this? By: Leif Madsen (lmadsen) 2011-11-30 14:58:45.045-0600 Looks like this is intentional behaviour. From the source code: {code} /* If autofill is not enabled or if the queue's strategy is ringall, then * we really don't care about the number of available members so much as we * do that there is at least one available. * * In fact, we purposely will return from this function stating that only * one member is available if either of those conditions hold. That way, * functions which determine what action to take based on the number of available * members will operate properly. The reasoning is that even if multiple * members are available, only the head caller can actually be serviced. */ {code} By: Leif Madsen (lmadsen) 2011-11-30 16:56:29.143-0600 After speaking with Mark Michelson, this could actually be a regression based on some features and changes made to Asterisk. I'm going to open another issue and assign it to the developer so we can figure out where to go from here. By: Leif Madsen (lmadsen) 2011-12-01 10:09:27.644-0600 Issue ASTERISK-18945 is the parent of this issue. By: tgj (tgj) 2012-07-18 12:07:15.737-0500 Will this issue ever be solved? By: Rusty Newton (rnewton) 2013-04-25 12:05:31.289-0500 Thorben can you re-test with the latest release version of 1.8 or 11? By: Rusty Newton (rnewton) 2013-05-17 17:24:05.684-0500 Closing this out as can't reproduce until someone who was previously experiencing this can demonstrate this happening in the latest 1.8 or 11. Feel free to comment on the issue or ping a bug marshal in #asterisk-bugs to discuss. | ||||