There's some subtle interaction involved between DCUtR and webrtc hole punching especially considering that the dialer initiates the holepunch in webrtc and the receiver initiates the hole punch on DCUtR. I'm documenting some cases here. Sorry this is not too clear right now but I'd like to get other people's inputs.

It seems to me that situation will be simplified if we let the receiver of a relayed connection dial /webrtc addresses.

1. private non browser -> private non browser

• When dialing a peer that supports webrtc(private to private), the dialer sees two addresses, the relay address and the /webrtc address.
• In this case the optimal outcome is to get a holepunched quic connection. This can only happen when the dialer holds off on dialing the /webrtc address, wait for identify and then decide if the peer is a browser node or not depending on the identify information exchanged.
• This also requires that on the peer while checking for DCUtR connection reversal doesn't dial the /webrtc address. (NOTE: this has implications for webrtc: specify multiaddresses on a browser-to-browser webrtc connection #579, here we do not want to interpret /webrtc as a direct address)

2. public non browser -> browser node

• When dialing a browser node that supports webrtc (private to private) a publicly reachable host would prefer that the browser dial back and reverse the connection using webtransport. The dialer needs to hold off on dialing /webrtc
  @achingbrain, does the present js-libp2p implementation support this?

3. private non browser -> browser node

• The private non browser dialer should trigger the /webrtc connection after performing identify with the peer and inferring that the peer is a browser node that will not be able to do DCUtR.