Grandstream HT502 Call Waiting Issue

[Spednix]

This isn't really a question as more of an acknowledgement to anyone else having this problem.  We have customers on a hosted NetSapiens solution, beside the new customers we're putting on Kazoo, and both systems seem to have this issue.

We've been getting complaints after a recent firmware upgrade of people "dropping calls" when they hear the Call Waiting tone.  After re-creating the issue in our offices I found that the 1st call waiting beep would mute the audio, the 2nd call waiting beep would un-mute the audio, the 3rd would mute the audio again, and so on and so forth.  I disabled the call waiting tone in the HT502 and it solves the problem, however the tone is replaced with an irritating blip sound, but does solve the problem.  I've opened a ticket with Grandstream to look into a better solution.

If anyone has any other suggestion or thought on this, please share, but in the mean time I just wanted to help anyone that might be having this same issue.

[Darren Schreiber]

Ironic. I have this same problem at home on my HT502 after the firmware upgrade. Same behavior, same “fix”.

It’s definitely a hardware issue IMHO

--
You received this message because you are subscribed to the Google Groups "2600hz-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 2600hz-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sebastien Legare]

Hi,

I also have been experiencing the same issue on my HT502. Latest firmware update didn't fix the issue, however as you suggested, disabling the tone did fix it.

Did you hear back from Grandstream?

Thanks!

[Darren Schreiber]

I worked with Grandstream support on this issue. Apparently, in one of the updates, an invalid prompts / tones setting was added to the setup. I’m still testing this theory but that is the belief - that the call waiting tone definition has some characters appended which cause the tone and the silence after to last X seconds.

[Sebastien Legare]

Did they give you a new configuration to try? If so I would really like to try it too.

[Darren Schreiber]

Nope, not yet. But their assertion makes sense.

[Sébastien Légaré]

Ok, please update us if you find something, I'm pretty sure it could be helpful to others as well.

Thanks!

You received this message because you are subscribed to a topic in the Google Groups "2600hz-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-users/TrCqPBbVAw0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-users...@googlegroups.com.

[Darren Schreiber]

I think it’s this... If you go to the Advanced Settings tab, near the bottom, there is a “Call Waiting Tone” box. For some reason it has this:

f1=440@-13,c=300/10000-300/10000-0/0;

Which means “on for 300ms, off for 10000ms” or 10 seconds of silence! After the tone!

I think that’s the cause. Change the 10000 to 100. Note that it’s there twice.

I think that will fix it.

[Darren Schreiber]

After a little more playing, I determined it should just be this:

f1=440@-13,c=300/100

This provides the “dual tone” beeps - first one at the beginning of the call and a second one if you don’t pickup.

Seems to fix the issue.

[bnelsonfs]

Thank you for posting this!  I may not have time to go through every single possible change to the new firmwares, but I would expect Grandstream to have caught this before releasing bad firmware.  Release notes seem to reference this problem, but newer versions do not fix it:

CHANGES SINCE FIRMWARE RELEASE 1.0.12.1 BUG FIXES • Fixed Call Waiting on device side causes Noise/Dead Air on remote party

If I get some time, I will try the beta firmware and post here for everyone.

To unsubscribe from this group and all its topics, send an email to 2600hz-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[SpideyTheMan]

Yes, we agree! Changing the call waiting tone from "f1=440@-13,c=300/10000-300/10000-0/0;" to "f1=440@-13,c=300/100" does resolve the issue. We are running firmware 1.0.14.1 which also had the issue. Thank you for posting the fix!