${EXTEN} Variable behavior for Custom destinations

I’d like to set up a custom destination as an target for a chain of 4 time conditions. This is necessary as we want 4 different announcements for different holidays. But that would also mean that I have to built up this chain for aprox. 60 Extensions > 240 entries. That is very unflexible, so I’m trying to make a custom destination which works as a wildcard for all Extensions.

As a target, I’ve set “from-did-direct,${EXTEN:9},1”

This works and I can see in the protocol that the firs 9 digits are removed and the pure Extension number is left. Linking this directly with the inbound route works great.

But here comes the problem: When I use this target with the time conditions I does not work.

I’ve set up a test condition which points to the custom destination for the true case and to the extension directly for the false case.
The extensions_additional.conf shows in the timecode context:

true case
exten => 257,n,GotoIf($["${TCRETURN}"!=“RETURN”]?from-did-direct,${EXTEN:9},1)
false case
exten => 257,n,GotoIf($["${TCRETURN}"!=“RETURN”]?from-did-direct,215,1)

It looks as it would work but it doesn’t. In the true case the ID of the timecondition is dialed. As an extension with the number 257 really exists, the call ends up there. So I think the EXTEN variable changes or is not available when entering the timecondition function. Does anybody know more this variable behavior or how I can get out the dialed number there. I really can’t find similar cases… Thank you.


Function CALLERID(dnid) may have the dialed number you want.

${EXTEN} is a hidden function, not a variable. It always contains what matched the pattern after the => on the same line. You would have to save its value when it was correct.

1 Like

YES! This works. Thank you…!

Thank you! The FROM_DID works as well.

1 Like

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