Terence Burnard
2006-May-01 13:45 UTC
[Asterisk-Users] Asterisk-Users Digest, Vol 22, Issue 1
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@benshaw.com> Subject: Re: [Asterisk-Users] PRI Issue: D-Channel woes To: asterisk-users@lists.digium.com Message-ID: <200605010720.51416.akohlsmith-asterisk@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 0First 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@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,b8zsThat 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-23I 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, ActiveThat'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.