Wildcard x100p doesn't seem to always detect hangup


Sometimes my Wildcard X100P does not seem to be properly detecting hangups on the PSTN line.

This causes some of my Asterisk dialplan commands to loop indefinitely waiting for input on a dead channel, and even worse, leaves the line busy so no new calls can come in.

Has anyone experienced this kind of problem/know what I can do to diagnose and fix it?

Also, this is related but not totally, and this one isn’t really the Wildcard’s fault inherently, but I’ve had a couple of people who seem to have figured out that if they call my line and let it ring once, the Wildcard will pick up the line, but since the caller already hung up it’s greeted with a dialtone, and thus again, stays on the line indefinitely. (Nice DoS trick.)

any advice would be greatly appreciated - thanks


This would be normal for outgoing calls to landlines, at least in the UK. The network will not give disconnect supervision until about two minutes after the called party hangs up, to give the called party a chance to answer on another extension.

What is the direction of your problem calls?

Are you sure that your network provider provides disconnect supervision and that you are correctly configured to detect it?

If neither of these apply, you will need to provide a trace of the line events (in particular voltage reversals).

I’m in the US. The problem seems intermittent. On hangup the PSTN does some kind of voltage change or polarity switch - on a standard land phone you will hear a loud click, and for about .75 seconds your voice is not echoed back at you - then the line comes active again and the “Fast busy” tone begins playing.

The problem is intermittent and I’m not exactly sure what might be triggering it. My only suspicions are that for some reason my PSTN is not reliably sending the signal that the call has hung up, or for some reason my ZAP card is not properly detecting it reliably.

The ohter case - where a caller rings once then hangs up - well there does not seem to be a real solution for that one. Because in that case there would never be a disconnect signal - the ZAP card will receive a dialtone when it picks up, and start running the dialplan at that dialtone.

It may simply mean I have to somehow adjust my dialplan and AGI scripts to timeout after some time.


I still haven’t figured this out totally and I’m still at a loss…

Here’s some more specifics. I coded a custom voice mail system because the built in Asterisk one was lacking some features I wanted. I wrote it using AGI, and it actually works extremely well.

I have a timeout on recording, so if the caller records too long, it hangs up on them.

But I also have a “press pound for more options” menu that I wrote.

And for some odd reason, calls are ending up in that menu, even though they are disconnected. That menu loop, which waits for user input then repeats the menu if nothing was entered, ended up looping indefinitely, holding my ZAP channel open! What I ended up doing for that instance was to recode the script so if it recites the menu 3 times and still nohting, it hangs up.

A call would not end up in the post-recording IVR menu unless a user specifically pushed the pound key, which would mean there was something live on the line initially… So the only conclusion is that the ZAP card is for some reason not detecting hangups consistently from the ZAP channel.

My PSTN uses a disconnect signal wherein the voltage on the line drops for about 0.5 seconds, after which it returns and the error tone (fast busy) starts to play. Most of the time my Wildcard picks up on this disconnect signal with no issue and ends the call - but as I said it doesn’t seem to do so all the time.

And on top of that, does anyone have any suggestions for the other issue I mentioned - where someone calls my PSTN line, lets it ring once, then hangs up, and when Asterisk picks it up, it’s greeted with a dialtone, and again holds the line open (at least until my scripts explicitly time out)? Apparently someone out there is messing with me because I’m getting a lot of calls like this - calls where Asterisk picks up to the tune of a dialtone (I figured this out using monitor recording)

The only short-term solution as I said so far is that I’ve adjusted my scripts to automaticaly disconnect after so much user inactivity. But since my VM system does allow recording times up to like 200 seconds, that means one of these calls holds the line off-hook for at least 200 seconds (recording a VM consisting of a dialtone, followed by the telco “hang up and try agian”, folllowed by fast busy, blah blah) and then three loops of the post-record IVr, before it finally gives up.

Here’s a thought…Is there any Asterisk application that could listen to the line and check for certain tones (i.e. a dialtone, a fast busy, etc)? I could run that application from within AGI using Exec and for example if dialtone or fast busy is detected immediately end the call at that time.



have you tried the busy detect feature in zapata.conf
i had such problem before, have a look here it might help:
asteriskguru.com/tutorials/r … email.html

I ran a debug on the wcfxo driver. As I expected, this is what I get:

Jul 21 08:22:34 millions kernel: BATTERY!
Jul 21 08:25:45 millions kernel: RING!
Jul 21 08:25:47 millions kernel: NO RING!
Jul 21 08:25:51 millions kernel: RING!
Jul 21 08:25:51 millions kernel: Setting hook state to 1 (07)
Jul 21 08:25:59 millions kernel: NO BATTERY!
Jul 21 08:25:59 millions kernel: Setting hook state to 0 (0a)
Jul 21 08:26:00 millions kernel: BATTERY!
Jul 21 08:26:00 millions kernel: NO RING!

So the driver is telling me exactly what I suspected my telco does - drops the power for a moment to signal a hangup.

So what I need to do instead is look into tone detection, because either the hookstate thing isn’t reliable enough for some reason or the driver is missing it somehow. I’m going to leave debug on too and see what happens exactly.


Looks like everything is configured properly in my zapata.conf:

channel => 1

And in indications.conf,


So it looks like everything is set right, but I can reliably cause Asterisk to mess up by calling my PSTN line, waiting for only one ring then hanging up. Asterisk still sets the phone off hook and starts running the menu at the dialtone…