[asterisk-dev] A plan for span

[Oron Peled]

On Tuesday, 8 בJuly 2008, Shaun Ruffell wrote:
> It's not ideal, but I still think it would be less risky / easier to
> implement especially since Xorcomm is already doing something similar.

Again. What we do solve only part of the problem (deterministic probe
order across boots). Still:
 - An addition/removal of single span, force a complete dialplan change.
 - There is no way to know when you have *all* devices (maybe the admin
   would plug another one after a cup of coffee). So we *hope* to see
   the probe calls before /etc/init.d/zaptel. If this is the case
   (luckily, it usually is), we have a mechanism to wait deterministically
   until initialization/calibration etc (by blocking on a read from a
   specific /proc file).

> My assumption (perhaps wrong) is that Asterisk itself cannot handle dynamic
> arrival and  removal of dahdi spans.

It didn't. That's why long time ago Tzafrir added a dynamic removal.
Look for ZT_EVENT_REMOVED. In the future, we can add dynamic addition.

> If this is so, as long as the registration utility is  
> told which unique devices to wait for,

That's the crux of the problem! Do you configure your kernel
about the order of SATA drives? iSCSI targets? That's exactly
the same problem (look at the LABEL= and later the UUID= parameters
added to mount, to see what I mean).

> Now, if we want to be able to walk up to a production asterisk system
> and just  plug in a new span or two and have it work....no....this
> won't cut it.

Why not? Can you plug an RJ45 into your laptop and have it magically
functioning? (DHCP, zeroconf, you name it).

Do you think in our lab we manually configure zaptel.conf+zapata.conf
every time we hook a new set of Astribanks for testing? (and each
such device contain a different *mix* of spans, mind you)

> I agree this would be better...but this is orders of magnitudes more
> complex.

It's somewhat more complex, but I fail to see the gigantic problem.

> Everything that refers to zap channels by a number would need to change, 
> dialplans, management scripts, call files, GUIS, etc..

Yes, but what about the proposed backward compatibility I proposed.
I think it would let you migrate *incrementally* as you want, since
the old /dev/dahdi/<number> would just be an alias (symlink) to
the new names.

-- 
Oron Peled                             Voice/Fax: +972-4-8228492
oron at actcom.co.il                  http://www.actcom.co.il/~oron
"Software is like Entropy: it's hard to grasp, weighs nothing and obeys the 
Second Law of Thermodynamics, i.e. it always increases" 
        -- Norman Augustine