How to set up remote Wave apps without RemoteConnect/GDMS

#1

This was asked here but not answered.

What do I need to do to allow remote Wave apps to connect directly to a UCM63xx without going through GDMS/RemoteConnect?

Obviously I have to forward TCP port 8090 to the UCM, but that doesn’t seem to be enough.

With the port forward, shouldn’t I be able to connect to the Public_IP:8090 that is forwarded to the UCM?

If I want to use an FQDN instead of an IP, do I need to configure a purchased public certificate in the UDM?

I realize that RemoteConnect can handle or bypass some NAT traversal issues, but normally with a few simple instructions and a decent understanding of networking, it’s easy to set up traversal.

Where are the instructions for setting up Wave without RemoteConnect? Or has Grandstream explicitly blocked remote Wave unless you purchase RemoteConnect?

#2

A little more research. Wave initially uses port 5090 (as you can see if you set up the Windows app). I had hoped that this was a tunneling port that encapsulated all other traffic, similar to the 3CX client, but after tracing a call from the desktop Wave app, I see

TLS (TCP) to port 8090
STUN and SRTP to port 13867 (in another test, port 14782)

Even after forwarding TCP and UDP 10000-20000 to the UCM, Wave on Android won’t connect from a remote IP.

I should perhaps mention that I’m using UCM firmware 1.0.21.9.

#3

Dear user,

Thank you for using the Wave application! Please refer to the document “UCM63xx Remote Work Environment - Setup Guide”, and you can find out how to configure UCM63xx and Wave without using the UCMRC services:

Users need to build STUN server and TURN server respectively and set up in the UCM63xx to resolve the NAT issues. You can find the configuration steps in details in this document. Thanks for your testing!

Thank you!

#4

the advice is always to do the NAT in ACL

#5

Dear user,

You can follow the document I sent to you to build the STUN/TURN servers and configure your UCM63xx. Please kindly let us know if you encounter any issues. Thanks for your testing!

Thank you!

#6

Thank you, that is a very helpful document.

  1. To clarify: if I only want to use Wave, not remote SIP extensions, which part of the configuration are required? I’m thinking port forward Wave (8090), RTP (10000-20000), but not SIP? And add STUN and TURN servers?

  2. After configuring as above, I am able to log in from a Windows Wave app on a remote app, but not from an Android Wave app. Note that SIP > NAT has my public FQDN (remote.mydomain.com) but there is no certificate installed on the UCM for that domain. Does Android require a cert while the Windows app does not?

RTP%20settings

#7

Not sure what you are referring to here. Can you provide an example of how you would set this up in the UCM? My understanding is that the UCM will handle the NAT in conjunction with the STUN and TURN servers.

#8

Dear user,

Thank you for your feedback! The remote extension will be counted if you used the UCMRC domain address for login. If you are using the IP address of the UCM63xx, it will not be counted. You will need to build your own STUN/TURN servers and make sure they are working fine and configure on the UCM63xx.

For the Android app login issue, you may export the logs from your Wave Android app and send the logs to us for troubleshooting. Thanks for your testing!

#9
#10

I got Android Wave connected and I think I now have the requirements for using remote Wave without GDMS. This is the result of my testing on with a UCM6301 behind a UniFi UDM router:

  • A certificate from a public Certification Authority is not required. The built-in 25-year certificate issued by Grandstream is sufficient.
  • Set up STUN and TURN servers as described in the Remote Work Environment setup guide.
  • Port forward TCP 5061 (Secure SIP) and TCP 8090 (Wave) to the UCM63xx.
  • It is not necessary to forward port UDP 5060. Wave does not use unsecured SIP.
  • It is not necessary to forward ports 10000-20000 for RTP. The Wave app is doing a normal TLS REGISTER on 5061. The RTP ports will be opened I guess as “Related” ports on by the router.

That last one still needs verification and further testing. I saw one thread where it mentioned that this works as long as the keep-alives are frequent enough.

