[Asterisk-Users] Asterisk-Users Digest, Vol 22, Issue 1

[Terence Burnard]

Hey,

Thanks for the input Andrew. I did all you suggested but noticed that 
when I did the loopback test, the output *was not* there as you 
mentioned ("I'm set to pri_net, but the other side thinks it is pri_net!").

In fact, the same message as before kept repeating every second or so:

 >> Unnumbered frame:
 >> SAPI: 00  C/R: 0 EA: 0
 >>  TEI: 000        EA: 1
 >>   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode

extended) ]

 >> 0 bytes of data

Sending Set Asynchronous Balanced Mode Extended


This was true on both of our Te411 cards so I'd be surprised if both 
were defective.  The cisco gateway that this Asterisk box is replacing 
is dms100, esf, b8zs so I just set the asterisk box with the same 
configuration.  I spoke to the telco and they said everything looks good 
on their end, and since this a production T1 it doesn't need turning up.

Now that I know support comes with these cards, I might give Digium a 
shout. :)

Terence




Date: Mon, 1 May 2006 07:20:51 -0400
From: Andrew Kohlsmith <akohlsmith-asterisk at benshaw.com>
Subject: Re: [Asterisk-Users] PRI Issue: D-Channel woes
To: asterisk-users at lists.digium.com
Message-ID: <200605010720.51416.akohlsmith-asterisk at benshaw.com>
Content-Type: text/plain;  charset="iso-8859-1"

On Monday 01 May 2006 01:42, Terence Burnard wrote:
> Module                  Size  Used by
> wcusb                  21760  0
> wctdm                  36512  0
> wcfxo                  13408  0
> wcte11xp               24896  0
> wct1xxp                16544  0
> wct4xxp                97664  24
> tor2                   89856  0

First of all, don't load every Asterisk module under the sun.  Load the
modules for the hardware you have, and if you're using something like A at H
which loads everything, edit your /etc/modules.conf to alias the ones 
you do
NOT have to 'off' to prevent them from being loaded.

> # cat /etc/zaptel.conf
> span=1,0,0,esf,b8zs

That should read '1,1,0' but is otherwise great.  You want to 
synchronize to
the telco.

> [channels]
> context=pri_inbound
> switchtype=dms100
> signalling=pri_cpe
> group=1
> channel => 1-23

I generally add
pridialplan=unknown
priindication=outofband
overlapdial=no
resetinterval=86400

to that as well (i.e. before the "channel =>" line) to make things a little
cleaner and clearer.  Only the first line would have any effect on 
mitigating
your problem, though.

> *CLI> pri show span 1
> Primary D-channel: 24
> Status: Provisioned, Down, Active

That's the problem: your D channel is not up.  Either your switchtype is 
wrong
(it is NOT set to the physical switch make/model on the other side, it 
is set
to the signaling system it is emulating), the telco's brought the line 
down,
or the two sides just can't see each other.  Since you're running
green-light, you're seeing each other.

You can do a very simple test by plugging a loopback plug into the span
instead of the PRI.  just take an RJ45 end and two pieces of wire.  plug 
one
wire into pins 1 and 4, and the other into 2 and 5.  Crimp it down and plug
it in.  The light on the back of the card should go green and the system
should be in the exact same state it's in now.  If you change your 
signalling
to pri_net, you should see messages on the Asterisk console complaining 
about
"I'm set to pri_net, but the other side thinks it is pri_net!".

Verify your switchtype...  The Cisco should have a setting and you 
should set
Asterisk in a similar fashion.  Failing that I would try loading the 
wct4xxp
module with the "vpmsupport=0" parameter to disable the voice processing
module just to see if that helps (i.e. possible card issue), and failing 
all
of that, I would contact Digium technical support, as the price of that 
card
included technical assistance and it is this type of problem that is a 
great
use of that support.

-A.