GS Wave hold key issues while remote


Hi All,

I’m encountering a strange issue when trying to transfer/place calls on hold via GS Wave. When the phone is connected to local wifi, and is registering via the local account, hold key functionality works fine; I press hold, hold music is heard by the other party, and I can take the call off hold when I’m ready.

However, when I try the same setup, but connected via the external account, the hold key does not work. When pressed, the other caller hears only silence. What’s more, pressing the hold key again does not retrieve the call; it is left in limbo until the connection times out.

Is this a known issue, or is there a workaround? Audio and SIP streams between the softphone and PBX are fine, during a normal call both parties can hear eachother without problems.


I have not had this particular issue in recent memory.

What system are you connecting to?
Firmware version?

I’d also open a ticket at
They will likely want a packet capture of the incident occurring.
You could also share that here for extra support.


I’m connecting to a UCM6208 in both cases; both are running a 17.XX revision, just noticed that 18.XX was out, so I’m upgrading to that to test; will report what I find along with packet capture.


The problem still occurs on the most recent FW version; attached is a PCAP of an attempt to use the Hold key.

I initiate a call from the softphone ( over an external connection

The call passes through the UCM ( and is answered by my physical extension (

At 00:01 in the call, I press Hold; I hear a slight click on the far end, the silence

At 00:04, I press Hold again; no audio changes, still silent. I hang up the softphone, and then must manually hang up the physical extension.

Let me know if this sounds like anything to you; I’ve taken your advice and created a reseller ticket as well, will update this if we can find a solution through that.

capture-000B82D04322.tar (296.5 KB)


are your firewall settings correct?

It looks like RTP streams don’t know their way back and forth or are being blocked.

Be sure you have forwarded ports in your firewall that accommodate the calls setup and RTP streams as well as making sure SIP ALG is off so it doesn’t rewrite packets.

Check the following:
-port forwards(this is with default settings on the UCM)
UDP 5060 to UCM (can be locked down to just SIP Provider IPs)
UDP 10000-20000 to UCM (must be open to all)

SIP ALG must be off

On the UCM
PBX-SIP-NAT External Host should have static IP or dynamic DNS address in it (this tells the SIP Provider what address to respond to)

-Keep in mind best practice is to change the 5060 port to something else as well as narrowing down the RTP ports to a much smaller amount.


I believe they are; SIP ALG is disabled in all our configs, and the required ports are forwarded. We currently do have 5060 locked down to our SIP providers, and are routing the GS Wave traffic to a different port, as you suggested; RTP is also open.

These settings work great on regular calls; RTP traffic is passed all the way up until you press the hold key, as both parties can hear eachother. This leads me to believe my router/pbx is configured correctly, unless there are some strange factors I don’t know about at play.

Should DTMF settings have any bearing on the call? I don’t expect them to, as I hear no tones, but at this point I’m not sure


I have discovered the root issue here, and made Grandstream aware of it; hopefully they can forward my issue to the GS Wave dev team for an app fix.

As is (I assume) standard procedure, we have 5060 locked down to our SIP providers, and use an alternate port for GS Wave traffic. When using this alternate port, the problem occurs; however, when I unrestrict 5060 and test that way, it works as intended. It seems as though the SIP messages triggered by the hold key are still set to the default port, an oversight that will hopefully soon be corrected.


That’s interesting, thanks for sharing your results.