As per my understanding from my previous question : Kurento: STUN/TURN
The TURN server configured from webrtcendpoint.conf.ini is used only for exchanging ice candidates. Also we can specify only one TURN server in webrtcendpoint.conf.ini because What I have observed is that if i provide 2 or more TRUN server in webrtcendpoint.conf.ini Kurento media server service fails to start, is this correct ?
Also is there any way to verify which STUN/TURN server is being used at Kurento media server and between two peers?
The STUN/TURN which we provide in conferenceroom.js will be used for the actual media flow/mediapipeline between peers. Is this correct ?
If we provide multiple TURN servers in conferenceroom.js then the TURN server neatest/fastest response time will be selected for media flow between the two peers? Same as we get response time form this Link.
Also what I have observed is that if the TURN server provided in webrtcendpoint.conf.ini and conferenceroom.js are different then we are not able to see remote participants video but if both the TURN server are the same then I am able to see remote participants video. Is this correct ?
Edit 1:
In groupcall sample example we have onExistingParticipants() and onNewParticipants() where we can define iceServers in receiveVideo() and onExistingParticipants() so what will happen if we specify TURN server t1 in kurentoUtils.WebRtcPeer.WebRtcPeerSendOnly() and TURN server t2 in kurentoUtils.WebRtcPeer.WebRtcPeerRecvOnly() then will these two TURN server communicate between each other as relay chain ?
The TURN server configured from webrtcendpoint.conf.ini is used only
for exchanging ice candidates. Also we can specify only one TURN
server in webrtcendpoint.conf.ini because What I have observed is that
if i provide 2 or more TRUN server in webrtcendpoint.conf.ini Kurento
media server service fails to start, is this correct ?
It is used for gathering candidates, and if needed as video relay. You KMS won't probably need this, as the location where it's deployed is managed by you. If you can do with STUN only which is the desired way, then the relay server won't be used.
Only one server can be configured,
Also is there any way to verify which STUN/TURN server is being used
at Kurento media server and between two peers?
Yes, the WebRtcEndpoint has methods for this
getStunServerPort()
getStunServerAddress()
getTurnUrl()
The STUN/TURN which we provide in conferenceroom.js will be used for
the actual media flow/mediapipeline between peers. Is this correct ?
It will be used to gather candidates in your client. Also, if your client is behind a NAT that needs to use a relay server, it will use the one configured in conferenceroom.js. Keep in mind that the media path might not be symmetric: while media going from client->kms might be not using a relay server, media going from KMS-> client might due to the network conditions at your client's location.
If we provide multiple TURN servers in conferenceroom.js then the TURN
server neatest/fastest response time will be selected for media flow
between the two peers? Same as we get response time form this Link.
Yes, candidates are probed and the best one is chosen.
Also what I have observed is that if the TURN server provided in
webrtcendpoint.conf.ini and conferenceroom.js are different then we
are not able to see remote participants video but if both the TURN
server are the same then I am able to see remote participants video.
Is this correct ?
This shouldn't be the case, unless one TURN is working and the other not.
EDIT
TURN servers will not exchange media between them. They will be used, if needed, to act as a relay with the other peer. The process is
Each peer gathers candidates: host, srflx (STUN) and relay (TURN). Nothe that if the TURN server is different, the relay candidates will also be different.
Candidates get sent to the other peer.
Each candidate is probed individually, and the best one is chosen.
Since all media is going through KMS, it will be the KMS the one sending media to the relay server. Keep in mind that KMS is always in between peers. It would be
kms->t2->client
client->t1->kms
Even if the connection was browser to browser, the TURN servers would not communicate directly, as they would act as relay for the media sent from one peer to the other. Here it would be
client1->t2->client2
client2->t1->client1
Related
We use a provider of global TURN servers (Xirsys). When establishing a connection between peers, each peer first identifies the closest TURN server to their location, then fetches credentials for that server. The peers then exchange ICE candidates, including their respective TURN server URLs.
If those peers are in different regions, they will propose different TURN servers. According to the accepted answer to this question: TURN-Server for RTCConfiguration the respective TURN servers will connect to each other to relay streams from Peer1 <> TURN1 <> TURN2 <> Peer2. However, I have been unable to get this to work. Forcing TURN in the clients (i.e. no direct p2p connections), and attempting to establish a peerConnection using a TURN server in e.g. the United States to one in Brazil, negotiation always fails.
Is this because the servers require credentials that are not passed in the ICE candidates? Or perhaps it's a Xirsys-specific problem? Or should it actually work fine and we're doing something else wrong?
No it's not going to be because of the credentials. They are used between the client and its TURN server. The connection between the TURN server and remote end point doesn't use any authentication.
In fact each TURN server should be blissfully unaware that the remote party is even another TURN server. As far as they are concerned they forward packets to the remote end point just the same no matter whether it's a browser, another TURN server or some other application.
So, while working through two TURN servers is possible, it's definitely not easy. The reason is that the first TURN server will generate an allocation with a given port. The second TURN server will need to send data to this port. However, how does the first TURN server know where to send that data? The second TURN server will not yet have an allocation!
Typically, WebRTC applications use a singular TURN server. If you want to use two, it means having control of the allocation generation and massaging of the SDP.
I am building this video teaching site and did some research and got a good understanding but except for this thing. So when a user want's to connect to another user, P2P, I need signaling server to get their public IP to get them connected. Now STUN is doing that job and TURN will relay the media if the peers cannot connect. Now if I write signaling server with WebSocket to communicate the SDP messages and have ICE working, do I need coTURN installed? What will be the job of the job of them particularly?
Where exactly I am confused is the work of my simply written WebSocket Signaling server (from what I saw in different tutorials) and the work of the coTURN server I'll install. And how to connect them with the media server I'll install.
A second question, is there a way to use P2P when there is only two/three participants and get the media servers involved is there is more than that so that I don't use up the participant's bandwidth too much?
The signaling server is required to exchange messages between peers (SDP packets) until they have established a P2P connection.
A STUN server is there to help a peer discover information about its public IP and to open up firewall ports. The main problem this is solving is that a lot of devices are behind NAT routers within small private networks; NAT basically allows outgoing requests and their response, but blocks any other "unsolicited" incoming requests. You therefore have a Catch-22 scenario when both peers are behind a NAT router and could make an outgoing request, but have nowhere to send it to since the opposite peer doesn't expose anything to make a request to. STUN servers act as a temporary middleman to make requests to, which opens a port on the NAT device to allow the response to come back, which means there's now a known open port the other peer can use. It's a form of hole-punching.
A TURN server is a relay in a publicly accessible location, in case a P2P connection is impossible. There are still cases where hole-punching is unsuccessful, e.g. due to more restrictive firewalls. In those cases the two peers simply cannot talk 1-on-1 directly, and all their traffic is relayed through a TURN server. That's a 3rd party server that both peers can connect to unrestrictedly and that simply forwards data from one peer to the other. One popular implementation of a TURN server is coturn.
Yes, basically all those functions could be fulfilled by a single server, but they’re deliberately separated. The WebRTC specification has absolutely nothing to say about signaling servers, since the signaling mechanism is very unique to each application and could take many different forms. TURN is very bandwidth intensive and must usually be delegated to a larger server farm if you’re hoping to scale at all, so is impractical to mix in with any of the other two functions. So you end up with three separate components.
Regarding multi-peer connections: yes, you can set up a P2P group chat just fine. However, each peer will need to be connected to every other peer, so the number of connections and bandwidth per peer increases with each new peer. That’s probably going to work okay for 3 or 4 peers, but beyond that you may start to run into bandwidth and CPU limits of individual peers, especially if you’re doing decent quality video streaming.
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.
I'm trying to achieve peer to peer video conference using google stun server.
I can connect anyone by stun server randomly.Because stun gives multiple and random addresses and connect with it.
But is there any way to connect specific peer by stun server for a login based system or room based system?
I want to achive something like - https://apprtc.appspot.com/
You need to design your signalling method (this is up to the application developer), which is independent of STUN.
WebRTC does not specify the mechanism for signalling. Signalling is the method whereby users discover each other and establish that a call (media streams between two peers) is going to take place.
The 'discovery' process could involve a registration-based system (eg using SIP proxy) or room based where two users have access to a 'room' (by knowing the credentials or some means of authentication). Once two peers have found each other, their browsers then need to share and negotiate network topology and media capabilities to ensure that the streams can reach the intended destination and can be encoded/decoded properly.
Is the signaling server used only the first time to establish a connection between 2 peers or is it also used to send and receive data-streams between the peers?
According to the w3c proposal:
An RTCPeerConnection allows two users to communicate directly, browser to browser. Communications are coordinated via a signaling channel which is provided by unspecified means, but generally by a script in the page via the server, e.g. using XMLHttpRequest.
So the Server is only used for signalig not for data transmission. But signaling is not limited to establishing the first connection. The signaling channel is also used for transmitting error messages, metadata such as codecs, codec settings, networkdata and keys for secure transmission.
This depends on the network configuration.
If at least one of the peers is not behind a NAT firewall, the peer that is directly on the internet acts as server, and the signalling server is no longer used after the connection is established.
If both peers are behind a NAT appliance, under certain circumstances it might be possible to negociate a client server connection between the peers, and the data is again sent directly between the two peers.
If both peers are behind a NAT firewall that is locked down, all the traffic between the peers passes through the signalling server.
Notice also that in the first two cases, a STUN server is used to establish the connection. If the full data is relayed through the server, a TURN server is used.
Look at a good explanation in the article an video on html5rocks. They claim only about 14% of all connexions need TURN, which seems a really low number to me (This corresponds to only 37% of all clients are behind a locked down NAT router).