In a multiple inbound routes environment, I need all DIDs to be routed to a unique destination from time X to time Y
It sounds crazy to create hundred time conditions (the same one) as target of hundreds inbound routes just to keep the non-matching destination to proper extension…
Is there a way to analyze time group prior to route DID to its destination ?
So what you are saying is that you have 100 DIDs and they all have 100 different destinations during “work hours” but “after hours” they all go to the same destination like a voicemail?
Exactly !
So… any smarter solution than 100 TC ?
Custom dialplan to create a new incoming context to point the trunk to. In that incoming context, you do you time checks and then if match, send to the inbound route and if not match go to general voicemail.
Just remember, you would need to mimic what an inbound route does before it actually routes the call (CallerID, blocklist, pattern matching, setting variables, etc) before sending it to voicemail. Missing settings/variables could cause unwanted behaviour.
So a pre-processing of the incoming call like this ?
Yes and no, it sends the call to the inbound routes after the processing. In your case you only want to do that when the time condition matches that way your 100 inbound routes go to the 100 destinations. When it doesn’t match you want to send it to voicemail. It is when you send it to voicemail you need to do certain things that happen in inbound routes to make sure the system handles the call right.
Clearly I haven’t understood well how it works…
I created a custom context [from-pstn-timecheck] that trunks points to:
[from-pstn-timecheck]
exten => _X.,1,Goto(timeconditions,10,1)
On this time condition , the non-match goes to voicemail , the match goes to ???
How can at that point pass the call to check DIDs and route call to rigth extension like originally , trunk points to [from-pstn] ??
To complete the preprocess time condition, you need a destination that you can select in the GUI that will send the call back to the inbound routes. There would be a number of steps.
Modify your preprocess context
[from-pstn-timecheck]
exten => _X.,1,Set(FROM_DID=${EXTEN})
exten => _X.,n,Goto(timeconditions,10,1)
Create a Custom Destination with an arbitrary name and a goto string of
from-trunk,${FROM_DID},1
In the preprocess TC, set one of your conditions to this new Custom destination
Having written all that out, I now realize you may run afoul of 911 regs that require a 911 callback to be routed somewhere useful. With this in place it would also be impossible for anyone working after hours to receive an inbound call.
Possibly a better solution would be to forget the pre-process custom dialplan and instead create a TC for after hours that directs to the alternate destination on match and otherwise does a terminate call - hangup. Then create a dialable feature code with a Misc Application for this time condition. Individual users on the system can enable FMFM and add the feature code in the list of dialed numbers (perhaps after ringing the primary extension for a few seconds first), so that when the TC matches it will intercept the call and direct it away form the user’s vmbox. You can’t send a caller directly to this time condition, as you run the risk of hanging up on a caller, but you can safely add the Misc App feature code to a list of numbers.
The main drawback to this is that users may enable/disable (perhaps accidentally) FMFM and mess up the call flow, but has the advantage of a pure GUI solution, which is easier to debug if anything goes wrong.
I never said you could use the existing time condition. You want a global time condition and when it matches the time condition you want to send it to the inbound route for the DID in question. When it doesn’t match, general voicemail box.
If this is Time Condition 1, it would be like this. You would have to declare ARG1 with the need variable normally passed. Note the two lines I put ** around
[from-pstn-timecheck]
exten => _1NXXXNXXX,1,Set(ARG1=)
exten => _1NXXXNXXX,N,Set(DB(TC/1/INUSESTATE)=INUSE)
exten => _1NXXXNXXX,n,Set(DB(TC/1/NOT_INUSESTATE)=NOT_INUSE)
exten => _1NXXXNXXX,n,Noop(TIMENOW: ${STRFTIME(${EPOCH},,%H:%M,%a,%e,%b)})
exten => _1NXXXNXXX,n,Noop(TIMEMATCHED: ${IFTIME(08:00-18:00,*,*,*?TRUE:FALSE)})
exten => _1NXXXNXXX,n,GotoIfTime(08:00-18:00,*,*,*?truestate)
exten => _1NXXXNXXX,n(falsestate),GotoIf($["${DB(TC/1):0:4}" = "true"]?truegoto)
exten => _1NXXXNXXX,n,ExecIf($["${DB(TC/1)}" = "false"]?Set(DB(TC/1)=))
exten => _1NXXXNXXX,n(falsegoto),Set(DEVICE_STATE(Custom:TC1)=INUSE)
exten => _1NXXXNXXX,n,ExecIf($["${DB(TC/1)}" = "false_sticky"]?Set(DEVICE_STATE(Custom:TCSTICKY${ARG1})=INUSE))
**exten => _1NXXXNXXX,n,GotoIf($["${TCRETURN}"!="RETURN"]?ext-local,vmu100,1)**
exten => _1NXXXNXXX,n,Set(TCSTATE=false)
exten => _1NXXXNXXX,n,Set(TCOVERRIDE=${IF($["${DB(TC/1):0:5}" = "false"]?true:false)})
exten => _1NXXXNXXX,n,Return()
exten => _1NXXXNXXX,n(truestate),GotoIf($["${DB(TC/1):0:5}" = "false"]?falsegoto)
exten => _1NXXXNXXX,n,ExecIf($["${DB(TC/1)}" = "true"]?Set(DB(TC/1)=))
exten => _1NXXXNXXX,n(truegoto),Set(DEVICE_STATE(Custom:TC1)=NOT_INUSE)
exten => _1NXXXNXXX,n,ExecIf($["${DB(TC/1)}" = "true_sticky"]?Set(DEVICE_STATE(Custom:TCSTICKY${ARG1})=INUSE))
**exten => _1NXXXNXXX,n,GotoIf($["${TCRETURN}"!="RETURN"]?from-trunk,${EXTEN},1)**
exten => _1NXXXNXXX,n,Set(TCSTATE=true)
exten => _1NXXXNXXX,n,Set(TCOVERRIDE=${IF($["${DB(TC/1):0:4}" = "true"]?true:false)})
exten => _1NXXXNXXX,n,Return()
Now keep in mind that when it routes to the voicemail, there’s no indicator this was an inbound call from the PSTN and it ignores any contact details that might be set. Will probably give proper callerid but you would have to test it.
Thank you for suggestions.
Tom , lot of work , i’ll give it a try.
But… once incoming flow is routed into a new arbitrary context that points to a time condition , is there (simply) a way to re-route, upon a time condition match (or non-match), to initial [from-pstn] context where DID analysis take place against all available inbound routes ?
Tom, what’s wrong in using an existing TC made for just that purpose ?
Just tried kingarthur first approach , it seems to work,
A question: why custom destination “goto” from-trunk rather than original from-pstn context ?
Tom chosen from-trunk also in
exten => _1NXXXNXXX,n,GotoIf($["${TCRETURN}"!="RETURN"]?from-trunk,${EXTEN},1)
Overall speaking, what are real limitations or problems in preprocessing incoming calls via time condition ?
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.