New ISDN PRI – No Inbound or Outbound Calls

Asterisk Asterisk Support
1

I have a customer in the UK with an OpenVox D110P card and a new ISDN 30 E1 that cannot make inbound or outbound calls. The server is using Asterisk 1.4.21.2-2, Zaptel 1.4.11-6, and Libpri 1.4.7. The zaptel.conf is configured as follows:

span=1,1,0,ccs,hdb3,crc4 bchan=1-15,17-31 loadzone = uk defaultzone = uk
zapata.conf:

[code][channels]

signalling=pri_cpe
switchtype=euroisdn
overlapdial=yes
pridialplan=unknown
prilocaldialplan=unknown
group=0
context=from-zaptel
channel=>1-15,17-31
[/code]
Zttool shows that there aren’t any alarms, ztcfg -vv shows all 30 channels as does zap show channels. Zap show status shows:

[code]Description Alarms IRQ bpviol CRC4

Digium Wildcard TE110P T1/E1 Card 0 OK 0 0 0[/code]
and pri show span 1 shows:

Primary D-channel: 16 Status: Provisioned, Up, Active Switchtype: EuroISDN Type: CPE Window Length: 0/7 Sentrej: 0 SolicitFbit: 0 Retrans: 0 Busy: 0 Overlap Dial: -1 T200 Timer: 1000 T203 Timer: 10000 T305 Timer: 30000 T308 Timer: 4000 T309 Timer: -1 T313 Timer: 4000 N200 Counter: 3
Everything looks fine configuration wise but when making an outbound call you get all circuits are busy (CLI shows Asterisk trying to Dial(Zap/g0)) and when you make an inbound call nothing at all appears on the CLI. An engineer from the phone company (BT) has visited the site and done a line check using an ISDN test device and calls can be made/received without any issues. With pri debug enabled on span 1 the CLI shows the D Channel going up and down:

-- Timeout occured, restarting PRI q921.c:437 t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED Sending Set Asynchronous Balanced Mode Extended q921.c:211 q921_send_sabme: q921_state now is Q921_AWAITING_ESTABLISH == Primary D-Channel on span 1 down Sending Set Asynchronous Balanced Mode Extended Sending Set Asynchronous Balanced Mode Extended Sending Set Asynchronous Balanced Mode Extended -- Got UA from network peer Link up. q921.c:782 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED q921.c:733 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED == Primary D-Channel on span 1 up -- Got SABME from network peer. Sending Unnumbered Acknowledgement q921.c:782 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED q921.c:733 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED -- Got SABME from network peer. Sending Unnumbered Acknowledgement q921.c:782 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED q921.c:733 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED
This is the only pri related output received when making/receiving call. With pri intense debug on the output shows:

[code]< Supervisory frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
Handling message for SAPI/TEI=0/0
– ACKing all packets from 0 to (but not including) 0
– Since there was nothing left, stopping T200 counter
– Stopping T203 counter since we got an ACK
– Nothing left, starting T203 counter
– Unsolicited RR with P/F bit, responding
Sending Receiver Ready (0)

[ 02 01 01 01 ]

Supervisory frame:
SAPI: 00 C/R: 1 EA: 0
TEI: 000 EA: 1
Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
N(R): 000 P/F: 1
0 bytes of data
– Restarting T203 counter
– Restarting T203 counter

< [ 02 01 7f ]

< Unnumbered frame:
< SAPI: 00 C/R: 1 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
Handling message for SAPI/TEI=0/0
– Got SABME from network peer.
Sending Unnumbered Acknowledgement

[ 02 01 73 ]

Unnumbered frame:
SAPI: 00 C/R: 1 EA: 0
TEI: 000 EA: 1
M3: 3 P/F: 1 M2: 0 11: 3 [ UA (unnumbered acknowledgement) ]
0 bytes of data
– Restarting T203 counter
q921.c:782 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
q921.c:733 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED
– Restarting T203 counter

< [ 02 01 7f ]

