Meetme conference doesn't record

Below is what I get when somebody enters the conference

-- Created MeetMe conference 1023 for conference '6789'
   > Starting recording of MeetMe Conference 6789 into file (null).(null).

Using Asterisk 1.8 inside an openvz container, meetme works (compiled asterisk after copying dahdi/user.h and making /dev/dahdi/pseudo available to the container) but is not compiled. Is that a requirement for meetme recording to work ( says it is). If so how can I make asterisk compile with



I’ve not installed from sources but sure looks to me:

cd /ast/home/dir make menuselect
is what you need to run to add chan_dahdi, or any other options, to your install

Yes I thought so too, but under Channel Drivers, chan_dahdi is XXX



To make compile you require /usr/lib/

Just download dahdi source and you will find the file under /tools

After copying the file to /usr/lib you will have to link it in order for to find it.

the RHEL command is:

/sbin/ldconfig -v

Also, requires /etc/asterisk/chan_dahdi.conf. It is created when you run ‘make samples’. If you don’t have it you can find the sample file in asterisk source files under /configs/chan_dahdi.conf.sample. Just copy and rename.

Don’t, however, expect something that needs internal timing, like meetme, to work well on a virtual machine.

It does work pretty good if you make the device available inside the vm. … Me_problem

I recently used binary RPMS (asterisk18) for meetme inside a vm with recording, so those are also working.


It depends on how heavily loaded the host is. VM environments tend not to run guest time at 1ms per ms, so you can have large gaps followed by sudden catchups, which make the audio choppy. The CPU can be denied the guest for longer than VoIP will tolerate.

Can you elaborate? How loaded does the server need to be before this starts happening? I have Quad Core Xeon servers running multiple OpenVZ Asterisk/FreePBX servers and no timing problems. Then again meetme is a not used very much and I am starting to use confbridge instead to get away from the hassle of dahdi dependency.

I never let average CPU utilization go over 20%. If it get’s up to that I won’t add any more virtual servers. OpenVZ actually scales remarkably well. You can put a surprising number of Asterisk/FreePBX virtual servers on a physical server and have them work well. So as far as I’m concerned it is not difficult or expensive to have this work well. On the other hand if you are trying to run 20 busy virtual servers on a Celeron processor they yea, you may have problems. Not just with meetme timing but sip calls in general.