Re: [webrtc-rtptransport] RtpTransport and transport re-direction (#48)

I don't think this is something we should consider.

My understanding of this effort is essentially to take a major step towards moving basically all RTC logic into the application. In the future when encoding is done by the app then you can choose freely how you want to do BWE, how to packetize and how to transport it (RtpTransport might be one option).

I proposed having `RTCConfiguration.customPacer` and `RtpTransport.readPacketizedRtp()`, but they were only meant as stepping stones to get from the WebRTC-monolith-that-does-everything-for-you to application specific behavior, they don't really make sense long term.

When designing this API I think we have a good chance of creating an RTP/RTCP API surface that will be powerful and composable in the long term, but the rest of the API is just there to get a minimum set of pieces in place to make it usable _now_. These other set of pieces, well, to be honest they are fairly ad-hoc (this issue itself is an example of that).

I would be in favor of splitting this spec into two, one for the barebone parts of RtpTransport, and one for the convenience and piecemeal stuff. In the future, if something has to be updated to support other types of transport then the RtpTransport spec itself won't have to be updated, just the convenience stuff.

-- 
GitHub Notification of comment by Philipel-WebRTC
Please view or discuss this issue at https://github.com/w3c/webrtc-rtptransport/issues/48#issuecomment-2158261977 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 10 June 2024 12:51:03 UTC