Understanding the Fusion dial plan manager for time conditions

[ConFusious]

I am new to Fusion PBX and the freeswitch it is based on. I have worked with Asterisk based applications such as FreePBX and some plain Asterisk. I have made and modified Asterisk dial plan and made xml files for provisioning Polycom and Yealink phones. I really am not familiar with The regex expressions needed to create Freeswitch dial plan. I can see the reason for Freeswitch doing it that way and I am making an attempt to learn it. I appreciate that Fusion has tried to take the exasperation of learning the xml programing with the fill in the blank approach for developing dial plan much like FreePBX does with Asterisk dial plan. I have made many complex time conditions in FreePBX but the logic in Fusion except for the most basic and simple ones has eluded me. I have searched for the answers to my questions on this forum and other sites. There isn't much out there and some of the ones that seem like they would answer my questions have trojans according to Maleware Bytes. Here is what I can't figure out and don't see any explanation for:

I have included an example Time Condition dial plan that I am playing with. First question is what does the Break option do and how does the menu choices under that heading affect it? Second question is what does Inline mean? Third question is What is the effect of the group and order entries? I have tried to figure out these things by trial and error but they don't behave as my logic would allow so I know I am missing some important concepts. The company I work for is moving all our cloud based clients on to the Fusion Platform and some of them have complex time conditions and I can't make it happen in Fusion. Hence my username. Thank you for any answers provided.

 

[Adrian Fretwell]

Off the top of my head (I'm sure there are better explanations), and in no particular order:
1. The order entries are simply that, just the order in which the statements get assembled into an XML file.

2. The group allows sets of conditions to be grouped together, so you can form several sets of conditions under the one extension, 700 in your case.

3. The break option instructs FreeSWITCH not to stop processing the next condition if this one evaluates to false. The reason for having this is that if break is not specified then there is a default break on false that prevails for the condition. In other words, without the break never option, if one condition inside an extension evaluates to false then all processing for that extension stops. This facility allows you to effectively create a logical AND by staking up conditions.

4. The inline option instructs FreeSWITCH to immediately implement the instruction, in this case, set a variable. This ensures the variable is actually set as expected, if it needs to be evaluated or used later within the same extension.

I hope that helps a little, I'm sure better explanations are available!

 

[ad5ou]

Adrian beat me to the longer answer.

For some not so light reading: https://freeswitch.org/confluence/display/FREESWITCH/XML+Dialplan

 

[ConFusious]

Thank you gentlemen for replying to my question. it seems like every time I try to play with Time conditions, I am suddenly inundated with perplexing problems in other PBXs we manage or pressing projects. I didn't even get to look at Adrian's response until the end of last week. I tried to play with the settings but immediately got pulled away on another assignment. However I did find some time but it was entirely unfruitful. What I want to accomplish is create Time conditions where our client can have hours set to separate IVRs Monday through Thursday from 8am to 12 noon (morning), 12 noon until 1pm (lunch), and 1pm until 4pm (afternoon.) Then on Friday do the same thing only the afternoon is 1pm to 2pm. The IVRs for morning and afternoon can be the same. In other words they want a lunch hour broken out. Can easily do this in Freepbx. It seems to me that I should be able to nest everything Monday through Thursday into one time condition and Friday into a second. I can easily create a time condition with morning hours and an alternate destination linking to another time condition having the lunch hours, but when I try to link a third time condition with the afternoon hours it always goes to the alternate destination in the third time condition. The odd thing is if I set the alternate destination in each of the three time conditions to a recording and not a transfer to another time condition all three time conditions stop working individually when dialed with their unique extension number and I have to delete them and start over. I didn't save any screen shots of what I did so I will have to go back and recreate it and do the screen shots for another post. I attempted to read the Confluence article several time but got bogged down with the details. This would be helpful if I was to attempt to write dial plan from scratch but I couldn't find anything that helped me with fusion. One of the things I picked up on there was the idea that Freeswitch looks at all the conditions first before preforming any actions but this didn't seem to be the case for me. I' sure it was because I am doing everything wrong.

 

[ad5ou]

Here is an example from a client of mine. They are open Monday, Tuesday, Thursday, Friday, and Saturday. They close for lunch one hour each day and some days they are open later than others.
You may notice the "after lunch" time frame for Monday and Tuesday isn't defined until "order 545" (the last time group) This is because the person who built the time condition forgot to build it at first. The entry being out of order works fine. It just makes it slightly harder to understand. The entries could be condensed a little more, but as built makes it slightly easier to follow the logic.

In this time condition, the call will default to the "Main Night" destination. If a call happens during any of the defined day/times then it will follow the destination in the matching day/time group

 

[ConFusious]

ad5ou Thank you for providing the example. That is how I thought it was supposed to work. I created a single Time Condition and copied yours in every detail except for the transfer destinations which are unique to your system. Anyway on Thursday when I finally was able to finish it, I tested before 8 pm and it went to the alternate destination instead of the transfer destination I set for that time period. Today, Friday, I tried it during morning hours and that worked. Then I just tried it at the lunch hour and it worked. See what happens after that.

 

[ConFusious]

I just tried the Friday after lunch time and it did not go to the correct destination but to the alternate destination.

 

[ConFusious]

Ok It wasn't exactly like yours. I had different afternoon destinations than the morning destinations where yours are the same. Once I changed that to be the same it worked. I don't understand the difference that should make or why it wouldn't preform the afternoon destination. Maybe someone reading this post can clue me in on that?

 

[ad5ou]

I'm not sure where your issues are without seeing exactly what is programmed. Another thing to consider is the server time and time zone needs to be correct and it is usually a good idea to flush the cache after dial plan changes. Status>sip status> Flush cache

 

[wa4zlw]

Hi folks...happy holidays...I created some time conditions for the holidays and it didn't seem to work. In my case, I used the full inbound DID as the extension. Normally it goes right to a call center. In this case during the date/times we've specific for xmas and new years, we want to route the call to a different call count. It always went to the normal queue. There are inbound routes for these tollfree numbers pointing to the normal queue. Am I supposed to remove the inbound routes when using time conditions? Thanks leon

 

[wa4zlw]

OOOPS I think I found it. In the inbound route I need to send the destination to the time condition :-(

 

[wa4zlw]

UPDATE: I tried that but when a call came in it seemed to go into a loop adding more bridges so I removed it and moved the inbound routes manually. I'll have to test this when we have a little downtime.