Elastix ZAP calls

dan fl

Joined
Oct 13, 2008
Messages
11
Likes
0
Points
0
#1
Hi everyone,

I've just installed the latest stable Elastix software on an Intel Core Duo, 2GB RAM machine with a Digium TDM800P (4 FXO + 4 FXS) card. The software was installed smoothly, the card was detected correctly, no problems at all.
Provisioning my Linksys SPA922 was also NOT a problem. I've installed 2 PSTN analog trunks and an analog extension. The problems are when I try to call or make calls to/from analog extension. Also, any outbound call through FXO's ends with "all circuits are busy now".
I've read all posts in this forum, unembedded FreePBX docs, "Elastix without Tears", etc ... NO RESULT.
In my opinion I must use the system just by using the web interface, not by some super-guru-.conf editing procedures!
Am I wrong? Any ideeas? Any other similar experiences?
Thanks in advance,

Dan
 

Buks

Joined
Oct 15, 2008
Messages
18
Likes
0
Points
0
#2
I have a very similar machine running Elastix 1.3. It worked perfectly until I did a yum - y update from Elstix 1.2 to 1.3. Now I get an "all circuits are busy" message on all outbound trunks a few times per day. I have found that unplugging and replugging the PSTN lines into the TDM400 card fixes this until the next time. For info: This very same machine worked flawlessly for months on trixbox... I must admit that this problem is discouraging me from using Elastix in the future as I have 2 other production machines with FXO hangup detection problems in Elastix. One of them used to work well with trixbox. Obviously there is a major bug in the zaptel setup that ships with Elastix 1.2 / 1.3???
 

kalderista

Joined
Oct 21, 2008
Messages
179
Likes
0
Points
0
#3
Yeah!

I'm suffering the same problem... Anyway, Buks, why did you change your Tribox software? Did you have a wrong sperience with your Tribox? Do yoy find Elastix better. I'm interested in your opinion.

Kalderista
 

Buks

Joined
Oct 15, 2008
Messages
18
Likes
0
Points
0
#4
Perhaps I am walking the same route with Elastix as I have with trixbox. Two years ago Trixbox 1 was FULL of bugs and caused so many problems that I reverted back to Asterisk@Home. After some time I tried it again and recently I found it to be stable and in my opinion a good product. It has good features and Kerry (and others) give good support and are always online. (I think I just saw that I was the only registered user online when I logged in...)

A local voip equipment supllier suggested I use Elastix because of its claim to be the most "Reliable PBX..." I really cannot agree when I read the Elastix forum. There are numerous people with pstn outbound & inbound problems, especially after a yum update to version 1.3x. What bugs me is the silence from the developers about this matter. It is evident that there is a problem in the code. They have changed the zapata - files and have messed something.
 

Bob

Joined
Nov 4, 2007
Messages
2,400
Likes
1
Points
36
#5
Elastix is still, IMHO, one of the best distributions and other than an issue in one build 3-4 months ago, the releases have been very good.

What you have to remember is that the product is constantly under development. The only releases that you can trust are the stable releases. These, to a reasonable degree, have undergone a beta cycle, which normally weeds out any MAJOR faults before they are released as Stable.

Yum updates, especially wholesale YUM updates, install a large number of updates to products that make up your Linux system, and whilst everyone of them usually goes through some sort of software development cycle, they to can have faults or issues. Especially due to the high number of files, the probability is that this will happen at some time.

You are probably thinking, how do I upgrade if I don't perform a YUM update. If your system is stable than don't update (unless there is a major security flaw). If you want to update then like any business that runs IT systems, plan your upgrades, provide a rollback, run a test/development box and test the system first before doing upgrades. If you want to upgrade, install the latest stable release fresh and rebuild your system. If you have a test/development box, you would have created a config that you can backup and restore on the system reducing your downtime.

I am not saying do not do YUM updates, but they should be treated no differently to an SVN release mechanism. They are a snapshot at a particular time. Likewise, if you enjoy doing YUM updates, then learn more of what the Asterisk engine is about and how all the parts come together. I spent a year of rolling my own Asterisk systems before I looked at Asterisk@home, and Trixbox, and then finally Elastix. When a YUM update goes bad, then I go back to basics. Even taking the time to learn how to recompile Zaptel is a good place to start (but do it on a test box as you will learn what breaks, what Elastix changes have been made etc etc).

