Validation Issues

Validation is the mechanism used by VRC to detect and prevent illegal or inconsistent data from being written to the dial plan or sent to the network elements.  When errors are detected by the validation process, messages are produced and presented to the user through the client user interface (validation indicators), and through the server logs (system, audit, and internal).  

Validation is executed implicitly as part of some design operations, and explicitly when you choose Validate from the Design menu.  The appropriate recourse for troubleshooting validation errors and warnings depends on the type of operation being performed.

Design modification operations include the addition, modification, or removal of any dial plan component from the Design View.  When a design modification operation is executed, the validation process checks the affected object only, and determines if the modification being made is valid.  If not, the modification is rejected and you are presented with an explanation.  

To correct validation errors produced by design modifications, retry the modification in a way that addresses the conditions described in the error message.

Dial plan generation operations include the commit, distribution, or preview of CLI generated from the Design or Baseline View.  When a dial plan generation operation is executed, the validation process checks the full dial plan before generating the CLI.  If the validation fails, the operation does not continue and you are presented with an explanation.  

To correct validation errors produced by dial plan generation, review each error and manually correct the dial plan using the Design View for your modifications.  The validation message should direct you  to the components that require correcting, and which attributes are in violation.  

Certain elements (gateways, gatekeepers, directory gatekeepers, managed regions, foreign regions, managed zones, ingress routes, and egress routes) have "Validation state” attributes which indicate the severity (Fatal, Warning, OK) of the most significant validation message produced for those components.  Those in a Fatal or Warning state are indicated in the dial plan tree on the user interface.

For network elements, you might only be able to correct certain errors by reactivating the element. For example, if a gateway has the “reactivate” attribute set as “yes”, or an element has a required read-only field such as “h323id” not set at all, then an error is produced during validation.  In these examples, the failed element must be explicitly reactivated by the user to set these attributes to a state in which they can be committed.

Dial plan discovery operations include activation, reactivation, discovery, and import.  For these operations, validation is performed implicitly as an audit of the modifications made to the dial plan. Error messages produced by implicit validation of dial plan discovery operations notify you that the design is no longer in a state that can be committed to the elements.

Validation errors produced by dial plan discovery operations do not need to corrected immediately, because the operations succeed despite any errors.

Address issues raised by dial plan discovery validation errors in the Design View before you commit the design to the elements.

Explicit validation is triggered when you choose Validate from the Design menu.  This executes a validation of the entire design scope, the same as for dial plan discovery operations.  An explicit validation provides an audit of what changes must be made before you commit the design to the network.