I'm wondering if it is possible to establish a WebRTC connection between two clients that have different turn servers configured. Does the specification state if the configuration has to be identical?
What happens when they both specify different servers? Will they choose random or is the connection impossible?
The configurations don't have to be identical. If both Peers require a relay connection the TURN servers will communicate directly to each other (via their allocation ports)
If you do end up using the same TURN server make sure you handle hairpinning properly!
Related
I was curious on why a client cannot directly to a machine running webrtc server but can do that via turn server. Both turn & webrtc are in same VPC of AWS.
Could be a lot of things.
Assuming you have the TURN configuration file correct, and as you are noting both AWS instances have public IPs, then it's possible that on the instance with the TURN server, you do not have all the firewall ports opened needed related to the TURN server: https://stackoverflow.com/a/59212004/8201657
Or, maybe it's a DNS issue and the domain of your TURN server is unknown to your peer, so it is not able to access it.
Or, maybe you are attempting to connect via WebRTC but not securely. WebRTC requires a secure connnection (https).
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.
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
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).