I have two different WebRTC clients: an Android device and an angular application. I set up a turn and stun server and both seems to work with the trickle ice tester and the webrtc tester.
As you can see here:
But all ice candidates fail in Firefox when I am watching the candidates in about:webrtc.
Does anyone have an explanation for this?
More info:
A similar error occurs in Google Chrome, but the logs are from Firefox because Firefox has better logging.
The devices are on different networks, so the host request should fail and the turn server is needed.
The turn server is a coturn turn server, but I also tried it with a Pion turn server and the same result occurs.
Firfox logs: https://gist.github.com/Nick-v-L/365b7da10039d28a6a23a27fea15df52
Coturn logs: https://gist.github.com/Nick-v-L/04c3cfc677847e3cdcb7f6b5ca15c743
There was a simple error in my Android app. When receiving an ice candidate from the signaling server I did the following:
peerConnection.AddIceCandidate(new IceCandidate(sdpCandidate, sdpMLineIndex, sdpMid));
But as the documentation states you have to create an ice candidate in this order:
public IceCandidate(string sdpMid, int sdpMLineIndex, string sdp);
So I turned the sdpCandidate and sdpMid around to fix the issue.
peerConnection.AddIceCandidate(new IceCandidate(sdpMid, sdpMLineIndex, sdpCandidate));
Related
I'm hosting a video call site on Heroku here. My coturn server is Docker-containerized and runs locally behind a router. I opened all the needed ports (3478, 40000-65535) so that I am sure that the corturn server works over the Internet because I checked it using Trickle ICE.
Everything is fine except the video is not transferred when two devices are not on the same network. Any help?
Are you sure your code is using the TURN server?
You need to pass the iceServers list with the TURN URL and correct credentials. See for example https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setConfiguration
Then when you start the ICE gathering, you should see in coturn's log whether the Allocate Request was correctly handled and a XOR-RELAYED-ADDRESS returned.
But you can also see it on the client side (the laptop where the browser runs) by launching a tool like Wireshark and selecting stun as filter.
In addition, when the call is up, check in chrome://webrtc-internals whether ICE gathering has provided relay candidates.
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.
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
Does not work the connection between clients provided that one client uses the 3G network.
The configuration of server uses STUN and TURN.
The problem starts at the stage ICE. In console of Firefox browser the message: "ICE failed. Your TURN server appears to be broken."
The logs of WebRTC shows the next (shorted):
"
(stun/INFO) TURN Timed out
(turn/WARNING) mode 20
(turn/WARNING) nr_turn_client_error_cb
(turn/WARNING) failed
(turn/INFO) cancelling
(turn/WARNING) nr_turn_allocated_cb called with state 4
(turn/WARNING) nr_turn_allocated_cb failed
(stun/INFO) Timed out
(ice/INFO) All pairs are failed, and grace period has elapsed. Marking component as failed.
"
Do you know the standard solution for this problem?
I'm interested in WebRTC these days, so I don't know the exact cause, but I would like to help you.
When I look at this "error message", it appears that you can't connect to the TURN server when you are connected to a 3G network.
1) Check if there is a TURN server on a private network.
2) Make sure that the ISP (Internet service provider) supplying your 3G network is blocking access to this TURN server.
3) Or, make sure that the firewall on the TURN server only allows only specific IP connections.
4) Other...
Network problems are so diverse that you have to check each one to find out the exact cause.
Thank you.
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.