UDP Port are open, but video is still not working
1,773 views
Skip to first unread message
Robert Brown III
Aug 12, 2014, 10:56:20 PM8/12/14
to kur...@googlegroups.com
Greetings:
I am running the Korento (without KAS) installation. I have installed a web server and put in the Webrtc application. All kurento ports are open, and I used Bower to set up the sample applications from the tutorial.
On the adviice I received in a previous post, I have effectively negated the firewall on the machine, opening all UDP ports from 1024 -> 65K. I am now running the WebRTCLoop application.
Or rather, I am *trying* to.
When running the application I get different results on different machines. On all machines, I get a the two blank windows, one titled "Local Stream" and the other titled "Remote Stream".
On one machine, a laptop running Windows 8 with a single integrated webcam, when I click on the "click me to start" button I get a window allowing me to connect the camera, then when I connect the camera the Local screen comes up but the remote one does not.
On the second machine, a laptop running Windows 8.1 with an integrated camera, when I click on the "click me to start" button I get the window allowing me to connect my camera, and when I connect a light goes on showing that the camera is on but I get nothing in the Windows. Even the local stream is blank.
On the third machine, which is a Macintosh with a USB camera, I get the exact behavior that I get on the second machine. The only difference is that the camera on the Macintosh does not indicate that it is being accessed.
Having opened the ports as advised, I am certain now that my problems have nothing to do with closed ports. Something else is wrong. Kurento WebRTC video is not working.
Someone please advise. Why is this not working?
I am running the Korento (without KAS) installation. I have installed a web server and put in the Webrtc application. All kurento ports are open, and I used Bower to set up the sample applications from the tutorial.
On the adviice I received in a previous post, I have effectively negated the firewall on the machine, opening all UDP ports from 1024 -> 65K. I am now running the WebRTCLoop application.
Or rather, I am *trying* to.
When running the application I get different results on different machines. On all machines, I get a the two blank windows, one titled "Local Stream" and the other titled "Remote Stream".
On one machine, a laptop running Windows 8 with a single integrated webcam, when I click on the "click me to start" button I get a window allowing me to connect the camera, then when I connect the camera the Local screen comes up but the remote one does not.
On the second machine, a laptop running Windows 8.1 with an integrated camera, when I click on the "click me to start" button I get the window allowing me to connect my camera, and when I connect a light goes on showing that the camera is on but I get nothing in the Windows. Even the local stream is blank.
On the third machine, which is a Macintosh with a USB camera, I get the exact behavior that I get on the second machine. The only difference is that the camera on the Macintosh does not indicate that it is being accessed.
Having opened the ports as advised, I am certain now that my problems have nothing to do with closed ports. Something else is wrong. Kurento WebRTC video is not working.
Someone please advise. Why is this not working?
LuLop
Aug 13, 2014, 4:43:32 AM8/13/14
to kur...@googlegroups.com
The local stream should work independently on Kurento. It only depends on the browser. Which browsers are you using to run your experiments? Chrome, Fireforx? Which versions? Could you open the JavaScript console and share with us the messages appearing there?
Best.
L.
--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Robert Brown III
Aug 13, 2014, 6:44:19 PM8/13/14
to kur...@googlegroups.com
Greetings:
My primary browser is Firefox. Be advised: all tests are running *within* my loal network. No network firewalls are involved. I want this working within my network before I test it over the Internet.
On Machine 3 (Macintosh with USB), I was running Firefox v29. In theory, WebRTC should work without problems st that version, but I upgraded it to v31 anyway. The upgrade on the Macintosh involved replacing the entire old version, Once it was installed, I attempted to access the WebRTCLoopback application again. It now shows the local stream, where it did not before.
On Machine 2 (running Windows 8.1) I was running Firefox v30. I upgraded to v31 and retried WebRTCLoopback. There was no change in its behavior. The input stream still does not show, though my machine indicates that it is accessing the camera.
On Machine 1 (Windows 8), it was already displaying the local stream. That machine was running Firefox v28. Even though it was working fine with Firefox v28, I upgraded to v31 just for consistency. I retested. It still shows the local stream.
All of the machines are now running Firefox v31. Machines 1 and 3 are displaying the local stream. None of the machines are displaying the remote stream.
The reason for the failure to display the remote stream is unknown -- but I do know it was never port- related. I made an independent inquiry about UDP ports and Kurento security on the Ubuntu forum. According to the Ubuntu folks, the UDP ports are open by default (for now), so it was unnecessary for me to do anything to open them.
Nevertheless, I did monitor Firefox's logs and ran webrtcloopback again. There are no Javascript errors, but when I look at the network traffic there are some really odd behaviors in the Javascript.
The first odd behavior I notice is that somewhere after my request gos out to my HTML file, I get a 304 return which directs my browser to upload file adapter.js at a place called rawgit.com (https://rawgit.com/GoogleChrome/webrtc/master/samples/web/js/adapter.js). This GET request is completed without problems.
The second odd behavior I see is that, after I click on the "click me to start" button, something in the file Demo.js keeps sending a GET request to websocket on demo01.kurento.org:8888 (http://demo01.kurento.org:8888/thrift/ws/websocket).
The webrtcloopback application apparently sends this request periodically, and there is no response to it. The application keeps sending this request and receiving no response.
The obvious questions are: why are we depending on a JS file that is in a place called rawgit??? And why are we sending a GET request to some odd demo01 system on an obvious kurento site in order to access websocket, violating the Javascript rule of communicating only with the site you loaded from???
Of course, a more important question is: where is the correct place to look for these assets and what do I edit in order to point the Javascript to the right place?
My primary browser is Firefox. Be advised: all tests are running *within* my loal network. No network firewalls are involved. I want this working within my network before I test it over the Internet.
On Machine 3 (Macintosh with USB), I was running Firefox v29. In theory, WebRTC should work without problems st that version, but I upgraded it to v31 anyway. The upgrade on the Macintosh involved replacing the entire old version, Once it was installed, I attempted to access the WebRTCLoopback application again. It now shows the local stream, where it did not before.
On Machine 2 (running Windows 8.1) I was running Firefox v30. I upgraded to v31 and retried WebRTCLoopback. There was no change in its behavior. The input stream still does not show, though my machine indicates that it is accessing the camera.
On Machine 1 (Windows 8), it was already displaying the local stream. That machine was running Firefox v28. Even though it was working fine with Firefox v28, I upgraded to v31 just for consistency. I retested. It still shows the local stream.
All of the machines are now running Firefox v31. Machines 1 and 3 are displaying the local stream. None of the machines are displaying the remote stream.
The reason for the failure to display the remote stream is unknown -- but I do know it was never port- related. I made an independent inquiry about UDP ports and Kurento security on the Ubuntu forum. According to the Ubuntu folks, the UDP ports are open by default (for now), so it was unnecessary for me to do anything to open them.
Nevertheless, I did monitor Firefox's logs and ran webrtcloopback again. There are no Javascript errors, but when I look at the network traffic there are some really odd behaviors in the Javascript.
The first odd behavior I notice is that somewhere after my request gos out to my HTML file, I get a 304 return which directs my browser to upload file adapter.js at a place called rawgit.com (https://rawgit.com/GoogleChrome/webrtc/master/samples/web/js/adapter.js). This GET request is completed without problems.
The second odd behavior I see is that, after I click on the "click me to start" button, something in the file Demo.js keeps sending a GET request to websocket on demo01.kurento.org:8888 (http://demo01.kurento.org:8888/thrift/ws/websocket).
The webrtcloopback application apparently sends this request periodically, and there is no response to it. The application keeps sending this request and receiving no response.
The obvious questions are: why are we depending on a JS file that is in a place called rawgit??? And why are we sending a GET request to some odd demo01 system on an obvious kurento site in order to access websocket, violating the Javascript rule of communicating only with the site you loaded from???
Of course, a more important question is: where is the correct place to look for these assets and what do I edit in order to point the Javascript to the right place?
LuLop
Aug 14, 2014, 9:32:22 AM8/14/14
to kur...@googlegroups.com
El 14/08/2014, a las 00:44, Robert Brown III <robertbr...@gmail.com> escribió:
Greetings:
My primary browser is Firefox. Be advised: all tests are running *within* my loal network. No network firewalls are involved. I want this working within my network before I test it over the Internet.
On Machine 3 (Macintosh with USB), I was running Firefox v29. In theory, WebRTC should work without problems st that version, but I upgraded it to v31 anyway. The upgrade on the Macintosh involved replacing the entire old version, Once it was installed, I attempted to access the WebRTCLoopback application again. It now shows the local stream, where it did not before.
On Machine 2 (running Windows 8.1) I was running Firefox v30. I upgraded to v31 and retried WebRTCLoopback. There was no change in its behavior. The input stream still does not show, though my machine indicates that it is accessing the camera.
On Machine 1 (Windows 8), it was already displaying the local stream. That machine was running Firefox v28. Even though it was working fine with Firefox v28, I upgraded to v31 just for consistency. I retested. It still shows the local stream.
All of the machines are now running Firefox v31. Machines 1 and 3 are displaying the local stream. None of the machines are displaying the remote stream.
Local stream should be visible on all machines because it is only using local browser WebRTC capabilities. If you don't see the local stream in any of your machines, then review browser version and configuration.
The reason for the failure to display the remote stream is unknown -- but I do know it was never port- related. I made an independent inquiry about UDP ports and Kurento security on the Ubuntu forum. According to the Ubuntu folks, the UDP ports are open by default (for now), so it was unnecessary for me to do anything to open them.
Nevertheless, I did monitor Firefox's logs and ran webrtcloopback again. There are no Javascript errors, but when I look at the network traffic there are some really odd behaviors in the Javascript.
The first odd behavior I notice is that somewhere after my request gos out to my HTML file, I get a 304 return which directs my browser to upload file adapter.js at a place called rawgit.com (https://rawgit.com/GoogleChrome/webrtc/master/samples/web/js/adapter.js). This GET request is completed without problems.
adapter.js is an utility library provided by Google which abstracts different versions of the native WebRTC libraries on different browsers. In the code we provide, it's obtained from rawgit (a CDN for serving github code), but you can put the script in your local server and serve it from there if you want.
The second odd behavior I see is that, after I click on the "click me to start" button, something in the file Demo.js keeps sending a GET request to websocket on demo01.kurento.org:8888 (http://demo01.kurento.org:8888/thrift/ws/websocket).
You need to change this URL to the machine in which you have installed your KMS and your Kurento Connector. That URL (note that is a ws:// URL, not an http:// one) is where the browser contacts the connector. In our examples, it is configures to go against a demo machine we have. That machine is currently down for maintenance. You should simply set the URL to point to your machine:
The webrtcloopback application apparently sends this request periodically, and there is no response to it. The application keeps sending this request and receiving no response.
Sure, it's trying to contact the media server, but as it's not finding it, it re-tries.
The obvious questions are: why are we depending on a JS file that is in a place called rawgit???
Answered above. You can download that script to your local machine if you don't want to have external dependencies. You will need to update the HTML code accordingly.
And why are we sending a GET request to some odd demo01 system on an obvious kurento site in order to access websocket, violating the Javascript rule of communicating only with the site you loaded from???
WS connections do not need to comply with the same origin policy. This is not violating any JS security rule (in general WebRTC does not comply at all with any same origin policy you can imagine, but this does not need to mean that WebRTC is a security breach)
Of course, a more important question is: where is the correct place to look for these assets and what do I edit in order to point the Javascript to the right place?
In summary:
1. Download the adapter.js script (from the rawgit URL you provide above) and put it in your local machine. Update the HTML code accordingly so that the script can be found.
2. Set the ws:// URL you describe above to point to your Kurento Connector IP and port.
3. Test again the demo.
Javier Lopez Fernandez
Aug 14, 2014, 11:08:16 AM8/14/14
to kur...@googlegroups.com
Please,
Notice demo servers are under maintenance and service is currently down.
Javier Lopez Fernandez
Message has been deleted
Message has been deleted
Message has been deleted
Robert Brown III
Aug 14, 2014, 10:22:09 PM8/14/14
to kur...@googlegroups.com
Greetings:
Thanks for the useful info. I am making progress.
All machines except Machine 2 are getting the local stream. It should be noted that, as explained in my previous post, all machines are now running Version 31 of Firefox. For some reason, however, Machine 2 still fails to display the local stream.
I made the appropriate changes to the Demo.js file. The variable now points to the websocket that is on my server. For a time I was still failing to connect to websocket, but eventually I found out about the kws connector.
Now, when I click on the "Click me to start" button, and subsequently connect to the camera, the connector logs something like the following:
22:04:55.259 [888-exec-8] INFO - c.k.k.j.i.ws.JsonRpcWebSocketHandler - Client connection stablished from /192.168.1.104:61703
so I know something is going on.
Unfortunately, I am still not seeing the remote stream.
There are some questions I have:
1. I notice that the default KMF ports opened for the connector are 9090 and 9191. The KMF server has ports 9090 and 9091 open. Which of the ports does the connector use to talk to KWS? It should be noted that, thinking the connector needed to contact KMF using the second port, I changed the connector's ports to 9090 and 9091. I got a "port already in use" failure when I restarted the connector, so I changed 9091 back to 9091. What port is the connector actually using to talk to KMF.
2. Should the 9191 port be opened for the connector?
3. I notice that in the connector's instructions the startup should uses the localhost (127.0.0.1) address. The KMFserver is running on the same machine as the Connector. Is the localhost address the correct one to use?
Supplemental: I am having trouble downloading adaprer,js. Apparently the URL pointing to it is being redirected somewhere, and when I attempt to download it I am getting 404 file not found failures. Is there an alternate place where I can get this file???
Thanks for the useful info. I am making progress.
All machines except Machine 2 are getting the local stream. It should be noted that, as explained in my previous post, all machines are now running Version 31 of Firefox. For some reason, however, Machine 2 still fails to display the local stream.
I made the appropriate changes to the Demo.js file. The variable now points to the websocket that is on my server. For a time I was still failing to connect to websocket, but eventually I found out about the kws connector.
Now, when I click on the "Click me to start" button, and subsequently connect to the camera, the connector logs something like the following:
22:04:55.259 [888-exec-8] INFO - c.k.k.j.i.ws.JsonRpcWebSocketHandler - Client connection stablished from /192.168.1.104:61703
so I know something is going on.
Unfortunately, I am still not seeing the remote stream.
There are some questions I have:
1. I notice that the default KMF ports opened for the connector are 9090 and 9191. The KMF server has ports 9090 and 9091 open. Which of the ports does the connector use to talk to KWS? It should be noted that, thinking the connector needed to contact KMF using the second port, I changed the connector's ports to 9090 and 9091. I got a "port already in use" failure when I restarted the connector, so I changed 9091 back to 9091. What port is the connector actually using to talk to KMF.
2. Should the 9191 port be opened for the connector?
3. I notice that in the connector's instructions the startup should uses the localhost (127.0.0.1) address. The KMFserver is running on the same machine as the Connector. Is the localhost address the correct one to use?
Supplemental: I am having trouble downloading adaprer,js. Apparently the URL pointing to it is being redirected somewhere, and when I attempt to download it I am getting 404 file not found failures. Is there an alternate place where I can get this file???
LuLop
Aug 18, 2014, 4:29:43 AM8/18/14
to kur...@googlegroups.com
El 15/08/2014, a las 04:22, Robert Brown III <robertbr...@gmail.com> escribió:
Greetings:
Thanks for the useful info. I am making progress.
All machines except Machine 2 are getting the local stream. It should be noted that, as explained in my previous post, all machines are now running Version 31 of Firefox. For some reason, however, Machine 2 still fails to display the local stream.
I made the appropriate changes to the Demo.js file. The variable now points to the websocket that is on my server. For a time I was still failing to connect to websocket, but eventually I found out about the kws connector.
Now, when I click on the "Click me to start" button, and subsequently connect to the camera, the connector logs something like the following:
22:04:55.259 [888-exec-8] INFO - c.k.k.j.i.ws.JsonRpcWebSocketHandler - Client connection stablished from /192.168.1.104:61703
so I know something is going on.
Unfortunately, I am still not seeing the remote stream.
There are some questions I have:
1. I notice that the default KMF ports opened for the connector are 9090 and 9191. The KMF server has ports 9090 and 9091 open. Which of the ports does the connector use to talk to KWS? It should be noted that, thinking the connector needed to contact KMF using the second port, I changed the connector's ports to 9090 and 9091. I got a "port already in use" failure when I restarted the connector, so I changed 9091 back to 9091. What port is the connector actually using to talk to KMF.
I'm afraid you're mixing KAS and KMC concepts. As I have explained in several previous posts. Kurento documentation is currently being refactored and you should not take previous documentation versions as something written in stone. Just for you to get out of the mess. Please, go to the following URL and install the connector (KMC) as explained there:
Once you have installed the connector in that way, you should see that:
1. Browser (KWS) and connector (KMC) communicate through WebSockets using port 8888
2. KMC send requests to KMS using thrift through port 9090
3. KMS send events and notifications to KMC through port 9900
Kurento should not need any additional port for working. If you just want to use kws-tutorial examplex, no KAS installation is needed (forget about JBoss)
2. Should the 9191 port be opened for the connector?
3. I notice that in the connector's instructions the startup should uses the localhost (127.0.0.1) address. The KMFserver is running on the same machine as the Connector. Is the localhost address the correct one to use?
This depends on your network configuration. In general, the answer to your question should be "yes", but there are many cloud providers making localhost interface to be filtered, so that network traffic needs to get through the public interface even if it's inside the machine.
Supplemental: I am having trouble downloading adaprer,js. Apparently the URL pointing to it is being redirected somewhere, and when I attempt to download it I am getting 404 file not found failures. Is there an alternate place where I can get this file???
I can download it from this URL without problems:
LuLop
Aug 18, 2014, 4:31:10 AM8/18/14
to kur...@googlegroups.com
El 15/08/2014, a las 02:22, Robert Brown III <robertbr...@gmail.com> escribió:
Clarification:
There is apparently a "thrift" directory that contains a "websocket", which my machine apparently does not have (ws:<my-URL>:8888/thrisf/ws/websocket). I need to get any and all files/apps associated with that URL. There is apparently no instruction anywhere about how to set up this URL. Without it my remote stream will not work...
On Thursday, August 14, 2014 8:12:34 PM UTC-4, Robert Brown III wrote:There appears to be one last problem:
There is no instruction, in the tutotial or elsewhere, on where to get Thrift. It is not installed with the server, and the Bower command doesn't install it, either (I had hoped it would)...
Could you please tell me where I can get that? Thank you...
LuLop
Aug 18, 2014, 4:32:22 AM8/18/14
to kur...@googlegroups.com
El 15/08/2014, a las 02:12, Robert Brown III <robertbr...@gmail.com> escribió:
There appears to be one last problem:
There is no instruction, in the tutotial or elsewhere, on where to get Thrift. It is not installed with the server, and the Bower command doesn't install it, either (I had hoped it would)...
Thrift is installed automatically with KMS. If you KMS installation succeeded, then you already have thrift installed.
Could you please tell me where I can get that? Thank you...
Robert Brown III
Aug 18, 2014, 10:19:11 AM8/18/14
to kur...@googlegroups.com
I'm afraid you're mixing KAS and KMC concepts. As I have explained in several previous posts. Kurento documentation is currently being refactored and you should not take previous documentation versions as something written in stone. Just for you to get out of the mess. Please, go to the following URL and install the connector (KMC) as explained there:
Actually, I am not "mixing" anything.
Because you told me that KAS was deprecated, and because I was happy to eliminate JBoss from my system (note: I believe I mentioned that I *hate* JBoss!), I cleaned my harddisk, reinstalled Ubuntu, and installed the KMS and the KMC. I did *not* install KAS. As a result, my system is only running the things you said I needed to run.
Among the files in the KMC is a file called README.md. In that file are the following instructions:
Assuming that the command 'java' points to a Java 7 JVM executable, the proxy
can be executed as:
$ java -jar kmf-media-connector.jar --server.port=8888
--thrift.kms.address=127.0.0.1:9090
--thrift.kmf.address=127.0.0.1:9191
The meaning of configuration properties are:
* server.port: The http/websocket port of the proxy. This port will be used for
the clients to connect to the port. If not specified, the value 8888 will be
used.
* thrift.kms.address: The IP and port address of the Kurento Media Server.
If not specified, the address 127.0.0.1:9090 will be used.
* thrift.kmf.address: The IP and port address that Kurento Media Server will use
to connect to the proxy. If not specified, the address 127.0.0.1:9090 will be
used.
Please note the use of Port 9191 in the instructions. Note also that these instructions are unchanged in the latest zip file that exists in can be executed as:
$ java -jar kmf-media-connector.jar --server.port=8888
--thrift.kms.address=127.0.0.1:9090
--thrift.kmf.address=127.0.0.1:9191
The meaning of configuration properties are:
* server.port: The http/websocket port of the proxy. This port will be used for
the clients to connect to the port. If not specified, the value 8888 will be
used.
* thrift.kms.address: The IP and port address of the Kurento Media Server.
If not specified, the address 127.0.0.1:9090 will be used.
* thrift.kmf.address: The IP and port address that Kurento Media Server will use
to connect to the proxy. If not specified, the address 127.0.0.1:9090 will be
used.
the URL pointed to in that Stream- Oriented guide:
http://builds.kurento.org/release/stable/kmf-media-connector.zip(which happens to be the URL I got the zip file from in the first place).
It is because of the instructions in that README.md file that I was even mentioning Port 9191. There is no reference in that README.md to port 9900, or any indication that Port 9191 was a KAS port. If there was, it would have raised a red flag and I would have been asking very different questions.
Note also please that your post was the first reference I had to the URL:
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/StreamOriented_-_Installation_and_Administration_Guide
so there was no way I could have known about port 9900 prior to this post that I am replying to. The only instruction I had prior to your post was the README.md file. As a result, my KMC was likely seeking communication from KMS on the wrong port. But if that is the case, it is not because I "mixed" anything. It is because I followed the instructions that were available to me at the time.
Once you have installed the connector in that way, you should see that:1. Browser (KWS) and connector (KMC) communicate through WebSockets using port 88882. KMC send requests to KMS using thrift through port 90903. KMS send events and notifications to KMC through port 9900Kurento should not need any additional port for working. If you just want to use kws-tutorial examplex, no KAS installation is needed (forget about JBoss)
Thank you for providing the correct KMS port. And please note that, as explained above, JBoss was forgotten long before this latest set of experiments.
I can download it from this URL without problems:
I have successfully downloaded that JS file. Thanks for the alternate URL.
My main network is down, but it will be back up in a day or two. When it is, I will make the appropriate changes to my KMC startup script and see what happens. I will provide an update when I have done so...
My main network is down, but it will be back up in a day or two. When it is, I will make the appropriate changes to my KMC startup script and see what happens. I will provide an update when I have done so...
LuLop
Aug 19, 2014, 4:37:11 AM8/19/14
to kur...@googlegroups.com
Thank you for the clarification,
We have been performing some experiments and there are several issues in kws-tutorial and on KMS 4.3.6 which need to be fixed and which may be producing the anomalous behavior you are obtaining. We'll fix them and generate new versions asap.
Best.
L.
Robert Brown III
Aug 24, 2014, 5:32:49 AM8/24/14
to kur...@googlegroups.com
OK:
My network is back up, and I am using what I think is the correct port.
The remote is still not working.
I am running the connector in the following manner:
java -jar kmf-media-connector.jar --server.port=8888 --thrift.kms.address=127.0.0.1:9090 --thrift.kmf.address=127.0.0.1:9900
I found a kurento.conf file in the /etc/kurento directory. Thi file contains the following info:
[Server]
sdpPattern=pattern.sdp
service=Thrift
[HttpEPServer]
#serverAddress=localhost
# Announced IP Address may be helpful under situations such as the server needs
# to provide URLs to clients whose host name is different from the one the
# server is listening in. If this option is not provided, http server will try
# to look for any available address in your system.
# announcedAddress=localhost
serverPort=9091
[WebRtcEndPoint]
#stunServerAddress = xxx.xxx.xxx.xxx
#stunServerPort = xx
# TURN URL gives the necessary info to configure TURN for WebRTC.
# 'address' must be an IP (not a domain).
# 'transport' is optional (UDP by default).
#turnURL = user:password@address:port(?transport=[udp|tcp|tls])
#pemCertificate = file
[Thrift]
serverPort=9090
[RabbitMQ]
serverAddress = 127.0.0.1
serverPort = 5672
username = "guest"
password = "guest"
vhost = "/"
I think this all is set up properly, but I include it here just in case.
In any event, I am seeing the local window, and I am getting the "successful connection" message on the connector when I activate the camera. The only thing that seems to be missing is the remote content. It will not come up at all.
Everyhing seems to be working on the client side. It appears to be the server that is failing to communicate back to the client.
Is there some kind of log file for the media server that I can look at? I looked for one but could not find it. Maybe there is some failure condition happening on the server that I am missing???
I actually would like to look at any logs associated with the server side operation. Can you point me to them please?
Also: has anyone actually set up a demo site where the wtcloopback is actually working. If so, is there any way to examine the configuration to see how it might differ from mine?
My network is back up, and I am using what I think is the correct port.
The remote is still not working.
I am running the connector in the following manner:
java -jar kmf-media-connector.jar --server.port=8888 --thrift.kms.address=127.0.0.1:9090 --thrift.kmf.address=127.0.0.1:9900
I found a kurento.conf file in the /etc/kurento directory. Thi file contains the following info:
[Server]
sdpPattern=pattern.sdp
service=Thrift
[HttpEPServer]
#serverAddress=localhost
# Announced IP Address may be helpful under situations such as the server needs
# to provide URLs to clients whose host name is different from the one the
# server is listening in. If this option is not provided, http server will try
# to look for any available address in your system.
# announcedAddress=localhost
serverPort=9091
[WebRtcEndPoint]
#stunServerAddress = xxx.xxx.xxx.xxx
#stunServerPort = xx
# TURN URL gives the necessary info to configure TURN for WebRTC.
# 'address' must be an IP (not a domain).
# 'transport' is optional (UDP by default).
#turnURL = user:password@address:port(?transport=[udp|tcp|tls])
#pemCertificate = file
[Thrift]
serverPort=9090
[RabbitMQ]
serverAddress = 127.0.0.1
serverPort = 5672
username = "guest"
password = "guest"
vhost = "/"
I think this all is set up properly, but I include it here just in case.
In any event, I am seeing the local window, and I am getting the "successful connection" message on the connector when I activate the camera. The only thing that seems to be missing is the remote content. It will not come up at all.
Everyhing seems to be working on the client side. It appears to be the server that is failing to communicate back to the client.
Is there some kind of log file for the media server that I can look at? I looked for one but could not find it. Maybe there is some failure condition happening on the server that I am missing???
I actually would like to look at any logs associated with the server side operation. Can you point me to them please?
Also: has anyone actually set up a demo site where the wtcloopback is actually working. If so, is there any way to examine the configuration to see how it might differ from mine?
LuLop
Aug 27, 2014, 1:57:37 PM8/27/14
to kur...@googlegroups.com
Hi,
Please, execute the following command so that we can see your port configuration
sudo netstat atnp | grep LISTEN
Please, send us also the "ws://" URL that you have at the demo.js file of the WebRtcLoopback
To conclude, share with us the log of the connector, which can be found at /var/log/kurento/media-connector.log
L.
Robert Brown III
Aug 28, 2014, 8:31:50 PM8/28/14
to kur...@googlegroups.com
Greetings:
In answer to your various questions:
1. Apparently, there is nothing "listening" on my machine. A search for "active" connections yields nothing.
2. The ws URL is: ws://192.168.1.14:8888/thrift/ws/websocket
Note that the address is local in my network, as is the machine I am using to test the demo. I am trying to get everything to work locally before I attempt anything over the Internet.
3. The contents of media-server.log are large and have a lot of escape characters in them (why would you folks put such characters in a log file that is supposed to be looked at by humans???) . I have attached a copy of the log file.
Note that when I connect to the MediaConnector (after giving the application permission to use my camera and mic), nothing happens in the media server -- or so it appears. No new entries appear in the media-server.log file when I attempt to initiate the loopback.
Is there anything wrong here?
In answer to your various questions:
1. Apparently, there is nothing "listening" on my machine. A search for "active" connections yields nothing.
2. The ws URL is: ws://192.168.1.14:8888/thrift/ws/websocket
Note that the address is local in my network, as is the machine I am using to test the demo. I am trying to get everything to work locally before I attempt anything over the Internet.
3. The contents of media-server.log are large and have a lot of escape characters in them (why would you folks put such characters in a log file that is supposed to be looked at by humans???) . I have attached a copy of the log file.
Note that when I connect to the MediaConnector (after giving the application permission to use my camera and mic), nothing happens in the media server -- or so it appears. No new entries appear in the media-server.log file when I attempt to initiate the loopback.
Is there anything wrong here?
LuLop
Aug 29, 2014, 2:54:34 AM8/29/14
to kur...@googlegroups.com
El 29/08/2014, a las 02:31, Robert Brown III <robertbr...@gmail.com> escribió:
Greetings:
In answer to your various questions:
1. Apparently, there is nothing "listening" on my machine. A search for "active" connections yields nothing.
You must have things listening. I think the problem is that I gave you a wrong command, sorry, try putting a "-" before the options
sudo netstat -atnp | grep LISTEN
2. The ws URL is: ws://192.168.1.14:8888/thrift/ws/websocket
Note that the address is local in my network, as is the machine I am using to test the demo. I am trying to get everything to work locally before I attempt anything over the Internet.
This seems OK
3. The contents of media-server.log are large and have a lot of escape characters in them (why would you folks put such characters in a log file that is supposed to be looked at by humans???) . I have attached a copy of the log file.
Note that when I connect to the MediaConnector (after giving the application permission to use my camera and mic), nothing happens in the media server -- or so it appears. No new entries appear in the media-server.log file when I attempt to initiate the loopback.
The media server is not receiving anything. Please, send us the log file of the media connector (no the one of the media server). It should be located at /var/log/kurento/media-connector.log
Is there anything wrong here?
On Wednesday, August 27, 2014 1:57:37 PM UTC-4, lulop wrote:Hi,Please, execute the following command so that we can see your port configurationsudo netstat atnp | grep LISTENPlease, send us also the "ws://" URL that you have at the demo.js file of the WebRtcLoopbackTo conclude, share with us the log of the connector, which can be found at /var/log/kurento/media-connector.logL.
--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<media-server.log>
Robert Brown III
Aug 29, 2014, 7:02:26 AM8/29/14
to kur...@googlegroups.com
>The media server is not receiving anything. Please, send us the log file of the media connector (no the one of the media server). It should >be located at /var/log/kurento/media-connector.log
Sorry about that. I thought you wanted the server log.
There is no "media-connector.log" file at the location you specified.0
I will start searching for it...
LuLop
Aug 29, 2014, 7:07:15 AM8/29/14
to kur...@googlegroups.com
Are you sure the connector is running?
please, send me the result of the commands
sudo netstat -antp | grep LISTEN
sudo ps aux | grep kmf
sudo ps aux | grep kurento
Robert Brown III
Aug 29, 2014, 10:30:57 PM8/29/14
to kur...@googlegroups.com
Yes. The connector is running. It sends the output to standard output. It does not generate a log file.
The result of the netstat command:
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 32258/cupsd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 552/smbd
tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN 30653/kurento <== I presume this is the important line
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 552/smbd
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN 1046/dnsmasq
tcp6 0 0 ::1:631 :::* LISTEN 32258/cupsd
tcp6 0 0 :::8888 :::* LISTEN 1547/java
tcp6 0 0 :::445 :::* LISTEN 552/smbd
tcp6 0 0 :::9090 :::* LISTEN 30653/kurento <== As is this one
tcp6 0 0 127.0.0.1:8005 :::* LISTEN 2345/java
tcp6 0 0 :::8009 :::* LISTEN 2345/java
tcp6 0 0 :::139 :::* LISTEN 552/smbd
tcp6 0 0 127.0.0.1:9900 :::* LISTEN 1547/java
tcp6 0 0 :::8080 :::* LISTEN 2345/java
The result of the ps grepping kmf:
rbrown3 1547 9.3 1.7 2796820 141452 pts/15 Sl+ 21:46 0:13 /home/rbrown3/software/java7/bin/java -jar ./lib/kmf-media-connector.jar --server.port=8888 --thrift.kms.address=127.0.0.1:9090 --thrift.kmf.address=127.0.0.1:9900
rbrown3 1592 0.0 0.0 15940 916 pts/0 S+ 21:49 0:00 grep --color=auto kmf
The result of the ps grepping kurento:
rbrown3 1595 0.0 0.0 15940 920 pts/0 S+ 21:49 0:00 grep --color=auto kurento
nobody 30653 0.0 0.1 298504 11292 ? Sl Aug28 0:00 /usr/bin/kurento
And for completeness, here is the contents of /var/log/kurento:
$ ls /var/log/kurento
media-server.log
$
As stated, there is no media-connector.log file anywhere on my system. I am getting debugging information on standard output, though. Below is the output that has been generated from when I deliberately restarted the connector to when I hooked in from the loopback application:
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v1.0.0.RC1)
21:46:49.774 [ main] INFO - c.k.kmf.connector.MediaConnectorApp - Starting MediaConnectorApp v4.2.10 on AphrodetteBox with PID 1547 (/home/rbrown3/software/connect/lib/kmf-media-connector.jar started by rbrown3)
21:46:49.781 [ main] DEBUG - c.k.kmf.connector.MediaConnectorApp - Running with Spring Boot v1.0.0.RC1, Spring v4.0.1.RELEASE
21:46:57.660 [tartStop-1] DEBUG - c.k.k.j.i.s.config.OAuthFiWareFilter - Initializing filter 'applicationContextOAuthFilter'
21:46:57.661 [tartStop-1] DEBUG - c.k.k.j.i.s.config.OAuthFiWareFilter - Filter 'applicationContextOAuthFilter' configured successfully
21:46:58.196 [ main] INFO - c.kurento.kmf.media.factory.KmfMediaApi - Creating JsonRpcClient with Thrift transport. Prefix: null
21:46:58.197 [ main] INFO - c.kurento.kmf.media.factory.KmfMediaApi - kmsThriftAddress: 127.0.0.1:9090 and kmfThriftAddress: 127.0.0.1:9900
21:46:58.489 [ main] DEBUG - com.kurento.kmf.thrift.ThriftServer - Thrift server started in /127.0.0.1:9900
21:47:01.263 [ main] INFO - c.k.kmf.connector.MediaConnectorApp - Started MediaConnectorApp in 12.687 seconds (JVM running for 15.304)
22:17:41.871 [888-exec-1] INFO - c.k.k.j.i.ws.JsonRpcWebSocketHandler - Client connection stablished from /192.168.1.104:54540
All of that is from standard output. There is no media-connector.log file:
$ ls -a /var/log/kurento
. .. media-server.log
$
Hopefully, this is sufficient data...
The result of the netstat command:
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 32258/cupsd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 552/smbd
tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN 30653/kurento <== I presume this is the important line
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 552/smbd
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN 1046/dnsmasq
tcp6 0 0 ::1:631 :::* LISTEN 32258/cupsd
tcp6 0 0 :::8888 :::* LISTEN 1547/java
tcp6 0 0 :::445 :::* LISTEN 552/smbd
tcp6 0 0 :::9090 :::* LISTEN 30653/kurento <== As is this one
tcp6 0 0 127.0.0.1:8005 :::* LISTEN 2345/java
tcp6 0 0 :::8009 :::* LISTEN 2345/java
tcp6 0 0 :::139 :::* LISTEN 552/smbd
tcp6 0 0 127.0.0.1:9900 :::* LISTEN 1547/java
tcp6 0 0 :::8080 :::* LISTEN 2345/java
The result of the ps grepping kmf:
rbrown3 1547 9.3 1.7 2796820 141452 pts/15 Sl+ 21:46 0:13 /home/rbrown3/software/java7/bin/java -jar ./lib/kmf-media-connector.jar --server.port=8888 --thrift.kms.address=127.0.0.1:9090 --thrift.kmf.address=127.0.0.1:9900
rbrown3 1592 0.0 0.0 15940 916 pts/0 S+ 21:49 0:00 grep --color=auto kmf
The result of the ps grepping kurento:
rbrown3 1595 0.0 0.0 15940 920 pts/0 S+ 21:49 0:00 grep --color=auto kurento
nobody 30653 0.0 0.1 298504 11292 ? Sl Aug28 0:00 /usr/bin/kurento
And for completeness, here is the contents of /var/log/kurento:
$ ls /var/log/kurento
media-server.log
$
As stated, there is no media-connector.log file anywhere on my system. I am getting debugging information on standard output, though. Below is the output that has been generated from when I deliberately restarted the connector to when I hooked in from the loopback application:
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v1.0.0.RC1)
21:46:49.774 [ main] INFO - c.k.kmf.connector.MediaConnectorApp - Starting MediaConnectorApp v4.2.10 on AphrodetteBox with PID 1547 (/home/rbrown3/software/connect/lib/kmf-media-connector.jar started by rbrown3)
21:46:49.781 [ main] DEBUG - c.k.kmf.connector.MediaConnectorApp - Running with Spring Boot v1.0.0.RC1, Spring v4.0.1.RELEASE
21:46:57.660 [tartStop-1] DEBUG - c.k.k.j.i.s.config.OAuthFiWareFilter - Initializing filter 'applicationContextOAuthFilter'
21:46:57.661 [tartStop-1] DEBUG - c.k.k.j.i.s.config.OAuthFiWareFilter - Filter 'applicationContextOAuthFilter' configured successfully
21:46:58.196 [ main] INFO - c.kurento.kmf.media.factory.KmfMediaApi - Creating JsonRpcClient with Thrift transport. Prefix: null
21:46:58.197 [ main] INFO - c.kurento.kmf.media.factory.KmfMediaApi - kmsThriftAddress: 127.0.0.1:9090 and kmfThriftAddress: 127.0.0.1:9900
21:46:58.489 [ main] DEBUG - com.kurento.kmf.thrift.ThriftServer - Thrift server started in /127.0.0.1:9900
21:47:01.263 [ main] INFO - c.k.kmf.connector.MediaConnectorApp - Started MediaConnectorApp in 12.687 seconds (JVM running for 15.304)
22:17:41.871 [888-exec-1] INFO - c.k.k.j.i.ws.JsonRpcWebSocketHandler - Client connection stablished from /192.168.1.104:54540
All of that is from standard output. There is no media-connector.log file:
$ ls -a /var/log/kurento
. .. media-server.log
$
Hopefully, this is sufficient data...
LuLop
Sep 1, 2014, 5:41:13 PM9/1/14
to kur...@googlegroups.com
It seems the connection between client and connector is being established but the client library is not sending any request message. We are not being able to reproduce this issue in our facilities. It's quite strange. I imagine you are not using a javascript debugger with breakpoints or things like that. Apart from that, I've got no clues on what could be problem. I would need to be able to open a WebSocket connection to your connector for issuing a diagnose.
L.
Robert Brown III
Sep 1, 2014, 7:16:16 PM9/1/14
to kur...@googlegroups.com
Actually, I have a debugger on my Firefox browser. It is a full debugger which I used previously to prove that I was talking to the connector.
What should I be looking at?
What should I be looking at?
LuLop
Sep 2, 2014, 12:43:10 PM9/2/14
to kur...@googlegroups.com
Could you please use Wireshark and capture the traffic of the Kurento box on all interfaces while you run the demo? This could provide some clues on what's happening.
L.
Robert Brown III
Sep 3, 2014, 7:04:21 PM9/3/14
to kur...@googlegroups.com
Yes, I can do this. I'll let you know when I have something...
Robert Brown III
Sep 13, 2014, 3:17:38 PM9/13/14
to kur...@googlegroups.com
Greetings:
I was finally able to fo some debugging, and I found something.
There is an exception being thrown on the client side in the kws-media-api.js file. Something about a "kwsMedia" being null.
I am investigating further, but insights on what this kwsMedia needs to be set to would be helpful...
I was finally able to fo some debugging, and I found something.
There is an exception being thrown on the client side in the kws-media-api.js file. Something about a "kwsMedia" being null.
I am investigating further, but insights on what this kwsMedia needs to be set to would be helpful...
pir...@gmail.com
Sep 13, 2014, 3:19:21 PM9/13/14
to kur...@googlegroups.com
Could you be able to send us the full trace of the exception?
--
Robert Brown III
Sep 13, 2014, 3:36:20 PM9/13/14
to kur...@googlegroups.com
I'm not sure how to do this. I am using WebDeveloper to catch the exception and it doesn't look like webdeveloper provides a stack trace (that I know of).
I am somewhat of a beginner debugging Javascript.. Can you tell ne how to get the stack trace?
I am somewhat of a beginner debugging Javascript.. Can you tell ne how to get the stack trace?
Robert Brown III
Sep 13, 2014, 4:05:38 PM9/13/14
to kur...@googlegroups.com
Please ignore my last post. I figured out a way to get a stack trace.
I ended up editing the file where the exception was occurring. This file is kws-media-api.js. The code fragment below is from that file, lines 248 - 271. Theline that I added is marked.
The console.error line apparently writes a full stack trace to the console (correct me if I am wrong).
I ran the application. After allowing the application access to my camera and microphone, I checked the console output.
The exception occurs after the following console output:
Below are the exception details and trace:
Is that sufficient information? Please let me know if you need any more.
I ended up editing the file where the exception was occurring. This file is kws-media-api.js. The code fragment below is from that file, lines 248 - 271. Theline that I added is marked.
// Promise interface ("thenable")
this.then = function(onFulfilled, onRejected)
{
return new Promise(function(resolve, reject)
{
function success()
{
var result;
if(onFulfilled)
try
{
result = onFulfilled(self);
}
catch(exception)
{
console.error(exception); <== I added this line here!
return reject(exception);
}
resolve(result);
};
The console.error line apparently writes a full stack trace to the console (correct me if I am wrong).
I ran the application. After allowing the application access to my camera and microphone, I checked the console output.
The exception occurs after the following console output:
"Creating KwsMedia ..." demo.js:33
Below are the exception details and trace:
TypeError: kwsMedia is null
Stack trace:
startVideo/onOffer/<@http://192.168.1.14:8080/demo.js:35:4
KwsMedia/<@http://192.168.1.14:8080/bower_components/kws-media-api/js/kws-media-api.js:304:5
success@http://192.168.1.14:8080/bower_components/kws-media-api/js/kws-media-api.js:261:13
[64]</EventEmitter.prototype.emit@http://192.168.1.14:8080/bower_components/kws-media-api/js/kws-media-api.js:8693:7
[97]</module.exports/</attempt/<@http://192.168.1.14:8080/bower_components/kws-media-api/js/kws-media-api.js:14307:13
[64]</EventEmitter.prototype.emit@http://192.168.1.14:8080/bower_components/kws-media-api/js/kws-media-api.js:8668:9
[104]</</WebsocketStream.prototype.onOpen@http://192.168.1.14:8080/bower_components/kws-media-api/js/kws-media-api.js:14945:3
kws-media-api.js:265
Is that sufficient information? Please let me know if you need any more.
pir...@gmail.com
Sep 13, 2014, 4:28:13 PM9/13/14
to kur...@googlegroups.com
What demo are you running? Can you send us demo.js file?
Robert Brown III
Sep 14, 2014, 2:15:20 PM9/14/14
to kur...@googlegroups.com
Jesus:
The demo is one of your samples: the WebRtcLoopback demo. I just downloaded it, installed the necessary server- side components (the connector) and ran it. There shouldn't be anything new (to you guys) in this code. The only thing different in my copy of the application is the addition of that console.error() call that I made in kws-media-api.js yesterday.
As you can see from the attached copy of demo.js, it is your WebRtcLoopback demo.js file...
The demo is one of your samples: the WebRtcLoopback demo. I just downloaded it, installed the necessary server- side components (the connector) and ran it. There shouldn't be anything new (to you guys) in this code. The only thing different in my copy of the application is the addition of that console.error() call that I made in kws-media-api.js yesterday.
As you can see from the attached copy of demo.js, it is your WebRtcLoopback demo.js file...
LuLop
Sep 14, 2014, 4:19:47 PM9/14/14
to kur...@googlegroups.com
What version of kws-media-api are you using? If I'm not wrong in 4.3.17 a bug with the symptoms you describe was fixed.
L.
--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<demo.js>
pir...@gmail.com
Sep 14, 2014, 6:48:15 PM9/14/14
to kur...@googlegroups.com
I think problem is in that line :
KwsMedia(ws_uri, function(kwsMedia){
Recently we changed the signature of the function from two callbacks
(success and failure) to one callback with an error and an
kurentoClient argument, making it Node.js compliant, and that's the
reason why you are getting kwsMedia as null (in fact, you are getting
"no errors" :-) ). As Luis has told you, this have been fixed on the
demos in a rec release, please update the demos source code that you
are using.
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux
KwsMedia(ws_uri, function(kwsMedia){
Recently we changed the signature of the function from two callbacks
(success and failure) to one callback with an error and an
kurentoClient argument, making it Node.js compliant, and that's the
reason why you are getting kwsMedia as null (in fact, you are getting
"no errors" :-) ). As Luis has told you, this have been fixed on the
demos in a rec release, please update the demos source code that you
are using.
> --
> You received this message because you are subscribed to the Google Groups
> "kurento" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kurento+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
> You received this message because you are subscribed to the Google Groups
> "kurento" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kurento+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux
Robert Brown III
Sep 14, 2014, 9:48:08 PM9/14/14
to kur...@googlegroups.com
OK, all:
Where is the page with the latest demos and kws media API??? There seems to be no direct link to those demos on any of the many kurento websites I found, and when I originally found the demos it was pretty much by accident. So: where are they???
Where is the page with the latest demos and kws media API??? There seems to be no direct link to those demos on any of the many kurento websites I found, and when I originally found the demos it was pretty much by accident. So: where are they???
LuLop
Sep 15, 2014, 2:39:50 AM9/15/14
to kur...@googlegroups.com
The Kurento.org web site is currently under revision. A mayor revision of the documentation, the structure of the APIs and the Media Server will be released on the next few days.
L.
El 15/09/2014, a las 03:48, Robert Brown III <robertbr...@gmail.com> escribió:
OK, all:
Where is the page with the latest demos and kws media API??? There seems to be no direct link to those demos on any of the many kurento websites I found, and when I originally found the demos it was pretty much by accident. So: where are they???
Robert Brown III
Sep 15, 2014, 4:26:09 AM9/15/14
to kur...@googlegroups.com
Does this revision include the latest demo and API files? Can I get those at this time? If so, where are they?
LuLop
Sep 15, 2014, 5:16:49 AM9/15/14
to kur...@googlegroups.com
We'll publish all the information shortly, please, have some patience. Anyway, if you want to take a look, start here:
Robert Brown III
Sep 15, 2014, 8:20:25 PM9/15/14
to kur...@googlegroups.com
Thanks for the pointers.
I see that the kws API dependencies listed in the loopback demo's bower.json file all still point to version 4.3.17 -- which according to you and Jesus are versions that I *don't* want to use.
Could you or someone inform me when the "fixed" versions of the API (4.3.18?) will be available so I can begin performing proper tests?
Thanks.
I see that the kws API dependencies listed in the loopback demo's bower.json file all still point to version 4.3.17 -- which according to you and Jesus are versions that I *don't* want to use.
Could you or someone inform me when the "fixed" versions of the API (4.3.18?) will be available so I can begin performing proper tests?
Thanks.
pir...@gmail.com
Sep 15, 2014, 8:23:39 PM9/15/14
to kur...@googlegroups.com
We are releasing version 5.0.0 in some days, you can be able to fetch its code from the develop branch on our GitHub repo, but probably it could be a little bit unstable yet...
Robert Brown III
Sep 17, 2014, 7:53:29 AM9/17/14
to kur...@googlegroups.com
I am willing to "play" with the 5.0.0 pre- release and identify any bugs I find.
I am a bit of a Github novice. How do I get the version 5 demos?
I am a bit of a Github novice. How do I get the version 5 demos?
LuLop
Sep 17, 2014, 9:52:41 AM9/17/14
to kur...@googlegroups.com
Compiling from sources is complex. The release is almost ready. We're just cleaning and it'll be published with certainty before the end of the week. My recommendation for you is to wait a little bit.
L.
Robert Brown III
Sep 22, 2014, 3:19:02 PM9/22/14
to kur...@googlegroups.com
OK... will do...
I preume you will announce when the release is actually made? Please inform me when it is and where I can get it...
I preume you will announce when the release is actually made? Please inform me when it is and where I can get it...
Ivan Gracia
Sep 24, 2014, 4:28:38 AM9/24/14
to Kurento Public
Yes Robert, there will be an announcement made about the release. Keep a close eye these days ;-)
Ivan Gracia
Robert Brown III
Oct 9, 2014, 12:26:40 AM10/9/14
to kur...@googlegroups.com
I have upgraded to the Version 5.0.4 and am running the Java version of Tutorial 1.
It appears to be working without problems.
I do have other difficulties, but these seem to be WebRTC based and are not related to Kurento.
Thanks to all who helped with this issue...
It appears to be working without problems.
I do have other difficulties, but these seem to be WebRTC based and are not related to Kurento.
Thanks to all who helped with this issue...
Ivan Gracia
Oct 9, 2014, 8:38:37 AM10/9/14
to Kurento Public
Thank you for your feedback! Could you explain what problems you are having with webrtc?
Cheers,
Ivan Gracia
Robert Brown III
Oct 14, 2014, 7:05:06 PM10/14/14
to kur...@googlegroups.com
I'll be happy to enumerate the problems, if you wish. I have already posted them on the WebRTC discussion board. Note that the test code I describe is a basic getUserMedia() test client (which I wrote to consistently replicate my problem). This is what convinced me that it is a WebRTC problem, not a Kurento problem. Nevertheless, it does manifest even with the latest Kurento clients...
I am running the following Javascript code:
My HTML file is simple enough and has a basic video tag:
The text above describes the problem as I mentioned it in the discuss-webrtc. Because the getUserMedia() function does not appear to operate consistently on different machines with the same browser versions and operating systems, then the WebRTC technology on which Kurento is based does not work consistently enough to be able to deploy any applications based on it -- including Kurento's Javascript clients.
This problem can only be detected by someone (like me) who uses multiple machines that are (apparently) configured slightly differently from each other. I suspect that the problem is ne of configuration where something is either different or missing on the machines where the getUserMedia() call is failing. I just have no idea what the problem could be.
If your machine has this problem, it will show up immediately when you use the Tutorial 1 client (the loopback application) with Kurento. The local view simply will not display, and neither will the remote view. On machines where it works, the client will have no problems at all.
Have any of the Kurento users or developers seen this problem. Has anyone run into a situation where the getUserMedia() function is failing to operate for some reason? If so, did you find out what was causing the problem? Did you find a way to fix it?
Someone please advise...
I am running the following Javascript code:
navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia
|| navigator.mozGetUserMedia || navigator.msGetUserMedia;
/*
* Set up desired constraints
*/
var constraints = { audio:false,video:true };
/*
* This function to be called upon successful stream creation(?)
*/
function madeStream(aStream) {
var video = document.querySelector("video");
window.stream = aStream;
video.src = window.URL.createObjectURL(aStream);
/*
* At this point, we play the video!
*/
video.play();
}
/*
* This function is to be called should the attempt to create the stream fail.
*/
function failureWarning(theFail) {
alert("Failed to get user media! "+theFail);
}
if(navigator.getUserMedia) {
navigator.getUserMedia(constraints,madeStream,failureWarning);
}
else
{
alert("This video function is not supported on this browser!");
}
My HTML file is simple enough and has a basic video tag:
<video autoplay></video>
I've checked the code several times against API documentation. As far as I know I am using it correctly.
The problem is, that the video does not behave consistently across my browsers. This inconsistency is not between different browsers, but between installations of the same browser!
I am attempting to run this test on 4 different machines:
Machine 1 is a Macintosh that is running Firefox Version 31.0
Machine 2 is a Windows machine running Windows 7 and Firefox Version 31.0
Machine 3 is a Windows laptop that is running Windows 8.0 and Firefox Version 31.0
Machine 4 is a Windows laptop that is running Windows 81 and Firefox Version 31.0
Note for emphasis: all machines are using Firefox Version 31.0.
All machines, when accessing the web page, properly request access to the camera (note: in my constraints the audio is set to false).
When I grant access on Machine 1, I see the local video.
When I grant access on Machine 2, I see nothing.
When I grant access on Machine 3, I see the local video.
When I grant access on Machine 4, I see nothing.
Important note: The camera turns on on all machines. Debugging the Javascript code, I see that the MediaStream object is successfully acquired and that the video play function is successfully called.
Further debugging reveals that the video source is dynamically changed to reflect the acquired MediaStream object. A typical result of adding the object to the video tag is shown below:
<video src="mediastream:f7b34f2e-55d5-9148-ae7c-dfec4e436dde" autoplay=""></video>
This all happens in the same way on all machines, again all running the same version of Firefox.
I have further discovered that when the video tag is first rendered on the browser it appears as an empty Flash object. On Machines 1 and 3, this object changes to a working MediaStream video the moment the video tag's source is changed. For some reason, on Machines 2 and 4, the video tag does not update, but continues showing as a Flash object which remains empty (appearing to show nothing).
I originally thought the problem was a Firefox bug or
misconfiguration, so I downloaded the latest version of Chrome onto the 4
machines and tested them. The behavior is exactly the same in Chrome on
all 4 machines. The only difference is that on the machines where the
Flash video didn't change, there is a black blank box where the flash
object is.
I know the following about the problem:
It isn't the browser because the behavior is the same in Chrome and Firefox.
It isn't the browser version because they are all the same version.
It isn't the operating system because one is working on a Macintosh and another on a version of Windows.
I considered the possibility it was the camera driver or the OS version. I updated everything. The behavior is the sameThe text above describes the problem as I mentioned it in the discuss-webrtc. Because the getUserMedia() function does not appear to operate consistently on different machines with the same browser versions and operating systems, then the WebRTC technology on which Kurento is based does not work consistently enough to be able to deploy any applications based on it -- including Kurento's Javascript clients.
This problem can only be detected by someone (like me) who uses multiple machines that are (apparently) configured slightly differently from each other. I suspect that the problem is ne of configuration where something is either different or missing on the machines where the getUserMedia() call is failing. I just have no idea what the problem could be.
If your machine has this problem, it will show up immediately when you use the Tutorial 1 client (the loopback application) with Kurento. The local view simply will not display, and neither will the remote view. On machines where it works, the client will have no problems at all.
Have any of the Kurento users or developers seen this problem. Has anyone run into a situation where the getUserMedia() function is failing to operate for some reason? If so, did you find out what was causing the problem? Did you find a way to fix it?
Someone please advise...
pir...@gmail.com
Oct 15, 2014, 2:28:42 AM10/15/14
to kur...@googlegroups.com
Definitely, it's a getUserMedia related problem. The first thing I would do is to use Google adapter.js instead of remove by hand the prefixes as you are doing. You should find the URL to the latest version on the tutorials. Besides that, our main test platform is Chrome Dev on Ubuntu, could you be able to check that?
--
Ivan Gracia
Oct 15, 2014, 8:09:38 AM10/15/14
to Kurento Public
Have you tried with other versions of Firefox or with Chrome? We are using Chome (now versions 38 and 40 -dev-) and Firefox (now ver. 32), under Ubuntu and Mac, and can't recall having this problem.
If you get any feedback from the other list, please let us know!
Ivan Gracia
Robert Brown III
Oct 23, 2014, 2:35:00 PM10/23/14
to kur...@googlegroups.com
Greetings:
I *am*using adapter.js with the tutorial code. As previously stated, the test code that I provided was merely designed to provide a simple piece of code that illustrates the problem. The problem occurs in exactly the same way whether I run my test code or I run the Tutorials that use adapter.js. It is a pretty consistent problem that indicates some kind of failure that occurs when the getUserMedia() function is called. It dosn't matter whether the function is called directly or through adapter.js. The failure occurs on certain machines when it is called.
As for your use of Chrome, you can still duplicate the problem, because it occurs whether you use Firefox or Chrome. I would suggest, however, that you might want to test on operating systems other than Ubuntu if you want to see the problem. If you want to consistently duplicate this problem you will need at least 3 Windows systems. I am seeing this failure more on Windows systems than I am on any Linux- derived systems (including Fedora, Ubuntu, and Mac-OS).
I *am*using adapter.js with the tutorial code. As previously stated, the test code that I provided was merely designed to provide a simple piece of code that illustrates the problem. The problem occurs in exactly the same way whether I run my test code or I run the Tutorials that use adapter.js. It is a pretty consistent problem that indicates some kind of failure that occurs when the getUserMedia() function is called. It dosn't matter whether the function is called directly or through adapter.js. The failure occurs on certain machines when it is called.
As for your use of Chrome, you can still duplicate the problem, because it occurs whether you use Firefox or Chrome. I would suggest, however, that you might want to test on operating systems other than Ubuntu if you want to see the problem. If you want to consistently duplicate this problem you will need at least 3 Windows systems. I am seeing this failure more on Windows systems than I am on any Linux- derived systems (including Fedora, Ubuntu, and Mac-OS).
Robert Brown III
Oct 23, 2014, 2:45:00 PM10/23/14
to kur...@googlegroups.com
Ivan:
As I told Jesus earlier, Linux- derived systems do not seem to have this problem (so far). Note that one of the machines I tested on is a Mac-OS machine.
I am seeing the problem on *some* Windows machines (please check my description of the 4 machines I used). The browser used and the version used is irrelevant (as long as the browser supports WebRTC). In order to see this problem, it needs to be tested on more than one Windows machine.
If you want to replicate this problem, you need more than one Windows machine. You need to test it on more than one because on some Windows machines the screens come up as they should, while on others they do not -- even if you use the same browser and version on both machines. I cannot predict which Windows machines will display screens properly and which will not, because I do not know what factor is causing the failures on the machines where the views fail.
As I told Jesus earlier, Linux- derived systems do not seem to have this problem (so far). Note that one of the machines I tested on is a Mac-OS machine.
I am seeing the problem on *some* Windows machines (please check my description of the 4 machines I used). The browser used and the version used is irrelevant (as long as the browser supports WebRTC). In order to see this problem, it needs to be tested on more than one Windows machine.
If you want to replicate this problem, you need more than one Windows machine. You need to test it on more than one because on some Windows machines the screens come up as they should, while on others they do not -- even if you use the same browser and version on both machines. I cannot predict which Windows machines will display screens properly and which will not, because I do not know what factor is causing the failures on the machines where the views fail.
Ivan Gracia
Oct 24, 2014, 6:34:40 AM10/24/14
to Kurento Public
Hi Robert,
Many thanks for your detailed description! We will try and put our hands in different windows machines, and see if we can reproduce this issue. Couple of question only, that I might have missed but just to have a clear view:
- Are all the Windows machines exactly the same? Same version, installed updates and installed programs, I mean.
- Is the same machine always failing, or does it depend on the order of connection?
Once again, thanks for the thorough report. It really helps a lot.
Ivan Gracia
Reply all
Reply to author
Forward
0 new messages