webrtc: specify multiaddresses on a browser-to-browser webrtc connection

[sukunrt]

The spec currently doesn't say anything on what the multiaddress on an established /webrtc (browser to browser) connection should be.

Two options off the top of my head are:
1.
Initiator Side is /webrtc, with candidate pair from ICETransport if available.
Receiver Side, the address that was dialed: <realy-addr>/p2p-circuit/webrtc

For both sides,
We get the address candidate from the ICETransport(https://github.com/pion/ice/blob/master/candidatepair.go#L23) used to establish the connection and use those with a suffix /webrtc. I'm not sure if this is available in browsers.

Between the two, I think 1 is better. In this situation we have parity with other cases where the Receiver Side address is dialable in case of a disconnection. A problem here is there is probably a lot of code that assumes addresses with /p2p-circuit component are relayed addresses, e.g. https://github.com/vyzo/libp2p-flare-test/blob/085b6bf0f2beedbe6017b86bbf60ca6e64b28ea0/cmd/flarec/client.go#L531

[mxinden]

As discussed out of band, I am in favor of (1).

Receiver Side, the address that was dialed: <realy-addr>/p2p-circuit/webrtc

That makes sense to me.

Initiator Side is /webrtc, with candidate pair from ICETransport if available.

Why not use relay-addr/p2p-circuit/webrtc here as well?

A problem here is there is probably a lot of code that assumes addresses with /p2p-circuit component are relayed addresses, e.g. https://github.com/vyzo/libp2p-flare-test/blob/085b6bf0f2beedbe6017b86bbf60ca6e64b28ea0/cmd/flarec/client.go#L531

This is unfortunate, but off the top of my head, the special handling is worth the complexity.

[achingbrain]

The version with the ICE transport is interesting from an informational point of view but it's a bit weird in that it isn't dialable in and of itself.

I think the version with the relay-addr is probably the one to use since it's the address dialed to open the connection which seems a bit more predictable.

[sukunrt]

I'm now not in favour of 1 considering the argument given in #583
Consider the case of two non browser private nodes. After they've made a relayed connection the receiver will attempt to reverse the connection. Here the receiver needs to interpret the /webrtc address that it receives in identify as a relayed connection, skip it and proceed to DCUtR.

Because of the dialable /webrtc address's(<relay>/p2p-circuit/webrtc) interaction with DCUtR and smart dialing, we want to treat it as a relayed address.
But an established /webrtc connection is a direct connection and it's better to keep the address separate to not confuse it with the dialable but relayed address.

Doing 1 forces us to do make a definition like, if the webrtc address is on a connection it is direct, otherwise it is relayed.

[achingbrain]

Would it be simpler to just add it to DCUtR as a special case?

As in change this line to attempt a unilateral upgrade if the incoming connection is either transient OR the remote address contains a p2p-circuit segment?

[sukunrt]

I've decided on doing the same thing as a circuit v2 connection:

remote end addr: <relay-addr>/p2p-circuit/webrtc
local end addr: <ip-addr>/udp/port/webrtc