< Unnumbered frame:
< SAPI: 00 C/R: 1 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
Handling message for SAPI/TEI=0/0
– Got SABME from network peer.
Sending Unnumbered Acknowledgement
[/code]
I’m not an ISDN signalling expert, but from what I understand of the output above the server is receiving supervisory receiver ready frames, and is replying with unumeered UA and SABME frames but the D Channel is still going up and down. I have googled the issue described above and have found a few users that have had the same issue, but no one has posted a solution (except one that just tried a different Asterisk/Libpri/Zaptel combination so the issue could have been anything). I have tried the configuration with/without CRC4 but this has not made any difference. The card has its own IRQ and the average zttest score is about 99.99. If anyone has any ideas what the issue could be then I would be grateful for your help, thanks.

2

Hi

Does the card work when you use your ISDN simulator ? and also does the ISDN30 work when tested with the simulator.

Also who is the ISDN from ? and is it type 110 ?

Ian

3

Hi Ian,

Thank you for your reply. The ISDN line provider is BT and the line is a new ISDN30e so supports EuroISDN signalling.

A BT engineer tested the line earlier in the week using a hand held tester to confirm that the line was OK, but I haven’t got an ISDN simulator to test the Asterisk card and neither has the reseller (I am just the provider of the card trying to provide troubleshooting assistance). I’m not sure what other tests can be done, we could try a loopback test but I beleive that just transmits a bit pattern and checks that the same pattern is received.

From what I can understand from the debug output, the server is sending/receiving UI frames/acknowledgments, but no I frames are sent/received for Q.931 setup so the server times out and the negotiation starts again.

I don’t think its an issue with the card as there are no alarms and frames are being sent/received, but I can’t see any problems with the configuration or Zaptel/Asterisk either.

Richard

4

Hi

Ok its BT so it will be type 110 (Both 85 an 110 are euroISN varients that are found in the UK)

Is it a new link or an existing one. If its new has it had the datafill completed. and when you talk to the NOC and you look the card via zttool can they see it ?

does zttool say the card is ok and no alarms ? and what lights are on the card. and finally the card is set to e1 and not t1 ( I assume its a jumper like the digium)

But to be honest if you/reseller dont have the correct test gear then the NOC arnt going to be too helpful they will expect you/reseller to have a simulator.

I suppose the reseller could buy another card and build a server in net mode.

Personally I would wish them luck as they seem to be ill-equipped to do what they are doing.

Ian

5

Hi Ian,

When you mention ISDN type 110, I assume that you are referring to ISDN lines conforming to ITU-T recommendation V.110/I.463? However, what does the 85 type refer to? It isn’t an ITU-T V series recommendation and I can’t find any references to it in any BT SIN. I’ve tried googling but I can only find two references to it, and both are old Asterisk posts.

The line is a new provide and has never been used. I haven’t spoken to them myself, but the OpenReach helpdesk have said that there is a fault preventing calls being sent/received when connected to the server, but they are unable to say what the fault is. An OpenReach engineer visited the site and used a handheld ISDN tester to make test calls and the line worked OK. The light on the card is green, Zttool shows OK with no alarms, as does zap show status (shown above). The jumper on the card is set to E1 (default), and as Q.921/LAPD frames are being sent/received I don’t think there is an issue with the D channel configuration.

The customer may not be fully equipped to troubleshoot ISDN L2/L3 issues, but I don’t agree that the customer is ill-equipped to install an ISDN 30 card in a server just because they haven’t got an ISDN simulator. That’s analogous to saying that a home user is not equipped to install a router/switch if they haven’t got a network sniffer/analyser.

I do agree however that in this instance an ISDN tester/simulator would help determine what the issue is. I also agree that an ISDN tester/simulator is an essential tool for companies regularly commissioning, installing, maintaining ISDN equipment. However, for a company involved in a one-off ISDN install that normally deploys VoIP only solutions, the cost of a simulator/tester is likely to have a significant impact on profit margins.

As L1/L2 appear to be working OK, I don’t think it’s an issue with the card, I think it is most likely an issue with Zaptel/Libpri. However, without any ISDN cause codes or alarms its difficult to know what the issue could be.

