Further thoughts on the GDS3710

The Grandstream 3710 Door System provides a video intercom, security camera (its recordable using compatible NVRS), RFID reader, and door unlock control relay. The device has a contact input that can be used for an inside exit demand input and a second that can be used as a door status sensor input. And all of this for the price of a door controller from HID or AXIS.

This is a new device so it has a few rough edges. This post talks about the rough edges.

References

Applicability

Firmware version 1.0.3.32 — Use this with newer firmware and your experience may differ.

Web GUI is fussy about browsers

Thank god it likes Firefox. Safari would not fill out some of the Door System -> Basic items correctly leading to an unusable configuration.

Device ships with ancient firmware

My units shipped with 1.0.2.22 firmware. 1.0.3.32 firmware is current.

The documentation is inconsistent

There’s a lot of it but the browser sensitivity is unmentioned.
The firmware update guide is largely overtaken by events
Only one of the mentioned firmware update methods actually works
Only the getting started guide reveals the location of the password on the back sticker.

Updating firmware

The beast will only accept a firmware update off of the local network. And only by HTTP. Grandstream has stopped offering served updates for the GDS3710 as network hiccups were bricking devices. The firmware update guide is out of date.

For those having a windows machine about, HFS works well, it is easy to put the files in the right spot, and a log windows shows what was fetched.

For those having the option to tinker, NGINX works nicely on a Raspberry PI.

I was unable to get the TFTP method to work.

The Grandstream Updater is not currently supported. More correctly, I couldn’t get it to work.

If using NGINX, create s subdirectory in HTML and unzip the kit there. For example, mkdir /var/www/html/GDS3710 and unzip the kit in GDS3710. Make sure the web server has permissions to read the file and traverse the entire path. The corresponding GUI entry for firmware server location will be address: /GDS3710/. The combo box above provides the protocol part.

The GDS3710 updater will retrieve the version file from this directory and check the content with the version data compiled into the firmware. If the versions differ, it will download the updated versions. The poll interval is set as configuration data. Set it to hourly (60) for the initial update. After the update, the poll interval will revert to weekly.

Do read the release notes and follow the reset and restart instructions in the release notes. Some will require a full reset. Others will let you retain card and network settings. You’ll need to reset logging which will be empty and updating will default back to Grandstream.

Changing the password

Grandstream issues shortish pseudo-random admin passwords to each device. The password is on a sticker on the back of the device.

Before a new password can be set, a password recovery Email must be set and tested. If you have a SMTP server within the lifelines, you may use it. If not, you can use your regular domain Email. For Google or Apple hosted Email, you must use an APP password tied to the device just like you do for your desktop and mobile mail readers.

To recover the password, Grandstream will send an Email with a link to a landing page that allows you to set a new password. The link is good for 30 minutes or so. I don’t recall if the time to live can be adjusted.

Debug Log

The GDS3710 speaks syslog. I used syslog-ng on the same Raspberry Pi that was my firmware server. This puppy serves as log host for the router and phones both. I set mine up with separate ports for the router traffic and phone traffic and separate destinations in /var/log. Syslog is not open to the outside world so no authentication is required.

Phone Vendor Specifics

OnSip, our phone service provider, does not have organic support for the GDS3710 (no provisioning or firmware updates) but it works well.

If your Sip PBX provider does not support the phone in its provisioning and firmware databases, you’ll need to do the following

Leave your phone’s provisioning server set to the value included in the firmware data segment. Don’t trust the manuals or web articles.
Set up your own firmware update server as described above. Configure the firmware update to reference it.

Network Issues

We ran into two known to OnSip.

Routers have a behavior called “SIP ALG” that attempts to make it easier for SIP to work in a single IP address with NAT. This feature works poorly and must be disabled.

Routers have a behavior to assist with H.323 call setup of teleconference calls. This behavior must be disabled.

Be sure ports 80 and 443 are closed from outside at the firewall and open in the protected area. Closing at the access router prevents attacks.

SIP and RTP are designed to work with all connections originating from inside the protected area. No open ports are required.

Sip.OnSip.com serves as SIP proxy for our system. If you don’t have a SIP server inside the lifelines, you will be using your vendor’s proxy.

Completion of SIP basic parameters closely follow the OnSip user parameter naming. Account name and domain name are the same for OnSip clients.

Further Work

At this point, I have integration with the GXV3275 phones to complete (touch to unlock) and entry of RFID cards/FOBS to complete. GXV integration requires some specific setup of both devices. FOB/Card entry and log reading happens via the GUI but GDS Manager, designed for large deployments, may also be used. GDS Manager is free (except for the setup effort). I may have the 3 devices push door event records to my local NGINX server. This appears to be optional.