[asterisk-users] Problems Connecting Two Asterisk Installs Via ISDN PRI Cards

[Brian Alexander]

I am trying to connect two machines to each other with an T1 crossover
cable. The first machine has two TE120P cards - one connecting to the telco
on an ISDN PRI. The second to a crossover T1 cable to a second machine which
has one TE120P card.

  Telco <-cA-> Machine1 <-cB-> Machine2

  Machine1: Two TE120P cards
  Machine2: One TE120P card
  cA: Standard T1 Cable
  cB: Crossover T1 Cable

Configuration files are included at the end of this message.

I have used both 'cat /proc/interupts' and 'lspci -vb' to verify that the
cards do not have IRQ conflicts. Machine2 can be plugged into the telco pri
and works fine. Machine1 works on the telco PRI so long as I have removed
the configuration for the second span (the one on the crossover). I can
leave the card for the second span in - so long as it is not configured.

Machine 1 CLI Notices
====
If both cards are configured and connected. Zttool reliably reports no
alarms. Asterisk appears to start without errors at verbosity three. Very
quickly after it starts Asterisk starts reporting

  WARNING[28899] chan_zap.c:6668 handle_init_event: Detected alarm on
channel NN: Red Alarm
  WARNING[28899] chan_zap.c:1464 zt_disable_ec: Unable to disable echo
cancellation on channel NN

It will output these for all the channels on the second span (NN ranges from
25 to 47). It then will report

  NOTICE[28898] chan_zap.c:8460 pri_dchannel: PRI got event: Alarm (4) on
Primary D-channel of span 2
  WARNING[28898] chan_zap.c:2393 pri_find_dchan: No D-channels available!
Using primary channel 48 as D-channel anyway!

This is immediately followed by a notice that the alarms were cleared on
each of the channels of span 2, including the data-channel.

  NOTICE [29899]: chan_zap.c:6661 handle_init_event: Alarm cleared on
channel NN
  NOTICE [29898]: chan_zap.c:8460 pri_dchannel: PRI got event: No more alarm
(5) on Primary D-channel of span 2

This is then followed by the first error

  ERROR [29898]: chan_zap.c:8174 zt_pri_error: !! Got S-frame while link
down

I then get constant notices that "Primary D-Channel on span 2 up". This will
be periodically broken up by a repeat of the warnings, notices and errors I
describe above. However, now the problems occur for all of the channels of
both spans.

Machine 1 CLI Notices
====
Machine 1 experiences almost the same behavior on its span. The only
differance I am noticing is that instead of the S-frame error I get the
following notice:

  chan_zap.c:8457 pri_dchannel: PRI got event: HDLC Bad FCS (8) on Primary
D-channel of span 1

Zap Restart Fails
====
On either machine if I attempt a 'zap restart' I receive

  WARNING[30686]: chan_zap.c:903 zt_open: Unable to specify channel 1:
Device or resource busy
  ERROR[30686]: chan_zap.c:7160 mkintf: Unable to open channel 1: Device or
resource busy
here = 0, tmp->channel = 1, channel = 1
  ERROR[30686]: chan_zap.c:10467 build_channels: Unable to register channel
'1-23'
  WARNING[30686]: chan_zap.c:9764 zap_restart: Reload channels from zap
config failed!




I have not attempted to connect two Asterisk boxes though a T1 crossover
before so I am stumped. I have included my zaptel.conf and zapata.conf files
below. I will certainly appreciate any help you can give.

Thanks,
-Brian




Machine1
=========

zaptel.conf
-----------
defaultzone=us
loadzone=us
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24

span=2,0,0,esf,b8zs
bchan=25-47
dchan=48

zapata.conf
-----------
[trunkgroups]
[channels]
group=1
context=fromtelco
signalling=pri_cpe
switchtype=national
channel=>1-23

group=1
context=frommachine2
signalling=pri_net
switchtype=national
channel=>25-47

Machine2
=========

zaptel.conf
-----------
defaultzone=us
loadzone=us
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24

zapata.conf
-----------
[trunkgroups]
[channels]
group=1
context=frommachine1
signalling=pri_cpe
switchtype=national
channel=>1-23
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070920/66f21255/attachment.htm