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.
Related
Google Chrome scheduled for M74 release that the mDNS support for local ICE candidates will be involved in the browser to increase privacy.
This feature is controlled by the feature flag -enable-webrtc-hide-local-ips-with-mdns ;
I am trying to test the effect of mDNS support for WebRTC users on Google Chrome. I am testing with my custom WebRTC App and execute below test steps before making call;
1- WebRTC clients are logged in with using identical mDNS broadcast domains,
2- mDNS in Google Chrome Canary is enabled via -enable-webrtc-hide-local-ips-with-mdns flag on both party,
After the call has been generated, I saw that WebRTC agents are replaced their private IP's with anonymous local IP's which are followed by ".local";
Also I detect that the call signaling is generated and the media stream is performed successfully, but the ICE candidates are chosen from relay candidates(used TURN Server), not host candidates;
I think the parties cannot resolve their anonymous IP's and select to establish communication on existing TURN Server (use relay candidates).
I am sure that the clients are under the same subnet, but why they cannot resolve each other's anonymous IPs? I know that the nodes are broadcasted their anonymous IPs via 5353 port of mDNS and I expected that they will resolve the IPs easily. Is there anything that I missed during testing?
Your assistance would be highly appreciated. Thanks a lot
I have successfully compiled source code of doubango opentelepresence system (An open source video conference MCU) and successfully tested. I can make video calls through desktop version and using webrtc (sipml5 client) with Chrome and Firefox (with some modifications because the sipml5 was not compatible with newer versions).
Now my problem is with NAT traversal. I want to make video calls between clients behind NAT using turn server. The MCU server is behind NAT (SIP port is on public IP using port forwarding and tcp sip and ws connection is available). I have installed coturn Turn Server on a ubuntu system, and configured it using command line as like why the turn server does not support for the tcp connection. The turn server ports is open on public ip. I have also tested both udp and tcp but not successful.
On the mcu, ice, stun and turn is enabled. I have set turn server url and credentials correctly and the mcu can successfully communicate with turn server. Also webrtc on the browsers can successfully communicate with turn server (I say successful communication, because I can see candidates are being generated).
I have two major problems:
For some reasons related to firewall, I prefer to use only tcp relay. But in test environment, I have tested both with udp and tcp but not successful. It seems doubango opentelepresence does not support relayed tcp, because I cannot see any candidate with relayed tcp (there are udp relayed candidates).
What is wrong with my configuration which I was never successful on making a call. The ICE candidates are generated with public ip, but their state is always failed or frozen (what does frozen mean!). If you have any suggestions, let me know and try. I can test and report results here until reach a successful video call.
Yellow parts are public IP address (a valid IP address accessible on the internet for all clients).
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
I am trying to get a browser client to connect with my C++ linux application using WebRTC. So my environment is not the typical triangle WebRTC where 2 browsers setup a WebRTC call thru a server. Instead, the browser client side is typical, but my application is acting as the server and the remote client, so it does the signalling and also streams the SRTP media using gstreamer.
I am successful up to a point. I have successfully exchanged the ice candidates and the offer/answer SDP exchange is also successful. The browser ICE connection state successfully goes to "checking" and at that point I am stuck.
Question: Is the server or remote browser involved in the ice checking operations? That is, does the browser do the ICE checking with the STUN server or with the actual candidate address from the remote end. That would then imply that my C++ application has to be involved in that checking process.
Thanks,
-Andres
your server needs to respond to STUN binding requests at least which are sent as part of ICE.
If your server always has a public IP, using ice-lite (see RFC 5245) will make your life a lot easier.
I read that WebRTC uses relay servers, if the direct peer connection doesn't work because of firewalls.
Is there a way to check, if this is the case?
When you establishing WebRTC connection, you set STUN and/or TURN for a web browser to use. If you informed a web browser with the both options, web browser will start trying to use STUN first. Then, in case of unsuccess it will try to use TURN.
The 'relay server' is a TURN-server.
As I know, there is no standard way to know out which option a web browser decided to use: STUN or TURN.
In other hand, if you're the owner of TURN server, you can see whether web client does use it or not, and then send this information to the client.
UPDATED
This is my code: https://github.com/fycth/webrtcexample/blob/master/www/js/rtc_lib.js
You can see there I use just STUN server, so it is p2p or nothing, and no relay.
In chrome. go to chrome://webrtc-internals, go to succeeded connection-googCandidate pair(in black letters) check if googLocalcandidatetype is relay, then webrtc uses relay connection . If googLocalcandidatetype is local, then it uses peer to peer connection
In firefox, go to about:webrtc, if the succeeded connection contains any candidate as relayed-udp, then webrtc uses relay connection