Question: I've been looking at setting up an `RTCPeerConnection` in a decentralised manner using WebRTC. This means **only using servers for NAT traversal**. 

I know that a signalling process is necessary, but would it be possible to exchange the `RTCSessionDescription` objects **directly with the peer**, instead of having to use another communications channel?

Answer: 
Let's say you are trying to connect peer A (IP address 1.2.3.4) with the peer B (IP address 5.6.7.8).

```
   A                      B
1.2.3.4                5.6.7.8

```

First thing you need to do is to let at least one of them know about IP:PORT of the other peer, so that he can initiate a connection.

Once A knows about B's IP adress, A can contact B on it's IP:PORT endpoint.

At the beginning, there is no channel between them, you'll have it later, but for now, you just don't know where you want to send your data (IP:PORT?)

Now we need to somehow get the A's IP:PORT and let B aware of it. There is no standard defined in WebRTC so you can choose whatever way to get A's IP address to B. (Websocket, Google's Channel API, even email if you are crazy enough).

```
  Some communication channel
      (i.e. Websocket)
        /           \
1.2.3.4:port         \
      /               \
     /                 >
   A                      B
1.2.3.4                5.6.7.8

```

Now, B know's about A's endpoint and he can initiate a call, send a message, create a data channel (now we have it, too late right? :)

To anwser your question with another question ... how would you know where to send the A's IP:PORT?
At the beginning there is no channel so we need some other other type of communication.

Different situation would be if you have them somehow already connected, using some kind of DHT as mentioned in the post by @tom (but that's basically also just the alternative to Websocket, etc.)

**To answer your question about DHT** in the comment, the reason why building P2P DHTs in the web browsers was so complicated/impossible til now was that we didn't have possibility of direct communication between browser peers - that's basically what DataChannel API gives us today.

The point of DHT is that there is communication among peers which exchange/forward/keep information(in this case RTCSessionDescription) among them, I personally think that using DataChannel is the best way (maybe the only one today) how to do this.

As I already mentioned in the post, DHT is just another communication alternative how to transfer your endpoint information to the other peer. You can use centralized server solution, but if it doesn't fit your design, you can go for DHT instead.
No, the whole point of the signaling is to establish the peer connection. Each side generates ICE candidates (essentially IP addresses) and shares them with the other side through the signaling channel. The ICE candidates are then used by each side to attempt the various peer-to-peer connections (local, STUN, TURN).

That said, you could build use a DHT for the signaling. See <http://webp2p.org/>.