WebRTC client & server

[melekes]

Previous work by @tomaka: #1938
Refs #1712

TODO:

• read SDP spec https://datatracker.ietf.org/doc/html/rfc3264
• modify SDP in webrtc server (and check one in client)
• working connection
• make necessary changes to webrtc rs library
• sometimes DTLS handshake does not occur => debug & figure out why. maybe this is connected to tls-id attribute? no. it's because of the issue with local candidates (see https://github.com/melekes/libp2p-webrtc-direct/blob/ed829dc035b7cff1c155bfbd402261fbadf86d72/src/transport.rs#L531-L540)
• implement https://docs.rs/libp2p/latest/libp2p/core/transport/trait.Transport.html
• submit a spec for WebRTC libp2p transport
• finish feat: Add WebRTC transport libp2p/rust-libp2p#2622
• use the new transport in smoldot

ICE conn state: checking
main.js:1 ICE conn state: connected
main.js:1 conn state: connecting
main.js:1 'data' opened
main.js:1 conn state: connected
main.js:1 new message on 'data': 'WZaAkRgSkjiGwBw'
main.js:1 new message on 'data': 'dcgSNLysAvsyMJf'
main.js:1 new message on 'data': 'OZvQJpcHmpSdApM'

[tomaka]

do we need multiple UDP ports for ICE traffic on the server?

No, https://datatracker.ietf.org/doc/html/rfc8445#section-2.2

is it possible to disable DTLS client's certificate verification? or all clients will have the same certificate too similar to servers?

I would prefer to disable DTLS client verification.
Hacks such as using the same certificate everywhere are necessary because we can't control the browser. However we're totally in control of the code on the server side, so we should do what is the most appropriate.

modify SDP in webrtc server (and check one in client)

I'm not sure that's the right approach. If I'm not mistaken, the server doesn't need to manipulate SDP at all, unless it makes it easier to interact with the API of the webrtc library.

[melekes]

I would prefer to disable DTLS client verification.

trying to figure out how to do it right now. It's possible in Go library, but not in webrtc-rs, which suggest we might need to tweak it.

I'm not sure that's the right approach. If I'm not mistaken, the server doesn't need to manipulate SDP at all, unless it makes it easier to interact with the API of the webrtc library.

Yes for the most part. I was talking about modifying some fields like IP (of the offerer, ie. client) and media's timestamp

[wemeetagain]

Why is this necessary?

[melekes]

You can discard that. It turned out to be another issue with the library I'm using.

[melekes]

Closing. The work will be continued in libp2p/rust-libp2p#2622