There is no existence of 123@testing extension

Asterisk Asterisk Dialplan
1

I’ve configured Asterisk 20.0.1 as a simple test PBX to use Realtime chan_pjsip via odbc.

extconfig.conf

[settings]
ps_endpoints => odbc,asterisk
ps_auths => odbc,asterisk
ps_aors => odbc,asterisk
ps_domain_aliases => odbc,asterisk
ps_endpoint_id_ips => odbc,asterisk
ps_contacts => odbc,asterisk
ps_extensions => odbc,asterisk

extensions.conf

[testing]

switch => Realtime/@

modules.conf

[modules]
autoload = yes

Database table extensions:

Screenshot from 2023-01-17 17-02-47
Screenshot from 2023-01-17 17-02-47792×160 11.6 KB

Test for extension:

PBX2CLI> dialplan show 123@testing
Alt. Switch => ‘Realtime/@’ [pbx_config]
There is no existence of 123@testing extension
Command ‘dialplan show 123@testing’ failed.
PBX2CLI>

What am I doing wrong?

2

_x. exten pattern it means any dial number even 123.

3

I’m aware of that, but as seen from the error, even that pattern doesn’t match the extension 123. I’ve added the 3rd entry just out of curiosity if it’ll match it.

4

Paste the cli raw information.
Dialplan execution it finishes on second stage “Dial” application. If _x. pattern match with 101 it goes to extension 101, others pattern it will fail and channel will release and stop.
In both case it will never reach to the third stage.

5

The changes in the dialplan are recognized properly now. Seems that the restart of the PBX daemon fixed it.

6

Asterisk should ALWAYS pick the MOST specific match, when matching extensions in the dialplan, regardless of their order. Unless there’s something I’ve misunderstood.

7

Perhaps reloading the dialplan would had been enough?

You can reload it by typing the following in the console:

dialplan reload

8

That’s what I’m saying when I refer to pattern “_X.”

9

But if you have the following in your dialplan

[ctx1]

exten => _X.,1,Log(VERBOSE,Generic destination)
 same => n,Hangup()

exten => 123,1,Log(VERBOSE,123 Extension)
 same => n,Hangup()

Asterisk will ONLY go through 123, not _X.

That’s what I mean when I say picks the MOST specific. _X. is LESS specific than 123, even though both of them will match.

A dialplan reflecting the above database would look like this:

[testing]
exten => _X.,1,NoOp(Yeah, test!)
 same => n,Dial(PJSIP/101)

exten => 123,1,NoOp(whatever)

I don’t remember if Asterisk has fallthough, but I think they removed that WAY back around 1.2 or 1.4, so let’s assume there’s no fall through.

With the context testing as above, running dialplan show 123@testing in the console, should display both the steps for 123 and the steps for _X., but when actually CALLING 123 only the steps for 123 should be executed. (If I’m remembering wrong and Asterisk DOES fall through, it will first execute the steps in 123, then continue with _X.)

10

Longer matches, and matches with without wildcards should take precedence, so 123 should match here.

11

Yes, as exten 123 does not have set app it will assume previous as _x. Dial app.

12

Extension 123 has 1 line of dialplan…

exten 123,1,NoOp(whatever)

And as such, when dialing 123, this is what should be executed, NOT whatever is defined by _X.

So with the above dialplan, if you dial 123, the dialplan for _X. will NEVER be executed.

If you dial anything BUT 123, the dialplan for _X. will be executed.

A flow in the dialplan does NOT need to use the Dial application at all, I have several flows in my setup, that never runs dial. Some doesn’t even answer the channel.

1 Like
13

That’s true when you have “same => n,Hangup()” , but based on original dialplan question, NO.

14

So… Just setup a simple test… I made this dialplan:

exten => 111111,1,NoOp(A:${EXTEN})
exten => _11111.,1,NoOp(B:${EXTEN})
exten => _1111.,1,NoOp(C:${EXTEN})
exten => _111.,1,NoOp(D:${EXTEN})
exten => _11.,1,NoOp(E:${EXTEN})
exten => _X.,1,NoOp(F:${EXTEN})

Then I dialed 111111, my console output was this:

    -- Executing [111111@<REDACTED>:1] NoOp("PJSIP/<REDACTED>-00000005", "A:111111") in new stack
    -- Auto fallthrough, channel 'PJSIP/<REDACTED>-00000005' status is 'UNKNOWN'

On the SIP level, the call is rejected with a 603 Decline response.

From what I understand you said, this example should result in AT LEAST 111111 and _X. being executed, and if it’s falling through from most to least specific, all of them, in the order written here, should be executed.

That just isn’t what I observe.

15

_X.,2 (which is what the second exten line equates to) will match the second priority for 123, but _X.,1 will not match the first priority.

16

Seriously? Who got that bright idea?

It doesn’t really seem intuitive, that it can continue at a “random” priority for another extension, just because it happens to match the expression. I did not test that variant, but it sounds like something that might very well be true.

Pure luck I haven’t encountered that before.

17

It’s not really random. It goes to the next priority, or the explicit priority if you’re jumping yourself. At that priority the closest match is used.

It’s honestly been that way since before I was part of the project, so the history is probably lost to time.

18

NoOp application only prints its line arguments to the console without any process related to the call.

19

Yeah, i know it’s not truly random, hence the quotes. But if you’re not aware of this behavior, it could easily feel random.

Seems like a case of either “Seemed like a good idea at the time”, “Didn’t think of that as a problem” or “It’s always been like that, better not change it”.

But certainly something worth keeping in mind, when designing dialplans. With all the crazy stuff I’ve made, I guess I’ve just been lucky for this never to interfere with what I’ve made. :wink:

20

True, but that’s still ALL you need to figure out how the dialplan is processed. But from what others have added, I think I get how it works, even though it makes no sense why it’s implemented like that.