All circuits are busy message, but they really aren't...

[PImoose]

Out of the blue are system has started acting up. We have a 450, and we are getting all circuits are busy, even though we have a Full T1 and only a single call or two going out. For example:

[Mar 30 13:02:54] WARNING[20221] app_dial.c: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)
[Mar 30 13:02:54] VERBOSE[20221] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)
[Mar 30 13:02:54] VERBOSE[20221] pbx.c: -- Executing [s@macro-dialout-trunk:22] NoOp("SIP/221-0000000b", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 34") in new stack

Restart the system, things works great for a little while, then it starts this game again. Right now that process is repeatable.

How can I tell what is actually going on? The PRI card is still lit up green.

 

[ucxguy]

You could enable PRI debugging to see the setup message and the reply from the CO in the log. The Asterisk CLI (PBX - Tools) command to do that is

pri set debug on span 1​

Once enabled, make a call or two - then turn it off with the command

pri set debug off span 1​

If you have more than one span, you can enable debugging on all of them.

Finally, you can take a look at the Asterisk full log. There should be a SETUP message for your call, there could be CALL PROCEEDING after that and eventually a DISCONNECT message. The Cause in this DISCONNECT message should indicate why the call was not accepted by the CO.

 

[PImoose]

I have vehicle issues today so I am trying to work on them and help my co worker remotely.

After enabling debug I am seeing this alot:

[Mar 31 08:59:03] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 TEI=0 Sending SABME
[Mar 31 08:59:04] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (G): T200 expired N200 times sending SABME in state 5(Awaiting establishment)
[Mar 31 08:59:04] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 Changing from state 5(Awaiting establishment) to 4(TEI assigned)

 

[PImoose]

Disregard the last one, I think the router may have still been coming up that servers the PRI.

 

[PImoose]

What is odd is so far we can keep it up if we keep a call open from outside in. If we don't have any calls, within 10 minutes we will get all circuits are busy.

 

[theislandtech]

How long has this PRI been in service? Longer = solid configuration.
Any recent changes on the pbx or telco side?
Is the card using its internal timing source or external?

 

[PImoose]

PRI has been in service since we moved to this location, ~7yrs now.

No changes.

Not sure on the card timing - or what that is.

We had one of the recommended vendors set this up a couple years ago and all we have done is add/remove DID's & extensions. Pretty basic setup.

 

[PImoose]

Still watching in Debug on the PRI, some odd balls popped up today:

[Apr 1 10:34:22] NOTICE[3345] chan_dahdi.c: PRI got event: HDLC Abort (6) on D-channel of span 1
[Apr 1 10:34:24] NOTICE[3345] chan_dahdi.c: PRI got event: HDLC Abort (6) on D-channel of span 1
[Apr 1 10:34:46] NOTICE[3345] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1
[Apr 1 10:34:46] NOTICE[3345] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1

Didn't see any of the above yesterday just today.

 

[theislandtech]

The Pri has been in service for 7 years but the UCX 450 has been using the PRI circuit for only a couple of years.

What release, 3.0, 4.0, or 4.5? Any updates done to the UCX 450?

Insure that DAHDI and libpri are at the latest release.

In asterisk/dahdi-channels.conf has "signalling = pri_cpe or pri_net"?

That tells the card who is the master clock source.

There can only be one pri_cpe who provides the synchronizing clock. One end is pri_net and the other is pri_cpe. You're the network end slaved to the master clock from the service provider. You should have your spans set to pri_net.

Last resort - reseat the PRI card and the riser card in the UCX 450

 

[PImoose]

No downtime from 4/1 until this morning (looks like it died over the weekend sometime), I started getting emails from people. Nothing changed between those days...

[Apr 6 04:03:06] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (G): T200 expired N200 times sending SABME in state 5(Awaiting establishment)
[Apr 6 04:03:06] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 Changing from state 5(Awaiting establishment) to 4(TEI assigned)
[Apr 6 04:03:06] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 TEI=0 DL event: Q931_DL_EVENT_DL_RELEASE_IND(3)
[Apr 6 04:03:07] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 SAPI/TEI=0/0 Kick starting link
[Apr 6 04:03:07] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 TEI=0 Sending SABME
[Apr 6 04:03:07] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 Changing from state 4(TEI assigned) to 5(Awaiting establishment)
[Apr 6 04:03:08] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 TEI=0 Sending SABME
[Apr 6 04:03:09] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 TEI=0 Sending SABME
[Apr 6 04:03:10] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 TEI=0 Sending SABME
[Apr 6 04:03:11] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (G): T200 expired N200 times sending SABME in state 5(Awaiting establishment)
[Apr 6 04:03:11] VERBOSE[3345] chan_dahdi.c: PRI Span: 1 Changing from state 5(Awaiting establishment) to 4(TEI assigned)


Not sure where versionis listed for the UCx - Under Licenses it has - Product Code: UCx450-100-R3

-signalling = pri_cpe

 

[PImoose]

Changing PRI signaling to pri_net, caused it to drop with the error saying we are both trying to be the network.

 

[PImoose]

Here is a screen shot at boot too, I don't remember this so I wanted to check if the message on the driver is normal.

 

[telcodog]

It sounds like your clock is drifting or in free run. You need to get your carrier to have a good look at it.

When you reset the PRI by restarting the DAHDI service or rebooting the system or whatever, the PRI syncs up but immediately starts to drift and eventually loses synchronization with the "CO". When this happens, all calls in progress will drop and you will not be able to make outbound calls until you reset the PRI again and the cycle keeps repeating.

Whoever is supplying you with your PRI needs to have a serious look at your D channel setup.