WebRTC transports and multiaddrs

#1

There is something I struggle to understand with multiaddresses: are they representing the means for establishing a connection with a peer, or for communicating with this peer?

For exemple with WebRTC, there is a phase of signaling that utilizes a server to negotiate the connection between the peers, and then there is a phase of peer-to-peer communication that doesn’t involve any server or third party anymore.

So let’s consider this multiaddr:
/ip4/188.166.203.82/tcp/20000/wss/p2p-webrtc-star/p2p/QmcgpsyWgH8Y8ajJz1Cu72KnS5uo2Aa2LpzU7kinSooo2a

Does the /ip4/188.166.203.82/tcp/20000/wss/p2p-webrtc-star/ part indicates that there is a signaling-star rendez-vous server at 188.166.203.82:20000 and that the node must connect to it with WebSocket Secure? Or is 188.166.203.82:20000 the address of the other node? If so, I can’t figure the /wss/ part, because 2 browsers cannot connect themselves in peer-to-peer with WebSocket.

#2

Hello @talb

The first question is the correct one. We specify the address of the signalling server. Then the signalling server uses websockets for tracking and communicating its known peers, and the webrtc listener gets that information

1 Like
#3

Thank you for your answer. So to generalize the concept, multiaddrs only represent the connection establishment and not the communication, right? WebRTC might be the only case where connection and communication don’t use the same channel though, so this problem only applies here. This is mainly because WebRTC is meant for the browsers, and we can’t use UPnP in browser Javascript to do port forwarding, unlike in the Go and Node.js implementations of libp2p.