Inbound routing with from-did-direct custom context does not return

Had a need to route a lot of DID and did not ant to make routes. Fine, that is what [from-did-direct] can be used for, along with a custom destination.

Problem. You cannot return from the custom destination if the DID does not match. Granted not every one would care to do this. But some do. In this case they want to play an announcement and then dump the call to the non-DID call flow.

If you simply make a Custom Destination as noted in the linked post, the call is rejected, even if you have the Custom destination set to return to some other location. The [from-did-direct] context rejects it some place in there if there is no match. I did not bother to try and find where.

This forced me to create my own contexts to get around this.

[match-ext-to-did]
include => from-did-direct
include => match-ext-to-did-failed
exten => _.,1,NoOp(Entered [match-ext-to-did] with DID ending in ${EXTEN}, attempting to match)

[match-ext-to-did-failed]
exten => _.,1,NoOp()
exten => _.,n,NoOp(Entered [match-ext-to-did-failed] with DID ending in ${EXTEN}, returning to custom destination)
exten => _.,n,Return()

Then the custom destination is built as linked above. Failing to my extension for faster testing.

This is what a failed match looks like in the log.

[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx.c: Executing [NPANXX3997@from-pstn:20] Goto("PJSIP/Spectrum-00004967", "customdests,dest-1,1") in new stack
[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx_builtins.c: Goto (customdests,dest-1,1)
[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx.c: Executing [dest-1@customdests:1] NoOp("PJSIP/Spectrum-00004967", "Entering Custom Destination Try to match DID to Extenstion") in new stack
[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx.c: Executing [dest-1@customdests:2] Gosub("PJSIP/Spectrum-00004967", "match-ext-to-did,997,1()") in new stack
[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx.c: Executing [997@match-ext-to-did:1] NoOp("PJSIP/Spectrum-00004967", "Entered [match-ext-to-did] with DID ending in 997, attempting to match") in new stack
[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx.c: Executing [997@match-ext-to-did:2] NoOp("PJSIP/Spectrum-00004967", "Entered [match-ext-to-did-failed] with DID ending in 997, returning to custom destination") in new stack
[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx.c: Executing [997@match-ext-to-did:3] Return("PJSIP/Spectrum-00004967", "") in new stack
[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx.c: Executing [dest-1@customdests:3] NoOp("PJSIP/Spectrum-00004967", "Returned from Custom Destination Try to match DID to Extenstion") in new stack
[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx.c: Executing [dest-1@customdests:4] Goto("PJSIP/Spectrum-00004967", "from-did-direct,219,1") in new stack
[2020-04-21 23:58:58] VERBOSE[158207][C-00002e41] pbx_builtins.c: Goto (from-did-direct,219,1)

This is works just fine, but I would really prefer to not need to create custom contexts just to return like this. Every bit of custom dial plan is another break point.

So is there anything that would do this already that I am missing?

Hi Jared:

I think I understand the goal here, you are making this harder than it needs to be. If you want to have all inbound calls go to from-did-direct in cases where there is a matching extension number, and go to inbound routes in cases of no match, you donā€™t need a Custom Destination in the GUI, just a block of dialplan for your trunk:

[from-did-direct-sorvani]
exten => _.,1,NoOp(Entering user defined context from-did-direct-sorvani)
exten => _.,n,GotoIF($[${DIALPLAN_EXISTS(from-did-direct,${EXTEN},1)}]?from-did-direct,${EXTEN},1:from-trunk,${EXTEN},1)
exten => _.n,hangup()
3 Likes
  1. How is this going to matching the last three of the DID to the Extension? That was the point of the custom destination.
  2. I want to not have to add a custom context in the first place. That is why I liked the custom destination method. But since a call does not return from thereā€¦

I have almost no FreePBX out there without some kind of custom context added, but I always try and find a way around that first. To stay within the GUI as much as possible.

How about this for the Cust Dest:

[match-ext-to-did]
exten => _.,1,NoOp(Entering user defined context match-ext-to-did)
exten => _.,n,GotoIF($[${DIALPLAN_EXISTS(from-did-direct,${EXTEN},1)}]?from-did-direct,${EXTEN},1)
exten => _.n,Return()
1 Like

Making use of DIALPLAN_EXISTS will at least let it only be a single context.

The Custom Destination is hard coded to use GOSUB not GOSUBIF. In order to do what you want, the IF part of the logic needs to be your own context. I donā€™t see a way around that.

1 Like

Commented final version unless you see a problem with it.

[match-ext-to-did]
; This context is meant to be used by a Custom Destination that parses out a portion of the DID
; and exting 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()
1 Like

@sorvani

Looks like I was wrong (not for the first time), you can do this entirely within a Custom Dest without touching a custom.conf file:

${IF($[${DIALPLAN_EXISTS(from-did-direct,${FROM_DID:-3},1)}]?from-did-direct,${FROM_DID:-3},1:from-internal,219,1)}

Return is unused. You hard code the failover destination, shown here as from-internal,219,1 but obviously you can use whatever you want. Easily the most complex GoTo Iā€™ve ever seen.

1 Like

Because of that, I think I will stay with the custom context because it is readable with the comments to help.

Iā€™ve never understood why there is not some built in logic for this already. Historically, there are so many people with DID blocks. I mean I tell people they donā€™t need DID for everything and just use an IVR to let people dial extensions, but so many people cling to their DID.

1 Like

Features start with a feature request. In my 5 years of doing this full time, Iā€™ve not been asked for this feature nor can I recall anyone in the forum asking prior to today. The few who need this must be doing it with their own context. Also as telephony slowly moves away from PRI, there are fewer systems where the provider DID matches up nicely with extension numbers.

Sorry, but I disagree completely.

  1. It is unsafe to use an IVR while driving.
  2. On most caller systems, one canā€™t program a Contact that will reliably operate the IVR.
  3. On nearly all caller systems, Redial or calling from History do not work properly.
  4. The callerā€™s system will always show the call as ā€˜answeredā€™, even if it was not.
  5. The caller may pay for unanswered calls, or pay for time while the callee is being rung.
  6. If the extension range conflicts with other IVR options, it introduced needless delays and often confusion. For example, caller presses 1 for sales, system waits because there are extensions 1xx. Caller hears only silence for a couple of seconds, so presses 1 again. System responds ā€œThat was not a valid entry.ā€ Caller hangs up and goes to competitor.
  7. If an extension has its own external number, outbound calls can display it and the callerā€™s name to the callee.

In the US, some decent providers offer DIDs for $0.08/mo. or less. In large quantity, a nickel or less. There is no reason that any extension that is directly reachable shouldnā€™t have its own number.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.