Richard

6

Hi

Type 85 is a version of ISDN that can/was supplied by Telewest, Cable and Wireless and NTL, The reason you may not find many mentions of it is that that all ISDN equipment will work happily with it, except Digium/Zapata based cards.

as to

[quote]The customer may not be fully equipped to troubleshoot ISDN L2/L3 issues, but I don’t agree that the customer is ill-equipped to install an ISDN 30 card in a server just because they haven’t got an ISDN simulator. That’s analogous to saying that a home user is not equipped to install a router/switch if they haven’t got a network sniffer/analyser.
[/quote]

Not according to BT it isnt , It is expected for companies that provision ISDN30 lines to be equiped to test them. I would expect any company offering services installing them to also be so equiped, Lets hope BT don’t send the customer the Bill for the engineer coming to site.

The company should have a lab that is equiped with a method of simulating all types of services it offers. For example we have a Mitel SX2000 and Aculab groomer to simulate ISDN30e and ISDN2 and analog trunks so when a server is taken to site we know it works. This is in addition to PRI and BRI simulators that are taken to site on day of install.

That aside below is a known working config as im sure its a typo but in the zaptel.conf no d channel is defined

[code]=========zapata-channels.conf=========

; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;
; Span 1: WCT1/0 "Digium Wildcard TE110P T1/E1 Card 0"
switchtype=euroisdn
usecallerid=yes
hidecallerid=no
restrictcid=no
usecallingpres=yes
echotraining=yes
echocancelwhenbridged=yes
echocancel=yes
musiconhold=default
rxgain=0.0
txgain=0.0
signalling=pri_cpe
overlapdial=yes
pridialplan=unknown
prilocaldialplan=unknown
priindication=outofband
resetinterval = never
channel => 1-10 ; Using 10 channels otherwise 1-15,17-31
[/code]

[code]# Span 1: WCT1/0 "Digium Wildcard TE110P T1/E1 Card 0"
span=1,1,0,ccs,hdb3,crc4
bchan=1-15
dchan=16
bchan=17-31

Global data

loadzone=uk
defaultzone=uk
[/code]

Ian
www.cyber-cottage.co.uk

7

Hi Ian,

Thanks for your response, I have tried the zapata/zaptel settings suggested along with a number of other permutations but nothing has made any difference. I have also upgraded Zaptel/Asterisk, reinstalled Libpri and even upgraded the Kernel but each time the result is the same. I have done the upgrades via yum/rpm so haven’t built from source, but I don’t think this will make any difference. There are no IRQ/timing issues and we have tried two different cards so its not a faulty card.

Openreach have been out and tested the line using a hand held tester and could successfully make calls. When the Asterisk server is connected to the line the NOC (3rd party provider, not BT) says that there is a fault with the CPE, but are unable to provide any more information.

Several times yesterday we successfully made an inbound call. However, the far can hear very bad crackling and noise in the background like fax/modem noise and the call always hangs up after about 45 secs. Today inbound calls aren’t working at all and you just get “Sorrry there is a faultâ€

8

Hi

I would build from source if I were you. That way you will know its correct.

Sounds correct, I wouldn’t expect any more info than that.

what does lsmod say and also what does dmesg say.

a (TE/DE)110 is old now superseded by the 120 so may be having a firmware hickup, The newer TE110 did when they updated the chipset and you tried to use them on older versions of Zaptel.

Ian
(BTW I have sent you a PM)

9

Just going through my old posts and thought I would provide information on the solution for anyone reading this thread. The issue turned out to be an issue with the specific server build, which was an AsterCC build. We took the ISDN card out of the AsterCC server and put it in a Trixbox 2.6 server (built using exactly the same Asterisk/Zaptel versions) and it installed and worked correctly first time. In the end the customer set up a trunk between the two servers and just left them that way. It was too much hassle to find out what the issue with the AsterCC build was, and the two box solution had its own advantages anyway as it provided functional/resource separation, which helped from a scaling/operational perspective.