Caller id not matching in extensions

I am migrating from an old FreePBX setup working for the last 5 years, to a new one setup in Debian using this guide:
https://wiki.freepbx.org/display/FDT/How+to+Install+FreePBX+16+on+Debian+11+with+Asterisk+16

I am in the process creating new config based on my old one, almost line by line in order to check things.
I noticed that chan_sip is no longer used by default, so I setup PJSIP with two PJSIP trunks, custom contexts, a couple of extensions and made succesful calls through trunks and local extensions.
I experience a strange problem matching caller id:

extensions_custom.conf:
[from-ser]
exten => _6999,1,NoOp(Call from ${CALLERID(num)} to ${EXTEN} )
exten => _6999,2,Dial(PJSIP/6999)

This works fine:

-- Executing [[email protected]:1] NoOp("PJSIP/spock-0000006d", "Call from 6789 to 6999 ") in new stack
-- Executing [[email protected]:2] Dial("PJSIP/spock-0000006d", "PJSIP/6999") in new stack

but when i also try to match a caller ID, 6789 in this specific case, INVITE fails:

extensions_custom.conf:
[from-ser]
exten => _6999/_6789,1,NoOp(Call from ${CALLERID(num)} to ${EXTEN} )
exten => _6999/_6789,2,Dial(PJSIP/6999)

NOTICE[45637]: res_pjsip_session.c:4027 new_invite: spock: Call (UDP:192.168.28.99:5060) to extension '6999' rejected because extension not found in context 'from-ser'.

There is this issue open[1] for it.

[1] https://issues.asterisk.org/jira/browse/ASTERISK-28767

1 Like

Thank you @jcolp. This seems very critical and impacts many things apart from call routing. For example, restricting calls by matching caller id, or number rewriting is impossible with PJSIP.
So, as far as I understand, there is no workaround until a patch is released?

Why are you using the pattern match trigger for exact matches? You don’t need the _ in the match when it is exact. So nothing matches which is why you get this:

Any information including workarounds or working patches would be on the issue, unless someone has opted not to provide such information.

Fix your dialplan first then see if this is a bug.

The dialplan is sub-optimal, but not wrong. The effect of the pattern matching operator is that the matching process will be less efficient, and will match numbers containing certain punctuation characters, like “-”, but it won’t prevent pure numbers matching.

I’m surprised I haven’t run into this bug (ASTERISK-28767) before and also surprised we have not seen reports in the FreePBX issue tracker since this type of dialplan is used in places. I just did a bit of testing on FreePBX and see now why I’ve never been affected. Initially I was unable to repro this because I kept the extensions in the default FreePBX from-internal context and created the testing dialplan in the [from-internal-custom] context. Set up this way, the dialplan works as expected, nothing I try will trigger the issue. Once I change the extension and dialplan context to match the example given, then the issue appears.

This may be a work around or possible clue to what’s going on. It looks like some arrangement of context includes used in FreePBX negates this bug.

It’s basically if priority 1 is a callerid match only. If it’s non-callerid, then all works fine and subsequent priorities will match based on callerid.

Found a work around. This dialplan is working for me:

[from-ser]
include => from-ser1
exten => _6002/_6006,1,NoOp(Call from ${CALLERID(num)} to ${EXTEN} )
exten => _6002/_6006,2,Dial(PJSIP/6002)

[from-ser1]
exten => _X.,1,Hangup

I’m using different extension numbers, but the above works as expected. As soon as you comment out the include line, it goes back to not working again.

@BlazeStudios As mentioned by other users, this is not a pattern match problem, the problem also persist without using the underscore.
@lgaetz Thanx, seems I will go this way, I will use from-internal-custom context instead of a custom one, I tried to make my config more clear by using custom contexts but seems that this will not be fixed quickly.