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


#21

This is something that 3CX verified to work with the Grandstream GXW4104… nothing more… I am just reporting what I am using with the PSEUDO PSTN service and what works.


#22

Try using with any of the Busy tone detection signals you are using and if not try the ones that 3CX configured…


#23

My set up for testing purposes is - a Grandstream HT814 simulating Australian dial tone, busy tone signalling etc and the Grandstream GXW4104 via 3CX.


#24

Thanks Kevin,
I will perform some trial and error checks when I get home from work.


#25

Do I have to answer the phone that the GXW calls while it is performing its autodetection tests?

I have not answered the phone as it wasn’t clear to me from the documentation whether or not I had to answer the calls made by the autodetection tests?


#26

No matter how hard I try, the only way I can get this to behave half acceptably is to set all CPT f1 and f2 values to the same value (say 400 or 425).

And I would like for someone to help me understand why when I set the Inbound Route Destination for this PSTN to be an extension everything works perfectly. That is, I call the PSTN number using my mobile phone, the destination extension rings, and if I hang up my mobile before the call is answered, the destination extension stops ringing within 1 - 2 seconds. And when I check the status of Line 1 on the Grandstream it shows “Line 1: Connected, idle.” --> Perfect! And to me this indicates that the GXW4104 is very accurately detecting the PSTN line being hung up for this case. What do you all think?

