[webrtc-rtptransport] Expose L4S bits on the receiver side (#87)

pthatcher has just created a new issue for https://github.com/w3c/webrtc-rtptransport:

== Expose L4S bits on the receiver side ==
It would be nice to expose the L4S bits on the receiver side.  We already have a way to expose the L4S bits from feedback messages sent by the receiver to the sender, and thus is known on the sender side.

But if we expose it to the receiver side, the web app could choose its own way of sending back L4S rather than relying on the existing feedback messages.  Or it could do receiver-side BWE.  Or anything it wants.

Option A: Put a RTCExplicitCongestionNotification on RTCRtpPacket (but not on RTCRtpPacketInit).  Problem: it's a little awkward because if you send an RtpPacket you received, then clearly it won't set the RTCExplicitCongestionNotification  when sending.

Option B: Return something more than RTCRtpPacket from readPacketizedRtp.  For example, return some metadata as well.  Perhaps there are timestamps about when the packet was received that would also be useful.   Perhaps we need an RTCReceivedRtp with a .packet and .explicitCongestionNotification and room for other stuff.

Please view or discuss this issue at https://github.com/w3c/webrtc-rtptransport/issues/87 using your GitHub account


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

Received on Tuesday, 13 May 2025 13:36:03 UTC