I read about this online and I come to know that signaling is used for initiation of the communication, But I am very confused about how would I get the ip:port combination for the other peer.
I thought of three scenarios.
On the same network (LAN)
On the internet(but not behind a
proxy/NAT)
On the internet but behind a proxy/NAT
For 1. I get that we can get the ip:port from the signaling process it self(if I am not wrong)
For 2. and 3. How would we get the IP:PORT, how would STUN/TURN servers and ICE will play their role in all these cases? I know for what reason they are used for but can't figure out how each of them will fit in these scenarios.
Update: The question that is posted in comments is the one which compliments what I assumed that it should work in this way, what I don't know is how TURN would do the update, would it be establishing the communication using SDP? like it did for STUN? Is it absolutely necessary for TURN to work we should deploy it on cloud?
Related
Not sure the title makes a lot of sense. To add some context, we are building a WebRTC infrastructure and to so do we have a few STUN servers up and and running.
We sometimes have users complaining of call taking too long to connect therefore we would like to get some analytics on the calls. Because we provide a list of STUN IPs (including some public STUN as backup), we would like to detect the STUN server that successfully initiated the call.
We have collected a bunch of information thanks to RTCPeerConnection.getStats but there is nothing related to the STUN itself. So for my questions:
is there any JS API that allow us to retrieve the STUN used?
is there any tool that I am not aware of that could do the job?
do the SDP contains any information related to STUN?
Hope all of this is clear, thanks for your kind replies
The statistics do contain a server url:
https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatestats-url
However, that is not implemented and since STUN servers are not involved in the actual call that information is unlikely to be useful.
For TURN servers you can get the active candidate pair and the IP of any relay involved from getStats. See https://webrtc.github.io/samples/src/content/peerconnection/constraints/ for a sample that shows how to determine the active candidate pair.
I'm working on a WebRTC solution for audio/picture comunication and I'm a bit concerned about the lack of bandwidth control when two Peers in LAN are communicating.
Basically I want to be able to prioritize and pre-allocate bandwidth on my switch for WebRTC calls. But I couldn't see a proper way of filtering the packets when they are in a P2P call.
Also, I don't want to decode the packet to do that, because of the possible delay caused by this operation.
I hope you guys can show me a proper way or just tell me if my teorical solution could work.
I'm not 100% sure about the idea I'm planning to test, because I don't know how TURN server works internally.
But here is the idea:
And what I dont know is: Is it possible to make 2 turn servers know each other? Would they work like a 2 layer proxy between callers? If yes, could you please show me what I have to do to make it work?
Just install a internal proxy server to the external turn server and prioritize the proxy on your lan.
(answering my own question after realizing the solution was easier than I thought)
Signaling is not addressed by WebRTC (even if we do have JSEP as a starting point), but from what I understand, it works that way :
client tells the server it's available at X
server holds that information and maps it to an identifier
other client comes and sends an identifier to get connection information from the first client
other client uses it to create it's one connection information and sends it to the server
server sends this to first client
both client can now talk
This is all nice and well, but what happends if a 3rd client arrives ?
You have to redo the whole things. Which suppose the first two clients are STILL connected to the server, waiting for a 3rd client to signal itself, and start the exchanging process again so they can get the 3rd client connection information.
So does it mean you are required to have to sort of permanent link to the server for each client (long polling, websocket, etc) ? If yes, is there a way to do that efficiently ?
Cause I don't see the point of having webRTC if I have to setup nodejs or tornado and make it scales to the number of my users. It doesn't sound very p2pish to me.
Please tell me I missed something.
What about a chat system? Do you really need to keep a permanent link to the server for each client? Of course, because otherwise you have no way of keeping track of a user's status. This "permanent" link can be done different ways: you mentioned WebSocket and long polling, but simple periodic XHR polling works too (although this will affect the UX, depending on the interval).
So view it like a chat system, except that the media stream is P2P for reduced latency. Once a P2P WebRTC connection is established, the server may die and, of course, the P2P connection will be kept between the two clients. What I mean is: both users may always block your server once the P2P connection is established and still be connected together in the wild Internets.
Understand me well: once the P2P connection is established, your server will not be doing any more WebRTC signalling. The connection is only needed to keep track of the statuses.
So it depends on your application. If you want to keep the statuses of users and make them visible to others, then you're in the same situation as a chat system: you need to keep a certain link, somehow, to make sure their statuses are synced. Otherwise, your server exists to connect them together and is not needed afterwards. An example of the latter situation is: a user goes to a webpage, the webpage provides him with a new room URL, the user shares this URL to another peer by another mean, the other peer joins the room, server connects them together (manages WebRTC signalling) and then forgets them. They are now connected until one of them breaks the link. Just like this reference app.
Instead of a central server keeping one connection per client, a mesh network could also be considered, albeit difficult to implement.
I've read a lot about WebRTC, but there's one question that still remains. I hope you can help me with that:
Does WebRTC allow me to create a one-to-many connection? I don't mean "being able to have multiple connections to different computers", I really talk about having one connection that multicasts its data to multiple endpoints without the need to "upload" the data once for each endpoint. Will it be possible to send one single package to the web, that, when it reaches the web, magically splits itself into multiple packages with different targets?
I hope you get what I'm looking for :)
Until now, I've only seen one-to-one connections, or solutions that have one connection to a central server that does the multicast for them (which usually results in twice the ping).
But to me, one-to-one connections don't seem to be really useful (due to low upload-bandwith of clients), and solutions with a central server are also possible without WebRTC (using WebSockets), so the only real use case for WebRTC would be one-to-many connections.
So.. is this something that will be possible in the future? Or is it already possible today?
Three things:
IP multicast in the Internet is not possible at the moment (multicast addresses are not routed by ISPs)
WebRTC fits many use cases beyond one-to-many communication, just have a look at this document: https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-use-cases-and-requirements-06
WebRTC connections between browsers are always encrypted (using SRTP for A/V data and DTLS for generic data) and the encryption parameters (session keys etc.) are negotiated for every connection separately. How would you do that in a multicast environment (think of it as a distribution tree)?
So no, WebRTC cannot be used with IP multicast.
I would answer "It doesn't for now", because as a programmer, I can tell you, that there are number of ways browser devs to make it work if we (users) insist on it's importance. But how ? Since there's encryption, they could allow sharing of the session's encryption keys to the group of 'registered' (multicast) users. But how ? Well, Web was created for sharing. The most obvious way is through web server mediation and JS WebRTC API function (to load the user keys). Since multicast is most often used for efficient video distribution, you have a RTP/SRTP video server. The web server can coexist at the same machine. If they decide to extend it to web browsers - then just the "server" role can be done by the Web browser who created the multicast stream (the sender). The clients need to know who is it.
Again: In December 2013, this is still not possible. And multicasts are allowed on the Internet only in:
some experimental WAN nets
some internet+video ISP nets
LANs (when enabled at switch level, cheap switches transmit it to all ports). But you can be an ISP, researcher or LAN user, so it's necessary.
I have a question about the skype protocol.
Supposedly, according to wiki, the supernodes in Skype are used in UDP hole punching. The supernodes are nodes without firewalls/NATs.
My question is, how is this reliable? Isn't the vast majority of internet users behind NAT?
And, if I was to create a P2P application using this technique, what happens if there are no peers without firewalls? I don't understand how you can launch an application that relies on that there will be some peers eventually without NAT
Thanks
I can't comment on Skype specifically, but I have some experience with this (http://wiki.squeak.org/squeak/5629). We called our supernodes "big friendly giants" or BFGs :).
The idea behind supernodes is that while you hope that they pop up in the network, giving new users more options for NAT hole punching, you provide, as p2p network operator, a minimal set yourselves (could be just one or two machines, they are just needed for initial hole punching, real traffic will get re-routed directly anyway). As far as I'm aware, Skype does that as well - they run a minimum set of supernodes themselves.
When Skype had issues earlier this year, a lot of people tried to reconnect and thus the supernodes got overloaded, resulting in a domino effect. Skype added supernodes, but the amount of people trying to reconnect at that time was so massive that it took quite a while before the network rebuilt itself. It's quite funny - we had that with the above project as well - that a P2P network can be extremely resilient until it gets pushed over some edge and the whole thing crumbles.
[disclaimer: I work for eBay, former owner of Skype, but this is all my personal opinion and based on public information]
Read the papers on libjingle with discussion about services like STUN. When both parties are behind NAT an external service is often required to relay through or assist in punching a hole open on one or other side.
http://code.google.com/apis/talk/libjingle/important_concepts.html