[Asterisk-Users] TE110P flashing red/green when PRI connected
... continued
Peter Svensson
psvasterisk at psv.nu
Tue Aug 9 22:34:12 MST 2005
On Tue, 9 Aug 2005, Fredrik Lithén wrote:
> Perhaps everything isn't as spiffy as I thought
>
> When running zttool the card still reports as internally clocked
>
> Zaptel.conf:
> # Global data
> span=1,1,0,ccs,hdb3,crc4
> bchan=1-15
> dchan=16
> bchan=17-31
Zttool still shows the card as internally clocked and you have a working
connection at the same time? The only explaination I can come up with is
that the changes to zaptel.conf have not taken effect. There have been a
lot of talk about ztcfg requireing a full power cycle for come changes.
It should not be possible for your card to be internally clocked given the
above configuration.
> And as pointed out by Peter I do get a lot of D-channel warnings ...
> Aug 9 16:21:25 NOTICE[1350]: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
This can be related to bit slips. Another possibility is missed
interrupts. These can be checked in /proc/zaptel/1.
> And furthermore, now I've discovered that all channels seem to reboot from time to time
> Aug 9 16:15:18 VERBOSE[1350]: -- B-channel 0/1 successfully restarted on span 1 ...
>
> Could this be a HW problem with either the wiring, the PC or something else?
Asterisk will reset unused channels once an hour by default. This is
intended to keep channel state mismatches between the two endpoints from
persisting indefinitly. The is harmless most of the time.
Some equipment does not like these resets and there is some disagreement
whether it is fully within the specification to send these automatically.
The interval can be changed or the feature disabled with the
"resetinterval" option in zapata.conf. We have a pbx that resets the whole
E1 span in response to these requests, including active channels, so we
have had to disable these resets.
The resets will also be performed if the isdn signalling has been down on
a span. If you get slips or irq misses bad enough this is a possibility.
Peter
More information about the asterisk-users
mailing list