[Asterisk-Dev] zaptel.conf generation

[Tzafrir Cohen]

Hi

This is basically a re-run of a message I have sent to the
asterisk-users list. However I feel that that list may not have been the
right place. Maybe I'll have more luck here.

One of the goals of Xorcom Rapid is to automate the installation as much 
as possible. We know that a typical Linux installation will now 
configure apache+modphp+ssl and it "just works".  Therefore we figured 
Asterisk could be made to work the same.  We want to make the system to
have the sanest defaults and to have it do automatically anything that
is safe to automate.

Asterisk will simply abort with an incorrect Zaptel channel
configuration, as opposed to other channels that are optional. This
makes automatic detection of Zaptel cards even more important.


We wrote some detection scripts that do a great job of auto-detecting
the hardware we currently have. They are part of our modified Zaptel
package and we hope to push those changes to Debian and/or Asterisk. 

The basic script is /usr/sbin/genzaptelconf . It attempts to generate a
working /etc/zaptel.conf or /etc/asterisk/zapata.conf according to what
it sees on /proc/zaptel .

Originally it was just a glorified awk script without much logic inside.
However from the data in /proc/zaptel we have no way to tell if a
channel is available or not. The card we tested it with was a TDM400P
with just one FXS module.

Our simple test to tell if the channel is a working module or not was to
try to open it and read one byte from it (head -c1 </dev/zaptel/NUM) .
But we first had to verify that the channel is working. We did this by
running ztcfg with a temporary configuration file.

This worked fine for that card and for our FXO cards. But when we got 
to the E100P card the reading of the byte hanged. Therefore we decided
to skip it for the moment .  What exactly can I tell automatically about
E1/T1 cards? What about other cards?


/usr/sbin/zaptel-detect uses genzaptelconf to detect which modules could
be loaded. It starts by rmmod-ing all zaptel modules. Then for each
module it loads the module and checks if the load of the module has
changed the size of the output of genzaptelconf. If not, then the module
probably does nothing. 

I figure that eventually we will get a small c program that will contain 
all the relevant tests. Maybe ztcfg could be patched/abused .  


genzaptelconf does not attempt to generate a complete zapata.conf.
Rather , it creates /etc/asterisk/zapate-channels.conf , which is
#include-d by the main zapata.conf . Is there such a trick possible with
zaptel.conf?

The format of zapata.conf doesn't really help auto-generation: If you
put something in one extension you should take care to remove it later,
so it won't affect others. This is very unlike sip.conf and others.

The scripts are available from our zaptel package:
http://updates.xorcom.com/rapid/pool/zaptel/zaptel_1.0.2-1.2_i386.deb
and also directly from:
http://updates.xorcom.com/genzaptelconf
http://updates.xorcom.com/zaptel-detect

1. Currently we have a very short list of card signatures. Additions
   would be welcomed. 

2. Besides the signatures: what do we need to detect with other zaptel 
   channel types? 

3. keeping existing configuration in zaptel.conf (not an issue with
   zapata.conf, due to the use of #include). 

4. So maybe genzaptelconf should read and parse the existing zaptel.conf. 
   This will also allow it to write zapata-channels.conf without
   re-testing everything.

5. Debian (and hence Rapid) ships with discover (v1) and hotplug by
   default. Would it be smarter to use such a framework?

   How can I tell discover to use information from /proc/zaptel in
   addition to lspci and such?

-- 
Tzafrir Cohen   icq#16849755    050-7952406
tzafrir.cohen at xorcom.com  http://xorcom.com