We are getting the message "All circuits are busy, error 90" sometimes when we call out. We have a full PRI with 23 available voice channels, and this is happening when we only have 7-9 concurrent calls. I've already called the telco to verify the PRI is in good order. They don't see any issues, but I opened a ticket for them to monitor it anyways.

Our Switchvox is the AA350 with a Wildcard TE122 T1 card. The System Status page is not showing any alarm codes on any of the channels.

we had a similar issue for a about an hour at one of our sites. i rebooted the server and we haven't experienced the problem since. i opened a ticket with switchvox and the looked at my box but could not find anything out of the ordinary so they blamed it on the telco but the telco pointed their finger right back at switchvox. all the finger pointing is really frustrating but i don't really think there is much to do about it.

Wouldn't it be nice if there was a list of these "error codes' to tell you what they actually mean??? Like ISDN Cause Codes that have been around for decades.

I've asked but have been told a list doesn't exist. Which means that these numbers are random which I find extremely hard to believe. So if anyone has any idea what they mean then I, and I'm sure everyone else, would appreciate knowing so some fault finding can actually be done.

from what i know the number codes are not random. i've spoken to a couple of support techs about some of the codes so i know there is a list of them somewhere. it's just that they do not release them for public consumption.

I knew they're not random. But the refusal from certain parties to supply that information makes life incredibly difficult. So instead of fault finding and fixing an issue in 5mins it can take days because you need to run to someone else to ask for help So much for the open source community helping everyone out and providing information to share. Hopefully the list will make an appearance soon.

Error 90 is not an ISDN cause code. It actually means: "channel group call failed". I know, not terribly specific. We just use it to indicate that Switchvox is indeed generating the error message and not, for example, your telco. If you want more information about the reason the call failed, go look in the Diagnostics --> Call Logs section and mouse-over the call details. The ISDN call code should be in there if we're getting one from your provider.

Also, you really need to call your T1 provider and see if they can tell you why a call failed at that time. Don't settle with "well it works now" answers from them. Ask them if they see any alarms on the logs at the given time, or if the D-channel was up at the time the call failed. They'll probably come back with, "well we see timing slips on the card," and try to blame everything on that. Don't listen to that excuse, timing slips do not make calls fail. Keep pestering until they admit that they weren't logging anything on your T1, and they'll turn on logging. Then when the failure happens again, they'll be able to tell you what they see on their end.

Well....advanced error logs tell you everything...almost. I deal with T1 and E1 all the time, error 85, 90, etc....I basically ignore those and go to the error log and advanced error log. For those of you in love with switchvox will have to deal with those little missing things, but if you can't figure out what's wrong with the error logs, something major is happening.

Telcos WILL ALWAYS blame it on anything else but their stuff. It's the default behavior, worldwide, trust me.

In my case, I have a small asterisk home made appliance, with an E1/T1 card. When the problems get tough, I remove switchvox, plug my asterisk and use it as debugging, troubleshooting unit. Once I identified the problem, plug back the switchvox. off course, this is for us resellers, were we face these issues all the time.

I would dissuade people from paying too much attention to the advanced error logs. Our support staff spends an inordinate amount of time comforting users who have stumbled onto it who are now convinced that some line-item they've found means some catastrophic failure. Meanwhile the developers never look at it, because it does not contain useful information. It's only there because we don't want to hide the raw Asterisk logs on the system.

bmdhacks wrote:I would dissuade people from paying too much attention to the advanced error logs. Our support staff spends an inordinate amount of time comforting users who have stumbled onto it who are now convinced that some line-item they've found means some catastrophic failure. Meanwhile the developers never look at it, because it does not contain useful information. It's only there because we don't want to hide the raw Asterisk logs on the system.

I think there needs to be more technical documentation about what settings do, error messages, etc. Then support could spend less time comforting users as the users could read the documentation and realize that x error is benign caused by y and is benign.

As for the settings. I think the majority of things are covered in the built in documentation but many settings either have no additional information or the information provided is very generic. Service bulletins, know issues, known fixes, etc. would be very helpful as well.

The Switchvox user documentation is great but there is pretty much no real technical documentation available publicly.

Well after going round and round with both Switchvox and the Telco both saying their hardware/software tests come up clean and there are no issues with the PRI circuit and T1 card etc, it looks like we finally got to the root of this problem.

Our Telco provider, XO Comm., by default setup our PRI circuit with Ascending Incoming Call Sequence where an incoming call will start at channel 1 and work its way down until a free channel is found. It turns out that Asterisk is hardcoded to use Ascending Outbound Call Sequence, which starts at channel 1, and can't be changed.

So what is happening is an incoming call takes a channel that Asterisk is trying to acquire for an outbound call, but since the channel is already taken, Asterisk reports back that all of the circuits are busy. Since Asterisk can't be changed to use Descending Outbound Call Sequence, the Telco must change it on their end to use Descending Incoming Call Sequence to avoid the collisions.

Our circuit is going to be reconfigured tonight, so I will have to report back after a week or so to truly find out if it works, but I am pretty confident. Hope this information helps anyone else experiencing this problem.

That makes sense. Just another one of those hidden little technical details that only support knows. Your issue sounds like it could be called that. I had them realize that on my PRI when I was getting complete resets but they fixed it by applying a patch so I never did get the PRI switched around.

Following on from bmdhack's statement that it means "channel group call failed", below are some specifics for the codes you might encounter...

85 = SIP
86 = IAX
90 = Analogue/PRI/BRI

So, if you hear "error 86" it means that a call failed on an IAX trunk. Then you need to do more digging in Call Log and/or Error Logs to find the issue. In the case of "error 90" and you have ISDN trunks then the Call Log will show you ISDN Cause Codes for the reason of the failure.the

The error code itself doesn't tell you the reason for the call failure but it points you in the right direction.

While I agree with the argument of changing Ascending to Descending to resolve the issue, I'll throw a devil's advocate argument into the mix-

Since Switchvox defaults to Ascending search order on the PRI, and Telco also defaults to sending calls in Ascending order, wouldn't one think that the D-Channel signalling on the PRI circuit should prevent the 'glare' (Telco and CPE trying to choose the same channel)? The DCH negotiation, upon contention for the same channel, SHOULD result in one end declaring 'channel 1 is in use...offering channel 2' for instance?

I know, I know, I've been a reseller for a long time, and I KNOW setting one end for Descending resolves the issue, but I was queried a time or two before about the 'intelligent' DCH negotiation, and thought I'd throw it out to the group...