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.
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.)
-- 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.
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.
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.