Freeze the first failed boundary
Record the exact GDS3712, firmware, power source, address, VLAN, SIP topology, account or peer, called destination, receiving endpoint and version, observation time and physical door wiring. Preserve whether the doorbell press produced no call, audio only, blank video, a missing OpenDoor control, a rejected unlock, relay activity without opening or an opening without correct door-state feedback.
Do not reset, factory-default, rewire or expose the device before capturing its status, call evidence, event logs and configuration ownership. One symptom can have multiple downstream effects; start with the earliest missing transition.
Prove power, network and the SIP call leg first
Confirm stable approved power, link, address, route, time and intended management reachability. Then follow the doorbell action through INVITE, PBX or direct peer, destination, response, answer and two-way audio. A web login or camera stream does not prove SIP routing, while an answered call does not prove the video or unlock path.
Keep direct IP peering separate from registered PBX service. Correct only the first demonstrated address, VLAN, firewall, account, route, certificate or endpoint fault; do not broaden inbound access or disable security controls as a diagnostic shortcut.
Trace the exact video path and receiving capability
Capture the SIP and SDP offer and answer, negotiated codec and media addresses, then verify whether the endpoint expects SIP video, JPEG integration, a surveillance stream or a management preview. Grandstream's GRP guide lists some models as audio only and others as supporting JPEG video, and separately records an MJPEG limitation when the door station is added through UCM Remote Connect.
Test the documented combination actually deployed. Do not infer camera failure from an audio-only receiving phone, and do not infer successful SIP video from a working local or ONVIF view.
Follow unlock request, relay, lock and input separately
Determine whether the endpoint sent the documented SIP-message OpenDoor request or the in-call DTMF remote PIN and whether the GDS accepted it for the intended door. Then observe the selected relay, electrical interface, lock power, unlock timer and physical opening. A relay click without movement points beyond SIP; no relay action keeps the investigation at authorization, message, DTMF or device configuration.
Verify request-to-exit and door-sensor inputs against the intended normally open or normally closed state and schedule. Preserve safe egress and emergency-release design; do not bypass a controller or energize a lock outside its documented circuit to make the test pass.
Correlate events, repair one boundary and retest
Use local logs and the configured HTTP or HTTPS receiver to correlate doorbell, SIP, unlock and input events by device and time. A notification connection test or one received event does not establish complete delivery, correct order or physical outcome. Preserve receiver authentication, clock and retention evidence.
Repair only the first proven power, network, SIP, endpoint-video, control-message, relay, lock, input or event boundary. Repeat communication and physical-door acceptance separately. No device, PBX, endpoint, camera, recorder, relay, lock, sensor, credential, event receiver, packet, media stream or live call was inspected or tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Grandstream GDS3712 product page ↗
- Grandstream GDS3712 datasheet ↗
- Grandstream GDS3710/GDS3712 user manual ↗
- Grandstream GDS3712 quick installation guide ↗
- Grandstream GDS37xx and GRP26xx integration guide ↗
- Grandstream GDS37xx digital input configuration ↗
- Grandstream GDS37xx event logs guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.