Now having said all that, this issue you refer to relating to the ZAP issue, is not unique to Elastix. It also has been reported in the Trixbox and PIAF camps as well, relating to certain analog cards, and in particular, it appears to be related to the 1.4.12 release of the Zaptel drivers. Everyone is reporting the same resolution which is to revert back to the 1.4.11 release. Now what that means is either:-

1) Asterisk has released a buggy zaptel 1.4.11 (note that most of the distributions patch this file so it might not be a Asterisk induced bug)

or

2) All the Distribution camps have copied the same customisation of the Zaptel from one another reproducing the same fault.

One other thing, the developers may be quiet as they may not have an answer, especially as it is only affecting a small number of cards, cards that the developers may not have on hand. Or they are working on releasing a later version of the Zaptel driver, on the premise that this will fix it. The Elastix developers do not necessarily know the zaptel driver backwards, only the parts or patches that they apply, so they may not understand what the issue is at the moment.

The one system that I had with the issue, I used the 1.4.12.1 zaptel library (compiled it), and it corrected the issue, so my thoughts are that it is a buggy release from Asterisk.

Anyhow, stick with Elastix, it will pay you back in the long run.

Regards

Bob
 

Buks

Joined
Oct 15, 2008
Messages
18
Likes
0
Points
0
#6
Thanks for the reply, Bob.

These encouraging words are what I wanted to hear from somebody at Elastix. It was strange to me how many unanswered posts I see in the forums...

I have also used plain Asterisk, A@H as well as trixbox and it must be a coincidence that these zaptel problems come at the time I decided to change to & stick to one brand (Elastix). Having production boxes in the field with an unstable platform is not my idea of having fun. Unfortunately, when lightning destroyed a trixbox system 330km from my office, I changed over to Elastix (with zaptel problem) when I repaired it. The same hardware (without modules destroyed by lightning) worked well in trixbox 2.4

Per your advice I shall stick with Elastix as I like it (without the zaptel problems) and as you have stated reverting these boxes to trixbox with similar zaptel might just be problematic as well..

Regards!
 

Bob

Joined
Nov 4, 2007
Messages
2,400
Likes
1
Points
36
#7
Thanks for your comments as well.

Thank you for reading the response in the right way. I wasn't having a go at anyone, just stating some facts, and thoughts which can sometimes be forgotten in times of frustration.

Regards

Bob
 

Bob

Joined
Nov 4, 2007
Messages
2,400
Likes
1
Points
36
#8

dan fl

Joined
Oct 13, 2008
Messages
11
Likes
0
Points
0
#9
So, the basic ideea to this problem is (besides sticking with the Elastix :D ) to compile the latest Zaptel driver, which is (I think?) 1.4.13.
Any HOWTO's in these area on the web?
 

gleats

Joined
Nov 7, 2007
Messages
10
Likes
0
Points
0
#10
I too had a heap of trouble with an Elastix install using TDM400P hardware when I updated to Elastix 1.3
I was unable to recieve or make calls via the zap trunks. It turns out that asterisk 1.4.22, which is upgraded when you do yum -y update, is NOT compatible with the older Digium cards like TDM400P. Asterisk 1.4.22 works fine with the newer TDM410P cards.

How I overcome this was to reinstall elastix but prior to the yum update, I edited the yum.conf file to exclude asterisk and zaptel by adding "exclude=asterisk* zaptel*" without quotation marks to the /etc/yum.conf file. I don't know how long this method will be appropriate as I expect sooner or later that asterisk 1.4.22 will be necessary and may break Elastix/FreePBX.

I didn't perform a downgrade of asterisk 1.4.22 back to 1.4.21.2 that came with Elastix 1.2, maybe someone here can provide the process of rolling back the asterisk version.
 

Buks

Joined
Oct 15, 2008
Messages
18
Likes
0
Points
0
#11
Thanks for this info!

Although most of my installations have newer hardware, I still have at least 3 or four boxes with TDM400 cards in it.

If your facts are correct, it means that there either is a bug in this version of Asterisk or, even worse - Digium is not really supporting older cards anymore...

Now I am wondering how I can revert back to an older Asterisk without problems?
 

lee3111

