Call progress tones - IVR not recognising GXW4104 PSTN line being hung up


I am experiencing some issues with the GXW4104 not releasing the PSTN line after my FreePBX IVR has answered the phone and the caller hangs up.

This same problem is described here:

I am using a GXW4104, connected to Freepbx via SIP Trunk. I have an inbound route that points to IVR. When a PSTN caller makes a selection from the IVR options (after IVR prompt), and then hangs up, Freepbx doesn’t detect the disconnect and the call continues to the user’s voicemail which results in minutes of busy tone voice mail messages. While this is happening, the Grandstream shows:

Line 1: busy, PSTN Incoming (caller#): unknown

when in actual fact the caller has hung up up to 1 minute ago.

If I change the destination of the inbound route to an extension, the PSTN hangup is detected without a problem.

Another person who had this problem advised that the problem was fixed by Grandstream providing some advice on the Call Progress Tones needing to be adjusted.

I would like to know how I can fix this problem in the same manner that this person did.

Please note that I ran all PSTN Line Auto Detection Configuration tests and had the results of these test applied automatically.

I am in Australia.

Would appreciate the assistance of Grandstream or other forum members who have a solution to this issue.


Is it PSTN lines or pseudo PSTN from an ISP via some FXS ATA ?


I would say it is more a pseudo PSTN as it is provided by a CAU that is in turn fed from a multipurpose (cable broadband, pay TV, phone line) coaxial cable from our provider.
I am calling it a PSTN line as I can plug a regular analog phone line into the wall socket and it will work perfectly.
The same line is also providing a line for my old phone system and provides this line via that phone system’s PSTN (CO) card.
I am replacing my phone system with FreePBX and am connecting the “PSTN” line now into the Grandstream GXW4104.
Hope this helps.

Since posting this problem I have experimented with the frequency values for all 4 call progress tones, by setting f1 and f2 for all 4 call progress tones to the same frequency (Ryrota’s implied solution over at the FreePBX forum), This seems to have improved things, although the local extension seems to ring for longer than I would expect (10 seconds) it to following the caller hanging up. Not sure if this is related to the IVR timeout value. I will experiment with this too.


Do the 2 x line types exhibit different patterns for the incoming calls?

Physical PSTN service the timing of that would be different to the PSEUDO PSTN line provided by the carrier.

This also depends on the voltage offered as to what the ring signalling would be… but that is another problem you may counter between the 2 x line types.

Usually it is around 35 to 50 volts DC for a PSTN and some PSEUDO lines provided by an inbuilt ATA will only provide around 26 volts DC.

Now your IVR on free pbx will need timing to be set correctly. As far as Asterisk is concerned it is a SIP device it is connecting to, so all of the DTMF detection/hang up signal is handled by the GXW4104 and converted to SIP…

You may need to adjust the timing on a line by line basis to ensure the correct interoperability of the lines to asterisk.

Freepbx is just a gui over the top of command line asterisk.


Hi scottsip,
I don’t have any IVR on my old phone system.
Both old and new systems handle the PSTN line the same way so far as releasing it when either the caller or callee hangs up.
It is just when I add the IVR in to the mix to answer the incoming PSTN call, if the caller hangs up, the IVR does not see it and keeps the line open such that the call continues to progress through the pathway that was opened up for it by the IVR, leading to busy tone messages being left in the voicemail box of the extension where the call was directed to by the IVR.
I also would have thought that the Grandstream autodetection would have identified the characteristics of the pseudo PSTN and account for all that it needed to account for in relation to call progress tones etc.


I wasnt talking about your old system…

Totally depends on the way that the GXW4104 has been programmed up also what are your freepbx settings region wise ?

Never trust “Automatic” settings always verify or you will end up with anomalies like you have right now.


Thank you scottsip,
Sorry about my misunderstanding about the old system.

I don’t have 2 line types. I only have one line type which is a “pseudo” pstn and is working fine on both phone systems for calls that go direct to an extension. Given the at this works flawlessly I don’t understand why when the IVR answers the call it behaves differently.

I won’t be trusting the automatic settings moving forward.

I am quite sure I have set everything up properly in relation to regions. Is there a particular freepbx regional setting that you have in mind?

I am not sure what other settings in the GXW4104 I need to change or to what values.

Any help or suggestions here would be appreciated.

Thanks scottsip.



try the above settings - taken direct from another system.


Thanks scotsip,

Sorry to report that this hasn’t made a difference. In fact it made things worse.


How so?


It reverted back to not releasing the line for 30 seconds, compared to the 10 seconds that I got it down to by making the changes to the Call Progress Tones’ f1 and f2 values (making them the same for the 4 parameters as per Ryrota’s implied fix described here:

Ryrota states that Grandstream provided the answer / support needed to address the same problem and strongly suggests that the fix involved making f1 and f2 the same, which did make a significant improvement for me, but 10 seconds is still too long for my extension to keep ringing after the caller hangs up. The same call that with an inbound route direct to an extension will stop ringing in 2 - 3 seconds. With the call inbound routed to the IVR and then on to an extension will result in the phone ringing for 10 seconds after the caller hangs up.

Here are my Call Progress Tone settings:
My line is using Ch1.


I am hopeful that this problem can be sorted.


The above is taken from an ITU Bulletin.

Dial tone is not right on your settings, same as busy tone…


Thank you scottsip,
I am sorry to say that I have no idea how to translate this into the equivalent Grandstream values. Are you able to offer some advice / guidance?


1 column is Fi second is cadence
busy: 425@-11,f2=425@-11,c=375/375 (-11 is volume so you can change it if not work).

Normal phone do not use signal it use line power to drop it, if that is not working then you have messed signal on that line, so go with autodetect.


Hi Marcin,
Do you mean:
busy: f1=425@-11,f2=425@-11,c=375/375


yes, -11 can be higher maybe -24 ?


Thank you Marcin. I will try later today.

May I ask, is the problem that I am experiencing mostly, if not completely, related to the Busy Tone?

Also, I have already performed the autodetect tests and had them applied automatically, and the settings that were generated did not work at all. Only when I changed the f1 and f2 parameters to the same values did the problem improve (but it is still not great).



I believe your encountering issues related to how the GXW4104 is programmed and the Freepbx. Unfortunately you have been reading Freepbx fixes for an unidentified country fix - not sure it is for Australian standards which is different to the rest of the world. We use ETSI standards with DTMF signalling that had been developed for the European/Asian Pacific market not the US or Canada region.

I tested my system again last night and it works flawlessly using the frequency signalling that I posted before.

There was one change that I noted that might be coming into play. That is:

  • Enable Tone Disconnect: ch1-4:Y
  • Busy Tone: ch1-4:f1=480@-11,f2=620@-11,c=50/50;

That should resolve your disconnection issues.



Thank you Kevin,
So, I need to change all my settings back to the values shown here:

But, the difference being I need to ensure that the Enable Tone Disconnect is set to Y and not N. Is that correct?

Is there a reason for singling out the Busy Tone along with Enable Tone Disconnect? From what I can gather, the Busy Tone setting in your last post is exactly the same as the setting in

Also, what is the significance of Marcin’s suggested Busy Tone configuration values?

May I ask where in Australia your system is working flawlessly?

Many thanks for your ongoing support and assistance.


Hi Kevin,
May I also ask:
Why is the suggested Busy Tone in your last post so different to that specified by the Australian values listed in the ITU Bulletin, referred to here?