Unsupported Direct SIP for Grandstream HT 800 series

[tommellows]

Hi,

Does anyone know why there is no Direct SIP (STUN - remote) provisioning method for the HT 800 gateways?

We are looking to deploy these in conjunction with a hosted 3CX instance. At most sites there will only be a single HT818, so deploying an SBC (or multiple for redundancy) seems like an unnecessary complication. We can make the devices work with manual configuration, but this is inconvenient, especially once the devices have been deployed to the remote sites.

We thought we might be able to work around this issue by creating a custom template, but it looks like custom templates for FXS/DECT devices are also not an option.

 

[JohnS_3CX]

Hi Tom,

We do not support or recommend ever using STUN on those devices.
The only recommended and supported way of using them remotely is via SBC.

You can indeed do so manually if you wish to do so on your own, but please be advised that we cannot provide support for this method, and they may not work reliably in the long run, even if they appear to do so at first.

If I may, can I ask what purpose the devices will be used for?

 

[tommellows]

Hi John,

Thank you for your response.

Are you able to elaborate on what why the devices may not work reliably in the long run. We'd like fully understand the technical reason for this to allow us to make an informed decision as to whether or not to run the devices in this (unsupported) configuration.

We are looking to use the devices as a replacement for PSTN lines, when BT stop supporting them in 2025. Regular phones we will of course upgrade to SIP devices, but there other services which rely upon a PSTN infrastructure, such as lift lines, which we need a solution for.

We are aiming to come up with a solution which requires as few devices as possible, to cut down on the number of devices that need to be maintained, and the number of potential single points of failure.

 

[JohnS_3CX]

• For critical things such as lift lines (which would previously work after a power cut, given the nature of PSTN) you should best consider switching them to using GSM - do not use FXS!

• Even when the power goes down, GSM modules for lifts can still operate under battery power, ensuring the occupants can reach emergency services. Even with an expired subscription, GSM devices can attach themselves to any available carrier when it comes to emergency calls, providing an additional level of redundancy.

• On the other hand, an FXS needs to have power, network, internet, and a working PBX on the other end before anyone can reach 999 emergency (even on SBC mode). That is too long of a chain for such critical applications as emergency services.

Are you able to elaborate on what why the devices may not work reliably in the long run. We'd like fully understand the technical reason for this to allow us to make an informed decision as to whether or not to run the devices in this (unsupported) configuration.

Yes, STUN has been known to be at the whim of the device running it, the firewall controlling it, the ISP to which the firewall is connected, the actual STUN server on the other end and any in between equipment such as managed switches. It is the least reliable way of running IP phones, and requires too much admin and setup overhead to *maybe* ensure that it works reliably over the long run. Even a simple firewall tweak or firmware update has been enough to bring them down in the past. Add to that the fact that we do not interop those devices with Grandstream for STUN at all, so there may be yet unknown issues to be encountered. There is also a large body of networking devices and CPE out there that sometimes interact in unexpected ways when handling SIP traffic which could cause issues.

May be a bit of a tedious reply, but I really wanted to make it clear that you should not be going down this path when it comes to emergency phones, or alarm systems or anything that is critical. Reject the idea of FXS entirely if you can for this type of purpose where there is an extremely low tolerance for failure, I say this with the best intent.