Update 2 — Solved the DNS Error, but still no Inbound Alexa Connection (Properties Override Active)
Hello again,
We have made significant progress on the Windows PC troubleshooting instance and isolated exactly how the gateway handles (and mishandles) settings. Here is the latest diagnostic data:
1. DNS ENODATA Error Resolved:
The DNS RESOLVE ERROR: queryA ENODATA on the FRITZ!Box was successfully resolved. The router was strictly blocking the dynamically generated *.mproxy.io subdomains via its DNS Rebind Protection. Adding the root domain mproxy.io as an exception in the FRITZ!Box configuration immediately cleared the error.
2. Properties Override Implemented:
We discovered that the Windows gateway executable does not accept command-line arguments (throwing Unsupported command argument(s) for --port or --register). To bypass this and ensure exact binding, we successfully deployed a local monocle.properties file inside the %USERPROFILE%.monocle\ directory. The gateway now successfully initializes with the following explicit overrides:
• rtsp.host=192.168.1.5
• rtsp.ssl.port=443
• rtsp.register.host=192.168.1.5
3. Camera Stream Optimization (Axis Specific):
To ensure absolute Alexa compatibility, the Axis P3245-LVE stream profile has been strictly optimized directly on the camera’s web interface:
• Video Codec: H.264 (Strict Baseline/Main profile, Zipstream completely disabled).
• Resolution: Adjusted to 640x360 (16:9 widescreen profile matching the Monocle portal configuration).
• Frame Rate: Hard-capped at a stable 15 FPS.
• Audio: Completely disabled/stripped from the stream to prevent Alexa from dropping the connection due to unsupported audio codecs.
• Monocle Tags: Switched from @tunnel to @proxy to bypass the deprecated tunneling service.
4. The Remaining Bottleneck:
With the custom properties active, the gateway starts flawlessly, binds to port 443 (LISTENING confirmed via admin netstat), and successfully registers the camera stream directly with a 200 (OK) response from the Axis camera.
However, despite clearing all local firewalls, ensuring the Echo Show 8 is on the main private Wi-Fi network, and forcing a full Alexa Smart Home device rediscovery, the gateway logs still show absolutely zero inbound connection lines when requesting the stream via the Echo Show 8. The window remains completely stagnant at the registration handshake.
Current Targeted Questions based on this state:
• Given that the gateway claims it expects inbound traffic via rtsp://[unique-id].mproxy.io:443/STREAM:[stream-id], is it verified that the Amazon Alexa Cloud infrastructure still considers the *.mproxy.io SSL/TLS root certificates valid, or are Echo devices silently dropping the connection due to expired or untrusted gateway certificates?
• Why does the Windows gateway log show that it successfully registers @proxy, but completely ignores the custom rtsp.register.host=192.168.1.5 setting in the log printout, still insisting on printing the public mproxy.io URL instead of the local IP fallback?
Any guidance on why the Echo Show 8 completely fails to hit the open port 443 on the host PC despite a clean local handshake would be highly appreciated.
