We are doing some research regarding the behavior of Web RTC with the list of STUN/TURN servers provided. I cannot find any documentation so I am doing some tests but I hope someone can provide a clear explanation.
Following the documentation (https://developer.mozilla.org/en-US/docs/Web/API/RTCIceServer/urls) we can provide any number of servers.
But how does the RTCPeerConnection choose the server to use?
Does it try the first one and if it fails try the second one until one works?
Should all the servers be up and running or is the connection able to skip an unreachable server?
If the first server is able to conclude the negociation, does it still try with the remaining servers?
Does it simply change the list of candidates?
To provide more context, we have a working WebRTC application using the Google Stun Servers (stun.l.google.com:19302) however we are migrating on our own STUN servers. We have an API that returns the list of STUN servers to use however based on the behavior we might provide a different list.
Thanks for your help
But how does the RTCPeerConnection choose the server to use?
The RTCPeerConnection doesn't choose a server it choose a pair of ICE candidates. A ICE candidate is generated by contacting the servers.
Does it try the first one and if it fails try the second one until one works?
It contacts them all (this process is called gathering). Your WebRTC implementation may stop gathering when a connection is established.
Should all the servers be up and running or is the connection able to skip an unreachable server?
It is ok for a server to be down. Trickle ICE allows connectivity checks to proceed if all of them are not working.
If the first server is able to conclude the negociation, does it still try with the remaining servers?
Two WebRTC Agents don't communicate through a STUN server, this question has a little more nuance. In the connectivity chapter of WebRTC for the Curious check out how ICE goes through steps.
Does it simply change the list of candidates?
Yea! For each STUN server you may have another candidate. This depends on the behavior of your NAT. You could be behind a NAT configuration that only gives you one mapping. Unlikely but still possible!
Related
I've written a small WebRTC demo that streams a video file to the other peer and everything works fine (it's a real P2P connection without using the TURN server) except for this:
One client connects via a mobile network and one via wifi. When the mobile client creates the offer and kicks off the ICE candidate back-and-forth, they settle on srflx candidates and create a real P2P connection.
But when the wifi-client creates the offer, they fall back to the TURN server as a relay.
This happens in Firefox and Chromium on Ubuntu.
Does this behavior point to an obvious problem in my code?
If not, how can this be? Shouldn't the ICE protocol produce the same two candidates no matter which client is the controller?
NATs have two attributes influence if a connection will succeed between two WebRTC Agents. Those attributes are filtering and mapping.
When you send a packet to an address outside your NAT you create a mapping. A mapping is your IP:Port and people usually call it your Public IP. This is the Public IP that others can send into. A STUN server is just an echo server that responds with your mapping.
The first mapping type is an Address Independent NAT. This is the one you want. In this configuration you re-use a mapping everytime you contact an IP outside your NAT. You can give out your mapping to remote peers and they can send to you.
The second mapping type is Address Dependent. In this configuration you create a new mapping for each remote address. This means that the IP/Port you got back from the STUN server can NOT be used by other peers. In this case you may have to use a TURN server.
filtering controls who is allowed to send in. Some NATs allow anyone to send traffic in. Like mapping behavior this is called Address Independent. Other NATs only allow someone to send traffic in that you have attempted to contact, knows as a Address Dependent NAT.
Check out WebRTC for the Curious's Connecting Chapter I try to explain this in more depth. Pion also has a tool stun-nat-behavior that prints out the details of your NAT like so.
connecting to STUN server: stun.voip.blackberry.com:3478
=> NAT mapping behavior: endpoint independent
=> NAT filtering behavior: address and port dependent
WebRTC signalling is driving me crazy. My use-case is quite simple: a bidirectional audio intercom between a kiosk and to a control room webapp. Both computers are on the same network. Neither has internet access, all machines have known static IPs.
Everything I read wants me to use STUN/TURN/ICE servers. The acronyms for this is endless, contributing to my migraine but if this were a standard application, I'd just open a port, tell the other client about it (I can do this via the webapp if I need to) and have the other connect.
Can I do this with WebRTC? Without running a dozen signalling servers?
For the sake of examples, how would you connect a browser running on 192.168.0.101 to one running on 192.168.0.102?
STUN/TURN is different from signaling.
STUN/TURN in WebRTC are used to gather ICE candidates. Signaling is used to transmit between these two PCs the session description (offer and answer).
You can use free STUN server (like stun.l.google.com or stun.services.mozilla.org). There are also free TURN servers, but not too many (these are resource expensive). One is numb.vigenie.ca.
Now there's no signaling server, because these are custom and can be done in many ways. Here's an article that I wrote. I ended up using Stomp now on client side and Spring on server side.
I guess you can tamper with SDP and inject the ICE candidates statically, but you'll still need to exchange SDP (and that's dinamycally generated each session) between these two PCs somehow. Even though, taking into account that the configuration will not change, I guess you can exchange it once (through the means of copy-paste :) ), stored it somewhere and use it every time.
If your end-points have static IPs then you can ignore STUN, TURN and ICE, which are just power-tools to drill holes in firewalls. Most people aren't that lucky.
Due to how WebRTC is structured, end-points do need a way to exchange call setup information (SDP) like media ports and key information ahead of time. How you get that information from A to B and back to A, is entirely up to you ("signaling server" is just a fancy word for this), but most people use something like a web socket server, the tic-tac-toe of client-initiated communication.
I think the simplest way to make this work on a private network without an internet connection is to install a basic web socket server on one of the machines.
As an example I recommend the very simple https://github.com/emannion/webrtc-web-socket which worked on my private network without an internet connection.
Follow the instructions to install the web socket server on e.g. 192.168.1.101, then have both end-points connect to 192.168.0.101:1337 with Chrome or Firefox. Share camera on both ends in the basic demo web UI, and hit Connect and you should be good to go.
If you need to do this entirely without any server, then this answer to a related question at least highlights the information you'd need to send across (in a cut'n'paste demo).
I'm trying to make a video chat application based in http://www.html5rocks.com/en/tutorials/webrtc/basics/
It works well in the same network,
but when I try other networks have the following problem:
If i invite other user, only the other user can see the streaming
If he invites me, only he can see the streaming
I think the problem is in iceservers,
I'm using [{'url':'stun:stun.l.google.com:19302'}]
Any ideas on how can I solve this issue?
According to the same article that you mention:
If UDP fails, ICE tries TCP: first HTTP, then HTTPS. If direct connection fails—in particular, because of enterprise NAT traversal and firewalls—ICE uses an intermediary (relay) TURN server. In other words, ICE will first use STUN with UDP to directly connect peers and, if that fails, will fall back to a TURN relay server.
If I'm not mistaken, you use only STUN server. In this case if direct connection is not possible, and without TURN server, which acts as a relay, it's not possible to establish two-way connection.
Check out this article about how to set up your own TURN server, and about all this STUN and TURN stuff: http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/
I solve the problem creating my own server STUN/TURN, now is working two-way connection.
Alaershov thank you for your help.
I have followed the tutorials on http://www.html5rocks.com/en/tutorials/webrtc/basics as well as watch some of the videos but I am so confused. I was able to get 2 peerConnections working on a single page but I have no Idea how build on this to actually allow users on different machines/networks or what ever to actually connect.
From what I can see it involves using socket io and I have found plenty full frameworks and apps doing it but I am struggling to understand it.
Can any one point me to any tutorials that would help me to go from this rtcPeerConnection to communicating with other instances
Any help is greatly appreciated
To allow 2 users establish p2p connection, one of the peer should send "description" (ip address, port, etc) to second peer. Second peer sets it as remote description using setRemoteDescription method of RTCPeerConnection. Second peer invokes createAnswer and sends its localDescription to first peer.
When both peers know about each other, connection can be established. I think that tutorial mentioned by you in first link is comprehensive.
To allow 2 peers exchange "descriptions" you can use any hand-written signalling server. For example client can poll web-server using http.
Here's my current issue: I've been browsing multiple WebRTC resources, looking through Google experiments and likewise Mozilla ones too, but I have yet to find a simple explanation of how to do this. I'm also having trouble understanding the basic architecture of WebRTC.
What I would like to do is construct a peer-to-peer overlay, wherein each node is a browser. Each of these nodes would accept all incoming connections, and be able to connect to others using their IP address. They would communicate only over a DataChannel. Unlike many of the examples I have been reading, I would not like to rely on any server for signalling, only those necessary for subverting NAT (like STUN servers).
Could anyone explain how this might be achieved? I've been reading the resources on the WebRTC Experiments site and I need to do something with offers or something, but I'm not quite understanding.
How you address nodes in WebRTC is totally up to you, the implementor, because signalling is - deliberately - left out of the specification. So if you'd like to address the nodes in your overlay by their IP addresses, go ahead. But I think you slightly misunderstood how connection establishment in WebRTC works, so let me dive a bit deeper:
WebRTC connection establishment is accomplished by exchanging SDP messages (http://en.wikipedia.org/wiki/Session_Description_Protocol). If you want one browser to establish a PeerConnection to another browser, you'll have to find a way to send the SDP message (generated via RTCPeerConnection#createOffer) to the other browser. There's no way to just open a UDP connection to that browser (or ICE wouldn't work).
So for a node to join the overlay network you'll have to have a central point (let's call it server) or another channel (have a look at https://github.com/cjb/serverless-webrtc/ for "server-less" WebRTC) for connection establishment. As soon as all your nodes are connected to each other via RTCPeerConnections (e.g. as a chain) you can use those connections for further connection establishment (i.e. transfer SDP offers/answers through these connections).
Back to addressing nodes via IP address: This is not a good idea because sometimes you don't even know the address (e.g. when STUN and esp. TURN come into play).
Edit to answer question in comment:
Instead of the IP address you could use sth. like a UUID (http://en.wikipedia.org/wiki/UUID). Also, you could as well use sth. like the user's e-mail address if all your users are authenticated in some way. But keep in mind that the matter of authenticating peers is still not fully specified by IETF/W3C and implementations don't exist, yet.