FXO Trunklines don't hangup

mikedmr

Joined
Jun 18, 2009
Messages
37
Likes
0
Points
0
#1
Hello Guys,

Have another strange problem I encountered using both Elastix 1.6 and 2.0 versions.

My setup is the above mentioned elastix versions with 4FXO card on an intel machine.

For no apparent reason 2 or more trunks just dial out without any intervention. And they don't hangup or disengage. So All calls to PSTN trunks are always busy. I have to manually reboot the server or disconnect the said lines for it to be ok again.

I made changes already in the chan_dahdi.conf file to detect the busy signal and just hangup.

Really strange.

Mike
 

fmvillares

Joined
Sep 8, 2007
Messages
1,785
Likes
0
Points
0
#2
you have your machine open to the internet?
 

mikedmr

Joined
Jun 18, 2009
Messages
37
Likes
0
Points
0
#3
Not at this time. It's use primarily as a PABX system for internal calls and some PSTN outbound calls.

I already did 4 servers with different motherboards and cards. Same problem. Also tried elastix 1.5.2 version without any updates.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#4
Given your multiple deployments with the same result, I suggest you investigate your phone lines themselves, perhaps suspect other devices being "bridged" on the line, or poor wiring (split pairs)
 

mikedmr

Joined
Jun 18, 2009
Messages
37
Likes
0
Points
0
#5
Yes absolutely. I suspected the telco wires now. Will give updates on how well this scenario ends.
Thanks all!
 

fmvillares

Joined
Sep 8, 2007
Messages
1,785
Likes
0
Points
0
#6
Dicko sorry for the offtopic but happy b-day !!!!
 

mikedmr

Joined
Jun 18, 2009
Messages
37
Likes
0
Points
0
#7
Hi Dicko,

For for particular problem, I thought i had corrected it (since elastix server was running for a week now without this same problem).

Still using an intel machine with with 4 ports FXO card running on elastix 1.5.2 this time.

Attached 3 telco lines to the analog card.

Question 1: One telco lines has CALL WAITING enabled. Will this cause the hang ups?

Question 2: Incoming Route catches all inbound calls (any DID, any CID) without defining the DID number. Will this cause the problem also? Inbound calls go directly to a group call.
Btw, ZAP channels DID also configured, as well as most .conf files related to it..eg pstn=zaptel..etc

Hoping for another solution to this particular problem.

Mike
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#8
Absolutely the call waiting will need consideration, you will probably need to add (nobody but you needs it :) ) and adjust a parameter in /etc/asterisk/chan_dahdi.conf

flash=nnn ; milliseconds

the flash presented from SLT type device must be long enough for the Call waiting from your telco to work but short enough to prevent Asterisk interpreting it as a hangup. These settings would make no sense if you use SIP devices as there is no way to send a flash directly from such a beast, you will need to get your hands dirty with custom contexts.-

pstn=zaptel makes no sense, context=from-pstn or context=from-zaptel do, anything else is probably just guessing, Please read "Elastix Without Tears " again. Not using context=from-zaptel is hightly unadvised, just learn how to use it.

dicko
 

jgutierrez

Joined
Feb 28, 2008
Messages
5,737
Likes
0
Points
0
#9
When using analog lines, there are some issue with hangup detection, what I usually do is to edit /etc/asterisk/chan_dahdi.conf
and uncomment the lines for busydetect and busycount
Then I change busycount=3 to busycount=8
The I execute from CLI
module reload
 

fmvillares

Joined
Sep 8, 2007
Messages
1,785
Likes
0
Points
0
#10
hang up on polarity switch is also another o´ption to look for if your lines get blocked
 

mikedmr

Joined
Jun 18, 2009
Messages
37
Likes
0
Points
0
#11
Hi All,

I wish to state again this unique problem.

Elastix box runs fine..internal calls ok. Outbound calls runs fine for a while until....

for no apparent reason, 2 Dahdi (telco lines) starts engaging. Meaning if you look at the FOP, 2 Dahdi icons lights up like they are doing some calls, but in reality nobody is making the call. And these calls don't hang up for minutes or hours, until someone notices that these lines are creating a busy line.

What we do is disengage the line physically, or rebooting the system, then all systems fine again, until the next hang ups.

Did the chan_dahdi.conf things....eg. busycount, busydetect, hanguponpolarityswitch..etc
Will also disable the call waiting from telco side in the next days and observe.

Will state here all configs later.

Best regards,

mike
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#12
And I wish to state again your trunks are mis-wired or bridged or your hardware is broken, stick a butt-set on them and listen . . .

dicko
 

Adamant

Joined
Jul 27, 2010
Messages
11
Likes
0
Points
0
#13
I've found that here in the UK, the incumbent telco (BT) perfom a battery disconnect to signal a hangup.

I've noticed that the Sangoma A200 cards (and possibly others, I've not got any to try) require 500ms+ in order to reliably detect a hangup.

The problem is that BT send by default a battery disconnect of varying periods (different hardware in every exchange) but this is usually around the 200ms mark and so the Sangoma doesn't realiably detect the disconnection so lines can be held open.

This is even worse at the cable exchanges and battery disconnects can be <200ms.

A decent butt-set or even a scope if you don't have a butt-set then using a scope will show you the current disconnect time.

This can be changed in the Sangoma card configs to detect shorter battery disconnects but by going too short then you run the risk of random disconnections.

I can't see which country you're in but the best bet in this instance is to speak to your telco and ask for the battery disconnect time on hangup to be increased - BT calls this the DTC (Disconnect Clear Time). Getting this increased to in the region of 800ms helps to reliably detect a hangup with a battery disconnect.

In fact, best bet is to do as dicko says and stick a butt-set on to listen to the lines and check for battery disconnect / polarity reversal / tone on clear and then you'll have a much better idea of how to configure Asterisk to reliably detect the hangup and ensure that you're not accidentally setting the wrong thing on which could cause more problems!
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,902
Messages
130,887
Members
17,565
Latest member
omarmenichetti
Top