I have successfully run the "one2one-call" Kurento tutorial using a Windows KMS server, but am unable to see remote video when one of the peers is on a different network.
I have two laptops (one for each peer). One of these laptops is also running the Windows KMS server and the Application server.
I have also enabled port forwarding so that both peers can navigate to the web browser using the public IP and port number.
This works when both laptops are connected to the same network; but when I connect one of the laptops to another network, the remote video is no longer displayed. I can view the UI, register and attempt a call, additionally, when attempting the call, a notification does pop up on the remote peer and both peers get the popup requesting permission to access the microphone and camera, but no remote video. Each peer is only able to see their own image.
Would appreciate any information.
Did you configure STUN and TURN in KMS config file? (WebRtcEndpoint.conf.ini)
Try adding STUN server to config file. You can use google's STUN server.
stunServerAddress=74.125.143.127
stunServerPort=19302
If adding STUN to config did not work, you need TURN. If either of these networks have restrictive firewalls you will need to set up TURN server and add it to KMS configuration.
turnURL=USER:PASS#YOUR_MACHINE_PUBLIC_IP:<PORT>
You will also need to modify JavaScript for browser to use TURN.
For the reference: http://doc-kurento.readthedocs.io/en/stable/installation_guide.html#stun-and-turn-servers
Related
I was curious on why a client cannot directly to a machine running webrtc server but can do that via turn server. Both turn & webrtc are in same VPC of AWS.
Could be a lot of things.
Assuming you have the TURN configuration file correct, and as you are noting both AWS instances have public IPs, then it's possible that on the instance with the TURN server, you do not have all the firewall ports opened needed related to the TURN server: https://stackoverflow.com/a/59212004/8201657
Or, maybe it's a DNS issue and the domain of your TURN server is unknown to your peer, so it is not able to access it.
Or, maybe you are attempting to connect via WebRTC but not securely. WebRTC requires a secure connnection (https).
I am trying to make video calls with WebRTC and Janus. I am able to make calls using the video call demo page supplied by Janus as well as through an iOS app - this is all working perfectly fine.
However, when inspecting the network flow through both wireshark and chrome://webrtc-internals/ the connection does not seem to be directly to the public IP of the other device. Instead the data is directed to my Janus signaling server. It seems that the IP of the remoteIceCandidate is equal to the IP of my signaling server - shouldn't this should be equal to the public IP of device 2?
Is this correct behavior or not? If so, why is the remote IP not equal to the public IP of device 2? If not, what am I doing wrong?
This is correct behavior and a mistake on my part. The Janus video call plugin documentation says the following:
The idea is to provide a similar service as the well known AppRTC demo (https://apprtc.appspot.com), but with the media flowing through a server rather than being peer-to-peer.
Therefore, the media data is supposed to go to the server instead of over a peer-to-peer connection.
I had agora rtc integrated in my website few months back and it was running smoothly until recently when the remote video is not being seen, and upon checking in the console, there is an error that says
Agora-SDK [ERROR]: [866CE]None Ice Candidate not allowed.
Agora has provided the reason and solution to this problem in this documentation,
Reason:
When establishing a WebRTC connection, the SDK fails to find any ICE (Interactive Connectivity Establishment) candidate.
NOTE: A candidate contains the IP address and port information for connecting to a remote device.
Solution:
The type of candidates used for connection depends on whether you have enabled cloud proxy or not. Choose one of the following solutions accordingly.
If you have enabled cloud proxy, the SDK gets relay candidates from a TURN server. Check whether you have whitelisted the IP addresses and ports that Agora provides for cloud proxy, and ensure that the local client can connect to the TURN server.
If you have not enabled cloud proxy, the SDK gets host candidates from the local device. In this case, the error is usually caused by the security settings of the local device.
Check whether the browser has any plugins that disable WebRTC.
Ensure that you have enabled UDP in the system firewall, and added the specified domains and ports to the whitelist.
I have developed a WebRTC based application along with Kurento-Media-Server.
Problems with this application is:
It works but only on open network (i.e. if run on a network without firewall).
When in firewall it runs sometimes (once out of 10 attempts).
I have tried several things with the firewall, I have disabled all kind of incoming/outgoing traffic. I have created a port-forwarding for my application as well as Kurento-media server.
I am not sure how much useful this information might be but I am deploying my
application on the same physical box along with Kurento-Media-Server. I have configured google's STUN server on my client.js, I have also configured same STUN servers on kurento using code. I haven't configured TURN server.
Just confirming this, signaling server can be behind firewall along with rest of the application, correct?
I am not sure what to look for now, any help in this area would be great.
EDIT-1
From this link I learned that my current network on which my isn't working it has issues with plain websocket connection, it doesn't allow it, it only allows secure Websocket connections.
EDIT-2
Image of netscan:
In my phone network where my app works fine I see all greens in Websocket's "plain" column.
EDIT-3 Solved
Finally found the problem, We were using a router for testing and development and I found that the router had issues, I used LAN cable on the same router and everything worked fine. Calls from application were working just fine. Firewall related details help in configuring the firewall later on.
Based on your problem description it seems all the UDP traffic is not open in your firewall. WebRTC media run on UDP ports.As you mentioned it works one out of 10 times whch means only few UDP ports are open in your firewall.You are lucky when traffic comes via tose ports.You can open port-range in your firewall and configure the same in kurento-media-server config.Your job should be done.
Even if you configure TURN server you need to open certain ports for outgoing and incoming UDP traffic.For TURN server default port is 3478 or 8443 for sending data towards it but for incoming traffic you need to configure port-range on your TURN server and open those ports in your firewall. Always remember TURN server is assured way to connect but it's always costly.
I am using the google's TURN servers which is given in the demo, Sometimes the connection is established and remote video is streamed sometimes I just get a black screen instead of remote stream. Are these servers not reliable or is there any other issue because I can see the IP of the other machine on the peer which means the peer connection has been established. So what could be the possible problem is?
google doesn't provide any TURN server, only a STUN one.
There's a lot of situation where you need a TURN server, but as far as I know, there's no open TURN server. Even when the ip is detected, you can have problems with a proxy destroying the UDP stream or some of the ports needed.