Calls going to wrong DID and ring groups

1

Friday everything was fine, but today, we’re experiencing an issue where incoming calls are randomly going to the wrong ring group.

For example: this call should have went to ring group 1015, instead it went to ring group 2020 & it is showing the call in to DID: 6825555555 (masked for security), but the number the client actually dialed is a different one of my DID’s: 817-83x-xxxx.

[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] pbx.c: Executing [in@sub-record-check:3] ExecIf(“SIP/vitelity-inb-trunk1-000127c5”, “10?Set(FROMEXTEN=8175555555)”) in new stack
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] pbx.c: Executing [6825555555@from-trunk:8] ExecIf(“SIP/vitelity-inb-trunk1-000127c5”, “0 ?Set(CALLERID(name)=8175555555)”) in new stack
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] pbx.c: Executing [6825555555@from-trunk:20] Set(“SIP/vitelity-inb-trunk1-000127c5”, “__CRM_SOURCE=8175555555”) in new stack
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@macro-user-callerid:2] Set(“SIP/vitelity-inb-trunk1-000127c5”, “AMPUSER=8175555555”) in new stack
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@macro-user-callerid:4] ExecIf(“SIP/vitelity-inb-trunk1-000127c5”, “1?Set(REALCALLERIDNUM=8175555555)”) in new stack
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@macro-user-callerid:37] Set(“SIP/vitelity-inb-trunk1-000127c5”, “CALLERID(number)=8175555555”) in new stack
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@macro-user-callerid:41] Set(“SIP/vitelity-inb-trunk1-000127c5”, “CDR(cnum)=8175555555”) in new stack
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@sub-record-check:18] NoOp(“SIP/vitelity-inb-trunk1-000127c5”, “Generic rg Recording Check - 8175555555 2020”) in new stack
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@macro-dial:2] Set(“SIP/vitelity-inb-trunk1-000127c5”, “__CRM_SOURCE=8175555555”) in new stack
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] res_agi.c: dialparties.agi: Caller ID name is ‘ALVARADO TX’ number is ‘8175555555’
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] res_agi.c: dialparties.agi: dbset CALLTRACE/2001 to 8175555555
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] res_agi.c: dialparties.agi: dbset CALLTRACE/2002 to 8175555555
[2019-05-20 09:43:09] VERBOSE[19972][C-0000833e] res_agi.c: dialparties.agi: dbset CALLTRACE/2003 to 8175555555
[2019-05-20 09:43:29] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@macro-user-callerid:2] Set(“SIP/vitelity-inb-trunk1-000127c5”, “AMPUSER=8175555555”) in new stack
[2019-05-20 09:43:29] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@macro-user-callerid:4] ExecIf(“SIP/vitelity-inb-trunk1-000127c5”, “0?Set(REALCALLERIDNUM=8175555555)”) in new stack
[2019-05-20 09:43:29] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@macro-user-callerid:37] Set(“SIP/vitelity-inb-trunk1-000127c5”, “CALLERID(number)=8175555555”) in new stack
[2019-05-20 09:43:29] VERBOSE[19972][C-0000833e] pbx.c: Executing [s@macro-user-callerid:41] Set(“SIP/vitelity-inb-trunk1-000127c5”, “CDR(cnum)=8175555555”) in new stack

So I placed a test call & it came thru just fine to the correct ring group. So it is random/intermittent? How to troubleshoot this?

2

btw, we’re running fpbx: 10.13.66-20

3

correction: 10.13.66-19

4

You didn’t include the DID selection part of the log, so I’m going to guess that this went to your “any/any” Inbound Route.

Double check your inbound route DID. It has to match the call’s DID exactly. No extraneous “1” or “+” or “0” or “llama” or anything. The DID in the Inbound Route will only match when you have an exact match.

Also, make sure you aren’t using CID instead of DID. If you set the CID, the only things that will match that are calls from specific callers.

5

Good ideas Dave, but all of that is straight. It turns out it was on the carrier side, they claim there was a port out of 2 of my DID’s, but yet the calls are routed to two other of my DID’s that were not in use. Strange stuff, but I put a PIN on my account with the carrier & now, hopefully no one can port out my DID’s without my knowledge. Very weird because I have accounts with both the losing carrier and the unauthorized porting in carrier.

6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.