Is there a way to control outbound routes with Call Flow Toggle (or similar)? I see there is a field in the outbound route for a Time Group which is sort of the right concept except the validity of the route needs not to be dependent on the time of day but rather whether the manager has hit the magic button on his phone. Similar as well I suppose to a day/night mode for outgoing calls rather than incoming calls… but again not based on the time of day.
Essentially they want all calls to operate as normal through the existing outbound route… until the manager (under a specific set of circumstances) hits his preprogrammed “stop” button which would then switch to an outbound route containing no trunks such that it falls through to an announcement saying that all (external) calls are blocked. Its critical that this can be initiated by the push of a BLF button and that the status LED on the blf show the status of the feature (which is what drew me to the call flow module).
The first one would serve the extensions subject to the limit. It would route all outbound calls to a trunk that connects to the second PBX.
The second PBX would receive all calls on an inbound route that accepts all DIDs that goes to the call flow control. The manager’s extension would be on the second PBX. That system would be set-up to receive the inbound calls from the first PBX, route them through the Call-Flow-Control and then out to either the outbound trunk or Terminate Call:Play SIT Tone, depending upon the setting.
There may also be a way to do it with a single PBX that loops the calls from certain extensions back into the same system, but it might end up looping forever…
I thought a bit more and you can do it with a single PBX.
You may be able to set the outbound route to have no trunk as the destination (or a disabled trunk as the destination) and then have the Optional Destination on Congestion go to the Call Flow Control, which either delivers the call to a trunk or to a SIT Tone.
If that doesn’t work, you may be able to create an outbound route that prepends the dialed DID with something unique, i.e.
12125551212
gets prepended with
888111888
So that the outgoing number as modified will be:
88811188812125551212
That route sends calls to a trunk that loops right back into your machine. I.e., a custom trunk that goes to:
(where 192.168.1.50 is the IP address of your PBX)
You then create an inbound route that will accept all DIDs that match this format:
_8881118881XXXXXXXXXX
That route goes to a Call Flow Control controlled by the manager.
On the CFC: If allowed, it then goes to a trunk that modifies the dialed number by removing 888111888 at the beginning and then sending the call on to a service provider.
Come to think of it, the prepending may not be necessary…
I’ve thought about this a bit and I don’t believe there is a way you could do it without some level of custom dialplan. The disconnect with sending the call to an outbound route destination is that you ‘lose’ the number being dialed once it goes back into the standard call flow. This is because the number is retained within the ${EXTEN} and a result of the final destination, it gets vectored with a new Goto() call. One would have to examine the call to see if it’s maybe still retained in a channel variable somewhere such that you had the option of going to a CallFlow destination or something similar, and having that destination have the potential of going to some small custom context which gets it back into a normal outbound flow.
As mentioned, the TimeGroups don’t help because those specifically act based on time, they are not linked to an actual time condition which would otherwise let you use the TimeCondition’s feature codes to toggle it.
No matter how you cut it, I think you’re going to need some custom dialplan to address your desired outcome. You are welcome to submit a feature request for consideration into a future release to address something like this.
One thought, a little convoluted, with ‘minimal’ custom dialplan, could be as follows. You have the call go to a custom trunk. That custom trunk sends it back down the local channel into the ‘ext-did’ context with a unique prepend. Such as 999999${EXTEN} where ${EXTEN} is the number that was dialed. You create an inbound route for _999999XX. which catches those numbers dialed and send that to your call flow control. The destination route for that call flow control becomes a custom context you have to create. You can register that with the Destination Registry so you can configure it from the GUI as a destination. That destination would simply take the number out of ${FROM_DID} where it has been stored by the inbound route, strip off the 999999, do what ever else it needs to do so as to now send the call out a normal outbound route. You may have to get creative such as send the call to a specific route that is normally not made available to callers (using Extension Routing) or something similar. There are a lot of considerations in doing something like this including ‘ugly’ CDR’s and questions of what you’re expecting for CID’s on outbound calls, etc.
Of course if you’re going to go through all this, you can also just send it to a custom trunk that has slightly more sophisticated dialplan and does what you need. It can take advantage of an existing state of a Call Flow implementation but not bother with the complexity of going back into the ‘normal’ dialplan and just handling the routing directly from there.