Foscam R2 with Lenovo Smart Tab [SOLVED]
-
@Monocle Thanks for providing that context and detail.
When i tested again today, i do see the Demo Direct feed now!!!
[ { "timestamp": "2020-01-21T22:38:39.607Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://demo.mproxy.io:443/test", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] },
So this indicates that indeed the Alexa on Lenovo Smart Tab actually works. How do we test it through the proxy?
-
I tested the Demo Direct Feed with and without the “@noproxy” tags.
- It does indeed work with the “@noproxy”
- It does NOT work with blank tags section
-
Here is my Demo Direct Feed, Can you validate that i have this configured correctly. Note the port change and tag, everything else should be the same
This one going through the proxy with @proxy-tcp tag shows this:
------------------------------------------------- INITIALIZE RTSP STREAM: Demo Proxy ------------------------------------------------- - NAME : Demo Proxy - MAKE : Monocle - MODEL : Demo - LABEL : PRIMARY - URL : rtsp://demo.mproxy.io:554/test - UUID : STREAM:b10829c1-f61c-4f67-a30f-dc3dd578d447 - SESS : f3915c4d-2a2c-4325-9ba6-d5738a36875c - MODIF : Tue Jan 21 2020 14:40:28 GMT-0800 (Pacific Standard Time) - TAGS : @proxy-tcp ------------------------------------------------- 2020-01-21T22:43:03.664Z [INFO] [RTSP PROXY] REGISTERING STREAM [Demo Proxy/PRIMARY]; (STREAM:b10829c1-f61c-4f67-a30f-dc3dd578d447) 2020-01-21T22:43:03.674Z [DEBUG] <RTSP-PROXY> [REQUEST] --> [REGISTER] rtsp://demo.mproxy.io:554/test 2020-01-21T22:43:03.675Z [TRACE] <RTSP-PROXY> [REQUEST] --> [HEADERS] { "cseq": "1", "transport": "reuse_connection=0;preferred_delivery_protocol=interleaved;proxy_url_suffix=STREAM:b10829c1-f61c-4f67-a30f-dc3dd578d447" } 2020-01-21T22:43:03.677Z [DEBUG] <RTSP-PROXY> [RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined) 2020-01-21T22:43:03.677Z [TRACE] <RTSP-PROXY> [RESPONSE] <-- [HEADERS] { "cseq": "1", "date": "Tue, Jan 21 2020 22:43:03 GMT" } 2020-01-21T22:43:10.654Z [INFO] [RTSP PROXY] STREAM [Demo Proxy/PRIMARY] WILL BE DE-REGISTERED IN 4 MINUTES 2020-01-21T22:44:10.653Z [INFO] [RTSP PROXY] STREAM [Demo Proxy/PRIMARY] WILL BE DE-REGISTERED IN 3 MINUTES 2020-01-21T22:45:10.654Z [INFO] [RTSP PROXY] STREAM [Demo Proxy/PRIMARY] WILL BE DE-REGISTERED IN 2 MINUTES 2020-01-21T22:46:10.653Z [INFO] [RTSP PROXY] STREAM [Demo Proxy/PRIMARY] WILL BE DE-REGISTERED IN 1 MINUTES 2020-01-21T22:47:10.654Z [INFO] [RTSP PROXY] DE-REGISTERING STREAM [Demo Proxy/PRIMARY]; NO LONGER IN USE 2020-01-21T22:47:10.658Z [DEBUG] <RTSP-PROXY> [REQUEST] --> [DEREGISTER] rtsp://demo.mproxy.io:554/test 2020-01-21T22:47:10.659Z [TRACE] <RTSP-PROXY> [REQUEST] --> [HEADERS] { "cseq": "1", "transport": "reuse_connection=0;preferred_delivery_protocol=interleaved;proxy_url_suffix=STREAM:b10829c1-f61c-4f67-a30f-dc3dd578d447" } 2020-01-21T22:47:10.659Z [DEBUG] <RTSP-PROXY> [RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined) 2020-01-21T22:47:10.659Z [TRACE] <RTSP-PROXY> [RESPONSE] <-- [HEADERS] { "cseq": "1", "date": "Tue, Jan 21 2020 22:47:10 GMT" }
Here is the corresponding logs from Monocle WebUI
[ { "timestamp": "2020-01-21T22:43:03.709Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://demo.mproxy.io:554/test", "proxy": "rtsp://46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io:443/STREAM:b10829c1-f61c-4f67-a30f-dc3dd578d447?session=f3915c4d-2a2c-4325-9ba6-d5738a36875c", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] },
-
Can you revert back to the URL
rtsp://demo.mproxy.io:443/test
and test again both with and without the@noproxy
tag. I’m just trying to isolate the issue and make sure we are working on the exact breakdown.If it’s absolutely working with tag
@noproxy
and definitely not working with no tags, then that points to a new issue we have never seen before. But it’s a clue and possibly we can move to the next diagnostics step once this is confirmed.Thanks, Robert
-
After confirming the steps above in my last post, you can move forward and try RTSP URL:
rtsp://demo.mproxy.io:554/test
and include both of the following tags:@noproxy, @tunnel
and lets see if anything new shows up in the gateway log.If the key to getting this working is the tag
@noproxy
, then I suspect I know what the issue is. Tag@noproxy
tells our servers NOT to use a RTSP REDIRECT. In fact, I should change it to@noredirect
to avoid confusion because the word “proxy” in this case means something different than the @proxy used with the gateway. This issue has never come up before and we have never shared this tag for use until now. By default we use a RTSP redirection stage as this was the original working implementation method before Amazon started implementing stricter and stricter access policies.Thanks, Robert
-
Yes, i have 2 demo cameras in my configuration
The Direct one that isn’t using the gateway is the first camera that i have gotten to work at all. I am 100% positive that it is working using the @noproxy and as soon as i remove that it stops working
-
I will configure Demo Proxy with @noproxy, @tunnel and see what happens
-
So i tried Demo Proxy (should rename that to Demo Gateway)
I tried with a combination of
- @noproxy, @tunnel
- @noproxy, @proxy
- @noproxy, @proxy-tcp
Interestingly enough i didn’t get anything in the monocle gateway logs
I read a note somewhere that said the demo stream only works with proxy-tcp and not proxy or tunnel tags
for all 3 Alexa attempts to load the stream and then says “Sorry, Something Went Wrong”
-
OK, take a look in your Camera Feed History and lets make sure that the Alexa InitializeCameraStreams response is pointing directly to your gateway DNS hostname and not our redirection server. Just post the response here and I’'l review it.
Thanks, Robert
-
Again thank you so much for working with me on this. I am willing to do whatever it takes to make this work…
I tried those tags with my legit cameras (Foscam and Amcrest) with (@noproxy, @tunnel )
I get “Sorry, Something Went Wrong”
-
No problem, let just stick with
@noproxy, @tunnel
tags on “Demo Proxy” for the time being. Even if it does not result in the demo camera working, it keeps things simpler for now – the first goal is just to see TCP connections from the tablet in the Monocle Gateway log after an Initialize Camera stream.Thanks, Robert
-
Here is Demo Proxy
[ { "timestamp": "2020-01-22T00:34:47.422Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://demo.mproxy.io:554/test", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] }, { "timestamp": "2020-01-22T00:32:42.267Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://demo.mproxy.io:554/test", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] }, { "timestamp": "2020-01-22T00:31:41.481Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://demo.mproxy.io:554/test", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] }, {
I did 3 attempts with the @noproxy as listed above, all 3 show that it is indeed using the direct URL instead of the redirect URL.
Okay, i hear you about the @tunnel, @noproxy… i will leave it like that from now on
-
Here it is with
Here is the WebUI log
[ { "timestamp": "2020-01-22T00:52:50.078Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://demo.mproxy.io:554/test", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] },
This time she said “Im not sure what went wrong”
-
Note that it did not show the initial Loading Demo Proxy screen that i am used to seeing
-
OK, so looking more in-depth, I was wrong, the tag
@noproxy
should not be included. It looks like when using the@tunnel
or@proxy
(or@proxy-tcp
) tags we skip that redirection step anyways.So just include
@tunnel
only and then what I would expect is additional lines in the gateway log like this example:------------------------------------------------- INITIALIZE RTSP STREAM: Demo ------------------------------------------------- - NAME : Demo - MAKE : Monocle - MODEL : Demo - LABEL : PRIMARY - URL : rtsp://demo.mproxy.io:554/test - UUID : STREAM:86f988fe-1293-43c6-90c6-43d880e78103 - SESS : 92dfd8ac-8b4b-4430-8545-3de0fb1e551c - MODIF : Tue Jan 21 2020 20:08:57 GMT-0500 (Eastern Standard Time) - TAGS : @tunnel ------------------------------------------------- 2020-01-22T01:09:04.887Z [INFO] [10.1.2.90:51902 <ryt2x7rZI>] RTSP CLIENT SOCKET CONNECTED 2020-01-22T01:09:05.015Z [INFO] [10.1.2.90:51902 <ryt2x7rZI>] RTSP CLIENT ATTACHED TO STREAM: Demo (STREAM:86f988fe-1293-43c6-90c6-43d880e78103) 2020-01-22T01:09:05.088Z [INFO] [10.1.2.90:51902 <ryt2x7rZI>] RTSP ENDPOINT SOCKET CONNECTED {demo.mproxy.io:554} 2020-01-22T01:09:05.089Z [DEBUG] [10.1.2.90:51902 <ryt2x7rZI>] [CLIENT REQUEST] --> [DESCRIBE] rtsp://fb78694e-95a9-4e5f-8708-787c6bc33067.mproxy.io:443/STREAM:86f988fe-1293-43c6-90c6-43d880e78103?session=92dfd8ac-8b4b-4430-8545-3de0fb1e551c 2020-01-22T01:09:05.089Z [TRACE] [10.1.2.90:51902 <ryt2x7rZI>] [CLIENT REQUEST] --> [HEADERS] { "accept": "application/sdp", "user-agent": "Fire OS/6.0 stagefright/1.2 (Linux;Android 7.1.2)", "cseq": "1" } 2020-01-22T01:09:05.091Z [DEBUG] [10.1.2.90:51902 <ryt2x7rZI>] [ENDPOINT REQUEST] --> [DESCRIBE] rtsp://demo.mproxy.io:554/test 2020-01-22T01:09:05.091Z [TRACE] [10.1.2.90:51902 <ryt2x7rZI>] [ENDPOINT REQUEST] --> [HEADERS] { "accept": "application/sdp", "user-agent": "Fire OS/6.0 stagefright/1.2 (Linux;Android 7.1.2)", "cseq": "1" } 2020-01-22T01:09:05.183Z [DEBUG] [10.1.2.90:51902 <ryt2x7rZI>] [ENDPOINT RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined) 2020-01-22T01:09:05.183Z [TRACE] [10.1.2.90:51902 <ryt2x7rZI>] [ENDPOINT RESPONSE] <-- [HEADERS] { "cseq": "1", "date": "Wed, 22 Jan 2020 01:09:05 GMT", "content-base": "rtsp://demo.mproxy.io:554/test/", "content-type": "application/sdp", "content-length": "294" }
In this example, you can see the RTSP CLIENT SOCKET CONNECTED message from my Alexa device inside my network. (10.1.2.90 in my case)
Thanks, Robert
-
Okay
Demo Proxy
Log from gateway
****************************************************************** * __ __ ___ _ _ ___ ___ _ ___ * * | \/ |/ _ \| \| |/ _ \ / __| | | __| * * | |\/| | (_) | .` | (_) | (__| |__| _| * * |_| |_|\___/|_|\_|\___/ \___|____|___| * * * ****************************************************************** ------------------------------------------------- MONOCLE RUNTIME ENVIRONMENT ------------------------------------------------- VERSION = 0.0.4-3 OS/ARCH = win32\x64 PROCESS = monocle-gateway (PID=27404) TIMESTAMP = 2020-01-22T00:30:45.429Z ------------------------------------------------- MONOCLE GATEWAY SERVICE (Version: 0.0.4-3) ------------------------------------------------- [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=7852) [RTSP Server Listening] 0.0.0.0:8554 (PROXY) [RTSP Server Started] [Monocle Connected] [RTSP Server Registered] ------------------------------------------------- MONOCLE RTSP SERVICE - INITIALIZED ------------------------------------------------- FQDN = 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io HOST = 192.168.1.26 PORT = 443 ------------------------------------------------- ------------------------------------------------- INITIALIZE RTSP STREAM: Demo Proxy ------------------------------------------------- - NAME : Demo Proxy - MAKE : Monocle - MODEL : Demo - LABEL : PRIMARY - URL : rtsp://demo.mproxy.io:554/test - UUID : STREAM:b10829c1-f61c-4f67-a30f-dc3dd578d447 - SESS : bab0a510-777d-4b99-a1a9-a67023c700c5 - MODIF : Tue Jan 21 2020 17:15:09 GMT-0800 (Pacific Standard Time) - TAGS : @tunnel -------------------------------------------------
Log from WebUI
[ { "timestamp": "2020-01-22T01:16:08.814Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://demo.mproxy.io:554/test", "proxy": "rtsp://46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io:443/STREAM:b10829c1-f61c-4f67-a30f-dc3dd578d447?session=bab0a510-777d-4b99-a1a9-a67023c700c5", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] }, {
Alexa shows Camera Loading Screen and then about 10 seconds later it says “Camera Doesn’t Support That”
-
So it’s certainly acting like the tablet is not able to establish the RTSP connection to the gateway.
I know we have already checked the DNS, SSL cert, IP address, access to port 443, etc. So I think we know that a connection is not getting blocked by the typical actors.
Amazon does not provide us any details on how to further diagnose Alexa camera connection related issues on the Alexa hardware side. It’s just a black box to us.
I think some network packet sniffing might be in order to try and determine if the Alexa device is trying to connect to the gateway. This seems to be where we are stuck once again. Tracing outbound requests from the tablet device should reveal TCP attempts on port 443 to the gateway.
-Robert
-
Sure i can try to set something up with some guidance, i have used them in the past but i might need a little direction on setting it up. I mainly have windows on the network but may be able to setup something on one of the Raspberry PI3 i have.
Also the lenovo show is an android OS so im not sure if there is an android packet sniffer that can be installed directly on it. It isn’t rooted which may be necessary. I will do a little research unless you have some specific guidance.
Question: do you think its worth replacing my firewall. I have an older netgear that i have used in the past that i can try swapping out the USG with.
-
You might look into the USG and see if it supports any packet sniffing capabilities. I use a PFSense router and it does have support for traffic sniffing (with additional packages installed).
It’s hard to say if swapping out the router would make any difference … we really don’t know where the problem lies just yet.
Thanks, Robert
-
Im haven’t had a chance to analyze it yet, but essentially i installed a android packet capture on the Lenovo Smart Tab, started a packet capture and asked Alexa to show Demo Proxy
https://1drv.ms/u/s!AsWlCkfB-HIupUPka7vauYNhVbMl?e=e5Wctf
See if this link works for you. File is 1.2mb