I have a system that is at Asterisk 13.11.2 and Fpbx 13.0.188.9. The system is being used in Device and User mode. We have 10 drs with two staff people rotating between 6 office locations. All of the Drs calls are going to Ques from an IVR. I have one Que that is giving me fits. One user of one Dr will get the Que calls of another Dr AND also get her Dr calls as well. There is no evidence of the call being sent to the user, Not in any log files, nor CDR report. I removed the que and rebuilt it. We have had the users log out of the system and log back in. This system was upgraded to 13 from 2.10 using System Admin. Could something go awry then? Before the upgrade this was not an issue. Any ideas what is going on?
Can you transcribe/screenshot your queue configuration and post it here or on pastebin or imgbin or something so we can have a look (obfuscate your private info obviously )
Sorry for the long absence. REALLY busy week. I think it isn’t a Que issue at this point. It looks like the device has two users associated with it. Re:
The extension 137 is the test calling extension. 117 is the user that is getting the erroneous calls. 185 is the extension that has their calls go to 117.
If 137 dials 185 the call goes to 117
If 137 dials 117 the call goes to 117
The CDR report shows both calls going to device 3117 which is the device in question. We have put in *12 to log out and then we did a *11 117 to log 117 back in. I am going to do several *12 to see what happens. I will report back what happens
The que is 656 but I think that the que was just the method by which the problem manifested itself. They initially complained that outide calls were doing this. As I posted, it happens on phone to phone calls… Is there a possibility that user 185 is forwarded to 117? If I could figure out which device has 185 assigned to it I could remove a forward if that is the case.
can you go to your Asterisk Info page and see what the Queues tab would display w/r/t the USERS in question?
E.g. I have
200 has 0 calls (max unlimited) in 'ringall' strategy (3s holdtime, 116s talktime), W:0, C:12, A:0, SL:100.0% within 30s
Members:
26 Agent1 (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (Not in use) has taken 2 calls (last was 9117 secs ago)
22 Agent2 (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (Not in use) has taken 3 calls (last was 2256 secs ago)
31 Agent3 (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (Not in use) has taken 7 calls (last was 1352 secs ago)
21 Agent4 (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (Not in use) has taken no calls yet
.
.
.
No Callers
And then, go to Chan_SIP info on that same page and see what Chan_Sip Peers is showing…
[ I actually run a bit non-standard d&u in the sense that I have configured SOME of my devices to have same numerical ID as the users]
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
21/21 X.Y.Z.H1 D Yes Yes A 5060 OK (18 ms)
22/22 X.Y.Z.H2 D Yes Yes A 5060 OK (7 ms)
26/26 X.Y.Z.H3 D Yes Yes A 5060 OK (9 ms)
31/31 X.Y.Z.H4 D Yes Yes A 5060 OK (8 ms)
(the above are actually obtainable as outputs from asterisk command line but you probably need to use man asterisk more to get more than that…)
There is no device for 185, it is a user that moves around. So the Chan/Sip won’t help. There is one extension that has 185 as the user, I just stumbled upon that. I will have them log out on that device.
Here is the Ques that 117 and 185 are in from the info page
656 has 0 calls (max unlimited) in ‘ringall’ strategy (14s holdtime, 160s talktime), W:0, C:783, A:21, SL:92.7% within 60s
Members:
Natalie (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (Not in use) has taken no calls yet
Sue D (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (Not in use) has taken 18 calls (last was 7447 secs ago)
Mary (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (Not in use) has taken 28 calls (last was 7730 secs ago)
No Callers
658 has 0 calls (max unlimited) in ‘ringall’ strategy (4s holdtime, 119s talktime), W:0, C:270, A:5, SL:95.9% within 60s
Members:
Robbin (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (Not in use) has taken 12 calls (last was 11973 secs ago)
Holly (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (In use) has taken no calls yet
Kathy (Local/[email protected]/n from hint:[email protected]) (ringinuse enabled) (In use) has taken 12 calls (last was 8532 secs ago)
No Callers
By all means, please post the output of chan/sip registrations (i.e. your registered devices), when users are logged on, and when they are logged off too.
Even if just to confirm that it’s all correct there.
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
1280/1280 172.28.200.101 D Yes Yes A 5060 OK (9 ms)
1281/1281 172.28.200.101 D Yes Yes A 5062 OK (8 ms)
1282/1282 172.28.200.101 D Yes Yes A 5064 OK (8 ms)
1283/1283 172.28.200.101 D Yes Yes A 5066 OK (7 ms)
1284/1284 172.28.200.101 D Yes Yes A 5068 OK (8 ms)
1285/1285 172.28.200.101 D Yes Yes A 5070 OK (8 ms)
1286/1286 172.28.200.101 D Yes Yes A 5072 OK (8 ms)
1287/1287 172.28.200.101 D Yes Yes A 5076 OK (7 ms)
1288/1288 172.28.200.101 D Yes Yes A 5078 OK (7 ms)
3100/3100 172.28.200.186 D Yes Yes A 5062 OK (41 ms)
3101/3101 172.28.200.139 D Yes Yes A 5062 OK (20 ms)
3102/3102 172.28.200.118 D Yes Yes A 5062 OK (76 ms)
3103/3103 172.28.200.137 D Yes Yes A 5062 OK (21 ms)
3104/3104 172.28.200.143 D Yes Yes A 5062 OK (29 ms)
3105/3105 172.28.200.142 D Yes Yes A 5062 OK (23 ms)
3106/3106 172.28.200.179 D Yes Yes A 5062 OK (28 ms)
3108/3108 172.28.200.147 D Yes Yes A 5062 OK (24 ms)
3109/3109 172.28.200.173 D Yes Yes A 5062 OK (20 ms)
3110/3110 172.28.200.101 D Yes Yes A 5074 OK (8 ms)
3111/3111 172.28.200.155 D Yes Yes A 5062 OK (24 ms)
3112/3112 172.28.200.154 D Yes Yes A 5062 OK (22 ms)
3114/3114 172.28.200.169 D Yes Yes A 5062 OK (28 ms)
3115/3115 172.28.200.198 D Yes Yes A 5062 OK (26 ms)
3116/3116 172.28.200.172 D Yes Yes A 5062 OK (33 ms)
3117/3117 172.28.200.171 D Yes Yes A 5062 OK (68 ms)
3118/3118 172.28.200.176 D Yes Yes A 5062 OK (27 ms)
3119/3119 172.28.200.167 D Yes Yes A 5062 OK (22 ms)
3120/3120 172.28.200.165 D Yes Yes A 5062 OK (28 ms)
Thanks.
So, other than possibly checking whether the 2 devices in question use unique (not the same) secrets etc…, then maybe making use of asterisk -vvvvvvvvvvvr (more v’s more detalis) in one terminal (ssh) session, and looking at ngrep with SIP filters and per IP in another terminal (ssh) session, possibly analyzing some more detailed asterisk logs (but that would be same as asterisk -vvvvvvvvvvvvr (so you don’t get overwhelmed by the network stream of consciousness) I can’t think of much else… I’d need to call in @staff
on the other hand, the ngrep tool is pretty fantastic (it helped /me/ once upon a time)
Mostly by reading man ngrep and googling for answers…
but here are some examples of what I used it for
ngrep port 5060 -T some-string
ngrep -T my-trunk-provider port 5060
ngrep port 5060 -W byline match "REGISTER"
ngrep -T "(REGISTER).*(mytrunkprovider)|(401 Unauthorized).*(mytrunkprovider)" port 5060
Hope this helps
Basically ngrep is like wireshark, only you run it on the server itself so it can catch ALL communications relevant to the server; with the regular expressions you can filter what you are looking for - to see what server is receiving from your phones and see what it actually sends to phones; then you compare it with what you expect from your config;
To Me - it helped finding out what was the cause of inbound calls not working with my setup of my SIP provider
Anectode: so my SIP provider has free-form SIP account names to register with, and maps public DIDs to them; but then it emerged (from looking at the ngrep stream, actually) that on incoming call, they were sending calls to [email protected], not to [email protected] - which the inbound route setup was expecting; wasn’t possible to make it use numericdid without ‘serious meddlin’; I had to tell the inbound routes to accept TheFreeFormAccountName as DID… and then it all worked.
Using ngrep I will definately keep up with. I finally figured it out. User 185 was forwarded to 117 ! It wasn’t until I was there when the user was logged in and I could actually put my hands on that device that I figured it out. It had been forwarded for over a month. So the issue wasn’t with the que at all. Ugh, some user I just want to kick to the curb.
Makes me think: would it be something they might have dialed by mistake (e.g. similar to a feature code for Call Forward) that had this effect ?
(some devices have the integration of CF and other codes built in/selectable through their config as internal or external/pbx)
)