I have build a one to one webrtc communication system (peer to peer). I use coturn as a STUN and as TURN.
The connection works in chrome (72) and firefox (65) whithot VPN.
The connection also works in chrome and firefox, when behind a symetric NAT (for example while using a mobile-phone).
The connection works also when using VPN and chrome.
The connection (ICE) failed, when using VPN and firefox!
Testet with a couple of popular VPN's.
Any Ideas, what could be wrong/ how to solve?
My TURN-Server Configuration looks like:
listening-port=3478
tls-listening-port=5349
realm=xyz.com
min-port=49152
max-port=65535
user=uuuuuuuuuuuuu:ppppppppppp
pkey=/usr/local/psa/var/modules/letsencrypt/etc/live/turn.xyz.net/privkey.pem
cert=/usr/local/psa/var/modules/letsencrypt/etc/live/turn.xyz.net/cert.pem
CA-file=/usr/local/psa/var/modules/letsencrypt/etc/live/turn.xyz.net/chain.pem
mysql-userdb="host=localhost dbname=turnxxxxxx user=uuuuuuuuuuuu password=ppppppppppp port=3306"
fingerprint
lt-cred-mech
You should expect any WebRTC-related application to fail in all browsers, when VPN is on. I have exactly opposite situation - when VPN is on, no browser works except FireFox.
And in my app no TURN servers are used at all.
Somehow my VPN misses FireFox.
In general, WebRTC is prohibited by VPNs, because of IP address leak paranoia. Your real IP address can leak through signaling messages and STUN binding response, so once VPNs see STUN binding requests, they just kill it. VPNs cannot kill your signaling messages so your private IP can still leak, but that's a problem only with IPV6, where private and public IPs are the same. But, when it's time for STUN binding request/respose, VPNs kill it. Not sure how your Chrome survives.
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 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.
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