Foscam R2 with Lenovo Smart Tab [SOLVED]
-
Thanks for the log info … it is showing that the Alexa device is not connecting to the Monocle Gateway. Let’s just use the
@tunnelexample since its the simplest … immediately after the “INITIALIZE RTSP STREAM: Upstairs Bedroom” section in the log we should start seeing RTSP (TCP socket) connections from the Alexa device. After that connection is established, then the gateway will initiate a separate connection to the IP camera and then a bunch of RTSP negotiation will get logged followed by a working stream if everything goes right. So in this case, we are not seeing the initial connection from the Alexa device to start the whole process.This could be a couple of different issues, but it’s almost certainly network related.
I’m guessing the answer is YES, but I’ll ask anyway. Are both the tablet and gateway on the same network? Meaning the tablet is not on some guest network or VLAN?
The most likely culprit is DNS rebinding. You previously testing this and it appeared to be working. When you ran the PING/DNS/SSL tests, did you run them from the same machine the gateway is running on or from another computer? If possible try those tests from a different computer on your same network.
PS. I’ll check the DEMO stream and see if its still working. At a minimum that should work without any trouble. Albeit we have never tested on a Lenovo Smart Tab P10 or any third party device. We have tested it on select Fire tablets.
Thanks, Robert
-
Hi! Thanks again for the response
Yes Both the Lenovo Smart Tab and the gateway are on the same network. I have a flat internal network.I have been suspecting Network as well, although all of my tests have been checking out.
I believe i ran the PING/DNS/SSL from my laptop which is not the gateway. I will run again with more details for you to see:
DNS Rebinding / Ping TestWindows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : localdomain Link-local IPv6 Address . . . . . : fe80::5cd0:630d:e83:b50a%27 IPv4 Address. . . . . . . . . . . : 192.168.1.105 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 Wireless LAN adapter Local Area Connection* 5: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Wireless LAN adapter Local Area Connection* 6: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Wireless LAN adapter Wi-Fi: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : localdomain Ethernet adapter Bluetooth Network Connection 2: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : C:\Users\Ryan>ping 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Pinging 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io [192.168.1.26] with 32 bytes of data: Reply from 192.168.1.26: bytes=32 time<1ms TTL=128 Reply from 192.168.1.26: bytes=32 time<1ms TTL=128 Reply from 192.168.1.26: bytes=32 time<1ms TTL=128 Reply from 192.168.1.26: bytes=32 time<1ms TTL=128 Ping statistics for 192.168.1.26: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0msHere is the SSL test:
c:\Program Files (x86)\GnuWin32\bin>openssl s_client -showcerts -connect 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io:443 Loading 'screen' into random state - done CONNECTED(00000280) depth=1 /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/CN=*.mproxy.io i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 -----BEGIN CERTIFICATE----- MIIFTzCCBDegAwIBAgISBHpaO7am/U6QYocQdyvOiPVgMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTExMjgyMTAyNThaFw0y MDAyMjYyMTAyNThaMBYxFDASBgNVBAMMCyoubXByb3h5LmlvMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwv0unkexb7tcMVASBEjpvS6YUu2oQgJ8d2mU xzLeFfEv/oCTPQqE6nAyBGxetxm/suJpSRlPMjZthaSPubFL/HGdHyvkHrTV8QR6 sHzt2YhCKq4MrqmBrpexsAZ9a3nbyEXUtXtV79imZtKPkvu+d+Dmb36BKva3UB7R RfnwuFxl4Q2e+aCjqOKZlKWuJPNnmlgy7q6ugZ+jF9k4hgSDNfZviAI4k9DZg1VB WwmiZXe2xFbqAYHn+n7Y8BUwkRXw04iYQHdw+AYdQWzd36rEWRQmxZJFTI9Fkm1z chds1kNO/C3Ibr1ar1iOhyoQZuhd3SvoOfP2DObfS2Ge2XGDJwIDAQABo4ICYTCC Al0wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcD AjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBRjYwXLQe3dyi4HLhKFjxZb5ZuzzjAf BgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEFBQcBAQRjMGEw LgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlwdC5vcmcw LwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlwdC5vcmcv MBYGA1UdEQQPMA2CCyoubXByb3h5LmlvMEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcG CysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5 cHQub3JnMIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDxAHYA8JWkWfIA0YJAEC0vk4iO rUv+HUfjmeHQNKawqKqOsnMAAAFutAnopgAABAMARzBFAiEA8X6V15QoliGDhmRZ l/8G+HaUSWWGIrwEY1ZeW8s0o48CIG3K+zvNzkikIYskPND5AU/JXpQbgSspO/iN b/n21AAlAHcAsh4FzIuizYogTodm+Su5iiUgZ2va+nDnsklTLe+LkF4AAAFutAno sgAABAMASDBGAiEA0ylmXOv3gQjNoT8saKbrfYmfpU3IaUG95ZTPhT0gzjsCIQDN lk1sQvKVat/Xns+ebEXAfhKCcGzzwxMUONOH1ucN+DANBgkqhkiG9w0BAQsFAAOC AQEAGMeGfN/CizUsJSDy9vuqeKRlDCaCxd5kVQkEU3wgCpFS5eINorvWT9thcx8V Q4qpFov8R5QOCbqY1+vhbOhNjJrGSQ811weFAvCBbUxklLXIAwXMgcywEO6elyvl EQxo3rdoj68lmChyJPGP/0x5zmsZ/CnK1Ey8ey9QW3CkbolQkFdIJkuT24VMwfkq Rg7vkqOoTyOG9K6fpuwyxZ3xd227pJSXjRBlVOD3gJFcisJApdZsWv1V8e8LCeAy 8+h61albGiVy22yVtNi1zLLWcPOzC8kY/rTGvXlcsI22cxfEVidHsqOnq0R2e7Uo XbeSY32mN1tqz7ioPYpdV0GoCA== -----END CERTIFICATE----- 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 -----BEGIN CERTIFICATE----- MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTE2MDMxNzE2NDA0NloXDTIxMDMxNzE2NDA0Nlow SjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxIzAhBgNVBAMT GkxldCdzIEVuY3J5cHQgQXV0aG9yaXR5IFgzMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAnNMM8FrlLke3cl03g7NoYzDq1zUmGSXhvb418XCSL7e4S0EF q6meNQhY7LEqxGiHC6PjdeTm86dicbp5gWAf15Gan/PQeGdxyGkOlZHP/uaZ6WA8 SMx+yk13EiSdRxta67nsHjcAHJyse6cF6s5K671B5TaYucv9bTyWaN8jKkKQDIZ0 Z8h/pZq4UmEUEz9l6YKHy9v6Dlb2honzhT+Xhq+w3Brvaw2VFn3EK6BlspkENnWA a6xK8xuQSXgvopZPKiAlKQTGdMDQMc2PMTiVFrqoM7hD8bEfwzB/onkxEz0tNvjj /PIzark5McWvxI0NHWQWM6r6hCm21AvA2H3DkwIDAQABo4IBfTCCAXkwEgYDVR0T AQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwfwYIKwYBBQUHAQEEczBxMDIG CCsGAQUFBzABhiZodHRwOi8vaXNyZy50cnVzdGlkLm9jc3AuaWRlbnRydXN0LmNv bTA7BggrBgEFBQcwAoYvaHR0cDovL2FwcHMuaWRlbnRydXN0LmNvbS9yb290cy9k c3Ryb290Y2F4My5wN2MwHwYDVR0jBBgwFoAUxKexpHsscfrb4UuQdf/EFWCFiRAw VAYDVR0gBE0wSzAIBgZngQwBAgEwPwYLKwYBBAGC3xMBAQEwMDAuBggrBgEFBQcC ARYiaHR0cDovL2Nwcy5yb290LXgxLmxldHNlbmNyeXB0Lm9yZzA8BgNVHR8ENTAz MDGgL6AthitodHRwOi8vY3JsLmlkZW50cnVzdC5jb20vRFNUUk9PVENBWDNDUkwu Y3JsMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTANBgkqhkiG9w0BAQsF AAOCAQEA3TPXEfNjWDjdGBX7CVW+dla5cEilaUcne8IkCJLxWh9KEik3JHRRHGJo uM2VcGfl96S8TihRzZvoroed6ti6WqEBmtzw3Wodatg+VyOeph4EYpr/1wXKtx8/ wApIvJSwtmVi4MFU5aMqrSDE6ea73Mj2tcMyo5jMd6jmeWUHK8so/joWUoHOUgwu X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6 KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg== -----END CERTIFICATE----- --- Server certificate subject=/CN=*.mproxy.io issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent --- SSL handshake has read 2702 bytes and written 450 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: ABC576F7659B2F1BA3F52531C1C8AC64D60A35376458195F66CAB7BF2FE5BBA2 Session-ID-ctx: Master-Key: 7836EEA064FE9B40BF7EC15697A4D3A97FF57C56A698EFB8178CE5424C0AD9C6C2F881C3D402C81FA7E40A5DAB922610 Key-Arg : None Start Time: 1579310339 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- closed c:\Program Files (x86)\GnuWin32\bin> -
I noticed a couple others with Ubiquity USG that had issues “Camera Doesn’t Support That”
https://www.ui.com/unifi-routing/usg/But im not sure if they are related.
-
Im not sure its DNS rebinding these tests seem to work out i gleaned from this thread… Its worth investigating the USG config though. Also i am using OpenDNS as the public DNS and i checked the account to make sure it isn’t blocking DNS Rebinding
https://forum.monoclecam.com/topic/153/reolink-camera-wont-show-on-alexa-tv-solved/8
c:\Program Files (x86)\GnuWin32\bin>nslookup 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Server: ubnt Address: 192.168.1.1 Non-authoritative answer: Name: 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Address: 192.168.1.26 c:\Program Files (x86)\GnuWin32\bin>nslookup 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io 8.8.8.8 Server: dns.google Address: 8.8.8.8 Non-authoritative answer: Name: 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Address: 192.168.1.26 c:\Program Files (x86)\GnuWin32\bin> -
Even though the DNS Rebinding tests seem to check out (no mismatch on internal vs external) I tried manually adding the fqdn into the DNS host file and specific file for DNSmasq on the USG following instructions found on some forums.
Since DNS rebinding didn’t seem to the be the issue, i wasn’t able to really test other than asking Alexa to show the camera and look at the logs which show there is no connection attempt
Also thinking it is the firewall, i temporarily created ANY ANY rule effectively allowing all traffic through to the LAN network. Unfortunately nothing seems to make any difference or show at least the connection attempt.
I am thinking a good testing step would be connect to known working camera and known working proxy. If you can check that setup and provide details i will test it out.
------------------------------------------------- RTSP STREAM MODIFIED: Upstairs Bedroom Any existing RTSP steams will be shut down and a new stream instance will be registered. ------------------------------------------------- 2020-01-20T05:50:12.979Z [DEBUG] <RTSP-PROXY> [REQUEST] --> [DEREGISTER] rtsp://192.168.1.205:443/videoSub 2020-01-20T05:50:12.980Z [TRACE] <RTSP-PROXY> [REQUEST] --> [HEADERS] { "cseq": "1", "transport": "reuse_connection=0;preferred_delivery_protocol=udp;proxy_url_suffix=STREAM:43a3e6d3-53a9-48ca-b4fa-2554acae132c" } 2020-01-20T05:50:12.981Z [DEBUG] <RTSP-PROXY> [RESPONSE] <-- [200 (OK)] <cseq=1> (session=undefined) 2020-01-20T05:50:12.981Z [TRACE] <RTSP-PROXY> [RESPONSE] <-- [HEADERS] { "cseq": "1", "date": "Mon, Jan 20 2020 05:50:12 GMT" } ------------------------------------------------- INITIALIZE RTSP STREAM: Upstairs Bedroom ------------------------------------------------- - NAME : Upstairs Bedroom - MAKE : Foscam - MODEL : R2 - LABEL : PRIMARY - URL : rtsp://192.168.1.205:443/videoSub - UUID : STREAM:43a3e6d3-53a9-48ca-b4fa-2554acae132c - SESS : e79d3050-3344-4d6d-a14c-a381ecc582bc - MODIF : Sun Jan 19 2020 21:50:04 GMT-0800 (Pacific Standard Time) - TAGS : @tunnel ------------------------------------------------- -
Some more info this is the gateway server and which ports are listening. I ran the command twice. First run is with monocle gateway started, second one is is with monocle gateway stopped
C:\WINDOWS\system32>netstat -an |find /i "listening" TCP 0.0.0.0:80 0.0.0.0:0 LISTENING TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:443 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:554 0.0.0.0:0 LISTENING TCP 0.0.0.0:1801 0.0.0.0:0 LISTENING TCP 0.0.0.0:2103 0.0.0.0:0 LISTENING TCP 0.0.0.0:2105 0.0.0.0:0 LISTENING TCP 0.0.0.0:2107 0.0.0.0:0 LISTENING TCP 0.0.0.0:2869 0.0.0.0:0 LISTENING TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING TCP 0.0.0.0:3483 0.0.0.0:0 LISTENING TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING TCP 0.0.0.0:6789 0.0.0.0:0 LISTENING TCP 0.0.0.0:7680 0.0.0.0:0 LISTENING TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING TCP 0.0.0.0:8443 0.0.0.0:0 LISTENING TCP 0.0.0.0:8554 0.0.0.0:0 LISTENING TCP 0.0.0.0:8555 0.0.0.0:0 LISTENING TCP 0.0.0.0:8843 0.0.0.0:0 LISTENING TCP 0.0.0.0:8880 0.0.0.0:0 LISTENING TCP 0.0.0.0:9000 0.0.0.0:0 LISTENING TCP 0.0.0.0:9090 0.0.0.0:0 LISTENING TCP 0.0.0.0:10200 0.0.0.0:0 LISTENING TCP 0.0.0.0:10243 0.0.0.0:0 LISTENING TCP 0.0.0.0:10400 0.0.0.0:0 LISTENING TCP 0.0.0.0:10401 0.0.0.0:0 LISTENING TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING TCP 0.0.0.0:49668 0.0.0.0:0 LISTENING TCP 0.0.0.0:49722 0.0.0.0:0 LISTENING TCP 0.0.0.0:49752 0.0.0.0:0 LISTENING TCP 0.0.0.0:49753 0.0.0.0:0 LISTENING TCP 0.0.0.0:49769 0.0.0.0:0 LISTENING TCP 127.0.0.1:5354 0.0.0.0:0 LISTENING TCP 127.0.0.1:27117 0.0.0.0:0 LISTENING TCP 192.168.1.26:139 0.0.0.0:0 LISTENING TCP [::]:135 [::]:0 LISTENING TCP [::]:445 [::]:0 LISTENING TCP [::]:554 [::]:0 LISTENING TCP [::]:1801 [::]:0 LISTENING TCP [::]:2103 [::]:0 LISTENING TCP [::]:2105 [::]:0 LISTENING TCP [::]:2107 [::]:0 LISTENING TCP [::]:2869 [::]:0 LISTENING TCP [::]:3389 [::]:0 LISTENING TCP [::]:5357 [::]:0 LISTENING TCP [::]:6789 [::]:0 LISTENING TCP [::]:7680 [::]:0 LISTENING TCP [::]:8080 [::]:0 LISTENING TCP [::]:8443 [::]:0 LISTENING TCP [::]:8843 [::]:0 LISTENING TCP [::]:8880 [::]:0 LISTENING TCP [::]:10243 [::]:0 LISTENING TCP [::]:49664 [::]:0 LISTENING TCP [::]:49665 [::]:0 LISTENING TCP [::]:49666 [::]:0 LISTENING TCP [::]:49667 [::]:0 LISTENING TCP [::]:49668 [::]:0 LISTENING TCP [::]:49722 [::]:0 LISTENING TCP [::]:49752 [::]:0 LISTENING TCP [::]:49753 [::]:0 LISTENING TCP [::]:49769 [::]:0 LISTENING C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32> C:\WINDOWS\system32>netstat -an |find /i "listening" TCP 0.0.0.0:80 0.0.0.0:0 LISTENING TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:554 0.0.0.0:0 LISTENING TCP 0.0.0.0:1801 0.0.0.0:0 LISTENING TCP 0.0.0.0:2103 0.0.0.0:0 LISTENING TCP 0.0.0.0:2105 0.0.0.0:0 LISTENING TCP 0.0.0.0:2107 0.0.0.0:0 LISTENING TCP 0.0.0.0:2869 0.0.0.0:0 LISTENING TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING TCP 0.0.0.0:3483 0.0.0.0:0 LISTENING TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING TCP 0.0.0.0:6789 0.0.0.0:0 LISTENING TCP 0.0.0.0:7680 0.0.0.0:0 LISTENING TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING TCP 0.0.0.0:8443 0.0.0.0:0 LISTENING TCP 0.0.0.0:8843 0.0.0.0:0 LISTENING TCP 0.0.0.0:8880 0.0.0.0:0 LISTENING TCP 0.0.0.0:9000 0.0.0.0:0 LISTENING TCP 0.0.0.0:9090 0.0.0.0:0 LISTENING TCP 0.0.0.0:10200 0.0.0.0:0 LISTENING TCP 0.0.0.0:10243 0.0.0.0:0 LISTENING TCP 0.0.0.0:10400 0.0.0.0:0 LISTENING TCP 0.0.0.0:10401 0.0.0.0:0 LISTENING TCP 0.0.0.0:49664 0.0.0.0:0 LISTENING TCP 0.0.0.0:49665 0.0.0.0:0 LISTENING TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING TCP 0.0.0.0:49668 0.0.0.0:0 LISTENING TCP 0.0.0.0:49722 0.0.0.0:0 LISTENING TCP 0.0.0.0:49752 0.0.0.0:0 LISTENING TCP 0.0.0.0:49753 0.0.0.0:0 LISTENING TCP 0.0.0.0:49769 0.0.0.0:0 LISTENING TCP 127.0.0.1:5354 0.0.0.0:0 LISTENING TCP 127.0.0.1:27117 0.0.0.0:0 LISTENING TCP 192.168.1.26:139 0.0.0.0:0 LISTENING TCP [::]:135 [::]:0 LISTENING TCP [::]:445 [::]:0 LISTENING TCP [::]:554 [::]:0 LISTENING TCP [::]:1801 [::]:0 LISTENING TCP [::]:2103 [::]:0 LISTENING TCP [::]:2105 [::]:0 LISTENING TCP [::]:2107 [::]:0 LISTENING TCP [::]:2869 [::]:0 LISTENING TCP [::]:3389 [::]:0 LISTENING TCP [::]:5357 [::]:0 LISTENING TCP [::]:6789 [::]:0 LISTENING TCP [::]:7680 [::]:0 LISTENING TCP [::]:8080 [::]:0 LISTENING TCP [::]:8443 [::]:0 LISTENING TCP [::]:8843 [::]:0 LISTENING TCP [::]:8880 [::]:0 LISTENING TCP [::]:10243 [::]:0 LISTENING TCP [::]:49664 [::]:0 LISTENING TCP [::]:49665 [::]:0 LISTENING TCP [::]:49666 [::]:0 LISTENING TCP [::]:49667 [::]:0 LISTENING TCP [::]:49668 [::]:0 LISTENING TCP [::]:49722 [::]:0 LISTENING TCP [::]:49752 [::]:0 LISTENING TCP [::]:49753 [::]:0 LISTENING TCP [::]:49769 [::]:0 LISTENING -
Let’s start with a test of the Alexa device to a known working demo camera without the gateway.
The following RTSP URL is now working and I just tested it with FireTV and Echo Show 8:
rtsp://demo.mproxy.io:443/testHere are the connection details I am using in Monocle web portal.
In this case we are not using the Monocle Gateway at all. I’m just hoping to verify that your Alexa-enabled device can at least access a publicly hosted camera and show the camera’s stream thus verifying the device is fully capable of showing camera stream using the Alexa Smart Home Camera APIs.
-
Just says “Camera Doesn’t Support That”
-
Well, that’s not a good sign. I just tested the demo feed again to make sure it was still working and it is.
I renamed my demo camera to “Demo Direct” just to try it out. I then asked “Alexa, discover devices” so she would get the updated device name. She responded with “No new devices …” which is correct, because this is just a change to an existing device.
Finally, I asked “Alexa, show me Demo Direct” and she responded with “OK”. After about 5-10 seconds, the feed is displayed on my devices. I tested on the following:
- Fire TV 4K (Gen 1)
- Fire TV Cube 4K
- Fire TV Stick 4K
- Fire TV Edition 4K (Toshiba)
- Echo Spot (Gen 1)
- Echo Show 7" (Gen 1)
- Echo Show 10.1" (Gen 2)
- Echo Show 5
- Echo Show 8
- Echo Fire Tablet (7th Gen)
So at this point, I’m really out of suggestions to try other than trying to work with Amazon Alexa support. I don’t believe its a problem at all with the Monocle Alexa Skill.
Thanks, Robert
-
Actually … I did think of one more small thing to try. Add the tag “
@noproxy” to the “Demo Direct” camera.
This will eliminate one more step in the process. I don’t expect it to make a difference but it’s worth a shot.Thanks, Robert
-
I will try @noproxy
-
Thanks so much for trying to help… Unfortunately no love, I will try replacing my firewall with a different device to see if it is indeed some setting with the firewall. If that doesn’t work, do you have any suggestions on who and how to contact amazon support? I.e. is there an email address to contact?
-
If the Lenovo Smart Tab won’t work with the DEMO camera feed then I don’t think its an issue with your firewall. The DEMO camera feed is available publicly and thus as long as the Alexa device can access the Internet, then nothing firewall related should have an impact in this case.
Basically here is what should happen:
1.) You ask Alexa for a camera feed.
2.) Your Lenovo Smart Tab will contact Alexa servers to initiate the camera stream by name.
3.) The Alexa servers contact the Monocle servers with a request for the camera stream. (InitializeCameraStream)
4.) Monocle servers receive the Alexa InitializeCameraStream request and respond with the appropriate details (RTSP URL, username, password, etc) for the Alexa device to make a RTSP connection to the IP camera.You can verify this by inspecting the “
Camera Feed History” on your camera in the Monocle Web Portal.
You should see something like this in your feed history for the demo camera stream when using tag@noproxy:{ "timestamp": "2020-01-21T17:19:06.750Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://demo.mproxy.io:443/test", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] }5.) This response is then returned to the Lenovo Smart Tab by the Alexa servers and then the tablet should immediately attempt to establish a (secure) connection to the camera stream, negotiate a RTSP session and start playing the stream.
So as long as this is showing up in your camera feed history, then that tells us that the Alexa servers are accepting your request and we are responding with the demo camera stream information and at that point its entirely up to the Lenovo Smart Tab to make the connection to the camera stream and start playing the stream.
Thanks, Robert
-
@skarragallagher said in Foscam R2 with Lenovo Smart Tab:
… do you have any suggestions on who and how to contact amazon support? I.e. is there an email address to contact?
Unfortunately I don’t have access to any direct means of Amazon support … just the general customer support URLs.
- https://www.amazon.com/gp/help/customer/display.html/?nodeId=201952240
- https://www.amazon.com/gp/help/customer/contact-us
I’ve had limited success using the Amazon developer forums for certain issues in the past:
-
@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/testand test again both with and without the@noproxytag. 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
@noproxyand 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/testand include both of the following tags:@noproxy, @tunneland 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@noproxytells our servers NOT to use a RTSP REDIRECT. In fact, I should change it to@noredirectto 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
