Getting Monocle working with Alexa with Service

hugh

I am new to using Monocle and hoped some one could help me get it working. I have a number of different camera all IP some Hikvision and some ANPVIZ and a few more including QVIS and Sricam. So far I haven’t managed to get any of them working with Alexa except for one through EZVIZ skill. I hoped Monocle would allow me to connect at least some of the others but so far I have failed to get it working. I have installed Moncole gateway on a Windows 10 pc and have Alexa running on Windows 11 in show mode which I wondered whether that was the problem? Although it shows the EZVIZ skill camera. The cameras work on VLC but don’t work with Alexa which shows the devices but if you click on them they produce the error “Make sure that your camera is on and connected to the network, then try again.” I have tried a number of tags starting with @tunnel but also tried the @noaudio and the @proxy. I can telnet to the machine running the Moncole service and the command window shows the following when I try to connect which to my eye looks ok. I can telnet through to the service machine from the pc running Alexa without a problem. The res and the other settings match against what VLC said it was receiving
Is there any other debugging I can do that will help trace the problem?

        __  __  ___  _  _  ___   ___ _    ___              *

       |  \/  |/ _ \| \| |/ _ \ / __| |  | __|             *

       | |\/| | (_) | .` | (_) | (__| |__| _|              *

       |_|  |_|\___/|_|\_|\___/ \___|____|___|             *

MONOCLE RUNTIME ENVIRONMENT

VERSION = 0.0.4
OS/ARCH = win32\x64
PROCESS = monocle-gateway (PID=3324)
TIMESTAMP = 2021-11-17T16:08:28.346Z

MONOCLE GATEWAY SERVICE (Version: 0.0.4)

[Monocle Starting]
[Monocle Connecting]
[Monocle Started]
[RTSP Server Starting]
[RTSP Server Listening] 0.0.0.0:8555 (RTSP)
[RTSP Server Listening] 0.0.0.0:443 (RTSP-TLS)
[RTSP Proxy Started] (PID=14384)
[RTSP Server Listening] 0.0.0.0:8554 (PROXY)
[RTSP Server Started]
[Monocle Connected]
[RTSP Server Registered]

MONOCLE RTSP SERVICE - INITIALIZED

FQDN = {removed for security}.mproxy.io
HOST = {removed for security}
PORT = 443

INITIALIZE RTSP STREAM: Cam 1

NAME : Cam 1
LABEL : PRIMARY
URL : rtsp://{removed for security}:554/Streaming/Channels/102
UUID : STREAM:{removed for security}
SESS : {removed for security}
MODIF : Tue Nov 16 2021 20:57:33 GMT+0000 (GMT Standard Time)
TAGS : @tunnel

Blenky

I have been having a very similar issue with my Hikvision cameras. I could get them working and then it would lose the connection. You can see my attempts in this thread. https://ipcamtalk.com/threads/hikvision-unable-to-keep-stream-running-with-alexa-show-8.59950/

Some thing to try:

- make sure Alexa is on WIFI 5.0 and not 2.4.
- make sure you are using the IP for your NVR and not the IP for the camera. The Channels/102 you are using is for camera 1 on substream 2.
You can also add @proxy-tcp and also try @noaudio to see if the audio is causing the issue.

Your IP’s do not need to be blocked out as they are private to you only and of no use to anyone else. Mine NVR is rtsp:/192.168.2.25:554/Streaming/Channels/101 for camera 1 on the main stream. I can get it to work occasionally but it will not stay on and then I need to run the monocle-gateway.exe in a cmd window to get it to work again.

It can be very frustrating and the Monocle group support seems to be non existent.

hugh

thanks @Blenky I will try some of those things you have mentioned. My Alexa is indirectly on cable not WIFI at all as it is running on a networked PC through Windows 11 (from the Microsoft APP store) which I did not see mentioned in supported or unsupported devices. But it does seem to allow playing of other CCTV sources not through Monocle.

jshimota

That was a rough morning . All my camera feeds were down. I use the external MonocleCam gateway/portal/proxy and this AM none of my camera’s were showing on Alexa.
If you read any of my previous posts - my setup is BlueIris server with 6 cameras including PTZ, Onvif and no-name. I’ve had problems with NEW amazon devices (the Gen 3 10" Show NEVER worked and I sent it back.)
On my Echo Show 5", 8" and 10" displays, all cameras have always worked. When I saw the post this AM about Monocle being down - I checked my own cameras and - all were down.
I do development work for Home Automation on Hubitat - drivers etc and I integrate my feeds onto dashboards using the setup I just mentioned. There have been a lot of posting about Amazon redoing code and breaking things this last week.
It seems to have settled down - and I do not know much about what was changed so please don’t ask - my last debug venture which found problems with the new Fire OS - I never got Amazon to do sh*t about the problems I found on their end.
All that said - the solution this AM was easy - I deleted all my Cameras from Alexa (use your phone app, devices and Remove button) then had Alexa do a Discovery. All cameras found and all worked - again.
I use BlueIris for transcoding of non-standard streams to usable streams for Alexa - if you’re having problems with Camera setups and have never got them running previously - be sure to check the Help posting about new setups. If you’re an existing user and things are broke… double check things, then rediscover.

jshimota

@jshimota Okay. I lied.

I was adding another camera after what I thought was fixing my Alexa stream this AM - and determined I had been bypassing the Alexa when I tied dashboard tiles to the RTSP stream.

When I actually got off my butt and told Alexa Show in my kitchen to display the feed - it wasn’t displayed. All the camera’s are down. I do see Alexa changing the calls when I adjust the Monoclecam.com cameras but nothing I do is getting a display. VLC tests good, ONVif cam streams are normal and everything looks correct and unplayed with.

Researching further, it is possible I’ve found the latest problem which I think would affect just about everyone.
This AM, while reading the Amazon tech specs on RTSP integration - I stumbled over this:
Prerequisites and SLA requirements

Low latency is critical to an optimal user experience. To use the CameraStreamController API, you need the following:

RTSP + RTP streaming protocol.
Interleaved TCP on port 443 (for both RTP and RTSP).
TCP socket encryption on port 443 using TLS 1.2.
The RTSP commands DESCRIBE, SETUP, PLAY, and TEARDOWN are required, although we recommend a full RFC compliant implementation.

All RTSP URI responses must occur within six seconds from when the request is received.

443??!? so it has to use secure socket now? SH*T on a shingle. Thankfully I’m on BlueIris and can use an HTTPS port fairly easily but now I have to re-arrange some served ports, change BI, change my strings AND test. If I find I solve my own problem - I’ll post back.

chriskooken

I can confirm this is broken for me too. This integration has been working for years with Unifi cameras and within the last few days, nothing works. It looks like amazon now requires RTSPS Streams, but I still can’t even get that to work when I update the streams in the Monocle portal to RTSPS. What am I missing?

chriskooken

looks like their Proxy Server is down:
https://stats.monoclecam.com/

Does anyone know how to contact them? They must not know that it is down.

jshimota

@chriskooken I am by no means an expert - but rtsp (s)… is that a thing now? I realize we say ‘https’ for an ssl http and we’re talking about rtsp with ssl (but in this case it’s tls which is a different beast in the same forest). I guess I’ll begin referring to rtsp secured as rtsps in the future.

back to the problem at hand - the proxy down - I suspect it’s not down but broken by the changes by Amazon - thats just mho. Regardless, is you D/L the standalone version of the Gateway it has a proxy that comes with it. I tested for a few hours yesterday and was unable to definitively determine where the problem comes from. Error logs state I’m getting a started RTSP stream then it dies and I truly have no idea why.
I’ve fired up the old STunnel and rebuilt my firewalls/forwards and the BI configuration. I really don’t want to run NGrok ugh.
I have heard (and maybe someones got a rPI laying around?) that using a redirect from an rPI works better - something about the implementation of TLS1.2?
Honestly, ever since Microsoft started killing TLS 1.1 last year - I’ve been fighting hard to maintain some older tools. Theres a workaround on the TLS 1.1 so I can still keep running my Outlook 2010 but you’ve gotta manage it up on 0365 which is a nightmare! sorry. off topic.
I’m going to try more today to see if I can break this logjam but it doesn’t look good with the tools we have. Has anyone posted or checked on BI forums or IPCamTalk about the issue? Any other useful comments? Monocle is going to be blamed for this and honestly, I don’t think its his fault.

jshimota

that link you sent @chriskooken - I’d never seen it before, but if I hover over the last bar it is no show a percentage and the ‘operational’ is on so it seems up… do you think so?

Running a local gateway and proxy (NOT using stunnel) I see this:

RTSP STREAM MODIFIED: Backyard
Any existing RTSP steams will be shut down
and a new stream instance will be registered.

2021-11-19T19:30:10.473Z [DEBUG] <RTSP-PROXY> [REQUEST] --> [DEREGISTER] rtsp://192.168.1.125:554/Backyard
2021-11-19T19:30:10.474Z [TRACE] <RTSP-PROXY> [REQUEST] --> [HEADERS] {“cseq”: “1”,“transport”: “reuse_connection=0;preferred_delivery_protocol=udp;proxy_url_suffix=STREAM:ffe31e37-8ab1-4a3c-b2e9-220df5f1a6a7”}
2021-11-19T19:30:10.475Z [DEBUG] <RTSP-PROXY> [RESPONSE] <-- [451 (Invalid parameter)] <cseq=1> (session=undefined)
2021-11-19T19:30:10.475Z [TRACE] <RTSP-PROXY> [RESPONSE] <-- [HEADERS] { “cseq”: “1”, “date”: “Fri, Nov 19 2021 19:30:10 GMT”}
So my interpretation is that we indeed are seeing something new at the Proxy - that’s the dead spot. session=undefined… no stream is established so there isn’t yet a session - maybe this is a tls 1.1 to tls 1.2 issue? I’ve no idea!

chriskooken

I was able to find the developer and I reached out to him directly. He fixed the proxy server and all my cameras are working again.

Monocle

@jshimota said in Getting Monocle working with Alexa with Service:

ave heard (and maybe someones got a rPI laying around?) that using a redirect from an rPI works better - something about the implementation of TLS1.2?
Honestly, ever since Microsoft started killing TLS 1.1 last year - I’ve been fighting hard to maintain some older tools. Theres a workaround on the TLS 1.1 so I can still keep running my Outlook 2010 but you’ve gotta manage it up on 0365 which is a nightmare! sorry. off topic.
I’m going to try more today to see if I can break this lo

Well, the Monocle proxy was down … (an issue on our end -> https://stats.monoclecam.com/782085767) but its back up now.
Are your systems working now or still having issues?

Thanks, Robert

hugh

I have tried most things suggested and I am still having problems so I am guessing that Alexa running on Windows for what ever reason is not supported and is not quit the same as having a full physical Alexa Show device in some way. I am at the moment trying other methods to get round the problem involving using ISPY with the Agent.

Monocle

@chriskooken said in Getting Monocle working with Alexa with Service:

I can confirm this is broken for me too. This integration has been working for years with Unifi cameras and within the last few days, nothing works. It looks like amazon now requires RTSPS Streams, but I still can’t even get that to work when I update the streams in the Monocle portal to RTSPS. What am I missing?

For clarity, the Monocle Proxy server and Monocle Gateway both use different methods to attempt to satisfy the TLS/HTTPS/SSL requirements by Amazon. Many IP camera’s don’t support a SSL certificate and that various other secure requirements imposed by Amazon. So we attempt to satisfy these requirements such that Monocle users don’t have to overcome these complicated setups.
In some cases, the Monocle Proxy server may not be enough and a local Monocle Gateway server must be used.

Thanks, Robert

Monocle

@jshimota said in Getting Monocle working with Alexa with Service:

…
Researching further, it is possible I’ve found the latest problem which I think would affect just about everyone.
This AM, while reading the Amazon tech specs on RTSP integration - I stumbled over this:
Prerequisites and SLA requirements

Low latency is critical to an optimal user experience. To use the CameraStreamController API, you need the following:
RTSP + RTP streaming protocol.
Interleaved TCP on port 443 (for both RTP and RTSP).
TCP socket encryption on port 443 using TLS 1.2.
The RTSP commands DESCRIBE, SETUP, PLAY, and TEARDOWN are required, although we recommend a full RFC compliant implementation.

All RTSP URI responses must occur within six seconds from when the request is received.
443??!? so it has to use secure socket now? SH*T on a shingle. Thankfully I’m on BlueIris and can use an HTTPS port fairly easily but now I have to re-arrange some served ports, change BI, change my strings AND test. If I find I solve my own problem - I’ll post back.

So these requirements have been in place for several years now and yes they are somewhat stupid and unnecessarily complicated for local network camera streams. In summary the following is required by Alexa/FireTV devices:

Only stream on port 443
Must use TLS (1.2) encrypted communication (Interleaved RTSP)
Must have a valid SSL certificate (no self-signed certificates allowed)
Must connect to camera via a public DNS hostname/URL. (won’t connect via direct IP address or locally resolvable private DNS.)
Fully RFC compliant RTSP camera. (The @proxy tag in Monocle Gateway may help satisfy this condition for certain cameras.)

So the Monocle Proxy server and Monocle Gateway are two distinct and different approaches to helping satisfy these conditions. If you use either tag @proxy or @tunnel then your local instance of Monocle Gateway is used. If no tags, then the Monocle Proxy method is used.

The Monocle Proxy was the first method we implemented when we rolled out the Monocle solution and it worked fine on most Amazon devices at the time. However as newer Amazon Echo Show devices and FireTV devices have been released, Amazon has further tightened the security requirements and now select Amazon devices may only work with Monocle Gateway.

So in either solution you should not have to implement the TLS / SSL certs or port 443 on your cameras directly. Monocle should be handling this part for you. If using Monocle Gateway, then you instance must serve on port 443 but it internally handles all the TLS and DNS requirements.

Hopefully this helps shed some light on how things should be working together. PM me if you want a more technical discussion.

Thanks, Robert

Monocle

@hugh said in Getting Monocle working with Alexa with Service:

I have tried most things suggested and I am still having problems so I am guessing that Alexa running on Windows for what ever reason is not supported and is not quit the same as having a full physical Alexa Show device in some way. I am at the moment trying other methods to get round the problem involving using ISPY with the Agent.

I tried this on Windows a few years ago and never had any luck. I have successfully tested on Amazon Show devices, FireTV devices, FireTV editions (the physical TVs not just the STBs) and Fire Tablets.

Thanks, Robert

hugh

Thanks, I will try again if we ever get one of the physical devices. Hugh

Getting Monocle working with Alexa with Service

MONOCLE RUNTIME ENVIRONMENT

MONOCLE GATEWAY SERVICE (Version: 0.0.4)

MONOCLE RTSP SERVICE - INITIALIZED

FQDN = {removed for security}.mproxy.io HOST = {removed for security} PORT = 443

INITIALIZE RTSP STREAM: Cam 1

Running a local gateway and proxy (NOT using stunnel) I see this:

RTSP STREAM MODIFIED: Backyard Any existing RTSP steams will be shut down and a new stream instance will be registered.

FQDN = {removed for security}.mproxy.io
HOST = {removed for security}
PORT = 443

RTSP STREAM MODIFIED: Backyard
Any existing RTSP steams will be shut down
and a new stream instance will be registered.