Skip to main content

Visual Dialplan for GUI

Posted by matthewmalk248 on Fri, 02/17/2017

Would anyone else be interested in having the ability to design dialplan using visual aids, where inbound routes , time conditions, and hunt lists, would all be programmable via a graphical based interface? Giving the end users an easier way to make changes to their systems call routing?

Submitted by thirdlane on Wed, 03/01/2017 Permalink

I remember seeing something where Asterisk commands were practically mapped one-to-one to visual elements, which IMHO is not very helpful, but done right visual dialplan could probably be useful. It is always nice to see a full picture and may be even simulate flow.

Which ones did you try and did not like?

Submitted by netriplex on Fri, 02/09/2018 Permalink

Still none.

Must prefer custom call destinations for better fine grained control of call flow like numerous other solutions have.

Submitted by thirdlane on Wed, 02/21/2018 Permalink

The lack of interest to Visual Dialplan option really puzzles me. I understand that an experienced administrator does not need a visual dialplan, except perhaps as a view of what's already configured. I also understand that this forum is not frequented by the end users or office administrators :).

That said, I am surprised that practically nobody (of our service provider customers) wants to have a tool that may let their customers manage themselves. Do you think this is 1) not realistic (as in - customers will call you anyway after they do something wrong or get stuck), 2) will drive your fees down faster than costs as it will look like "self service", or you think that 3) most of your customers won't use it anyway?

Submitted by mattdarnell on Thu, 02/22/2018 Permalink

I am assuming you mean something like the picture I attached.

In my experience customers very rarely change their IVR once it is programmed. Set it & forget it. If it took one person 2 days to code it would be a nice selling feature but it would take longer to train the user on how to use it than to do it ourselves. If you move forward please budget to have professional documentation produced we can give to the end user.

I would rather see every penny spent toward:
1. Fixing bugs
2. Fixing bugs
3. Improving mobile applications - it is rapidly going to a mobile first world
4. Current documentation for administrators/resellers
5. Yealink phone apps (I could see paying per seat for this)
6. Enhanced routing options
a. Choose things like 1st & 3rd Saturday
b. Route on Labor day, Thanksgiving & day after, etc instead of having to update every year -
c. Combine/link operator and time based routes - now we have to loop calls
7. Create global phone templates (If you can today let please let me know)

Submitted by netriplex on Thu, 02/22/2018 Permalink

Couldn't agree with Matt more. Discussed this numerous times with you historically and even provided a very detailed writeup on call flow either on the forums or in an email to you on the need for improved call flow (Matt's "6c") with custom flow destinations and variables. We too have to loop calls in all kinds of hackish ways to meet our customer's needs with the existing very basic routing options.

I would say the order is fix bugs, fix bugs, improve call routing, enhance mobile applications.

I do not really agree with Matt on the need for a dedicated holiday schedule because that just opens up a new can of worms because I am sure every company operates with a different holiday schedule. Some companies are open "black Friday", others close. Some may work Christmas Eve/New Years Eve, others close and consider those days holidays. As such, I do not think you can ever eliminate the manually oversight for call routing on holidays, but it can be made easier with more advanced call routing options (custom call destinations/variables).

Submitted by eeman on Fri, 03/02/2018 Permalink

Matt youre going to love me with regards to this...

"b. Route on Labor day, Thanksgiving & day after, etc instead of having to update every year -"

from voip-info on the command GoToIfTime:

If the comment about holidays is true, then here's a list suitable in the United States:

Independence Day: *,*,4,jul
Christmas: *,*,25,dec
NewYear: *,*,1,jan
MartinLutherKing: *,mon,15-21,jan
Valentines: *,*,14,feb
StPatDay *,*,17,mar
Halloween *,*,31,oct
Thanksgiving *,thu,22-28,nov
MemorialDay *,mon,25-31,may
LaborDay *,mon,1-7,sep
Pres/WashBday *,mon,15-21,feb
MothersDay *,sun,8-14,may
FathersDay *,sun,15-21,jun

the only day you cannot code is Easter, because there is no set rules, its based on Paschal moons

So for thanksgiving, its always a thursday and always falls on a 22nd - 28th, Labor Day is always the first monday in september, so dates 1-7, as long as its a monday, will solve your variable day holidays.

Submitted by on Wed, 03/03/2021 Permalink

Possibly the lack on any response to a visual dialplan editor was due to the fact that there was already a visual dialplan editor out there -- Apstel Visual Dialplan. Yes I can go into a conf file and edit it but I found the learning curve for Visual Dialplan was very short and made my work (responsible for 5 Asterisk installs) very easy. However, Apstel sold off the rights to an unnamed party and stopped making any updates to it. When I updated 3 of my installs to the latest Asterisk Version, the link to Visual Dialplan broke. I'm very interested in a replacement solution. I've even gone as far as writing an app myself (25% completed).