Joined
Oct 25, 2008
Messages
3
Likes
0
Points
0
#12
I have a similar machine running Elastix 1.3.x. It was working fine until I did a "yum".
I did found some strange thing on our FOP. All my co lines are busy with none log in extensions.
I thought it was Elastix's problems until I received phone call today and that person told me that we are calling her and asked her "Credit Card Number with code number". I checked the log and they called almost 1000 calls using our phone line one day. I deleted all extensions and create new extensions and now the system running well. I don't know how they are using our system.
If you are having problem with "All circuits are busy", please check FOP any externsions and trunk lines are all using.
 

Buks

Joined
Oct 15, 2008
Messages
18
Likes
0
Points
0
#13
My problem seems to be solved.

After reading another post, I changed all kewlstart settings to loopstart in zapata conf files eg:

in zapata.conf:

signalling=fxs_ls

in zapata-channels.conf:

; Span 1: WCTDM/0 "Wildcard TDM400P REV I Board 1" (MASTER)
;;; line="1 WCTDM/0/0 FXSKS (In use)"
signalling=fxs_ls
callerid=asreceived
group=0
context=from-zaptel
dtmf=inband
channel => 1
context=default

and so on...

No problems for days now! :)
 

KLGIT

Joined
Dec 18, 2008
Messages
17
Likes
0
Points
0
#14
Bob,

That's fine to say for those that upgraded older version with YUM. But installing the bone stock 1.3 STABLE doesn't work either. The same failure happens out of the box.
Now IMO it doesn't really matter who's fault the bad driver is, Elastix still shipped it broken in a stable release. That's pretty hard to blame the others for.

The silence is also an issue. Someone should have tested and verified the problem asap and posted here at least stating that there is an issue, and that it's known about by the right people and being worked on. That's fine, I could live with that. But as it is it took me a day to find this much info.

While I'm at it, I've gotten the impression that Elastix is a little less focused on Analogue hardware and configuration that some of the other Asterisk flavours. I'm wondering if that's due to it's large usage outside North America where there's probably less use of those boards. For example even the Elastix without tears book glosses over the analogue extension setup while going into detail on the SIP setup. Just an observation.

Anyway, if anyone solves the TDM-400P issues with 1.3 and wants to post a clear solution description somewhere, I'm sure many would appreciate it.

Thanks,
Christopher Gaul
Kingland Group
 

KLGIT

Joined
Dec 18, 2008
Messages
17
Likes
0
Points
0
#15
OK, so here's my findings....

After searching here and googling all day, I put together something that works for now. But it's sure a kludge.

Basically I found the other post here where Bob refers to ElastixConnection and right on the front page (like I said should be here too) is a message about this bug and a proposed fix.

However in my case, the changing of fxo_ks and fxs_ks to fxo_ls and fxs_ls respectively didn't do it. I also had to throw in part of Maxonline's Tue, 04/22/2008 - 4:25pm post where he suggests a long fix.
I tried picking out part of that fix too. Here's what I came up with...

Keep in mind, my system was a fresh 1.3sep08 ISO install of Elastix. After having this problem I tried a yum update all and an update of all the FreePBX modules which of course did nothing.
So, my system is a fully updated 1.3 install.

I then changed all the fx(o|s)_ks references to fx(o|s)_ls as mentioned above.
Also from a root shell on the Elastix box I did parts of Maxonline's suggestion.

asterisk -rvvvvvv
help
Look for zap commands, if none, zap missing
type exit (enter)
back to shell
now do
modprobe zaptel
amportal restart

This gets my TDM-400P working. Dial tone on my handset and calls go out too.
However, it doesn't survive a reboot. And it's a kludge anyway. But it gets you up and running for now.

Hopefully there will be yum'able fixes for both 1.3 and 1.4b soon.

Hope this helps someone else.

Christopher Gaul
Kingland Group
 

Bob

Joined
Nov 4, 2007
Messages
2,400
Likes
1
Points
36
#16
KLGIT,

Good research, now a little close to understanding.

It is possible that this is a combination of hardware and software. Particular models of machines where detection of hardware is attempted by the system, appear (please note this is unsubstantiated) to upset the detection of the TDM400 card. It is possible that the addtional software that has been added to Elastix (e.g. Sangoma drivers etc) is upsetting the detection of the TDM400 at the point of booting. Typical workarounds may be taking out the additional card detects, leaving just the TDM400 or similar driver.

