Troubleshooting dropped calls

Hi,
Ok, so after the site meeting they left monitoring equipment attached to the line in order to test the link. The link tested fine from the exchange, they just re-testing from my side to prove to me that the link is stable.
I know the link is stable because it's only 1 call at a time that's dropped (not all at once).
What kind of troubleshooting can I do n my side?
This doesn't happen with internal calls, and the PRI card has been replaced.
Steven
StevenHookAsked:
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.

Ron MalmsteadInformation Services ManagerCommented:
Are these hardware phones or softphones ?
Is there any error on the Asterisk CLI when you drop a call ?

http://www.experts-exchange.com/Networking/Telecommunications/IP_Telephony/Asterisk_/Q_25132760.html
0
StevenHookAuthor Commented:
I can't see any error - looks like a clean hangup.
Both. I have soft-phones on all the PCs, then most of the technical staff and managers have Nokias that hook up over wifi and some of the production managers in the work area have wired or wireless DECT hard phones.
The dropped calls happen across the board.
I use xlite mostly but also some others for experimentation bria, the paid for x-lite, zoiper, there have been others over time. I use my Nokia N85 and I experience it quite a lot - but we all do :)
Steven.
0
feptiasCommented:
I have seen call drop problems with SIP, but you seem to be saying it happens even with calls where no part of the call is using SIP. Is that correct?
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

StevenHookAuthor Commented:
no, all our calls use sip internally (between the client / handset and the asterisk server) outbound calls are over the PRI
But strangely internal calls that do not go over the PRI are fine, don't ever get dropped.
Steven
0
feptiasCommented:
Are you able to capture the SIP packets at the time the call drops? For example, at the Asterisk CLI the command "sip set debug on" or "sip set debug peer <peer-name>" will cause SIP packets to be displayed on the console.
0
StevenHookAuthor Commented:
I can try.
It is difficult, as there isn't really a way to predict when a call will be dropped, they seem to happen about 5 - 10 min into a call, but only approximately 10% of calls drop.
Steven
0
feptiasCommented:
From your description, in my opinion the most likely cause of the cut-offs is "talk-off". This is where frequencies detected in speech match those defined for a disconnect tone or DTMF tone. If the SIP trace shows that Asterisk issued a BYE request at the point where the call drops, then this would tend to confirm the hypothesis.
0
StevenHookAuthor Commented:
do you know which DTMF tome initiates a dropped call?
I will give it a try.
One place I know it seems to happen more often than usual is when I am calling my telco's support line to report a fault, while I am on hold waiting and they have all these troubleshooting help messages it often drops. But that might also just be because I call them often.
Is this is the case, how do we go about resolving it?
Steven
0
feptiasCommented:
Check the file /etc/asterisk/features.conf to see if there is a single tone defined for "disconnect" in the [featuremap] section. If necessary, change it to a multiple tone sequence as this is almost impossible to be triggered by talk off.

In the files /etc/asterisk/sip.conf and /etc/asterisk/chan_dahdi.conf there may be a setting for "relaxdtmf" which, when set to yes, will make Asterisk more sensitive to talk-off. Also check in sip.conf to see if the SIP phones are using dtmfmode=inband or dtmfmode=auto. If possible, avoid these modes because they may be prone to talk-off problems.

In the file /etc/asterisk/chan_dahdi.conf, look for PRI settings that might be relevant, especially any that might allow tone disconnection (such as "busydetect", "callprogress" and "progzone"). Make sure settings like "switchtype" are correct for your location.

I have to admit most of the suggestions above are unlikely to be relevant and the best way to make progress would be if you could see what SIP request is being made at the time the call drops (and whether that request comes from Asterisk or from the client device).
0
StevenHookAuthor Commented:
disconnect = **
I can remove this altogether the problem should go away?
I don't think we use ** at all

this is my zapata.conf:

language=en
context=from-pstn
;signalling=fxs_ks
switchtype=euroisdn
pridialplan=unknown
prilocaldialplan=unknown
overlapdial=yes
signalling=pri_cpe
rxwink=300              ; Atlas seems to use long (250ms) winks
;
; Whether or not to do distinctive ring detection on FXO lines
;
;usedistinctiveringdetection=yes

usecallerid=yes
hidecallerid=no
restrictcid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=128
rxgain=0.0
txgain=0.0
group=0
channel => 1-15,17-31
callgroup=1
pickupgroup=1
immediate=no
busydetect=no
busycount=4
callerid=asreceived
;faxdetect=both
faxdetect=incoming
;faxdetect=outgoing
;faxdetect=no


I will try monitor calls I know will be long and look for disconnects
0
feptiasCommented:
It looks like you are in the UK although your Experts Exchange time zone is shown as Pacific Daylight Time. Here are some "safe/cautious" zapata.conf settings from a UK Asterisk server I configured some time ago:
signalling=pri_cpe
switchtype=euroisdn
pridialplan=unknown
usecallerid=yes
hidecallerid=no
callwaiting=no
callwaitingcallerid=no
threewaycalling=no
transfer=no
cancallforward=no
echocancel=yes
echocancelwhenbridged=yes
immediate=no
callprogress=no
callerid=asreceived
channel=>1-15,17-31

In features.conf, I am not sure if commenting them out will disable the feature or just make it use a default so the approach I always take is to set all the special feature codes to two different digits. For example:
[featuremap]
blindxfer => #1            ; Blind transfer
disconnect => *0            ; Disconnect
automon => *1                  ; One Touch Record
atxfer => *2                  ; Attended transfer

The problem is not necessarily talk-off so best not to start trying too many fixes for talk-off until we have more information such as a SIP trace.
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
StevenHookAuthor Commented:
Seems to be a LOT better after those small changes. Thanks
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
IP Telephony

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.