Valid dial plan line is silently rejected

[ndemou]

As part of a migration from v5.3 to v.5.5 we backed up all domains from one server running the old version and restored them to an other running the new version (we couldn't just copy the filesystem because of bugs that were --rightly-- attributed to filesystem corruption).

 

Issues 1,2

Most of our domains use global dial plans but a few have their custom DPs. After restoring we found out that in some lines of some DPs the trunk had been replaced with "Unassigned". The funny thing was that if you switched the DP edit page to plain text mode you would see the correct name of the Trunk and you had to just hit save without touching anything and all was working fine. The Trunk was one of the basic ones we also use on the global DPs and had been defined long before starting the restore procedure.

The issues here are two 1) that the dial plan had not been imported successfully and 2) that the failure had not been communicated to us via the WebUI

 

Issue 3

Because of Issue 1 I found myself coping dial plans in plain text format from the old server to the new one and discovered another issue: When pasting a DP with this line (copied from the v5.3 server)

7;vPBX-MainOffice;;5xxx;;;false

This specific DP entry was not created from the plain text script. Creating it manually on the the webUI succeeded and gave me the exact same line. Here it is copied from the v5.5 server:

7;vPBX-MainOffice;;5xxx;;;false

There are again two issues here, the one of less importance is that this line failed to get interpreted and the one of most importance is that the failure had not been communicated to us via the WebUI.

 

I consider the later issue (silent errors) extremely import. In this particular case the absence of the above DP line resulted in some calls not getting through. So the customer complained, we found out we fixed it and the harm was small. But consider this: we have dial plans were a few lines with high Pref are blocking high cost destinations. No one will complain if the dial plan missed these line until after a beefy bill at which point we'll have to pay for the calls (because blocking them is a contractual obligation). As you can understand we found ourselves spending more than an hour checking DPs line by line (we guessed that such lines will not be eaten by a bug --because they are even more simple that the above-- but we could take the risk).

[Vodia PBX]

For upgrading versions, I would just install a 2nd system and copy all files over. Doing this domain by domain can be indeed tedious. And those things that have a scope beyond the domain are indeed a problem.

 

The trunks are usually stored by their numbers. This is necessary to make it possible to rename trunks (we don't do that everywhere like in the hunt groups, but in principle it is a good thing to keep ID instead of names). In the text view, that is different where the trunk name is stored. Therefore, the text view is a good workaround when using global trunks. When you hit the save button, it will attempt to find the trunk and in you case that seems to work fine.

 

When you move the domain to another system where the global trunk has a different ID and even a different name, that will obviously not work.

 

The text mode for the dial plans make a lot of sense when you want to bulk transport then. See the input element-based dial plan only as a pretty way to enter the lines if you are not familiar with the editor. At first glance I don't see why the dial plan text import would not work. What you could do is to compare the text view during import and after import. In theory they should be the same. If there is a difference, well then that is something that should be checked.