[asterisk-dev] Zaptel-1.4.8; Zap trunk reverts to dialtone instead of processing call

syd wonder sydsyd65 at hotmail.com
Sat Jan 19 12:23:33 CST 2008


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?
 
1.4.8[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Using channel 1[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Dialing '4165551212'[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Deferring dialing...[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Exception on 14, channel 1[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Got event Hook Transition Complete(12) on channel 1 (index 0)[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Exception on 14, channel 1[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Got event Dial Complete(9) on channel 1 (index 0)[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Enabled echo cancellation on channel 1[Jan 19 12:57:48] DEBUG[4393] chan_zap.c: Engaged echo training on channel 1[Jan 19 12:57:50] DEBUG[4393] chan_zap.c: Exception on 14, channel 1[Jan 19 12:57:50] DEBUG[4393] chan_zap.c: Got event Dial Complete(9) on channel 1 (index 0)[Jan 19 12:57:50] DEBUG[4393] chan_zap.c: Echo cancellation already on
 
1.4.7.1[Jan 19 13:07:54] DEBUG[4095] chan_zap.c: Dialing '4165551212'[Jan 19 13:07:54] DEBUG[4095] chan_zap.c: Deferring dialing...[Jan 19 13:07:56] DEBUG[4095] chan_zap.c: Engaged echo training on channel 1[Jan 19 13:07:58] DEBUG[4095] chan_zap.c: Echo cancellation already on
 
Syd
> Date: Sat, 19 Jan 2008 01:21:28 +0200> From: tzafrir.cohen at xorcom.com> To: asterisk-dev at lists.digium.com> Subject: Re: [asterisk-dev] Zaptel-1.4.8; Zap trunk reverts to dialtone instead of processing call> > On Fri, Jan 18, 2008 at 06:03:09PM -0500, syd wonder wrote:> > > > Thanks Tzafrir, kinda weird results though. > >> > cat /sys/module/zaptel/version did report 1.4.8 was installed once > > I issued the ./live_zap unload, load sequence. I was able to make > > a call out through the FXO fine. Not being certain that everything > > was loaded I decided to issue a "zap restart" command from the CLI. > > This totally shut down the trunk. > > If instead you use 'module unload chan_zap.so' followed by: 'module load> chan_zap.so', is it any better?> > > When I issued a "Zap show status" > > command I noticed that ZTDummy/1 was no longer present. If I am > > interpreting the status returned text correctly, ZTDummy is the > > source of my clocking so this scenario of totally loosing the trunk > > makes sense. Why would it show ZTDummy (RTC) when I have an FXO card?> > You don't need ztdummy if you have a hardware device. > > -- > Tzafrir Cohen> icq#16849755 jabber:tzafrir.cohen at xorcom.com> +972-50-7952406 mailto:tzafrir.cohen at xorcom.com> http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir> > _______________________________________________> --Bandwidth and Colocation Provided by http://www.api-digital.com--> > asterisk-dev mailing list> To UNSUBSCRIBE or update options visit:> http://lists.digium.com/mailman/listinfo/asterisk-dev
_________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080119/84d83d8f/attachment.htm 


More information about the asterisk-dev mailing list