POTS line disconnects prematurely on some calls before answer.

I am tracing this issue where a user dials a number and it rings a few times however the call is disconnected after several rings if the dialed party fails to answer.  If the dialed party answers within a few rings the call is fine.  This is not a problem with all calls but just certain numbers.  The common factor may be the PBX at the called party.  It always happens when dialing into a PBX type system.

This has also happened when the dialed party transfers the caller to another extension: receptionist or IVR answers, caller is transferred to final extension and if the user does not answer within a few rings the call is disconnected.

Seems like in some cases a signal is being sent which aproximates the hangup tone or something of that nature.  Within the Asterisk logs is indicated that the call was placed and then a few seconds later it starts the hangup macro.

This is an Elastix 2.4.0 box with this card: Span # 1: OPVXA1200/12 "OpenVox A1200P/A800P Board 13" (MASTER) 1 FXS & 4 FXO ports.

indications.conf
[general]
country=us

[us]
description = United States / North America
ringcadence = 2000,4000
dial = 350+440
busy = 480+620/500,0/500
ring = 440+480/2000,0/4000
congestion = 480+620/250,0/250
callwaiting = 440/300,0/10000
dialrecall = !350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,350+440
record = 1400/500,0/15000
info = !950/330,!1400/330,!1800/330,0
stutter = !350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,350+440

Open in new window

chan_dahdi.conf
[trunkgroups]

[channels]
context=from-pstn
signalling=fxs_ks
rxwink=300              ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
faxdetect=incoming
echotraining=800
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
hanguponpolarityswitch=yes
;Uncomment these lines if you have problems with the disconection of your analog lines
busydetect=yes
busycount=3


immediate=no

#include dahdi-channels.conf
#include chan_dahdi_additional.conf

Open in new window

LVL 2
YMartinAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

arnoldCommented:
Unfamiliar with the system you use.
Your timeout is too short to establish your call. The configs you posted do not seem to cover it.
You may need to look at the per extension config if issue is limited to one phone/group or the global config
i.e. 5 seconds to establish/transfer will mean that only two rings will be heard on the other side before your side gives up.
0
YMartinAuthor Commented:
Most calls establish and terminate without issues.  It is only calls to a few numbers which are terminated prematurely.  It appears that the called PBX or the carrier is sending some signal which our PBX misinterprets as a disconnect signal.

This happens after the called PBX answers, our user selects options from the IVR, is transferred to an extension,  that extension rings several times - if the called party answers at that extension within a ring or two the call is fine.  If it rings for several rings our user is disconnected.  If the user places the same call with his cell phone he has no issues.

If this provides any clues I would like to resolve this, otherwise I will try routing those numbers out a sip trunk and see if that resolves anything.
0
arnoldCommented:
The issue might be the DTMF if any (click) when the extension is picked up after a while. i.e. equivalent to a "flash" on the old phones that mimics the hangup to handle call-waiting.
Digital systems are less susceptible to those. Analog devices often see the click (DTMF) transferring to voice-mail as a hung up.

you have to listen very intently to see whether at the conclusion of the IVR, you hear a click before the indication that the extension is being rang.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
YMartinAuthor Commented:
Thank you Arnold,

That does sound like it could be the problem.  I will test this out and try to hear the click.  Should that prove to be the problem what can be done to correct this in the DAHDI configuration?
0
arnoldCommented:
You have to look how long is your maximum call setup time is.The issue could be on the other side as well, i.e. it has a x number of seconds before it treats the call as no answer/and tries to go through its process that leads to the disconnect versus a transfer/voicemail.

Your only option is to call the other end and see what can be done if anything.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Voice Over IP

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.