[Home]

Summary:ASTERISK-27790: Realtime Queue Ringinuse=no not functioning
Reporter:Jaco van Niekerk (faqterson)Labels:asterisk
Date Opened:2018-04-04 01:28:11Date Closed:2019-10-24 12:00:05
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:Applications/app_queue
Versions:13.28.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Intel Core Processor (Skylake) 2Gig RAM MySQL Database Attachments:( 0) Configuration.txt
( 1) ringinuse_no.txt
Description:This is the description of ringinuse in the sample file:
; If you want the queue to avoid sending calls to members whose devices are
; known to be 'in use' (via the channel driver supporting that device state)
; uncomment this option.
; ringinuse=no

Problem 1:
However when setting ringinuse to 0 or no in the MySQL table it stops the queue from disturbing calls to the members. A single call is sent to the agent and no call after that (Attached CLI examples)

Problem 2:
Setting Ringinuse to 1 or yes allows the members to receive multiple calls but while in a 'in use' state you expect them to receive a second call but it doesn't.
Comments:By: Asterisk Team (asteriskteam) 2018-04-04 01:28:11.867-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Joshua C. Colp (jcolp) 2018-04-04 04:42:30.043-0500

It appears the bug you have submitted is against a rather old version of a supported branch of Asterisk. There have been many issues fixed between the version you are using and the current version of your branch. Please test with the latest version in your Asterisk branch and report whether the issue persists.

