Incoming DID not matching catch-all if an extension with that DID number exists

FreePBX Configuration
1

Apologies for the lengthy subject.

I’m having some issues with incoming DIDs not matching a catch-all rule if there’s an extension with the same number. Incoming calls are being routed to that extension rather than matching the catch-all rule.

For example: I have internal extensions 201-209. I also have a PRI that sends DIDs in the 100-800 range. I do not actively use all of them so I have a catch-all rule to match so my operators can answer accordingly.

Some of the DIDs I’m not using fall into the same range as my extensions (203, 204 and 208, to be specific). Incoming calls on my PRI that match those DIDs are being routed to the extension rather than the catch-all queue. The other DIDs that have an inbound route AND are in the range of my extensions ring through properly to their respective queues.

The short fix is to add inbound routes for those DIDs, but I’m curious why this is happening in the first place.

Any help would be greatly appreciated.

Thanks,
Jay

2

You have a route matching, obviously.

Inbound routing is most specific match.

DID + CID match then
DID + Any match then
CID + Any match then
Any + Any match.

3

So are you saying that an inbound DID will match an extension before it matches a catch-all inbound route?

4

Yes.

You can probably override this behavior by modifying your creating another catchall route with a DID of

_XXX

I just tested and can confirm it will match before the ext-local context.

2 Likes
5

Interesting.

I only have a few extensions that match a DID without an inbound route, so it’s not a big deal to just add the routes, but I must admit I’m a little surprised it doesn’t put the catch-all ahead of local.

Thanks for the help.

6

The whole point of a catch-all is that it comes last.

7

No, I said you have another inbound route or your trunk context itself, is routing the call prior to getting to the any/any route.

Nothing routes by itself. You 100% created something to route your DID.

8

He probably has a context on his trunk matching the DID to extensions

9

is it possinle that the context for that trunk has been set to from-did-direct which does provide a one-to-one relatyionship between DID and endpoint ?

10

Time to look at the twisting and turning dialplan.

extensions.conf:

; from-pstn:
;
; Entry context for calls from the outside world to hit FreePBX
[from-pstn]
include => from-pstn-custom             ; this context include remains for legacy reasons, but should not be used.
include => ext-did
include => ext-did-post-custom
include => from-did-direct
include => ext-did-catchall             ; THIS MUST COME AFTER ext-did

catchall comes last, therefore anything before it will match first. Including [from-did-direct] which includes [ext-local]

[from-did-direct]
include => ext-findmefollow
include => ext-local

and in [ext-local] is where you will find your extension numbers.

Here’s the explanation in the comments of extensions.conf:

; forces ext-findmefollow to take precedence over ext-local. Also exposed to
; the public side to allow an extension number to be used as an external DID
; without requiring inbound routes to be created, common in many PRI installations
; where the last 4 digits are used as the extnension and DIDs are delivered in
; 4 digit formats.

@lgaetz suggestion, above, should help you avoid this!

11

is it possible that the context for that trunk has been set to from-did-direct which does provide a one-to-one relationship between DID and endpoint ?

12

It’s probably set to the default of [from-trunk], which includes [from-pstn] and then see above…

This is actually a really great feature (direct inbound routing to extension numbers) but poorly documented, I think.

13

I believe this is the correct answer.

I could swap the order so it matches the catch-all before ext-local, but it’s just easier for me to add the few DIDs and route them appropriately.

Thanks, everyone, for the help!

14

System with an inbound route for 6006, an extension 6006, an _XXXX route and as well as catchall route:

uc-33435257*CLI> dialplan show [email protected]
[ Included context 'ext-did-0002' created by 'pbx_config' ]
  '6006' =>         1. Set(__DIRECTION=INBOUND)                   [extensions_additional.conf:2099]
*snip*
  '_XXXX' =>        1. Set(__DIRECTION=INBOUND)                   [extensions_additional.conf:1916]
*snip*
[ Included context 'ext-local' created by 'pbx_config' ]
  '6006' =>         hint: PJSIP/6006&PJSIP/906006&Custom:DND6006,CustomPresence:6006 
*snip*
[ Included context 'ext-did-catchall' created by 'pbx_config' ]
  '_.' =>           1. Set(__FROM_DID=${EXTEN})                   [extensions_additional.conf:5003]
                    2. Noop(Received an unknown call with DID set to ${EXTEN})

Same as what Bill posted above, but you can see the from trunk context priorities are specific DID’s first, then then XXXX route, then ext-local extensions then the empty DID catchall.

15

You are really good at not listening.

No, you cannot just “swap the order” because that is not how anything works.

Try answer any one of our posts with some actual detail of how your trunk and inbound routes are setup.

16

Whoa! Slow your roll there, champ. No need to get all uppity.

Both Lorne and Bill provided information that pointed me in the right direction and I’ve marked the thread as solved. (You, on the other hand, have replied with snippy comments and a smarmy attitude.)

Be more like Lorne and Bill. Catch more flies with honey and all that.

:slightly_smiling_face:

17

Except you did not solve the problem. You worked around it.

18

Except you missed the point in his original post where some DID in the block are supposed to go to extensions.

He has something intentionally routing a match to an extension. But he refuses to actually tell us any of that detail.

19

This is incorrect. Nothing on my system is supposed to ring an extension directly. I’m not sure how you inferred this.

20

Then you have something completely misconfigued.