Then need something at start of dial plan to check value, etc. Also need to check the registered account linked to the rule. So VSP index would link to something, somewhere. Or, hard-code the integers to specific VSP_X. Database to hold values - i.e. account (1 or all), state (on/off), destination (xxxx), etc.

Really keen to know your thoughts and whether there is anything already built to handle this, without having to use a massive dial plan!

I've seen a lot of criticism of the DB functions, saying that the server is often rebooted or the services flushed.
Is there a more reliable method? I think it was in the topic re: seeing active stats, but when checking active stats on inbound call, rules were not applied due to reboot, or flush, etc.

Maybe this is mission impossible... I just would have thought something would be available or 75% given it is such a basic and core feaure.
Cheers Aaron,

Flip wrote:I've seen a lot of criticism of the DB functions, saying that the server is often rebooted or the services flushed.
Is there a more reliable method? I think it was in the topic re: seeing active stats, but when checking active stats on inbound call, rules were not applied due to reboot, or flush, etc.

Maybe this is mission impossible... I just would have thought something would be available or 75% given it is such a basic and core feaure.
Cheers Aaron,

That's news to me. Whereabouts did you see that criticism?

I can't even recall the last time the sipsorcery database function was rebooted and it's irrelevant any way since if it was down then none of the sipsorcery services would work any way so there would be no dialplans running.

Perhaps if the use case for the DB functions was multiple simultaneous dialplans with a large number of reads and writes in each dialplan there could be a problem with data integrity but that's a general problem with data access rather than a reliability issue.

If you need to did happen to need to use a database transaction (which would only be the case for a pretty complicated scenario) there are the extra dialplan functions available: sys.StartTransaction(), sys.COmmitTransaction() and sys.RollbackTransaction().

Aaron wrote:Perhaps if the use case for the DB functions was multiple simultaneous dialplans with a large number of reads and writes in each dialplan there could be a problem with data integrity but that's a general problem with data access rather than a reliability issue.

If you need to did happen to need to use a database transaction (which would only be the case for a pretty complicated scenario) there are the extra dialplan functions available: sys.StartTransaction(), sys.COmmitTransaction() and sys.RollbackTransaction().

Thanks Aaron,
I cannot find where you posted your example code snippet for the time of day, etc. I guess it doesn't matter, I've included my code snippet below.

I am having difficulty with the logic/syntax of checking both CID and time. e.g. x, y, z || 1, 2 || 3, 4 just doesn't work. I am trying to add some numbers as exceptions to the time of day restrictions.

For your regular expressions the "pattern , pattern" syntax is not supported. Unfortunately the Ruby engine that the sipsorcery server uses (IronRuby) is substantially more primitive than the fully blown Ruby distribution. If you want to match multiple expressions in a single regex use the '|' operator:

Thanks for the run down on iron ruby and why things do not work.
Appreciate it Aaron!

So what does /^.../, /^.../, /^.../ mean?
Or? Either?

Really? The commands are case sensitive? You know I think I have come across that before. Had problems after bulk selecting some lines of code and setting to lowercase in Notepad++. So if "req.Header.From.FromURI.User" will work, but ".from." won't...

Thanks again mate!
Will post full code snippet once complete for others to utilise...