OpenVZ Conference Bridging and Zaptel

[KUMARULLAL]

Hi I am using the pbiaf on openvz. Things seem to work fine with other features but when in comes to conference bridging, it is not working.
For example, followme, or transferring an external inbound call to an external phone number does not work. The call is made, but then there is no music on hold for the 1st caller, and as soon as the call is bridged between the 2 external numbers, no one can hear anything.
How do we solve this issue?
Next thing is that, the Zaptel module is not loaded on the pbiaf VM.
As far as the Zaptel is concerned, since I know that the guest os shares the kernal with the host OS, is it required to install just the zaptel module on the host system (openvz server) ?
The openvz server runs on Debian Lenny.
How is this solved?
Please help!!!!

[jroper]

Hi

The issue, as you have properly identified is that zaptel/dahdi is not installed on the virtual machine.

This is required as a timing source, so that conferencing can happen.

There are a few threads around on this, but no definitive step by step that I can find, either that, or I am not following instructions properly.

I do understand that Ward has access to the answer however:-

http://pbxinaflash.com/forum/showpos...5&postcount=45

Joe

[KUMARULLAL]

Thanks for the reply Joe.
As I suspected, it is the zaptel issue.
As Joe pointed out, According to Ward

32-bit Asterisk runs fine with OpenVZ. Zaptel needs to be installed on the server (properly) and then mapped to the VMs. We'll publish the solution used by a major VM provider soon.

Installing zaptel on openvz server "seems" straightforward. I am hoping that it automatically maps with the VMs ( I will try it and post my feedback), unless there is a process of mapping with the VMs.

HN configuration
Finally you need to make sure that on HN ztdummy kernel module is loaded and the access to /dev/zap/pseudo device file is granted to the container:
modprobe ztdummy
vzctl set 240 --devnodes zap/pseudo:rw --save
This will create /dev/zap/pseudo and /lib/udev/devices/zap/pseudo in your container. The group/owner will be root/root and the permissions will be 644. If you're running Asterisk under the asterisk user in your container, you will need to set the proper ownership for these devices in your VE. The /dev/zap devices are recreated whenever the container is restarted. The /lib/udev/devices/zap files are persistent. The key to only doing this once is to make sure you change the ownership in the VE of the /lib/udev/devices/zap files in addition to the /dev/zap files.
To set the necessary ownership in the VE:
vzctl exec 240 chown -R asterisk /dev/zap /lib/udev/devices/zap
vzctl exec 240 chgrp -R asterisk /dev/zap /lib/udev/devices/zap

The source link is here http://wiki.openvz.org/Asterisk_from_source
A bit confused on what to do.

[wardmundy]

Our stumbling block has been locating the kernel source for proxmox.

[KUMARULLAL]

I could successfully install the zaptel module in proxmox server.
This is a step by step instructions for it.

Installing zaptel module in proxmox server.
1)apt-get update
2)apt-get install pve-headers-2.6.24-7-pve (This is very important)

This can take a while. You can grab yourself a cup of tea or coffee.

Next change to cd /usr/src
wget http://downloads.asterisk.org/pub/te....4.12.1.tar.gz
Then
tar xvzf zaptel-1.4.12.1.tar.gz

Then
wget http://downloads.asterisk.org/pub/te...current.tar.gz

tar xvzf zaptel-1.4-current.tar.gz
Then
Cd / zaptel-1.4.12.1

Then run ./configure
You will get gcc error and some other error.
You need to install gcc by typing
apt-get install gcc

Then
apt-get install make

And then finally….
./configure
will work
Then
Run the command “make”
Will work.
And lastly
Run the command “make install”

And then run
“make config”


Zaptel is now installed on proxmox server
Now at command prompt rum "modprobe ztdummy"
Then run

echo "ztdummy" >> /etc/modules
Finally you need to make sure that on HN ztdummy kernel module is loaded and the access to /dev/zap/pseudo device file is granted to the container:
modprobe ztdummyvzctl set 250 --devnodes zap/pseudo:rw --save This will create /dev/zap/pseudo and /lib/udev/devices/zap/pseudo in your container. The group/owner will be root/root and the permissions will be 644. If you're running Asterisk under the asterisk user in your container, you will need to set the proper ownership for these devices in your VE. The /dev/zap devices are recreated whenever the container is restarted. The /lib/udev/devices/zap files are persistent. The key to only doing this once is to make sure you change the ownership in the VE of the /lib/udev/devices/zap files in addition to the /dev/zap files.
To set the necessary ownership in the VE:
vzctl exec 250 chown -R asterisk /dev/zap /lib/udev/devices/zap
vzctl exec 250 chgrp -R asterisk /dev/zap /lib/udev/devices/zap


I have done all this. But still meetme problem persists.
What am I missing.
I read somewhere to uninstall zaptel module from the VM.
I tried to uninstall zaptel but was unsuccessful.
How do I uninstall zaptel from the VM?

[KUMARULLAL]

I think it is not required to uninstall zaptel from pbxiaf image.
In any case, in-spite of giving access of zap/pseudo to container by running
vzctl set 250 --devnodes zap/pseudo:rw --save
I am getting error.
When I run
tail /var/log/asterisk/full
I get "app_meetme.c: Unable to open pseudo device"
Please help..................

[KUMARULLAL]

I am almost certain, in order to support conferencing and zaptel/dahd, the template must be built from a 64 bit OS.
It wont work with a 32 bit system.
Once you fire up the vm, you may need to do this.
mkdir /var/lib/vz/private/$VID/lib/modules/2.6.24-7-pve
Next
cp -r /lib/modules/2.6.24-7-pve/* /var/lib/vz/private/$VID/lib/modules/2.6.24-7-pve

[jroper]

Hi

I've spent quite a few hours on this, and had never considered the fact that Proxmox was 64bit, and the virtual image was 32bit, this maybe why I failed.

So logically, your suggestion that the HN and the image must both be 64bit sounds as if it has potential.

I'm off to go and see if I can make it work.

Joe

[merlyn]

Could the answer really be that obvious?

Would love to get this working on a vps online host.
I remember thinking a while back ... hell if Joe cannot get it working what chance do i have .... zero ... and shelved the whole idea. ...

been reading your posts with interest KUMARULLAL.

looking forward to seeing how this all works out.

merlyn

[jroper]

Hi

Merlyn, Your faith in me is touching ;-) although possibly misplaced.

It seems that using a 64bit image to build asterisk on, and doing some relatively simple steps on the HN seems to have cracked the problem of meetme conferencing.

Install and start zaptel or Dahdi on the HN

Install and build asterisk / freepbx blah blah on the VE.

Copy /usr/include/zaptel/zaptel.h on the HN to the same location on the VE.

If using dahdi, that should read /usr/include/dahdi/user.h

on the HN, run

vzctl set 103 --devnodes zap/pseudo:rw --save

Where 103 is the number of your VE instance

or

vzctl set 103 --devnodes dahdi/pseudo:rw --save

for Dahdi.

Then run the following on the HN

vzctl exec 103 chown -R asterisk /dev/zap /lib/udev/devices/zap
vzctl exec 103 chgrp -R asterisk /dev/zap /lib/udev/devices/zap

or

vzctl exec 103 chown -R asterisk /dev/dahdi /lib/udev/devices/dahdi
vzctl exec 103 chgrp -R asterisk /dev/dahdi /lib/udev/devices/dahdi

Then go to /usr/src/asterisk on the VE

make menuselect, and make sure that app_meetme is enabled under applications. If it is not, then select it, make and make install.

Finally amportal kill, then amportal start.

Testing is still taking place, but not looking bad so far.


Joe