Hi Dave,

Actually, I got it fixed late last night, probably due to shear 
stubbornness more than anything.  I had to run the ./install_all.sh, 
which basically compiles [EMAIL PROTECTED] all over again. I had already done 
some of this when I discovered that the SMP kernel source 
references had and extra dash in it.  The zaptel portion of the CLI 
commands were not available (ie - help zap), so that was the final 
clue.  Only the full compile added the missing commands. Only then 
was I able to dial the ZAP trunk.

Its nice to be able to run parallel systems with @home so that you 
can see what is normal and what isn't, especially if one system 
actually works.  The difference was SMP on the home server (using 
an old ASUS P2 board), but I gather that has been patched in 
@home 2.2.  Its just that the PERL install is broken there so 
dialparties.agi couldn't run. I'm not sure if that would have been 
easier to fix, but look at all of the fun I would have missed!  Another 
weird thing was that calls to other extensions only started working 
after I added two more extensions to the ring group.

I'm just running an X100P card and a Grandstream Handytone 488 
for the wife's cordless.  Now I just have to juggle the incoming calls 
around a bit to stop them from going to one extension only and then 
see if the Handytone will actually ring the cordless.  That is the way 
its supposed to work, right?

We actually have a much bigger project in mind here at Message 
Centre PEI: a complete replacement for a TAS system.  Don't ask 
us what we are running now.  Its too ancient.  The home server is 
more of a pilot project. Wish us luck!  The project SEEMS very 
doable.

Regards,
Peter M.

> I have to say that I'm grateful for [EMAIL PROTECTED]  I wouldn't have
> had the time to try out so many different things if it hadn't come
> together in a nearly ready state.  Personally I'm not a linux guru so
> it's nice to not have to take hours learning how to install Apache and
> configure it just to take a look at Flash Operator Panel, for
> instance.
> 
> Having said that, I have had my share of seemingly random grief moving
> from one version to another.  My @home box is just a toybox, my
> everyday system is a box that I built from scratch.  As Simon
> suggests, it's a little easier to trust something when you put it
> together yourself.  I'm torn though, my main box is way behind on
> several components and I've considered just dropping the @home CD in
> to save lots of time and get the benefit of features that I wouldn't
> otherwise have taken the time to install.
> 
> Peter:  I'm interested in the problem you're having.  Do you mean that
> you can't dial any zap phones or use any zap trunks?   What sort of
> error do you get?  Maybe I can replicate the situation over here. 
> What sort of hardware are you using.
> 
> Dave
> 
> On 1/16/06, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > I think we're better off using [EMAIL PROTECTED] 2.1 for now. I don't think 
> > 2.2 is
> > an official release.  It hasn't shown up on the main site yet for a
> > while now.  When I went to test the dialparties.agi PERL script, I
> > found that the PERL install was messed up.  The yum update just
> > made things worse so I went back to 2.1.  After patching for an extra
> > "-" in the SMP kernel source, I finally have it mostly working but the
> > ZAP line is not available.  If anyone knows the way to get the "zap"
> > command back, it would be appreciated.
> >
> > [EMAIL PROTECTED] sure packs a lot in, but that seems to mean there is lots 
> > to
> > go wrong. Comments anyone?
> >
> 


**********************************************************
Peter MacFarlane
Network Administration & Programming
Target Call Center/Message Centre PEI
**********************************************************


Reply via email to