<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Yes, using module unload / load from CLI didn't shut the trunk down as did Zap restart. I've took a stab at capturing the debug log from Chan_zap.c as it outputs when 1.4.7.1 and 1.4.8 were installed (Make install). You can see that there is an exception 14 generated when 1.4.8 is installed. Also, I noticed an error message (I think from ztcfg during boot when 1.4.8 was installed) about and error trying to load loadzone=us from zaptel.conf. I don't know think this is a problem since it didn't complain about loading defaultzone=us (or does the load stop on first error?). I've removed ZTdummy from my loaded modules, just have wcfxo and wcusb loaded. Does this output provide any further insight?<BR>
<BR>
1.4.8<BR>[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Using channel 1<BR>[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Dialing '4165551212'<BR>[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Deferring dialing...<BR>[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Exception on 14, channel 1<BR>[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Got event Hook Transition Complete(12) on channel 1 (index 0)<BR>[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Exception on 14, channel 1<BR>[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Got event Dial Complete(9) on channel 1 (index 0)<BR>[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Enabled echo cancellation on channel 1<BR>[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Engaged echo training on channel 1<BR>[Jan 19 12:57:50] DEBUG[4393] chan_zap.c: Exception on 14, channel 1<BR>[Jan 19 12:57:50] DEBUG[4393] chan_zap.c: Got event Dial Complete(9) on channel 1 (index 0)<BR>[Jan 19 12:57:50] DEBUG[4393] chan_zap.c: Echo cancellation already on<BR>
<BR>
1.4.7.1<BR>[Jan 19 13:07:54] DEBUG[4095] chan_zap.c: Dialing '4165551212'<BR>[Jan 19 13:07:54] DEBUG[4095] chan_zap.c: Deferring dialing...<BR>[Jan 19 13:07:56] DEBUG[4095] chan_zap.c: Engaged echo training on channel 1<BR>[Jan 19 13:07:58] DEBUG[4095] chan_zap.c: Echo cancellation already on<BR>
<BR>
Syd<BR>
<BR>> Date: Sat, 19 Jan 2008 01:21:28 +0200<BR>> From: tzafrir.cohen@xorcom.com<BR>> To: asterisk-dev@lists.digium.com<BR>> Subject: Re: [asterisk-dev] Zaptel-1.4.8; Zap trunk reverts to dialtone instead of processing call<BR>> <BR>> On Fri, Jan 18, 2008 at 06:03:09PM -0500, syd wonder wrote:<BR>> > <BR>> > Thanks Tzafrir, kinda weird results though. <BR>> ><BR>> > cat /sys/module/zaptel/version did report 1.4.8 was installed once <BR>> > I issued the ./live_zap unload, load sequence. I was able to make <BR>> > a call out through the FXO fine. Not being certain that everything <BR>> > was loaded I decided to issue a "zap restart" command from the CLI. <BR>> > This totally shut down the trunk. <BR>> <BR>> If instead you use 'module unload chan_zap.so' followed by: 'module load<BR>> chan_zap.so', is it any better?<BR>> <BR>> > When I issued a "Zap show status" <BR>> > command I noticed that ZTDummy/1 was no longer present. If I am <BR>> > interpreting the status returned text correctly, ZTDummy is the <BR>> > source of my clocking so this scenario of totally loosing the trunk <BR>> > makes sense. Why would it show ZTDummy (RTC) when I have an FXO card?<BR>> <BR>> You don't need ztdummy if you have a hardware device. <BR>> <BR>> -- <BR>> Tzafrir Cohen<BR>> icq#16849755 jabber:tzafrir.cohen@xorcom.com<BR>> +972-50-7952406 mailto:tzafrir.cohen@xorcom.com<BR>> http://www.xorcom.com iax:guest@local.xorcom.com/tzafrir<BR>> <BR>> _______________________________________________<BR>> --Bandwidth and Colocation Provided by http://www.api-digital.com--<BR>> <BR>> asterisk-dev mailing list<BR>> To UNSUBSCRIBE or update options visit:<BR>> http://lists.digium.com/mailman/listinfo/asterisk-dev<BR><BR><br /><hr /> <a href='' target='_new'></a></body>
</html>