I have internal extensions 5000-5999. The DID I get from the Vega gateway (which gets it from teleco) is 3 digit. I map the DID to the internal extension using Inbound Routes, works great, nothing exiting.
I have an old Toshiba PBX that I was able to get to forward the 5XXX extensions to the PSTN (the Vega) and configured the Vega to send those 5XXX extensions from the Toshiba interface to the SIP interface.
Surprisingly, I tested it out before creating an inbound route for the 5XXX extension, and it rang the SIP phone…call worked fine. Is there some sort of fall through for inbound routes that I didn’t know about?
In researching how to show dial plans I ended up running ‘asterisk -r, dialplan show’ and saw a mention of ‘ext-did-catchall’…but I don’t want to get too deep in the woods. I guess I just expected a DID coming in on the trunk with no matching inbound route would end up in /dev/null chatting with Lenny or something.
So is this by design or did I misconfigure something in such a spectacular fashion that I inadvertently made it work? What’s the best way to take that DID/internal extension and route it to the actual extension?
Maybe some cr@ppy ascii art will help explain:
PSTN->812->Vega->812->[ IPPBX IR 812->5012]-> User/Device/Ext 5012 (works)
Toshiba PBX ->5012->Vega->5012->IPPBX->User/Device/Ext 5012 (somehow works)
Toshiba PBX ->5012->Vega->5012->[ IPPBX IR 5012->[Existing IR for DID 812->5012] ->5012]-> User/Device/Ext 5012 (What I thought I would have to do)
It’s a feature, though I don’t think it’s well known or well-documented (what follows is internal documentation from the extensions.conf file):
; from-did-direct:
;
; 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.
from-did-direct is included in the default trunk context.
Ah, that makes sense. I was under the misconception that if I didn’t define anything in an inbound route that nothing would get through. I guess as long as the defaults never change I’ll be good.
I use from-did-direct after parsing the inbound call with a custom destination because the system needed to match on the last 3 of the inbound DID, and I wanted to control where the fail to match returns to. Your scenario may be a bit simpler and you may be able to just use a custom destination.
[match-ext-to-did]
; This context is meant to be used by a Custom Destination that parses out a portion of the DID
; and attempting to match to an extension. If that match fails, this returns to the Custom Destination
exten => _.,1,NoOp(Entered [match-ext-to-did] with DID ending in ${EXTEN}, attempting to match an extension)
; Check for the passed extension to exist in the dialplan
exten => _.,n,GotoIF($[${DIALPLAN_EXISTS(from-did-direct,${EXTEN},1)}]?didmatched:didnotmatched)
; The extension was found in dialplan, send the call to it.
exten => _.,n(didmatched),GoTo(from-did-direct,${EXTEN},1)
; Since the extension was found, the call should never return here. In case it does, hangup the channel.
exten => _.,n,Hangup()
; The extension was not found in dialplan, return to the pocess that call this context.
exten => _.,n(didnotmatched),NoOp(Did not find a match with [match-ext-to-did] for DID ending in ${EXTEN}, returning)
exten => _.,n,Return()
