Is ICE Necessary for Client-Server WebRTC Applications?

Question

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?

Disobedience

Answer 1

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.

Alaska

How should i implement the client so that it initiates webrtc connection? It looks like we dont have any control on who starts in webrtc! – Disobedience

You write the app, you decide who sends the offer. – Nsf

ICE works with offer, answer model. The end sending offer is the one who initiates the connection. One end sending offer means sending session description, which is actually ip informations, to the other end. When other end receives, it generate its own session description which is called answer and send it to the other end. After that ice check starts. So You need to have access to both client and server end code. From your client end code you need to send offer to the server and from your server end code receive this offer and generate and send the answer back to client. – Alaska

I would also be interested in a more in-depth example since the tests I have made always result in the client sending STUN requests even though the server tries to say it can just connect. Might be enough for another question even since I'm not using any existing server. – Bolick

Also, the RFC5245 says even ICE Lite will involve STUN so even if it's not used entirely, it is still there. – Bolick

In a client->server communication model, is adding ICE candidates necessary on one or both hosts to establish a connection? – Cailly

There is no need for ICE when its a client server communication! ICE is necessary when two end point resides on two different private network. But if you are using ICE anyway then yes you need to add candidate for both client and server to establish connection. – Alaska

Thanks! The hard part to understand was that ICE servers are really necessary when endpoint resides on two different private networks, since WebRTC doesn't provide a way to specify listening sockets for data communication, which of course it would be a totally different handshake but it would also ease a lot the client->server model use case. – Cailly

Answer 2

• 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.

Nsf

How should i configure the RTCPearConnetion on client and server so that my MCU acts as TURN? – Disobedience

You do not need your MCU to act as turn. No need for all that extra machinery. Your MCU is sitting on a public address so ICE (or ICE-Lite) is enough. Your signaling server can tell every client that connects to it to initiate an handshake (i.e. send an offer) to your MCU. – Nsf