I think you should request to get it fixed via free digium tech support
Martin
On Fri, May 22, 2009 at 12:51 PM, Russell Brown russ...@lls.lls.com wrote:
I've having problems with a BT 2 span ISDN-30/Digium TE205P asterisk
setup with outgoing calls not completing and requiring an Asterisk reset
to 'unstick' span 1.
Sorry this is a bit long but I'm completely out of my depth :-(
This system has been in use for some while and I recently upgraded it to
asterisk 1.4.24, zaptel 1.4.11 and libpri 1.4.9. I didn't change
/etc/zaptel.conf or zapata.conf.
The upgrade fixed the problems with calls getting stuck in voicemail and
a few other issues but the inability to make outgoing calls that started
a couple of days after the upgrade is a bit of a bigger problem!
Initially it looked like a BT fault and indeed BT agreed that there was
a problem with a 'card in the exchange'. However they say that they've
changed that and the problem's still happening :-(
It's not consistently failing. On Tuesday it was fine. On Wednesday it
failed 7 times, Thursday 4 and today 11. This could be down to usage
though (more calls being made). Each time span 1 won't complete
outgoing calls we have to restart asterisk and then it comes right back
for a while. Span 2 (which only has 8 channels enabled) seems to
continue working.
BT have now installed an ISDN monitor and their engineer is saying that
there are problems with Asterisk generating malformed packets and out
of sequence packets.
Here's what the BT engineer said including examples from his ISDN
monitor of the failures (some asterisk pri debug logs follow that).
Can anyone suggest a course of action here? While I can happily
construct dialplans and stuff, this level of ISDN is completely beyond
my experience.
Here's the BT chappies report:
I've had a good look at the trace containing yesterday afternoon's failures.
There seem to be 2 issues that I think are closely related.
Malformed Packets
Intermittently packets sent by the PBX are malformed. My analyser shows them
as CRC-Errors, but, in fact, when you study the data in hex you see that,
quite simply, some information is missing. Like my analyser, the exchange
doesn't understand these malformed packets and ignores them which means that
the next packet sent by the PBX has an incorrect sequence number and is
rejected by the exchange. The exchange then asks for the packet with the
correct sequence number to be resent.
This is happening intermittently throughout the trace; when it happens at
quieter periods the correct sequence is quickly recovered and call
processing carries on. When it happens at busier periods, or when there are
two or more incorrect packets close together, things quickly start to get
out of control with the sequence between exchange and PBX (that has to be
followed) getting further and further apart. Eventually we start to see the
layer 3 call reset messages that we were looking at yesterday morning, but
even these can't recover the situation because the sequence is so far out.
The only cure (as we know) is a complete PBX or exchange reset which
re-establishes the packet sequence and allows calls to be passed once again.
Malformed Packet
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
12:18:30/850.8 1- RS D1 BOP FRAME flg=3D999 =
[0043]
D2 Q921 (S:00 T:000 C/R:1) I P:0 NR:103 NS:058 =
[0039]
D3 Q931 Pro:08 Ref:(O,00 ca) SETUP =20
IE:(0/a1) len:0 Sending complete
IE:(0/04) len:3 Bearer capability
Oct 3 : -00- Coding =3D ITU-T
---0 Capability =3D Speech
Oct 4 : -00- Transfer mode =3D Circuit
---1 Transfer rate =3D 64 kbits/s
Oct 5 : -0100011 L1 protocol =3D G711 A-law
IE:(0/18) len:3 Channel identification
Oct 3 : -0-- Int id =3D implicit
--1- Interface =3D Primary
0--- Preferred/Exclusive =3D =
Preferred
--01 Channel select =3D Indication =
follows
Oct 32: -00- Coding =3D ITU-T
---0 Number/Map =3D Number
0011 Type =3D B-channel
Oct 33: ---00010 Channel number =3D 2
IE:(0/6c) len:12 Calling party number
Oct 3 : -010 Type of number =3D National
0001 Numbering plan=3D ISDN/tel. =
(E164/E163)
Oct 3a: -00- Presentation =3D Allowed
--11 Screening =3D Network =
provided
