PRI Channel issues

Asterisk Asterisk Support
1

I am having recurring issues with my PRI channels. At least 3 times a day our phones drop the calls they have whle the system clears the channels and restarts.

My hardware is hp DL380 G1 with 2 PIII processors and 4GB Ram connected with a Digium Wildcard TE110 T1/E1 Card.

I am running Asterisk 1.4.18 on CentOS 5.

I only have 5 PRI channels from my Time Warner vendor (am checking on that to see why that was chosen).

My zapata.conf file looks like:

[trunkgroups]

[channels]
context=default
switchtype=national
signalling=fxo_ls
rxwink=300
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
context=incoming
switchtype=national
signalling=pri_cpe
group=1
channel=1-5

the var/log/asterisk/messages file indicates these types of warnings durring the events:

[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Detected alarm on channel 1: Red Alarm
[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Unable to disable echo cancellation on channel 1
[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Detected alarm on channel 2: Red Alarm
[Apr 21 07:37:35] WARNING[2728] chan_zap.c: No D-channels available! Using Primary channel 24 as D-channel anyway!
[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Unable to disable echo cancellation on channel 2
[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Detected alarm on channel 3: Red Alarm
[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Unable to disable echo cancellation on channel 3
[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Detected alarm on channel 4: Red Alarm
[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Unable to disable echo cancellation on channel 4
[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Detected alarm on channel 5: Red Alarm
[Apr 21 07:37:35] WARNING[2729] chan_zap.c: Unable to disable echo cancellation on channel 5
[Apr 21 07:37:38] WARNING[2728] chan_zap.c: No D-channels available! Using Primary channel 24 as D-channel anyway!
[Apr 21 07:37:40] NOTICE[2729] chan_zap.c: Alarm cleared on channel 1
[Apr 21 07:37:40] NOTICE[2729] chan_zap.c: Alarm cleared on channel 2
[Apr 21 07:37:40] NOTICE[2729] chan_zap.c: Alarm cleared on channel 3
[Apr 21 07:37:40] NOTICE[2729] chan_zap.c: Alarm cleared on channel 4
[Apr 21 07:37:40] NOTICE[2729] chan_zap.c: Alarm cleared on channel 5
[Apr 21 07:37:40] NOTICE[2728] chan_zap.c: PRI got event: No more alarm (5) on Primary D-channel of span 1
[Apr 21 07:41:42] WARNING[19439] app_dial.c: Unable to create channel of type ‘SIP’ (cause 3 - No route to destination)

Can anyone point me to the root cause and resolution of this issue? This has become a very large problem for me.

Thanks in advance,

Avfan AKA Randall Rolston

2

First, you really should clean up your zapata.conf as you have some setting defined multiple times. The last one should be the one used but its best to not introduce any confusion.

Second, this is your actual issue, you dont have the D-channel defined and its obviously not finding it on channel 24

After you find out from your vendor what channel the d-channel is your zaptel.conf should look similar to this:

[quote]span=1,1,0,esf,b8zs
bchan=1-23
dchan=24[/quote]

3

thank you. I am a little confused regarding the clean up of the zapata.conf file as I thought I needed two different context(s) first for default and second for incomming but I will take your advice.

Secondly - I don’t seem to have a zaptel.conf file located at /etc/asterisk - this could be the issue. Could this be a result of version 1.4 or is this because I have not compiled the modules correctly?

Thanks for you assistance

4

after installation my zaptel.conf file is under /etc/sysconfig/zaptel is there any reason it is there and not in my Asterisk folder?

Thanks to anyone who can point this out

5

Did you install * (and zaptel) from sources or from a binary package ? Sounds to me the latter…

Cheers.

Marco Bruni

6

latter is correct as the system was up and running for 4 months before this problem arose

7

looks like my problems have been solved through my PRI service provider - the problem was on their end not supplying a quality d channel. I will update this string if the problem shows itself again but since the service change this morning - all has been well