I am looking for a solution to a problem which many of our customers face, but has been more problematic for one customer than others.
The customer is not staffed 24/7 and provides live coverage by cell phone approximately 12 hours per day, using different people on different days of the week. They need to be able to, by dialing an externally accessible phone number, change the ring-to destination for all calls on the system. This could either be the call forwarding destination of an extension, the single member of a ring group, or something similar. This would be identical to the way most telcos implement Remote Call Forwarding, where a dial in number is provided, the phone number is entered, followed by a password, then the destination.
Here is what we have tried to work around this:
Elaborate set of time groups and time conditions. These work well, until the schedule changes, at which point our support techs need to manually reorder the time conditions and their destinations. This requires that a support ticket be opened and the customer is not in control, which is especially problematic for last minute changes. The customer is not advanced enough to make these modifications on their own.
Inbound route points to a virtual extension. Virtual Extension has a login to UCP, which their users use to change Endpoint Settings - Forward All to the number where they want calls to ring at the moment. This is the solution that we use for the majority of our clients who have a similar situation, but this client does not grasp the web interface and has had instances where they make an error.
Modify queue to permit call forwarding to outside number and have the user pick up a handset which is a queue member, dial the feature code for call forwarding and the forward-to number. This fails the requirement because the customer is sometimes away from the office when the destination needs to be changed.
Has anyone faced a similar issue? If so, do you have any suggestions?
I’m up for rewriting the dial plan manually if that’s the only option, but I prefer to keep systems as mainstream as possible.
Set up a number for them to use for this specific task (or perhaps an IVR destination?)
Set up a custom context
Ask for their PIN.
They enter the pin.
It asks for the extension they want to forward.
They enter it.
It asks for the new destination (press ‘0’ to clear maybe?).
They enter the new destination.
It sets the AstDB CF variable for that extension to whatever they entered.
It says thank you.
I did something like this for a client a couple of years ago using an external script that watched for the MAC addresses of their cell phones. When the phone was out-of-office, the system would recognize it and forward all of their calls to their cell phone.
This way, it works a little like an “Uber”. The technician dials into the system and sets the office extension to CF remotely. It’s a little surgical, but it would play reasonably well with the rest of the system. Also, if someone decides to cover two shifts, they could dial into both numbers and forward both to their phone.
Once that infrastructure is in place, you could extend it to do forward just about anything. By adding “virtual” extensions (for purposes of the script/context), you could code up all kinds of strange and wonderful things.
Sorry for the significantly delayed reply. I think something like this would work.
Do you have an example of something you’ve done which is similar? I’m not opposed to experimenting with the dial plan, but would prefer to see an idea of something that may have worked in the past.
I don’t have one that would do specifically this, since I don’t have a need for it.
The FreePBX guys could code it up for you if you lack the skills. If you don’t, I suggest starting with the existing dial plan to look for examples. I could too, but I’m way behind with other commercial projects, not to mention the cool stuff I want to do.
The VoiceMail context does PIN processing, you can grab a lot of the code from there.
Anyplace that monkeys with the CF database code would be a good place to look at how call forwarding is handled, especially in regard to the setting and unsetting of the extension in Asterisk.
Actually, that’s about it. If you plan it right, the extension would be virtual, in that it doesn’t actually have to back to a real phone. You can set that up in the GUI. The custom context would probably go in extensions-custom.conf. I don’t see that it would need to be more than about 20 lines of custom context code.
Now, one place that you might run into a jam is with one-way audio through the server. There are lots of places that this can be an issue, but it wouldn’t have anything to do with this script.
