RtpTransport and transport re-direction

[aboba]

One potential use case for RtpTransport would be to capture the RTP packets that would have been generated by WebRTC, and then redirect them over another transport (such as WebTransport or P2P WebTransport).

Such a use case would require the following:

• Ability to capture the RTP packets that would have been sent
• Ability to turn off RTP congestion control (since CC is handled by QUIC)
• Ability to specify the desired MTU for an audio or video stream
• • Decrease MTU of audio packets slightly to allow for additional QUIC datagram overhead
• • Use infinite MTU for video packets when transporting them over a QUIC reliable stream

[Philipel-WebRTC]

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.