I am using Asterisk 11.10
ringinuse=no is not working in Asterisk realtime which results queue member is getting 2 calls
example: if one agent is busy but still agent getting waiting calls…
Is this a bug? or am I doing something wrong?
See recent answers on similar subjects. You have probably not enabled callcounters so Asterisk doesn’t know that there are multiple users of the device.
Also note that version 11 is not suitable for new installations as it went to security fixes only last month. If you have to use Asterisk 11, you should be using 11.24.1.
Thanks for the updates
In full Realtime I set callcounter=yes in sip_reg table but still no luck and showing the below stats while 1001 is on call
SIP/10001@SIPTRUNK (SIP/10001 from SIP/10001) (ringinuse disabled) (realtime) (Unavailable) has taken 3 calls (last was 1246 secs ago)
You will only get device states for the “trunk”, not for the individual number. I would guess that, because your full member address doesn’t match the trunk name, it won’t have any device state information associated with it.
(Even if the queue system knew whether Asterisk was accessing the end device, and that the end device was a single device, not a hunt group, it could not tell if the device was being made busy from something other than the current Asterisk system.)
I have sent one peer for example and I have 5 peers like this same status showing ringinuse disabled
“disabled” is just how it presents “no”. Therefore it is what you would expect for ringinuse=no, and has nothing to do with the actual member. The reason it isn’t working is that your member isn’t a simple local device.
Then why it is showing (Not in use) while 1002 is in talking mode and the 2nd call is still attempting on 1002
SIP/10002-00000010 connected line has changed
SIP/10002-00000010 is ringing
SIP/10002@SIPTRUNK (SIP/10002 from SIP/10002) (ringinuse disabled) (realtime) (Not in use) has taken 3 calls
(last was 1248 secs ago)
If you really have call limits properly configured, the issue will be with chan_sip as it applies this logic:
/* Check status in this order
- Hold
- Ringing
- Busy (enforced only by call limit)
- Inuse (we have a call)
- Unreachable (qualify)
If we don't find any of these state, report AST_DEVICE_NOT_INUSE
for registered devices */
and therefore defaults to not in use.
Looking at the code, it strips the digits, so, as noted before, anything using SIPTRUNK1 should make it appear busy, which is probably not what you want.
I’d suggest using the CLI device state enquiry command to see what chan_sip really thinks the state of the “trunk” is, and to use “sip show peer” to see if the call limit feature is enabled.
You may also want to check whether the parameter was actually called callcounter in version 11. The name was changed to this because the original name represented a deprecated feature.
In Asterisk 11 I guess call limit does not work
Both call-limit and callcounter are accepted by 11.10.0 (there is no 11.10). That’s true for at least configuration files. I don’t know my way around realtime enough to work out whether they can be set from realitme, but would note that realtime is not, as far as I know, covered by the core support for Asterisk, so may well lag considerably.
Ok Thanks, Mine is 11.10.2 But I found this is a bug
https://issues.asterisk.org/jira/browse/ASTERISK-16115 and no solution so far…We stucked
That bug is recorded as fixed, although not in any Asterisk 11.x version, and now never will be. (Note the sub-version of 11 you should be using is 11.24.1; I looked at the SVN versions and that cut off at 11.17.
There is recent discussion, with a suggestion to raise a new issue.
I have installed 11.24.1 also to test the ringinuse issue but same results
The issue report says it isn’t fixed in version 11. As version 11 is now security fixes only, it will not be fixed in version 11.
So which version is stable to use and bug free?
Asterisk versions are documented here:
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
All software can have bugs. If you mean software that doesn’t have the particular bug that you referenced, the issue itself documents what versions it was fixed in:
If you aren’t running one of those versions or later, than I’d expect you to run into that bug. If you are running one of those versions or later and you experience that issue, then I would open a new issue on the issue tracker.
Finally, all software can have bugs, despite the best efforts of its maintainers. If you expect software to never have a bug - ever - you are going to lead a very disappointing life.
1 Like
@mjordan for your info
Today I installed 11.23.0
Connected to Asterisk 11.23.0
But still ringinuse not working as the agent is in talking mode and the below is showing by queue show command
Members:
SIP/1001@EURUS (SIP/1001 from SIP/1001) (ringinuse disabled) (realtime) (Not in use) has taken no calls yet
No Callers
So tomorrow I will install 13.10.0 as you recommended
If you read the full article here https://issues.asterisk.org/jira/browse/ASTERISK-16115
you will find that is not solved yet and Joshua Colp added a comment - 03/Jun/16 5:03 PM
A new issue should be created.So may be that is why 11.23.0 is also not working
FYI.
I tried using 13.8-cert2 and following are the below result but the issue is member is to re-register always to take a call
but the good thing is member status is updating
SIP/10501@TRUNK (SIP/10501 from SIP/10501) with penalty 1 (ringinuse enabled) (realtime) (in call) (Not in use) has taken 6 calls (last was 34 secs ago)
Hello all, it’s your old pal Sherwood McGowan (although, I’ve been out of touch with the community for some time, so you probably don’t know me).
I’ve used Queues rather extensively and utilized the realtime architecture with those queues. I do remember performing a little voodoo to make sure that the Agent would not receive calls, and since I’m actually working on a call center setup now it’s the perfect time to revisit this.
I’ll post my theoretical solution soon, after I review some of my old code, and hopefully that will help. If not, once I get testing in place on some of the Queue and Agent handling code, I’ll post a final working example that should show how to avoid this issue.
Please keep in mind, I most likely will post a solution that works for agents who are members of a single queue, as that should be enough to get everyone started on a working solution that could guarantee multiple queues could be set to not call an agent who is a member of said queues and is on a call from a single one of those queues.
Slainte!
Sherwood McGowan
1 Like