*abridged* :)
I have been attempting to get a Trixbox up and running with a Beronet 4 port ISDN card. (explaining my recent absence from the board). The card is a 'standard' HFC 4s card (looks pretty much like the design on the HFC website). It has all the bells and whistles and is cheaper than others on the market? (more cost effective? Whatever)
I am posting this with my recent experiences and as a general discussion of HFC cards. There are various other posts discussing this on the forum.
Before anyone berates me for being foolish, I did not use the ZAPHFC drivers at all. I had some reasons for doing this mostly to do with gaining the impression that the drivers are a 'hack' against the zaptel driver and may or may not survive a future update of the zap drivers. I was looking for an elegant solution and my impression was that Bristuff is not elegant. However I do understand that they are a proven solution in use in many installations (and they work!).
Ok. So onto the chan_Misdn drivers. I installed these using the script from the Beronet site. Good script, very simple, does everything for you. However, after spending some hours/days/nights trying to figure them out and working with the Beronet support guys the following comes to light:
chan_mISDN has some minimum requirements which are not clearly documented:
1) You need to use the latest stable kernel (minimum=2.6.14, current=2.6.16.20). I did this on my Trixbox and the drivers worked much better (or even, worked!). This is a kludge and counter to the Trixbox spirit. You move out of the normal update procedure and need to take care about future updates. The Centos/Redhat kernel is 2.6.9 based with patches back ported from later stable kernels.
2) The second one is you need to have a kernel with the profiling option turned off at kernel compile time. If profiling is on on your kernel then your trixbox suffers from high cpu load issues and machine lock ups. This situation is at best sub-optimal. The Centos distribution has a pre-compiled kernel with profiling turned on and probably will continue to have in the future.
The short answer is mISDN is not compatible with the standard Trixbox distro. Probably can never be due to the profiling issue.
Although the Centos kernel is based on an old stable kernel it is regularly updated by Redhat. I would guess if you used a standard Centos kernel with profiling switched off chan_mISDN will probably work.
Ok, onto vISDN. I tried these drivers out of desperation (constantly seeking beauty and elegance in the world....actually no, I just felt like it at the time). Ok they don't 'look' good at the moment but architecturally they are elegant. What speaks to this elegance is that they work with kernels all the way back to 2.6.8 (with profiling switched on!). Apparently, not tested this myself.
I did have them working on a trixbox install a couple of days ago though. The main issue was the neccessity to patch asterisk source and re-compile to get the chan_visdn.so to work properly. If you don't asterisk doesn't see the driver and your asterisk log gets full of ISDN errors. Once patched all works well. The biggest problem with this was that an asterisk re-compile breaks various bits in the Trixbox/Freepbx..... :(
I am not experienced enough to fix them. I did read about an asterisk compile option that may help here. Unfortunately I had blown away the Trixbox install and reverted to AAH 2.8 due to time constraints.
For the adventurous try the following:
1) Build your Trixbox. Install vISDN. Get the same version of the asterisk sources as on the latest Trixbox update (from the SVN). Put them in /USR/SRC/ASTERISK
2) cd /usr/src/asterisk
3) make clean
4) make bininstall
I believe this will just replace the binaries without touching any of the configs. So Trixbox should work as it did but with the additional patches installed. Maybe Andrew could do us a test version of the Trixbox Asterisk RPM's with the patches? (oh, go on matey)
VISDN installs a driver and an asterisk module (chan_visdn.so).
Note regarding the need for an Asterisk patch. The developer believes this is an Asterisk issue in the way that it handles ISDN (or Euro ISDN) and doesn't need to be fixed by vISDN but by Asterisk.
Some Notes for anyone having a go:
1) Lots of info on the visdn hackers mailing list. Go to http://www.mail-archive.com/ and type visdn in the box and click on find list. Much easier to read than the archives. It's a bit random but ALL the info u need is there.
2) there is an AAH 2.8 howto on the mailing list that has most of the steps you need to install the drivers and get things right. some modification needed for Trixbox.
3) If you are having problems and you need to, google for a udev 0.51 rpm or higher and install. It is a known working version (Centos has version 0.39 - this should still work but you need to config the udev permission.d files a bit differently. Upgrading udev should not break anything on your Trixbox (quite the opposite - things might work better!).
4) If the drivers are not loading (you can't see visdn interfaces if you run 'ifconfig') try and re-locate the pci configuration file. Success in installing the drivers is demonstrated by seeing visdn interfaces when the ifconfig is run.
5) the file - /etc/init.d/visdn-init doesn't work for centos properly. It was written for SUSE. If you comment out any commands that have rc.xxxxxx commands the file works to start and stop visdn but not the others - e.g. status, reload etc. This would be very useful to fix (er.... my shell scripting skills are rubbish - volunteers?). We can then use chkconfig to start the visdn drivers at runlevel 1/2 so they are available to asterisk which starts at runlevel 3. The work around here is to do a chkconfig --del asterisk (i.e. stop asterisk auto running early in the startup) and then edit /etc/init.d/rc.local and add /usr/local/sbin/visdn_configurator before the asterisk line already in the file. Asterisk starts last after all drivers have loaded. Otherwise you have to do a 'amportal restart' when you can get a login.
Unfortunately I don't have a machine or ISDN card (or ISDN line for that matter) any more. The window for my opportunity has passed :(
Anyone want to take the batton from here? I would really like to see visdn succeed. Like I said its an elegant solution.
Rehan
Member Since:
2006-06-02