ndemou Posted October 4, 2016 Report Share Posted October 4, 2016 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). Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.