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
Related
In my case, I have a webrct based web app that supports multi-parti video chat and has STUN and TURN servers configured. The connections are done in a mesh way (peer to peer) What happens when some of the users involved in the video chat need to establish the connection via TURN? Do all of the users start to use TURN? What if I'm the user that's behind a NAT? Does that mean that all connections established with me are using TURN?
Connections are peer to peer, so if one connection uses TURN then it doesn't affect other peer to peer connections.
If the user is behind a NAT, he may not need TURN in some cases: all depends on the type of the NAT.
Is it possible to have Asterisk as the signaling server for WebRTC enabled mobile app. I have found that I need to create the signaling server in node.js. I was wondering whether Asterisk can do the job for me.
Also, does the WebRTC media pass through the signaling server (or) is it direct device to device media transfer.
Any help is appreciated. Thank you. :)
If you want WebRTC signal switching alone then you can use some websocket server like socket.io but it won't handle STUN or TURN.
If you want WebRTC signalling along with STUN,TURN and media recording then you can go with Kurento, Freeswitch, asterisk etc.
If you carry media over signalling server then you might consume more CPU and memory processing on server side. Try to keep peer-peer direct media to get better audio and video.
But in all these case you need to register your endpoints to the signalling server. So if you call B from A. the signalling server knows where B is!
Is it possible to have Asterisk as the signalling server for WebRTC enabled mobile app?
Of course. Just use SIP over websocket (RFC 7118). See this Asterisk WebRTC setup guide for the details. If you already have an Asterisk server, then there is no need to implement a separate signaling server in node.js.
Also, does the WebRTC media pass through the signaling server (or) is it direct device to device media transfer.
This is handled automatically by ICE. Ideally your goal should be to have as many peer to peer media as possible to minimize the server load. However in some situations a relay is required which can be the Asterisk server itself or a separate TURN server. Also make sure to set the STUN correctly (that is required for STUN to find the direct path)
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 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 have developed a p2p video chat using Webrtc. I am aware that STUN or TURN server is required to identify the public IP behind NAT. Currently am using Google's STUN server.
I have the application installed in the server connected to the LAN which will not have internet access, do I need to install the STUN server in my server to make Webrtc video chat work within the LAN?
Peers should be able to connect within a LAN (on the same side of a NAT) without STUN, i.e. using the host candidates. Try it out!
In general, you won't need a STUN server. However, depending on the firewall configuration, you may actually need STUN (and even TURN). For example, at the SFHTML5 WebRTC Hackathon, we were on a corporate guest WiFi network that blocked local UDP and TCP traffic. Making successful calls required a TURN server in this case.