Please see the Asterisk Versions [1] wiki page for info on which versions of Asterisk are supported.
[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions


By: Jaco van Niekerk (faqterson) 2018-04-05 05:27:26.240-0500

Thank you, I will recompile to asterisk 13.20.0 and run a couple more test.

I will advise over the weekend the results from the tests.
By: Asterisk Team (asteriskteam) 2018-04-19 12:00:01.847-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
By: Jaco van Niekerk (faqterson) 2019-10-08 02:12:11.865-0500

I am still experiencing the same result with the latest version of asterisk 13.

Connected to Asterisk 13.28.1 currently running on pbx (pid = 7993)

1570515476|1570515475.219618|gems_english|NONE|ENTERQUEUE||0873615352|1
1570515478|1570515475.219618|gems_english|SIP/455|CONNECT|2|1570515476.219624|1
1570516144|1570515475.219618|gems_english|NONE|CALLERONHOLD|GEMS Inbound
1570516148|1570515475.219618|gems_english|NONE|CALLEROFFHOLD|
1570516148|1570515475.219618|gems_english|SIP/455|ATTENDEDTRANSFER|APP|Playback|2|670|1

1570515968|1570515967.220188|gems_isixhosa|NONE|ENTERQUEUE||0873679544|1
1570515980|1570515967.220188|gems_isixhosa|SIP/455|RINGNOANSWER|12000
1570515989|1570515967.220188|gems_isixhosa|SIP/409|CONNECT|21|1570515985.220203|3
1570516169|1570515967.220188|gems_isixhosa|NONE|CALLERONHOLD|GEMS Inbound
1570516243|1570515967.220188|gems_isixhosa|NONE|CALLEROFFHOLD|
1570516243|1570515967.220188|gems_isixhosa|SIP/409|ATTENDEDTRANSFER|BRIDGE|38162036-3e04-41a6-a307-e043a3c1cc9a|21|254|1

1570515039|1570515039.219022|gems_english|NONE|ENTERQUEUE||0873615352|1
1570515042|1570515039.219022|gems_english|SIP/425|CONNECT|3|1570515039.219028|2
1570515443|1570515039.219022|gems_english|NONE|CALLERONHOLD|GEMS Inbound
1570515446|1570515039.219022|gems_english|SIP/425|BLINDTRANSFER|*800|extensions|3|404|1

1570515340|1570515339.219426|gems_isizulu|NONE|ENTERQUEUE||0873615352|1
1570515352|1570515339.219426|gems_isizulu|SIP/425|RINGNOANSWER|12000
1570515358|1570515339.219426|gems_isizulu|SIP/415|CONNECT|18|1570515357.219442|1
1570515380|1570515339.219426|gems_isizulu|NONE|CALLERONHOLD|GEMS Inbound
1570515392|1570515339.219426|gems_isizulu|SIP/415|COMPLETEAGENT|18|34|1
By: Asterisk Team (asteriskteam) 2019-10-08 02:12:12.323-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.
By: Benjamin Keith Ford (bford) 2019-10-08 11:16:47.680-0500

I'm not seeing this problem, or maybe I'm misunderstanding it.

I have a realtime queue (RTQueue), with 2 members in it. I place a call to the queue using the following dialplan:
{code}
exten => 123,1,NoOp()
same => n,Queue(RTQueue,,,,30)
same => n,Hangup()
{code}
If an agent is already in a call, it does not receive a call with 'ringinuse=no'. When I have 'ringinuse=yes', the agent will receive the call, even if already in a call. This, from what I've read of the documentation, appears to be the correct functionality. Is this not working for you?
By: Jaco van Niekerk (faqterson) 2019-10-08 11:27:47.707-0500

Its not happening every time, its happening intermittently.

1570515478|1570515475.219618|gems_english|SIP/455|CONNECT|2|1570515476.219624|1 - Call connected to the agent 455
1570516148|1570515475.219618|gems_english|SIP/455|ATTENDEDTRANSFER|APP|Playback|2|670|1 - Call was transferred by the agent

1570515980|1570515967.220188|gems_isixhosa|SIP/455|RINGNOANSWER|12000 - New call received and ringed to 455.

If we look at the epoch time ID we can see the agent was busy on a call when the new call was received:
1570515478(call received) is less than 1570515980(new call) transfer time is greater 1570516148(Transfer)

Queue database values:
| name          | musiconhold | announce | context | timeout | monitor_join | monitor_format | queue_youarenext | queue_thereare | queue_callswaiting | queue_holdtime | queue_minutes | queue_seconds | queue_lessthan | queue_thankyou | queue_reporthold | announce_frequency | announce_round_seconds | announce_holdtime | announce_position | retry | wrapuptime | maxlen | servicelevel | strategy | joinempty | leavewhenempty | eventmemberstatus | eventwhencalled | reportholdtime | memberdelay | weight | timeoutrestart | ringinuse | periodic_announce | periodic_announce_frequency | setinterfacevar |
+---------------+-------------+----------+---------+---------+--------------+----------------+------------------+----------------+--------------------+----------------+---------------+---------------+----------------+----------------+------------------+--------------------+------------------------+-------------------+-------------------+-------+------------+--------+--------------+----------+-----------+----------------+-------------------+-----------------+----------------+-------------+--------+----------------+-----------+-------------------+-----------------------------+-----------------+
| gems_english  | NULL        | NULL     | NULL    |      12 |         NULL | NULL           | NULL             | NULL           | NULL               | NULL           | NULL          | NULL          | NULL           | NULL           | NULL             |                  0 |                   NULL | no                | no                |  NULL |          0 |   NULL |           20 | rrmemory | yes       | NULL           |              NULL |            NULL |           NULL |        NULL |   NULL |           NULL |         0 |                   |                           0 |            NULL |
| gems_isixhosa | NULL        | NULL     | NULL    |      12 |         NULL | NULL           | NULL             | NULL           | NULL               | NULL           | NULL          | NULL          | NULL           | NULL           | NULL             |                  0 |                   NULL | no                | no                |  NULL |          0 |   NULL |           20 | rrmemory | yes       | NULL           |              NULL |            NULL |           NULL |        NULL |   NULL |           NULL |         0 |                   |                           0 |            NULL |


By: Benjamin Keith Ford (bford) 2019-10-09 09:48:21.521-0500

We're going to need logs from Asterisk with at least debug and verbose set to 5 to better diagnose this.
By: Jaco van Niekerk (faqterson) 2019-10-10 02:55:11.444-0500

I have gone through the logs and can't find any abnormal in warnings or errors in message.

I have also run a debug with verbose 5 and can't find any device stat information per queue being displayed.

I did however find that doing "sip prune realtime peer" seams to effect the device state in the queue. Why will pruning the peer effect the queue?

By: Benjamin Keith Ford (bford) 2019-10-10 09:23:54.149-0500

If you can attach the logs here, that would help. Specifically, logs that capture the incident happening, so we can see the flow of events through Asterisk that lead up to this.

A more detailed description of what you are doing to test this and the chain of events you see happen versus the events you would expect to happen would also help.

Pruning the peer doesn't really affect the queue, but the agent itself. Since the queue has to monitor the agent somehow, the queue is indirectly affected by any changes that occur.
By: Asterisk Team (asteriskteam) 2019-10-24 12:00:04.651-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines