[asterisk-dev] Zap channel naming is way too confusing

[Tzafrir Cohen]

On Fri, Feb 24, 2006 at 11:15:07AM +1100, James Harper wrote:
> > 
> > My thoughts along the lines of a fully sysfs/hotplug enabled Zaptel
> > include supporting 'named' spans... this could help in that area.
> 
> I'd like to add my vote to this, or something like it. I've just started
> toying with the 'dynamic' spans and it gets confusing as hell. And even
> without hotswap, the coldswap of a card might muck up your whole
> dialplan!
> 
> Maybe the channel number could look like this:
> Zap/ASSCCC
> A = adapter number
> SS = span number
> CCC = channel number

This is the channel number. Do I really need to expose the channel type
here? And the span of a simple analog card? What happens to a dynamic span?
What exactly is an "adapter" here?

This is useful for zaptel.conf, but more problematic in chan_zap.

> 
> Where the adapter number is configurable in the conf file somehow (see
> below), the span number is unique within to adapter, and the channel
> number is unique within the span.
> 
> Do any of the Digium adapters have unique id's like Ethernet adapters
> do? 

IIRC from a previous thread, it seems that Digium's cards will have. Our
adapters will soon have them (as of the second batch). 

> Otherwise I guess you could describe them by PCI bus or something.
> Maybe like this:
> adapter=<#>,<module>,<uniqueid>

This "number" is error-prone. You have to set it manually. If you finally
decide to break the format, get rid of that simple number. It essetially
leaves the same problem only requires writing yet other config lines.

> where # is the adapter number you are defining, module is the zaptel
> module name, and uniqueid is some per-module way of uniquely identifying
> an adapter, be it PCI bus address, Ethernet ID (for dynamic spans), or
> other id.
> 
> Then spans could be defined with reference to the adapter, and the
> channels (with my proposed channel numbering scheme) would self describe
> the adapter and span they belong to.

BTW: we basically have a script to rewrite zaptel.conf and zapata.conf.
Sadly this requires a restart of Asterisk. I bet it could be extended to
dynamic spans. Certainly if you expose enough information through
/proc/zap

Reconfiguration of a dialplan is more tricky. A poorman's wildcard
dialplan is, of course, something like:

exten=> _2XX,1,Dial(Zap/${EXTEN:1})
exten=> _3XX.,1,Dial(Zap/${EXTEN:1:2}/${EXTEN:3})

Add an extra digit if you have more than 99 channels...

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