I've been scratching my head at what might be the best approach to checking if the DID exists already in the from-outside / from-outside-redir context before proceeding with the outbound SIP route.
My (past, asterisk-centric) approach would be to use the include pattern:
For example:
[myInboundDID]
exten => 5141231234,1,Macro(myDidHandler,${EXTEN})
[myOutboundContext]
include => myInboundDID
exten => _NXXNXXXXXX,1,Macro(myDialMacro,${EXTEN})
However, as I snoop more through the macros and dialplans, I'm thinking that this may not necessarily be the best pattern, because the context "from-outside-redir" also contains some default extension behaviours which we don't necessarily want to taint the from-inbound context.
So that leaves me to the next idea; using the LOCAL channel driver, and performing a two-trunk dial, one being to LOCAL/${EXTEN}@from-outside to validate if it exists, before going to the secondary trunk, however, I've read in a previous post that this may not necessarily be the best pattern and its exploiting a flaw that's supposed to be patched in an upcoming release.
Which boils-down to me scratching my head; any insights?
Alright, you got me thinking,
Alright, you got me thinking, and discovered that function DIALPLAN_EXISTS to save the day.
With much luck, my target users dial 10 digits, and my DIDs are 10 digits, which makes everything simple. But you are right, number formatting, and at a larger scale, using E164 would be interesting. When DUNDI came-out many years ago, I played with the number discover concept and seemed that it was a great approach for number & route discovery in cluster scenarios, but I've never had to tackle a large-scale implementation.
Derived from the tl-dialout-1-trunk macro; my rather simplistic implementation:
; Figure-out if we are routing locally or externally
exten => s,1,GotoIf($["${MACRO_EXTEN}" = "s"]?dial)
exten => s,n,Set(__DIALED_NUMBER=${MACRO_EXTEN})
exten => s,n,GoSubIf($[${DIALPLAN_EXISTS(from-outside-redir,${MACRO_EXTEN},1)} = 1]?s-DID,1)
exten => s,n(dial),Macro(tl-dialout-base,${ARG1},${ARG2},${ARG3},${ARG4},${ARG5})
; The target digits were found in the DID table; lets just jump there
exten => s-DID,1,Goto(from-outside-redir,${MACRO_EXTEN},1)
Great product! I like how it's easily possible to add custom scripts and handlers, instead of being confined to specific call patterns.
Cheers
it seems DIALPLAN_EXISTS
it seems DIALPLAN_EXISTS didnt show up until sometime during the 1.6.x.x development branch.
one question, why send it to s-DID if you were just going to Goto from-outside-redir immediately anyway?
wouldnt it have been easier to
exten => s,n,GoSubIf($[${DIALPLAN_EXISTS(from-outside-redir,${MACRO_EXTEN},1)} = 1]?from-outside-redir,${MACRO_EXTEN},1)
will this function return 1 if a pattern like _514123123X was in that context?
Erik, This got me thinking
Erik,
This got me thinking about load distribution. Which macro should I edit to place my dundi lookup for extensions? I would like to experiment with running 2 thirdlane PBX's for load distribution.
Cheers
theres 2 problems with your code
1) local patterns and extensions are processed before included patterns so your code could not look like that.. it would have to instead look like
[myInboundDID]
exten => 5141231234,1,Macro(myDidHandler,${EXTEN})
[myOutboundPatterns]
exten => _NXXNXXXXXX,1,Macro(myDialMacro,${EXTEN})
[myOutboundContext]
include => myInboundDID
include => myOutboundPatterns
2) your code does not address pattern length problems, as of now you would only keep the call local if your tenant happened to dial 514-123-1234. Should he happened to dial 123-1234 because its a local call for him, or perhaps 1-514-123-1234 those calls would still leave the box. The only TN that is absolute is E.164 (+15141231234). Unless your inbound DID are already numbered this way, and you can convert your outbound patterns to this format before checking against your inbound context, its a less than perfect approach.