[Home]

Summary:ASTERISK-28354: app_queue: Call to Unavailable member when ringinuse=yes and another member is available
Reporter:Vyrva Igor (vigor1710)Labels:pjsip
Date Opened:2019-03-27 07:17:49Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Applications/app_queue
Versions:13.26.0 16.2.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Asterisk 16.2.0 PJSIP CentOS 7Attachments:
Description:If the Queue parameters are set to ringinuse=yes, then the call occurs including on the Members with the status "unavailable".

This leads to Errors in the CLI / logs with the content that these Membranes have the wrong contact

For example:
queue.conf:
{noformat}
[test]
ringinuse=yes
member => PJSIP/666,1,Test User
{noformat}

test extenion
{noformat}
exten => *666,1,NoOp(Test call)
same => n,Queue(test,ct,,,15)
same => n,NoOp(${QUEUESTATUS})
same => n,Hangup()
{noformat}

queue show test
{noformat}
test has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0%, SL2:0.0% within 0s
  Members:
     PJSIP/115 with penalty 1 (ringinuse enabled) (dynamic) (Not in use) has taken no calls yet
     Test User (PJSIP/666) with penalty 1 (ringinuse enabled) (Unavailable) has taken no calls yet
  No Callers
{noformat}

Call
{noformat}
  -- Executing [*666@local:1] NoOp("PJSIP/423-00000000", "Test call") in new stack
   -- Executing [*666@local:2] Queue("PJSIP/423-00000000", "test,ct,,,15") in new stack
   -- Started music on hold, class 'default', on channel 'PJSIP/423-00000000'
[2019-03-27 14:50:52] ERROR[24233]: res_pjsip.c:3500 ast_sip_create_dialog_uac: Endpoint '666': Could not create dialog to invalid URI '666'.  Is endpoint registered and reachable?
[2019-03-27 14:50:52] ERROR[24233]: chan_pjsip.c:2498 request: Failed to create outgoing session to endpoint '666'
   -- Called PJSIP/115
{noformat}


However, if all Members in the Queue are not available, the call is not assigned.

queue show test
{noformat}
test has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime, 0s talktime), W:0, C:0, A:1, SL:0.0%, SL2:0.0% within 0s
  Members:
     PJSIP/115 with penalty 1 (ringinuse enabled) (dynamic) (Unavailable) has taken no calls yet
     Test User (PJSIP/666) with penalty 1 (ringinuse enabled) (Unavailable) has taken no calls yet
  No Callers
{noformat}

Call:
{noformat}
   -- Executing [*666@local:1] NoOp("PJSIP/423-00000002", "Test call") in new stack
   -- Executing [*666@local:2] Queue("PJSIP/423-00000002", "test,ct,,,15") in new stack
   -- Started music on hold, class 'default', on channel 'PJSIP/423-00000002'
   -- Stopped music on hold on PJSIP/423-00000002
   -- Executing [*666@local:3] NoOp("PJSIP/423-00000002", "TIMEOUT") in new stack
   -- Executing [*666@local:4] Hangup("PJSIP/423-00000002", "") in new stack
{noformat}

In queue_log:
{noformat}
'2019-03-27 14:50:52.942106', '1553687452.0', 'test', 'NONE', 'ENTERQUEUE', NULL, '', '423', '1', '', ''
'2019-03-27 14:50:58.066067', '1553687452.0', 'test', 'PJSIP/115', 'RINGCANCELED', NULL, '5121', '', '', '', ''
'2019-03-27 14:50:58.067558', '1553687452.0', 'test', 'NONE', 'ABANDON', NULL, '1', '1', '6', '', ''
'2019-03-27 15:02:53.852089', '1553688173.2', 'test', 'NONE', 'ENTERQUEUE', NULL, '', '423', '1', '', ''
'2019-03-27 15:03:08.867865', '1553688173.2', 'test', 'NONE', 'EXITWITHTIMEOUT', NULL, '1', '1', '15', '', ''
{noformat}

Although in normal operation we need to only call on those Members that have a status other than "unavailable."

If you remove ringinuse=yes then the call to the Members with the status "unavailable" is not made. But at the same time the call of Members with the status "in use" is also not made.
Comments:By: Asterisk Team (asteriskteam) 2019-03-27 07:17:50.461-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].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Chris Savinovich (csavinovich) 2019-04-01 11:26:32.545-0500

