Asterisk trouble after dbase migration Vicibox 8.0.1 > 8.1.2

[dspaan]

I want to migrate my Vicibox 8.0.1 servers to 8.1.2.

Of course this means Asterisk changes from 11 to 13.

What i did was:

1.Install a clean Vicibox 8.1.2 server
2.Upgrade the SVN of the older 8.0.1 server to the same SVN as the new 8.1.2 server
3.Run the vicidial backup script on the 8.0.1 server and export the database to the 8.1.2. server
4.Drop, create and import the database on the 8.1.2 server
5.Run the server update IP script, change the asterisk version on the admin>servers page, Rebuild conf=Y and reboot

After all that's done and i open the CLI and give a command like 'sip show peers' i get a message No channel type registered for 'SIP'.
When i issue the command module show like chan_sip.so it says the module is not loaded.

What could have gone wrong?

[williamconley]

If your asterisk version changed, you must reinstall asterisk with sample conf files included. Verify settings in Admin->Server Settings as well as /etc/astguiclient.conf. Pay particular attention to the Asterisk Version in all locations.

Also be sure "screen -r asterisk" shows "READY" at some point. Otherwise, you could be experiencing a delay in starting asterisk often due to the sqlite berkeley database being huge (must all be loaded into memory). Resolved easily by disabling sqlite. During the delayed load, asterisk modules after the "delayed" module will not yet be available.

[dspaan]

Don't know why but re installed the server, imported database again and now i'm not having this problem.

[williamconley]

Reinstall of the server dumps the sqlite DB. That DB can take a very long time to load (especially if the server wasn't shut down properly) and cause Asterisk to NOT be ready until the load is completed. Any traffic during that time can fail for multiple reasons (due to the missing modules waiting in line to load). So when the sqlite DB is empty ... asterisk loads instantly and those asterisk errors never happen. Until sqlite fills up again (which can take a couple years).

But in this case, it's more likely that your astguiclient.conf had a slight error. I've seen "11.X" vs "11" cause specific failures in the past. So your second run had a slightly different outcome quite possibly due to a couple characters difference. It helps if you keep a copy of the Summary of the perl install.pl output for future reference.

[dspaan]

Aha, good tip. Will save install output for next time to compare. In my memory i did the same steps but it must have been something i did different

[williamconley]

Our installers save this in our internal ticket for each install in case there's a problem. Has answered a lot of questions over the years in both directions (ie: Yep, you screwed up the install! and Nope, there was a bug, had nothing to do with you!)