Using realtime configuration as below:
Queue:
name | timeout | ringinuse | retry | autopause | strategy | joinempty | timeoutrestart |
---|---|---|---|---|---|---|---|
Support | 20 | yes | 10 | no | ringall | yes | yes |
Endpoint:
id | transport | aors | auth | context | disallow | allow | send_pai | callerid | inband_progress | device_state_busy_at | dtls_auto_generate_cert | webrtc |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1004 | transport-wss | 1004 | 1004 | internal | all | opus,alaw | yes | Flamur Dervishi <1004> | yes | 2 | yes | yes |
In the Queue configuration we are using the option ringinuse=yes and in the endpoint configuration device_state_busy_at=2.
Reading queues.conf option descriptions:
; 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. This can be controlled on a per member basis by
; setting ‘ringinuse’ on that member. This can be done in the member definition,
; in the ‘ringinuse’ field on a realtime member, via the QUEUE_MEMBER dialplan
; function, or with CLI/AMI. By default, the per member value will be the same
; as the queue’s ringinuse value if it isn’t set on the member deliberately.
; (Note: only the SIP channel driver currently is able to report ‘in use’.)
; ringinuse = no
We noticed that the Busy device state seems to be considered as ‘In use’ device state.
So we would expect that ‘ringinuse’ option would respect the ‘device_state_busy_at’ when deciding to pass a call through or not.
As workaround, we used Local channels as interface in the queue to manage the call from the dialplan by checking the device state.
Is this the normal behaviour of these 2 options or are we missing something ?