Is this non-existent destination for Gosub Error spam in Asterisk normal?

Hi!

Are you using Dialing Permission feature for incomming calls? Can you tell if calls to 1248555555 are going through?

Hi Volodya, yes we are using dialing permissions on a tenant level (blocking known spam caller numbers).
Most calls to the 12485555555 number seem to be going through, but I can't find any calls coming in that would match the timestamp of this error, but I do see where it will have this error between 1 and 3 times about 7 or 8 seconds before a call is registered in the CDR. Which worries me that this is causing some kind of long delay for inbound calls. During the times where it spams 3 times, there's a new log id and channel id like in this one..

[2017-12-04 15:48:30] ERROR[3513][C-0001795f] app_stack.c: Attempt to reach a non-existent destination for Gosub: (Context:tl-check-inbound-acl-AnotherTenant, Extension:12484444444, Priority:1)
[2017-12-04 15:48:34] ERROR[3537][C-00017961] app_stack.c: Attempt to reach a non-existent destination for Gosub: (Context:tl-check-inbound-acl-AnotherTenant, Extension:12484444444, Priority:1)
[2017-12-04 15:48:37] ERROR[3553][C-00017962] app_stack.c: Attempt to reach a non-existent destination for Gosub: (Context:tl-check-inbound-acl-AnotherTenant, Extension:12484444444, Priority:1)

Then the call finally seemed to come through at 2017-12-04 15:58:39. This DID only got one call that day so should I assume the caller either had to wait 9 seconds for the call to route, or that they possibly had to call 4 times before it went through??

One thing I did notice, is that under the system Telephony Settings, there's no entry for inbound permissions, but at the tenant level, there is the default allow permission of "_X." . Should this be entered in the system level dialing permissions as well? ("System Management" > "Telephony Settings" > "Dialing Permissions" > "Inbound")

Correction, the call finally came through at 2017-12-04 15:48:39, not 2017-12-04 15:58:39 (Cant edit post)

Please execute dialplan show tl-check-inbound-acl-TENANT_NAME command in Asterisk's CLI at the time when you will be getting those errors. And post the output.

Thanks.

All tenants seem to show the same thing for that, currently we've seen the error happen about 80 times so far today with 2 more tenants

[ Context 'tl-check-inbound-acl-TENANT_NAME' created by 'pbx_config' ]

'_X.' (CID match '_X.') => 1. Return(1) [pbx_config]

-= 1 extension (1 priority) in 1 context. =-

Can you confirm that dialplan line from below was present for the exact tenant which was having the problem?

'_X.' (CID match '_X.') => 1. Return(1) [pbx_config]

Can you also tell if there were changes affecting dialplan, made during that time?

Yes I confirmed that the tenants having the problem all have that line when running dialplan show tl-check-inbound-acl-TheTEnantName

I don't know of any dialplan changes done other than what has been done automatically via the GUI

What should I try next?

Please do the following:
1. Check /etc/my.cnf configuration file. Check if you have log_slow_queries option. If yes - replace it with slow_query_log_file and add slow_query_log = 1. Then restart mysqld service (during non-working hours) and look if you will get entries in /var/log/mysql-slow-queries.log log file at the time when you will see the problem.

2. Check if you will find WARNINGs from func_odbc.c in Asterisk's CLI. It could be something like this:
[2017-12-13 19:06:21] WARNING[22312][C-00000002]: func_odbc.c:191 generic_execute: SQL Execute returned an error -1: 08S01: [MySQL][ODBC 5.1 Driver][mysqld-5.1.73-log]MySQL server has gone away (69)
[2017-12-13 19:06:21] WARNING[22312][C-00000002]: func_odbc.c:199 generic_execute: SQL Exec Direct failed (-1)![call tenantinfo('test')]
[2017-12-13 19:06:21] WARNING[22312][C-00000002]: res_odbc.c:604 ast_odbc_direct_execute: SQL Execute error! Verifying connection to pbxconf [pbxconf]...
[2017-12-13 19:06:21] WARNING[22312][C-00000002]: res_odbc.c:757 ast_odbc_sanity_check: Connection is down attempting to reconnect...
[2017-12-13 19:06:21] NOTICE[22312][C-00000002]: res_odbc.c:1529 odbc_obj_connect: Connecting pbxconf

K will do, I'll post results. In the meantime, could this possibly be related to the custom context we had to create to get Voip Innovations Trunks to work on Thirdlane?
[from-voipinnovations]
exten => _X.,1,Set(CALLERID(num)=${CALLERID(num):-10})
exten => _X.,n,Goto(from-outside,${EXTEN},1)
exten => _+X.,1,Set(CALLERID(num)=${CALLERID(num):-10})
exten => _+X.,1,Goto(from-outside,${EXTEN},1)

I think I'm onto something, when inbound calls come in with the Caller's Caller ID coming in as "__INCOMINGCLI=+12487655555" the call gets rejected, when it comes in like this "__INCOMINGCLI=2487655555" either from the trunk or by that custom context that removes the + and Country code, the call comes through fine

Hello,

Please check from-voipinnovations context from Asterisk itself by running dialplan show from-voipinnovations.

In your previous post you wrote:
exten => _+X.,1,Set(CALLERID(num)=${CALLERID(num):-10})
exten => _+X.,1,Goto(from-outside,${EXTEN},1)

You have two dialplan applications for same pattern with same priority. You should change priority in second line from 1 to 2 or n.

[ Context 'from-voipinnovations' created by 'pbx_config' ]
'_+X.' => 1. Set(CALLERID(num)=${CALLERID(num):-10}) [pbx_config]
'_X.' => 1. Set(CALLERID(num)=${CALLERID(num):-10}) [pbx_config]
2. Goto(from-outside,${EXTEN},1) [pbx_config]

-= 2 extensions (3 priorities) in 1 context. =-

Ah I see, it seems to be working luckily but I want to make sure it's correct so I should have it set like this?

[from-voipinnovations]
exten => _X.,1,Set(CALLERID(num)=${CALLERID(num):-10})
exten => _X.,n,Goto(from-outside,${EXTEN},1)
exten => _+X.,1,Set(CALLERID(num)=${CALLERID(num):-10})
exten => _+X.,n,Goto(from-outside,${EXTEN},1)

Also ,is it normal to have TL reject calls from trunks that send caller ID with "+" in front of the number?

Hi!

Yes, from-voipinnovations context is now correct.

Default configuration has single Allow rule for _X. Caller ID Pattern. You need to add similar one with the except of pattern. It should be _+X.