Merry Christmas!
I am trying to configure KMS on my Ubuntu 14.04 (64 bit). I could install the KMS server successfully following the guide at https://www.kurento.org/docs/6.0.0/installation_guide.html.
Also, downloaded the Javascript HelloWorld tutorial from https://www.kurento.org/docs/6.0.0/tutorials/js/tutorial-1-helloworld.html. I could run the example successfully on localhost on Google Chrome Version 47.0.2526.106 (64-bit) on the same Ubuntu System.
But, I could not see the local video nor the loop backed video. Only a spinner icon is shown on both the Video placeholders. Consulting the Console log reveals a problem after creating the SDP offer. The error is as described below.
kurento-client.js:21072 WebSocket connection to 'wss://127.0.0.1:8433/kurento' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
I am no expert on web sockets and stuff. Any help on this would really help me to proceed forward.
Note: I am running the example on HTTP, not on HTTPS. I guess that would not be the cause of the problem, though.
Regards,
LazyCoder7
I managed to solve it. I was wrong on my guess though, HTTPS was indeed required in order to make the WebSocket connection ( i was not aware of that part ). Created a certificate file (.pem) (from crt and key file already in the helloworld folder) and configured the KMS server to use the certificate. After this I was able to see myself and the same me in loopback :)
You are following an old version of the documentation. Since Chrome 47, in is mandatory to server pages through HTTPS if you want to use the getUserMedia APi. So we updated all our tutorials, and they now have a self-signed certificate. In case of the JS tutorials, you also need to configure KMS to expose a secure WS signalling connection, as the browser directly connects to the media server to control it.
Please follow the latest version of the documentation here
Be sure that the KMS is running on the port 8433 (not 8888), if you are using docker
docker run -d --name kms -p 8433:8433 kurento/kurento-media-server:trusty-latest
Related
I have my Django application deployed on heroku. It uses websockets, and everything is configured properly. When I go to my site, the websockets fail with WebSocket connection to 'wss://<url>' failed: Error during WebSocket handshake: Unexpected response code: 404. I did some digging and it's apparently due to chrome blocking the websockets? I came across this issue which sounds like what I'm getting, but the answer did not fix it for me.
Can someone explain what's going on here, and potentially how to fix it?
So the solution was nothing to do with heroku. I was using gunicorn to deploy my application, and that does not support websockets, so when the website hit my websocket endpoint gunicorn threw back a 404. I switched to daphne, and added web: daphne <application>.asgi:application --port $PORT --bind 0.0.0.0 to the Procfile, and everything started working. This blog post from Heroku helped me out, most specifically This segment.
try using https://<url> inspite of using wss i came across the same issue when i deployed my node.js application on heroku.
hope this will solve your problem too.
I'm trying to configure an AWS Greengrass group through their JavaScript SDK, and I get everything up and running up to where I have a deployment. The issue is that the deployment seems to be stuck on "in progress" and there are no cloudwatch logs to help me.
I looked at the core device, and this is what I saw in the /greengrass/ggc/var/logs/system/runtime.log file:
[2019-01-18T03:17:22.64Z][INFO]-Greengrass Root: /greengrass
[2019-01-18T03:17:22.64Z][INFO]-Greengrass Write Directory: /greengrass/ggc
[2019-01-18T03:17:22.64Z][INFO]-Group File Directory: /greengrass/ggc/deployment/group
[2019-01-18T03:17:22.64Z][INFO]-Default Lambda UID: 498 GID: 496
[2019-01-18T03:17:22.64Z][INFO]-===========================================
[2019-01-18T03:17:22.64Z][INFO]-The current core is using the AWS IoT certificates with fingerprint: 7591dcd10e96f86dd2d323d468b84b419b26280bbcfd3c0eee45c5a12c6d2dd7
[2019-01-18T03:17:22.641Z][WARN]-worker process info: /greengrass/ggc/packages/1.7.0/var/worker/processes
[2019-01-18T03:17:22.641Z][WARN]-worker process info: /greengrass/ggc/packages/1.7.0/var/worker/processes
[2019-01-18T03:17:22.641Z][INFO]-Reloading registry
[2019-01-18T03:17:22.642Z][INFO]-The current core is using the AWS IoT certificates with fingerprint: 7591dcd10e96f86dd2d323d468b84b419b26280bbcfd3c0eee45c5a12c6d2dd7
I've checked and I'm able to successfully hit the ATS endpoint using OpenSSL and the certificates that I have. I'm using Amazon's recommended certificate from the Greengrass tutorial RSA 2048 bit key: Amazon Root CA 1.
What are some diagnostic steps or clues where to go from here?
I've had this issue before. I believe it's just a bug with the internals getting mangled from a bad deployment.
The way I brute force hanging deployments are to create a new core and then add known working lamdbas in a working group to the new core, kill and restart the deamon on the core device, and then redeploy.
So for me, I had 2 things misconfigured which prevented successful deployment
The deployment was stuck "in progress" because the permissions in the policy and role that were attached needed lambda permissions to deploy. Once I did this, the deployment went from "in progress" to "failed deployment" which brought me to the second mistake.
The EC2 instance which was hosting the core software somehow didn't run the setup shell script correctly (probably didn't run it as sudo) and my cgroups were not fully setup for memory (not sure what this means but you need it setup)
Thank you Steve B for the help!
I've encountered the mention issue many times. In my case, the problem was always related about internet connectivity.
To check your system, before starting the deployment process, please subscribe # (wildcard) to listen all topics and check out messages related about deployments. If you don't see any incoming messages, It means network connectivity is the problem.
Then you can run this command ping greengrass-ats.iot.region.amazonaws.com where the greengrass core installed to investigate the issue. If everything seems Ok, you can start deployment again. But If you see lost packages, you should investigate the main issues which causes the network problem.
I have problem with my app with Action Cable on Heroku:
WebSocket connection to 'ws://localhost:3000/cable' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
My production.rb:
config.action_cable.url = "wss://NAME.herokuapp.com/cable"
config.action_cable.allowed_request_origins = ['https://NAME.herokuapp.com', 'http://NAME.herokuapp.com']
I tried to specify the server in the cable.js as well:
#App ||= {}
App.cable = ActionCable.createConsumer("wss://NAME.herokuapp.com/cable")
I tried to change it in development.rb just in case but nothing helps. The Heroku is still trying to connect to localhost.
Another weird thing that has nothing in common with it I think, is that the app is not able to process some js code like: alert('test') or console.log("haha") despite of some js code works and I tried assets:precompile as well.
In localhost, everything works perfectly. Any idea what can be wrong with heroku and the setting?
While ActionCable was in development, I remember you had to startup 2 servers for the cable connection and for Rails. I don't think that is still needed for the final release.
My guess is that you don't have Redis provisioned on your Heroku instance, whereas in Production, ActionCable relies on Redis for it's server communication.
To fix this, you should do the following:
heroku addons:add redistogo
heroku config | grep REDISTOGO_URL
In your config/cable.yml, set the Redis url to the one given. I guess you should also be able to use ENV['REDISTOGO_URL'] in place of the url.
Let me know if that helps.
If it's working locally but not remotely it may be an SSL problem. Make sure you properly set up an SSL endpoint for the secure websocket (wss):
https://devcenter.heroku.com/articles/ssl-endpoint
Also, there is an excellent blog post on Heroku about how to set up Action Cable: https://blog.heroku.com/real_time_rails_implementing_websockets_in_rails_5_with_action_cable. Alas, the article does not mention the necessity of setting up an SSL endpoint for the Heroku deployment to work.
I'm trying to replicate this demo
using my own mosquitto instance to control the meter. When I try to connect to "test.mosquitto.org", 8080 everything works great, but when I plug my own mqtt server's IP I receive: Connection failed: AMQJ0007E Socket error:undefined.
I believe this is due to the requirement of a websocket service to run on the same machine as the mqtt. The original author uses WSS, and I can't figure out how to install this service (complete noob). I Even tried to follow these directions with no luck Could anyone give some directions?
You can try Installing him HiveMQ while you wait for mosquito 1.4. That is a broker with websockets built in.
The easiest answer to this is probably to wait for Mosquitto v1.4 to ship which has baked in Websocket support.
If you can't wait for it to ship you can build from the development head stream which will get you what your looking for. You've not said what platform you are running the broker on, but these instructions should help on Linux: http://goochgooch.wordpress.com/2014/08/01/building-mosquitto-1-4/
Mosquitto v1.4 has been released on February 18th, 2015. It has inbuilt support for websockets.
I'd netty running on my dev machine which runs Windows 7. Now, When I migrate my app to a CEntOS 6 server, all websocket communications do not work. I thought that it is because of iptables restrictions. So, I added entries for the ports used to the iptable.
My interface binding information is 0.0.0.0:port, and the URL I use in my client code to access the websocket is ws://SERVER_IP:port/. I've googled for sometime now in vain. Any assistance will be appreciated. My client uses JavaScript.
UPDATE:
When I run netstat -nlp, I see :::port_number for local address and :::* for the foreign address. I'm thinking that this should be 0.0.0.0:port_number for the local address and 0.0.0.0:* for the foreign address. May be I'm missing something in my configuration.
UPDATE:
After a painstaking troubleshooting process, I found out the root of my problem was my network security configuration. After resolving this, everything now works fine.