[asterisk-dev] Methodologies for validating dialplan

[Mark Murawski]

Oh!  And One more thing!

There needs to be an externally-facing way to call function/application 
validators for those of us who write dynamic dialplan generators.  Maybe 
an AMI command?


Action: ValidateFunction
Function: MAX
Param[0]: foobar

Response: Error
Message: All inputs must be integer


Action: ValidateApplication
Application: Goto
Strict: false    <-- allow for generic 'does it look okay' testing vs 
does the destination actually exist
Param[0]: foo
Param[1]: bar
Param[2]: 1234

Response: Success
Warning: Destination context 'foo', extension 'bar', priority 1234 does 
not exist



Action: ValidateApplication
Application: Goto
Strict: true
Param[0]: foo
Param[1]: bar
Param[2]: 1234

Response: Error
Message: Destination context 'foo', extension 'bar', priority 1234 does 
not exist




And then more of a full validator via a new application and AMI Command
ValidateDialplanFile(/tmp/new_extensions.conf,/tmp/path_to_errors.log);
^--- Sets DIALPLAN_VALID = 1/0

Action: ValidateDialplanFile
File: /tmp/new_extensions.conf
Log: /tmp/path_to_errors.log

Response: Success



And, direct response via AMI


Action: ValidateDialplanFile
File: /tmp/new_extensions.conf

Response: Error
EventList: start
Message: Errors/Warnings will follow
....etc etc



On 1/5/22 18:06, Mark Murawski wrote:
> Hi!
> 
> Throwing my .02 in here.  Adjust to .10 for inflation!
> 
> 
> On 1/4/22 14:53, asterisk at phreaknet.org wrote:
>> .... However, there are a lot of dialplan problems that represent 
>> potentially valid syntax that will cause an error at runtime, such as 
>> branching to somewhere that doesn't exist. The dialplan will reload 
>> with no errors, since there isn't a syntax issue, but at runtime, the 
>> call will fail (and most likely crash). I found over the years that a 
>> lot of these were often simple typos or issues that were easily fixed 
>> but wasted a lot of time in finding solely in the "test, test, test" 
>> approach. Another common grievance I hear time to time about the 
>> dialplan is most issues are caught at runtime, not "compile time" 
>> (i.e. dialplan reload).
> 
> 
> I love it!
> 
> And... take an example from a basic cli call that has a validator built-in:
> 
> 
> 
> static char *meetme_kick_cmd(struct ast_cli_entry *e, int cmd, struct 
> ast_cli_args *a)
> {
>          switch (cmd) {
>          case CLI_INIT:
>                  e->command = "meetme kick";
>                  e->usage =
>                          "Usage: meetme kick <confno> all|<userno>\n"
>                          "       Kick a conference or a user in a 
> conference.\n";
>                  return NULL;
>          case CLI_GENERATE:
>                  return complete_meetmecmd_mute_kick(a->line, a->word, 
> a->pos, a->n);
>          }
> 
>          if (a->argc != 4) {
>                  return CLI_SHOWUSAGE;
>          }
> 
>          return meetme_cmd_helper(a);
> }
> 
> 
> This design pattern has self-contained validation.  And it's up to the 
> function to validate as much or as little as it wants to.
> 
> We would need a new ast_register_application_xml2 and 
> ast_custom_function_register2 to have a new design pattern for 
> self-validating functions and applications.
> 
> Each application would know what kind of parameters it takes, and what's 
> valid and not valid
> 
> new-stle for say... Goto Application
> 
> static int gosub_exec(int cmd, struct ast_channel *chan, const char *data)
> {
>      if (cmd == APP_PARAMS_VALIDATE)
>          ... do some validation!
> 
> 
> 
> ideally gosub knows it's being passed an exten/context/priority and can 
> call ast_exists_extension at dialplan parse time via the validator flow
> 
> This would be a major undertaking to add validation for every function 
> and every application but since dialplan is so ubiquitous and is 
> probably never going away... would make huge inroads to making sure 
> everything is as correct as possible at parse/load time.
> 
>