search

w3c / webrtc-extensions

A repository for experimental additions to the WebRTC API
https://w3c.github.io/webrtc-extensions/
Other
57 stars 19 forks source link

RTCIceTransport extensions vs webrtc-ice #208

Open dontcallmedom opened 2 weeks ago

dontcallmedom commented 2 weeks ago

Back in 2018, the Working Group adopted IceTransport Extensions for WebRTC as a WG document.

Since then, the Working Group started documenting extensions to RTCIceTransport in WebRTC extensions. It would be good to clarify the relationship between the two efforts.

aboba commented 2 weeks ago

WebRTC-ICE was designed as a "standalone" ICE transport, combining aspects of ORTC's IceTransport and IceGatherer. A standalone IceTransport (e.g. an IceTransport not "vended" by WebRTC-PC) was required for the P2P QUIC Origin Trial, because that trial utilized Google QUIC (which did not support multiplexing with RTP/RTCP/DTLS) rather than IETF QUIC, which supports multiplexing with RTP/RTCP/STUN/TURN/DTLS/ZRTP via RFC 9443.

With QUIC multiplexing having been worked out, it is now possible for the proposed P2P WebTransport API to construct an RTCQuicTransport using the "vended" RTCIceTransport defined in WebRTC-PC, rather than requiring a "standalone" RTCIceTransport as defined in WebRTC-ICE or ORTC. This would be desirable if P2P WebTransport is used as a data transfer mechanism alongside RTP/RTCP/STUN/TURN packets generated by RTCPeerConnection.

On the other hand, if P2P WebTransport were used for both data transfer as well as media transport (perhaps using RTP over QUIC), then using a standalone RTCIceTransport as contemplated in ORTC or WebRTC-ICE might make more sense, since that would remove any dependency on RTCPeerConnection.

With RTP over QUIC still in the experimental stages, it's somewhat early to tell which of these use cases (if any) will prove compelling.