asterisk users - May 2008 - Calls on E1 TDMoE span are dropped at random

Hi!

We are using a red-fone bridge (connected to an E1 line from the Telekom 
Austria) to provide TDMoE connectivity to our asterisk server (ubuntu 
7.10, asterisk 1.4.10 from ubuntu, libpri 1.4.0-2, zaptel 1.4.9.2 from 
http://support.red-fone.com/downloads/zaptel/). We can establish 
outgoing calls and receive incoming calls from the POTS.
	Sometimes however (no aparent triggers) all established calls suddenly 
drop, the span goes into YELLOW alarm and is restarted. Right after the 
restart we can use the lines as if nothing ever happened. Just sound 
quality seems to be decreased. The server is a real machine Intel Core 
2 with a dedicated 3Com NIC for the red-fone bridge.
	We have been in touch with red-fone support for hours. They suggested a 
loopback cable test (which suceeded, we had a few calls up for about 15 
hours) and then concluded that either the E1 line must have a problem 
or it has to be something with asterisk. Today we had a telco 
technician on-site who told us that the line works as expected and the 
configuration settings of the redfone bridge (framing, encoding, 
timing, etc.) are correct.
	I'm attaching the logfile with span debug information, as well as the 
relevant snippets from our configuration files. Maybe someone could 
help us with a few suggestions, as we are a bit lost at this point.

Cheers,
	Florian

=== zaptel.conf ==dynamic=ethmf,eth4/00:50:C2:65:D2:1A/0,31,2
dynamic=ethmf,eth4/00:50:C2:65:D2:1A/1,31,1
bchan=1-15,17-31
dchan=16
bchan=32-46,48-62
dchan=47
alaw=1-62
loadzone = us
defaultzone=us
=============
=== redfone.conf ==[globals]
fb=192.168.1.254
port=1
server=00:1C:C4:8E:8C:7B

[span1]
framing=ccs
encoding=hdb3
slave
crc4

[span2]
framing=ccs
encoding=hdb3
slave
crc4
=============
=== zapata.conf ==[trunkgroups]

[channels]
pridialplan=dynamic
prilocaldialplan=local
internationalprefix = 00
nationalprefix = 0
localprefix = 03142
usecallerid=yes
hidecallerid=no
hidecalleridname=no
usecallingpres=yes
context=default
group=0
switchtype = euroisdn
signalling = pri_cpe
channel = 1-15,17-31,32-46,48-62
=============

-- 
DI Florian Hackenberger
florian at hackenberger.at
www.hackenberger.at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asterisk_consolelog.txt.zip
Type: application/x-zip
Size: 5491 bytes
Desc: not available
Url :
http://lists.digium.com/pipermail/asterisk-users/attachments/20080509/8ed36b35/attachment.bin

On Fri, May 9, 2008 at 5:32 PM, Florian Hackenberger
<f.hackenberger at chello.at> wrote:
> Hi!
>
> We are using a red-fone bridge (connected to an E1 line from the Telekom
> Austria) to provide TDMoE connectivity to our asterisk server (ubuntu
> 7.10, asterisk 1.4.10 from ubuntu, libpri 1.4.0-2, zaptel 1.4.9.2 from
> http://support.red-fone.com/downloads/zaptel/). We can establish
> outgoing calls and receive incoming calls from the POTS.
>        Sometimes however (no aparent triggers) all established calls
suddenly
> drop, the span goes into YELLOW alarm and is restarted. Right after the
> restart we can use the lines as if nothing ever happened. Just sound
> quality seems to be decreased. The server is a real machine Intel Core
> 2 with a dedicated 3Com NIC for the red-fone bridge.
>        We have been in touch with red-fone support for hours. They
suggested a
> loopback cable test (which suceeded, we had a few calls up for about 15
> hours) and then concluded that either the E1 line must have a problem
> or it has to be something with asterisk. Today we had a telco
> technician on-site who told us that the line works as expected and the
> configuration settings of the redfone bridge (framing, encoding,
> timing, etc.) are correct.
>        I'm attaching the logfile with span debug information, as well
as the
> relevant snippets from our configuration files. Maybe someone could
> help us with a few suggestions, as we are a bit lost at this point.
>
> Cheers,
>        Florian
>
> === zaptel.conf ==> dynamic=ethmf,eth4/00:50:C2:65:D2:1A/0,31,2
> dynamic=ethmf,eth4/00:50:C2:65:D2:1A/1,31,1
> bchan=1-15,17-31
> dchan=16
> bchan=32-46,48-62
> dchan=47
> alaw=1-62
> loadzone = us
> defaultzone=us
> =============>
> === redfone.conf ==> [globals]
> fb=192.168.1.254
> port=1
> server=00:1C:C4:8E:8C:7B
>
> [span1]
> framing=ccs
> encoding=hdb3
> slave
> crc4
>
> [span2]
> framing=ccs
> encoding=hdb3
> slave
> crc4
> =============>
> === zapata.conf ==> [trunkgroups]
>
> [channels]
> pridialplan=dynamic
> prilocaldialplan=local
> internationalprefix = 00
> nationalprefix = 0
> localprefix = 03142
> usecallerid=yes
> hidecallerid=no
> hidecalleridname=no
> usecallingpres=yes
> context=default
> group=0
> switchtype = euroisdn
> signalling = pri_cpe
> channel = 1-15,17-31,32-46,48-62
> =============>
>
> --
> DI Florian Hackenberger
> florian at hackenberger.at
> www.hackenberger.at
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
Try "resetinterval=never"

On Friday 09 May 2008, Steve Totaro wrote:
> Try "resetinterval=never"
Hi! I tried setting resetinterval=60 and established a call. The call 
survived several channel resets successfully, so this setting is 
probably not the problem. Any more ideas?

Cheers,
	Florian

-- 
DI Florian Hackenberger
florian at hackenberger.at
www.hackenberger.at

On Sat, May 10, 2008 at 2:32 AM, Florian Hackenberger
<f.hackenberger at chello.at> wrote:
> On Friday 09 May 2008, Steve Totaro wrote:
>  > Try "resetinterval=never"
>
>  Hi! I tried setting resetinterval=60 and established a call. The call
>  survived several channel resets successfully, so this setting is
>  probably not the problem. Any more ideas?
>
>  Cheers,
>         Florian
>
>  --
You can be shot several times and not die.  I would try
resetinterval=never just to be able to to say "Not the problem" rather
than "Probably not the problem.

PRI debug info would be a great help too.

Thanks,
Steve Totaro