How is this different to the existing libp2p WebRTC packages?

[2color]

I'm trying to get a better understanding of the different libp2p WebRTC implementations.

We have a couple in the libp2p org. How is this one different?

[ckousik]

webrtc-direct: The receiver node serves SDP over HTTP to establish an RTCPeerConnection. This works for most browsers as long as the receiver node can serve the HTTP endpoint over TLS with certificate from a trusted CA.
webrtc-star: This is not a direct connection and requires a separate signaling server.

js-libp2p-webrtc: The initiator node is able to infer the receiver node's SDP answer from it's multiaddr. Similarly, the receiver node can infer the SDP offer from the STUN connectivity checks sent by the initiator. There is no intermediary server required. The receiver needs to have a public IP (either directly on an interface, or with a NAT binding traversable by STUN). Currently, this js implementation is browser only.

Kindly refer to the spec , and the Rust and Go implementations.

[fanhai]

仅仅是推断吗？能不能穿透呢？
Is it just inference? Can it penetrate?

我有一个完整的本地ipfs服务，然后有一个基于浏览器的应用程序，我如何利用js-libp2p-webrtc 进行穿透连接呢
I have a complete local ipfs service, and then I have a browser based application. How can I use js libp2p webrtc to penetrate the connection

[ckousik]

You need to set up a WebRTC listener in the non-browser application. This should provide you with a multiaddress to which js-libp2p-webrtc can connect. If it is a complete local service, insecure WebSocket would be a better transport. WebRTC is mostly for cases where we want to connect to a remote node that does not have a domain or trusted CA cert.

[fanhai]

我的应用程序是视频通话，需要webRtc 的实时视频传输

My application is video calling, which requires webRtc's real-time video transmission

[fanhai]

我对WebSocket 与webrtc 的关系并不清楚，所以不知道你说的这种方式应该怎么做
I'm not clear about the relationship between WebSocket and webrtc, so I don't know what you should do in this way

[ckousik]

That is outside the scope of this project then. We use WebRTC for libp2p data transport. Currently there is no media support.

[fanhai]

是否有其他计划支持一下媒体传输呢
Are there any other plans to support media transmission.

[ckousik]

Not as of now

[fanhai]

ipfs 已经相当具有影响力了，我觉得浏览器厂商应该支持一下，这样就不需要webrtc作为传输层了，直接使用tcp或者udp
IPFS is already very influential. I think browser manufacturers should support it. In this way, webrtc is not needed as the transport layer, and tcp or udp is used directly.

[mxinden]

Are there any other plans to support media transmission.

Not aware of any short-term goals. Feel free to propose it to the roadmap https://github.com/libp2p/specs/blob/master/ROADMAP.md.

IPFS is already very influential. I think browser manufacturers should support it. In this way, webrtc is not needed as the transport layer, and tcp or udp is used directly.

That would be ideal, though I doubt it will happen any time soon. Would be glad to be proven wrong.

[2color]

IPFS is already very influential. I think browser manufacturers should support it. In this way, webrtc is not needed as the transport layer, and tcp or udp is used directly.

@fanhai Check out the work being done on this: https://blog.ipfs.tech/14-11-2022-igalia-chromium/