But, then if I set the Inbound Route Destination for this same PSTN to be a IVR, everything does not work perfectly. That is, I call the PSTN number using my mobile phone, the IVR answers the call, I press a key (number “1”) and I am transferred to the same extension that is called in the scenario described in the paragraph above, the destination rings and if I hang up my mobile, the destination extension does not stop ringing for 10 seconds and during this 10 seconds, the status of Line 1 on the Grandstream shows “Line 1: busy, PSTN Incoming (caller#): unknown”, even though I have hung up my mobile phone. --> Not so perfect! After the 10 second period, the line status shown on the Grandstream is “Line 1: Connected, idle” and is ready for service once more.

But, what I have realised is that when the IVR “answers” the call I make from my mobile, this is the same as me answering the extension in scenario described in the 2nd paragraph above and when I perform this test and answer the call myself and then hang up my mobile, the line is kept open for 10 seconds and during these 10 seconds the Grandstream reports the line is busy and after the 10 seconds shows it as idle. In this case, the extension “hangs up” 10 seconds after the mobile phone has hung up and for a second or two, I hear a busy tone, after which the PSTN line is available again.

In both cases of the PSTN call being answered (by either the IVR or me), the PSTN will become idle 10 seconds after the mobile phone is hung up if and only if I have set all CPT tone f1 and f2 values to the same value (400 or 425). If I don’t set them to these values, then the line will not be released after 10 seconds and instead I will just hear a constant engaged / busy tone from the speaker phone of the extension that received the call but was hung up on.

What is also interesting is the case where if I hang up the extension that was dialled, then the PSTN line status changes from busy to idle practically instantly.

Food for thought. If I try any of the suggested CPTs then they are worse than what I have now which is:

Any further thoughts / suggestions?


#27

The reason for the variance in the disconnect is that when you hang up from an extension connected to the PBX, the PBX sends a BYE via SIP messaging almost instantaneously that tells the GXW to end the call.

When you hung up, before the call was answered, the call was never completed. The GWX only sent an INVITE, and the FPBX sent the 100 Trying and the 180 Ringing or 183 Session Progress, so you heard the ringing and then you disconnected which was detected and the GXW sent a Cancel request to the extension and ended the call. There was never any audio flow between you and the extension so no 200OK or an ACK.

When a call is ended from a phone coming over the landline, the GXW is reliant on some form of disconnect indication coming from the remote end. This can be one of several different forms depending upon the signalling in use by the telco provider. If tone disconnect is used, then it will typically occur within 6 seconds. The issue is that the tone used may be a reorder (same as congestion) and in some cases a busy. Again, it depends on the provider. It is played long enough for a human to hear and understand that a redial is needed. As your call referenced earlier was never connected to the extension, there was no need to play the audio so a human could hear.

What Marcin suggested earlier is that most phones are loop start and as a result, the disconnect is signaled when the phone sees the absence of battery on the line for X milliseconds. His setting is correct if the ITU bulletin that Kev published is in effect.

This is the section that controls the signalling used to indicate a need to disconnect:


The tone disconnect setting is used in conjunction with the call progress tone settings you will note that the busy tone is the one of interest. If indeed a tone disconnect is used, you have to keep in mind that they are using the same tone for both a reorder/congestion and a standard busy and there will be a delay.

What happens when you connect an analog phone to the line and call the number and answer with the analog phone and then hangup at the other end while keeping the analog phone off-hook? What do you hear? If you get a fast busy, let it do that for 12 seconds or longer.

When using an analog phone, the detection is the human listening on the phone. The phone is a mechanical/electronic relay (on-hook/off-hook) controlled by the receiver either being in or out of the cradle. When you get a tone, you generally hangup, but if you don’t, the tone should continue to play or may switch after some period to a off-hook warning. This may shed some light on what signaling is used.

The GXW on the other hand is an electronic line sensing mechanism. It has to determine if a line if actually connected, what the line parameters are and how to handle whatever line signalling and CID methods are used. Of course, it needs some help, which is what you are attempting to do.


#28

It can be also problem with audio. Answered call can have lower signal so GXW do not hear it correctly.
Try change -11 to -20 (after f).


#29

I am unaware if the NZ and Australia standards are the same, but I found an old post that indicated a solution for a HT503:

Preferred DTMF Method: In-Audio
Disable DTMF Negotiation: Yes
AC Termination Model: Impedance-based
Impedance-based selection: Complex3 - 370 ohms + (620 ohms || 310 nF)
Enable PSTN Disconnect Tone Detection: Yes
PSTN Disconnect Tone: f1=400@-30,f2=400@-30,c=250/250;[/font]

With these settings in place, the HT503 within New Zealand can dial out to PSTN, and can detect disconnect beeps and automatically hang up on PSTN calls.

I suppose you could try, but there are a lot of unknowns.


#30

-30, yeah can be loudness problem


#31

I saw that too.

I still think if the ITU is correct, which I have no reason to think it isn’t that the 425 @ 375 is correct.

Here is the NZ ITU standard -

So, yes, I do indeed think your suggestion is correct.

Additionally, I looked at a UCM and the settings for Australia are 425/375 and -50


#32

@Ipneblett,
Thank you very much
I will hook up an analog phone tomorrow and listen.

May I ask who “they” are in “they are using” in the above? If you could elaborate on what you mean by this that would be very much appreciated.

I am curious and confused that the GXW degrades completely (does not release the line at all) when I change f1 or f2 on another unrelated CPT (eg. dial tone) to a different value than all other frequencies in use by the 3 other CPTs. Since the busy tone is the one of interest, isn’t it strange that changing a value for an unrelated parameter is causing the unit to stop releasing the line entirely? Is there something wrong with the device?

Also, the parameter values detected by the autodetection did not work at all.

@Marcin, I am quite sure I tried -24 for the busy tone volume and this made no difference. I will try again with -30 or -50 (based on @Ipneblett’s UCM findings).

Thank you all for your amazing support and assistance. I am very lucky to have you all offering me this awesome help.


#33

“They” being the telco provider who provides the tones.

Something wrong with the device, unknown. As you are changing various settings, I have no idea of how the device may interpret what is “heard” and the timing of when such occurs while the line is off-hook hence why I suggested the analog phone. If you had a butt-set, you could audibly monitor the line while it was in use with the UCM.

Further, as this is a line provided by a cable provider from an eMTA, I assume that there may be some slight differences in how the tones are presented versus those of an interconnected landline telephone provider.


#34

The ISP may not have set the Analogue device correctly - Terry which carrier is it?

iiNet? TPG? I have direct contacts with each tech department…


#35

Thank you all for your ongoing assistance and support

@Ipneblett, I am not a telephony engineer and do not have a butt-set, nor do I know what a UCM is.
I will check with analog phone today.
I think you are correct regarding the provider not doing the tones in the standard way. I remember many years ago when I was configuring a SPA3102 as a PSTN to VOIP gateway, that I wrestled for some time to get the SPA3102 to release the PSTN line and this was something to do with the disconnect tone not being “standard”. So I dug out the device which I have not used for maybe 8 years and found that I had to set the SPA3102 disconnect tone to

425@-30,425@-30;1(.390/.390/1+2)

I don’t know how to translate this into a GXW4104 CPT setting.
Can anyone help here and if so, should I make the Busy and Re-order tones the same?

I also checked a forum that I used back then and others said that they needed to use

425@-30,425@-30;10(.375/.375/1+2)

Note the value of ‘10’ in place of ‘1’. Does anyone know the significance of that value?

@scottsip
My carrier is Optus. Coaxial cable feeds CAU and CAU provides pseudo PSTN.

Further thoughts and suggestions very much appreciated.


#36

What Marcin posted is correct. You can change the volume setting to try -30…-50.
UCM…my mistake. Should have been GXW.


#37

Thank you. I will give it a go after work.


#38

Hi Mr. Terry,
I think your problem is at your ivr setting or ivr system on your freepbx not in your gxw4104 call progress tones. Why i can say that? because like your mentioned above, if you changed your destination to extension in your inbound route, it worked perfect but when you changed your destination to ivr, it didn’t work perfect. I do not know about freepbx, so maybe you can ask freepbx expert. And here, I give you a link that had same problem with ivr freepbx and maybe this link can help you. Here is the link : https://community.freepbx.org/t/ivr-not-giving-hang-up-command/31855


#39

Make sure the following setting is set in freepbx … callprogress=yes


#40

Okay so now I see you have 2 x problems and you are using a cut down port of Freepbx and asterisk using a Raspberry PI and Raspbian os stretch??

Is this system for a home or a business??

Why not install 3cx for the raspberry pi… much more assistance on the forums for this…