[Asterisk-Dev] The Zaptel init scripts must die!

[Tzafrir Cohen]

On Wed, Dec 14, 2005 at 12:25:06PM -0600, Steven Critchfield wrote:
> Not knowing where to place this comment in this thread, I have just
> attached it to the root.
> 
> Is there a compelling need for Zaptel to stay backwards compatible? 

First-off, there is the zaptel kernel module and chan_zap of Asterisk.
Which of them do you have in mind. Note that with all the asterisk 1.2
breakage parade, the interface to the zaptel 1.0 kenel code has remained
stable.

There is existing code and configuration that relies on it. So it would
require a very good reason to break.

> Also
> is there a compelling reason for each channel to be individually
> openable? 

a. Asterisk is not the only client of zaptel
b. Much of those "open"s actually go through the control channel.

> Some of the changes I am thinking of would break current
> config apps, and that is of some concern. Not to mention the flag day
> type of change we would be looking at.
> 
> I'm going to ramble a few thoughts out that may not be fully formed, but
> maybe it will spark a bit if creativity in someone else to finish the
> thought with some polish.
> 
> Where I am going with this is that it might not be necessary for us to
> deal with channels by number. Wouldn't it be nice to tag a set of
> channels with a useful name, and from then on out you use that name in
> reference to that set of channels. 
> 
> For T1/E1/PRI, you would probably name each span with something that
> referenced the end point, or split it for what ever tech you have
> attached to the channels. 
> 
> I could see the config file being similar to the dhcp config file when
> setting up static addresses. All channels are relative to the device
> being configured. A sample is listed below. 
> 
> One of my reasons for thinking this way is that eventually we may see
> asterisk run on hardware with hotswap capabilities and chassis designs
> such that adding or replacing devices might be done more frequent than
> asterisk restarts. If we could push the name of the channel instead of a
> number, we could possibly make the number of config changes needed to be
> made after hardware change minimal.

I'm not sure I follow you. You suggest moving from a flat scheme to a
scheme where channels are grouped by names? 

However, why should that information be written in zaptel.conf ? Maybe
pass the information up to chan_zap and let it decide?

See my next reply soon...

> 
> If asterisk only needed to open the zaptel driver up and pass messages
> with it instead of each individual channel, we might get away from
> asterisk needing to have intimate knowledge of how the underneath is
> wired up. For instance with the below config example, if I wanted to
> dial Zap/Steven, zapatel could say the line is unavailable, and the
> underlying cause could be no device. Once the device was made available,
> and asterisk attempted the dial again, then we could complete with
> success. If I changed where my phone was plugged in, I could limit the
> change to the lower zaptel config file and nothing else. 
> 
> I'll stop here and let those of you with more and deeper knowledge think
> and debate on this.
> 
> device wct1xxp {
> 	slot PCI:00:08.0
> 	# later options
> 	# hardware-id TBD

What I don't like about such a format (and its close relative: XML) is
that it is not simple to generate in parts. Suppose I have discovered
a new FXO adapter and want to update the config file: how do I do that?

I need complex text-processing routines for that.

Though I agree that zaptel.conf as is is not extendible enough.

Another note, off the top of my head: I'm always looking for simpler
ways to configure. Your "suggested" configuration scheme is modeled
after ISC's dhcp server. That server indeed has a very flexible
configuration, but a very cinfusing one. You won't appreciate just how
confusing until you start using a tool with saner defaults like dnsmasq.

> 
> 	# connected to old Zhone box
> 	span Zhone {
> 		span 1
> 		timing 1
> 		lbo 0
> 		framing esf
> 		coding b8zs
> 	}
> 	name FXO {
> 		channels 1-8
> 		signalling fxsks
> 	}
> 	name PJO {
> 		channels 9
> 		signalling fxoks
> 	}
> 	name Steven {
> 		channels 10
> 		signalling fxoks
> 	}
> 	name John {
> 		channels 11
> 		signalling fxoks
> 	}
> 	name unused {
> 		channels 12-24
> 		signalling fxoks
> 	}
> }
> device tor2 {
> 	slot PCI:01:00.0
> 	# later options
> 	# hardware-id TBD
> 
> 	# connected to TelCove
> 	span TelcovePRI {
> 		span 1
> 		timing 1
> 		lbo 0
> 		framing esf
> 		coding b8zs
> 		dchan 24
> 	}
> 	span analogT1 {
> 		span 2
> 		timing 0
> 		lbo 0
> 		framing esf
> 		coding b8zs
> 	{
> 	name Telcove {
> 		channels 1-23
> 		signalling bchan
> 	}
> 	name Adit {
> 		channels 25-48
> 		signalling fxogs
> 	}
> }
> 	
> -- 
> Steven Critchfield <critch at basesys.com>
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> Asterisk-Dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 

-- 
Tzafrir Cohen     icq#16849755  +972-50-7952406
tzafrir.cohen at xorcom.com  http://www.xorcom.com