Next I’ll test using a non-standard external TLS port.

#11

Dear user,

Thank you for your feedback! Please kindly let us know if you notice any issues when testing the Wave app and UCM63xx. Thanks for your testing!

Thank you!

#12

I can confirm that the non-standard TLS port seems to be working:

  1. In the UCM63xx, under PBX Settings > SIP Settings > NAT, change external TLS Port to 5667, for example. No need to change the UDP and TCP ports since Wave is not using those.
  2. In the router, forward external port 5667 to the UCM’s port 5061.
    I had some double ringing on the Wave side as I established the call between the Android Wave app and an internal desk phone. But once established, I had two-way audio.

As for the keep-alives, I haven’t deduced an exact pattern, but I see OPTIONS and REGISTER packets at 17:34, 17:39, and 17:43 from the Android to the UCM when not in a call, so maybe every 4-5 minutes? Depending on the TCP timeout, that might be enough too keep the connection alive.

#13

Dear user,

Thank you for your feedback! May I ask what is the configuration of the option “Max Registration/Subscription Time” on the Web UI of your UCM63xx? The REGISTER packets you noticed are SIP refresh registration packets and do not apply to TCP link protection. Thanks for your testing!

Thank you!

#14

In my opinion WAVE is WebRTC and not standard SIP,
therefore you don’t have to follow the SIP NAT logic

#15

Dear user,

Thank you for your feedback! The Wave app has separate keep-alive packets. Could you kindly let us know the value you set for the option below:
%E5%9B%BE%E7%89%87

Thank you!

#16

these are SIP helpers and are required else you will write on the forum for help when they fail.

These applications open ports as needed so that you do not need to open them on the router!

#17

I have not changed any values on that screen so the values match your screen shot:

  • Min Registration/Subscription Time: 90
  • Default Incoming/Outgoing Registration Time: 120
  • Max Registration/Subscription Time

This screen is pretty confusing, though:

  • The default values do not match the defaults in the User’s Guide. For example, the manual says ToS is disabled, but the UCM by default is tagging all packets with ToS.
  • The tab name is “ToS”, which implies that everything on this page refers to Type of Service. However it appears that only the first three fields refer to ToS; everything else is more general SIP settings, which I guess should be on the Misc page. Oh look, the Misc page says Outbound Registrations > Register Timeout = 20. The manual says that is the retry timeout? (It would be helpful to have all registration controls on one page.)

I understand that there many possibilities to keep a TCP connection open: keep-alive packets, OPTIONS packets, re-registrations, etc. (See https://www.asterisk.org/wanted-dead-or-alive/.) I’d be interested to read more about which keep-alive options are implemented in the UCM.

#18

Dear user,

Thank you for your feedback! Your suggestions are very important to us and we will check the UI layout issues you mentioned. We will investigate and improve your suggestions in the future.

This is the signaling keep-alive on UCM. If this option is enabled, the OPTION packets will be sent.
%E5%9B%BE%E7%89%87

This is in the trunk:
%E5%9B%BE%E7%89%87

Thanks for your testing!

Thank you!

#19

Thanks for that update. Note that with 1.0.21.9, there is no Advanced tab on Extensions. Are you using a newer release or an older one? At present, extension Keep-alive is on two lines of the Basic settings tab. It is off by default, but if the earlier screen you mentioned, SIP Settings > ToS, is really about all system-wide SIP settings, then re-registration happens every two minutes so OPTIONS every minute is probably not needed.

Extension%20Keep-Alive

I do like the trunk-level heartbeat. It’s the only way I found to confirm that a peer trunk is up: Maintenance > System Events > Alert Events List > SIP Peer Trunk Status.

#20

Dear user,

Thank you for your feedback! It is a newer firmware (internal test version). We will consider your suggestion and update the layouts in the future release. Thanks for your testing!

Thank you!