tldr: I need to route calls from a specific “individual” into their own path.
if I have CID Priority Route set to Yes
DID: Any
CID: _5558675309$
that CID should catch most forms of +15558675309, 15558675309, and 5558675309 in the inbound callerID, correct?
because of Course it doesnt… it seems that its not true regex / I cant “End of line” this…
_+?1?5558675309 might do that I need.
… so I cant have ?'s in my CID match…
Dial patterns are not general regular expressions. They are always anchored on the left, and variable length matches are only possible on the extreme right. $ and ? have no special meaning.
You can use character classes, or the special codes N ([2-9]), X ([0-9]), or Z ([1-9]).
Thanks!
and thats… incredibly frustrating.
so i need 3 inbound routes, per number, to properly catch/match +1, 1, and no-1 numbers?
The general advice is that you should canonicalise numbers. However I can only find suggestions of how to do this with custom dialplan, but they are very old, so I may have missed a more GUI oriented, more recent, way of doing this.
However, it looks as though no-one was suggesting alternatives to custom dialplan as recently as 2019:
I think if you add a . at the beginning it should match any character. So:
_.5558675309
Looking this back I realize you will probably still need another inbound route to match just 5558675309. The above is expecting some character beforehand.
edit: . is only meaningful as the final character in the pattern
. is only recognized as the last character. I believe this limitation exists to allow patterns to be matched with a minimum of backtracking, which is important because every dialplan line has to be pattern matched at run time.
thats where i get caught up.
I have trunks and DIDs from 4 different carriers (don’t ask…) and depending on which number was dialed, and what their origin country was, the same caller can come in 3 different ways.
I just want a straightforward way to route every call from bob to an inbound queue no matter which of our numbers they call.
You could send the inbound route to a DynRoute. In the Dyn route you may trim out characters from the CallerID or just create single entries for every possible CID, but easier.
coding my own solution seems like overkill for what (I think) should be a basic feature of pattern matching.
its honestly easier for me to implement your APIs in a web service that just calls the Add Inbound Route APIs three times.
its ugly as sin, but it’d work
The underlying pattern matching is done by Asterisk, and is optimised for directly working with dialplans. When doing that, it only takes a small number of extra lines of code to canonicalise numbers, compared with the over 100 that FreePBX uses when processing a typical call.
Asterisk supports +?1? optional tags in patterns though.
The from-pstn-e164-us context will handle 2/3 of your DID patterns. Maybe copy it and add your third one (1NXXNXXXXXX) and send inbound calls to your custom context. Then use just the 10-digit pattern in your inbound routes.
[Summoned from my Friday afternoon slumber …]
So as you’ve learned the dial patterns in inbound routes and elsewhere in FreePBX are not regex’s. Patterns can contain digits, * ,# ,N, Z, X and a few other chars. The ! and . are only meaningful as the final character of a pattern.
If the CID/DID format changes depending on provider, one thing you can do in Can/US is to set all your trunks to use context from-pstn-e164-us which will normalize inbound CID/DID to 10 digits. On existing systems that may mean touching all your routes tho, so you may want to write your own context to only touch the things you want. Once CID/DID is normalized, then a single inbound route with a single CID match pattern will work for all providers.
No, it just ignores numbers that don’t match NANP number format.
Ignores = “does not modify”?
Yes, non-NANP DID/CID are passed directly to dialplan without modification.
Asterisk has two ways in which patterns can be invoked. One is the core dialplan interpreter, which is where the _ prefix patterns come from. That does not support a ? operator, but the patterns are precompiled, to allow a parallel search of all the patterns. The other is a standard posix style regular expression, which is invoked via functions and expressions. That has to be compiled every time, doesn’t result in one of several patterns being recognized, and can involve, expensive, back tracking. That does support ? operators.
Anywhere in FreePBX that accepts a plain number or a pattern starting with _ is using the first mechanism, internally.