Need dial plan to send authenticated external call to Dictate

I need to have users calling in authenticate and once authenticated, start dictating. This is really not configurable through the UI AFAIK. Am I wrong? If not, what would be the dial plan?

It seems best to have one extension configured to use the Dictate app, then use the UI to send callers to that extension when the extension they called originally, is unreachable. Otherwise, I would have to configure the Dictate app for every extension.

Set up a DISA and in that disa make the caller id that of a user with dictation privileges. You are good to go. If you need more than one, make more DISA’s.

In FreePBX 2.9 and above you can choose that DISA destination for no answer or busy on each extension from the GUI. Prior to that you need to setup forwarding to other than voicemail by more physical methods.

Further, the user can set up DND from https://box/recordings to arbitrarily send the caller to the busy extension (DISA in this case) if she so wishes, even if she is not there and not in fact busy at all.

But also yes, *35 to email will need an entry somewhere for the email for that dictation to be sent for, but *34 needs that you go to each extension to enable it anyway.

Is the only security concern with DISA the issue of someone possibly making expensive outbound calls. If so, I have deleted the outbound route (there will be no outbound calls from this system) - is there any other security issue I need to address with having a DISA configured? - T.I.A. !!

The security concern with asterisk is basically that it is running, the Security concern with FreePBX is that it runs under Apache/httpd , There are many ways to secure your system, this is not the place to discuss though. DISA is protected with a password BUT there are a huge number of “exploits” out there that you will encounter WAY before having to worry about that one.

It is generally believed that if a clever guy had the IP of your average FreePBX/Asterisk deployment and a reason to choose you over his other drive-by victims, then you would likely be cracked within minutes. You need to not be average.

So in no particular order of importance, an effective set of firewall rules, an effective suite of IDS programs, an audit of each and every TCP/UDP port you have open on your machine. Encryption of all tftp files, all http sites should have effective .htaccess files and be redirected to https, you will need a trusted certificate or risk pissing off all your users. Use keys for ssh, don’t allow passwords, and change the default port of anything you have running, be that http, https, webmin, vnc or wordpress, whatever, Avoid voip registrations on udp/5060 (or TCP/5060 like the plague,if you got that far yet These will be a good start.

Probably the biggest advice I have is don’t get complacent and think your system is secure, Most experts will disagree with you. and those experts all seem to live in Palestine or China :wink:

You also could simply create and IVR with an entry to go to each dictation account.

You could choose a 3/4 digit code for each dictation account.

The issue is that AFAIK the Dictate feature is only available if the system seems you as internal. All the dictation clients call inbound and therefore do not have access to the *34 feature. I have found that setting up a DISA for the inbound callers does give them a dial-tone where they can dial *34 to get to the dictation feature.

I would prefer to use the IVR to get them straight into the dictation feature after authenticating but I just dont see any intuitive way to get that done in the GUI.

The preferred workflow would be:
START:
User calls in over the trunk, chooses they extension at the IVR - then gets routed to the extension (easy so far - this I can setup no sweat. The next part is the tricky part).

After getting routed to the extension, they’re authenticated, then the Dictate app should kick in.
:END

I would prefer not to have edit any config files or get DISA involved for this solution. It’s a real shame that the GUI does not let you set the *34 Feature Code as a destination in a Not Reachable scenario, as that would ultimately be the solution.

You need to look at the misc. destination module.

I did, however the issue with that becomes that the default {$AMPUSER} variables becomes useless in the Dictate command* and replacing it with ${EXTEN} results in “*34” instead of the actual extension the user selected in the IVR - hence since I we can no longer get the dictations to drop into specific folders matching the user, we have another issue to overcome.

  • exten => *34,n(dictok),Dictate(/var/lib/asterisk/sounds/dictate/${AMPUSER})

You know if you want to purchase a couple hours of support I am sure we can whip out some custom dialplan to do exactly what you want.

If interested click on the support tab and just ask for Scott in the ticket. The guys will assign it to me.

I’m reluctant to pay for support because:

  1. I am cheap + poor.
  2. I hate having things done for me.
  3. I aim to prove that you dont need to pay for support to get things going.

Once I start getting revenue though, I will pay for support, just to have someone double check my work. After all you guys really do deserve it. In the meantime, my solution is posted here: http://sylnsr.blogspot.com/2012/08/setting-up-dial-plan-for-dictations-in.html

  1. I am cheap + poor - We gotta pay the developers !!

Anyway thanks for the great write up. Dictation is not one of the most popular features, frankly it is not very feature rich.

Not sure what your biz model is but good luck with it.

I would rather pay you guys to add certain feature than pay for support.

I don’t understand?