Hello Vyrva,  we are going to need your configuration of all related extensions from pjsip.conf.  Also complete corresponding configuration of queue from queue.conf.  There is also not clear how the agent logins to queue. (corresponding conf from extensions.conf)
Thanks
C. Savinovich

By: Vyrva Igor (vigor1710) 2019-04-02 02:02:13.874-0500

pjsip.conf:
[system]
type=system
timer_t1 = 500
timer_b = 32000
compact_headers = no
[global]
type = global
debug = no
[transport-udp]
type = transport
protocol = udp
allow_reload = yes
bind = 0.0.0.0
symmetric_transport = yes

[phone-endpoint](!)
type = endpoint
context = local
disallow = all
allow = ulaw,alaw
dtmf_mode = rfc4733
direct_media = no
rtp_symmetric = yes
[phone-auth](!)
type = auth
auth_type = userpass
password = Pa$$w0rd
[phone-aor](!)
type = aor
max_contacts = 1
default_expiration=600
qualify_frequency=150
authenticate_qualify=yes

[115](phone-endpoint)
auth = 115
 aors = 115
[115](phone-auth)
username = 115
[115](phone-aor)

[423](phone-endpoint)
auth = 423
 aors = 423
[423](phone-auth)
username = 423
[423](phone-aor)

[666](phone-endpoint)
auth = 666
 aors = 666
[666](phone-auth)
username = 666
[666](phone-aor)

queue.conf
[general]
persistentmembers = yes
autofill = yes
monitor-type = MixMonitor
shared_lastcall = no

[test]
setqueuevar = yes
ringinuse = yes
member => PJSIP/666,1,Test User

queuerules.conf / pjsip_notify.conf / pjsip_wizard.conf - defaults

115 added to queue by command from CLI:
CLI> queue add member PJSIP/115 to test penalty 1

By: Vyrva Igor (vigor1710) 2019-04-02 02:14:31.652-0500

The described problem also appears if the Member were registered in queue directly, but not added dynamically.

Also, this problem exists if the Membrane is added to the queue through the Dialplan:
same => n,AddQueueMember(test,PJSIP/${CALLERID(num)},1)
By: Vyrva Igor (vigor1710) 2020-01-22 04:48:42.992-0600

On the Asterisk version 16.7 the situation has not changed in any way
By: Vyrva Igor (vigor1710) 2020-02-28 07:06:09.450-0600

On the Asterisk version 16.8 the situation has not changed in any way
By: Vyrva Igor (vigor1710) 2021-02-08 07:46:01.955-0600

It is already 2021, and this problem is still not considered in any way.
By: Ivan Poddubny (ipoddubny) 2021-02-08 14:51:09.837-0600

Hi Igor. The issue remains open, which means the bug is acknowledged, simply no one has time to work on it.

I have looked at the code, my conclusions are below.

Every call executing the Queue application goes through 2 stages:
- waiting for a turn,
- calling queue members.

In the first stage, the call is caught in a loop in queue_exec -> wait_our_turn.
wait_our_turn calls is_our_turn on every iteration of its loop.
is_our_turn uses num_available_members to find how many members are available.
Finally, num_available_members uses is_member_available to determine if a member is available or not.
is_member_available considers "invalid" and "unavailable" as "not available" regardless of ringinuse value (and it makes sense).
When is_our_turn gets 0 from num_available_members, it concludes that it's not "our turn", and the call stays in wait_our_turn for another iteration.

A call to a queue where all members are unavailable never leaves the stage 1.
When at least 1 member is available, the call is proceeding to the stage 2, that calls try_calling in a loop.

The interesting call chain here is try_calling -> ring_one -> ring_entry -> can_ring_entry.
When ringinuse is NOT set, can_ring_entry selects only those members whose status is "not in use" or "unknown".
But when ringinuse IS set, members' statuses are completely ignored, and that's why calls are made to "unavailable" members too.
can_ring_entry / member_status_available should use the same logic as is_member_available (at the stage 1).
Ideally, there should be only one function used at both stages.

So, it shouldn't be hard to fix. I might try later when I have time, if nobody submits a fix before.