Open mkumars20 opened 2 years ago
The OWT QUIC agent uses WebTransport stream and datagram APIs in different scenarios. Since QUIC agent only supports WebTransport over HTTP/3 (no HTTP/2 fallback), stream is ordered and reliable while datagram is unordered and unreliable.
Hi
Looks like you are sending video and audio using datagram API as its ok to be unreliable and unordered.
Under what scenario do you use stream API ?
Does both API use UDP / QUIC ?
What is the difference in latency between stream API and datagram API in your implementation ?
thanks
Currently, client sends media with stream API, receives media with datagram API, sends and receive data (arbitrary data forwarding) with stream API. This is subject to change in the future.
I don't have latency comparison between these two methods so far. Unreliable mode is still working in progress. More recovery mechanisms are needed to achieve better performance.
thanks for the reply. I am currently sending arbitary non-media data using socket io. If I send this data using streams API how much faster will it be ?
Is there also a plan to add support sending and receving arbitary data using datagram API in the client SDK ?
thanks
It depends on how much data you want to send. Sending too much data with signaling channel (socket.io) may impact portal's performance. However, WebTransport is only supported by web clients using the latest Chrome.
There is no plan to support data forwarding in datagram mode.
Ok I understand Webtransport/http3 uses reliable UDP vs TCP used in http2 or older implementations.
But for media transport in current implementations of webRTC we use sRTP over UDP.
Media over webTransport using datagram API also uses UDP.
Is there any difference in performance/ or latency or other improvements in the webtransport method as both of them still uses unreliable UDP.
So what is the need to switch to the new media over Datagram API model ?
Will this just be an option or moving forward you are going to replace current sRTP over UDP with webtransport using Datagram API for media transport ?
thanks
WebTransport is not a replacement of WebRTC. With WebRTC, both sides need to have ICE module which is designed for P2P. WebTransport natively support client server mode.
At this time, I don't expect the WebTransport mode in OWT has better performance or latency than WebRTC.
Hi So with WebTransport, owt server can work with SFU or MCU mode only and not P2P .
Also is there any specific reason for this implementation " client sends media with stream API, receives media with datagram API"
thanks
We don't have a plan to support WebTransport in P2P mode. Actually, I'm not quite sure what's your thoughts about using WebTransport in P2P mode.
No specific reason. It's just the initial version we implemented.
I was wondering what is the need to use WebTransport in OWT ?
Is it only for client server communication of media using datagram as of now ?
Unrelated question: We have data channel working with streams API using webtransport API. We are having issues when we the client tries to leave the room it has joined , it is crashing looks like something not cleaned up.
I saw this checkin , this looks like it is on the server side.
and
What is the correct set of APIs to call leaving the room correctly on the owt-client-sdk ? It is crashing when we call this? ConferenceClient::Leave(
Should we be calling unpublish or unsubscribe before calling leave.
I also see that void WebTransportOwtClientImpl::Close() { LOG(WARNING) << "Close is not implemented."; }
should'nt this implemented to close from the client side properly ?
thanks
Hi What is the underlying implementation differences between Streams API and Datagram API with OWT server / client implementation using chromium ?
Does datagram API use UDP at transport layer ?
Does stream API QUIC for transport layer or does it use TCP as it is reliable? or is has better latency than TCP and still it is reliable ?
thanks