Candidate attribute in a SDP provides connection address of the candidate. Which looks like this:
a=candidate:4022866446 1 udp 2113937151 192.168.0.197 36768 typ host
I want to know how does sdp collects information about my local ip.
It'd be great help if there's any specific webrtc code to look at. And, if it is possible to look at local IP, can sdp know my default gateway ?
WebRTC provides you some APIs. You can not see whats going on underneath. You call specific APIs and internally the SDK does its job which in this case gathering your ip information.
There are 3 types of candidates Host, Server Reflexive(public address) and relay address.
Host candidate is your interface address. The interface addresses are gathered through some system API calls and also a socket is created and bound for each interface to get the port.
As WebRTC internally uses ICE, STUN and TURN protocol, the server reflexive and relay candidate gathering has specific rule to follow.
To gather Server Reflexive candidate(NAT's public IP:Port) internally a STUN message is sent to STUN server and the response message contains mapped/XOR mapped address. This how your server reflexive address is gathered.
To gather Relay candidate a TURN allocate request is sent to TURN server and the response message contains relay address. TURN message response contains the server reflexive address also. So if you have TURN server then you don't need STUN server.
Edit:
I dont think there are WebRTC APIs that can help you with this.
You dont need WebRTC for finding out your default gateway. You can programmatically find that out by yourself. There are some system calls which will give your devices routing table entries. Or in some platform you need to read a specific configuration file to get those entries. You can parse these entries to find out the default gateway. See the following questions fie some examples.
How to get the WIFI gateway address on the iPhone?
Default Gateway in C on Linux
Whenever you create a PeerConnection object, it collects all the possible ice candidates( addresses through which the remote peer could reach you), you have to gather them using PeerConnection.onicecandiate event handler and pass them on the remote peer through signalling server.
Some of these candidates would reflect on the locally generated sdp, they are not mandatory part of the sdp, the main purpose of the sdp is to describe the mediasteam you are sharing.
It s called "ice gathering" and it s done internally in the browsers.
The browser does NOT know about your gateway, but if you use a STUN server, it will know your public IP.
Related
I'm a little confused. On this MDN page it says the following (emphasis mine) https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/icecandidate_event
An icecandidate event is sent to an RTCPeerConnection when an RTCIceCandidate has been added to the target as a result of calling RTCPeerConnection.setLocalDescription(). This event handler should transmit the candidate to the remote peer so that the remote peer can add it its set of remote candidates.
The only example I could find that uses a STUN server is webrtc/samples trickle-ice https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/. My STUN server appears to work.
It will list my tcp and udp ports. However when I have IceTransports value set to relay I always get an empty list
If I want three users to visit my page and talk to eachother using RTCDataChannel how do they detect and connect to eachother?
You need a signaling server to exchange the offer, answer and candidates. A STUN servers is not a signaling server, its only purpose is to find out your own public IP address.
I have a WebRTC MCU (kurento) running on a public IP address
serving some clients that only send or only receive audio
So every clients is directly connected with MCU (not with each other ) that has a public IP address .
Q1: Is there still a necessity to use STUN and TURN for NAT traversal ?? if so Why ??
Q2: Is there any hack in WebRTC in browser that would remove the need for STUN and TURN ?
In my opinion : most of client-server architectures do not have any difficulty with clients behind NAT .What's the difference here with webrtc?
Yes ICE is absolutely must for WebRTC.
Q1: Is there still a necessity to use STUN and TURN for NAT traversal
?? if so Why ??
For your scenario you don't need to use STUN or TURN. Let me explain why.
Every client that are in private network is under some kind of NAT which has a public IP address. Outside world doesn't know this client's private IP address and even if they knew they can't connect with the client without knowing that public IP address. STUN server is used to gather this public IP address.
So if your server wants to initiates the connection then it needs the client to send its NAT's public IP. Client will use STUN server to know its public IP and send it to the server. But if client initiates the connection then there is no need to know the NAT's public IP. Client can send packets to the public server to initiate the connection. Server can know the cilents public IP from the clients packet and then they can connect. So no need for STUN.
Your server is doing TURN's role in this scenario. So you don't need TURN server.
Q2: Is there any hack in WebRTC in browser that would remove the need for STUN and TURN ?
There is no hack. Depending on scenarios TURN/STUN is used. For your scenario you don't need. If you wanted to make client-client connection then you would have needed STUN server.
ICE is mandatory
but using any stun and turn server is not.
since you are connecting to a server on a public port, you NEVER need to use a TURN server, but depending the kind of NAT/Firewall your clients are behind, you might need a STUN server
you do not need to modify the browsers at all. The application decides wether to use a stun server or not. if you pass an empty "iceservers" parameter to your peerconnection object at creation, the ICE UA in your browser will only generate host (local) candidates.
My understanding about STUN server for webrtc is that when the clients are behind the NAT (in most cases, if not all), the STUN server will help the webrtc clients to identify their addresses and ports. And I also read some article saying that a signaling server is needed for webrtc clients. The signaling server could be a web server, socket.io, or even emailing a url. My first question would be: is the STUN server the signaling server?
Actually now I built a very simple socket.io based service which broadcasts client's session descriptions to all other clients. So I believe the socket.io based server should have enough knowledge about the clients' addresses and ports information. If this is the case, why do we bother to have another STUN server?
The STUN server is NOT the signalling server.
The purpose of the signalling server is to pass information between the peers at the start up of the session(how can they send an offer without knowing who to send to?). This information includes the SDPs that are created on the offers and the answers and also any Ice Candidates that are created by either party.
The reason to have a STUN server is so that the two peers can send the media to each other. The media streams will not hit your signalling server but instead will go straight to the other party(the definition of a peer-to-peer connection), the exception to this would be the case when a TURN server is used.
Media cannot magically go through a NAT or a firewall because the two parties do not have direct access to each other(like they would if they were on the same LAN).
In short STUN server is needed the large majority of the time when the two parties are not on the same network(to get valid connection candidates for peer-to-peer media streaming) and a signalling server is ALWAYS needed(whether they are on different networks or not) so that the negotiation and connection build up can take place. Good explanation of the connection and streaming process
STUN is used to implement the ICE protocol, which tries to find a working network path between the two clients. ICE will also use TURN relay servers (if configured in the RTCPeerConnection) for cases where the two clients (due to NAT/Firewall restrictions) can't make a direct peer-to-peer connection.
STUN servers are used to identify the external address used by the computer on the internet (the outside-the-NAT address) and to attempt to set up a port mapping usable by the peer (if the NAT isn't "symmetric") -- contacting the STUN server will tell you the external IP and port to try to use in ICE. These are the ICE candidates included in the SDP or in the trickle-ICE messages.
For almost-guaranteed connectivity, a server should have TURN servers (preferably supporting UDP and TCP TURN, though UDP is far preferred). Note that unlike STUN, TURN can use appreciable bandwidth, and so can cost money to host. Luckily, most connections succeed without needing to use a TURN server (i.e. they run peer-to-peer)
NAT(Network Address Transformation) is used to translate "Private IP', which is valid only in LAN into "Public IP" which is valid in WAN.
The problem is that "Public IP" is only visible from outside, so we need STUN or TURN server to send back "Public IP" to you.
This process enables a WebRTC peer to get a publicly accessible address for itself, and then pass that on to another peer via a signaling mechanism
A STUN server is used to get an external network address.
TURN servers are used to relay traffic if direct (peer to peer) connection fails.
for more you can also refer from below link: https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#what-is-signaling
In your case, you need STUN. Most clients will be behind NAT, so you need STUN to get the clients public IP. But if both your clients were not behind NAT, then you wouldn't need STUN. More generally, no, a STUN server is not strictly required. I know this because I successfully connected 2 WebRTC peers without a stun server. I used the example code from aiortc, a python WebRTC/ ORTC library where both clients were running locally on my laptop. The signalling channel used my manual copy-pasting. I literally copied the SD (session description) from the one peer to the other. Then, copied the SD from the 2nd peer to the 1st peer once again.
From the ICE RFC (RFC8445), which WebRTC uses
An ICE agent SHOULD gather server-reflexive and relayed candidates.
However, use of STUN and TURN servers may be unnecessary in certain
networks and use of TURN servers may be expensive, so some
deployments may elect not to use them.
It's not clear that STUN is a requirement for ICE, but the above says it may be unnecessary.
However, signalling has nothing to do with it. This question actually stems from not understanding what STUN does, and how STUN interplays with signalling. I would argue the other 3 answers here do not actually answer these 2 concerns.
Pre-requisite: Understand the basic concepts of NAT. STUN is a tool to go around NAT, so you have to understand it.
Signalling: Briefly, in WebRTC you need to implement your own signalling strategy. You can manually type the local session description created by one peer in the other peer, use WebSockets, socket.io, or any other methods (I saw a joke that smoke signals can be used, but how are you going to pass the following session description (aka. SDP message) through a smoke signal...). Again, I copy pasted something very similar to below:
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
When both peers are not behind NAT, you don't need a STUN server, as the IP addresses located in the session description (the c= field above, known as connection data) generated by each peer would be enough for each peer to send datagrams or packets to each other. In the example above, they've provided the domain name instead of IP address, host.anywhere.com, but this can be resolved to an A record. (Study DNS for more information).
Why don't you need a STUN server in this case? From RFC8445:
There are different types of candidates; some are derived from physical or logical network interfaces, and others are discoverable via STUN and TURN.
If you're not using NAT, the client already knows the IP address which peers can directly address, so the additional ICE candidates that STUN would generate would not be helpful (it would just give you the same IP address you already know about).
But when a client is behind a NAT, the IP they think they won't help a peer contact them. Its like telling you my ip address is 192.168.1.235, it really is, but its my private IP. The NAT might be on the router, and your client may have no way of asking for the public IP. So STUN is a tool for dealing with this. Specifically,
It provides a means for an endpoint to determine the IP address and port allocated by a NAT that corresponds to its private IP address and port.
STUN basically lets the client find out what the IP address. If you were hosting a Call of Duty server from your laptop, and port forwarded a port to your machine in the router settings, you still had to look up your public IP address from a website like https://whatismyipaddress.com/. STUN lets a client do this for itself, without you accessing a browser.
Finally, how does STUN interplay with signalling?
The ICE candidates are generated locally and with the help of STUN (to get client public IP addresses when they're behind NAT) and even TURN. Session descriptions are sent to the peer using the signalling channel. If you don't use STUN, you might find that the ICE candidates generated that is tried by ICE all fail, and a connection (other than the signalling channel) does not successfully get created.
What I want is, basically, to create a connection between two different computers on same local network. But i want to do this by computers' local IP's. (like 192.168.2.23 etc)
This must be a totally local connection. no TURN or STUN Servers. I am not sure if this is possible. Because there are not much documentation/example/information about WebRTC.
So, how can I create a connection from my computer to another one just passing its local IP as parameter?
Update: To be more clear; imagine there is an html page contains some code that activates my camera and audio services. and another -almost same- page is open in other computer. Waiting a connection request... And there is a textbox in my page to type an IP belongs to other computer on my local network. type 192.168.2.xx and bingo! i have connection between me and other computer.
I want this process as IP based, because there may be more than 2 devices on the network. And all of them are possible devices to create connection. So i need to reach them by their IP's.
Any example code or explanation would be great! even if it tells that this is not possible.
Thanks
Peer discovery is a vital part in any WebRTC application. It's an expensive term for saying: "Hi, I'm computer 4 and I want to talk to you!".
See it as calling a friend over the phone. You need to dial his number first.
This part is not defined in the WebRTC standards. You need to implement this logic in your application. Once you know who you want to call, you need a way of exchanging vital information. This is called signaling, like flo850 put in his answer.
Signaling is needed before any peer-to-peer connection can be set up.
To come up with an idea for your use case of 7 devices in a LAN.
If you have these devices connected to for example a WebSockets server and are in the same channel.
The WebSockets server can be written to route messages to specific receivers.
Devices connected to the channel often are identified with some kind of ID, imagine you use the device's IP.
When you want to talk to computer 4 with IP 192.168.0.4 you send the exchange messages (signaling) on the channel to the receiver with ID, the IP of the device you want to connect with.
How to send the signaling (offer, answer) is described here with example code.
Hope this helps
Users usually sit behind NATs; that's why ICE concept implemented in WebRTC.
If both users are sitting behind same NAT; you can skip ICE servers by passing "NULL" parameter value over "RTCPeerConnection" constructor:
var peer = new [webkit|moz]RTCPeerConnection ( null );
Now, browser will use "host" candidates, also known as "local" candidates.
you still need a signaling server. During the ICE candidate search, your clients will exchange their local ip through this signaling server
I'm interested in Peer-to-Peer connections in the browser. Since this seems to be possible with WebRTC, I'm wondering how it works exaclty.
I've read some explanations and saw diagrams about it and now it's clear to me, that the connection establishmet works over the server. The server seems to exchange some data between the client that are willing to connect to each other, so that they can start a direct connection, that is independent of the server.
But that's exaclty what I don't understand. Until now, I thought the only way to create connections is to listen on a port on computer A and connect to that port from computer B. But this does not seem to be the case in WebRTC. I think none of the clients starts to listen on a port. Somehow, they can create a connection without listening on ports and accepting connections. Neither client A, nor client B starts acting as a server.
But how? What data is exchanged over the WebRTC server, that the clients can use to connect to each other?
Thanks for your explanations for this :)
Edit
I found this article. It's not related to WebRTC, but I think it answers a part of my question. I'm not sure, tough. It still would be cool, if someone could explain it to me and give me some additional links.
WebRTC gives SDP Offer to the client JS app to send (however the JS app wants) to the other device, which uses that to generate an SDP Answer.
The trick is that the SDP includes ICE candidates (effectively "try to talk to me at this IP address and this port"). ICE works to punch open ports in the firewalls; though if both sides are symmetric NATs it won't be possible generally, and an alternative candidate (on a TURN server) can be used.
Once they're talking directly (or via TURN, which is effectively a packet-mirror), they can open a DTLS connection and use it to key the SRTP-DTLS media streams, and to send DataChannels over DTLS.
Edit:
Acronyms here: http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ for the rest, there is Google. Most of these are defined by the IETF (http://ietf.org/)
Edit 2:
Firefox and Chrome (and the spec) have moved to using "trickle" for ICE candidates, so the ICE candidates are generally added after-the-face to the PeerConnection and exchanged independently of the initial SDP (though you can wait until the initial candidates are ready before sending an offer, and bundle them together).
See https://webrtcglossary.com/trickle-ice/ and https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/
How WebRTC Works
This document provides a quick and abstract introduction to WebRTC. In order to get more information about WebRTC please look at the Further Reading section at the end of this document.
WebRTC
WebRTC(Web Real-Time Communication) is a set of technologies that is developed for peer to peer duplex real-time communication between browsers. As its name mentions it is compatible with Web and it is a standard in W3C One of the important feature of WebRTC is that it works even behind NAT addresses.
WebRTC uses several technologies to provide real-time peer to peer communication between browsers. These technologies are
SDP (Session Description Protocol)
ICE (Interactivity Connection Establishment)
RTP (Real Time Protocol)
There is one more thing which is Signalling Server is needed for running WebRTC. However, there is no defined standart in implementing signalling server. Each implementation creates its own style. There will give some more information about Signalling Server later in this section.
Let's give some quick info about technologies above.
SDP (Session Description Protocol)
SDP is a simple protocol and it is used for which codecs are supported in browsers. For instance, assume that there are two peers(Client A and Client B) which will be connected through WebRTC. Client A and Client B create SDP strings that defines which codecs they support. For example, Client A may support H264, VP8 and VP9 codecs for video, Opus and PCM codecs for audio. Client B may support only H264 for video and only Opus codec for audio. For this case, the codecs that will be used between Client A and Client B are H264 and Opus. If there are no common codecs between peers, peer to peer communication cannot be established.
You may have a question about how these SDP strings are sent between each others. This is where Signalling Server takes place.
ICE (Interactivity Connection Establishment)
ICE is the magic that establishes connection between peers even if they are behind NAT. Let's assume again Client A and Client B will get connected and take a look at how ICE is used for that.
Client A finds out their local address and public Internet address by using STUN server and sends these address to Client B through Signalling Server. Each addresses received from STUN server is called ICE candidate
In the image above, there are two servers. One of them is STUN and other of them is TURN server.
STUN server is used to let Client A learn its all addresses. Let me give an example for this, our computers generally has one local address in the 192.168.0.0 network and there is a second address we see when we connect to www.whatismyip.com, this IP address is actually the Public IP address of our Internet Gateway(modem, router, etc.) so let's define STUN server; STUN servers lets peers know theirs Public and Local IP addresses. Btw, Google provides free STUN server(stun.l.google.com:19302).
There is a one more server, TURN Server, in the image. TURN Server is used when peer to peer connection cannot be established between peers. TURN server just relays the data between peers.
Client B does the same, gets local and public IP addresses from STUN server and sends these addresses to Client A through Signalling Server.
Client A receives Client B's addresses and tries each IP addresses by sending special pings in order to create connection with Client B. If Client A receives response from any IP addresses, it puts that address in a list with its response time and other performance credentials. At last Client A choose the best addresses according to its performance.
Client B does the same in order to connect to Client A
RTP (Real Time Protocol)
RTP is a mature protocol for transmitting real-time data. It is based on UDP. Audio and Video are transmitted with RTP in WebRTC. There is a sister protocol of RTP which name is RTCP(Real-time Control Protocol) which provides QoS in RTP communication. RTP is also used in RTSP(Real-time Streaming Protocol)
Signalling Server
The last part is the Signalling Server which is not defined in WebRTC. As mentioned above, Signalling Server is used to send SDP strings and ICE Candidates between Client A and Client B. Signalling Server also decides which peers get connected to each other. WebSocket technology is generally used in Signalling Servers for communication.
Compatibility
In the last one year, all browsers including Safari, Edge have released new versions supporting WebRTC. Chrome, Firefox and Opera have already supported WebRTC for a while. The video codec that is common to browsers are H264. For the audio, Opus is common in browsers. PCM can also be used for audio codec but AAC is not used even if AAC is supported in all browsers because of licensing issues. IP Cameras generally support H264 for video codec and PCM or AAC for audio codec.
Further Reading and References
WebRTC Samples
ICE Wikipedia
SDP
RTP RFC
Getting Started with WebRTC
WebRTC.org
STUN Server
RTSP Wikipedia
Btw, I am developer at Ant Media Server which supports scalable one-to-many WebRTC and peer to peer WebRTC connection
Establishing a p2p WebRTC connection has 3 steps (10.000 feet overview) :
Step 1: Signaling: both peers connect to a signaling server (using websockets over 80/443, comet, SIP,etc..) and exchange information (about their media capabilities, public IP:port pairs when they become available, etc.)
Step 2: Discovery: Devices connected to LAN or mobile networks are not aware of their public IP (and port) where they can be reached at so they use STUN/TURN servers located on the public Internet to discover their ip:port pair (ICE candidates). In the process they punch a hole through the NAT/router which is used in step3:
Step 3: P2P connection: once the ICE candidates are exchanged through the initial signaling channel each peer is aware of each other's ip:port (and holes have been punched in NATs/routers) so a peer to peer UDP connection can be established.
The scheme above explains the process with 2 devices connected to local networks. It's part of an article I wrote that deals with troubleshooting connection issues but it does a good job of explaining how WebRTC works.
A very good explanation can be found in this book "High Performance Browser Networking (O'Reilly)" http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE
which provides the fundamentals on how WebRTC uses ICE technology.
In particular assuming the IP address of the STUN server is known, the WebRTC application first sends a binding request to the STUN server. The STUN server replies with a response that contains the public IP address and port of the client as seen from the public network.
Now the application discovers its public IP and port tuple which can send to the other peer through SDP. (note that SDP are sent over an external signalling channel, f.i. websocket established through a web service)
With this mechanism in place, whenever two peers want to talk to each other over UDP, they can then use the established public IP and port tuples to exchange data.
Unfortunately, in some cases UDP may be blocked by a firewall. To address this issue, whenever STUN fails, we can use the Traversal Using Relays around NAT (TURN) protocol as a fallback, which can run over UDP and switch to TCP if all else fails.
WebRTC connection starts with WebRTC offer.
Caller creates the WebRTC offer and posts it to the Signaling server which will pass the offer to the callee. Users actually passing their SDP (Session Description Protocol) information each other.
Then we need to exchange the internet connection details. it allows clients to discover their public IP address and the type of NAT they are behind. this information is used to establish the media connection. This is handled by STUN server. this process is also known as getting the ICE Candidates. This data is also exchanged via the Signalling Server.
Final step is to exchange audio and video streams true TURN (Traversal Using Relay NAT) server. This ensures the connection even thought users are behind the firewall. this server process a lot of heavy calculations so its cost is high. when you test your app in dev with different browsers, you are directly connecting each other, you are not using TURN server