Doing a Modprobe again afterwards works because the card has sorted itself out, but naturally fails on boot again. It has happened on other systems as well such as Trixbox (over two years ago), which required the removal of all detection except for the TDM400 card. This may also explain why you have tried other distributions and it works....

Again the offer is open, that I made in one of the other messages. It would be good to resolve this on a system that has the issue.

Regards

Bob
 

KLGIT

Joined
Dec 18, 2008
Messages
17
Likes
0
Points
0
#17
Bob,

What's strange is that, at least on my test system, the TDM-400P does get initialized at boot. It even shows up in some tests and diagnostics.
It's just not working correctly.

I think you're on to something though. I'm wondering if it's not (or not entirely) the wctdm driver that's the problem but some other driver that's being initialized (modprobed) after the wctdm driver that's hosing the TDM-400P. This way it's still known to the system, still in /dev and so on, but it's not talking anymore because something caused it to go into a state that breaks communications between the TDM-400P and the system or asterisk.

I'm still a little unfamiliar with how asterisk handles hardware. Where would be the correct place to 'comment out' other drivers from loading so I can test this? Or at least re-order them so the wctdm driver is modprobed last?

Sorry about all my questions and occasional lack of detail, but even though I'm a pretty advanced Linux admin, I've only been working with Asterisk (and CentOS) for a few days so I'm still slogging up the learning curve.
Can't say I'm a big fan of CentOS(RH) BTW. The init setup is....well kinda backwards when you're used to the (IMO better and easier) SuSE way of doing it. However, I realize CentOS is popular, relatively stable, and being RH based somewhat of a defacto standard. It's just that it's been an added thing for me to deal with on top of learning all this other telephony/asterisk stuff...

That's one of my attractions to AsteriskNOW and Elastix. The UI abstracts the dirty work. Though I always like to learn how to do the manual stuff first before I go all GUI.

Thanks,
Christopher Gaul
Kingland Group
 

KLGIT

Joined
Dec 18, 2008
Messages
17
Likes
0
Points
0
#18
Bob et al,

In case it helps, my test box is an IBM/Lenovo ThinkCentre M57 (6071-BDU) upgraded to 2GB RAM. Specs available here.

Though I don't think this is PC HW related...but it doesn't hurt to have more info.
 

Bob

Joined
Nov 4, 2007
Messages
2,400
Likes
1
Points
36
#19
KLGIT,

The file I referring to is under /etc/sysconfig called zaptel.

zaptel under init.d uses this file to load and unload the drivers. What I have done with problem systems in the past, where the card fails to initialise, is to comment out (using #), the drivers that I have no interest, such as E1 cards, Xorcom etc...in fact all of them except for the

MODULES="$MODULES wctdm" # TDM400P - Modular FXS/FXO interface (1-4 ports)

if you are using the TDM400 card (or equiv).

Now what I am referring to in the previous post, is that in this unloading and loading of drivers, it is clobbering the TDM400 card, which is not recovering in time, when the load command comes up for the TDM driver, and as such goes on past. However, a minute or two later, when you issue a modprobe, the card has recovered and as such handles a reload.

When I talk a about a HW problem, I am not neceaarily saying your hardware (IBM) is faulty, just that its design, along with Centos may have some issue that we are not aware of. It could be the way that the Interrupt controller handles probing for the card, the way Centos interacts with your Interrupt controller etc. As you are very much aware, no motherboard is designed the same as another.

Anyhow try the modification of the zaptel file in sysconfig, to see if this resolves the issue.

Regards

Bob
 

KLGIT

Joined
Dec 18, 2008
Messages
17
Likes
0
Points
0
#20
I will try that and get back to you.

I knew what you meant about hardware, however that comment got me thinking that it might be worth mentioning my test system so that those diagnosing this can have all the info in case there's another component to this problem. For example, PCI 2.1 vs. 2.2, or BIOS manufacturer, and so on.


Anyway, I'll try that mod and post the results here.


Thanks again.
 

Members online

Latest posts

Forum statistics

Threads
30,902
Messages
130,887
Members
17,567
Latest member
achilont13
Top