Oddly, both systems are using the exact same install of the very same Distro. I did a single install onto a VMWare Player machine and the shut it down, copied the VMWare machine and set it up somewhere else. The original is the one with the error message. The copy still works just fine.
I’ve done a ton of testing with the original, but nothing at the command line. Just a lot of changing the configuration using FreePBX. I’ve gone through all the general configuration and advanced configuration settings and they are all the same.
Well conference rooms require dahdi so you need to get dahdi working. Virtualizing Asterisk and FreePBX has known issues and dahdi is one of them as dahdi also to operate correct needs hardware timing.
Conference room seems to work fine, in that I can have multiple people join and we can all talk. And the recordings work fine on one of the two virtualized systems.
Are there any commands that I could run to get some output on how Dahdi is working, so that I could compare the working and the non-working system?
I executed the yum commands there, did an amportal restart, and now dahdi show channels works.
The only difference between these two systems is when I executed the update scripts. I’m guessing that, at some point, you had a problem with the update scripts that wasn’t loading one of the dependencies that were need for Dahdi to load.
System #1 and #2 were originally the very same VMWare Machine. I did an initial install last year when the Distro was relatively new (System #1). I then made a copy of System #1 before any configuration changes were made to create System #2. System #1 and System #2 were then configured to different locations, using similar configurations. Both were both upgraded using the upgrade scripts to 1.86.29.55-1, but at different times.
System #2 reports that libss7.i386 and libopenr2.i386 are installed.
I then checked a backup of System #1 from two weeks ago, it reports that neither of these were installed. When I install them on System #1, the conference recordings work.
Do you recall if this was a problem with the update scripts that you corrected?
Based upon everything I’ve seen, I’m guessing that the upgraded Dahdi needed an updated version of some of these programs, and that they didn’t get updated as part of one of the scripts. I know that there have been times where you found a bug in the upgrade scripts and fixed it. I wonder if this isn’t one of those cases.
In any case, I did a fresh install of 1.87.29.55-2 and also of the latest version and both load chan_dahdi.so just fine.
I’m running fresh install of 1.88.210.57.
Two problem noticed:
1 - The first user of the conference room has to enter PIN code twice.
2 - Conference recording does not work. In the CLI I can see the following lines:
Starting recording of MeetMe Conference 585 into file (null).(null).
Starting recording of MeetMe Conference 585 into file /var/spool/asteri sk/monitor/2012/03/25/conf-585-585-20120325-211117-1332724277.49546.wav.
but no folders/files were created in /var/spool/asterisk/monitor.
I have found that if the folder under /var/spool/asterisk/monitor/YEAR/MONTH/DAY is not already created then the conference recording will not work as it will error out saying that the path is not valid.
2012-06-11 17:25:31] WARNING[1026] file.c: Unable to open file /var/spool/asterisk/monitor/2012/06/11/conf-2897-2897-20120611-172530-1339449930.175763.WAV: No such file or directory
Any more word on this? I also have run into this, and am currently using a workaround by recording a call before trying to record a conference so that the folder structure gets created.
Digium’s Bug Tracker shows this issue as closed, and “Not a Bug”
Essentially this runs 2nd after the dialplan sets the CALLFILENAME variable and makes the folder structure that the system is looking for when writing the conference to disk.
Spent a few hours screwing around with this today!